Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Google's assumption: People will add WebM encoding to their already complicated video workflows

What will actually happen: Chrome will get served h.264 wrapped in Flash.

Lose all round, then.



Well i don't know. What i see :

Adobe is gonna support webm. So having only one format is gonna be possible.

Browsers who supported or were gonna support H264 :

- Safari (5% market share) - IE9 (0% market share right now, probably around 15% in 3 years) - Chrome (around 13 %)

Browsers who supports Webm :

- Firefox (30% market share) - Chrome - IE9 will probably support it via codecs which is better than nothing

The big deal breaker i see is the mobile devices who natively support H264. But as a long term move i can only approve what google is doing.

Also :

> People will add WebM encoding to their already complicated video workflows

Most people video workflow is youtube/vimeo/dailymotion video workflow. All of which seems ready to support webm.


> The big deal breaker i see is the mobile devices who natively support H264

You kind of buried this but this is the true deal breaker. There aren't (and probably won't be) hardware WebM decoders.

And Firefox doesn't support WebM yet. You'll have to wait on version 4 (0% market share right now as you said for IE9).


> There aren't (and probably won't be) hardware WebM decoders.

The very article states that there are hardware WebM decoders, not only that but Google is licensing the technology for free as in zero dollars:

http://blog.webmproject.org/2011/01/availability-of-webm-vp8...


Licensing isn't the (only) issue for asics. Hardware decoders are only reasonably priced if they're being produced at scale. If I'm a device manufacturer and I have a choice between getting h.264 for free because it's on the SoC I'm using and paying multiple dollars (!) for a WebM decoder, not to mention wasting valuable board space and paying for it to be soldered on, which do you think I'll choose?


1) You aren't going to get H.264 decoder for free. There will be always at least license fees to MPEG-LA. 2) Current hardware video decoders are DSPs. You are not going to "waste valuable board space". It is a program in ROM, it is easy to change H.264 to VP8, you will probably even save some space.


1) Those license fees approach zero as you produce more units.

2) If I'm not mistaken they're not general purpose computers. If they were what would be the point? Why not use a math coprocessor?


Most hardware video decoders are special-purpose DSPs that the manufacturers write firmware/microcode for to decode particular formats. The instruction sets of the DSPs are well suited to operations normally performed when decoding (or encoding) video.


> If I'm not mistaken they're not general purpose computers. If they were what would be the point? Why not use a math coprocessor?

They are not general-purpose, but that doesn't mean they're not easily re-programmable either. Consider the example of GPUs.

I want to say some SNES games used a DSP chip, there are several known to emulator authors, including two versions that used the exact same hardware with different microcode (and therefore different abilities). So it's been done before at least.


DSP's are like processor units in GPU. Optimized for fast and parallel multiply and add computations (and some other basic signal processing stuff). One codec is not that much different from other from computation point of view.

The accelerator units are usually filters that operate over a region of memory while processor is busy computing something else. These can be made fixed function, however most of them are programmable to support multiple steps in codec processing.


DSPs are programmable, limited functionality, computers.

TI I believe is the largest vendors of DSPs for hardware decoding/encoding

http://focus.ti.com/dsp/docs/dsphome.tsp?sectionId=46&DC...


Presumably the next Android Dev phone will have a SoC that supports WebM... otherwise yes this move is toothless.


Someone else's SOC?


Yes. The only smartphone makers that I can think of that design their own chips are Apple and Samsung.


Your assumption is valid only in case when you don't count smartphone makers that actually design their own complete phones and not license baseband implementation from someone :)


To clarify, I meant choose option C) a SOC that supported my requirements.


But it is not sure whether Apple will adopt them. Could the competition with iPhones have influenced this decision?


which means that not one of the tablet/mobile devices out there right now supports webM.

is that true? how many released mobile devices have hardware support for the webM decoder?


None. And its likely that software decoding of WebM will behave on mobile devices the same way Flash behaves. Okay in newer devices, but laughable in previous generation devices.


> You kind of buried this but this is the true deal breaker.

Well i mentionned it. I'm at least partially intellectually honest :)

> Firefox doesn't support WebM yet. You'll have to wait on version 4 (0% market share right now as you said for IE9)

That's totally true, but from experience and statistical evidence, i think firefox users are more inclined to upgrade their browser than IE user are.

> There aren't (and probably won't be) hardware WebM decoders.

I don't think that's true


> That's totally true, but from experience and statistical evidence, i think firefox users are more inclined to upgrade their browser than IE user are

Very true. Our site has had for a while only a couple percent of non 3.5+ Firefox traffic.


There are hardware decoders but nobody uses them at this point. It will be a very long very painful process. I am not sure whether it is good or bad.


There are already hardware WebM decoders, in fact they've just announced hardware encoders too.

They link to a relevant announcement in the linked blog post:

http://blog.webmproject.org/2011/01/availability-of-webm-vp8...

And the update rates of Firefox and Chrome and totally different from IE, especially since version 9 doesn't support XP.


There aren't _(and probably won't be)_ hardware WebM decoders.

http://googland.blogspot.com/2011/01/g-availability-of-webm-...

The Oulu team will release the first VP8 video hardware encoder IP in the first quarter of 2011. We have the IP running in an FPGA environment, and rigorous testing is underway. Once all features have been tested and implemented, the encoder will be launched as well.


No, there are hardware webm decoders. Eg: "Broadcom Accelerates WebM Video on Mobile Phones" from http://www.broadcom.com/press/release.php?id=s471536 And that's from eight months ago. Broadcom is a huge maker of mobile SOCs; I haven;t checked the others, but I bet they support webm too.


The problem is that content providers have yet another option to choose from, but so far one that is supported by almost no one. Firefox will support WebM, and so will Chrome, so to reach those browsers you either need WebM, or Flash.

Flash also supports h.264 video, as do most mobile devices (Android, iPhone, iPad, iPod Touch, Windows Phone 7, Zune even) and game consoles (XBox, PS3, and afaik the Wii). In fact from what I can tell, the only platform that doesn't support H.264 is Firefox without Flash. Compare that to the massive amount of existing platforms and devices which don't support WebM (and have no hardware WebM decoding), and it seems like moving to WebM makes much less business sense.


Software decoding video isn't really that big of a deal. Even mobile processors are powerful enough...

(yes, it'll consume battery like a dry horse drinks water in a desert)


> (yes, it'll consume battery like a dry horse drinks water in a desert)

For mobile devices, that's a huge deal. There are no resources more scarce than battery power on a mobile device.


I don't disagree, but Android users seem to get by more or less "ok" without hardware 264 decoding (at least the ones who have devices without hardware decoding).

Personally, I just leave my mobile devices plugged in most of the time anyway so they're always topped off, but that's just me.


>mobile devices plugged in most of the time

DOES NOT COMPUTE.


Well, having a desk job does tend to make me stay in one place for the most part. If I know I'm going to be sitting there for longer than an hour -- I plug it in.

In the car? Plug it in.

etc.


That's the fast way to ruin your batteries. Don't do it.

https://secure.wikimedia.org/wikipedia/en/wiki/Battery_memor...


> The big deal breaker i see is the mobile devices who natively support H264

And of coure it's only a coincidence that most of those are the ones competing with a Google product.


And all the embedded chips in cellphones,m set top boxes and mp3 players are going to support WebM?

Thats going to take a while - the lead time on new DSP families isn't quick.

And how long before their are optimized open source libraries like ffmpeg and x264?


FFMPEG claimed to have the fastest VP8 decoder on the planet back in July:

Announcing the world’s fastest VP8 decoder: ffvp8

http://x264dev.multimedia.cx/archives/499


ffmpeg does already supports webm, and the encoder is quite good from what i gathered, since it's done by the same crew than x264


ffmpeg only has a working webm decoder. xvp8 (the x264-based encoder) hasn't been touched for a few months and is basically vaporware.


In #ffmpeg on freenode:

(09:50:48 PM) sjuxax: Guy on HN said this: "ffmpeg only has a working webm decoder. xvp8 (the x264-based encoder) hasn't been touched for a few months and is basically vaporware"

(09:50:50 PM) sjuxax: true?

...

(09:52:34 PM) Dark_Shikari: not quite true

(09:52:42 PM) Dark_Shikari: close, but not quite.

(09:52:58 PM) Dark_Shikari: 1) the github tree hasn't been updated

(09:53:05 PM) Dark_Shikari: there is more stuff that isn't in the tree yet

(09:53:13 PM) Dark_Shikari: 2) Ronald is dealing with his first baby boy, give him some slack

(09:53:20 PM) Dark_Shikari: 3) Google just hired him full-time for a year to work solely on xvp8

and later on...

(10:12:27 PM) Dark_Shikari: tl;dr: it's kinda vaporware, there's a bit of work done, but it will stop being vaporware in march when Ronald goes to work for Google.


Assuming you're sjuxax, thank you for the research! I think a lot of us sometimes forget how simple it is to go to the primary sources in cases like this.


As much as google can seem pretty sinister these days, it's reassuring that their strategy for implementing a video decoder is "hire the dev on the leading open source project for a year."


The encoder is good, but it doesn't hold a candle to x264. It's is still _very_ slow.


Google as always wants us to use their beta software. This thread has generated much debates. I'm always suspicious when big corporation touts ideology as their cause. Don't fall into the pray. Just asked the question "Where is the money?" and you can guess the real reason for their move. Google seems to think that they have the clouts to influence all area of humanity, in this case the audio/visual entertainment industry that includes set top boxes, chip and hardware makers etc. They are fighter all wars (MS Office, iPhone, Bing, Facebook) by spreading themselves thinly. I believe these few years will see the start of decline of Google as a company.


IE8 is at 33% share now. IE7 is about 7%. I expect most on IE6 are still on XP. So I'd expect that we'll see similar uptake rates for IE9, if not more given the HTML5 benefit (IE8 doesn't have much clear benefit over IE7 from what I can tell).

So I'd say expect IE9 to be closer to 27% in 3 years.

Of course this ignores two big questions:

1) Is IE still hemorraging market share? 2) Does IE9 actually reverse the trend of people using Chrome?


IE 9 won't support XP users (60% of Web-connected PCs) so they will only be able to get a fraction of the IE 7 and IE 8 users to upgrade.


Firefox overtook IE in Europe recently (38%), and it wasn't at the expense of Chrome which is higher in the EU than in the US (15% v 12.5%)


And why will that happen? Because people like to pay license fees so much they will be all too eager to pay the fees for both h.264 encoding and flash?

Yes, businesses that already use h.264 and flash will probably continue using them. But the bootstrapped websites and startups will opt for the free stuff at least initially, and of all those bootstrapped startups some will be successful enough to make some noise. And then some of the established companies will have cost cutting rounds and will look at those license fees and think about whether they really need to pay them when some of their brand new competitors aren't paying them. At this point the iPhone will start looking bad for not supporting the newest and coolest video startups that are supported on android and Jobs will eventually cave too and add WebM support to the iPhone.

Everything in the web thus far has gone towards the lowest cost and easiest alternative that is still effective, and this will not be different.


You're dreaming if you think Apple is going to add WebM hardware decoding support to iPhones. That would basically mean that all previously sold iPhones would be marginalized, it would increase the hardware costs and space/power requirements, and there is no market advantage to supporting the WebM format as there's no WebM-exclusive content.


I believe lukeschlather provided a good response, but I would like to add something more about the hardware side. It is a mistake to believe that one needs an entirely newly designed hardware chip to handle the WebM standard. Those hardware accelerators are not pure hardware. They are like little computers, with their own processors, and their own instruction memories, and their own software (or firmware). The processors are designed to efficiently compute the most commonly used math operations of the standard (which are usually Fourier transforms, matrix operations, etc.). The firmware causes the processor to apply the mathematical operations properly to the data to decode the video.

The thing is that all of those video standards use more or less the same basic math operations, just in a different way. This means that a WebM hardware accelerator would look very similar hardware wise to a h.264 one but would have different firmware.

In practice, I am sure that the hardware companies will make one hardware accelerator that can handle both h.264 and webm through different firmware programs. So you wont need much additional silicon or power to handle WebM. It might cost more, if the hardware companies decide to charge extra for WebM support, but that surcharge will not be much, because (i) they do not need to pay license fees, and (ii) there is a lot of competition in that field.


Android is already marginalizing old iPhones (and to some extent Apple's business model is built around marginalizing old iPhones.)

Also, Google controls YouTube. So H.264 <video> YouTube could see a sunset at some point, which would be a BFD.


That's a really interesting point. All at once you helped me understand the giant chess game we're watching.


You're dreaming if you think Apple is going to add WebM hardware decoding support to iPhones.

You're dreaming if you think Apple could ignore WebM if it became the de facto web video standard. It all depends if WebM becomes that popular.


> there is no market advantage to supporting the WebM format as there's no WebM-exclusive content.

hristov's entire parent post was about why this sentence should end in "for now."


Which sucks for HTML5 video. Without Chrome, only about 5% of web users actually support HTML5 playback using h.264. Chart: http://videojs.com/2011/01/google-is-dropping-h-264-from-chr...

Two things could end the format war. 1. Apple adopts WebM (which requires WebM hardware for iOS devices) 2. MPEG LA removes all royalties from h.264


1. Apple adopts WebM (which requires WebM hardware for iOS devices)

Why? Aren't the iOS devices powerful enough to software decode WebM streams?


They might be, but battery life is an issue.

Hopefully SIMD and GPU in high-end phones can at least partially alleviate the problem (iOS has Accelerate framework and programmable shaders).


That would be incredibly slow.


Or another way to view it is that 30% support html5 video with WebM


Or another way to view it is that if you factor in Flash support for H.264, the only clients that can't view H.264 content are Firefox, Opera, and IE 8-or-earlier installs without Flash installed.

I'm not sure what percentage of the market that is, but I'm pretty sure it's pretty small.

In comparison, all mobile devices, game consoles, and Blu-Ray players support H.264, as do all Flash installations (including the one bundled with Chrome that users can't remove), and all installations of Safari and IE9 (when it arrives).


Firefox 3.x doesn't play WebM content. So it's just Chrome's ~13% share at the moment.


Maybe that is somehow what Google wants? It has cozied up to Adobe to the point of including flash in Chrome itself. And YouTube apparently can't be bothered to make html5 video work reliably.

I can't think of why anyone would want to promote flash, though.


YouTube depends on Flash for its most profitable enterprises, which are advertisements before the video you're trying to watch, rental, and so forth. I don't know why they can't implement pre-show ads in HTML5, but rentals, etc., can't be done in HTML5 because they require DRM.

There was a big post a while back about all the things YouTube needs to do in Flash instead of HTML5. The fact of the matter is that HTML5 video puts several of YouTube's main money-makers out of order, at least temporarily while the logic is re-implemented.

Edit: The post from YouTube about why they still need Flash is at http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html .


Because it locks people out of Apple mobile devices.


I have been without flash for almost a year now and I can't remember the last time I had a problem playing a video on YouTube.

It has happen possibly twice.


Really? You must be much, much luckier than I. I just headed over to YouTube, disabled the (excellent) YouTube5 Safari extension, and tried 20 random videos. Only two worked (but fullscreen is still broken).


Completely agree bonaldi. What a stupid move by Google. In order to promote their own technology they are setting back HTML5 video another year or 2 so they can fluff around and whine about which video codec is better.

I could understand other companies not implementing WebM because it was a new codec developed by Google with no existing community or anything around it.

But such a widely used codec (all my videos are H.264), I don't understand.

Can't they just all support each others codec's, get this stupid war over with and start a large scale push of HTML5.


Once Adobe adds WebM support in Flash, it might happen the other way around.


You'll have to add these caveats in as well:

Once Apple supports WebM.

Once chipset manufacturers produce WebM optimized hardware decoders.

Once handset, set-top, etc. manufacturers purchase and integrate those WebM hardware decoders.

Once handset, set-top, etc. manufacturers develop or license software players that support WebM encoded video and file format.

Could happen the other way around. But it ain't likely.


Yeah. There is no way Google of all people could launch a Cell Phone OS based on a Java variant and beat Apple by the end of 2010. Stupidest idea ever. I'm still laughing.


This seems like kind of an odd comment. How did Android 'beat' Apple? What's the game they're playing? Google is displaying a lot of ads (their goal). Apple is making a shitload of money (their goal). How did Apple 'lose' or Android 'win'?

Also, not to nitpick, but 'Java variant' seems inaccurate. Code is written in actual Java (not a variant, as far as I'm aware), and compiled to bytecode to run on the Dalvik VM (not a JVM variant).


You can only beat an opponent if you're playing the same game.


Really? "Disruptive Technology" don't happen?

Google drove the cost of smartphone OSes down to as near to zero as patent law will allow.

I'd say that is a game changer.

How much does WebM cost?


The issue is not whether it's a game changer. Apple's game is to build devices, software, and a highly consistent and polished user experience, irresistable to buyers and app developers, all in an effort to capture maximum profit share. Google's game is to build a similar OS that is irresistible to device makers, all in an effort to maximize market share and the advertising revenues boiling off the free app ecosystem.

With Apple, the product is the device and you are the buyer. With Google, the product is you and the advertiser is the buyer. They are each winning their respective games. Superficially they are competitors, but if there is a winner, then there's a loser. How can you look at either company and consider it the loser?


They can both be winners and losers depending on what game they choose to play. Being disruptive is about pissing on the rules for the original game.

Actually the more I think about it the more non-sensical your original statement and this conversation becomes. ;)


Putting aside the metaphors, Google's growth is not coming at the expense of Apple's profits. Nor are Apple's seemingly perpetual revenue and profit gains coming at Google's expense. They are attacking different problems from very different angles.

With only three or four percent of the market, Apple swallows up more profit share than the largest three phone makers combined (in the neighborhood of 40 percent). That's an astounding number, and it doesn't even include non-phone devices. At the same time, Android had tremendous growth in 2010, inevitably passing Apple in unit sales rate. It's a bit glib to simply say Google therefore beats Apple in 2010. There is nuance, and either company can be painted in the foreground.


Agreed,

Both companies seem to be doing wildly well with their respective mobile strategies.


There's a massive volume of h.264 out there that isn't going to get converted just to satisfy some dogmatic commitment to 'openness'.


They won't change it for openness reasons, but they will change it if 80% of their visitors support WebM and not h264. It happened before. How longer were people forced to design web pages for ie6 due to its market share.


Content providers already have to support browsers that don't include h.264, and Chrome users are now in the same boat as Firefox users -- which content providers certainly won't ignore.

For sites which only produce h.264, Chrome includes Flash which can play h.264. And every video site is going to support a Flash playback path for older browsers.

The real impact here is pretty small, other than legitimizing a free and open codec. Chrome has just moved from one must-support category to another one. Most people will never notice the difference. How is that a loss?


It's a loss because Chrome is moving from the HTML5 video must-support category to the Flash fallback category.


Yea, if WebM is free people will. If both are available then WebM is probably superior from a content producer's perspective.


Not necessarily, and not in the long run.

These changes will occur in the next couple months

By then flash will gain WebM playback support. This move is a good one and it does make sense, I don't think there is room for compromise in regards to the open internet and non-proprietary standards.


Considering how long it took Flash to gain hardware acceleration on platforms aside from Windows, I wouldn't hold my breathe. MobileFlash on Android still ranges from "Sucks" to "it's fine".

I haven't tried Flash video on my android tablet (it has a YouTube app) yet, but I've also rooted it and flashed the firmware to remove a software underclock so my experience may not be representative of any stock devices.


And I thought people were happy for HTML5 video because it eliminated the need for Flash. We've turned a full circle.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: