Estoy teniendo algunos problemas para transmitir video H.264 sobre RTSP. El objetivo es transmitir en vivo una imagen de la cámara a un cliente RTSP (idealmente un complemento del navegador al final). Esto ha estado funcionando bastante bien hasta ahora, excepto por un problema: el video se retrasará en el inicio, tartamudeará cada pocos segundos y tiene un retraso de ~ 4 segundos. Esto es malo.

Nuestra configuración es codificar con x264 (w / cerolatency & ultrarrápido) y empaquetado en RTSP / RTP con libavformat de ffmpeg 0.6.5. Para las pruebas, estoy recibiendo el flujo con un canal de GStreamer con gst-launch cuando me conecto a un servidor RTSP.sin embargo, He podido reproducir el mismo problema al transmitir directamente desde otra instancia de GStreamer con solo RTP.

Máquina de envío:

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

Máquina de recepción:

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

También puede ejecutar estos dos en la misma máquina, simplemente cambie el host a 127.0.0.1 en el remitente. En el extremo receptor, deberías notar un video de tartamudeo y generalmente de bajo rendimiento, junto con advertencias repetidas en la consola:

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.

Una "solución" sugerida comúnmente que he visto en todo Internet es usarsync=false con xvimagesink:

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

Luego, el video se reproducirá con una latencia cercana a cero, incluso cuando se pruebe con nuestro software de cámara. Esto es útil para las pruebas, pero no es muy útil para la implementación, ya que no funcionará con Totem, VLC o las incrustaciones de su navegador.

Me gustaría tratar de resolver el problema en la fuente; Sospecho que falta algún tipo de información de marca de tiempo en la transmisión H.264 por x264 o quizás en las cargas útiles de RTP. ¿Hay alguna manera de modificar elfuente gst tubería para que yo hagano necesitará usarsync=false en el receptor?

Si eso no es posible, ¿cómo puedo informar a los clientes (a través de SDP o de otra manera) que la transmisión no debe estar sincronizada? En última instancia, incrustaríamos esto en el navegador utilizando una especie de plugin VLC, por lo que una solución que funcionaría allí sería aún mejor.