Estou com problemas para transmitir vídeo H.264 por RTSP. O objetivo é transmitir ao vivo uma imagem da câmera para um cliente RTSP (idealmente, um plug-in de navegador no final). Isso tem funcionado muito bem até agora, exceto por um problema: o vídeo fica lento na inicialização, gagueja a cada poucos segundos e demora ~ 4 segundos. Isto é mau.

Nossa configuração é codificar com x264 (w / zerolatency e ultrafast) e compactar em RTSP / RTP com libavformat do ffmpeg 0.6.5. Para testes, estou recebendo o fluxo com um pipeline do GStreamer com gst-launch ao se conectar a um servidor RTSP.ContudoEu consegui reproduzir o mesmo problema ao transmitir direto de outra instância do GStreamer com apenas RTP.

Máquina de envio:

gst-launch videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=10.89.6.3

Máquina de recepção:

gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink

Você também pode executar esses dois na mesma máquina, basta alterar o host para 127.0.0.1 no remetente. No final do recebimento, você deve observar um vídeo intermitente e geralmente de baixo desempenho, junto com avisos repetidos no console:

WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: A lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2875): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:
There may be a timestamping problem, or this computer is too slow.

Uma "correção" comumente sugerida que vi em toda a Internet é usarsync=false com xvimagesink:

gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink sync=false

O vídeo será reproduzido com latência próxima de zero, mesmo quando testado com o software da câmera. Isso é útil para testes, mas não é muito útil para implantação, pois não funcionará com o Totem, o VLC ou o plug-in do navegador.

Eu gostaria de tentar resolver o problema na fonte; Suspeito que haja algum tipo de informação de timestamp ausente no fluxo H.264 por x264 ou talvez nos payloads do RTP. Existe alguma maneira de modificar ofonte gasoduto gst para que eu façanão precisa usarsync=false no receptor?

Se isso não for possível, como posso informar aos clientes (via SDP ou de outra forma) que o fluxo não deve ser sincronizado? Por fim, incorporaríamos isso no navegador usando um tipo de plug-in do VLC, para que uma solução que funcionasse ali fosse ainda melhor.