[xiph-rtp] Interesting post on AVT list

[David Barrett]

Aaron Colwell wrote:
> Can we please use a different term than "chaining". Chaining refers to an
> Ogg concept that can't be fully supported inside an RTP session. Perhaps
> "codebook switching" should be a better term.

Good idea; "codebook switching" is much more accurate and intuitive.


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

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.


> The client also has to manage it's own resources and only try to play something
> it knows it can play. The server is in no position to make this decision.

True.  It's not without cost for the client.


>>Personally, I think the ability to change the parameters mid-stream 
>>without the overhead of a total stream negotiation is a nice advantage 
>>of the Xiph codecs.  This in fact could be a selling point for streaming 
>>situations where high-level adaptive encoding is valuable.
> 
> Many video codecs (H.263+, MPEG4, RV, WMV) at least have this ability without
> the  need to negotiate different codebooks. It is yet to be proven that there
> are significant gains to be had for different codebook selections. That is
> a seperate discussion though. I'm only pointing out that this funtionality has
> been supported without the need to reliably transmit large chunks of codebook
> data.

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?

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


> It seems strange to me that implementations ignore a MUST inside a standard. 
> I don't think we should bow to SIP implementations that aren't RFC compliant.
> With that said though, I agree that we should probably still have a solution
> for UDP.

I'll ask around the SIP/P2P community and see if my initial impression 
is right.  As for the SIP/TCP requirement, that was actually added quite 
late (it was originally optional) so I'm not sure to what degree very 
old or very new implementations support it.

-david