我已经编写了一个自定义的QtGStreamer appsink，它工作正常。我尝试用 T 形管拆分以处理流的录制时遇到麻烦，因为管道开始预卷但从未进入播放状态。
我的管道：
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 只能单独工作？
太大
而无法评论。
您如何处理 appsink 缓冲区？它在主线程中，您通过阻塞调用来获取缓冲区，或者您是否正在等待新样本/新预卷信号（这是非阻塞 - 一种推送样式）？
检查一下我的意思（appsink 章节）：
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-data-spoof.html
您的应用程序是否被阻止？
我怀疑（我可能是错的）appsink被阻止了，因为它被许多缓冲区淹没了.. 发球台是非常棘手的元素.. 如果 Tee 之后的一个分支想要预卷，例如 100 个缓冲区，那么它会导致 100 个缓冲区也转到另一个分支，这可能会阻止例如 appsink，它会在您等待播放状态时阻止整个管道（或者我不知道你在做什么您的应用逻辑）..
您可以尝试一些方法来解决此问题：
- 将
drop=true添加到应用程序... - 尝试添加队列参数
leaky=2以测试它是否有帮助（与 1 非常相似，只是技术不同） - 分析调试日志，因为哪个队列首先被阻止。在运行你的东西时使用此 env 变量
GST_DEBUG=3,queue_dataflow:5（我认为它是 5，我希望我正确记住了这个的调试类别） - 尝试将 splitmuxsink 更改为不应该阻塞的假接收器 - 只是为了测试谁是罪魁祸首......如果它有帮助，它也可能意味着 splitmuxsink 是请求如此多缓冲区的那个。
- 无论如何，如果我全错了，您可以使用GST_DEBUG进行调试并设置级别 3、4、5，直到您找到有趣的东西。