QtGstreamer: AppSink & tee

Question

我已经编写了一个自定义的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只是一个人工作呢？

Answer 1

太大了，评论不了。

如何处理app接收器缓冲区？它在主线程中，您是通过阻塞调用获得缓冲区，还是在等待新的示例/新的预录制信号(这是一种非阻塞的推送方式)？

检查一下我的意思(app接收器一章)：

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

你的申请被阻止了吗？

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

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

1. 将drop=true添加到应用程序接收器
2. 尝试添加队列参数leaky=2来测试它是否有用(非常类似于1，只是不同的技术)。
3. 分析调试日志中哪个队列首先被阻塞。在运行GST_DEBUG=3,queue_dataflow:5时使用这个env变量(我认为它是5，我希望我正确地记住了调试类别)
4. 试着改变不应该阻塞的fakesink的分裂库--只是为了测试谁是罪魁祸首。如果有帮助的话，这也意味着拆分库是请求这么多缓冲区的那个。
5. 在任何情况下，如果我都错了，您可以使用GST_DEBUG进行调试并设置级别3、4、5，直到您发现一些有趣的东西。