What Formats supported by the Video Renderer filter.
john
I have written a colorspace converter filter for YUV to RGB
conversion.
In my case the source filter output format is always I420. I observed
that on some system the source filter is being connected directly to
Video renderer without any intermediate filters i.e. avi decompressor
or colorspace converter. That's mean the colorspace conversion is not
required on those systems.
I would like know how we can determine whether the color space
conversion is required on a particular system or not before creating
the filter graph So that I can use my own colorspace converter filter
whenever the color space conversion is required.
Can we determine the display format supported by the video render
filter?
Please anyone can give some suggestion.
Thanks.
Alessandro Angeli
[...]
> Can we determine the display format supported by the
> video render filter?
The stock video renderers do not support any format at all.
They simply ask the video driver through
DirectDraw/Direct3D. So the set of available formats depends
on the specific video driver's capabilities.
During pin connection, the format is dynamically negotiated.
Instead of writing a separate color space converter, you
could support the conversion internally so that you can
simply offer RGB alongside I420 and, if that is the selected
format after the connection is complete, perform the
conversion.
If you want to keep the converter as a separate filter, you
can implement IStreamBuilder on your output pin so that the
pin can insert the converter after itself if it fails to
connect to the renderer.
If you are writing the application, before you connect the
pins, you can also call IPin::EnumMediaTypes() on the
renderer's input pin to discover what it supported and
insert your converter if needed.
Or you can add you converter to the graph and connect the
source to the renderer, so that IntelligentConnect will
automatically use the converter if needed. Afterwards, if
the converter is not connected, you can simply remove it
from the graph.
Just a note, I420/IYUV is not commonly supported, but YV12
is exactly the same with reversed U and V planes.
To connect to the renderer, you should also take care of
respecting the stride asked for by the renderer during pin
connection. If you don't, the system will have to insert the
MSYUV codec (wrapped by the AVIDecompressor, for some YUV
formats) and/or a ColorSpaceConverer (for RGB formats) to
adapt the stride.
- How media type negotiation works during pin connection:
http://msdn.microsoft.com/en-us/library/dd390925.aspx
http://msdn.microsoft.com/en-us/library/dd377635.aspx
- How to respect the video renderer's requested stride:
http://msdn.microsoft.com/en-us/library/dd388901.aspx
http://msdn.microsoft.com/en-us/library/dd377489.aspx
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
john
wrote:
> From: "john"
>
> [...]
>
> > Can we determine the display format supported by the
> > video render filter?
Thank you for your suggestions.
> The stock video renderers do not support any format at all.
> They simply ask the video driver through
> DirectDraw/Direct3D. So the set of available formats depends
> on the specific video driver's capabilities.
>
> During pin connection, the format is dynamically negotiated.
> Instead of writing a separate color space converter, you
> could support the conversion internally so that you can
> simply offer RGB alongside I420 and, if that is the selected
> format after the connection is complete, perform the
> conversion.
>
> If you want to keep the converter as a separate filter, you
> can implement IStreamBuilder on your output pin so that the
> pin can insert the converter after itself if it fails to
> connect to the renderer.
>
> If you are writing the application, before you connect the
> pins, you can also call IPin::EnumMediaTypes() on the
> renderer's input pin to discover what it supported and
> insert your converter if needed.
I have tried with the IPin::EnumMediaTypes() on the renderer's input
pin
But The IEnumMediaTypes::Next() function is returing S_FALSE. Please
Can you tell me the reason. It look like that we can't enumerate the
media types
on video renderer's input pin.
>
> Or you can add you converter to the graph and connect the
> source to the renderer, so that IntelligentConnect will
> automatically use the converter if needed. Afterwards, if
> the converter is not connected, you can simply remove it
> from the graph.
>
> Just a note, I420/IYUV is not commonly supported, but YV12
> is exactly the same with reversed U and V planes.
But I have observed on some system that the YUY2 is supported by the
VMR7 ans VMR9.
> To connect to the renderer, you should also take care of
> respecting the stride asked for by the renderer during pin
> connection. If you don't, the system will have to insert the
> MSYUV codec (wrapped by the AVIDecompressor, for some YUV
> formats) and/or a ColorSpaceConverer (for RGB formats) to
> adapt the stride.
>
> - How media type negotiation works during pin connection:http://msdn.microsoft.com/en-us/library/dd390925.aspxhttp://msdn.microsoft.com/en-us/library/dd377635.aspx
>
> - How to respect the video renderer's requested stride:http://msdn.microsoft.com/en-us/library/dd388901.aspxhttp://msdn.microsoft.com/en-us/library/dd377489.aspx
john
>
> > - How to respect the video renderer's requested stride:http://msdn.microsoft.com/en-us/library/dd388901.aspxhttp://msdn.micr...
>
> > --
> > // Alessandro Angeli
> > // MVP :: DirectShow / MediaFoundation
> > // mvpnews at riseoftheants dot com
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
How we can enumerate the formats supported by the graphics hardware.
Is there any APIs for this task?
Is it possible that the graphics hardware doesn't support the RGB
format?
As per my requirement, First I need to enumerate the formats supported
by the graphics hardware So that we can use
any supported format for direct connection between source filter and
video mixing renderer and convert the original video stream(i.e. I420)
into that supported format.
Thanks.
Alessandro Angeli
> I have tried with the IPin::EnumMediaTypes() on the
> renderer's input pin
> But The IEnumMediaTypes::Next() function is returing
> S_FALSE. Please
Sorry, I forgot that the stock video renderers do not
advertise the formats supported by the h/w but wait for the
upstream pin to try its own preferred formats.
>> Just a note, I420/IYUV is not commonly supported, but
>> YV12
>> is exactly the same with reversed U and V planes.
>
> But I have observed on some system that the YUY2 is
> supported by the VMR7 ans VMR9.
But YUY2 is a packed format with a memory layout very
different from I420/IYUV/YV12, which instead all have the
same planar layout (with YV12 having the U and V planes
reversed). If you want support YUY2, you can of course, but
it will require some work, while supporting YV12 when you
already support I420/IYUV only requires a pointer swap (or 2
block memcpy()s).
> How we can enumerate the formats supported by the
> graphics hardware.
> Is there any APIs for this task?
The OVR and OM use DirectDraw5.
The VMR7 uses DirectDraw7.
The VMR9 and EVR use Direct3D9.
But what good is that going to do? If the h/w does not
support any of the formats you propose, them you won't be
able to connect anyway, so you can just let
IntelligentConnect discover how to connect the pins by
itself.
> Is it possible that the graphics hardware doesn't support
> the RGB format?
It's not possible, since GDI and the desktop use RGB.
However, most modern GFX cards seem to only support RGB16
and xRGB32 and not RGB24.
> As per my requirement, First I need to enumerate the
> formats supported
> by the graphics hardware So that we can use
> any supported format for direct connection between source
> filter and
> video mixing renderer and convert the original video
> stream(i.e. I420)
> into that supported format.
There is no need to do any of that:
1. let you pin advertise all the formats it can convert
into, in order of preference
2. the pins will agree on a common format if it exist, or IC
will insert the necessary converters
3. when the connection is done, you will know what format
was selected and what to convert into
As I said, if you want to connect directly to the renderer,
supporting a format also supported by the h/w is not enough:
you *must* accept the stride changes. Tim also told you
that.
Read the docs I pointed you to and do what they say,
otherwise you are wasting everybody's time.