[xiph-rtp] My impressions about the discussion about codebook delivery.

[Phil Kerr]

Hi Ramon,

I'm back on-line from the death of my iBook, but in an email I sent to 
Ralph yesterday to say I was off-line I mentioned using a 32 bit field 
in the RTP header for codebook identification.

What we need is an identifier for the codebook used and to an extent 
producing a CRC32 hash seems to fit the bill.  The only problem is CRC32 
is not very collision-proof and I was wondering if as a test it would be 
possible to check, from a large'ish Ogg collection if it was possible to 
generate a list of CRC32 hashes and if there are any duplicates we could 
then check to see if the matching codebooks are the same, or different.

If the matches are the same then this would be great as hash collision 
isn't a problem.  If there are hash clashes with different codebooks, 
and the frequency which this happens is high, then we need to think of 
another way of creating an unique identifier for a codebook, but not 
using a large hash value like MD5.

For codebook transmission I think the best option is by HTTP, for 
reliability reasons.  I think the best way is to have a SDP attribute 
which gives an URI of a codebook package which may contain one or many 
codebooks - which could be all of the codebooks needed for the session life.

An idea is to use a custom VORB RTCP message which can send a message to 
clients to refresh their codebook cache.  This would allow for the 
situation where new files are chained for transmission and the client 
may not have the codebooks cached.

One of  my motivations for having the codebooks sent as a VORB RTCP 
message in the -03 draft was the project we were hoping to use Vorbis 
for was satellite-based.  The AVT-WG did not like this idea as it could 
push the RTCP bandwidth usage above outside its normal range.  To an 
extent I prefer having the main RTP stream to be for data-only.

So, are there sufficient real-world usage scenarios for having an 
unidirectional stream to try and incorporate this feature or should we 
stick with the usage scenario which is bi-directional (which is required 
for client RTCP messages anyway).

-P


Ramón García wrote:

>[Message repeated because it was bounced, apparently because of a DNS update]
>
>This is an attempt to summarize this discussion. I do not want to look
>like an authority to say the final word. This is just the impression
>that one has arrived after listening all of us.
>
>After listening all this discussion, it looks like the best posible
>method is to include in every RTP data packet an identifier of the
>codebook needed for decoding this packet (16 bits or 32 bits) .  As
>Aaron demonstrated, including off-line messages for changing codebooks
>is not reliable, and could lead to wrong decoding. The overhead of a
>codebook identifier is not large taking into account that the RTP
>header already adds 128 bits.
>
>For actual codebook delivery, HTTP is in my opinion the best option.
>The session descriptor should have a pattern that tells how to
>retrieve any codebook giving its identifier. This avoid shipping an
>URL after the codebook changes. HTTP takes advantadge of the
>transparent web proxies already used by most Internet providers.
>
>One drawback of using HTTP is that it does not work with
>unidirectional links. For these cases, a special type of RTP data
>packets can be used. These packets can use marker bit of the RTP
>header to be distingished from other packets. They should be sended
>periodically by the server.
>
>There are some issues that have not yet been discussed enough. Is it
>necessary to provide dynamic changing of sampling rate? How should be
>chained OGG files handled? I think that they should be handled like
>playlists.
>
>Ramon
>_______________________________________________
>xiph-rtp mailing list
>xiph-rtp at xiph.org
>http://lists.xiph.org/mailman/listinfo/xiph-rtp
>
>  
>