Hacker News Reader

Hacker News

Comment by Raphael_Amiard | Hacker News Reader

Parent Full thread

Raphael_Amiard

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.

View on HN

> 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).

> 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 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...

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

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?

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.

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

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 :)

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?

> 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.

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.

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...

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.

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?

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%)

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.

Reply on news.ycombinator.com