MSYUV Color Space Converter Codec
NickP
Does anyone know how I can use this codec in a filter graph? I would
like to convert a YUV2 stream to RGB24 manually.
If I cannot use the MSYUV Color Space Converter Codec, is there any
other way to do this?
My impression so far is that I will need to make a new transform filter.
Thanks a million in advance.
Nick.
Alessandro Angeli
> Does anyone know how I can use this codec in a filter
> graph?
It's a VCM codec so you use it the usual way, that is
wrapped by the AVIDecompressor.
I would like to convert a YUV2 stream to RGB24
> manually.
> If I cannot use the MSYUV Color Space Converter Codec,
> is there any other way to do this?
The MSYUV codec does not support every possible YUV subtype.
Among the non-supported subtypes, the very common YV12. I
haven't tried YUV2.
> My impression so far is that I will need to make a new
> transform filter.
You can make a filter, a DMO or a VCM codec. A transform
filter is IMHO by far the easiest thanks to CTransformFilter
base class.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
NickP
> The MSYUV codec does not support every possible YUV subtype. Among the
> non-supported subtypes, the very common YV12. I haven't tried YUV2.
Oh dear :-( I've got to cover every eventuality really so I guess it's
going to have to be something custom.
> You can make a filter, a DMO or a VCM codec. A transform filter is IMHO by
> far the easiest thanks to CTransformFilter base class.
Cool, thanks for the information, I think this is what I am going to
have to do as at the moment this is proving to be a bit of a nightmare!
Thanks a million for your help.
Nick.
Thore B. Karlsen [DShow MVP]
<nob...@nowhere.in.the.net> wrote:
> I would like to convert a YUV2 stream to RGB24
>> manually.
>> If I cannot use the MSYUV Color Space Converter Codec,
>> is there any other way to do this?
>The MSYUV codec does not support every possible YUV subtype.
>Among the non-supported subtypes, the very common YV12. I
>haven't tried YUV2.
It supports YUY2, but that's the only YUV subtype I've tried it with.
:)
--
Be seeing you.
Thore B. Karlsen [DShow MVP]
>> The MSYUV codec does not support every possible YUV subtype. Among the
>> non-supported subtypes, the very common YV12. I haven't tried YUV2.
> Oh dear :-( I've got to cover every eventuality really so I guess it's
>going to have to be something custom.
You may also look at Geraint's YUVXfm filter, found here:
http://www.gdcl.co.uk/downloads.htm
Perhaps Geraint could elaborate on the YUV formats that are supported.
If you want to do a custom filter yourself, you could look into using
the Intel Performance Primitives (IPP) library which has a lot of
optimized conversion routines.
--
Be seeing you.
Geraint Davies
<s...@6581.com> wrote:
>You may also look at Geraint's YUVXfm filter, found here:
>
>http://www.gdcl.co.uk/downloads.htm
>
>Perhaps Geraint could elaborate on the YUV formats that are supported.
as far as I remember, it supports YUY2, UYVY, Y41P, YV12, i420, YVU9,
IYUV, 8-bit and 16-bit monochrome and a bunch of RGB formats.
To force a particular conversion, you can use an in-place transform
(placed downstream of the converter) that only accepts a specific
format but does nothing else.
G
Tim Roberts
>
>> The MSYUV codec does not support every possible YUV subtype. Among the
>> non-supported subtypes, the very common YV12. I haven't tried YUV2.
>
> Oh dear :-( I've got to cover every eventuality really so I guess it's
>going to have to be something custom.
No, you don't. I mean, get real. Many manufacturers make up custom
fourccs for their own peculiar format. The KEY is that you support the
COMMON cases. Filters that produce odd formats will supply their own
translation filters that will be inserted in the middle by DirectShow.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Alessandro Angeli
> No, you don't. I mean, get real. Many manufacturers
> make up custom fourccs for their own peculiar format.
> The KEY is that you support the COMMON cases. Filters
> that produce odd formats will supply their own
> translation filters that will be inserted in the middle
> by DirectShow.
Unfortunately at least the very common case of YV12, which
is often the preferred output of MPEG/WMV decoders, can not
be handled by either the CSC or MSYUV on Win32/Win64, which
means that either it goes straight to a video renderer that
uses hardware acceleration on a video card that supports
YV12 (quite common) or you need custom code to handle this
subtype.
NickP
> No, you don't. I mean, get real. Many manufacturers make up custom
> fourccs for their own peculiar format. The KEY is that you support the
> COMMON cases. Filters that produce odd formats will supply their own
> translation filters that will be inserted in the middle by DirectShow.
Firstly you might want to learn how to talk to people on a newsgroup,
telling me to get real is hardly lightly to make me see you with enough
respect as to want to read what you have to say.
Firstly my use case
1. My filter graph is automatically created.
2. I have to position a sample grabber into the rendered filter graph.
The only way I have found that this will have any chance of working is
to place it near the end, before being rendered. Unfortunately I found that
on some machines the same video was being rendered using different codecs,
which resulted in a different colour space being passed to the final
renderer. Your advice on using the standard color space converter is just
complete garbage as you obviously can't read the documentation before
shouting your head off and telling people to get real. It only accepts RGB,
and only converts to RGB. You might want to have a read for yourself,
http://msdn2.microsoft.com/en-us/library/ms781972.aspx
So yes, I still stand by this, the only way I can do this effectively
and efficiently enough is to have a custom filter.
Thanks, is that real enough for you?
Nick.
NickP
That certainly looks like the sort of thing that I am after using,
unfortunately, we cannot have external dependencies (non xp base standard)
to the application so that rules out your filter.
Not to worry though as we have a soloution for the problem, we are going
to develop a renderer fit for the purpose.
Thanks for your time and help, same goes to everyone who has helped if I
haven't thanked them already.
Nick.
"Geraint Davies" <gera...@gdcl.co.uk> wrote in message
news:6jdc835b5vvpob5s2...@4ax.com...
Alessandro Angeli
> That certainly looks like the sort of thing that I am
> after using, unfortunately, we cannot have external
> dependencies (non xp base standard) to the application so
> that rules out your filter.
A custom filter does not need to be external to your
application. It needs to be packaged in a DLL only if you
want to register it so that it participates in
IntelligentConnect, otherwise it can just be an internal
co-class you manually insert into the graph.
Jeremy Noring
wrote:
> If you want to do a custom filter yourself, you could look into using
> the Intel Performance Primitives (IPP) library which has a lot of
> optimized conversion routines.
FWIW, I do this in a filter I wrote. The input to the filter is
always YV12, but using the IPP and some other code I wrote, it can
output YV12, YUY2, RGB565, and RGB32. I could support more types,
but...no point. I have yet to find a renderer that doesn't support at
least one of those types.
NickP
> A custom filter does not need to be external to your application. It needs
> to be packaged in a DLL only if you want to register it so that it
> participates in IntelligentConnect, otherwise it can just be an internal
> co-class you manually insert into the graph.
Yes of course, but Geraint has a DLL for download.
Nick.
Alessandro Angeli
> Yes of course, but Geraint has a DLL for download.
Sorry, he usually provides the source code so I hadn't
noticed. Anyway, even if you only have a DLL you still don't
need to register anything to use it if you don't want to and
you do not even have to ship it as a separate file as long
as your application can write somewhere on disk.
Thore B. Karlsen [DShow MVP]
<nob...@nowhere.in.the.net> wrote:
>> Yes of course, but Geraint has a DLL for download.
>Sorry, he usually provides the source code so I hadn't
>noticed. Anyway, even if you only have a DLL you still don't
>need to register anything to use it if you don't want to and
>you do not even have to ship it as a separate file as long
>as your application can write somewhere on disk.
And not even then, you can use something like Molebox
(http://www.molebox.com/) to package the DLL inside the executable. It
doesn't even have to be written to disk first.
--
Be seeing you.
The March Hare [MVP]
> And not even then, you can use something like Molebox
> (http://www.molebox.com/) to package the DLL inside the executable. It
> doesn't even have to be written to disk first.
Cool.
--
Please read this before replying:
1. Dshow & posting help: http://tmhare.mvps.org/help.htm
2. Trim & respond inline (please don't top post or snip everything)
3. Benefit others: follow up if you are helped or you found a solution
Thore B. Karlsen [DShow MVP]
<ph...@ndsm.maps> wrote:
>> And not even then, you can use something like Molebox
>> (http://www.molebox.com/) to package the DLL inside the executable. It
>> doesn't even have to be written to disk first.
>Cool.
Yep. :) Would be great if Microsoft could have built this
functionality into the linker/compiler!
--
Be seeing you.
Alessandro Angeli
> Yep. :) Would be great if Microsoft could have built this
> functionality into the linker/compiler!
I wrote something similar a couple of years ago and AFAIK
it's not so much a limitation of the linker but a limitation
of the system loader, which can only load from random access
filesystem handles, which practically means files unless you
write a kernel-mode filesystem driver. In the end, instead
of writing a loader or a linker, which are both a sort of
very very complicated and lenghty hacks, I decided to just
hack the system loader to load from my own file handle
instead of its own, so that I was able to extract the DLL
from the EXE resources, decrypt it and delete it when done
without ever releasing the exclusive lock on the file to
prevent user-mode snooping.
So I'd be wary of how they do it (I hope they wrote a
linker), but it's a cool software to know anyway.