[SOLVED] Unexpected behavior when DMOs are inserted to the graph as Filters

Unexpected behavior when DMOs are inserted to the graph as Filters

im trying to insert a certain DMO into my DirectShow Graph. i've wrapped this DMO using the appropriate interfaces:

ATL::CComPtr< IBaseFilter >         spDMOWrapper;
ATL::CComPtr< IDMOWrapperFilter >   spDMOWrapperEx;

if(FAILED(hr = spDMOWrapper.CoCreateInstance(CLSID_DMOWrapperFilter)))
    return hr;
if(FAILED(hr = spDMOWrapper.QueryInterface(&spDMOWrapperEx)))
    return hr;

IDMOWrapperFilter->Init(SomeDMO)

connecting pins and so on

if(FAILED(hr = pGraph->AddFilter(spDMOWrapper, L"WM DMO Video Encoder")))
        return hr;

the following problem occurs randomly on the same input,

qasf.dll!CMediaWrapperFilter::NewSample() re-initializes my sample's timestamps by using the "Flush" function implemented in my DMO.

I'm not sure what's excatly going on, but there aren't any gaps as far as i can say and on short clips, the DMO works just fine. if you guys want to examine the callstack:

    DMO::Compression::Mainconcept::H264Encoder::Flush()  Line 1165  C++
    qasf.dll!CMediaWrapperFilter::NewSample()  + 0x48 bytes 
    qasf.dll!CWrapperInputPin::Receive()  + 0x16 bytes  
    Filters::Helpers::CPipeOutT<Filters::Helpers::CGenericPipe>::Deliver(IMediaSample * pSample)  Line 383 + 0x20 bytes C++
    Filters::Helpers::CPipeInT<Filters::Helpers::CGenericPipe,Filters::Helpers::CGenericInputPin>::Receive(IMediaSample * pSample)  Line 178 + 0x23 bytes   C++
    CBaseOutputPin::Deliver(IMediaSample * pSample)  Line 2695 + 0x20 bytes C++

In addition to solving this problem, im more interested in the reasons that make the CMediaWrapperFilter think he needs to zero the sample's timestamps.

Thanks for your help!

Solution

This is the behavior of DMO Wrapper Filter. If at the time of streaming it sees that underlying DMO produces no more output, and yet does not accept new input, the filter flushes the DMO and indicates streaming error.