Recentemente, estou tentando transmitir uma área de trabalho remota usandoffmpeg. O objetivo é poder enviar o que é mostrado na tela de um computador para outro computador e ao mesmo tempo escolher configurações como resolução de saída, etc.
É um pequenoquase funcionandoprova de conceito. Quando terminar, poderei substituir o VNC usandoffmpegtransmitindo comx2xousinergiapara 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 cerca de 800ms.
Coisa que estou tentando alcançar:
- Alcance uma latência de100ms.
Quando
mplayer
é executado ele reclama que não consegue buscar em fluxos lear e hásem áudio. Ainda tenho o som quando salvo a saída em um arquivo e a reproduzo.EDIT: Após adicionar
-cache
, as mensagens para buscar em fluxos lineares não aparecem mais. Alterar o formato de saída para-f mpegts
fazer o áudio funcionar.Seria ótimo se a codificação não ocupasse 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. No entanto, não conheço 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? Em caso afirmativo, quais seriam os comandos equivalentes para transmitir de um desktop para outro?
Responder1
O streaming do desktopA para o desktopB é um problema interessante. Se você não precisa de vídeo/áudio, talvez queira verificar o protocolo NX. É muito mais eficiente que o VNC. FreeNX é um servidor e NoMachine e outros fazem clientes NX. Existem outros servidores - gratuitos e comerciais.
Também há trabalho sendo executado em um desktop remoto de alto desempenho, SPICE, como um projeto F/LOSS. Acho que Redhat está assumindo a liderança.http://spice-space.org/
Não sei se essas respostas são úteis, mas talvez apenas levem a algo mais útil?
Para streaming de vídeo, provavelmente é necessário evitar a sobrecarga de um protocolo de desktop completo.
Responder2
Recentemente, precisei configurar o streaming de baixa latência com requisitos ainda mais rígidos do que o postador original (OP). Eu desenvolvi uma solução que funciona bem o suficiente para ser usada como um monitor adicional para meu laptop, com entrada suave de mouse e teclado.
No lado do envio, usei o seguinte ffmpeg
comando:
ffmpeg -video_size 1920x1080 -r 30 -framerate 30 -f x11grab -i :0.0+0x0 \
-b:v 40M -maxrate 50M -bufsize 200M \
-field_order tt -fflags nobuffer -threads 1 \
-vcodec mpeg4 -g 100 -r 30 -bf 0 -mbd bits -flags +aic+mv4+low_delay \
-thread_type slice -slices 1 -level 32 -strict experimental -f_strict experimental \
-syncpoints none -f nut "tcp://10.0.0.1:1234"
A parte crítica deste comando é o argumento -g 100, que adiciona tempo entre os quadros-chave, diminuindo a taxa de bits do fluxo.
No lado de recepção, usei ffplay
(incluído ffmpeg
) para exibir o stream em um Raspberry Pi 3:
ffplay -autoexit -flags low_delay -framedrop -strict experimental \
-vf setpts=0 -tcp_nodelay 1 "tcp://10.0.0.1:1234\?listen"
Embora eu perceba que a pergunta original tem mais de uma década e que o poder de processamento disponível para o usuário médio tenha melhorado significativamente desde então, esses dois comandos fornecem um ponto de partida razoável para qualquer pessoa que queira configurar um fluxo de baixa latência em uma rede local, mesmo em hardware de baixo custo.