[xiph-rtp] Codebook delivery and metadata

Phil Kerr phil at plus24.com
Tue Oct 26 15:01:00 PDT 2004


Hi all,

Below are some ideas for handling codebook delivery and metadata  
handling.  Please feel free to pull-apart these suggestions.

-P

------------------------------------------------------------------------ 
----------------------------

Codebooks

1.)

SDP is used to set the initial stream codebook.

If the codebook changes a codebook change message is sent (within the  
RTP Vorbis stream) indicating when (according to RTP-time) the change  
will occur and the URL of the new codebook package together with a MD5  
sum (used for cache identification).  Within the codebook package is  
the RTP-time when the new codebook is to be used.

Metadata can be sent within the RTP stream as a meta-message packet  
(see points 5/6 below).

Pros:

Codebook and RTP stream are temporally tied together.

Cons:

When do we know a codebook change will occur?  If this is a series of  
chained Ogg files is this when the current filestream has ended?  If so  
then we are relying on the length of the playout buffer to inform the  
player of the change and retrieve the new set before we have a break in  
the stream.  If this cannot be done in time then the player may play  
garbled audio.  Also adds small packet decoding overhead as each one  
needs to be checked to see if it is data or message.

Can the chaining module read-ahead (or use the track length) to  
schedule sending the codebook change message at the right time?  Can we  
accurately pin the codebook change time?


2.)

SDP is used to set the initial stream codebook.

Periodic transmission of associated codebook URL in-stream.

Pros:

More reliable than sending single message.

Cons:

No real tight temporal coupling between codebook and Vorbis stream for  
chaining.


3.)

As above but add codebook key to each Vorbis-RTP packet.  Each packet  
has the MD5 key of the associated codebook needed for decoding.

Pros:

Hard association between Vorbis stream and associated codebook.  Player  
is able to prevent decoding Vorbis data with wrong codebook.

Cons:

Adds packet bloat, adds processor overhead for decoding as each packet  
needs to be checked.


4.)

SDP is used to set the initial stream codebook.

Make the stream session single codebook only and chaining files will  
need to be re-encoded first.

Pros:

Makes the stream management a lot simpler.

Cons:

Puts strain on the server re-encoding on-the-fly, or makes playlist  
pre-processing a pain.



Metadata

5.)

Metadata is sent as a distinct message within the Vorbis-RTP stream.

Pros:

Simple.

Cons:

Not flexible, adds packet decoding overhead.

6.)

Have metadata sent in a separate RTP stream - Annodex or something  
similar.

Pros:

More extensible.

Cons:

Adds implementation overhead as you need to run another RTP receiver.



More information about the xiph-rtp mailing list