Diary Of An x264 Developer

I'm pretty sure h264 is the superior codec in all regards except for that pesky license issue. It encodes faster and creates smaller files that look better. From (lead x264 developer and HN user) DarkShikari[1]:

"Overall, VP8 appears to be significantly weaker than H.264 compression-wise. The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264. Of course, this is still significantly better than Theora, and in my tests it beats Dirac quite handily as well.

...

Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder..."

I won't pretend to know what all of those terms mean off the top of my head, but if the lead x264 developer sees absolutely no technical advantage in WebM vs. h264, that sounds pretty damning to me.

As for why x264 encodes h264 so much faster than ffmpeg or whatever encodes WebM, the simplest explanation would be that there is much greater demand for an optimized h264 encoder. WebM has some admittedly large users (Wikimedia Foundation, Youtube for browsers with no h264 support and no flash player, and now 4chan), but they're still vanishingly small in comparison to the users of h264…

Your interpretation doesn't match those of people who have analyzed it. The problem with WebM is that it may infringe on H264 patents! And its not clear they have done enough to avoid the problems. H264 has come together to form a very strong patent pool. None of the patents can be asserted against H264 (nor can the partner companies in general), but any of them can be asserted against WebM.

Read JGG's account, which is still the best account to date at:
http://x264dev.multimedia.cx/archives/377

Some quotes:

"But as noted in my previous post, merely being published by Google doesn’t guarantee that it is. Microsoft did similar a few years ago with the release of VC-1, which was claimed to be patent-free but within mere months after release, a whole bunch of companies claimed patents on it and soon enough a patent pool was formed."

"VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be "H.264 Baseline Profile with a better entropy coder". Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents."

"Most importantly, Google has not released any justifications for why the various parts of VP8 do not violate patents, as Sun did with their OMS standard: such information would certainly cut down on speculation and make it more clear what their position actually is."

And not about patents, but the quality of the spec:

"The spec consists largely of C code…

There's something in all this that I suspect demonstrates a possible flaw in Google's traditional data-orientation, as opposed to human judgement.

What the colour gradients (1Mcolors) example in the referred to article (http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/) shows is that WebP, at the limits of quality, prefers to blur. The problem is that most real-world scenes are of objects that have texture, and an artificial texture is psychologically more pleasing than blurring away all these high-frequency small detail patterns. Dark Shikari’s article (http://x264dev.multimedia.cx/?p=541) shows this really clearly: in a real-world landscape, WebP loses badly to both jpg and x264 with too much blurring.

Thing is, if you just do the "obvious" quality metric and do a subtraction of the encoded picture from the original, and sum up all the differences, that doesn't encode the psychological aspect.

A blurred image might indeed do well here, because the blur colour will be somewhere in the middle between the highs and lows of the high-frequency pattern, so the error won't be too large.

But a psychologically-oriented encoding may have encoded a pattern that resembles the original frequencies, but not precisely aligned, so the highs and lows may not coincide exactly between encoded image and original. It may thus simultaneously give a worse difference on a subtraction, but please the eye more.

> However, I was merely a contractor, and not making the business decisions. I worked with multiple contractors that thought similar things to yourself

Do you know you're not talking to some contractor, you're talking to the guy behind x264?

If you don't know him, read his analysis of VP8 (note copyright footer):

http://x264dev.multimedia.cx/archives/377

Having been in the streaming industry since the mid 90's, with heavy work in live and on demand encoding, I've seen dozens of these companies make similar claims, usually in pursuit of investment dollars. For years running, regardless of open source versus closed source, none stack up well against x264 when measured for the way people see video and for the resources taken to produce the encoded content.

You really don't have to read past the first graph:

http://compression.ru/video/codec_comparison/h264_2011/

This is an informative study, and has been for the last seven years. If you have a better compression that would let me, as a CDN, offer clients movie delivery to users with enough less bandwidth and storage it's worth retooling for, we're all ears. Again, I've talked to dozens upon dozens. None really had it. So far, given their original source, I could personally produce an even smaller x264 file that end users prefer.

I agree with everything but your last point:

> Apple should have just completely created their own format instead of extending ePub, and we wouldn't be having this discussion. Now Apple has become the convenient scapegoat for ePub's failure, whilst others, most notably Amazon, get a free pass for doing exactly the same.

That seems like a terrible reason to head off on your own and create a totally new format. Case in point, look at audio/video CODECs. Under the hood, many of them have startling similarities. The consumer has no idea they're similar, because they're named differently.

More directly, what is wrong with extending ePub, provided you don't represent it as ePub. Gruber's best points are made on a technical basis, not a business basis. Apple isn't calling the iBooks Author output ePub. That would be egregious.

As is typical in the technology space, everyone is conflating arguments. They're pissed about Apple's business tactics, and so the argument spreads like fire in a field of dry grass.

From a black box perspective, iBooks files are proprietary. Whether their "based on" ePub is no more relevant than the fact that VP8 bears similarities to H.264 and many other video CODECs [1].

1 - http://x264dev.multimedia.cx/archives/377

Re: Third, nobody knows if anything is immune from unknown-by-definition patents, and MPEG-LA does not protect against them either:

> Q: Are all AVC essential patents included?

> A: No assurance is or can be made that the License includes every essential patent.

http://www.mpegla.com/main/programs/AVC/Pages/FAQ.aspx

However, as far as known patents go, VP8 is clean. I'm pretty sure Google put incredible effort in analysing the risk before making themselves troll target.

The codec is very close to violating many patents, but with "strange omissions" (http://x264dev.multimedia.cx/archives/377) that make it non-infringing. IANAL, but that sounds like great strategy — there are unlikely to be two different 99% overlapping patents (that would survive re-examination and apply to VP8 only), and you can be sure you're not infringing the known one.

If you look at list of supporters:

http://www.webmproject.org/about/supporters/

That's patent troll dream. Everyone to sue, from small fish to test claims on to biggest pockets to drain. And yet, no trolls appeared.