[xiph-rtp] Codebook delivery and metadata

[Phil Kerr]

Hi Aaron,

On 27 Oct 2004, at 01:53, Aaron Colwell wrote:

> 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 think if there is something smaller, say 32 bits, we could use to  
uniquely identify a codebook this would keep the packet size down.

To an extent having a variable length field for the ID is good in one  
way, it keeps the size down, but bad in another as it creates  
additional decoding overhead (work out how big the key field is and  
then compare it to the current codebook).  With a small fixed-field you  
can just memcmp() it with the current codebook key, which is a very  
quick operation.

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

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