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

illiminable ogg at illiminable.com
Wed Oct 20 23:32:47 PDT 2004


----- Original Message ----- 
From: "Ross Finlayson" <finlayson at live.com>
To: <xiph-rtp at xiph.org>
Sent: Thursday, October 21, 2004 2:13 PM
Subject: [xiph-rtp] Suggestion: Define a static set of codebooks for Vorbis 
streaming


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

Or to further build on that idea... I think the dynamic codebook is also a 
strength in many cases... and saying one set of codebooks to rule them all 
isn't a realistic solution... but i do like the idea of a codebook id.

So how about the idea of a codebook server... which could be http... you 
just make a query of the codebook server with the codebook id and you get 
delivered the codebook... players could come with the standard set of 
codebooks already... so you wouldn't need to do this every single time, this 
means most of the time the codebook doesn't need to be transmitted... but it 
still provides a way that future improvements can be made without all 
players needing to already have the codebooks. Each unique codebook would 
only be transmitted once, rather than once per file/chain.

Though i guess one issue is... can anyone just have their own codebook 
server... or should xiph provide the master list of known codec id's... ie 
is the codec id a universal id, or just one unique to the stream provider. 
There's advantages and disadvantages to each method... probably for the 
client side, one authoratative source of codecs run by xiph is better... but 
from the distributor side, that's not so great, as they need to submit their 
codebooks before they can be used (though that's probably not too big a 
deal... as it's not like peopel are coming up with new codebooks elft right 
and centre).... and also it means that one entity bears the burden of 
distributing all the codebooks.

So i guess namespacing the codebooks might be an idea... but then you'd need 
an official namespace, so that you don't end up duplicating codebooks for 
every stream providor.

Zen. 




More information about the xiph-rtp mailing list