[xiph-rtp] Lots of proposals

[Tor-Einar Jarnbjo]

David Barrett wrote:

> Ok, yes, I see this concern.  Any protocol with optional extensions 
> necessarily runs the risk that two similar clients/servers decide to 
> implement different optional extensions, and that's a problem.

I agree with you on this,

> However, the only way to mitigate that risk is to assert that all 
> clients/servers MUST support all codebook delivery methods.  But there 
> are so many options, and they are so dependent on the particular usage 
> model, that I'm afraid (or rather, expect) people will only implement 
> the non-standard subset that is relevant to their specific usage model.

but disagree here. Are there really that many usage models for which 
Vorbis over RTP is a feasible protocol? I am not sure about Theora, but 
Vorbis is IMHO not usable for scenarios requiring a low latency, which 
includes VoIP and conferencing applications. I might have missed some of 
your opinions on this, but what are your concerns against HTTP and a 
separate RTP stream as not only the two mandatory delivery methods among 
several optional, but as the only two delivery methods defined? The 
implementation will of course be slightly more complicated, but it is 
not exactly rocket science to implement a minimalistic HTTP stack able 
to handle codebook delivery and/or use an HTTP client library on the 
client side.

> In other words, I believe it's inevitable for different 
> clients/servers to support different codebook delivery methods, and I 
> propose the best way to handle this unfortunate situation is with base 
> RTP payload standards for Theora, Speex, and Vorbis, and then optional 
> codebook delivery specifications on top of that, shared by all.

Is this problem really relevant for Speex? I am not 100% into the stream 
definition, but I was pretty sure that Speex does not require reliable 
delivery of any part of the stream.

> It's my impression that all Xiph codecs (Vorbis, Theora, and Speex) 
> have the exact same codebook delivery problem (too many options, too 
> little time to build them all).

I'm not very familiar with Theora and Speex, but to be honest, it is my 
impression that Xiph built Ogg and Vorbis far too complex and without 
much respect to existing standards, common practice and media codecs. 
Chaining and dynamic codebooks probably beeing the two most adventurous 
features. This makes it difficult to integrate Ogg/Vorbis into commonly 
used media frameworks like Quicktime or Windows Media, or to pack a 
Vorbis stream into other containers than Ogg, as which RTP may be 
considered in this sense.

> That's fair, I'm only speaking my opinion as one avid user of Theora 
> and Speex over RTP.  And I'm not sure who comprises "Xiph", but I know 
> I don't in any official capacity.

Neither am I, but have you ever seen any software writing Ogg/Vorbis 
files, which can not be read by any other software which supports 
reading Ogg/Vorbis files? I think this is a very perfect analogy to RTP 
servers (producing Vorbis streams) and RTP clients (consuming Vorbis 
streams).

> However, even if there is *interest* in enforcing compatibility, I 
> question if there's the *capability* to do so.  If the base standard 
> mandates that adopters create technology that's wholly inappropriate 
> for their usage model (such as forcing my VoIP application to support 
> multicast codebook delivery), I think it's just begging for incomplete 
> implementations. 

Well, the RTP draft for Vorbis has been around for a couple of years 
now, so I don't see any point in rushing to get an unusable RFC through 
the clearing process. If it takes more effort to complete a usable RFC 
now than there is available capacity, why not wait? I already have quite 
a lot of code snippets laying around waiting for an acceptable RFC to be 
finished, so a reference implementation can be put together with not too 
much effort.

Tor