Obter latência semelhante ao webrtc com ffmpeg?

Eu tenho usado isso entre o Chrome e meu telefone:

http://www.webrtc.org/demo

E a latência é realmente boa - menos de 1 segundo.

Eu tenho tentado replicar isso no meu computador sem sucesso.

ffmpeg -f video4linux2 -i /dev/video0  -s 320x200 -r 50 -deadline realtime -vcodec libvpx -f webm -fflags nobuffer udp://10.0.0.55:9002

E então usando ffplay do outro lado.

Ainda tem alguns segundos de atraso.

Eventualmente, eu gostaria de transmitir do meu computador para o telefone Android, mas a latência precisa ser boa.

Editar - isso funciona significativamente melhor. Se eu pudesse me poupar um pouco disso, ficaria feliz:

ffmpeg -vcodec rawvideo -f video4linux2 -i /dev/video0  -s 320x200 -r 25 -vcodec libvpx -f rtp -deadline realtime rtp://10.0.0.55:9002

ffmpeg video-streaming

— David N. Welton
fonte

O link está morto. Basicamente, você deseja converter vídeos e transmiti-los para o seu telefone? No wifi ou externo?

— Jiggunjer

O que eu quero fazer é transmitir a partir de uma câmera conectada a um dispositivo e exibir em um tablet Android (Nexus 10) conectado via USB.

— David N. Welton

Não sei muito sobre esses codecs, mas você verificou se eles são acelerados por hardware sempre que possível? Esse seria o meu palpite sobre o motivo pelo qual você vê mais de 1 segundo de latência.

— Snoopen 29/05

VPX vai ser complicado para perto de tempo real, eu sei x264 tem uma melodia "baixa latência" ou algo parecido FWIW

— rogerdpack

O problema é principalmente do fato de você estar usando a transcodificação de software , em vez da transcodificação de hardware .

Como regra geral, se a conversão usar a aceleração de hardware, a latência será da ordem de menos de um segundo (geralmente milissegundos). Se isso for feito em software, a latência será da ordem de mais de um segundo.

O FFmpeg suporta aceleração de hardware, mas geralmente é complicado fazê-lo funcionar para você.

https://trac.ffmpeg.org/wiki/HWAccelIntro

Por outro lado, o Google Chrome suporta codificação / decodificação de hardware VP8 e H264 (quando disponível), tanto no seu computador quanto no seu telefone Android:

http://code.google.com/p/chromium/issues/detail?id=428223

— Ho1
fonte

Não se trata apenas de aceleração de hardware ... a configuração do codec desempenha um papel muito maior na latência. O codec precisa ser ajustado para manter a latência baixa, em detrimento da qualidade e da largura de banda. Isso pode ser feito se você estiver usando codecs acelerados por hardware ou não.

— Brad

Esse link diz especificamente que o Chrome NÃO suporta codificação de hardware na área de trabalho, APENAS no Android.

— davr 18/03/19

Desculpe, mas Brad está certo, a resposta está totalmente errada: desde que você defina as mesmas configurações de codec, não haverá nenhuma diferença se você fizer codificação de hardware ou software (contanto que você tenha capacidade de CPU suficiente para codificar em tempo real com o seu configurações de codec). Correto é que não se trata apenas das configurações do codec de vídeo, mas principalmente do tipo de transporte e comportamento de buffer do decodificador. O WebRTC funciona porque está ajustado para baixa latência. Decodificador Webm típico não se destina a fazer baixa latência

— Harry