similar to: OggYUV

On Tue, Nov 08, 2005 at 06:08:25PM +0800, illiminable wrote: > Why not just make it OggRawFOURCC, do we really need one stream format for > rgb, and one for yuv ? [snip] > I just meant oggRaw, not fourcc. Oh, thank god you corrected this. :-) I was contemplating an "OggVid" format, and here is why I'm steering against it (though, yes, this has been a topic of

On Tue, Nov 08, 2005 at 06:08:25PM +0800, illiminable wrote: > Why not just make it OggRawFOURCC, do we really need one stream format for > rgb, and one for yuv ? [snip] > I just meant oggRaw, not fourcc. Oh, thank god you corrected this. :-) I was contemplating an "OggVid" format, and here is why I'm steering against it (though, yes, this has been a topic of

On Tue, Nov 08, 2005 at 09:36:52PM +0800, illiminable wrote: > > Then there's YUY2 which is interleaved Y0 U0 Y1 V0 Y2 U1 Y3 V1, and YVYU > (Y0 V0 Y1 U0 Y2 V1 Y3 U1), and UYVY (U0 Y0 V0 Y1 U0 Y2 V0 Y3)... and then > there's AYUV, which has a 4th alpha channel. We will only be doing [A]YUV ordered planar encoding, no other order, not packed using one of several methods.

On Tue, Nov 08, 2005 at 09:36:52PM +0800, illiminable wrote: > > Then there's YUY2 which is interleaved Y0 U0 Y1 V0 Y2 U1 Y3 V1, and YVYU > (Y0 V0 Y1 U0 Y2 V1 Y3 U1), and UYVY (U0 Y0 V0 Y1 U0 Y2 V0 Y3)... and then > there's AYUV, which has a 4th alpha channel. We will only be doing [A]YUV ordered planar encoding, no other order, not packed using one of several methods.

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

On Tue, Nov 08, 2005 at 03:33:57PM -0500, John Koleszar wrote: > > In terms of colorspaces, it seems to me that the only way to completely > describe the colorspace is to provide the transform matricies to or from > some reference colorspace. Is this a valid statement? Except there are not enough colorspaces in use to need to do this, as far as I've read at least.. a set of

> 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

Arc wrote: >Not the camera, only the application which goes between the camera and >OggStream. Plus, changing between packed and planar is easy, my reason for >wanting to avoid packed is there's simply too many different ways to do it. > > My argument is that that application shouldn't have to convert to a fixed format. It should be able to say here's some YUY2

On Wed, Nov 09, 2005 at 10:52:53AM +0800, illiminable wrote: > > "fourcc" 's of rgb types > http://www.fourcc.org/rgb.php I'm prowd to say that http://wiki.xiph.org/OggRGB supports all of these losslessly as well as PNG for non-indexed bitmaps. These are video formats, correct? Not just single frames? > raw yuv formats only > http://www.fourcc.org/yuv.php

Timothy B. Terriberry wrote: >Chapter 4 of the Theora specification does a reasonable job of laying >out all of the possible parameters for a Y'CbCr-style color space, which >includes as a subset those needed for RGB. Much more detailed >information is available from Charles Poynton's Color and Gamma FAQs: >http://www.poynton.com/Poynton-color.html >If you wish to do any

In the effort of reducing list traffic, I've consolidated two replies into one: On Tue, Nov 08, 2005 at 08:24:33PM -0800, Ralph Giles wrote: > > BTW, there are already a number of general "raw" video formats in > professional use; it's not just AVI we have as prior art. :) > I'd like to see some discussion of the merits of adopting one of those > if we

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

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

On Wed, Nov 09, 2005 at 01:14:08PM +0800, illiminable wrote: > > >I agree, which is why I wrote the OggPCM draft when we already have FLAC. > >These > >formats are not difficult to design or implement, and I think the added > >efficiency and simplicity will more than make up for it. > > Which i looked at... and i'm wondering why on earth it has a sync code

On Fri, Nov 11, 2005 at 05:29:52PM +0800, illiminable wrote: > > (quote:"and thus the subject of FourCC labeling in OggStream's native video > interchange formats is closed.") > > ... doesn't sound like community debate to me. > > Maybe i missed the meeting where you became god here. If you are going to > make claims that you somehow are in charge

> But chroma subsampling? no. And this is where much of the complexity > comes. > > If we were to combine them, we would be, essentially, doing it something > like > this: > Value Meaning > 0 RGB > 1 YUV444 > 2 YUV422 > 3 YUV420 > 4 YUV411 > ..... Yes. > And then spend an additional field on bits/channel, whereas both chroma

> But chroma subsampling? no. And this is where much of the complexity > comes. > > If we were to combine them, we would be, essentially, doing it something > like > this: > Value Meaning > 0 RGB > 1 YUV444 > 2 YUV422 > 3 YUV420 > 4 YUV411 > ..... Yes. > And then spend an additional field on bits/channel, whereas both chroma

On Tue, Nov 08, 2005 at 04:59:33PM -0800, Arc wrote: > 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. Well, we're talking about an uncompressed format. OggMNG is already "FLAC for video". However, it doesn't do

On Thu, Nov 10, 2005 at 05:30:10PM +0100, oliver oli wrote: > John Koleszar wrote: > >I hadn't even heard > >of ambisonics until your post, to be honest. > > because people don't know how to distribute ambisonics. no way to play > it in a DVD player. there are no easy to use software players that > decode ambisonic files and there are no widely used audio

Moved off OggYUV thread as this is off-topic for it.. On Wed, Nov 09, 2005 at 04:51:51PM +0800, illiminable wrote: > > > >Um, data packets consist of a 32-bit header followed by PCM data. Where > >did you get the idea that "sync" data was in the packet? > > That's what the first 32 bits of "header" are. Um, no, the first 32 bits of the header is