Потоковая передача RTP/RTSP :проблемы с синхронизацией/отметкой времени

У меня возникли проблемы с потоковой передачей видео H.264 через RTSP. Цель состоит в том, чтобы -транслировать изображение с камеры в режиме реального времени на RTSP-клиент (, в идеале — плагин для браузера ). До сих пор это работало довольно хорошо, за исключением одной проблемы :видео будет отставать при запуске, заикаться каждые несколько секунд и иметь задержку ~4 -секунд. Это плохо.

Наша настройка состоит в том, чтобы кодировать с помощью x264 (с нулевой задержкой и сверхбыстрым )и упакованным в RTSP/RTP с помощью libavformat из ffmpeg 0.6.5. Для тестирования я получаю поток с конвейером GStreamer с запуском gst -при подключении к RTSP-серверу. Однако мне удалось воспроизвести ту же проблему при потоковой передаче прямо из другого экземпляра GStreamer только с RTP.

Отправляющая машина:

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

Приемная машина:

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

Вы также можете запустить их на одном компьютере, просто измените хост на 127.0.0.1 на отправителе. На принимающей стороне вы должны заметить заикание и в целом плохое -воспроизведение видео, а также повторяющиеся предупреждения на консоли :

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.

. Одно обычное -предлагаемое «исправление», которое я видел во всем Интернете, заключается в использовании sync=falseс xvimagesink:

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

Затем видео будет воспроизводиться почти с нулевой задержкой -, даже при тестировании с нашим программным обеспечением камеры. Это полезно для тестирования, но не очень полезно для развертывания, поскольку оно не будет работать с Totem, VLC или их встроенными плагинами для браузера.

Я хотел бы попытаться решить проблему в источнике; Я подозреваю, что в потоке H.264 x264 или, возможно, в полезных нагрузках RTP отсутствует какая-то временная метка. Есть ли способ изменить исходный gst-конвейер, чтобы мне не приходилось использовать sync=falseна приемнике?

Если это невозможно, как я могу сообщить клиентам (через SDP или иным образом ), что поток не следует синхронизировать? В конце концов, мы бы встроили это в браузер с помощью своего рода плагина VLC, поэтому решение, которое будет работать там, будет еще лучше.