> > FourCC is a codec identifier, nothing more. It's four letters which can > be > referenced against a table to see what codec it is, it's a standard used > by RIFF > (aka, wav and avi) and older Macintosh formats, and in my opinion, its > obsolete. >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.> > This is also interesting work in that, once we're done, we'll have a > standard to > use for a compressed lossless format.. a FLAC for video, for editing or > archival > purposes, similar to HuffYUV.I think that's something completely different. Any specialised lossless compression, as opposed to raw data will have it's own special setup requirements.> I'm drafting OggYUV and OggRGB on the wiki right now, so everyone can be > on the > same page for what the result of this will look like. The questions we > need to > answer are which colorspaces are needed and which encoding methods are > needed.At the end of the day, the reason such a codec doesn't exist, is not because no one has written a spec... it's because no-one has written the code yet. I know from my perspective, a far more useful format in directshow would be a simple rawFOURCC code for the yuv types, if we insist on keeping RGB and yuv separate. 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. Zen.
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
This also includes, other non raw formats... http://www.fourcc.org/codecs.php "fourcc" 's of rgb types http://www.fourcc.org/rgb.php raw yuv formats only http://www.fourcc.org/yuv.php Registered fourcc codecs http://www.microsoft.com/whdc/archive/fourcc.mspx Enumeration of actual types that are used in directshow (bottom of page) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcedshow/html/_wcesdk_directshow_media_types.asp Descriptions of the common yuv types used in windows http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp> > 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.Well thats the thing about raw codecs, if you use the types that are supported by hardware and/or other codecs, you don't have to do anything except copy the memory. When you start using things that no hardware generates, or can display directly, that's when you have to write code to convert. All i'm saying, is there are certain types that are defined, hardware can display them, hardware like cameras generate them. Zen.
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.