[xiph-rtp] Lots of proposals
dbarrett at quinthar.com
Thu Sep 1 15:47:56 PDT 2005
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
More information about the xiph-rtp