我有一个C程序，它将来自v4l2源的视频和音频录制成flv格式。我注意到该程序不适用于较新版本的ubuntu。我决定尝试在gst-launch中运行problamatic管道，并尝试找到可以重现问题的最简单的管道。只关注视频方面，我已将其缩小为您在下面看到的内容。
所以我有一个正在运行的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.
任何人都可以解释这里发生了什么吗？我做错了什么？
答案 0 :(得分：1)
您声称第一个管道停止工作但您没有解释发生了什么。事情因为其他改变而停止工作： - GStreamer和子模块的版本？ - 操作系统版本？ - 相机版本？
不需要连续添加一堆队列。在实践中，他们将创建线程边界并在跨线程之前和之后分离部分，并且它将添加您看到的延迟，这将影响延迟和同步。
答案 1 :(得分：0)
旧消息，但问题仍然没有解决。介于9.10和11.10之间（我在注意之前升级了一些）。我避开了x264enc并使用了ffenc_mpeg4来解决这个问题。
我刚从Gstreamer Cheat Sheet注意到这个说明：
注意：我们可以用theoraenc+oggmux替换x264enc+someothermuxer，但是除非我们在xvimagesink泄漏前面建立队列[19]元素，否则管道将冻结，即{{1} }。
这对我不起作用，所以我会坚持使用"queue leaky=1"。