[xiph-rtp] Lots of proposals
Tor-Einar at Jarnbjo.de
Thu Sep 1 16:21:24 PDT 2005
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
> 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
> 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
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
More information about the xiph-rtp