QtGstreamer：AppSink＆tee

Question

我寫了一個定制的QtGStreamer appsink，工作正常。 我很難嘗試使用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"

如果我評論兩個三通分支中的任何一個，任何工作都按預期工作。

這也有效：

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

評論太大了......

你如何處理appsink緩沖區？ 它在主線程中，您通過阻止調用獲取緩沖區，或者您正在等待新樣本/新預卷信號（非阻塞 - 推送樣式）？

檢查一下我的意思（appsink章節）：

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

您的申請被封鎖了嗎？

我懷疑（我可能是錯的）應用程序被阻止，因為它被許多緩沖區淹沒..發球台是非常棘手的元素..如果一個分支在發球台后想要預先輸入例如100個緩沖區然后它導致100個緩沖區去另一個分支也可以阻止例如在你等待播放狀態時阻止整個管道的appink（或者我不知道你在app邏輯中做了什么）。

您可以嘗試一些事情來解決這個問題：

1. 將drop=true添加到appsink
2. 嘗試添加隊列參數leaky=2來測試它是否有幫助（非常類似於1，只是不同的技術）
3. 分析首先阻止哪個隊列的調試日志。 運行你的東西時使用這個env變量GST_DEBUG=3,queue_dataflow:5 （我認為它是5，我希望我能正確記住調試類別）
4. 嘗試更改splitmuxsink for fakesink，它永遠不會阻止 - 只是為了測試誰是罪魁禍首..如果它有幫助它也意味着splitmuxsink是請求這么多緩沖區的那個。
5. 在任何情況下如果我都錯了你可以使用GST_DEBUG進行調試並設置3,4,5級，直到你找到一些有趣的東西..