[xiph-rtp] Chaining

[David Barrett]

Oh, that's unfortunate.  I'd come to depend on the chaining feature to 
support adaptive encoding (a rather important feature in my product).

My reason is as follows: in a P2P scenario, setting up connections is 
incredibly time consuming and unreliable.*  Once a connection works, I'm 
loathe to kill and re-create it.  Furthermore, "session establishment" 
and "session send/recv" are actually quite far apart in the code.  It 
was nice negotiating an entire set of codebooks exactly once, during 
session initialization.  I'm not eager to trigger a SIP/RTP 
re-negotiation each time I want to change my broadcast settings (a 
reasonably frequent activity in my app).

* Granted, if the new connection uses same endpoints it's less painful, 
but it's still not fun.

However, I could just be misunderstanding this.  Here's what I'm 
currently doing -- could you please summarize for me how this latest 
change affects my approach?

1) Broadcaster sends SDP in SIP INVITE describing the codebooks I want 
to to broadcast
2) Receiver sends ACK and obtains codebooks (HTTP, cache, generate, etc)
3) Receiver prepares to receive RTP using listed codebooks
4) Broadcaster picks initial codebook and begins broadcasting
5) Broadcaster wishes to change settings (resolution, encoding quality, 
framerate)
6) Broadcaster resets encoder using new codebook, broadcasts using new 
chainID
7) Receiver notices the new chainID, resets decoder with new codebook
8) Receiver has seamlessly begun decoding with new settings, within the 
span of a single frame.

One option would be to pre-establish several RTP sessions and just stop 
broadcasting on one and start broadcasting on the other.  Another option 
is to re-INVITE the existing SIP session with the new parameters.  But 
neither are as seamless and elegant as the chaining solution.

Perhaps I just don't see the complexity introduced by chaining.  I do 
see the complexity of inline and HTTP codebook transmission, but these 
aren't what are being removed/redesigned.  I guess the SDP syntax is a 
bit complicated to set up the chains (chainID->codebook mapping), but is 
that it?  Where is the complexity that forces the dropping of this feature?

-david

(Again, sorry for falling behind if I'm missing this obvious point.)

Ralph Giles wrote:
> On Mon, Aug 29, 2005 at 12:50:06PM -0700, David Barrett wrote:
> 
> 
>>Can you give a 20-second review of what all this means to those of us 
>>(ie, me) who haven't followed the issue closely?  Specifically:
>>
>>1) What is the difference between "chaining" and "inline codebook 
>>transmission"?  It sounds like you're de-supporting the former while 
>>retaining the latter.
> 
> 
> Chaining means switching between multiple decoder configs within a 
> single RTP session. Inline codebook transmission just means that
> the decoder may receive its configuration data as packets send at
> the beginning of the RTP stream as well as through some out of band
> method. It's the simplest option, and the only one is some applications.
> 
> Chaining might still be possible with inline codebook transmission;
> the problem is RTP packets are usually sent without delivery guarantees, 
> so if the SDP only defines one sent, you can't transition reliably,
> and the decoder may suddenly start producing garbage drop in the middle
> of the stream.
> 
> In a multicast setting, there's no also way to syncronize the change. 
> (Maybe you could use different SSRC id's to mark the distinction?)
> 
> 
>>2) What's the latest on the "codebook ID" member of the Theora RTP 
>>header?  It sounds like you're suggesting the whole RTP header is just a 
>>single byte -- wasn't there a field that associated each packet with a 
>>specific codebook (so the SDP could define a codebook library using HTTP 
>>downloads, and the session could switch back and forth on a per-packet 
>>basis)?
> 
> 
> That's the main change; we've done away with that field because there's 
> only one codebook option--nothing to choose to between.
> 
> 
>>3) You said "A given RTP session has only one corresponding info and 
>>setup header pair": what's a "setup header"?  I thought there were 
>>"info", "command", and "tables" headers, which together comprise the 
>>"codebook".  Is this changing, or am I just misunderstanding something?
> 
> 
> The vorbis and theora codecs have three required headers that configure 
> their decoders. Their specifications call them the 'info, comment (or 
> metadata), and setup (or codebook)' header packets. collectively they're
> often referred to as "the codebooks". The 'info' and 'setup' headers are 
> required for meaningful decode of data packets. The comment header is 
> required by the spec, but not necessary on technical grounds.
>  
> 
>>If there's only one per session, does this mean codebook changing has 
>>been de-supported as well?
> 
> 
> That's that same as "chaining" so yes it would no longer be supported.
> 
> If you want to change the codebooks, you must get the player a new
> SDP and or otherwise open a new RTP connection. A stack of rtsp: 
> playlist entries would work fine, for example.
> 
> Hope that clarification helps,
> 
>  -r
> 
>