[xiph-rtp] Lots of proposals
Tor-Einar at Jarnbjo.de
Thu Sep 1 14:20:51 PDT 2005
David Barrett wrote:
> (I'm assuming you meant to post this to the list; I apologize in
> advance if I assumed wrong.)
Of course, my mistake.
> 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.
> What we have are usage models that call for different codebook
> delivery techniques. I would imagine that all client/servers
> targeting the same usage model would tend toward the same codebook
> delivery technique. For example, web radio servers would use the same
> technique, and thus they would all be compatible. All VoIP techniques
> would use the same technique, and thus they would all be compatible.
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.
> Now I'll grant it's possible that VoIP and web-radio would do codebook
> delivery different, but they do *everything* different. It's not like
> if only they used the same codebook delivery technique they'd be
> compatible -- they'll never be compatible, no matter what we say,
> because they're totally different products.
Where do you get these ideas from? I have no problem at the moment to
use one client to listen to most of the webradios out there, no matter
if they use HTTP or RTP as transport for their content and no matter
which radio is broadcasting. The ones using Vorbis are limited to HTTP,
but isn't the point of getting a standard for Vorbis over RTP, that a.o.
web radios can be able to use the standard? Is it realistic to assume,
that all the web radios transmitting Vorbis over HTTP at the moment with
all compatible clients will switch to another protocol without being
sure that their listeners can continue using mostly the same software?
> 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?
More information about the xiph-rtp