4 ms·
> "But, we already have all this expensive stuff for H.264! We spent a lot of time and money buying it and figuring out how to make it all work!" You cast this
by bonaldi 16y ago
> "But, we already have all this expensive stuff for H.264! We spent a lot of time and money buying it and figuring out how to make it all work!"
You cast this as if investment and legacy are irrelevant quibbles, when in fact they're commercial considerations of the kind that are pretty relevant when you want to do something like establish the video tag.
> While your expensive super-duper video authoring toolchain does not now support WebM, if Google has its way, it one day will and you'll encode WebM/VP8 just like you encode H.264 today.
This is a big assumption, and right now the only reason you would do it so you can serve ... well, virtually nothing. One day soon, three browsers in HTML5. You're certainly not reaching anyone new. By contrast, h.264 is well beyond the tipping point, lets you reach all-new mobile audiences, and has a huge installed base, and a toolchain that runs from home-level to corporation.
The drive for HTML5 video depends entirely on making it fit as closely as possible to the path of least resistance that is Flash Player. A decision like this makes HTML5 more expensive and more complicated for people to support, which simply means they won't.
> Some sources have claimed VP8 is much better.
Cite.
- bzbarsky 16y agoWhich one is better depends on what you're doing with it and what sort of decoders you care about. If you read Dark Shikari's analysis carefully, he says that VP8 is better than H.264 Baseline Profile. As it happens, H.264 Baseline Profile is all that the "hardware acceleration" in most mobile devices handles (see http://weblogs.mozillazine.org/roc/archives/2010/05/its_a_relief_to.html http://weblogs.mozillazine.org/roc/archives/2010/05/its_a_re... ). So if you want to get better quality than VP8 out of H.264 on the web you need to either lose hardware acceleration or get different hardware (I'm not sure how much of this can be done with the existing hardware and different firmware, and how much actually needs new hardware; the parts of H.264 non-baseline that are not hardware accelerated are the more complicated ones, obviously). Of course VP8 also requires changes to the decoding hardware/firmware; I also can't tell you whether those changes would be such that the result would be able to handle non-baseline H.264. But the upshot is that current VP8 video on the web can easily be higher quality per bit than current H.264 video on the web, because the latter is self-constrained by hardware support and the former is not worrying about it for the moment, since it's not there anyway. All of which is a far cry from "VP8 is much better". ;)