Streaming de baixa latência usando ffmpeg

Question

Recentemente, estou tentando transmitir uma área de trabalho remota usando ffmpeg . O objetivo é ser capaz de enviar o que é mostrado em uma das telas do computador para outro computador, sendo capaz de escolher configurações como a resolução de saída, etc.

É uma pequena prova de conceito. Quando terminar, poderei substituir o VNC usando o ffmpeg streaming com x2x ou sinergia para encaminhar eventos de teclado e mouse.

Agora, posso começar a transmitir usando:

ffmpeg -f x11grab -s "1600x1200" -i ":0" \
    -f alsa -i pulse \
    -s 800x600 -b 200k -f mpegts - \
    | mplayer -cache 1024 -
#
# I have pulse audio configured so that '-i pulse' will
# The output can sent through for example netcat to another host
#

A latência depende das opções de codificação. Com essas opções, o atraso entre a atualização da tela e a atualização do vídeo é de 800ms.

Coisa que estou tentando alcançar:

• Alcance uma latência de 100 ms .

• Quando mplayer é executado, ele reclama que não pode procurar em fluxos lear e não há nenhum áudio . Eu ainda tenho o som quando estou salvando a saída em um arquivo e o reproduzo.

  EDIT: After adding -cache, messages to seek in linear streams no longer appear. Changing output format to -f mpegts makes the audio work.

• Seria ótimo se a codificação não aceitasse 100% de um dos núcleos da CPU (objetivo secundário).

Depois de algumas pesquisas na internet, acho que esses problemas estão relacionados aos codecs / opções que devo usar. Ainda não sei as diferenças entre as possibilidades existentes. Você poderia me dar algumas opções que resolveriam meus problemas? Além disso, o VLC é uma boa alternativa e, em caso afirmativo, quais seriam os comandos equivalentes para transmitir de um desktop para outro?

    

Answer 1

A transmissão do desktopA para o desktopB é um problema interessante. Se você não precisa de vídeo / áudio, talvez queira fazer o check-in no protocolo NX. É muito mais eficiente que o VNC. O FreeNX é um servidor e o NoMachine e outros fazem clientes do NX. Existem outros servidores - gratuitos e comerciais.

Também há trabalho sendo executado em um desktop remoto de alto desempenho, SPICE, com capacidade de projeto F / LOSS. Eu acho que Redhat está assumindo a liderança. link

Eu não sei se estas são respostas úteis, mas talvez apenas leve a algo mais útil?

Para streaming de vídeo, provavelmente é necessário evitar a sobrecarga de um protocolo de desktop completo.