正在运行的 gstreamer 管道现在需要一堆队列组件，为什么？
我有一个 C 程序，可以将 v4l2 源中的视频和音频录制为 flv 格式。我注意到该程序不适用于较新版本的 ubuntu。我决定尝试在 gst-launch 中运行有问题的管道，并尝试找到能够重现该问题的最简单的管道。仅关注视频方面，我已将其简化为您在下面看到的内容。
所以我有一个正在工作的 gstreamer 管道：
gst-launch v4l2src ! tee name="vtee" ! queue ! videorate ! ffmpegcolorspace ! ffdeinterlace ! x264enc ! flvmux name="mux" ! filesink location=vid.flv vtee. ! queue ! xvimagesink
现在只有当我在 xvimagesink 之前添加了一堆队列时，它才会工作。虽然这确实有效，但在管道开始工作之前我得到了 2 秒的延迟，并且我还收到了消息：
gst-launch v4l2src ! tee name="vtee" ! queue ! videorate ! ffmpegcolorspace ! ffdeinterlace ! x264enc ! flvmux name="mux" ! filesink location=vid.flv vtee. ! queue ! queue ! queue ! queue ! queue ! xvimagesink
虽然上面的第二个管道可以工作，但在管道开始运行之前有一个暂停，我收到了消息（我不认为这个系统慢了 2 倍，它是一个带有大量内存的核心 i7）：
Additional debug info:
gstbasesink.c(2692): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:
There may be a timestamping problem, or this computer is too slow.
任何人都可以解释这里发生了什么吗？我做错了什么？
I have a C program that records video and audio from a v4l2 source into flv format. I noticed that the program did not work on newer versions of ubuntu. I decided to try to run the problamatic pipeline in gst-launch and try to find the simplest pipeline that would reproduce the problem. Just focusing on the video side I have reduced it to what you see below.
So I have a gstreamer pipeline that was working:
gst-launch v4l2src ! tee name="vtee" ! queue ! videorate ! ffmpegcolorspace ! ffdeinterlace ! x264enc ! flvmux name="mux" ! filesink location=vid.flv vtee. ! queue ! xvimagesink
Now it will only work if I do this with a bunch of queue's added one after another before the xvimagesink. Although this does work I get a 2 second delay before the pipeline starts to work and i also get the message :
gst-launch v4l2src ! tee name="vtee" ! queue ! videorate ! ffmpegcolorspace ! ffdeinterlace ! x264enc ! flvmux name="mux" ! filesink location=vid.flv vtee. ! queue ! queue ! queue ! queue ! queue ! xvimagesink
Although the second pipeline above works, there is a pause before the pipeline starts running and I get the message (I don't think this system is 2 slow, its a core i7 with tons of ram):
Additional debug info:
gstbasesink.c(2692): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:
There may be a timestamping problem, or this computer is too slow.
Can any one explain what is happening here? What am I doing wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您声称第一条管道停止工作，但没有解释发生了什么。由于其他事情发生了变化，事情停止了：
- GStreamer 和子模块的版本？
- 操作系统版本？
- 相机版本？
没有必要连续添加一堆队列。在实践中，他们将创建线程边界并将跨线程的前后部分分开，这将增加您看到的延迟，这将影响延迟和同步。
You claim that the first pipeline stopped working but you don't explain what happened. Things stop working because something else changed:
- version of GStreamer and submodules ?
- version of OS ?
- version of camera ?
It shouldn't be necessary to add a bunch of queues in a row. In practice they will create thread boundaries and separate the part before and after across threads, and it will add the delay you see, which will affect the latency and sync.
旧消息，但问题仍然没有解决。介于
9.10和11.10之间（我在注意到之前升级了一些）。我通过避免使用 x264enc 并使用 ffenc_mpeg4 来解决这个问题。我刚刚注意到 Gstreamer Cheat Sheet 中的这条注释：
注意：我们可以替换
theoraenc +oggmux与x264enc+someothermuxer但随后管道将冻结，除非我们使xvimagesink前面的队列 [19] 元素泄漏，即“队列泄漏=1”。这对我不起作用，所以我会坚持使用
ffenc_mpeg4。An old message, but the problem is still not fixed. Somewhere between
9.10and11.10(I upgraded a few before noticing). I got around it by avoiding thex264encand usedffenc_mpeg4instead.I just noticed this note from Gstreamer Cheat Sheet :
Note: We can replace
theoraenc+oggmuxwithx264enc+someothermuxerbut then the pipeline will freeze unless we make the queue [19] element in front of thexvimagesinkleaky, i.e."queue leaky=1".Which doesn't work for me so I'll stick with
ffenc_mpeg4.