Now that Google has opened up VP8, the big question is obviously how it’ll hold up to H264. Of course, VP8 already wins by default because it’s open source and royalty free, but that doesn’t mean we should neglect the quality issue. Jan Ozer from StreamingMedia.com has put up an article comparing the two codecs, and concludes that the differences are negligible – in fact, only in some high-motion videos did H264 win out. As always, this is just one comparison and most certainly anything but conclusive. Update: Another comparison. I can’t spot the difference, but then again, I’m no expert.
On2 once claimed that VP8 could deliver twice H264’s quality at half the bandwith, and while that certainly isn’t true, the codec is pretty much on par with H264 – according to this test, of course. “To set the table, Sorenson Media was kind enough to encode these comparison files for me to both H.264 and VP8 using their Squish encoding tool,” Ozer writes, “They encoded a standard SD encoding test file that I’ve been using for years.”
The results for low motion video are clear: there is absolutely no difference between the two competing codecs. In fact, Ozer notes that in some cases VP8 retains more detail than H264 did – but in all honesty, if Ozer hadn’t pointed them out, I would’ve missed it. In high motion video, there are cases where H264 wins out, but once again, if Ozer hadn’t pointed them out I wouldn’t have noticed it.
If this rather crude test shows one thing, it’s that VP8 is more than good enough. Add to this its royalty free nature and the strong industry backing it has already garnered, and we’re looking at a winner. After Google’s continuous stabs at Apple during the I/O conference, I’m convinced YouTube will switch to the new codec exclusively as soon as WebM support is added to Android (Gingerbread, Q4 2010) – if only to spite Apple.
It is important to note that when comparing Theora to H264, Ozer was pretty clear in declaring the latter the winner, so we’re not looking at a biased test here. Ozer’s Theora vs. H264 test was widely linked on the internet by the pro-MPEG-LA/H264 lobby, so it’ll be interesting to see if they’re going to do the same with this one.
Why use Squeeze instead of x264?
Images show different times, so are they key frames we’re looking at? Or intermediate frames?
Also not enough details of the encoding profiles used.
Finally, the web is moving towards HD video, how about some hi-def content instead of these tiny images?
Someone from a reputable site needs to test this properly.
What kind of details would you want ?
Because most of the web is moving towards upscaled tiny images flagged as “hd”, except for vimeo ?
I agree. This test should have been against a well-optimized x264 command line, not a random GUI encoder that has pre-baked options. The reason for this is two fold:
1. The kind of videos people look at mostly, at Youtube & Vimeo, are using these well-optimized command lines to encode (youtube is using a modified x264 version, and Vimeo is using x264 via mencoder AFAIK). Therefore, it’s these kinds of videos that will essentially matter on web video. What you and me are encoding at home will always be good enough with either encoder (really, do we need better quality recording our cats sleeping on a couch?), but web broadcasting is where the difference is made. And since these web broadcasting services are always well-optimized, I expect any benchmarking test to try to be as close as possible to the level of these web services.
2. The guy possibly did use the command line to encode to WebM, so why not for h.264 too?
I know that the x264 developer was called biased for his recent blog article that was linked from many places, however, I don’t think he was lying. When he said that VP8 is possibly as good only as h.264 Baseline, I think he was truthful in that.
Still, I rather have VP8 (even on my camera, shooting directly to VP8) than have the patent nightmare and ESPECIALLY the crazy licenses for cameras/video-editors surrounding h.264.
Also, isn’t most web video H.264 Baseline anyway?
No. Squish is just Sorenson’s very simple online WebM encoder (whereas Squeeze is Sorenson’s desktop software).
https://www.sorensonmedia.com/vp8/
Therefore the h264 version is the one most likely to have been optimized “by hand”, but I don’t think it is. It is also unlikely that Squeeze uses x264 because the former is licensed while the second is open-source*.
(*not in America)
… and what will you be measuring? how well the codec specs stack up against one another or how well different encoders stack up against one another?
there is a difference btw a codec spec and codec encoder. A bad spec will do badly independently of the encoder used and a bad encoder can produce a terrible video no matter how good the spec is.
Blogs like osnews should try to show a distinction btw a spec and an encoder. It will be rediculous to compare html5 spec against previous versions based on how well/terrible different browsers handle the two and it just as rediculous to compare these two codecs based on how different encoders handles them
nah he’s correct:
test should be against x264 and probably high profile
and..
hd video should be encoded, as there is a lot more detail to retain
i’m pretty sure x264 will win but the question is by how much
I don’t know anything about this “Squeeze” encoder, but I’m guessing it’s not really as good as x264.
There is really no point in comparing anything to H.264 if you’re not using x264 (in the same way that if you are comparing something to Theora, you really should use Ptalarbvorm, or at least Thusnelda).
My guess is that x264 will beat VP8, but the difference will be small, and VP8 will be perfectly suitable for web video.
Edited 2010-05-23 11:10 UTC
Yeah, and what’s the point of comparing at bitrates high enough to make them indistinguishable?
If we go to a high enough bitrate (as lemur2 did) then Theora will become indistinguishable too, but no-one would claim it is as good as x264.
I demand lower bitrate, non-HD tests! Something like DVD resolution, at 350 MB/hour, to give a realistic example.
I compared them at a lower bitrate than this page indictaed:
http://en.wikipedia.org/wiki/Bit_rate#Video
Theora is close in quality to h.264 at bitrates appropriate for the quality and resolution level, as indicated by this table, and even quite a bit lower bitrates.
Mainconcept Codec is one of the best but it’s not even free, it costs 179 $$
http://www.mainconcept.com/products/apps-plug-ins/avc-encoder.html
For a comparison of x264 to Mainconcept AVC:
http://graphics.cs.msu.ru/en/science/research/videocompression/264c…
I all, here you can find a comparison between H.264 (x264 encoder) and VP8 encoded videos. We used the latest VP8 library version from webm project:
http://www.quavlive.com/video_codec_comparison
While you’re here, could you explain why, in the shell scripts, “bitrate=15000” for x264 and “bitrate=15000000” for vp8enc?
Because the vp8enc plugin takes the bitrate parameter as bit/s, instead x264enc takes the same parameter as kbit/s.
Are SI units used, or standard computing units? 15000 Kib would be 15360000 bits, giving x264 a 2.4% advantage. OTOH rounding might trump that, I’m didn’t download the videos to check the actual bitrates.
AFAIK, bits are always counted in base 10. It’s bytes that use powers of 2. Are there any situations where a kilobit is 1024 bits?
Video encoding ALWAYS uses base 10 values. So it’s 1000 or 1000000, not 1024 or 1048576.
Isn’t 15 Mbit/s too high? 1080p rips on thepiratebay seem to be around 8 Mbit/s.
Can you do the test again at that bitrate?
Yes, I’ve re-encoded the Sunflower sequence with target bitrate=7500 kbps. See the results here: http://www.quavlive.com/video_codec_comparison#TOC-Sunflower
What is strange is that while I could see some difference in Jan Ozer’s test, I cannot see *any* difference on your test..
If someone would have asked me if both images were identical, I would have said yes..
If it’s not a mistake then this means that the bandwidth allowed here is big enough here that both codec reproduce flawlessly the original video..
Yes, the results are quite the same. I used the same encoding rate of this test (http://doom10.org/compare/). I will include other results on the same page soon.
The VP8 encode is worse than VC-1 and x264 Baseline in that comparison.
Check the water, grass, and the fenceline.
The image overall is softer/blurrier.
Edited 2010-05-23 13:51 UTC
Can you post an original frame for comparison too?
I can’t tell what’s actually a true detail and what’s just an artifact on the H.264 one. The grass and trees look more “detailed” but on the human figures they just look a different kind of odd.
Is the extra detail on the trees just an illusion? It looks like someones run a sharpen filter over everything. And is the lady with the boa really wearing insane clown posse-style face makeup?
Edited 2010-05-24 15:27 UTC
I just had a look at both and I barely notice a difference; I’m sure when in full motion the differences will be even less detectable. I am confused, therefore, why people are trying to make out that there is a massive difference between the two of them. I am sure with more optimisations artefacts will be minimised and will be offered as a viable alternative to h264.
Media quality is not a major issue on the internet, as long as the gap is small (it’s the case here). Licensing quality is one.
Remember the Unisys episode : GIF was certainly superior to JPEG in its time about compression ratio vs quality…
I think you should compare gif to png. That’s more inline with the usage pattern.
Yes, but as far as I know PNG did not exist at that time. GIF was a superior format on the 256-color screens in term of compression vs image quality, but JPEG was safer.
(True, PNG beats them all, I use this format for just about everything which doesn’t require layers or animation ^^ But at the time, there was a compromise about compression quality vs licensing quality)
Edited 2010-05-23 17:45 UTC
No, GIF and PNG are good for encoding diagram-like images. JPEG is for photos, which GIF is terrible at.
It did exist for part of that time, but wasn’t widely used. But yeah, you are right ofcourse.
PNG was created when patent fears about GIF began to seem reasonable. It is not reasonable to compare PNG and GIF therefore because for many years there was no such option; the choices were JPEG and GIF, or to take a chance that the client would support some other format and have the bandwidth to download it.
PNG is superior to GIF in almost every way. It does not animate and under certain very specific scenarios has inferior compression. Other than those it is superior.
PNG is superior to JPEG in image quality, being lossless, but for photographic imagery compresses much less well.
Today GIF is used almost exclusively for its animations, since no other means of animation is natively supported by all browsers.
http://people.mozilla.com/~dolske/apng/demo.html
http://en.wikipedia.org/wiki/APNG
http://animatedpng.com/
Enjoy. Especially Chompy. (You will need Firefox 3.0 or later, or Opera).
That’s the problem. I’d love to see a modern standard for animation on the web, but IE does not implement APNG and Apple, in their usual love of open media standards, didn’t implement support for it in Webkit so the number of browsers which do not support it is likely going to increase in the upcoming years…
Moreover, the PNG guys, pissed off because their bloated MNG format did not get as much attention as they wanted, declared APNG as unsupported and vandalized its wikipedia page, favoring market fragmentation.
(PS : About PNG, I don’t understand why there’s 3 rows of thumbnails : GIF, APNG, and ?)
Edited 2010-05-24 12:22 UTC
Yes, browser support is a problem, but IE doesn’t support anything anyway. Not even SVG. The larger problem is webkit, and I can’t see why webkit shouldn’t support it.
However, my post wasn’t really about that point. I was replying to the claim that “It does not animate”.
Actually, it does animate. Easy to show that it does.
Edited 2010-05-24 12:17 UTC
The original claim was…
It does not claim that PNG does not animate. Just that not all (common) browsers support it, unlike GIF…
Edited 2010-05-24 12:31 UTC
The quote that you give says that apart from GIF, no other means of animation is natively supported by all browsers. That is not a statement that PNG does animate.
The other statement made was actually about PNG. I quote: “PNG is superior to GIF in almost every way. It does not animate and under certain very specific scenarios has inferior compression. Other than those it is superior.”
My bold.
We have one statement that PNG does not animate, and another statement that only GIF animation is supported by all browsers. Neither says that PNG can animate, when actually, it can.
Although the second statement is true, that does not mean that the first statement was right.
Edited 2010-05-24 12:47 UTC
Since I made the original statements let me clarify: PNG cannot animate. Is that clear enough? APNG can, MNG can, PNG cannot. Sure APNGs can be displayed as PNGs by browsers not supporting APNG, but that doesn’t change the fact that PNG doesn’t animate. If you have a PNG-supporting browser and load a PNG file in to it you will not get animations. If you have a PNG-supporting browser and load an APNG in to it… you will not get animations. APNG or MNG must be supported to get animations.
GIF, as a format, natively supports animations. PNG does this only through a kind of extension; an extension which is not supported natively by all browsers.
So, I reiterate, PNG is superior to GIF in almost every way. One way in which it is inferior is that it does not animate. Support for animated image formats other than GIF is not universal across common browsers. GIF remains the only image animation answer today.
I added more comparison encodings at Youtube bitrate levels and resolutions for the sunflower and the park joy sequences:
http://www.quavlive.com/video_codec_comparison
Again, for Sunflower sequence the results are equivalent, instead for Park Joy sequence with x264 we obtain the best results.
Early versions of GIF did not support animation. Just as you need an “extension” to the basic PNG functionality to support APNG, so to did you need an extension to basic GIF in order to support animated GIF.
PNG and APNG are superior to GIF.
One can animate PNG alone (i.e. no browser support required for APNG) by using Javascript.
http://www.schillmania.com/content/projects/javascript-animation-1/
http://otanistudio.com/swt/sprite_explosions/
This requires only a sufficiently capable, fast and correct implementation of Javascript, and PNG, which is supported in all browsers except IE.
MNG support was maliciously dropped by Mozilla because “you’re face!” — or at least that’s the best argument I heard at the time. “We don’t like to have a 100kb of image library weighing us down” is just plain silly.
Why people are still so bitter, after all these years…
Time to stop crying over MNG corpse, bury it and move on already.
MNG is simply too complex, for no good reason. End of story.
You could’t be more wrong. Comparing GIF to JPEG is slightly more meaningful than comparing MP3 to DivX, they are two different formats intended for different purposes.
Gif is a lossless 8-bit (usually) color indexed format that is great for simple computer graphics and illustrations. JPEG is a lossly (with exceptions) 24-bit format that is great for photographs but terrible for illustrations.
I know what GIF is. However, let’s go back to those times. When you were making an average personal website (that looked horrible), if you wanted to put a little graphic as a button, you had two choices :
-> Gif (smaller file size in most cases, pretty close to the original file, supports animation)
-> JPEG (big or ugly, no animation)
So GIF was the superior format for most little images on the web. JPEG is good for photographs, but it can also be used for illustrations, even though it does a terrible job. And it became used so in the time where Unisys went amok.
It’s hard to compare h264 to vp8… because it’s like comparing trees to rocks… Each technology has it’s strengths, but in the end, they’re both depended of encoders and decoders, the first ones are pretty strait forward to compare, but h264 has mature encoders and vp8 doesn’t have many yet (but will, due the interest to WebM/OpenSource)… also, h264 is a pretty big standard, it has profiles to mobile devices, to pcs, to media boxes and bluray players, but also for authoring, also pretty much decoded equality, but requiring more processing. VP8 is more of a deliver to costumer codec, it doesn’t have as many options, and also, much of the work done by profile levels in h264 is done in VP8 by the decoder, in post-processing (so, mobile clients may use less intensive post-processing when more powerful clients can use more intensive post-processing.), actually, it’s heavy dependent on this post-processing process.
…in the end, one should read this articles as a preliminary view of codecs differences, and one should probably prefer articles offering more information about the tests, the encoder as the renderer than simple screenshots at this time. This still very very early to really see each technologies’s strengths.
So Google, while having a member on the Apple board, get the YouTube app included on the iPhone using h.264 and now that they have released their own smartphone platform in competition they buy and release a codec that, if the above prediction is true, would effectively render a built-in iPhone app inoperable and significantly benefit Google’s own platform in the process, yet nobody seems to think there is anything anti-competitive let alone unethical about this?
Isn’t this just Google trying to use their dominant position in a market segment to control what transpires in that market and force the hand of anyone who wants to play in that market? Antitrust anyone? Or is it ok for Google to kill off the competition as long as it’s in the name of being “free and open”?
I see lots of people talking about wanting choice, but this isn’t giving choice. Leaving both options in place would be giving choice…
Edited 2010-05-23 14:28 UTC
not realy becus apple are free to add support to webm.
they can even use googles code well except if they do they cant su webm for infring their h264 patent.
so a simpel update to iphone os would fix the issue
Except h.264 it’s hardware accelerated on the iPhone…
yes it is but it is most likley not done by a dedicaded h264 chip. most phones uses generic dsp and gles hardware to achive this task. so den there would not be a hard ting to do to get webm accelerated since it is kind of similar to h264
As much as I’d enjoy (and already enjoy) the vision of Apple finally getting slapped in the face for all of their horrible business practices, and the MPEG-LA’s patent trolling and FUD put to an end, what you say here makes a lot of sense. You can’t ask me to defend the GIF of video formats, but it’s more than fair to declare that Google will use this to increase its monopolistic power.
And then I wonder (and it’s a real question, not some trolling) : what can we do against Google, when they’re always the most reasonable choice ?
Being a bit worried about them one day, after enumerating all the Google-owned services which I were using, I reduced my Google consumption, going as far as trying other search providers like Yahoo and Exalead (still using YouTube and GMail, though). But then, every time I use Yahoo, I see horrible interface design along with poor search results, and I think “those guys don’t even understand what an user asks from a search engine”.
I, as a geek, will then choose to use the clunky service. But I can’t honestly recommend them to anyone else. If someone asks me “What are the benefits”, I’ll say “Google does not own you”, and if someone asks me “…and ?”, I’ll say “Nothing else, in fact you’ll rather lose a lot”.
And indeed, saying “no” to Google means losing a lot for just about everyone. It means losing the best search provider in the world, the most complete video sharing service in the world, the guys who helped open-source going twice as fast lately through the GSoC system, an easy-to-use free and ad-free blogging service, the sole flash-free map service which I know of, the sole H.264 alternative that’s able to stand against the MPEG-LA’s patents, and so on… Sometimes I lose faith and think that saying no to Google is related to masochism.
What benefit, other than experiencing that we’ve still got some freedom, does one get from that ?
Edited 2010-05-23 15:09 UTC
Apple has the choice of including support for an open standard.
Calling YouTube switching to an open, royalty-free standard lockin or choice-limiting is the most ridiculous amount of spin I’ve ever heard in this debate.
And I read DaringFireball, so that says a lot.
Edited 2010-05-23 15:16 UTC
Since when did VP8 become a “standard”? It’s been in the public for a week.
It’s a standard because it is standardized… Do I need to copy-paste a dictionary entry, with the different acceptions of the word, or could you stop being anal?
And yeah, WebM is open, so there is no lock to any implementation (heck, it is not even GPL, so you can take it and sell it without owing anything but credits to the creators).
Edited 2010-05-23 17:10 UTC
Citation needed. Did Google submit VP8’s spec to some standards body? I would be please to hear that they did. Even so it cannot possibly have been adopted yet, so it is not a standard.
It may become a de-facto standard, but it isn’t that (yet) either.
How do you figure that? They can support the codec without hardware acceleration and the iPhone gets horrid battery life playing YouTube stuff, or they reprogram the DAC to give VP8 hardware acceleration and the iPhone’s battery goes into meltdown playing content from the iTunes store. Are you THAT one eye’d? Honestly? I’m not the one putting spin on this buddy, for that you need to just look at into the mirror. Irrespective of the openness of VP8 this is categorically a case of someone abusing their market position to force a market’s direction. Only a few weeks ago you were wanting Theora to be the standard, now VP8, so I ask you this, how much chance does a codec like Theora have with Google doing this? So it’s NOT about choice at all.
the decoders do not worlk that way. they use a dsp it dosent need to be reprogramed that way. they just need to write library and they can have h264 and vp8.
So, the world should just stick to a patent-encumbered codec because Apple was too short-sighted to think about the possibility of different codecs becoming popular? Are you really that full of Apple?
On top of that, as someone else already pointed out, you present the wrong view on the hardware side. As the CEO of ARM already explained, Cortex-A8 and Snapdragon processors already have the right hardware to accelerate VP8 – you just need to write the correct software. How else do you think Google is going to add VP8 acceleration to existing Android phones with Gingerbread?
As usual, your world revolves around Apple, but that you would be able to twist and turn something like switching to an open and royalty-free codec as anti-competitive is just beyond me. It is borderline idiotic.
At what point did I say that? Show me. That statement shows how little of what you read you actually comprehend. You talk about spin yet that is ALL you ever do. You claim to report on what’s news yet you consistently present “the news according to Thom” and expect everyone to buy your drivel, berating those who dare to have a different opinion.
The point that you miss as someone who has very obviously never put anything on the line in business themselves is that the YouTube app is already on the iPhone, and Google as much as Apple, have benefited from it being there, so why should Apple have to write anything so that an existing app can keep working? Why should users have to upgrade their phone’s OS so they can keep using an existing app? Users will never blame Google for the YouTube player not working any more, they will blame Apple, who will have had no part in breaking it. Bad vibe for Apple, Google wins on the Android front. Anti-competitive. If you’d spent any appreciable time in support you’d know that, but alas.
I realize you have issues comprehending anything business, so let me clarify for you. IMPLEMENTING an open and royalty free codec is fine. Great in fact. SWITCHING on the other hand is a problem if it damages your competition in another market. It would be like Microsoft going into the hard drive business and restricting Windows to only support hard drives from the company they set up. Worse in fact, because at least the existing Windows users could keep using what they had, unlike the existing iPhone users who’s app will be broken.
And my world doesn’t revolve around Apple. I happen to make significantly more money from non-Apple business. My issue is that you and people like you claim that anyone who defends Apple on anything are caught in a reality distortion field, yet it’s very obvious that the opposite is true. Your absolute distain for Apple is so obvious it’s ridiculous, borderline idiotic even, to the point where your world revolves around hating Apple. Your articles have constant snipes at them even when the content has absolutely nothing to do with them, and I’ve yet to see you published a wholly positive article about them like you regularly do about other vendors. Then you have the hide to claim that you’re not anti-Apple.
Go and spend ten or fifteen years in business for yourself putting your money and your family’s very survival on the line then I might have some respect for your views. Until then just report the news because your spin has nothing to back it up.
I understand what you’re trying to say here and you have a couple of good points, but you’re missing some important stuff as well.
Google is already restricting Youtube to a single format, so switching doesn’t restrict anything further. In fact, I’d guess they’ll probably keep a 360p copy around in h264 just for compatibility, at least for a while. They can get away with saying you’ll need VP8 support if you want the higher resolutions.
Also, I can guarantee you that Google themselves would write the VP8 acceleration code if Apple allowed them. Heck, Apple could just allow Flash to run on their phones, and that would be taken care of for them by Adobe. Also, isn’t that kind of the point of writing a mobile phone OS? What are we paying Apple to do, if it isn’t to enable content support in their OS? No one is stopping them from implementing the support, just like we expect them to ship the phone with a browser that can view most websites on the internet without problem. So I think that argument is fairly weak.
Where I think you do have an argument is that Google has the power to change things maliciously, and that would indeed be bad. I just don’t think they are here.
Why would Apple require that a large number of developers must rewrite their apps for them to be included in their app store? Why can the same not be required of Apple? I do not understand the indignation.
Apple as a company has managed to segment out a group of customers that are both wealthy and stupid at the same time. The only positive thing that Apple has ever done for the IT industry is to show that such a segment exists and that large sums of money can be sucked from it with very little effort.
Poisoning the well, if that is the level of discourse that you can come up with, then I’m sure Apple has some wares that will accommodate you just fine.
Apple’s fault.
Apple knows perfectly well that the policy for web standards, and hence HTML5, is “ROYALTY-FREE”, yet Apple still shipped millions of i-devices with no support for open codecs, but instead supported only a patent-encumbered codec.
http://www.w3.org/Consortium/Patent-Policy-20040205/
Apple’s fault. Apple should pay the cost.
Perhaps Apple can ask Google to code a VP8 accelerator for the iPhone/iPad/iPod, and Apple can then upgrade everybody’s i-device for free. That is just about the only way that I can see how Apple can extract themselves from their current PR mess.
Edited 2010-05-24 10:34 UTC
I don’t think that hardware optimization for a codec goes as far as hardwiring the codec, As it is for general purpose computer codec optimization, there would be some motion estimation helper from various unit in the device, so I don’t think that adapting the general code for another codec would be that impossible ( maybe difficult, but hey Apple is pushing the industry to give up flash by saying the transition to HTML5 is trivial, is it turns out not to be ).
I don’t even believe the battery/cpu meltdown you predict. So hold on your horses.
However I don’t even think that people would update flash to read webM video, as they can already read h264 video, and there would’nt be any webm “killer application” that would motivate people.
I hope you understand the liability of of using 264 codec according to the mpeg-la, and that woudl be a problem for open source browser (both present and future) and alternative operating system (ok most of the people don’t care about them, but we do, right ?).
Wow, Apple uses DSPs that are only capable of supporting a single codec? Let me guess – they had the opportunity to get more flexible DSP chips, but Steve didn’t like the color they came in (it clashed with the logic board, so tacky!).
Reality check: the entire universe doesn’t revolve around Apple. The release of WebM actually helps nearly every Google competitor, except for companies with a vested interest in locking customers into a particular video format (for instance, Apple).
No one else is getting all whiny and defensive over WebM, I don’t see Palm, Microsoft, Nokia, Adobe, nVidia, ARM, etc (or their advocates) crying about it. Should Apple get special treatment because their h.264 lock-in agenda has been undermined?
Uh, it’s called being sensible. Let me spell it out for you: WebM has the exact same virtues as Theora, and an infinitely better chance of succeeding. So you’re criticizing Thom for supporting a codec based on merit, rather than being a blind Theora fanboy.
Buwahahahahahaha! What chance did it have before? Oh, and who can we thank for that?
It’s amazing that you accuse Google of anti-competitive behavior and then mention Theora, which Apple has done more to hinder than anyone else (by refusing to even allow 3rd parties to support it on the iDevices).
Tell me, what sounds more like anti-competitive behavior:
Google releasing a royalty-free codec, that Apple or anyone else can implement so long as they don’t try to pull an SCO.
– or –
Apple holding back the adoption of a royalty-free codec (Theora) by refusing to support it & lobbying against its standardization by the W3C, in favor of a codec that Apple just happens to have a financial interest in via their membership in the MPEG-LA.
The assertion makes zero sense considering the way Google operates. The only scenario I can see them removing H.264 support is if MPEG-LA force them to.
This is actually a really interesting point. I’m sure that there is an Apple-Google deal that prevents Google from breaking the iPhone app for the foreseeable future, though.
Since Eric Schmidt apparently has Steve Jobs penis envy, who knows what Google is going to do tomorrow?
Looking at the “park joy” example provided by the second comparison the x264 encoded image is visibly sharper than its VP8 counterpart, especially in parts with lots of foliage and grass (i.e. small details). I’m not familiar with the encoder settings so I would like to know if the settings used for x264 produce encodings compatible to the baseline profile.
That’s to be expected. A similar (or same?) scene was used to show the improvements in Theora – this was also less blurry after the codec was improved.
VPx codecs generally tend to blur the image to save bit. I guess VP8 can fix that just like Theora (being based on VP3) did
Edited 2010-05-23 19:36 UTC
This looks pretty good, differences seem small (enough). I wonder how well a efficient a good decoder will be.
I’m always bothered by the “the visual difference is so small that it doesn’t matter” comments.
If you are comparing codec A and codec B and codec A is better than the other in ways you can barely see, it more often than not means that you can lower codec’s A bitrate to achieve codec’s B quality, thus saving bandwidth.
By the way I’m not talking about VP8 vs H.264. The differences on the first link are indeed really minor and on the second I can’t spot any.
Hey people, you are trying to find epsilon difference between the 2 codecs.
Do you really notice any difference on quality when playing a movie ?
The most important isn’t quality because of the epsilon difference, but the terms of the licence and the freedom to use the codec everywhere.
Stop talking about quality difference, I really don’t notice any difference in quality. And for acceleration, in Linux vp8 coded video runs better than a h264 one.
(at least on my small system)
Sounds good, I hope they can keep it that way or possible even improve on it.
First they should use best encoders in each class, for exmaple two pass x264.
And anyway i see a differences, slightly in favor to H.264. You need to click on images to see full size versions. (Full double blind test would be better to judge here).
But as VP8 is free (and we hope without patent issues on it), it is out of question which to use.
Still VP8 quality can be improved by some adaptative techniques without changing decoders or bitstream protocol.
VP8 doesn’t have to be better than h.264, and I sincerely doubt it can be given the very mature encoders available for h.264 and you can bet that the x.264 guys aren’t going to wait for vp8 to catch up. Also given the patent situation vp8 is denied the use of many useful algorithms that could improve things a lot.
But the question isn’t can vp8 beat h.264 in all cases, its can vp8 be good enough for streaming video that it is a viable patent free alternative. If patents weren’t an issue h.264 would be the clear winner, but patents are an issue and they can’t just be ignored if your trying to do a full comparison because technical issues won’t be the only thing potential users are looking at.
This isn’t Beta max versus VHS.
As VP8 is already good enough for internet streaming (yes it is, stop trolling), maybe we could shift focus on improving high-resolution non-streaming codecs. Theora could still be improved, and Dirac, like all wavelet-based codecs, needs a breakthrough innovation – or it will remain as useless as JPEG2000.
It is important because if open video codecs don’t jump ahead of proprietary codecs (the way audio ones did), the latter will always patent the next good idea.
Edited 2010-05-23 16:44 UTC
I know they won’t drop Flash anytime soon. But will they drop support for H.264? Maybe, but they certainly haven’t given any indication of this yet.
It would be less expensive than serving Flash Video, MP4 and WebM. Also, they recently dropped support for older versions of Flash, but only for Desktop OS’s. But dropping support for MP4 would immediately mean no iPhone/iPad users (at least in the short run). I just don’t think Google would risk making existing viewers unhappy like that.
I think if they do drop a format it’ll be carefully done. When they have some way to guarantee they can keep viewers. Maybe if they could update Youtube app to include the VP8 and WebM built in.
Dropping H.264 would mean that the youtube button on idevices would no longer work. Apple could roll out an update that links it to a new VP8 app but they sure as hell wouldn’t be happy about it and there would still be the hardware decoding issue.
As the x264 dev snarked on how VP8 is similar to h264, it shouldn’t be too hacky to make those hardware decoders chew through VP8.
Changing new models is one thing but most devices in the wild have hardware decoders that can’t be updated.
But as they say you can’t make an omelet without cracking a few eggs.
I wonder if this is really true. I have yet to find a single decoder that works this way. Do you know of any chip that works in this way? in that case i would be glad if you could name it so i can look it up i try to follow news letter from ic makers.
I think the big reason for this are first it complex to make a chip that implements the whole h264 in hardware ex that you just can stream h264 to the chip and get decoded frames in return. second if it implements h264 in firmware then the chip makers would have to pay mpgla.
however if you just make a chip that can handle the math behind h264. you can leave constructing a h264 library to the manufactures and you should be clear from infringing patents. And that how it works on most phones that i have seen in the wild
As an end user who only watches low quality youtube videos I can’t tell a difference between the two. I’ll be glad once this whole debate is over. It doesn’t matter to me which codec gets used, I’m betting the average user couldn’t notice and doesn’t care either.
The http://www.quavlive.com/video_codec_comparison has been updated, and VP8 is as good (or, maybe, as bad) as h264 encoded with the libx264 (is it x264?) on a visually complex video. The bitrate of the output is different from the one entered in command line (rounding?), and is always lower with VP8. Also, the size of the video file is always smaller with VP8. Both are beneficial for streaming.
Notice that the x264 video done by quAVlive, on the same video “park joy”, is noticeably worse than the ones done by the x264 dev Dark Shiraki:
http://193.204.59.68/comparison/park_joy_1080p.y4m_x264.avi_jpg/002…
vs.
http://doom10.org/compare/x264.png
http://doom10.org/compare/x264baseline.png
Edited 2010-05-23 19:47 UTC
Tried to download the linked files and got this helpful message from VLC (OS X):
No suitable decoder module
VLC does not support the audio or video format “VP80”. Unfortunately there is no way for you to fix this.
😀
A quick googling (…yeah, I know) shows VLC should have VP8 support since the 1.1.0 release.
And that only a win32 build is available for now.
Try on another computer, launch bootcamp or… Just wait? We are all too nervous and eager to know the final word on this subject, I think, between the amount of publicity http://x264dev.multimedia.cx/?p=377 already got (from Steve Jobs himself) and the number of comments on OSnews…
… in terms of quality, even if it isn’t as good as the output from a hand-tuned run of the best H.264 encoder around. What remains to be seen is if patent threats will end up torpedoing it.
That doesn’t automatically give software a win. Absolutely terrible statement.
We already knew this. Prove it time and time again.
No arguing there.
The Park Joy video is an extremely difficult one to encode, which is why it’s often used in the these encoder tests. Note that in addition to the high level of motion and detail present, it’s running at 50 fps. So for a standard video, you would cut the bitrate in half and have identical levels of quality.
VP8 clearly looks blurry in that video when you take a screenshot and compare them side by side. When you view the video in motion, though, it’s tough to spot any difference unless you are really trying to spot it. And the other video with the bee shows that there’s really no difference in the result for some easier videos.
VP8 is clearly good enough for web videos, it’s going to be other factors that determine it’s success. Patent issues and hardware support spring to the top of list.
OK, really, if you can put these two up in two tabs, then tab back and forth between them at their full resolution, and can’t see any difference between them you may want to get your eyes checked out.
http://193.204.59.68/comparison/park_joy_1080p.y4m_x264.mkv_png/002…
http://193.204.59.68/comparison/park_joy_1080p.y4m_vp8.mkv_png/0028…
I mean, really, the VP8 one looks like a complete mess compared to the x264 one in that example.
Source ? Encoder settings ?
I updated the x264 encoded sequence with the latest encoder version (93). The command line is:
x264 –bitrate 15000 –threads 4 -o ouput.mk input.y4m
It is from the “Another comparison” part of the story as posted by Thom, linked up above, the one that Thom says he can’t spot any difference in. All the info is listed there.
The H.264 one has artefacts, and the VP8 one is slightly blurred (normal for motion frames). Almost identical, quality-wise.
The VP8 one is unencumbered by patents for everyone to use.
Everyone uses H.264 = 0.00001% of people make money, and everyone else pays.
Everyone uses VP8 = 99.999999% of people reduce their costs, and no-one pays.
Win-win for VP8.
Edited 2010-05-24 10:20 UTC
Just so you know, that green stuff is actually supposed to be grass and not some homogeneous pile of slime. The VP8 looks absolutely atrocious and I am rather surprised that anyone would try to defend it in that comparison.
Patents and pricing aside of course, I am just discussing the technology here, since that is what the story is about.
You prefer artefacts that aren’t there? When things are moving, people see blur. Even cameras see blur.
Your examples are very high resolution. People don’t have that much bandwidth on the net, they would be watching that video at one frame every ten seconds. (We are talking here about a codec for the web, not for a blueray player).
To give a little more bandwidth to high-motion areas and de-blur (without introducing invented artefacts) is a matter of tuning (of the encoder only). Activity masking and Altered Skip weighting are techniques that have helped Theora improve recently, and at first blush these look as if a bit of tuning might also help VP8.
http://people.xiph.org/~xiphmont/demo/theora/demo9.html
There doesn’t seem to be anything unique to Theora in those methods.
The basic, unpolished VP8 encoder performance is almost indistinguishable from H.264. A bit of fine tuning of the encoder here and there to polish out effects like these, and it will be sweet. Just discussing the technology here, there is absolutely no reason why we should invoke costs for 99.9999% of the people on the planet, and direct money to 0.0001% of the people, just for the sake of a bit of fine tuning of the VP8 encoder.
Oh, and because the fine-tuning needs to be done only to the encoder, people can go ahead with the decoder (player) software embedded in browsers right away.
Edited 2010-05-24 10:53 UTC
1st comparison:
In 1 and 4, H.264 was obviously superior. 2, 3, and 5 I couldn’t tell a difference in quality (H.264 is a bit blocky in its shadows, but VP8 smoothed those over a bit too much, or made it splotchy–very much a draw), and 6 looked better with VP8. In #1, look how much clearer the man’s wrinkles and dimples are in H.264.
So, for web streaming: it’s ready right now.
2nd comparison:
Even my Superbit DVDs aren’t all up to 7.5Mbps. I’m not terribly enamored with HD, I guess. It would also have been nice to just see the saved 480 frames at 100%, too, rather than scaled up. Some of the live frames are fuzzy, but not too bad. I’ll stay optimistic about the encoder. The live video as a whole looks quite good, IMO.
For high quality video: the encoder needs some work, but it’s not bad.
Most of the, “indistinguishable,” Theora videos looked like Hell with any real motion. VP8 seems to be up to the task of competing with H.264, and is free, to boot. Let’s give it a year to spread around, get a more mature encoder, and so on, then ditch H.264, and rejoice.
Edited 2010-05-24 11:34 UTC
An Easy Way to Convert Videos to WebM
http://openvideoalliance.org/2010/05/an-easy-way-to-convert-videos-…
http://www.mirovideoconverter.com/
When I was looking at the linked page, it already contained comparisson to x264, and the images could be clicked to open the full resolution version. My monitor happens to be 1920×1200 and with my browser fullscreen, I can look at them unscaled. Loading them in two separate tabs, I can flip forth and back.
With the bee, I agree the difference is almost not noticable, I think x264 has less block artifacts, the gradients are somewhat smoother.
However with park scene, I have to say the difference is staggering. x264 is playing in a whole different league. There is soo much more detail in all the plants and suroundings. I really wonder how someone would not notice it.
What a mess !!!
I see an half to dispute claims of other half.
And video quality and so on and so forth.
And bandwidth and so on and so forth.
And patent encumbered and so on and so forth.
And why not organise a blind test for a week with a vote ?
Show two sequences to the world and let’s vote !
Vote for A, vote for B, Vote for C: No diffs.
Results will be show a week later.
And maybe, to see in the comments who vote for what will bring a lot of fun… A week later.
I just gave a quick look to the “Park Joy” videos (the videos themselves and not the still images) on the quavlive link. My conclusions:
– h.264 has a lot more artifacts than VP8;
– on still screenshots, h.264 wins in all cases;
– on (almost) all resolutions (in motion), both codecs seemed the same;
– the exception was SD video, which seemed strange in h.264 and more “natural” in VP8.
At least it is my opinion, but who cares? Here is my opinion about the much more interesting topic of the codecs themselves:
– The visual output of each one is incredibly different on low framerates;
– Yet, both are able to reproduce the intended image!
– So, they are not comparable;
– This happens because for us to compare them, we would need an objective way of deciding which are good and bad losses.
– We don’t have that.
– So, opinions on how close to reality it gets will vary from person to person.
At least it is my opinion… on something much more interesting than a boring comparison of different moving images.
Exactly. People actually see motion as blur. There is no real point in precise sharp definition for parts of the video which are in high motion … people are going to see it as blur anyway.
These observations also highlight that there are major differences in approach between h.264 and VP8. The codecs use distinctly different methods to achieve the same end (compression of digital video data). Ergo, one would surmise that these codecs do not infringe on one another’s patents.