Como formular o comando FFmpeg para fluxo de latência ZERO no headset VR?

Question

Como se poderia formular um comando para streaming ponto-a-ponto de 60 a 90 Hz de um PC para outro com a menor latência possível usando o ffmpeg?

Notícia completa:

Eu criei um fone de ouvido de realidade virtual a partir de uma caixa de som da Amazon, giroscópio + arduino e tela HDMI de 2 K da Alibaba. Funciona bem com o mecanismo Blender Game, mas o fio me deixa louco.

Estou tentando fazer com que seja sem fio com um Raspberry Pi ou algum outro pequeno computador. (Eu preciso adicionar um peso na parte de trás para equilibrar o fone de ouvido de qualquer maneira)

É assim que eu imagino configurando as coisas -

Servidor (PC): janela do aplicativo Stream 2K com a menor latência possível para uma das portas no IP

Client (HMD): Executa o Mplayer no modo de benchmark para a menor latência possível (por documentação do FFmpeg)

O FFmpeg é totalmente integrado ao Blender, mas o fluxo de entrada pode ser apenas uma captura de tela da área de trabalho.

O roteador doméstico do meu provedor suporta 5Ghz Wifi. Eu também tenho um pen drive USB 5Ghz Wifi CSL que é plug-and-pay com o Linux.

Como a latência é muito ruim para a RV, acho que posso reduzir alguns milissegundos ao transmitir sem compressão? Como o streaming é apenas sobre a largura de banda da LAN é limitado apenas eu acho que por 5GHz Wifi que eu acho que como 100Mb / s.

Existem centenas de maneiras de interpretar a documentação do ffmpeg, parece que você só pode realmente entender quais opções usar a partir da experiência. Não vejo ninguém tentando a mesma coisa.

Eu poderia passar uma semana tentando todas as configurações possíveis, mas tenho certeza de que alguém que lida com o ffmpeg todos os dias saberia as melhores configurações para isso imediatamente.

Este comando dá cerca de um segundo de atraso e 25 FPS:

Servidor: avconv -f x11grab -s 2160x1200 -r 60 -i: 0.0 -f mpegts udp: //192.168.0.2: 1234

Cliente: mplayer -benchmark udp: //192.168.0.2: 1234

Se eu usar 'rawvideo', o fluxo não será captado pelo mplayer. Ele dirá apenas "fluxo não procurado".

    

Answer 1

avconv -f x11grab -s 640x1200 -r 60 -i :0.0 -f mpegts udp://192.168.0.2:1234

avconv -f x11grab -s 640x1200 -r 60 -i :0.0 -f mpegts udp://192.168.0.2:1235

avconv -f x11grab -s 640x1200 -r 60 -i :0.0 -f mpegts udp://192.168.0.2:1236

avconv -f x11grab -s 640x1200 -r 60 -i :0.0 -f mpegts udp://192.168.0.2:1237

e

MPlayer no modo de referência, sem latência

Mais detalhes: Descobri essencialmente que o fluxo precisa ser dividido para usar mais CPU. Usar 'legal' para priorizar um único fluxo não faz nada. É só empurrar 2k a 25fps usando talvez 30% da CPU. Onde, como se eu dividi-lo em vários fluxos como acima, posso obter 60FPS em cada telha com 85% de uso da CPU. A opção -threads 0 a 6 não se comporta como se esperaria. Isso apenas torna o rending mais lento se qualquer coisa. H264 é melhor e a rede tem que ser gigabit.