[xiph-rtp] Updated -04 Vorbis-RTP I-D

Michael Smith msmith at xiph.org
Wed Dec 15 20:49:03 PST 2004


On Thursday 16 December 2004 13:44, Phil Kerr wrote:
> >First question: Why are you trying to get the packed codebooks? I think
> > it's fairly unlikely that these will be interesting on their own. I would
> > think what you'd be interested in is getting the entire codebook setup
> > packet (which has the mode definitions, mappings, etc. as well as the
> > codebooks themselves) - and since that's just an entire packet, you don't
> > need a special API for it. Am I misunderstanding your needs here?
>
> Nope.  It does look a lot easier to use the unpacked codebook.

Now I'm confused again - what are you going to do with the _unpacked_ 
codebook? It's only useful internally to the decoder, and doesn't have a 
canonical form (different decoders will have different unpacked structures). 

>
> Thanks for this info.  I was wondering what they did as well as getting
> access to the values.

Ah. Ok, I can give a better explanation of that, then.

Vorbis has two blocksizes for any given stream: 'short' and 'long'. They may 
be the same size, but 'short' must be equal to or less than 'long'. They can 
be any power of two between 64 and 8096 (I think; check the spec if you 
really need to know). The reference encoder uses 256 and 2048 for most 
streams, and 512 and 4096 for very low bitrates.

Each audio packet in a vorbis stream has a single bit to indicate which type 
of block it is (short or long), so these values (from the header) are 
essential for decode. They're used to know how much data to decode and 
overlap with the previous packet before returning to the application.

The other thing an application often needs the blocksizes for is figuring out 
the (PCM) length of a packet - for timing information in a framing layer such 
as ogg, or rtp. Since packets in vorbis are not independent, the amount of 
data decodable from a given packet also depends on the blocksize flag of the 
_previous_ packet (this is used in calculating how to overlap the output of 
the MDCT). 

I hope that helps you. Feel free to ask more :-)

Mike





More information about the xiph-rtp mailing list