"The x264 developer's analysis is certainly interesting, but I don't think it is the final word on "WebM vs. H.264". Not only is WebM doing well compared to the H.264 baseline profile, which is what's relevant to HTML5 video, but I think WebM will continue to improve both quality-wise and performance-wise."
From the x264 developer's article:
"Update: it seems that Google is not open to changing the spec: it is apparently “final”, complete with all its flaws."
The opera.com entry addresses that update. Look at the WebM FAQ: They have a separate branch for possible improvements for inclusion on the main branch.
I doubt that anything is really final in google's hands. just look at how fast android is changing and evolving. Google will do what it needs to do to reach their goals, even if it means that they need to break backward compatibility. This is a company with so much resources it can probably design its own reference hardware implementation of vp8 at whatever stage of its evolution, regardless of backwards compatibility - and also persuade chip makers like TI and Qualcolm to include it in their product line at a moment's notice ie within 4 months or so. In this respect, I think the "finality" is overrated - the reviewer / x264 developer is thinking too small.
the reviewer / x264 developer is thinking too small
And, there is always a bit of "uh oh, my life's work is suddenly becoming irrelevant, even though it's technically better". One thing I've learned from reading HN is that good technical solutions rarely get you much. What you need is a good product.
H.264 is a great technical solution, but a horrible product. VP8 is not as good technically, but it's exactly the product the Internet needs. Sad, but that's the reality of it.
The work in x264 isn't that irrelevant suddenly. H.264 has great market penetration and isn't going anywhere. And x264 could already be adapted into a VP8 encoder if necessary; it'd work better than libvpx, as the fundamental algorithms and psy optimizations are all better tuned.
Yeah, Jason's life work is really in jeopardy. I mean, as the primary author of the best performing video encoder in existence in his 3rd year of undergraduate study, how will he regain any meaning in his life?
The technical analysis is sound -- technically, WebM is not as good as H.264. But considering it's mostly for cat videos, it doesn't really matter.
The super high quality stuff will take an extra minute or two to download, but you won't have to pay a licensing fee for it. The movie and the hardware and software that play it will be much cheaper. A compromise, yes, but not a really difficult one.
If that turns out to be the case, then everyone should go back to H.264. But honestly, I have a feeling that Google looked into this before they decided to use it for YouTube. Remember that patents cover exactly what they describe, not things similar to what they describe.
Google could always also just buy the patent, if it turns out to be a problem. Basically, I am not ready to dismiss this yet. I trust Google's legal team over one H.264 programmer.
So far the only thing Google said is "they are very confident" which legally means nothing. They are not going to indemnify everybody that gets sued over VP8, are they?
Wow i fail to understand why you were down voted!
Is HN new place to spread FUD?
Just because some bumpkin developer comments that code is similar to H.264 does not makes it an infringement. Also a company like Google which has thousand times smarter engineers should have surely thought about it before spendin ~125M$
People here are going bonkers over some comment by naive code monkey.
Maybe google has patents enough to coerce MPEGL LA!
who knows, but spreading FUD is bad.
Esp when you are a naive code monkey!
On2 does not have the resources of Google and the entire internet at their disposal. Even the x264 developer pointed out that the VP8 spec was clearly unfinished.
Sorry, ON2 is a codec company that prior to being bought by google was in the business of selling their codecs, VP8 included. Now, either they were good at it, then it was OK to pay that price and we would have a good codec. Or they were not and it needs google's resourses and "the entire internet" to fix that, but then google overpaid. Which one is it?
It's a good codec. But as you can see, the specification was clearly not finished. So On2 sold a codec package that wasn't very polished. Doesn't mean it wasn't worth the money. It just means that polish needs to be applied, and now that it's open, it will.
I seriously doubt that they have had remotely the number of skilled man-hours as the most popular open source codecs. The source code would back that assertion up, if they're doing things like simply groveling through 2^16 combinations of things looking for the best.
Either they weren't skilled or they didn't have time; I favor the latter theory. Feel free to advocate for the former if you like. But you can't have it both ways, because the results were clearly not well-skilled people spending lots of time on the problem. One or the other is not true.
Regarding the patent:
I suggest reading original email to Wikipedia developer mailing list
To quote
"""
On the patent part— Simply being similar to something doesn't imply
patent infringement, Jason is talking out of his rear on that point.
He has no particular expertise with patents, and even fairly little
knowledge of the specific H.264 patents as his project ignores them
entirely. Codec patents are, in general, excruciatingly specific — it
makes passing the examination much easier and doesn't at all reduce
the patent's ability to cover the intended format because the format
mandates the exact behaviour. This usually makes them easy to avoid.
It's easy to say that VP8 has increased patent exposure compared to
Theora simply by virtue of its extreme newness (while Theora is old
enough to itself be prior art against most of the H.264 pool), but
I'd expect any problems to be in areas _unlike_ H.264 because the
similar areas would have received the most intense scrutiny. ... and
in any case, Google is putting their billion dollar butt on the line—
litigation involving inducement to infringe on top of their own
violation could be enormous in the extreme.
""
Dont trust some stupid kids comments for god sake knowledge in programming does not equal legalese.
The amusing thing is that it was actually a good review, as the author is too smart to actually lie about it (though he does make a few minor technical blunders). Just the surface layer of nerd rage over a core of deeply technical nit-picking leads everyone to believe otherwise and link to it as if it revealed anything we didn't already suspect, or indeed hope for.
I mean he says it's better than H.264 baseline. If you're watching it on an iPod or iPhone then that's the only profile they support. In other words Android phones will have better maximum quality video than Apple's. Is that part getting overlooked somehow?
To reiterate, if you only want to create one file for all your web viewers then H.264 baseline is your best option, and VP8 beats that.
Another general theme is that it's very similar to H.264. If you put your armchair patent lawyer hat to one side for a moment, isn't "similar to H.264" a really good thing to say about a codec? Personally I think it's good for H.264 to be knocked off its pedestal. Just because Steve Jobs mentioned it in a keynote it seems to have attained the same mystical halo that surrounded PPC, Altivec, AAC or Firewire, untouchable by mere mortals with their X86, MMX, MP3 and USB2 when really they're all just fairly standard technologies with pros and cons and susceptible to external market forces like any other tech.
All the flaws he finds are unquantified in their impact, much like the recent attack piece on Ogg by his colleague where fatal flaws were later revealed to save 7-bits per media file or be 0.1% less efficient than MP4. Maybe they are real problems that annoy software encoder purists, design flaws or actual bugs that can't even be fixed until a spec revision but do you actually care as a customer? (Again was H.264 handed down from God or is it just a committee written spec like most other technologies. Are we claiming it perfect or flawless just because it's the incumbent?)
About the only one that he quantifies is lack of B-frames. (Actually left out because of patents, yet this still gets criticized by someone who thinks they're also careless about patents) But B-frames have costs as well as benefits, something clearly shown by the fact that they were left out of H.264 baseline as well. If they're all sunshine and lollipops then why leave them out? Like many things in codecs and software generally, it's a tradeoff, more decode power for extra compression which may make sense on a destkop but not a laptop or mobile device.
Finally, note how often in this (and his preview article) he says VP8 will not be a serious challenger unless(!) they adopt psy optimizations that make x264 so much better than the other H.264 implementations. You'd think this was either impossible, or unthinkable, but it's not. It's only a matter of time and at least the Xiph guys have experience of doing exactly this on a similar codebase and they've been working on VP8 for weeks already.
> though he does make a few minor technical blunders
Such as?
> I mean he says it's better than H.264 baseline. If you're watching it on an iPod or iPhone then that's the only profile they support. In other words Android phones will have better maximum quality video than Apple's. Is that part getting overlooked somehow?
"Better" doesn't mean "much better"; a better residual coder is useful, but H.264 has better reference frame system - On2 seems to love idiosyncratic systems which aren't as good - and much more flexible adaptive quantization. Which is the basis of x264's psy optimizations, so the same (fundamentally good) ideas probably can't be implemented as well.
> It's only a matter of time and at least the Xiph guys have experience of doing exactly this on a similar codebase and they've been working on VP8 for weeks already.
IIRC Theora barely implemented rate-distortion optimizations in the first place, let alone Psy-RD - you have to get that out of the way before you can do the really interesting things.
However, I don't think VP8 uses the weird Hilbert coding of the older system, so it might be easier to implement all of that. Besides, you can just copy it from x264.
27 comments
[ 4.5 ms ] story [ 83.6 ms ] thread"The x264 developer's analysis is certainly interesting, but I don't think it is the final word on "WebM vs. H.264". Not only is WebM doing well compared to the H.264 baseline profile, which is what's relevant to HTML5 video, but I think WebM will continue to improve both quality-wise and performance-wise."
From the x264 developer's article:
"Update: it seems that Google is not open to changing the spec: it is apparently “final”, complete with all its flaws."
Mhm.
And, there is always a bit of "uh oh, my life's work is suddenly becoming irrelevant, even though it's technically better". One thing I've learned from reading HN is that good technical solutions rarely get you much. What you need is a good product.
H.264 is a great technical solution, but a horrible product. VP8 is not as good technically, but it's exactly the product the Internet needs. Sad, but that's the reality of it.
The super high quality stuff will take an extra minute or two to download, but you won't have to pay a licensing fee for it. The movie and the hardware and software that play it will be much cheaper. A compromise, yes, but not a really difficult one.
I'm not so sure about that. Yesterday's analysis seemed to predict some questionable usage of H.264 bits in the encoder.
Google could always also just buy the patent, if it turns out to be a problem. Basically, I am not ready to dismiss this yet. I trust Google's legal team over one H.264 programmer.
People here need to get a life, no one is stupid enough to spend 100M$ for some copy paste C code!
And you have 3 Up Votes!! has HN turned into a zoo of code monkey listening to only their kind and thinking everyone at Google is a stupid???
Just because some bumpkin developer comments that code is similar to H.264 does not makes it an infringement. Also a company like Google which has thousand times smarter engineers should have surely thought about it before spendin ~125M$ People here are going bonkers over some comment by naive code monkey. Maybe google has patents enough to coerce MPEGL LA! who knows, but spreading FUD is bad. Esp when you are a naive code monkey!
VP8, and the libvpx codebase, is older than x264, as it said in the original article.
Either they weren't skilled or they didn't have time; I favor the latter theory. Feel free to advocate for the former if you like. But you can't have it both ways, because the results were clearly not well-skilled people spending lots of time on the problem. One or the other is not true.
Dont trust some stupid kids comments for god sake knowledge in programming does not equal legalese.
I mean he says it's better than H.264 baseline. If you're watching it on an iPod or iPhone then that's the only profile they support. In other words Android phones will have better maximum quality video than Apple's. Is that part getting overlooked somehow?
To reiterate, if you only want to create one file for all your web viewers then H.264 baseline is your best option, and VP8 beats that.
Another general theme is that it's very similar to H.264. If you put your armchair patent lawyer hat to one side for a moment, isn't "similar to H.264" a really good thing to say about a codec? Personally I think it's good for H.264 to be knocked off its pedestal. Just because Steve Jobs mentioned it in a keynote it seems to have attained the same mystical halo that surrounded PPC, Altivec, AAC or Firewire, untouchable by mere mortals with their X86, MMX, MP3 and USB2 when really they're all just fairly standard technologies with pros and cons and susceptible to external market forces like any other tech.
All the flaws he finds are unquantified in their impact, much like the recent attack piece on Ogg by his colleague where fatal flaws were later revealed to save 7-bits per media file or be 0.1% less efficient than MP4. Maybe they are real problems that annoy software encoder purists, design flaws or actual bugs that can't even be fixed until a spec revision but do you actually care as a customer? (Again was H.264 handed down from God or is it just a committee written spec like most other technologies. Are we claiming it perfect or flawless just because it's the incumbent?)
About the only one that he quantifies is lack of B-frames. (Actually left out because of patents, yet this still gets criticized by someone who thinks they're also careless about patents) But B-frames have costs as well as benefits, something clearly shown by the fact that they were left out of H.264 baseline as well. If they're all sunshine and lollipops then why leave them out? Like many things in codecs and software generally, it's a tradeoff, more decode power for extra compression which may make sense on a destkop but not a laptop or mobile device.
Finally, note how often in this (and his preview article) he says VP8 will not be a serious challenger unless(!) they adopt psy optimizations that make x264 so much better than the other H.264 implementations. You'd think this was either impossible, or unthinkable, but it's not. It's only a matter of time and at least the Xiph guys have experience of doing exactly this on a similar codebase and they've been working on VP8 for weeks already.
Such as?
> I mean he says it's better than H.264 baseline. If you're watching it on an iPod or iPhone then that's the only profile they support. In other words Android phones will have better maximum quality video than Apple's. Is that part getting overlooked somehow?
"Better" doesn't mean "much better"; a better residual coder is useful, but H.264 has better reference frame system - On2 seems to love idiosyncratic systems which aren't as good - and much more flexible adaptive quantization. Which is the basis of x264's psy optimizations, so the same (fundamentally good) ideas probably can't be implemented as well.
> It's only a matter of time and at least the Xiph guys have experience of doing exactly this on a similar codebase and they've been working on VP8 for weeks already.
IIRC Theora barely implemented rate-distortion optimizations in the first place, let alone Psy-RD - you have to get that out of the way before you can do the really interesting things. However, I don't think VP8 uses the weird Hilbert coding of the older system, so it might be easier to implement all of that. Besides, you can just copy it from x264.