Force the graph builder to always use my sample grabber
Odie
for my application to work. But I don't know how to add it properly since
the graph builder doesn't need it to complete the graph.
So how do I make sure my filter is always added to the graph properly?
The technical bits:
I have a sample grabber as a transform filter that I wrote which can handle
YUY2, RGB32, and a few more video formats. It does no tranformation. It can
only copy data over in the same format it came in as. And I'm not
registering this filter on the system with regsvr32. I just keep it internal
in my application and add it to the graph builder. Then I connect my source
filter to my sample grabber and then my sample grabber to my VMR9.
Problem is that when I do this, sometimes the graph builder successfully
connects a video decoder's output pin to my sample grabber's input pin and
then when I try to connect my sample grabber's output pin to the VMR9, it
doesn't know how to use the input format that was already negotiated. So say
it negotiates YUY2. But the VMR9 only supports RGB32. And the graph builder
doesn't seem to know how to disconnect my filter and try again with RGB32.
Chris P.
> Problem is that when I do this, sometimes the graph builder successfully
> connects a video decoder's output pin to my sample grabber's input pin and
> then when I try to connect my sample grabber's output pin to the VMR9, it
> doesn't know how to use the input format that was already negotiated. So say
> it negotiates YUY2. But the VMR9 only supports RGB32. And the graph builder
> doesn't seem to know how to disconnect my filter and try again with RGB32.
Typically you would implement this kind of filter as Trans-In-Place so that
media type negotiation happens somewhat transparently through your filter.
The trans-in-place model should allow the reconnection to happen
automatically. You can probably make this happen with your filter by
stealing some of the code from the CTransInPlaceFilter base classes where
it passes IPin::EnumMediaTypes() upstream to the connected pin and forcing
a reconnection of that pin when necessary. Probably just easier to start
over as an In-place filter.
--
http://www.chrisnet.net/code.htm
[MS MVP for DirectShow / MediaFoundation]
Odie
news:12jzx1j8eyjf$.12ddug7nn5csx$.dlg@40tude.net...
> Typically you would implement this kind of filter as Trans-In-Place so
> that
Thanks Chris. But I've tried getting the trans-in-place filter working over
and over again. But I could never get it down. I could get it working, but
then I had issues with speed from reading from video memory sinces the
trans-in-place filter typically uses a buffer from the video card. So then
you have to write your own allocator.. etc etc. And I just never could get
it working or find any working source code using a trans-in-place filter in
this manor. So I wrote a transform filter which works perfectly expect in
some situations where the VMR9 doesn't support certain video formats.
So if you knew of any examples of a trans-in-place filter working with its
own allocator, then I'd be happy to try that. Thanks.
Alessandro Angeli
> Thanks Chris. But I've tried getting the trans-in-place
> filter working over and over again. But I could never get
> it down. I could get it working, but then I had issues
> with speed from reading from video memory sinces the
> trans-in-place filter typically uses a buffer from the
Simple solution: connect the decoder to the renderer, copy
the connection media type, disconnect both of them,
reconnect with your filtern in between, so that your filter
on accepts the copied media type as input.
Harder solution: every time your input's CheckMediaType() is
called, call IPin::QueryAccept() or
IPinConnection::DynamicQueryAccept() on the renderer's input
pin (the renderer must be in the graph, but does not need to
be connected). When, afterwards, you will connect your
output to the renderer, the renderer will call
IPin::QueryAccept() on your output pin to tell you the
correct stride. You will need to take that into account when
copying the buffer (that is, if the stride is larger than
the width, copy 1 scanline at a time instead of the whole
raster). Or you can call QueryAccept() on your upstream pin,
so that the decoder will take care of the stride. Or you can
force a reconnection of your input pin by sendind an
EC_DISPLAY_CHANGED event to the graph.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
Odie
renderer.