[xiph-rtp] Chaining

[Ralph Giles]

On Sun, Aug 28, 2005 at 06:31:38PM -0700, Aaron Colwell wrote:

> I've spent the weekend thinking over the need for chaining in the RTP spec. I
> may be leaning towards dropping it as well. First, I'll outline the use cases 
> that Real has typically used RTP for. Then I'll describe the Helix rate
> adaptation since Ralph mentioned it in another email. Finally I'll outline
> why we may not want to do chaining after all.

Oh my. :-) Well, it is nice that you've come around to my way of 
thinking on the complexity tradeoff.

In light of this, I'm in favor of reversal. If you still think chaining
support should be in the spec, time to argue for it again. Please 
address the use cases Aaron nicely outlined.

Following discussion on IRC, Aaron and I have the following revised 
proposal. (Please correct me if I got something wrong or leave something
out.)

A given RTP session has only one corresponding info and setup header 
pair. There's no longer need for a chain id, so we're back to a 
single-byte rtp payload header:

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|F|R| # pkts. |     for vorbis.
+-+-+-+-+-+-+-+-+

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|F|RR |# pkts.|     for theora.
+-+-+-+-+-+-+-+-+

After which the payload is the normal packet data as expected by the 
respective decoders.

The reserved bits must be zero to comply with this specification,
and the C,F flags use the improved semantics as we agreed earlier
on the list.

A note should be added explaining that we consided a decoder 
configuration id in the payload header to allow support of
the "chaining" feature of Ogg bitstreams, but it was rejected
because of complexity.

(We could obviously use the reserved bits to add the chain id
 back in as an optional field if we ever change our minds).

And that's that, really. Luca's job just got easier. :)

Luca, I'd like to see a revised draft based on the above ASAP.

If you want, it would also be reasonable to do one based on the old 
32-bit payload header if we get lots of objections, or if you're
almost done with it anyway. :-) 

 -r