5

在将解复用的 h264 解码输出发送到 gstreamer 管道中的 autovideosink 之前，是否可以在两者之间提供一些延迟。如果是这样，任何人都可以发布示例管道来做到这一点。我使用的管道是 udpsrc port=5000 ！mpegtsdemux 名称=demux ！队列 ！ffdec_h264 ！ffmpeg色彩空间！自动视频接收器解复用器。！队列 ！ffdec_mp3！音频转换！alsasink 解复用器

在这种情况下，一旦在 upd-port 5000 接收到流，它将在 demuxing-queuing-decoding 后立即开始播放。在将其发送到实际播放的自动视频接收器之前是否有任何延迟的可能性，例如 60 秒。是否有任何 Gstreamer 插件/元素可以做到这一点。

4

2 回答 2

5

您可能需要查看queue的参数（运行gst-inspect queue）：

max-size-buffers    : Max. number of buffers in the queue (0=disable)
                      flags: lesbar, schreibbar
                      Unsigned Integer. Range: 0 - 4294967295 Default: 200
max-size-bytes      : Max. amount of data in the queue (bytes, 0=disable)
                      flags: lesbar, schreibbar
                      Unsigned Integer. Range: 0 - 4294967295 Default: 10485760
max-size-time       : Max. amount of data in the queue (in ns, 0=disable)
                      flags: lesbar, schreibbar
                      Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 1000000000
min-threshold-buffers: Min. number of buffers in the queue to allow reading (0=disable)
                      flags: lesbar, schreibbar
                      Unsigned Integer. Range: 0 - 4294967295 Default: 0
min-threshold-bytes : Min. amount of data in the queue to allow reading (bytes, 0=disable)
                      flags: lesbar, schreibbar
                      Unsigned Integer. Range: 0 - 4294967295 Default: 0
min-threshold-time  : Min. amount of data in the queue to allow reading (in ns, 0=disable)
                      flags: lesbar, schreibbar
                      Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 0

通过设置min-threshold-time，您可以将输出延迟 n 纳秒。
我刚刚用我的网络摄像头试了一下，它工作正常（延迟 60 秒）：

gst-launch v4l2src ! queue max-size-buffers=0 max-size-time=0 max-size-bytes=0 min-threshold-time=60000000000 ! autovideosink

请注意，我已将max-size-*参数设置为 0，因为如果队列在达到阈值之前填满，您将无法从队列中获取数据。

请记住，对解码的视频流进行排队可能会导致大量内存使用。使用您编码的 udpsrc，我建议延迟编码的 h264 流。您可能需要以字节而不是纳秒为单位设置阈值（我认为队列对编码数据的了解不足，无法猜测比特率）。

于 2013-06-20T15:46:39.047 回答
2

我的解决方案是将延迟添加到自动音频接收器。一个漂亮的功能，神秘地称为 ts-offset：

$ gst-launch-1.0 souphttpsrc location=http://server:10000/ ! queue \
    max-size-bytes=1000000000 max-size-buffers=0 max-size-time=0 ! \
    decodebin ! autoaudiosink ts-offset=500000000

min-threshold-* 对我不起作用。

延迟有效。禁用同步也有效：

$ gst-launch-1.0 souphttpsrc location=http://server:10000/ ! \
    decodebin ! autoaudiosink sync=false

对于音乐，就像我用它来做的那样，同步并不重要，只是在改变曲目时让下一首歌早点出现是件好事。所以我还是更喜欢半秒的延迟。

通常，禁用同步时，流会慢慢失去同步。对于实时生成数据的直播流，可以通过要求队列转储额外数据来保持流同步：

gst-launch-1.0 souphttpsrc location=http://server:10000/ ! \
    queue max-size-bytes=65536 max-size-buffers=0 max-size-time=0 \
    leaky=downstream ! decodebin ! autoaudiosink sync=false

这使流同步到数据首次在服务器上可用时的 64KiB 以内。这最终成为了我的首选解决方案，因为我正在流式传输数据，这些数据是由同一 wifi 网络上的计算机的声卡实时生成的。这仅适用于直播。如果流的数据已经预先确定，这将不起作用，在这种情况下，整个流将被尽快下载，从而导致整个内容或多或少地快进播放。

于 2016-10-22T20:54:49.913 回答