Search code examples
directshow

Is it normal for a filter to receive BeginFlush and EndFlush in a graph which is not being seeked?


I'm working on a custom multiplexing filter that doesn't support seeking - because it's not designed to and doesn't need to.

When I connect it downstream of the Main Concept / Rovi MP4 demultiplexer and Main Concept broadcast MP4/AVC decoder my filter receives calls to BeginFlush, EndFlush, NewSegment just after IBaseFilter::Pause is called but before the first sample is delivered. SetPositions is not called. I've narrowed down the BeginFlush to the mp4 demux filter.

Is this correct DirectShow behaviour? I understand the role that BeginFlush/EndFlush play in seeking but is it safe or allowable to call them at the start of streaming? I don't see much reference to BeginFlush/EndFlush in the Microsoft documentation outside the context of seeking operations. The call to BeginFlush is clearly happening during the call to IMediaControl::Run (see call stack below) rather than as a result of the host program seeking the graph by calling SetPositions (or similar).

Is it a reasonable filter workaround to discard BeginFlush/EndFlush requests that arrive before the first sample? Presumably there are many filters out there that don't support seeking and therefore don't support BeginFlush/EndFlush well.

 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    

Solution

  • Perhaps "correct" is not the right word here, is it a legal behavior? I think it is. Demultiplexer flushes before it starts streaming, why not. It could so happen it is specific to how they handle seeking, that is they flush before sending from clean point and they do it even on initial sending.

    Flushing is not a part of seeking capability only. It is rather a core feature a filter should support and implement, so why would not you just flush when you receive the request? Or simply ignore when you have nothing to flush? I would say that if it creates a sort of a problem then maybe multiplexer does something else in a wrong way because flushing request is not something that looks breaking. I suppose it is even legal to get it in the middle of streaming, let us say if a source or decoder for whatever reason decides to withdraw data in transit downstream.