Потоковая 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, которая не работает должным образом. поскольку он отвечает за генерацию часов.
