1

我已经编写了一个自定义的 QtGStreamer 应用程序，它工作正常。我在尝试使用 tee 拆分管道以处理流记录时遇到了麻烦，因为管道开始预滚动但从未进入播放状态。

我的管道：

souphttpsrc location="%1" ! queue ! tee name=tp tp.! queue ! tsdemux ! h264parse ! splitmuxsink muxer=mpegtsmux location=/tmp/rec/video%02d.mov max-size-time=60000000000 max-size-bytes=100000000 tp.! queue ! appsink name="mysink"

如果我评论两个 tee 分支中的任何一个，任何事情都会按预期工作。

这也有效：

souphttpsrc location="%1" ! queue ! tee name=tp tp.! queue ! tsdemux ! h264parse ! splitmuxsink muxer=mpegtsmux location=/tmp/rec/video%02d.mov max-size-time=60000000000 max-size-bytes=100000000 tp.! queue ! decodebin ! autovideosink

为什么我的 AppSink 只能单独工作？

4

1 回答 1

0

评论太大了。。

你如何处理应用程序缓冲区？它在主线程中，您是通过阻塞调用来获取缓冲区，还是在等待新样本/新预滚动信号（它们是非阻塞的 - 某种推送风格）？

检查我的意思（appsink章节）：

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-data-spoof.html

您的应用程序被阻止了吗？

我怀疑（我可能是错的）appsink 被阻塞了，因为它被许多缓冲区淹没了.. tee 是非常棘手的元素.. 如果 tee 之后的一个分支想要预滚动例如 100 个缓冲区，那么它会导致 100 个缓冲区转到另一个分支也可能会阻塞，例如在您等待播放状态时会阻塞整个管道的 appsink（或者我不知道您在应用程序逻辑中在做什么）..

你可以尝试一些事情来解决这个问题：

  1. 添加drop=true到应用程序接收器
  2. 尝试添加队列参数leaky=2以测试它是否有帮助（与 1 非常相似，只是技术不同）
  3. 分析哪个队列首先被阻塞的调试日志。在运行你的东西时使用这个环境变量GST_DEBUG=3,queue_dataflow:5（我认为它是 5，我希望我能正确记住调试类别）
  4. 尝试将 splitmuxsink 更改为不应该阻塞的 fakesink - 只是为了测试谁是罪魁祸首。如果它有帮助，也可能意味着 splitmuxsink 是请求这么多缓冲区的那个。
  5. 无论如何，如果我错了，您可以使用 GST_DEBUG 进行调试并设置级别 3、4、5，直到您发现有趣的东西。
于 2016-07-15T07:30:10.020 回答