search for: koleszar

...in order to maximize the value of the patches we submit back to the community. I'm aware of OGM, and of the philosophical differences involved. However, it does seem to meet the technical requirements, so I'd be interested to hear arguments for and against adopting it. Thoughts? John Koleszar

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

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

...in order to maximize the value of the patches we submit back to the community. I'm aware of OGM, and of the philosophical differences involved. However, it does seem to meet the technical requirements, so I'd be interested to hear arguments for and against adopting it. Thoughts? John Koleszar

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

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

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

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.

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

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

...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 Message ----- From: "John Koleszar" <jkoleszar@on2.com> To: <ogg-dev@xiph.org> Sent: Friday, November 11, 2005 3:43 AM Subject: [ogg-dev] OggPCM version / header finalization >I have OggPCM (as currently defined) support implemented in mencoder and >mplayer. I'd like to request that we settle on modific...

...ot;unspecified" variants I declared will have to suffice. It's not meant to support every conceivable format (notably it doesn't do >8bpp) but it should support lots of common/popular formats easily, and is extendable to scratch someone else's itch. Thanks in advance, John Koleszar

...n) so that roundtrip compatibility becomes possible, 2) keep the existing mapping approach, because at least Jean-Marc Valen has indicated (on IRC) preference for it over the restrictions I suggested a couple of years ago, 3) add the multiple, preferential mapping approach because at least John Koleszar agreed with it the last time around and nobody objected, and 4) cover as many of the special cases, nits, canonicalization issues, and so on, as I can think of. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/fr...

...ot;unspecified" variants I declared will have to suffice. It's not meant to support every conceivable format (notably it doesn't do >8bpp) but it should support lots of common/popular formats easily, and is extendable to scratch someone else's itch. Thanks in advance, John Koleszar

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

Hi, The Xiph Wiki contains the four pages: OggPCM OggPCM Draft1 (with Talk page) OggPCM Draft2 OggPCM Draft3 Can I suggest that this be reduced to just one (or maybe two) pages. I suggest this because somebody has started making changes to OggPCM Draft2. My guess is that this is not desirable. Regards, Martin -- Martin J Leese E-mail: martin.leese@stanfordalumni.org Web:

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

...ed, vs establishing a "standard order", so that multiple streams can supply different bitrates/etc for different channels if such support is needed. Even mono audio should do so, simply to specify that the audio is "center". On Thu, Nov 10, 2005 at 04:23:23PM -0500, John Koleszar wrote: > Basically I was trying to provide a method where a logical bitstream > could contain only a subset of the total number of channels of the > source. [snip] > This is similar to the page serial number, I know, but I don't think that's > sufficient if data from the sa...

On Tue, Nov 15, 2005 at 03:10:22AM +1100, Erik de Castro Lopo wrote: > That spec is being superceded by: > > http://wiki.xiph.org/index.php/OggPCM2 The project has been forked, not superceded. Work on OggPCM is continuing, the team working on OggPCM2 is free to submit their own draft but some are not welcome to continue work on OggPCM due to their recent social conduct. I'm