...is at the top of the first Opus/CELT demo page:

http://people.xiph.org/~xiphmont/demo/celt/demo.html

The low latency makes more interactive applications possible. By way of illustration, the total algorithmic delay of an Opus or CELT stream is approximately equivalent to the time it takes sound to travel from you to someone standing five feet away.

As a Theora developer, this is news to me. Would you mind mentioning who this buddy is so I can go back through my mail queue and verify that you're just making shit up?

I know you're lying, as regardless of what our response would have been it most certainly would _not_ have been, "ssshhh don't tell anyone".

This whole thing is really about bad blood between Xiph and the mplayer folks. Once, long ago, I made disparaging remarks about a particular mplayer developer's extensive collection of ass hats, and they declared war. This stopped being about facts or reason years ago. Here's the last blog thread that got completely hijacked by the anti-Ogg container wingnuts. It's a hell of a read:

http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/

So, rehashing this yet again: The Anti-Ogg bullet points [Not going to bother with complete sentences, because I've wasted too much typing on this recently]:

1) A few of the mplayer/x264 hackers are right pissed that Ogg and Theora are getting all this attention when x264 is so obviously superior. That simply cannot stand. Since only America has patents and there are no computers there anyway, nobody should have to worry about them. Stick it to The Man! (How very ironic, Xiph being considered 'The Man' by folks contributing to an h264 encoder).

2) Xiph should immediately drop Ogg for [insert container here], breaking millions of hardware decoders and hundreds of millions of software decoders:

    a) the [patented] mp4/MOV container is one suggestion they actually make seriously. Never mind adding 'willful infringement' to breaking the entire installed software/hardware base, this choice would totally redeem Xiph in their eyes. The benefit: by their own figures, it would reduce container overhead from .7% to .3%.

    (Except that number is wrong. I found later that DonDiego screwed up his mp4 overhead figures at the link above; I had simply assumed he got his container numbers right. The mp4 file in his example has almost identical container overhead to the Ogg, a shade under 1%. His demultiplexed mpeg audio and video had framing in them, so it made it appear the mp4 container overhead was much smaller when he subtracted their file sizes.)

    b) OK, mp4 is patented and no better, fine, Xiph should have just used Matroska from the beginning. Despite the fact that Ogg and Vorbis predated it by about five years (also mkv's not been able to interleave until just recently, which == no streaming). This is not to say you can't put Theora and Vorbis in Matroska. It's even a good idea! I've come to like MKV. But for streaming, Ogg is still much easier to deal with. Ogg was designed to stream, mkv was not.

    c) OK, so, mp4 and Matroska are right out for streaming, Xiph should use Nut, which is the system they designed. Nut came ten years after Ogg was already widespread. And looks almost exactly like Ogg. Which is not to say there aren't things about it I like that improved on the Ogg approach. Eg, the packet length encoding is better. It has a conditional checksum coverage feature I had never considered, etc. At some point we'll make those changes when that wouldn't mean completely abandoning any chance we have at adoption just to save a fraction of a percent and add... no new features.

    d) but.. but.. even FLV is better! OK, at this point I can't even entertain the arguement.

3) OK, maybe not adopt another container, but Xiph should immediately improve/change Ogg for, breaking millions of hardware decoders and hundreds of millions of software decoders for a 'better' implementation that won't actually give users any features they don't have now. FOSS need _tools_, not us wasting time overoptimizing something they couldn't care less about.

3) 64 bit timestamp! OMG, waste! Wait, mov/mp4 uses 64 bit stamps... Also, plenty of things in Ogg use a full byte instead of one bit because the container assumes octet alignment. Alignment makes it much faster/easier to deal with (you don't need a bitpacker to read pages, and you don't have to repack packet data to embed it into the page). Remember, all the completely unacceptable waste adds up to about .4% of the bitstream [except those numbers were wrong and it wasn't that much anyway].

4) [Someone actually accused me of this one verbatim!] Xiph is cramming Ogg down our throats so they can control us! ...using an open, documented, published, unencumbered container format on which Xiph reserves no rights or control.

OK, this is getting long...

Here's a bombshell in all caps: OGG COULD BE IMPROVED. Gasp! It sure as Hell could be. Or rather, could have been and will be in the future at some point. I'm a little surprised that no one saw fit to suggest improvements until now. It's been documented and used for twelve years. It seems odd to wait that long to suddenly alert the world that it's suddenly the worst thing ever created. Despite the fact that no one else really seems to have any problem with it.

But that said, most of the argument against Ogg really does consist of "I would not have designed it that way" and "how dare you not take my advice". The simple fact is there are a couple places where they're right-- and a whole bunch more where they're suggesting changes that improve nothing. It's also too late to change anything (for now) for completely negligable benefits that no user would notice or care about in the slightest. When could improvements happen? Possibly at the next major new codec rollout, when the whole world would want to upgrade anyway (eg, if and when Ghost sees release).

But yeah, that's not acceptable or sensible and we're totally out of control Nazi design pigs for not immediately apologizing to MPEG and retracting all our software. We suck!

I'm not worried about there being a ton of later comparisons as Theora continues to improve :-)

In general, we recommend people not use non-default settings with our codecs. Unlike many other projects, we put effort into making sure the defaults are correct.

That said, this is one case where the Theora default was suboptimal because it was the wrong use case. We need to reword the way these options are specified. For bitrate manged modes, there's two common ways to use them: Very tightly constrained rate for a fixed-rate channel (like ISDN or low-rate DSL) and a more relaxed management that is simply trying to hit some size over the space of the whole movie (usually a two-pass mode, fit-a-DVD-on-a-CD type use). Right now, the Theora tools all do the first and that's how your test was performed. The h264 was encoded with the second. So that's a penalty to the constrained encoder.

VBR vs VBR is a more accurate direct test of encoder capability. Don't get me wrong, x264 is going to win that test too, just not by as much.

Only one point I wanted to mention (since the article and comments have all been--- oddly balanced for Slashdot)

The article points out that current Thusnelda is not as high quality as the best available h264 encoder at high bitrate video and unlimited encoding time. No argument there, it's true. Thusnelda still has a ways to go, despite the distance it's come; the current alpha still has no Adaptive Quant whatsoever, which will go in before final release.

However, the vast majority of users are not using x264. If you look at the h264 YouTube encoder, which has been designed for speed rather than 'work as long as you like to optimize the output', suddenly Theora is exactly on-par. In short--- Theora is every bit as good as the way that the real world is going to end up using h264 for the forseeable future. And the users of that 'inferior' h264 encoder seem pretty happy with it.

Anyway, this isn't disagreeing with anything you've said, it's simply a practical way to look at the difference.

Monty

Uh, that version is also six months old. We're talking about *new*, remember? Not last thanksgiving before any version of Thusnelda was even released.

"Ogg" is actually a term from an early internet game.

http://en.wikipedia.org/wiki/Ogging

Theora is named after Theora Jones, a secondary heroine character from the movie 'Max Headroom: 20 Minutes into the Future' about a dystopian future where video media is overwhelming, centralized, oppressive, dangerous, and an off switch on a television is illegal:

http://en.wikipedia.org/wiki/Theora_Jones#Theora_Jones

"Xiph" is actually from the Greek ξÎÏÎÏ (sword) by way of 'Xiphophorus' (sword-bearing, pseudolatin?) from the genus name of a fish (Xiphophorus helleri). Which is where I picked it up in middle school. I'd been using it for my software projects since I was 14 or so and by the time Xiph.Org was a real thing [many many years later] I wanted to change the name to something less silly and my co-founders voted me down. They liked Xiph. It became the precedent-setting silly name.

Vorbis is from Terry Pratchett's _Small Gods_ and I dearly hope Mr. Pratchett considers it a compliment. It was meant as tribute to my favorite fictional villain, Archdeacon Vorbis. "A mind like a steel marble"

Well, one tester (and Greg's graph was generated to rebut his graph) was converting each output frame to PNG and then feeding them into one of a number of PSNR tools one by one to get a PSNR result. The conversion from YCb'Cr' to RGB is lossy, but apparently this particular author didn't know that.

He was also using multiple PSNR tools because some were mysteriously not working with some video inputs. Given that there's no one standardized way to calculate PSNR, that led to additional data lulz.

And for x264, he apparently didn't generate his own numbers, he just used someone else's published numbers.

Anyhow, He reported that x264 was 30-ishdB (!) better than Theora. Wha? If every Theora frame was black, that still wouldn't account for that much difference. YUV12 is only 40-45dB deep!

In other words, the whole point of the graph was originally to illustrate and rebut these errors, and it turned out to be a nice regression test too.

Also, for the record, the x264 curve is not perfectly smooth, but that it's as smooth as it is attests to the fact that it's a nicely tuned codec. That Theora is lumpier is one indication it still has more tuning to be done.

Also, Greg's response below is way more levelheaded than mine. He actually collected the data himself (so has more detailed, accurate and first-hand knowledge) and he also probably hasn't been drinking whiskey all night.