Hi, I'm looking for more documentation on the Vorbis bitstream format. The goal for me is to write an optimized decoder using only integer or fixed point math for use on the Phatnoise Car Audio System (see http://www.phatnoise.com). I've already found the info on the Ogg framing system and I've already written my own thing for parsing through Ogg frames (easy). Also, is RTP only used for streaming Vorbis data from internet streams? When that data is packeted into a file, I assume it uses the Ogg framing system. <p>Thanks, <p><p>Brendan Dowling Embedded Systems Engineer Phatnoise, Inc. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 12:38 PM 2/8/02 -0800, you wrote:>Hi, > >I'm looking for more documentation on the Vorbis bitstream format. >The goal for me is to write an optimized decoder using only integer >or fixed point math for use on the Phatnoise Car Audio System >(see http://www.phatnoise.com).Sorry. In-depth bitstream format docs are the bit we haven't really even started on documenting. The libvorbis source is where you have to go (and though the source is fairly impenetrable if you try and figure out how the encoder works, figuring out the decoder - and the bitstream format - is substantially easier). You might be better off starting from libvorbis - ripping out all the encode side stuff, and then converting everything to fixed point. That way you don't need to rewrite all the generic non-fp-stuff, or even figuring out all the details of the bitstream. The licence of the code is such that you should be able to do this without any problem. If you have specific questions that the source doesn't make clear, we're always willing to answer them - either here on the list, or on our irc channel (which, if people are around, is a better way to get quick responses, and discussion, etc.). irc.openprojects.net #vorbis> >I've already found the info on the Ogg framing system and I've already >written my own thing for parsing through Ogg frames (easy).Yeah, this is simple (ogg/src/framing.c is what does this, including encode (write) side stuff, and that's only about 1700 lines including extensive self-tests.> >Also, is RTP only used for streaming Vorbis data from internet streams? >When that data is packeted into a file, I assume it uses the Ogg >framing system.Whilst it should be possible to use RTP for streaming, and there is a draft RTP payload spec out there (I forget the URL, but it should be easy to find), it isn't used currently. For reasons of simplicity, compatibility with the MANY clients out there, and so on, we use HTTP (with some special headers, which are optional) - there's stuff in xiph.org cvs (ices and icecast) for doing this. This just streams the data as-is, including the ogg framing. Michael <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Fri, Feb 08, 2002 at 12:38:57PM -0800, Brendan Dowling wrote:> Hi, > > I'm looking for more documentation on the Vorbis bitstream format. > The goal for me is to write an optimized decoder using only integer > or fixed point math for use on the Phatnoise Car Audio System > (see http://www.phatnoise.com). > > I've already found the info on the Ogg framing system and I've already > written my own thing for parsing through Ogg frames (easy).'Tis one of my priorities for the next month or so (unfortunately, along with a bunch of other stuff). But.... I can start you off. You can take the mainline encoder and do a simple but good translation to fixed point, using the following tips: 1) you want 8.24 precision for the floor vector. An integerized version of the floor0 LSP algorithm is on mainline, and floor1 is already integer only. For floor1, you just need to replace a lookup table. 2) the residue vector assembly has to be in 24.8. The implication of the above two is that the codebooks can't be pre-unpacked to a specific fixed point position. Codebooks are general and may need to be anywhere from 1.31 to 24.8. You can either unpack upon first use or do on-the fly unpacking from the unnormalized vorbis codebook packed float 32. The former is easier, the latter slower but more flexible. I can guarantee either will work for Vorbis I, Vorbis II may break a simple version of the former. 3) the MDCT on mainline has a stable dynamic range and is easy to integerize. The mainline integer version assumes a 14 bit fraction on the trig lookups, which frankly is far too little. This is done only because C doesn't have a 32x32->64 bit two result register multiply. If you're on ARM (for example) and have SMULL, use 2.30 for the lookups, only save the RdHi register and you'll have very good S/N. Sure, that's glossing over alot, but it turns out that integerization is mostly busywork. There's nothing tricky in an integerization; it's just that no one has taken the time. (As a note, I was contracted to take the time, and have written and am currently maintaining a commercial version for iObjects/Fullplay. For this reason I can't assist in coding, but I can answer any questions you have about the mainline code or specs.) Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.