Slashdot Mirror
VP8 and H.264 Codecs Compared In Detail
An anonymous reader writes "Moscow State University's Graphics and Media lab have released their sixth MPEG-4 AVC/H.264 video codecs comparison. Also of note is a recently added appendix to the report which compares VP8, x264, and Xvid. The reference VP8 encoder holds its own against x264 despite the source material offering x264 a slight advantage. The VP8 developers comment in the report: 'We've been following the MSU tests since they began and respect the group's work. One issue we noticed in the test is that most input sequences were previously compressed using other codecs. These sequences have an inherent bias against VP8 in recompression tests. As pointed out by other developers, H.264 and MPEG-like encoders have slight advantages in reproducing some of their own typical artifacts, which helps their objective measurement numbers but not necessarily visual quality. This is reflected by relatively better results for VP8 on the only uncompressed input sequence, "mobile calendar."'"
RTFA?? -- I think I'll wait for the movie
In Soviet Russia, Codecs compare YOU!
(did I do it right?)
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Input content *will* usually have been compressed with H264. Even the likes of Google will find itself transcoding 99% of its content into VP8 from some other codec. That might suck for comparison tests but its a fact of life.
One is an extorsion accessory, the other is not (yet).
Unfortunately their statement is very misleading considering how VP8 and H.264 and other MPEG codecs use basically the same transform so their statements of bias against VP8 ring untrue. One of the professors who was part of doing this test even confirmed that the VP8 developers statement was untrue and misleading.
"The reference VP8 encoder holds its own against x264 despite the source material offering x264 a slight advantage."
Um, sure, if VP8 on its "best" preset being roughly equivalent to x264 on its "high speed" preset means it's holding its own, I guess that's a fair statement.
One important consideration is how the encoder is "set up". On2/Google has probably been tested using standard test material (such as Mobile Calendar), but does not perform so well across a wider range of material. I would like to see its performance on wide range of material, particularly slow pan with fast small objects. For these scene, it will be forced to use more SPLITMV macroblock type. This has more bit required for MVs or worse coding more Intra MBs.
Also, remember almost all new camcorder/camera are AVCHD, and TV broadcast is MPEG2/AVC. So, On2's future, if it exists, has to be good at transcoding from such source material.
**Z
Then that reflects the real world. Most footage that a person shoots will be compressed anyway (during recording or in editing). The fact that VP8 still looks good after the recompression tells me that we have a real winner.
It will all come down to support. Which codec has the widest support.
Even Firefox will eventually add H.264 support even if it is with a plug in.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
I don't understand the "VP8 holds its own against x264".... The graphs show that it certainly does not hold it's own against x264. For example, if you look at the best quality settings of x264 vs VP8 for the Ice Age clip, at the same quality (SSIM=0.97), x264 takes 800Kbps while VP8 takes ~1.2Mbps... So VP8 takes 50% more bits to achieve the same quality. This shows that VP8 is not nearly as efficient as x264. (Also, note that x264 is only one implementation of an H.264 encoder. There are other implementations that will make different tradeoffs to get better compression efficiency at the cost of performance).
Since when did "near enough" become "good enough"? We might as all switch to Windows...
Does anyone have the comparison site rendering poorly? I am running Firefox 3.6.6 and I can confirm that the site looks awful. Something is surely wrong.
The graphs and the text just below them appear 'cut off' in a way. Anyone experience this as well?
Both H.264 and VP8 use the pretty much the same exact approximation of DCT. They should be identically good at reproducing each others errors. The better performance in the mobile calender test is probably more representative of either a coincidence or the fact that the encoder has especially been optimized for certain standard test sequences. Also, I'm glad that the people doing this comparison tested for SSIM rather than PNSR. It's a metric which, while not perfect, has a much better correlation with "looks good" than psnr.
It's also almost never H264 first but MJPEG/XVid/MPEG2/etc and NOT H264. For a start, encoders for mobile phones don't have the power to encode H264 live. So the OP assertion is obviously and trivially wrong.
While looking at encoder comparisons, keep in mind this post from a x264 developer about cheating on encoder comparisons. I'm not saying that these guys are cheating, just things to look out for.
Most video material comes, originally, from a camera of some sort. (Obviously, this isn't the case for animation.) All of the HD camera systems I know of record in H.264, MPEG-4 or MPEG-2. (It might be called HD-DV or something else, but it's MPEG compressing under the hood.) So, if that gives H.264 an advantage, there isn't much that can be done about it. It will take a long time to replace all of the camera gear out there...
$699for what essentially is a research paper???
Check the validator output.
The VP8 developers comment in the report: 'We've been following the MSU tests since they began and respect the group's work. One issue we noticed in the test is that most input sequences were previously compressed using other codecs. These sequences have an inherent bias against VP8 in recompression tests.
I'm sorry, but what do you expect from a report that's all about transcoding performance? From TFR:
The main task of the comparison is to analyze different H.264 encoders for the task of transcoding video—e.g., compressing video for personal use. Speed requirements are given for a sufficiently fast PC; fast presets are analogous to real-time encoding for a typical home-use PC.
Is it legal to distribute media that is for profit using the x264 codec in the United States? I was under the impression that x264 infringes on H.264 patents in the US and that distribution of media that is encoded using H.264 has licensing fees associated with it.
I could be way off base here and would like some clarification. If this is true, then VP8, as long as it does not have licensing fees, is by far the way to go. I have been concerned about this as I have been considering developing and distributing video tutorials for 3d apps. It would seriously suck to discover that I was infringing and at risk of legal action.
And there's almost two billion chinese trying to make hardware that doesn't infringe pattens so they can sell obscenely cheaper here in the west.
The manufacturer's license for H.264 is $0 - for sales of 100,000 units or less each year.
20 cents a unit - for sales of 100,001 to 5 million units a year.
10 cents a unit - for sales above 5 million a year.
With an "Enterprise Cap" of $5 million a year.
SUMMARY OF AVC/H.264 LICENSE TERMS
The Korean Samsung Group - for comparison - has about a quarter of a million employees and annual revenues of $170 billion.
I was under the impression that there is no standard for encoding a video stream, and that the standard is in the decoding of the stream.
It makes it unlikely that this comparison of codecs shows the full potential of one standard over another - and I would be wary of drawing any conclusions.
General statements/headlines about a comparison between "VP8 to h.264" are absurd. One can compare aspects of each standard or how the standard performs in a single field, but not the standards themselves. H.264 will always come out ahead if you do that, because, as a standard, it is clearly better and I do not think many people would argue otherwise.
H.264
-Produces superior video
-Is already widely supported in software players, hardware players, games consoles, cameras etc.
-Produces results that most people are very happy with
I don't like the idea of them trying to replace a widely supported codec with something inferior and which nothing currently supports. Google have arrived about five years too late and with a substandard codec. I for one would be happy to pay a small additional fee for H.264 support.
...Which brings us back to the "for now" part of the comment.
If you're a camcorder manufacturer, chances are you're using H.264 (and paying licensing fees to do so) precisely because it's convenient for people to upload to YouTube and otherwise muck with the video without having to transcode it. If that changes because YouTube and other mainstream sites and software support VP8, and you have the ability to offer consumers the option of doing the same thing without paying licensing fees by encoding in VP8, you'll likely do so to increase your profit margin.
Your logic here supports the chicken-and-egg scenario that MPEG is praying for: manufacturers unwilling to support a format not in common use, and a format won't get in common use because manufacturers won't support it. As Google and other companies break the cycle by convincing people that the format will come into common support, manufacturers will be more willing to jump on board, bringing consumers with them.
While most of the card ones are AVCHD which is H.264, HDV cameras are MPEG-2. They are quite popular as there's reason to want tape as a storage medium.
Then of course in terms of pro video, it is still compressed, raw video is just too daunting to store, but again with different codecs. They are often takeoffs of DV where there is just very light per frame compression as well as chroma downsampling. That offers better quality on subsequent recompression and editing, as well as lower hardware requirements to encode.
This idea that everything will be H.264 as a source is inaccurate. It is popular no doubt, and I believe it will continue to be, but it isn't universal and probalby won't be.
They go out and download x264 and think "H.264 is free, I just downloaded the encoder and it was open source." No, not by a longshot. H.264 has hefty licensing fees in many areas. What's more, every 5 years they review the licensing and decide if it is going to change. Originally, they had it such that you had to pay per viewer for streaming media, with no cap on royalties. While that's gone now, perhaps they bring it back when they have a monopoly.
WebM on the other hand is truly free. If you look at Google's license it gives you complete, royalty free access for any purpose to all code and patents. Only way you can lose it is to file a patent lawsuit against WebM. So there are no fees, ever, for anything and there never will be.
Does this matter? Well depends. For professional production, probalby not. The license fees aren't extreme and you can build them in to the cost. The extra quality per bit you get with H.264 is worth it. However for the web? Well I'd want to use WebM. If I go posting a silly video of my cat online I do not want to get someone on my ass for roylaties later because the license changed. So what if it isn't as good per bit, it is good enough.
It really annoys me to see all the 264 fanboys/WebM haters on Slashdot. I bet you some of these people are also Windows haters/Linux fanboys. They love H.264 because of the x264 project so they think they are sticking up for OSS. They just have no idea what the real situation is and thus look like idiots.
Personally I think there's plenty of room for both. WebM may never be as good as H.264 per bit. That's completely fine, it is good enough. It gives a good looking video stream at a reasonable bitrate. That is all you need for web video. Then for the times when quality is a premium and money is ok, you can use H.264. We don't have to have one codec. I'm fine with H.264 being on my Blu-rays, WebM being on the web and VC-1 streaming me Netflix.
Has a rate of uptake that exceeds any previous codec?
Where do you get that information from?
http://lkml.org/lkml/2005/8/20/95
I'm not sure that formal comparisons are really going to help anyone. This post is little more than a footnote on a larger report, and it just seems to be stirring up controversy. (Not that I find that surprising here.)
Everyone is going to have different requirements. Try vp8 yourself and draw your own conclusions.
For my purposes, vp8 creates smaller files using higher target bitrates. The only way I can see a difference between two bitsreams of equal size is by scrutinizing individual frames. x264 is still slightly sharper, but not enough to matter to me. They both produce ugly artifacts in dark backgrounds, but you won't see them when viewing the video normally. They both need way too much tweaking to get the best results.
- The newest official version of libvpx (google vp8 codec) is now in stable.The license issues with libvpx is now resolved. Bugfixes has been done. Gstreamer supports VP8 and WebM.
- Newest stable release of ffmpeg with support for VP8/WebM is in rpmfusion testing (extra packages for Fedora). Expected to be released to stable soon.
- A new svn version of mplayer/mencoder with support for VP8/WebM is in rpmfusion testing(extra packages for Fedora). Expected to be released to stable soon.
- VLC 1.1 with support for WebM/VP8 has not reached rpmfusion testing yet. Expected soon.
- Epiphany web browser supports WebM/VP8 trough gstreamer. Example http://www.youtube.com/watch?v=A1zySeNpW20&html5=1&webm=1
- Looks like we have to wait for Firefox 4.x before we get WebM in Firefox. Fedora 14?
The infrastructure for adding and streamlining the support for VP8/WebM in Fedora is getting there.
They don't use those on 99.9% of the phones out there. OP said "now".
And baseline is the crappy version. Why is it when any H264 is compared, you complain that they're comparing it against "crappy" baseline, but when it comes to how a tiny segment (remember, OP said "now") baseline is fine and dandy?
Listen, who cares for these marginal speed differences. All I want is a way to watch videos for free without having to install malware, a way to publish my videos commercially or non-commercially without having to pay license fees to stupid lawyers now or later, and a way to check and modify the source code and implement video playing and streaming abilities in my software as I like. I know this is a bit off topic, but this is really starting to make me angry. I just can't understand why media companies and software patent holders, who have already made billions of money by using and taking advantage of the originally free and open internet and in many cases owe their existence to it, keep trying to destroy it with patents, licensing schemes, DRM, and malware. Is it not possible for mankind to agree on one single FUCKING video codec that is not encumbered by patents and will remain free to use and modify forever and for anyone?
Here is my suggestion: Pressure your politicians to create a commercial internet that is completely separate from the non-commercial one. On the commercial one people can sell whatever they like with whatever proprietary software they like. On the non-commercial one, on the other hand, non-free, non-open source is banned and since it is non-commercial and for the benefit of everyone special laws should permit the use of any technology on the non-commercial internet even if it is protected in other contexts. I want my good old internet back... :-(