arc at Xiph.org
Tue Nov 8 18:33:45 PST 2005
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
> 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.
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
More information about the ogg-dev