<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Ralph Giles wrote:
<blockquote cite="mid20050418205013.GA22972@ghostscript.com" type="cite">
<pre wrap="">On Mon, Apr 18, 2005 at 03:13:19PM -0400, Steve Kann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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..
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
I buy it, but I think that there might be some compromise that's
possible:<br>
<br>
1) Include in Theora I a set of predefined codebooks. (This set might
be 1 right now, I'm not sure..). <br>
<br>
2) Include these codebooks in the specifications for decoders;<br>
<br>
3) ALSO include in the specifications for decoders the ability to load
new codebooks, etc, dynamically, as they do now.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
<blockquote cite="mid20050418205013.GA22972@ghostscript.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<blockquote cite="mid20050418205013.GA22972@ghostscript.com" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
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. <br>
<br>
-SteveK<br>
</body>
</html>