Hacker News new | past | comments | ask | show | jobs | submit login
The first in-depth technical analysis of VP8 (multimedia.cx)
275 points by DarkShikari on May 19, 2010 | hide | past | favorite | 61 comments



In terms of both raw talent and writing ability, Jason's blog is one of my favorites. You can depend on him for solid analysis, clear thinking, and good writing. This article is worth reading.

While I only have a surface-level understanding of video encoding and compression techniques, there are some very good criticisms here. That said, I've been reading through the libvpx source for the past 20 minutes or so. Jason repeatedly slams the quality of the source. The code is much cleaner than he suggests and rather well-commented.

Better than H.264/main or not, I'm excited to see where VP8 goes. With implementations in Chrome, Firefox, Opera, and Flash, it's off to a good start from day one. We'll see where it heads from there.


> That said, I've been reading through the libvpx source for the past 20 minutes or so. Jason repeatedly slams the quality of the source. The code is much cleaner than he suggests and rather well-commented.

It is possible he had an older revision of their code. Since he didn't say how he obtained it early, it may have not been through official channels.


I had rc8 through an NDA which has now expired (hence why I waited until now to post the analysis).


    > It is possible he had an older revision of their code. 
Unless he had a very ancient version of this codebase it is unlikely that it is different in structure from the current mainline.

Adding comments or sanitizing local variable names are only very superficial changes.


Except that he goes out of his way to slam the comment quality. Besides, I think the difference between well-commented code and code without comments can be quite vast, especially when you're inlining assembly, as is the case here.


I think it's reasonable to be overly critical of the source code quality based on the factors he cited (the lack of a real spec and the extreme age of the codebase) - if the code is the only thing we have to go by in many cases, it had better be pristine.

Hopefully there's some sort of a real specification forthcoming and it just isn't ready for release yet.


This blog is the best technical blog I've found, period. Ever. I've worked on an implementation of H.264, so I enjoy the tech details, and I find his posts informative, insightful and well written.

This has to be said — there is so much mediocrity around.


A fun thing about the VP8 patent situation: any company which attacks VP8 with a patent lawsuit has their license to use VP8 automatically terminated. From the license:

> If You or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of VP8 or any code incorporated within this implementation of VP8 constitutes direct or contributory patent infringement, or inducement of patent infringement, then any rights granted to You under this License for this implementation of VP8 shall terminate as of the date such litigation is filed.


A non-fun thing about that license: it seems to me that it's not compatible with the GPLv2, which doesn't allow adding extra restrictions on the end user. I can't remember if it's compatible with LGPL or not, though GPLv3 seems safe.

This has been raised on ffmpeg-devel, so hopefully Google has some opinion about it.


Actually, this restriction is a subset of the one in GPLv2 and LGPL. And it is very reasonable, as opposed to the GPL ones.

Take a close look at section 7 of the GPL:

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

What this means is that if anyone, anywhere, imposes conditions on you (e.g. by way of patent claims), then you cannot distribute the Program at all.

It's a sweeping provision and is the main reason why many companies shy away from the GPL (including some I worked for). It's the reason why we never used XviD, for example — someone, someday, could (and would) come up with patents pertaining to XviD (MPEG-4 ASP) and we would have to stop distributing the software. Meaning, recall the millions of set-top boxes sold.

The restriction in VP8 licensing is much more reasonable — it says that if you come up with patent claims, then you lose the right to do anything with the software.


"The quality generated by On2’s VP8 encoder will probably not improve significantly without serious psy optimizations."

Fortunately, there are open video developers with experience building psychovisual optimizations for codecs like the VP3-derived Theora. This post from yesterday details some of the psy improvements coming soon to Theora: http://people.xiph.org/~xiphmont/demo/theora/demo9.html

So it might take a lot of work (it has for Theora), but I believe the potential for improvement is there.

P.S. Hello from a fellow Mudder!


Of course; x264 isn't unique in its psy optimizations. x264 was not the first encoder to have good adaptive quantization and Theora, while late to the party, is moving that way too.


I thought this was particularly interesting:

With regard to patents, VP8 copies way too much from H.264 for anyone sane to be comfortable with it, no matter whose word is behind the claim of being patent-free.

Google isn't indemnifying those who might use VP8, right?


Right. As far as I understand, this is untenable legally anyway. The MPEG group has the authority to sue anyone and everyone in violation (including the end user). Google is obviously not offering to pay damages in all of those suites.


Google may however sue MPEG / MPEG members in retaliation, and that could be an effective deterrent.


He also says this:

> VP8 is definitely better compression-wise than Theora and Dirac, so if its claim to being patent-free does stand up, it’s an upgrade with regard to patent-free video formats.

Sounds to me like he has no clue yet, and how could he if it's just been released?


Down-voted for factual inaccuracy. From the very first paragraph:

>Fortunately, it seems I was able to acquire access to the VP8 spec, software, and source a good few days before the official release and so was able to perform a detailed technical analysis in time for the official release.

The only "clue" he's missing is whether or not VP8 is buried under a flood of patent lawsuits. Since that's something only time will tell, I think it's perfectly reasonable for him to add that qualification to his claim that VP8 is an upgrade from Theora and Dirac.


a few days is not enough to determine whether it infringes on any patents, sometimes it take year for a single patent.


For all the clueless opinions flying around patents, Jason actually gave technical arguments ... imagine the shock I had to read an insightful technical article, rather than opinions filled with religion or politics.

> sometimes it take year for a single patent

It takes only seconds to issue threats. And a single threat can stop people from adopting it.


The VP8 hope bubble has been deflated for me (I was expected a free and technically better alternative to h.264). I'm a bit bummed out about it, but there was no better way to learn about it than from this blog. Great writing, as always.

Thank you for bursting my bubble in style!


Summary: It has a crappy spec. Not better visual quality (yet? ever?):

http://mirror05.x264.nl/Dark/website/compare/vp8.png http://mirror05.x264.nl/Dark/website/compare/x264.png


Is there some way to express my displeasure at the recent trend of people offering summaries of the linked content rather than their own opinions?

This is one of the better examples of the species, which is partly why I'm responding to it, but often I find the summaries actively misleading, and almost invariably adding snarky content-free remarks.


My motivation was thus: I'm not a video transcoding guy. I just wanted to know a 10,000 ft overview. My summary is what I got out of a very detailed technical article (and it took me a minute to find the comparison pictures in the article, so hopefully re-posting the highlights saved others time).

Another way of looking at it: People hyper-summarizing articles are like HFT for news aggregators. It makes the aggregator more efficient by cutting to what many people only want to know thereby increasing their capacity to consume even more knowledge irrelevant to their lives.


How is the comparison to HFT valid?


You could link to a relevant blog post expressing your displeasure, I suppose.


Or as a Theora dev said, it has no spec, and Google's mistake was calling this 94-page thing they released consisting of an intro textbook crossed with copy-pasted C code a "spec".


> http://mirror05.x264.nl/Dark/website/compare/vp8.png http://mirror05.x264.nl/Dark/website/compare/x264.png

If you open both of these in separate tabs or windows and switch from one to the other, it's pretty obvious that VP8's picture isn't as detailed as X264's. By a pretty wide subjective margin, IMO.

Too bad.


This comment makes an interesting point: http://blog.gingertech.net/2010/05/20/vp8-adobe-is-the-key-t...

"Patents are about _details_ so the mere fact that something does something like something else, isn’t necessarily something at all.

As we’ve pointed out before, many codec patents are exceptionally easy to work around: They specify every little detail because it makes it _much_ easier to get through the examination but doesn’t harm the patent’s ability to read on the final standard because the standard specifics exactly the patented behaviour.

D_S, for all his undeniable H.264 experience isn’t an expert on patents or even the H.264 patents. We can assume that in cases where VP8 looks similar to H.264 those would have been exactly the cases where care was taken to differ in the right places. I’d expect the primary risks for VP8 to be anywhere _but_ there."


Not very promising. I'd think that VP8 would need to be decidedly superior to H.264 in order to become a universal standard. Maybe Google should have acquired Red?

http://www.engadget.com/2009/04/25/red-blows-away-small-room...


Red's R3D codec was a modified JPEG2000. Perfect for its primary application, but intraframe only and a patent minefield.

http://peter.schlaile.de/redcode/

Great company and kit though.


Afaik R3D is a separate codec.


It is decidedly superior: it has a free licence. If that’s not important to you then you won’t be fussed by this announcement, but for the rest of us this is a big deal.


Free license is irrelevant if you're going to get your ass handed to you by MPEG LA in a patent lawsuit.


When the MPEG-LA actually start suing people instead of just blustering about it then get back to me.



As I said, when they file a suit then get back to me. This is more of what they’ve been doing for the past few years: vague threats of patent pools and litigation without anything to back it up.


Ogg Theora has a free license as well, but at this point it doesn't seem like that format will go anywhere.


That Red "magic 4k codec" is complete vapourware. Also is it impossible to get an unbiased opinion from that demonstration in a room of Red fans.


Quoted from "Summary for the lazy" aka tl;dr

"VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1. It’s not even close to competitive with H.264 Main or High Profile. If Google is willing to revise the spec, this can probably be improved.

VP8, as an encoder, is somewhere between Xvid and Microsoft’s VC-1 in terms of visual quality. This can definitely be improved a lot, but not via conventional means.

VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much.

With regard to patents, VP8 copies way too much from H.264 for anyone sane to be comfortable with it, no matter whose word is behind the claim of being patent-free.

VP8 is definitely better compression-wise than Theora and Dirac, so if its claim to being patent-free does stand up, it’s an upgrade with regard to patent-free video formats.

VP8 is not ready for prime-time; the spec is a pile of copy-pasted C code and the encoder’s interface is lacking in features and buggy. They aren’t even ready to finalize the bitstream format, let alone switch the world over to VP8."


> With regard to patents, VP8 copies way too much from H.264 for anyone sane to be comfortable with it, no matter whose word is behind the claim of being patent-free.

This is the scary one. The other points are simply a matter of improving the spec / technology.

edit: read comment #16

"Actually ripping of H.264 may be a way to avoid submarine patents.

By having design so similar, Google only has to worry about MPEG-LA patents.

So there is a known, finite list of patents to review.

Given bizarre tweaks and omissions in VP8, I suspect that’s exactly what they did – looked at claims on H.264 and tweaked VP8 just a little to avoid crucial points (remember in patents you have to infringe all points in a claim, if you infringe 2 out of 3, then you’re safe)."


But remember, all it takes is you infringing on one claim in a single patent.


I'm actually surprised how well xvid does in those comparison shots. Based on those, xvid would seem to be the closest competitor for VP8 alongside with VC1. x264 is in a class of its own. There seems to be some kind of trade off between blurriness and artifacts, imho x264 shots coulda been bit softer, and VP8 seems to lean heavily on the blur side.


Betamax offered some technical advantages to VHS, but look who won that war. The main reason they won is because JVC allowed other people to use their designs for a reasonable scale. Keep in mind in this debate that H.264 isn't free to use, and VP8 is. Are the technical merits of H.264 enough to outweigh the cost? In my opinion, no.


While the licensing costs did play a part in the win of VHS I think the bigger problem was the price of the decks (1.5-2x price of a VHS VCR) and beta camcorders were incompatible. To watch a home video you had to play it back through the camera onto another beta deck.

The only technical advantage it had was color reproduction and clarity. Every other metric (cost and convenience) it did poorly. It did go on to live a second life, as Betacam, in professional studios, where reproduction and clarity are important. And their ENG cameras are some of the sturdiest I have ever encountered.


This part was interesting to me:

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.

Then later, about the encoder:

there were comments describing bugfixes dating as far back as early 2004. That’s right: this software is even older than x264!

Wouldn't that mean that VP8 didn't copy if the software is older? Prior art? I mean, you can't write an encoder for a spec that doesn't exist. IANAL, so I'd like some info here.


The H.264 spec dates back to ~2000-2001.

x264 is an open source software program that implements H.264, and was written starting in 2004.

Furthermore, we don't know when they added intra prediction to VP8; it could have been many years after the original program was written.


Thanks. Makes sense.


Thanks for the great write-up Jason. I had no idea you were a junior at Harvey Mudd. I remember when you helped me on an IRC channel when I was writing a patch for FFmpeg. I thought you had many years more experience than me when you were only a year older the whole time. Very impressive!


The contrast of the site is so bad that I had to hit browser back button after a couple of minutes.


I think it's much more readable with white on black than black on white. But of course if you disagree, which is fine -- some people do -- you can use readability, as in mbrubeck's post.

I'm not quite sure why some people really like black/white while others like white/black. Maybe it's something psychological, or maybe it's just room lighting.


I find that, while I like white-on-dark, I tend to require a larger font to comfortably read it than I do dark-on-white.

On the article's page, when I knock the browser "zoom" feature up one notch from default, it's like the entire page magically becomes this wonderful, easy-to-read document.

It may be because I'm on a 1920x1200 display on a 17" laptop screen, but at any rate, I would consider a small upward bump in font size. I wouldn't have brought it up myself, since as I noted above, I can do it myself in my browser with a quick hold of Ctrl and a flick of the mouse wheel. But since the topic came up, I thought I'd throw that in.


Use http://lab.arc90.com/experiments/readability/ or just disable the stylesheet (View -> Page Style -> No Style in Firefox).



Don't forget that this is written by a x264 dev, so not very surprising that he concludes that his codec is way better. Is there an analysis from a less biased source?


Don't forget that this is written by a liberal, so not very surprising that he concludes that his liberal view is way better. Is there an analysis from a less biased source, possibly with fewer well detailed explanations of the basis and reasoning of all of the sub-arguments that lead up to the obviously not surprising conclusion? The fewer credentials they have, the easier it will be for me to follow along.


Papachito's point is still valid.

If VP8 somehow overtakes h264, the value of the author's work on x264 would be diminished. He is the "lead developer" for x264.


Why the downvotes?

This is like having Bill Gates critique a new release of Linux.


How could anyone write an analysis only a few hours after such a complicated technology is released? It's also full of IANAL and yet still FUDing about how it's probably full of patents (as if google was dumb enough not to check patents). It looks to me like he had his opinion already formed on his previous use of VP8 and just published it today on time to make a big splash.

Edit: it looks like this article was released a few minutes after Google announcement...

Edit2: it looks like he had access to the spec a few days ago. I still think that Google is not putting their money blindly into VP8 though, they have the money to pay hundreds of analysis like this one and they sure did a lot of them, so it's either good enough or they have plans to make it good soon enough. Still better than x264 for people involved in free/open source like me.


In the second sentence, before he even addresses the attention deficient, "Fortunately, it seems I was able to acquire access to the VP8 spec, software, and source a good few days before the official release and so was able to perform a detailed technical analysis in time for the official release."

In the comments here, where you might find people discussing e.g., validity, you can find the author commenting on this "issue" further: http://news.ycombinator.com/item?id=1361739

Not to mention an x264 developer is a lot more interested in VP8 succeeding than H264...

If you have any actual concerns, rather than the cargo cult concerns that seem similar to those more intelligent people may voice in situations when they're actually informed on a topic, please mention them.


Have you RTFA? He states:

"Fortunately, it seems I was able to acquire access to the VP8 spec, software, and source a good few days before the official release"


The author had access to a release candidate version but was under NDA until the official announcement.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: