Streaming RTP/RTSP：sync/timestamp problems

我在通過RTSP傳輸H.264視頻時遇到了一些問題。我們的目標是將攝像頭圖像直播到RTSP客戶端（最終是一個瀏覽器插件）。迄今爲止，這一切都非常順利，除了一個問題：視頻將在啓動時滯後，每隔幾秒結束，並且延遲約4秒。這不好。Streaming RTP/RTSP：sync/timestamp problems

我們的設置是用x264（w/zerolatency & ultrafast）進行編碼，並使用ffmpeg 0.6.5的libavformat打包到RTSP/RTP中。爲了進行測試，我在連接到RTSP服務器時使用帶有gst-launch的GStreamer管道接收流。但是，我只能用RTP從另一個GStreamer實例直接流式傳輸時就能夠重現相同的問題。

發送機：

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或其瀏覽器插件嵌入。

我想嘗試從源頭上解決問題;我很懷疑x264或者RTP有效載荷上的H.264流中缺少某種時間戳信息。有沒有什麼辦法可以修改來源 gst管道讓我做不是需要在接收器上用sync=false？

如果這是不可能的，我該如何告訴客戶端（通過SDP或其他方式）流不應該同步？最終，我們會使用各種VLC插件將其嵌入到瀏覽器中，因此，在那裏工作的解決方案會更好。

來源

2012-07-09 Jacob Peddicord

您可以將「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」屬性（在源管道上）。

來源

2012-07-12 23:00:18

謝謝你..同樣的問題，但我已經在接收端給予「sync = false」，它爲我工作。 – 2016-08-12 10:41:53

由於發佈了root.ctrlc，因此可以使用sync = FALSE。但是，您可能會注意到發件人的CPU使用率大幅增加。原因是sync = FALSE指示接收器一接收緩衝區就立即推出緩衝區。水槽驅動整個管道。因此，sync = FALSE將導致流水線對視頻進行編碼並儘可能快地將其推送到UDP;它將使用100％的CPU。

你需要的是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

來源

2012-08-02 23:09:46

+1，但是當我們使用gst-launch-0.10 -v'gstrtpbin name = rtpbin latency = 40 udpsrc caps =「..」port = 50000'時，你如何使用'gstrtpjitterbuffer'，你能分享一下接收器部分嗎？使用gstrtpbin使用？ – YumYumYum 2013-11-18 17:19:46

gsrtpbin已包含gstrtpjitterbuffer。至於命令行，我會盡力回覆你。目前我無法嘗試，因爲我沒有安裝GStreamer 0.10。（順便說一句，你真的應該移動到1.0，這是強烈建議。） – 2014-02-18 13:28:11

@dv_感謝您指向'gstrtpjitterbuffer'和'sink = false'的解釋。你能否解釋一下如何驅動管道（當'sync = true'時）？ – joanpau 2015-05-06 19:52:22

我不知道有多少，這是真的，但是當我跑我沒有管道將電池充電器連接到我的筆記本電腦，它曾經給我帶來同樣的警告，當我插上電源時，請相信我的工作。我認爲這可能是因爲舊的CMOS電池，這是不應該的，因爲它應該是。因爲它負責時鐘產生。

來源

2014-03-17 18:08:17

在這種情況下，我懷疑您的筆記本電腦有電源配置選項，以減少使用電池供電時的最大可用CPU功率。當你用充電器運行時，你可以獲得100％的CPU，當你使用電池運行時，你會減少。因此「或這臺電腦太慢」。 – KevinM 2014-05-26 07:56:28

Streaming RTP/RTSP：sync/timestamp problems

回答

相關問題