[Theora-dev] Re: [ogg-dev] OggYUV
jkoleszar at on2.com
Tue Nov 8 05:43:21 PST 2005
>Because the fields are /not/ going to be the same for RGB.
>RGB has resolution, framerate, prehaps even interlace and aspect ratio...
>But chroma subsampling? no. And this is where much of the complexity comes.
Not all YUV formats are subsampled either. And not all YUV formats are
planar. If you're going to distinguish between them, I think it has to
be along the lines of packed vs planar, not colorspace. An <a
href="http://www.fourcc.org/yuv.php#AYUV">AYUV</a> frame, for instance,
and a RGBA frame are going to look identical in terms of header info and
data packet size, they just differ in colorspace.
It seems easier to me to have two 32 bit fields, one I'll call
"PixelFormat" and another I'll call "FormatExtraData" for this
discussion. The PixelFormat field uniquely identifies the data storage
method. This includes YUV/RGB, the chroma sampling, packed vs planar,
etc.. Then let the FormatExtraData field could be defined (or not) for
each format. This might be a good spot to stick the RGB bit packing, or
an endianness flag, or a vertical flip flag, etc.
Yes, I would propose using the proper fourcc to describe the pixel
format, since they're reasonably well documented at fourcc.org, but it
doesn't have to be that way. There are so many pixel formats that's it's
hard to just enumerate all the data contained in a fourcc, let alone put
it in a simple header. I don't know of any applications that operate on
completely arbitrary image data, so putting some of the smarts into the
application rather than trying to put it in a header doesn't seem like a
bad trade off. As an exercise, how would you create a header to
distinguish between UYVY data and YVYU? Both are 4:2:2 packed YUV
formats, just differing in component order.. It's not an endianness
issue either (U Y0 V Y1 vs Y0 V Y1 U)
More information about the ogg-dev