[xiph-rtp] Codebook delivery and metadata

[Aaron Colwell]

Hi,

I vote for a modified version of 3 with the URL transmission of 2. Instead of 
shipping the whole MD5 with each packet I'd pick a smaller identifier. 
Something like a chain group ID. The URL packets would also contain the group
ID so it can be correlated with the data packets. I would also make the group
ID a variable length field so that there is minimal impact for streams that
don't use chaining an progressive impact for ones that do. You could do 
something like if MSb if the group ID byte is set, then it means that the
next byte is also part of the group ID. Since you'll likely need a "header
byte" to seperate URL packets from data packets, you could also put a flag
in this byte to say whether a group ID is present. The flag not being set
is equivalent to group ID 0. If the bit is set then a group ID field is present
and the group ID is 1 + the value of the group ID field.

I vote for 6 because I think it is the better solution. It also prevents the,
who's metadata do we use situation, that currently exists in multiplexed .ogg 
files.


Aaron

On Tue, Oct 26, 2004 at 11:01:00PM +0100, Phil Kerr wrote:
> 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.
> 
> _______________________________________________
> xiph-rtp mailing list
> xiph-rtp at xiph.org
> http://lists.xiph.org/mailman/listinfo/xiph-rtp
>