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

How much web video do you watch on your phone?

If you're going to pay $10 for a full-length movie, then the H.264 licensing cost is worth it to not have to recharge your phone on the flight. But if you are watching kitteh videos on Youtube, the freedom from cost is worth the tiny additional power draw. Are you really going to watch cat videos for 5 hours?



No, but I'd also prefer my five minute cat video to not eat ten percent of my iPhone's battery. To me, the extra freedom is not worth the extra battery, even if it only quadruples my usage while watching video.

Anyway, it's a moot point. H.264 has "won" in the sense that if HTML5 video happens, most of it will probably be available in that format. The battle was, in my opinion, basically decided when YouTube led with H.264 in their HTML5 experiment. What Mozilla does at this point is relevant only to people who might want to both watch HTML5 video and use Firefox (i.e. they may not be able to do both depending on Mozilla's choice, and on whether a dual-content model is feasible and desirable for most web developers -- hint: probably not).

This is not that big of a deal. There are at least two other no-cost browsers on the important operating systems that will support HTML5 video, three on Windows.


Quite simply (IMO):

Youtube + iPhone = win for h.264.

Hardware decoders are an extra bonus, and h.264 is definitely superior quality-wise to theora. Given all that, Firefox without h.264 is likely to lose significant ground to Chrome for that reason alone.


If you've got an iPhone? Probably a fair amount.

But consider that the battery argument holds for every battery-powered device. Laptops, the iPad / iPhone, and even (to get nitpicky) your electrical bill. It likely also will extend to future gaming handhelds, likely to have a hardware decoder (and why not use h.264? high quality and small size) and run on batteries. The market that is effected is (if not now, likely to be soon) in the hundreds of millions of people, with many many hours each.

I'll be incredibly conservative, and say "a billion hours". Might that be worth reducing power use?


H.264 is not more power efficient than Theora.

It compresses better so that it's got higher quality per bit, but it achieves that by using more computing power on both the encode and decode end. Consider gzip vs bzip for a very rough analogy, more "cleverness" means smaller files but also more computation time. Or think of the CABAC feature that makes your H.264 file 10% smaller but unable to play on iPhones or other low power devices (http://en.wikipedia.org/wiki/CABAC).

H.264 does have "hardware" assisted decode on iPhones but that's a choice made by Apple not a universal law. Despite the constant repetition of the "fact" that H.264 decode is done in custom silicon, it's simply not true. The same DSP or generic video decode units are used for other codecs (inc VC-1, MPEG-2, MPEG-4 part 2, RealVideo). There's no reason Theora can't be accelerated in the same way and it already has been for the OMAP3 chips (as used in N900s, Palm Pre and the Droid).

Here's a link to a company selling software that decodes High Profile H.264 (amongst many other codecs) on OMAP3 SoCs. How would that be remotely possible if H.264 implementations were entirely custom silicon, unchangeable and non-upgradeable?:

http://www.ittiam.com/pages/news/pres-rel-20100215-omap3-720...


Who said that H.264 encoding is entirely custom silicon? And why can't there be custom silicon if other less "hardware" (why do you keep putting it in quotes?) acceleration strategies exist?

You've been pushing this hardware angle hard, and the point is well taken. Yes, you can accelerate Theora if you write some new software. Not every mobile producer has the luxury of letting a third party do that (or putting the resources to do it themselves). But yes, it is possible.

So now all we're left with is that Theora is an inferior codec: worse quality, worse encoding options, more investment required to make it power efficient on mobile.

The industry has decided—with or without Mozilla—long before this question was ever asked. When Youtube started converting everything to H.264, the biggest player moved over. Now you see other smaller players moving to H.264 as well.

All MozillaCo's refusal is doing is ensuring that Flash continues to exist as a video solution for Firefox, playing H.264 and not giving HTML5 video support. The decision has already been made by the big sites!


First post in this thread: "Dedicated mobile hardware is a necessity".

The post I replied to, by a different poster, had taken this one step further and decided that Theora's lack of "a hardware decoder" was going to melt the ice caps.

Who knows exactly what these people meant by "hardware" or "dedicated mobile hardware" but the generally accepted meaning isn't something that can be created by writing software. Writing software for already deployed hardware is considered one of the strengths of Free and Open Source software developers. Creating fabs to build silicon chips with 3 year lead times and magically placing them in devices that have already been sold isn't, and I have repeatedly seen this factoid cited as the reason why Theora is hopeless, regardless of all other considerations.

Here's a quote from the latest Daring Fireball piece:

"There are no hardware decoding chips for Ogg Theora. If you want to send video to mobile devices, H.264 is the only practical encoding for the near future."

If this point is now made and widely accepted and the discussion has moved on to "Theora is an inferior codec: worse quality, worse encoding options etc." then that's great. Inferior is pejorative, and I find "worse quality" to be highly misleading, as if every Theora video will look like something on Youtube, but I'd happily admit to "lower quality per bit" (in fact I do in the post you replied to) which is okay because it has other advantages and room to grow.


going to melt the ice caps.

An exaggeration built on an exaggeration is doomed to fall over. I implied nothing of the sort, and my main goal was just to point out that a hardware decoder is a big deal in terms of battery life, though I admit it didn't come through clearly. Though I will claim that hardware decoding is typically more power efficient than software, and has much more room to improve.

I'm glad to see Theora getting hardware acceleration, especially as I hadn't heard about it, though I'd be curious to see if it'll work on more computers / devices than h.264 is likely to appear on.

As to MPEG-2 and other formats where there are more prevalent hardware decoders, do some comparative runs. h.264 does significantly better per bit from my subjective experiments. It's more future-capable because of that and it's ability to do ridiculously high quality encoding, which combined with a business to hold accountable for problems will likely mean other businesses will choose it over Theora.


> Inferior is pejorative,

Also: accurate.

> and I find "worse quality" to be highly misleading, as if every Theora video will look like something on Youtube,

Also: strictly true that it in apples-to-apples comparisons, H.264 will win in nearly every case. And not by insignificant margins the way audio formats might.

> but I'd happily admit to "lower quality per bit" (in fact I do in the post you replied to) which is okay because it has other advantages and room to grow.

Both are mature video codecs, not kids going to college to find themselves. Unless you are a codec implementor or enthusiast, why do you give a shit how much “room to grow” that your codec has?

Like I said before: All MozillaCo is doing is lying to themselves and ensuring that Firefox uses continue to watch video on Flash—an even more toxic presence on the web. The industry has already moved past them and their reluctance; they're having their argument years too late.


Why not just move back into caves? That would save even more energy.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: