search for: jkoleszar

> Unfortunately the ALSA API defines a number of formats which are > in practice extremely rare. In particular, any unsigned int format > larger than 8 bits. For instance, the only unsigned int type that > libsndfile supports is unsigned 8 bit. I expected this, it just seemed like a good starting point to get more than 7 formats on the table. Specifically I wanted to the logarithmic

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.

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

...s... 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 modifications to this heade...

jkoleszar@on2.com wrote: > I updated the wiki with another rev of this format. Updates include > support for 43 formats in 14 coding schemes, as derived from the ALSA API. As an interested bystander, I see that this proposal still has only one format and one rate field for possibly many channels. Ea...

Hi John, jkoleszar@on2.com wrote: > Hi all, > > I updated the wiki with another rev of this format. Updates include > support for 43 formats in 14 coding schemes, as derived from the ALSA API. > This seemed like a good way to get a list of what the formats in common > use out there are, so it shou...

Hi all, I updated the wiki with another rev of this format. Updates include support for 43 formats in 14 coding schemes, as derived from the ALSA API. This seemed like a good way to get a list of what the formats in common use out there are, so it should be fairly comprehensive. Modifications to the "rev 2" format: 1. Expanded the 'id' field to support more than 7 formats.

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

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

> True, but remember that the channel map type implied the number of > entries in the table, and also that in this organization you'll always > number the logical channels consequtively since each logical channel > indeed corresponds to an index into the array. If the channel map type > says it's a map for 5.1, there will only be 6 slots in the table no > matter how

Hi all, I'm soliciting comments on OggUVS, a proposed method of encapsulating uncompressed video in Ogg files. Please have a look at: http://wiki.xiph.org/index.php/OggUVS First note, on the supported colorspaces: I know they're lacking. Had a good conversation with derf_ about it last night, and when I get some time I'll add the two that Theora supports. For my immediate

Rene Herman wrote: > Why store N-bit in the most significant bits and not least? Doesn't > that mean an application would likely need to shift everything down > again? One advantage of storing in the MSB's is that the relative value remains correct when processed as the larger word size. For instance, a signed 12 bit integer would use 0x400 to represent +50% amplitude. By

Hi all, I'm soliciting comments on OggUVS, a proposed method of encapsulating uncompressed video in Ogg files. Please have a look at: http://wiki.xiph.org/index.php/OggUVS First note, on the supported colorspaces: I know they're lacking. Had a good conversation with derf_ about it last night, and when I get some time I'll add the two that Theora supports. For my immediate

>> True, but remember that the channel map type implied the number of >> entries in the table, and also that in this organization you'll always >> number the logical channels consequtively since each logical channel >> indeed corresponds to an index into the array. If the channel map type >> says it's a map for 5.1, there will only be 6 slots in the table no

Jean-Marc Valin wrote: >>I'm also not entirely sure that the coding chosen for the channel >>definitions is the best one. Typically we'd expect each type of channel >>map to contain all and nothing but the channel definitions typically >>used with that map type, in some order. For example L, C, R, Ls, Rs and >>LFE for 5.1. If so, all we're really

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

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

(crossposted to theora-dev, since I thought some folks there might be interested) Hi all, Does anyone know of a ogg based container format that would be appropriate for holding raw AV data? I'm specifically interested in PCM audio, and uncompressed YV12 and RGB32 video. Basically looking to use it as a lightweight tool interchange format, generally muxed by mencoder and read/modified by

(crossposted to theora-dev, since I thought some folks there might be interested) Hi all, Does anyone know of a ogg based container format that would be appropriate for holding raw AV data? I'm specifically interested in PCM audio, and uncompressed YV12 and RGB32 video. Basically looking to use it as a lightweight tool interchange format, generally muxed by mencoder and read/modified by

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