QtGstreamer：AppSink＆tee

Question

我寫了一個自定義的QtGStreamer appsink工作正常。 我遇到了麻煩，試圖用流水線分割流水線來處理流的記錄，因爲流水線開始預先滾動，但從未進入播放狀態。

我的管道：

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

是應用程序阻止？

我懷疑（我可能是錯的），該appsink被阻止，因爲它是由多個緩衝區涌了進來。發球是非常棘手的元素。如果開球后一個分支想預卷例如，然後100個緩衝區它導致100個緩衝區也會轉到另一個分支，這可能會阻止例如在您等待播放狀態時阻止整個管道的appsink（或者我不知道您在您的應用邏輯中正在做什麼）。

您可能會嘗試一些事情得到這個整理出來：

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