[Theora-dev] Re: [ogg-dev] OggYUV

[John Koleszar]

Arc wrote:

>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)