[ogg-dev] OggYUV

[jkoleszar at on2.com]

Here's a shot at a list of fields:

// High level data
Displayed Width&Height
Stored Width&Height
Aspect Ratio (Fractional)
Frame Rate (Fractional)
FourCC (Optional, set to zero to use values below)
Colorspace (enum, R'G'B', Y'CbCr, JPEG (not sure proper name), etc)

// Subsampling data
U Channel X Sample Rate (Fractional)
U Channel Y Sample Rate (Fractional)
U Channel X Sample Offset (Fractional)
U Channel Y Sample Offset (Fractional)
V Channel X Sample Rate (Fractional)
V Channel Y Sample Rate (Fractional)
V Channel X Sample Offset (Fractional)
V Channel Y Sample Offset (Fractional)

// Storage data
A Channel Bits Per Sample
A Channel Field 0 Offset (in bits)
A Channel Field 1 Offset (in bits)
A Channel X Stride (in bits)
A Channel Y Stride (in bits?)
Y/R Channel Bits Per Sample
Y/R Channel Field 0 Offset (in bits)
Y/R Channel Field 1 Offset (in bits)
Y/R Channel X Stride (in bits)
Y/R Channel Y Stride (in bits?)
U/G Channel Bits Per Sample
U/G Channel Field 0 Offset (in bits)
U/G Channel Field 1 Offset (in bits)
U/G Channel X Stride (in bits)
U/G Channel Y Stride (in bits?)
V/B Channel Bits Per Sample
V/B Channel Field 0 Offset (in bits)
V/B Channel Field 1 Offset (in bits)
V/B Channel X Stride (in bits)
V/B Channel Y Stride (in bits?)

Known limitations: This won't support formats with variable strides.
Haven't found any common formats that this will exclude, but I haven't
looked very hard. Also won't support subsampled alpha, which is probably
undesirable anyway.

I'm still not convinced that RGB and YUV can't (shouldn't) be combined,
since RGB is so similar to a 4:4:4 YUV format.

I still include FourCC, because using it is a shorthand way of filling out
almost all of the fields below for the common raw formats. Subsampling
offsets are one example. However, any application that can only identify
its source data by FourCC probably doesn't know where the samples were
taken, so that would have to be invented in any case. If you want to limit
the allowable values for the FourCC field, I don't have an issue with
that, but I think it's useful for decoders to be able to tell easily
whether or not they support the format (since most decoders will operate
on the well defined formats) and useful for encoders, since most data
sources are described by a fourcc (the exception being application that
actually generate images, rather than extract/transcode, I suppose)

Well formed streams should fully describe the FourCC in the descriptive
fields below, but whether it's actually necessary to describe them or not
is a separate argument.