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

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

Наша настройка - кодирование с x264 (w/zerolatency и ultrafast) и упакованное в 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-плагина, поэтому решение, которое будет работать там, будет еще лучше.

Ответ 1

Вы можете добавить "sync = false" в исходный конвейер gst. На Ubuntu 12.04, который, кажется, удаляет сообщения о задержке и ошибке.

Здесь команда, которую я использовал в источнике:

gst-launch videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 sync=false

и вот что я использовал на приемнике:

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

К сожалению, я понятия не имею, почему это работает или даже какой компонент принадлежит свойству "sync = false" (в конвейере источника).

Ответ 2

Как выгрузили root.ctrlc, вы можете использовать sync = FALSE. Однако вы можете заметить огромный рост использования ЦП на стороне отправителя. Причина в том, что sync = FALSE сообщает приемнику просто выталкивать буферы, как только он их получает. Раковина управляет всем конвейером. Следовательно, sync = FALSE приведет к тому, что конвейер будет кодировать видео и подталкивать его к UDP как можно быстрее; он будет использовать 100% процессор.

Вам нужен gstrtpjitterbuffer. Он также заботится о временных метоках, которые здесь нарушаются.

Пример отправителя:

gst-launch-0.10 -v videotestsrc ! videorate ! video/x-raw-yuv, framerate=30/1 ! ffmpegcolorspace ! x264enc ! rtph264pay ! udpsink port=50000 host=<sender IP>

Пример приемника:

gst-launch-0.10 udpsrc port=50000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000 , encoding-name=(string)H264 , payload=(int)96" ! gstrtpjitterbuffer ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! "video/x-raw-yuv, width=320, height=240" ! xvimagesink

Ответ 3

Я не знаю, насколько это правда, но когда я запускаю свой конвейер, не подключая зарядное устройство к ноутбуку, он использовал для меня то же предупреждение, и когда я подключил блок питания, поверьте мне это работал. Я думаю, что это может быть из-за старой батареи CMOS, которая не работает должным образом. поскольку он отвечает за генерацию часов.