Override checkmediatype with care

A problem I encountered while developing my source filter's output pin is that inside fillbuffer method, the media type and size of the media sample is not exactly the same as the one I proposed in getmediatype method. the strange thing is my pin has successfully negotiated with downstream Renderer Filter (its actual type is video mixing Renderer-9 filter), and its input pin has agreed to use the m EDIA type my filter proposed. So why the actual media type being used changes?

The answer lies in this document, handling format changes from the video Renderer:

Video mixing Renderer Filter
The video mixing Renderer Filter (VMR-7 and VMR-9) will connect with any format that is supported by the graphics hardware on the system. the VMR-7 always uses DirectDraw for rendering, and allocates the underlying DirectDraw surfaces when the upstream filter connects. the VMR-9 always uses direct3d for rendering, and allocates the underlying direct3d surfaces when the upstream filter connects.
the graphics hardware may require a larger surface stride than the image width. in that case, the vmr requests a new format by calling queryaccept . it reports the surface stride in the biwidth Member of the bitmapinfoheader in the video format. if the upstream filter does not return s_ OK from queryaccept , the vmr rejects the format and tries to connect using the next format advertised by the upstream filter. the vmr attaches the media type with the new format to the first media sample. after the first sample, the format remains constant; The vmr will not switch formats while the graph is running.

During the connecting phase, after both filters 'pins have agreed on a media type, they perform Allocator negotiation. and the downstream pin proposed a larger biwidth during Allocator negotiation. as a result to the new proposal, our pin's queryaccept method is called. if we don't override it, the default Implementation of Grandpa class cbasepin comes into play. cbasepin: queryaccept internally callcheckmediatype method to see if the newly proposed media type can be accepted. because our pin's checkmediatype method's original implementation is too sloppy without examining all fields of the new media type, so we ended in the situation I described at the beginning of the post.

So, the best practice for creating a source filter is we needHandle checkmediatype carefully. Or we can take the alternative way of overriding the queryaccept method to handle media type change explicitly.

references:
How to Write a Source Filter for DirectShow
core media technology in Windows XP empowers you to create custom audio/video processing components