[xiph-rtp] Theora "setup idents" and codebook URLs in SDP

David Barrett dbarrett at quinthar.com
Wed Jun 1 17:50:49 PDT 2005


So it sounds like the final word is that each Theora data packet will 
have a 16-bit "setup ident" field (ie, a codebook identifier) in the 
following payload header:

From: http://lists.xiph.org/pipermail/xiph-rtp/2005-May/000229.html
 >     0                   1                   2                   3
 >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >    |           Setup Ident         |   Reserved    |C|F|R| # pkts. |
 >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Currently it sounds like the only requirement is that the "setup ident" 
be unique within a given session.  Ie, ident #1234 might indicate a 
different codebook in two different sessions (though it always refers to 
the same codebook within any given session).  With all this in mind, I 
have a couple questions:

1) What is the SDP syntax for associating a particular codebook URL with 
a given setup ident?

2) Can I specify many codebooks (each with a different setup ident) in 
the SDP such that the decoder can "prefetch" the codebooks before they 
are used in the RTP?

3) What are the rules for caching codebooks in the decoder?  If setup 
idents are only unique and persistent within a given session, obviously 
I can't use those.  I can easily use the URL, but because it's 
essentially arbitrary (ie, not derived from the codebook itself), it's 
entirely possible that the codebook "at the other end" of the URL might 
change without my knowledge (ie, my cached version can become dirty). 
One proposal is to say:

"A codebook URL SHOULD include a CRC32 of the codebook itself, so as to 
prevent the codebook referenced by URL from changing, and thereby 
enabling decoding clients to use the URL as a persistent, 
globally-unique identifier of the codebook itself, suitable for reliable 
caching purposes."

-david


More information about the xiph-rtp mailing list