[xiph-rtp] Interesting post on AVT list

[Aaron Colwell]

On Wed, Sep 07, 2005 at 01:35:15PM -0700, David Barrett wrote:

> 
> >>	2) If it is, can new codebooks be delivered on the fly?
> >
> >Does this mean a new codebook that wasn't known about at SDP generation 
> >time?
> >If so then this potentially causes a problem where a codebook shows up that
> >the client doesn't have resources to support. The server may not be in the
> >position to determine whether the client can support the new codebook or 
> >not.
> >I think the codebooks that are availble for switching should be negotiated 
> >up
> >front.
> 
> I certainly agree this is a possibility.  I'd say:
> 
> Servers SHOULD define all codebooks at SDP generation time.  But servers 
> CAN send new codebooks at any time, and clients SHOULD support all 
> codebooks if possible.  Packets encoded in a codebook the client cannot 
> support MUST be dropped.
> 
> Thus servers seeking maximum compatibility across the broadest range of 
> devices would pre-negotiate all codebooks up front.  But servers that 
> know their clients can handle the full range of codebooks should have 
> the option of sending them "just in time".

This sounds reasonable to me.

> 
> To give a real-world example, I do live videoconferencing using Theora, 
> and I'd like to adjust the frame size depending on the size of the 
> playback window (ie, if it's full screen, send a big feed, if it's a 
> thumnail, send a small one, and anywhere in between).  Thus rather than 
> pre-generating every possible codebook and sending over up front, I'd 
> like to generate codebooks "just in time" and send as needed.

This actually brings up another "issue". In the case you described above
you technically only need to update the ident header and could use the same
codebook. Do we want to provide a way of indicating that some headers for a
new "codebook ID" are the same as another "codebook ID". The way we have things
now the answer seems to be no. I'm only asking because you could potentially
avoid sending the codebook over and over again if you decide to keep changing
the frame size.
 
> 
> I certainly agree (and I'd like to hear the final logic on this, if 
> anyone knows it) that codebooks are a *big immediate cost* for only a 
> potential future gain.  Has anyone done a rigorous cost/benefit analysis 
> demonstrating the value of dynamic codebooks?

I agree. I'd be interested in seeing hard stats on what changes have been made
to the Vorbis codebooks since it was initially release and how much gain
has been realized.

> 
> Regardless, I'm accepting for the sake of progress that dynamic 
> codebooks are they way it is.

Me too.

Aaron