過濾器在未搜索的圖形中接收BeginFlush和EndFlush是否正常？

我正在開發一種不支持查找的自定義多路複用篩選器 - 因爲它不是設計用於並不需要。過濾器在未搜索的圖形中接收BeginFlush和EndFlush是否正常？

當我將它連接到Main Concept/Rovi MP4解複用器和主概念廣播MP4/AVC解碼器的下游時，我的過濾器在調用IBaseFilter :: Pause之後但在第一個示例交付之前接收到對BeginFlush，EndFlush，NewSegment的調用。 SetPositions不被調用。我已經縮小了BeginFlush到mp4 demux過濾器的範圍。

這是正確的DirectShow行爲？我瞭解BeginFlush/EndFlush在搜索中扮演的角色，但在流式傳輸開始時是否安全或允許調用它們？在尋找操作的上下文之外，我沒有在Microsoft文檔中看到很多關於BeginFlush/EndFlush的參考。在調用IMediaControl :: Run（參見下面的調用堆棧）期間，調用BeginFlush顯然是發生的，而不是主機程序通過調用SetPositions（或類似的）尋找圖形的結果。

是否合理的過濾解決方法是放棄在第一個示例之前到達的BeginFlush/EndFlush請求？據推測，有很多過濾器不支持查找，因此不支持BeginFlush/EndFlush。

quartz.dll!CFilterGraph::Pause() + 0x109 bytes  
quartz.dll!CFGControl::Cue() + 0x1b bytes  
quartz.dll!CFGControl::CueThenRun() + 0x12 bytes  
quartz.dll!CFGControl::CImplMediaControl::StepRun() + 0x59 bytes  
quartz.dll!CFGControl::CImplMediaControl::Run() + 0x2d bytes

來源

2014-10-27 persiflage

也許「正確」在這裏不是正確的詞，它是一種合法的行爲嗎？我覺得是這樣的。解複用器在開始流式傳輸之前刷新，爲什麼不呢。它可能發生，具體到他們如何處理尋求，即他們在從清潔點發送之前刷新，甚至在最初發送時也是如此。

法拉盛不只是尋求能力的一部分。這是一個過濾器應該支持和實施的核心功能，那麼爲什麼不在收到請求時刷新呢？或者乾脆不理會什麼時候你什麼都不需要衝洗我會說，如果它產生了一種問題，那麼多路複用器可能會以一種錯誤的方式做其他事情，因爲刷新請求並不是看起來突破的。我認爲在流式傳輸中獲得它甚至是合法的，讓我們假設一個源或解碼器是否因任何原因決定在下游傳輸數據。

來源

2014-10-31 07:01:35

刷新基於文件的複用器會使其處於未知狀態。是否應該清除所有準備好並等待寫入磁盤的數據，是否應該清除所有未準備好寫入磁盤的排隊數據，因爲它正在等待更多幀？在我看來，它能做的唯一確定性事情就是不會刷新任何日期，只是在任何情況下忽略刷新。或者，它可以關閉文件 – persiflage 2014-11-24 18:37:29

過濾器上的刷新方法假定調用方以某種方式處理外部同步。並分成正在/結束，以便多個流可以同步（全部開始，然後全部結束）。最終確保狀態穩定是一個同花順的調用者。一個典型的沖洗器本身就是解複用器：在尋找時（在你的情況下初始化數據流），它確保管道在其下游的任何地方都是空的。 – 2014-11-25 10:13:31

然後關於寫入磁盤 - 刷新更多的是丟棄在這裏，而不是強迫處理完成。當然，BeginFlush接收器決定自己做什麼，但調用的本質是確保流水線是空的，而不考慮如何處理未決數據。相反，請求完成處理是'EndOfStream'。 – 2014-11-25 10:16:37

過濾器在未搜索的圖形中接收BeginFlush和EndFlush是否正常？

回答

相關問題