[xiph-rtp] Chaining Theora codebook changes

[Ralph Giles]

On Fri, May 20, 2005 at 02:44:36AM -0700, David Barrett wrote:

> Hi, I'm still getting up to speed on the topic so please forgive my
> ignorance, but does "chaining" mean "changing codebooks on the fly"?
> If so, what is the latest proposal on this?

The idea is to do the same thing as the latest consensus for vorbis. 
That's only documented in the list archives at the moment.

> Looking over the archive, it sounds like:
> 
> - The server CAN specify one or more codebooks URLs in SDP
> - The server CAN specify new codebooks at will inline
> - The server CAN change codebooks at will, and the client MUST accept
> 
> Are these statements true?

well, 'at will' has some caveats, but basically, yes.

> I know the precise language and syntax are in flux, but it sounds like
> each packet will have some kind of variable-length codebook
> identifier, effectively choosing from the codebooks predefined by the
> SDP.  Is this true?  Can I further choose not only from those defined
> in the SDP at the start, but those delivered inline since?

Yes. there's also a proposal for an url construction scheme, so that the 
server can generate new codebooks on the fly outside what's in the SDP 
and the client can construct a url to retrieve them.

> Next, are there any restrictions on what can change with the
> codebook?  Can I change framerates, bitrates, resolutions -- basically
> anything I want to change?

In principle anything in the decoder setup can be changed. I'm not sure 
how things like frame size and rate which have standard representations 
in the SDP would work. It may be some session estabilishment protocols 
will end up placing additional limits.

> Finally, if I have a stream that starts with codebook A, switches to
> B, and then switches back to A, is it assumed that A picks up "where
> it left off", or do I reset the encoder with codebook A?  Is switching
> codebooks (assuming I don't need to re-download them) an expensive
> operation?

Not sure what you mean here. Parsing the codebook does take a little bit 
of time, but should be small compared to frame decode or encode. One can 
also of course cache the parsed codec setup and switch simply by sending 
frames to one context or another.

How the encoder generates a particular set of codebooks could be very 
expensive, of course, if it's tuned to a particular input stream for 
example. It's not a problem on decode.

> Thanks for your clarifications; just trying to make sure I have my
> assumptions in line so I don't march myself into a corner down the
> road.

Sounds like you have it more or less right. The idea is really just to 
support the same chaining you can do with the Ogg container, where 
playback of the concatentation of any two streams must be handled, 
preferrably in as gapless a manner as possible.

 -r