[xiph-rtp] Lots of proposals

[David Barrett]

Tor-Einar Jarnbjo wrote:
> David Barrett wrote:
> 
>> I see your concern here, but I don't share it.  Vendor lock-in 
>> generally happens due to proprietary, non-standard extensions -- and 
>> that's not what we have here.  (And incidentally, nothing we say 
>> prevents vendor lock in should a vendor wish it.)
> 
> No, but I was not thinking of incompatibilites built on purpose. If the 
> standard requires a method A for codebook delivery with optional methods 
> B, C, D, E and F, of which one of the optional methods is necessary to 
> make common use of the standard, as method A is not probably not usable, 
> I have no doubt, that this will be a critical problem.

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.

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.

Thus as much as I would like to have a world where all clients support 
all codebook delivery models, I simply don't see that as practical.  So 
I'd much rather take a world where people implement a standard base plus 
some optional standard extensions, rather than a world where people each 
implement a different non-standard subset of some enormous base standard.

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.

That said, I wouldn't be at all opposed to recommendations like "If you 
are building X type of application, you SHOULD support Y codebook 
delivery mechanism".  Just so long as all application types A-Z needn't 
support all codebook delivery mechanisms 0-9.


> I don't know about you, but I tend to use the same client for all 
> thinkable usages for Vorbis over RTP and this client is not "targeting" 
> any special usage model. I doubt that Vorbis will be used for VoIP, as 
> the codec latency is far from ideal.

I apologize; I think I've been speaking inaccurately.

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).  Thus I don't mean to limit my argument to 
Vorbis alone, but rather state generally that Speex, Theora, and Vorbis 
would each be best served by a tight base payload standard, with 
optional codebook delivery extensions.

Thus in my ideal world, there would be the following IETF standards:

1) Theora RTP payload
2) Speex RTP payload
3) Vorbis RTP payload
4...n) Optional codebook delivery extensions (shared by all Xiph codecs)


>> It's not our goal to make all vorbis-enabled products interchangeable, 
>> and it shouldn't be.
> 
> Who are "we"? Can someone from the Xiph confirm that Xiph's attitude on 
> this subject is that there is no interest in enforcing a compatibility 
> between different RTP media servers and clients?

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.

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.

-david