[xiph-rtp] Lots of proposals

[David Barrett]

Ralph Giles wrote:
> On Tue, Aug 30, 2005 at 02:06:56PM -0700, David Barrett wrote:
> 
>>Ok, so are you suggesting the baseline vorbis-rtp draft include basic 
>>inline codebook transmission (which is adequate for all cases, but 
>>non-optimal for many), but no out-of-band systems, and no 
>>acknowledge/retransmit RTCP profile?
> 
> So if we do this, does every packet have a codebook id field, or
> none, with the plan being to use the Reserved flag to indicate
> it's presense in said later drafts?

Good question.

The question of which codebook delivery methods to use is entirely 
independent from the question of whether to support chaining.  Even if 
we never go beyond the baseline codebook delivery method (inline without 
retransmit/acknowledgement), the baseline method is entirely sufficient 
to support chaining (especially for files, which are lossless).

Furthermore, all codebook delivery options are valid, irrespective of 
whether or not chaining is supported.  None of the codebook delivery 
options makes the problems associated with chaining better or worse.

Thus I'd say if we ever intend to support chaining, it the one byte 
header should be there from the start, else it shouldn't ever be there.


So at this point, if I could have my choice, I'd say:

- Yes vorbis-rtp supports chaining, through a one-byte codebookID field 
in the header.
- The only codebook mechanism supported by the baseline spec is inline 
delivery, without ack/retransmit.
- Additional codebook delivery mechanisms are documented in subsequent 
drafts; the SDP indicates which the server/client supports.
- A stream can support up to 255 codebooks over its lifetime.

However, I do see the problems associated with chaining, as Aaron 
pointed out.

> There are several problems with allowing chaining to be supported in a general
> sense.
> 
> - The client has no way to determine if it can actually play the stream
>   properly... 
> 
> - The server might guess a bad value for the RTP timestamp sample rate...
> 
> - Managing coordination of codebook downloads in the middle of playback is
>   non-trivial...

However, the first could be handled in SDP (ie, when negotiating the 
media types, you negotiate all codebooks types you intend to use, up 
front).  The second could be handled by stating that all chains must use 
the same timestamp sample rate.  (Prevents chaining of different 
timestamp sample rates, but at least it doesn't prevent chaining 
altogether.)  And the third is the cost of doing business.

Furthermore, I'm assuming a single stream can't switch codecs (ie, from 
Theora to MPEG); it can merely swich codebooks within a single codec 
(ie, Theora, Speex, etc).

-david