[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