VP8 vs H.264 – Which One is Better?
gist.github.com
gist.github.com
I chose the clip based on what Dark_Shikari (x264 developer) had to say about it[1]:
It shouldn't bias too heavily towards any one encoder like many of the other standard test clips will:
a. It's relatively high motion, so it won't bias heavily against encoders without B-frames or qpel (as, say, mobcal does).
b. It's not so high motion that it would cripple video formats that don't support motion vectors longer than 16 pixels (e.g. Theora).
c. It's not something that benefits an unreasonably large amount from some of x264's algorithms (which is why I picked this and not parkrun).
[1] http://forum.doom9.org/showthread.php?t=154430
I could have done multiple test encodes, sure, but the problem in this case was that downloading several gigabytes of raw source material isn't exactly instant. And even if I tested with multiple clips, I doubt the conclusion would be that much different.
And sure, perhaps you'd get the same result on other clips. Over high-profile H264 the only obvious format feature that come to mind that could really let VP8 get ahead are the 'truemotion' intra-predictor and creative use of the synthetic reference frame (though I suppose the vp8 developers might have other suggestions) and I'd expect those features to only be big wins on a small number of clips so it wouldn't be hard to miss the cases where VP8 really shines over high profile h264.
But you (or I) could have said that without doing the test at all, and there would be 100% fewer clueless people going around claiming that something was proven here that wasn't. Your opinion (or mine) is a fine thing, but it's not proper to launder an opinion as fact by dressing it up in an inadequate test.
But it wasn't. I was comparing the visual quality of the whole video, and provided the full encoded clips for people to download and compare for that reason.
I am willing to do further test encodes, but have no interest in doing something like encoding all 28 HD test clips available on derf's test clip page[1], since as a purely visual comparison, especially with the actual encodes, it would be incredibly exhausting.
EDIT: I added a notice about the downsides of single clip comparison to the top of the post.
Science is exhausting. If you're not working hard, then you're likely to miss the interesting (counter-intuitive) results. In fact, finding counter-intuitive results is the whole point of science. If the truth were intuitive, explanations wouldn't need testing.
Anyway, I brought up the subject to some Xiph folks over at IRC. Maybe in the future the test clips will come equipped with more detailed information to help in testing. It'd also benefit smaller scale tests, since it'd allow one to identify possible biases more easily.
Given that people do hundreds of test encodes when they actually use things like x264, I think that if you want to say anything general about these encoders you have to do more than one comparison.
Also, I don't think that H.264 forbids only commercial use. Can you freely distribute their decoders and encoders? What about putting them in hardware for non commercial use?
The idea that VP8/VP9 will gain traction and remain royalty free is laughable.
That's right, and that's the reason to avoid any closed codecs.
> The idea that VP8/VP9 will gain traction and remain royalty free is laughable.
What's laughable? VP8 remains royalty free. VP9 will as well. In practice you can never guarantee that some submarine patent troll won't appear tomorrow to threaten you. But the same perfectly applies to H.264/H.265 so your argument is irrelevant, since such threat applies to virtually anything, but it doesn't mean one should stop innovating because of it.
"The first in-depth technical analysis of VP8" http://x264dev.multimedia.cx/archives/377
It's important to explore the space a bit for discussion's sake.
Obviously there are problems with testing unfinished implementations, as:
A) they are generally VERY slow given that there's little optimization during the development phase, and these next gen video codecs are more demanding than the previous generation
B) a great deal of the quality comes from fine-tuning during implementation, not from the specification. For example x264 is a 'best-in-class' implementation of h.264, readily beating many other implementations of the very same specification.
As such, this fine-tuning is not likely to exist until the codec implementations mature, which likely means that what is available now of HEVC/VP9 serves only as very rough estimates.
Would still interesting though :)
*VP8 doesn't have B frames, similar to the h.264 baseline profile.
Apart from being one of the developers of open source GPL licenced x264 encoder, he and the other developers are also licencing it for proprietary use (nothing wrong with that, I think it's a great way of making money out of open source development). This means that a open source royalty free codec like VP8 (and later VP9) could cut into their revenue stream.
I'm not saying that this affected the outcome of his test, but it's still context. Also his test back then was also criticized for only using one clip, here's another test with a larger set of comparisons:
http://qpsnr.youlink.org/vp8_x264/VP8_vs_x264.html
I can't vouch for the validity of this anymore than the validity of any other test.
I really do hope that VP9 can offer the quality of H.265. VP8 just wasn't good enough to compete against H.264.
I am okay with the minor loss in quality, just for the ease of managing a lot of videos and a lot of disk space.
How exactly? There is no indication that Google wants to make VP9 patent encumbered, since their whole idea behind VP8 was to enable high quality open video codec for the Web and beyond. If VP9 will be their natural next step, it will be open as well. If Daala comes soon enough too - it will be another option.
http://www.webmproject.org/license/bitstream/
Your post, makes my point. Why would Apple and MS expect Google not to do it again?
Because if VP9 is indeed similar to H.265 then you I would imagine a patent is being infringed somewhere. And since Google doesn't provide patent indemnification you can guarantee that some big royalties will be demanded from users.
Why would they design the codec to be vulnerable to patent attacks? VP8 was designed to work around threats from H.264. They surely applied the same logic for VP9 since they intend it for practical use and not as theoretical brain exercise. MPEG-LA spits threats all the time, including against Theora and VP8, but they have no teeth to bite.
Also, On2 which Google purchased holds lots of video compression patents, patents which codec's like h.264 and h.265 just as likely violates.
MPEG-LA does not offer any patent indemnification either.
Why would Apple or Microsoft believe Google's patent and royalty free license given their behavior with Motorola's prior promises?
How can it help against some patent troll who can appear tomorrow and threaten H.264 users? No army of lawyers can help against that. So all this rhetoric is completely useless. Legally VP8 is as good as H.264. The only reason for them to avoid is to retain their monopolistic grip on codecs usage.
The standard itself doesn't specify how an encoder behaves. That leaves a lot of room for innovation on encoders. End of the day, the qp/bitrate ratio you get is encoder implementation dependent and not sometime that's specific to the standard. This is the part where most of the patents exist.
Of course as everything switches to android this will change completely by the end of the decade, but for streaming in 2013, h264 is the better investment.
Once they move to h265 vs vp9 the point is moot but that won't be common for at least five years. The encoding requirements for those streams will also be significant.
That's hilarious.
I mean we are reaching the point where a $20 device can just plug right into a hdmi port and you have a full blown pc with standardized wifi and bluetooth support. By 2018 they will be $10 and sold at gas stations.
When that happens you can have any codec upgrade you want as long as it can still decode on that hardware spec in realtime.
The ffmpeg guys wrote a VP8 decoder with 1400 lines of C because of how much they were able to reuse. From: http://blogs.gnome.org/rbultje/2010/06/27/googles-vp8-video-...
I wonder why couldn't they allow software usage ( Encoder and Decoder ) to be free. And only collect royalty on Hardware, and Industry Production use.
{currently at the bottom of page 4 when by pts it should still be in the top 10)