similar to: Raw/general purpose Ogg based container format?

I have OggPCM (as currently defined) support implemented in mencoder and mplayer. I'd like to request that we settle on modifications to this header by the middle of next week or freeze the current header as the official major version 1.0, so I can get the patches cleaned up and released. We will be shipping a separate product based on this work in the near-term future, and compatability

I take it you are talking about what is listed under alternative format ? If you have an implementation... you must have a list of enumeration fields... could you put them on the wiki. If we are asking for final comments... the wiki should be tidied up. The original format removed if the general consensus is that this is more on the right track... which it looks to be. Zen. ----- Original

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.

Michael Smith wrote: > libogg has two bitpackers; a little endian one and a bigendian one. ok, I didn't see it in the docs at http://www.xiph.org/ogg/doc/libogg/reference.html and didn't look in the header file first. My bad. Is it correct to state that the oggpack_* functions use little endian order, and the oggpackB_* functions use big endian order? Is it safe to mix calls to

Hi all, Xiph aims at developing open-standards media formats. Though xiph.org tells about vorbis/theora/flac/speex, nothing is mentioned about container to use (that is ogg/ogm). I have a few questions Is there a difference between ogg and ogm? I guess its only the extension that is different and everything else is same. Some tools (like ogmtools) are available to create ogm files. What is

John Koleszar wrote: > I have OggPCM (as currently defined) support implemented in mencoder and > mplayer. I'd like to request that we settle on modifications to this > header by the middle of next week or freeze the current header as the > official major version 1.0, so I can get the patches cleaned up and > released. One week is very little time to get public comment

Updated again... theora works and seeks properly (not to keyframe) in WMP 9 and 10. You can encode from a bunch of onew input types like RGB32, RGB24, IYUV etc. And fixed a bug that was stopping the filters being used in a activeX control in an IE browser. www.illiminable.com/ogg/ Enjoy, Zen.

Updated again... theora works and seeks properly (not to keyframe) in WMP 9 and 10. You can encode from a bunch of onew input types like RGB32, RGB24, IYUV etc. And fixed a bug that was stopping the filters being used in a activeX control in an IE browser. www.illiminable.com/ogg/ Enjoy, Zen.

Updated again... theora works and seeks properly (not to keyframe) in WMP 9 and 10. You can encode from a bunch of onew input types like RGB32, RGB24, IYUV etc. And fixed a bug that was stopping the filters being used in a activeX control in an IE browser. www.illiminable.com/ogg/ Enjoy, Zen.

Updated again... theora works and seeks properly (not to keyframe) in WMP 9 and 10. You can encode from a bunch of onew input types like RGB32, RGB24, IYUV etc. And fixed a bug that was stopping the filters being used in a activeX control in an IE browser. www.illiminable.com/ogg/ Enjoy, Zen.

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

Michael Smith wrote: >Whilst I accept that there are many good uses for chunked data, I >think the transformation is trivial, particularly given certain >characteristics of the Ogg container. Remember, the data, if you read >an ogg stream into memory, is _already_ likely to be non-contiguous, >due to ogg's structure. It's trivial, and has insignificant additional

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

From googling around, it seems that the ogg bitpacker has defined endianness, but I can't find anywhere that says which order it's in. Any help? The endianness of the 24 bit field in the OggPCM header should be specified. I was going to edit the wiki to specify it as network byte order, then realized that you may have standardized on something else in theora/vorbis already.

I threw a rough draft of an alternative format incorporating the comments received so far in this discussion on the wiki: http://wiki.xiph.org/index.php/OggPCM#Format Oliver, This seems to me like it would support the ambisonic requirements you mention, though it doesn't (and I imagine won't) describe the mic locations. Somebody who actually uses that info could probably define extra

Hi, I hope you can help, I am in need of some assistance with the DirectShow filters for Theora. I have successfully created a working capture graph using OGG / Vorbis / Theora, however, when I add a Sample Grabber Directshow filter between the FFDShow decoder and Theora Encoder, this results in the video file being mirrored vertically. I have noticed that the original CaptureGraph was using

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