[xiph-rtp] Theora RTP payload format

[Steve Kann]

Ralph Giles wrote:

>On Mon, Apr 18, 2005 at 01:50:13PM -0700, Ralph Giles wrote:
>  
>
>Our concern with defining profiles, like the 'VP3' bit I suggested has 
>always been encouraging inoperable implementations that only support 
>that profile. "profiles are useless" has been a common lesson of many 
>specification designs. They make committee decisions easier, but then 
>end you either implement the de facto standard or you don't. Those are 
>the main reasons I remain unconvinced.
>  
>
Maybe my case is an outlier, and maybe I'm just lazy :), but for this 
situation, a fixed codebook would make life a lot easier. Since the 
application is videoconferencing, the fact that the encoding format 
would be (at the moment) limited to a fixed codebook would not affect 
future decoders, and I would be keeping the on-disk recordings in a 
format which does include the codebooks (*).

At some point in the future, when better codebooks are developed, we can 
improve the conferencing engine and such to support them, without 
changing anything about the decoders.

>Note also that while the chain id lets you multiplex streams from 
>encoders using a different setup, you don't have to do it that way.
>Your application might be better served by mandating that everyone
>use the same profile and then not worry about chaining at all. That's 
>more like the situation you have with fixed setup codecs.
>  
>
And this would work for me, given an API to force the decoders to do 
this. (presently, I think it will happen automatically, given all the 
same parameters).

>I hope that explains the design reasoning a bit better, and why we've 
>been resistent to things like static codebook sets. We do very much 
>appreciate your opinion and contribution to the design discussion and 
>are very willing to help you figure out what needs to be done to make 
>your implementation work well.
>  
>
Thanks so much for your thoughtful responses.

(*) Speaking of that format, one of the things that I've been pondering 
is whether to use ogg as that format at all; The problem that ogg does 
not solve that I'd like to solve in my on-disk format is I'd like the 
format to be able to store a "lost frame" as a lost frame. In other 
words, there is a VoIP client that is sending Speex via some unreliable 
protocol. At the receive end, we see 10% packet loss. I'd like to the 
file format to store the speex frames like this: 1 2 3 4 5 . 7 8 . 10 
(with frames 6, 9 noted as "missing"), such that at playback time, I can 
interpolate for those lost frames just like we would do if they were 
played in real-time. I guess this is another thread to discuss somewhere 
else, though :)