[xiph-rtp] Lots of proposals

[David Barrett]

Tor-Einar Jarnbjo wrote:
> David Barrett wrote:
> 
>> Well to start, if you're delivering RTP via a lossless channel (over 
>> TCP, or in a file) then the baseline works just fine and I'd stick 
>> with that.
> 
> It would, but you are not guaranteed that RTP is transmitted over a 
> lossless channel, in most practical implementations it is not and I 
> can't image that IETF will approve an RFC for an RTP based protocol 
> which requires a lossless transport mechanism.

Yes, I agree entirely; I was just mentioning this as one area where 
baseline vorbis-rtp works without trouble.  I agree, it's a corner case.


> Depending on the codebook size and available bandwidth, it would not be 
> practiable with such tight intervals, as the codebooks will consume too 
> much bandwidth. I assume that you in this case would start to transmit 
> audio data shortly after transmitting the first codebook burst. If the 
> first receptions of the codebook are failing, the client would either 
> have to cache audio data or skip the beginning of the stream. If joining 
> e.g. a radio channel, that might not be a problem, but if you order a 
> song "on demand", skipping the first few seconds of the song is probably 
> not what you expected and e.g. a mobile player will likely not have too 
> much memory to waste for an audio cache.

Again, I agree 100%.  I totally agree the baseline has a number of 
disadvantages for streaming broadcast scenarios.  I merely state that 
there is no single improvement on it that works in all situations.  Thus 
I'm just endorsing Luca's proposal that the baseline be separated from 
the optional codebook delivery mechanisms, leaving it up to the 
broadcaster/receiver to negotiate the best way to deliver codebooks.


> I'm not really convinced. Using FEC has already been discussed as a 
> solution, and if inband RTP transmission of the codebook header is to be 
> the generic "compatible base" with only optional alternatives, I would 
> rather go for an attempt to achieve a robust transmission of the 
> codebook header using FEC encoding. There is still a chance that the 
> client fails to receive the codebook header, but in that case, packet 
> loss will probably be too high for the client to stream at all. A nice 
> side effect would of course be that also the audio stream itself with 
> little effort could be secured against packet loss using FEC as well.

Forward error correction is another fine optional delivery mechanism, 
and I'd add it to the list.  But I don't believe it's practical or 
necessary to mandate that *all* recievers MUST support FEC, any more 
than that all MUST support multicast codebook delivery.

Standards are best when they focus on areas of agreement.  The baseline 
spec is identical for all situations.  But codebook delivery depends 
heavily on the usage model, and thus I think it's reasonable to split it 
out and leave it up to the developers to pick the best one.

-david

PS: Sorry for the explosion of posts today.  This is just an issue that 
happens to directly impact my current use of Theora.