[ogg-dev] OggYUV

[Arc]

On Wed, Nov 09, 2005 at 09:59:02AM +0800, illiminable wrote:
> 
> While it's true there are a bunch of FOURCC's that represent non-raw 
> formats like DIVX etc, the ones which represent raw YUV types are pretty 
> well defined. Yes you certainly still need the width, height, aspect ratio 
> and frame rate.

Since FourCC is an identifier for a different codec, what you are talking about 
is an array of different raw codecs, each representing a different chroma 
subsampling and data packing method.  This sounds absolutly horrendous and 
utterly unuseable, as these things combined would make for a very large number 
of possible raw codecs.

If there is a limited set, then please paste to the list (or a URL) a list of 
what those formats are.  

Oh and I really, REALLY don't want to hear anymore from you about wanting to 
combine OggRGB and OggYUV into a single codec... if FourCC supports so many 
different YUV and RGB codecs, consolidating these into 2 is very reasonable by 
comparison.

 
> As far as  i see it there's no reason not to use such a simple fourcc based 
> format for the common cases, and use a more complete/complicated format for 
> the strange cases where people want to get fancy. Since all the data being 
> worked with in directshow is either a fourcc yuv, or one of a handful of 
> rgb types.

If someone's already done the work to find the common YUV formats, then again, 
please paste them or a URL to a webpage describing them.

However, we're going to use a single YUV codec which permits many different 
formats, as unlike MS's DirectShow/RIFF, Ogg isn't crippled by FourCC, and I see 
little reason for doing so.

If the bits can be provided which allow several hundred (or thousand) possible 
formats, by combining interlaced vs non-interlaced, chroma subsampling and 
methods thereof, colorspace, packed vs planar, and channel bit depths, and 
within this generic set all of the common and uncommon-but-probobal formats are 
covered, I think our job will be done.

Just because the codec supports it, doesn't mean that every application which 
uses the codec must support all the possibilities.  By making the data 
definition generic we allow more re-used code (ie, for colorspace converters) 
and prevent the "raw codec" sprawl you above described with FourCC codecs.


As a new issue, does anyone know if "gamma correction" is something used by YUV 
codecs at all?  I know it is by some RGB, which is why I included a 16-bit field 
for it in the draft OggRGB spec, 16 being an arbitrary size which conviently 
pads the remaining fields to convient 32-bit words.

 http://wiki.xiph.org/OggRGB


-- 

The recognition of individual possibility,
 to allow each to be what she and he can be,
  rests inherently upon the availability of knowledge;
 The perpetuation of ignorance is the beginning of slavery.

from "Die Gedanken Sind Frei": Free Software and the Struggle for Free Thought
 by Eben Moglen, General council of the Free Software Foundation