On Fri, 1 Mar 2002, Chris Nuernberger wrote:
> > In the Windows world all anyone needs to know is the fourcc code
> > (or the GUID). The format is unambiguously defined by this (at least
> > the YUV formats are). Nobody uses anything other than this.
> >
> > These are industry standard formats. Documented in many places on
> > the web. Such as:
> >
> > http://www.webartz.com/fourcc/
>
>
>
> 1. Never programmed video in Windows.
> 2. ass-umed that GUID meant Globally Unique Identifier, not fourcc code (They
> looked particular, perhaps should have followed that up a bit more).
The GUID is generated from the fourcc code. See RFC2361:
http://rfc.sunsite.dk/rfc/rfc2361.html
In the case of a fourcc code, there is always a coresponding GUID.
The opposite isn't true, however.
> 3. You are definitely correct. That web page tells me everything I could
> ever want.
>
> > Despite this, the vImageFormatValues spells all of this out
> > in excruciating detail. I don't understand what problem you are having.
>
> No it does not. It does not explain where the actual data needs to be.
> Example, UYVY needs a byte of U, followed by a byte of Y, followed by a byte
> of V, followed by a byte of Y. That is pretty self explanatory, perhaps.
> YV12 needs a plane of y, a plane 1/4 size of v, a plane 1/4 size of u. The
> two period values, horizontal then vertical for each yuv tell you everything
> you need to know about the size of the planes, but what about if there is
> padding in the Y plane (some capture devices will do that)? Also, YV12 seems
Padding?
> to indicate that there is only a y and v plane, although you could guess that
> there is a U plane somewhere, and if there was then the component order would
> let you know where it would be.
>
> The point is that unless you are familiar with the fourcc code, then the
> structure does *not* tell you everything you need to know. It tells you a
> LOT, but not everything.
In all the YUV formats currently supported all the information is
there and you haven't given an example to the contrary. It is possible
to define surfaces that can't be described by the XvImageFormatValues,
but that's the purpose of the GUID. There isn't a set of parameters
that can encompass all the possiblities and I don't see the purpose
of trying. The current XvImageFormatValues is a compromise. I
didn't want to have anything more than the GUID, but people were
whining about that so they went in even though they'll make no
sense at all for compressed surfaces or indexed subpictures and
the like. In the end, at least for non-RGB formats, nobody ends
up using anything other than the GUID.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
