的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管道滞后

回答

相关问题