[xiph-rtp] Theora RTP payload format

[Steve Kann]

Ralph Giles wrote:

>On Mon, Apr 18, 2005 at 03:13:19PM -0400, Steve Kann wrote:
>
>  
>
>>In one particular use case, (off-line encoding to .ogg files), all this 
>>isn't much of a headache. But for use-cases like this, and perhaps for 
>>many others, this is quite a headache. For example, If I had all this 
>>working with h.263 (or h.264), and I wanted to switch to theora, it 
>>would be quite a job, because compared to the design of most video 
>>codecs, theora is a square peg when you might have a round hole..
>>    
>>
>
>Yes, this is all about the configuration header which is different from 
>the way way most other codecs are designed. (Or, as Aaron points 
>out, the configuration being more than frame size and rate.) The Vorbis 
>audio codec has all the same issues.
>
>Our motivation here was the longevity of the baseline jpeg image format,
>still an excellent choice 15 years after it was first developed. We 
>didn't think we could be equally well tuned in our first release, so
>we designed the format so encoders could have maximum flexibility 
>without having the upgrade the installed base of decoders.
>
>It may be that we've bet wrong. Much of the world hasn't seemed to mind 
>upgrading repeatedly for each new incompatible iteration of the 'Windows 
>Media' format, or "AAC" or even "MPEG-4 video", perhaps because OS 
>vendors are shipping the upgrades as a normal part of their systems. So 
>longevity (of the codec, not the brand) hasn't been an issue in the last 
>couple of years.
>
>  
>
I buy it, but I think that there might be some compromise that's possible:

1) Include in Theora I a set of predefined codebooks. (This set might be 
1 right now, I'm not sure..).

2) Include these codebooks in the specifications for decoders;

3) ALSO include in the specifications for decoders the ability to load 
new codebooks, etc, dynamically, as they do now.

Then, when, encoding, you have choices, you can choose to use a 
predefined codebook, and then operate more or less like other codecs do, 
or you can have the ability to use new and optimized codebooks.

It doesn't limit any uses at all to offer this, but it does give you the 
ability to operate the encoder in the predefined codebook mode, without 
needing to go through the whole codebook transfer mode.

Then, if newer/better codebooks are developed (say, for Theora 1.2), you 
have a choice about whether you want the encoder to use these as 
predefined codebooks or not. If you choose not to, then you can still 
use them as "dynamic codebooks", and have lost nothing in compatibility.

>>Absolutely, it would be much easier to do, if I could just use the 
>>theora implementation with fixed codebooks, and not have to worry about 
>>any of this stuff. If VP3 codebooks were an option, that would be 
>>excellent.
>>    
>>
>
>So we could use one of the 8 reserved bits in my 32-bit aligned payload 
>header proposal to mark something like this. I remain unconvinced of the 
>value though.
>  
>
>In regards to instructing the encoder on what decoder setup to use, 
>Derf's experimental encoder already supports this, and it's on the list 
>for the revised reference encoder api. So while you can't do this now 
>without some hacking, you should be able to in the future, including
>configuring the encoder from a set of codebooks pulled from another 
>stream.
>  
>
That sounds interesting.. I do plan to experiment with some of the 
experimental work out there; The theora-mmx branch looks interesting, 
because presently performance is really just barely adequate for 
real-time conferencing. Of the other open-source (but not patent-free) 
encoders out there, it seems that ffmpeg (for any of it's mpeg/h263 
variants) and x264 really blow theora away at the moment.

-SteveK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/xiph-rtp/attachments/20050418/38d2b2e0/attachment.htm