[xiph-rtp] Codebook delivery and metadata

[Aaron Colwell]

On Wed, Oct 27, 2004 at 11:19:51PM +0100, Phil Kerr wrote:
> 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 doubt the decoding overhead is significant enough to worry about. In the
overall scheme of the playback process I doubt a profiler would show much of
a difference between the 2. You could even use memcmp for this scheme if you
wanted to. I guess I am pro-variable size because it incrementally penalizes
chaining. If you aren't using chaining, there is no bandwidth penalty. The
more chained groups you use, you incur a slowly increasing bandwidth penalty.
The penalty is not that large, but it can add up when a server is sending a
lot of streams.

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