的Gstreamer H264管道滯後

我使用gst-rtsp-server具有下列管道：的Gstreamer H264管道滯後

gst_rtsp_media_factory_set_launch(factory, "(" 
    "appsrc name=mysrc " 
    "! videoconvert " 
    "! videoscale " 
    "! video/x-raw,format=I420,width=350,height=250 " // fps 
    "! x264enc bitrate=128 speed-preset=ultrafast tune=zerolatency byte-stream=true threads=4 key-int-max=15 intra-refresh=true " 
    "! video/x-h264,profile=baseline " 
    "! rtph264pay name=pay0 pt=96 mtu=1300 " 
")");

來發送H264視頻流（我是完全新到gstreamer的）。我在推模式下運行：

g_object_set(appsrc, "stream-type", GST_APP_STREAM_TYPE_STREAM, NULL);

並且只能通過需要數據回調進行推送。大多數情況下，一切都按預期工作。當我運行我的服務器時 - 我的相機正常播放，除了我的視頻流正在經歷2秒（大約）的延遲。

無論我使用哪種設置組合，此延遲都是一致的。

不同

比特率
的攝像頭分辨率
在4 fps的運行：GST_BUFFER_DURATION(buffer) = gst_util_uint64_scale_int(1, GST_SECOND, 4);
運行在30fps：GST_BUFFER_DURATION(buffer) = gst_util_uint64_scale_int(1, GST_SECOND, 30);

都具有相同的效果。這就像我的流積累了一個確切的2秒的滯後時間，並且從那以後永久地被抵消了。就好像gstreamer在開始廣播之前正在將其內部緩衝區積累到特定的大小。

因爲我對gstreamer缺乏經驗，所以我對此持平。如果有人有任何想法或提示指向我一些方向繼續調試，這將不勝感激。

編輯：

爲了完整（如果任何人涉及到這個問題），之後@peter的方向，我不得不改變我的管道，以適應現在的VLC緩衝較小。我不知道這是否是「正確的方式」，但它對我有用。

我基本上使我的「製作人」（我的程序）以60fps的速度製作，並使用videorate模塊將其縮小到30fps以用於傳輸。有了這個，我能夠給VLC一個200ms的緩衝區。這是我的新管道。

gst_rtsp_media_factory_set_launch(factory, "(" 
    "appsrc name=mysrc " 
    "! videoconvert " 
    "! videoscale " 
    "! videorate " 
    "! video/x-raw,format=I420,width=350,height=250,framerate=30/1 " // fps 
    "! x264enc bitrate=128 speed-preset=ultrafast tune=zerolatency byte-stream=true threads=4 key-int-max=15 intra-refresh=true " 
    "! video/x-h264,profile=baseline " 
    "! rtph264pay name=pay0 pt=96 mtu=1300 " 
")");

再次感謝@peter。

來源

2016-04-24 JDR

您的發件人可能是100％的罰款。如果我是一個賭博的人，我敢打賭問題出在接收者身上。

一些接收器（如VLC）將要緩衝視頻以防止口吃。如果可能的話，如果您的目標延遲時間較短，我會通過接收器上的選項來關閉這些選項。

編輯補充：

檢查了這一點：http://www.groovypost.com/howto/change-vlc-streaming-buffer/ 默認情況下，VLC有1500毫秒（1.5秒）高速緩存。

來源

2016-04-24 04:17:32

@peter皮特，你是我的朋友（我甚至忘了提及我使用的接收器確實是VLC），謝謝。我幾天來一直在爲此撓頭。我希望我能做的不只是打字謝謝 - *流下了眼淚* - 謝謝！ – JDR

的Gstreamer H264管道滯後

回答

相關問題