[xiph-rtp] Suggestion: Define a static set of codebooks for Vorbis streaming

Ross Finlayson finlayson at live.com
Wed Oct 20 23:13:28 PDT 2004


Let's face it - Vorbis's use of dynamic codebooks is a major Archilles heel 
for streaming.  One could even go so far as to call it an architectural 
flaw.  (Having to send a complete new codebook potentially for each song 
partially defeats the purpose of audio compression.)

It would be much better to have a fixed, predefined set of codebooks that 
all receivers would know in advance.  Then you'd need to send only a 
'codebook id', which should be small enough to include in the Vorbis RTP 
payload format header.    E.g., if there were <= 256 pre-defined 'codebooks 
for streaming', then you could use a 1-byte field within the RTP payload 
format to indicate which one.

I suggest that the Vorbis designers should just figure out a complete set 
of codebooks that are likely to be useful, and use only those for streaming.

Some other people's comments on this issue (on the IETF "avt" mailing list):

At 05:14 PM 2/26/01, Dave Singer wrote:
>This being the case, I suggest the approach that JPEG took:  make it 
>possible to transmit the code-bbooks in stream, but also have a set that 
>are statically defined and that can be selected simply by index. Despite 
>what you say about them changing with every release below, I bet that by 
>the time the RTP payload is mature, there can also be a mature set of 
>codebooks...

At 01:12 PM 7/9/03, Aaron Colwell wrote:
>I agree with Ross on this. It seems that these codebooks are causing too
>many problems that aren't worth dealing with. People have been suggesting
>getting the codebooks via HTTP, alternate TCP links, and all sorts of
>other methods. If your going to go that far why not just use HTTP to
>deliver the data. That way you are guaranteed to get everything in the
>right order.
>
>My guess is that other video and audio codecs use predefined tables to
>avoid this very problem. Vorbis should do the same. The Vorbis folks
>should come up with a "streamable" profile that encodes the audio using
>predefined codebooks. Doing this makes all of the complicated codebook
>issues go away. They could also create an offline tool that will translate
>any Vorbis file into a "streamable" Vorbis file. This idea is similar to
>hinting tools used for MPEG4 and 3GPP files.




More information about the xiph-rtp mailing list