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

Tue Nov 9 09:33:46 PST 2004

On Tue, Nov 09, 2004 at 02:27:45PM +0000, Phil Kerr wrote:
> 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.

Is this CRC intended to be put in every packet or only in packets that
contain the codebook URL? If the intent is to put it in every packet, I still
think that my stream group ID idea is better because then you don't waste bits
in every packet when chaining is not even used. If it is intended to go in
the periodic URL transmissions, then I'd just prefer using MD5 just so we
don't have to worry about the "is this hash function good enough" issue.
These packets would likely have a low packet rate so the extra bits shouldn't
significantly contribute to overall bitrate. I don't really have a strong
opinion either way between MD5 and CRC32.

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

I agree that HTTP should be the normal method of HTTP retrieval. Personally
I think that the codebooks should be kept seperate so that the client only
has to download what it needs. The SDP could contain a list of URLs or the
URLs could just be transmitted within RTP packets. Personally I prefer having
the URLs in the RTP packets so that simulated live streams have a simple way
to notify the client that it will need new codebooks that it didn't know about
at SDP generation time. 

I also think that codebooks should be allowed to be transmitted in the RTP
channel. My main reasoning for this is to support 1-way multicast broadcasts.

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

I renew my objection to putting stuff in the RTCP channel. I agree with the 
AVT-WG concerns and I don't believe it belongs in the control channel. You
can't decode any of the bitstream without the codebook so in my mind that means
that it actually IS part of the data stream. There are also no transmission
restrictions in the RTP channel but there are restrictions on the RTCP
channel. If you want an example of control data being transmitted in the
RTP data stream, look at the MP4-LATM RTP payload format. It allows inline
codec configuration information to be transmitted in the RTP stream.

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

The main use case that I know RealNetworks has worked with is satellite 
content distribution. TV stations usually record programming at specific 
times off of satellite feeds. This allows a convenient way to send one 
transmission to many people at once. The same can be done for digital content
delivery. Content could be embedded in the satellite MPEG2 streams and 
broadcast over existing satellite infastructure. There is no backchannel 
because the satellite system is a unidirectional system. The receiver might
also have no form of Internet connectivity other than what it gets over the
satellite. 

Aaron

> 
> -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
> >
> > 
> >
> 
> _______________________________________________
> xiph-rtp mailing list
> xiph-rtp at xiph.org
> http://lists.xiph.org/mailman/listinfo/xiph-rtp
> 