我在使用GStreamer中的实时源（网络摄像头）和pseuso-live源（screencaptures）编写的文件时遇到问题。生成的文件没有时间长度，因此不会在Media Player Classic中播放。它们可以在Firefox中播放，但没有时间长度，有时速度也会提高。
我使用的是什么（伪）实时源，也不管编解码器或容器是什么似乎都不重要。故事总是一样的;没有设定时间长度的不正确的媒体文件。
然而，当我添加选项＆＃34; num-buffers = 100＆＃34;对于dx9screencapsrc，src元素在该数量的缓冲区之后发送EOS事件，然后文件在MPC和Firefox中正确呈现。所以EOS事件似乎做了一些事情，以便文件正确关闭。
我已经尝试了停止管道的常用方法（通过setState（...））。试图手动向所有元素发送EOS事件，监听总线上的EOS事件，然后退出管道。一切都无济于事，文件仍然存在腐败。
我的问题是，如何在使用（伪）实时源并生成正确的文件时停止管道（即在这种情况下，具有正确的时间长度）。
我在Java 6和Windows 8上使用gstreamer-java和GStreamer 0.10。 以下面的管道为例：
dx9screencapsrc ! video/x-raw-rgb,framerate=15/1 ! ffmpegcolorspace ! vp8enc ! webmmux ! filesink location=%s
此时，我对如何解决这个问题感到茫然。非常感谢任何帮助！
固定 事实证明，我必须将EOS事件仅发送到src元素，而不是发送给管道中的每个元素。
答案 0 :(得分：0)
正确的方法是将EOS事件发送到管道并等到你将其作为总线上的GstMessage获取。
如果你说你已经尝试了它并且它不起作用，它可能是涉及的元素（不太可能），java绑定或代码中的错误。
为了排除相关元素中的错误，我建议您尝试：
gst-launch-0.10 -e dx9screencapsrc ! video/x-raw-rgb,framerate=15/1 ! ffmpegcolorspace ! vp8enc ! webmmux ! filesink location=%s
-e标志将启用eos-on-shutdown，这意味着一旦你中断进程，它将发送EOS并在总线上等待它（就像你的应用程序应该做的那样）。如果可行，我建议您查看代码。
重要的是要注意您使用的是gstreamer 0.10，现在已经过时3年并且没有使用。强烈建议您转到1.x系列。