On Sat, 2 Mar 2002, NUERNBERGER CHRISTOPHER PETER wrote:
> I would agree, just the GUID is enough. And it is easy to check, easy to
> look up.
>
> Looking at the header for xvideo, how is someone supposed to know that the
> guid refers to a fourcc code?
It doesn't refer to a fourcc. It refers to the GUID.
It just happens to be that many GUIDs have a corresponding fourcc
code as described in RFC2361.
The point is that looking up capabilities from the structures
is not practical and I question the usefulness of such data
structures (for YUV anyhow). I can advertise a compressed surface or
some other weird surface and the info in the structure (other than
the GUID) isn't even applicable. You shouldn't try to use a
format if your app doesn't recognize the GUID. Because of
the large varieties of surfaces possible all apps can really
do is compare a list of GUIDs they know and support with ones
that are being reported. That's how things have ended up in
the Windows world.
One exception are the RGB formats whos fourccs unfortunately
don't describe the data unambiguously. In that case the extra
data is needed. Fortunately the requirements for describing
RGB formats are very simple and can easily be described with
a few values.
>
> Padding refers to the extra bytes at the end of a line.
> Some capture cards will do that so that scanlines are word or double word, etc.
> In YUV420:
> if a Y line is padded w/ two bytes, each U or V line will be padded with one
> byte so two U lines precisely equals one Y line.
>
That's not part of the format specification. Pitches of the data
and offsets to individual planes are hardware specific and returned in
the XvImage structure after it has been created.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
