Hacker News Reader

You missed the most critical point, which is

"This license is fundamentally incompatible with software freedom. It requires developers to restrict how their software can be used, and to collect royalties in many situations."

And that is what it is all about. H.264 imposes end-user licenses and if it gets entrenched, freely redistributable browsers would lose. The argument against dropping H.264 is basically "why switch formats when what we have works?". H.264 does not work for free software. It's as simple as that. If HTML5 video suffers in the short term, that's the price we'll pay - at least that's the FSF's position.

>Everyone points to the GIF fiasco. The net result? PNG was born. If the screws are ever put to us on H.264, you'll see exactly the same thing, only quicker.

Why wait until a fiasco?

> Computing power being what it is today, the effort of re-encoding every video that exists on the Web is actually not that hard of a problem, and is certainly in the realm of what Google can do today, let alone 5-10 years from now.

Seriously, you're arguing against yourself here. Besides, what of the omnipresent 'hardware decoders' we keep hearing about?

Let's not forget that PNG is superior format compared to GIF. Also, let's not forget, that browsers were not dropping support for GIF's meanwhile adopting PNG. Sure, issue with GIF helped PNG, but I'd say it was destined to "win" anyway.

H.264 is probably superior to webm. I don't understand video codecs, but it's the consensus opinion among people who know this stuff. However, I fail to see how its relevant in any way. The tegra2 can already decode 1080p vp8 in hardware, and I'm pretty sure you wouldn't notice the difference between a 720p video in webm and another in H.264 in terms of performance on your x86 cpu. The inefficiency, if any, would be negligible.

H.264 baseline codec is similar to vp8, not superior. And baseline is what is used on mobile and all hardware encoders, so the highest versions of H.264 don't even matter.

...baseline is what is used on mobile...

That's the market segment that the baseline profile was conceived for, but the phone in my pocket and the tablet on my nightstand both support the main profile. Sure, most content that I view on it is probably encoded in baseline, but there are 17 million iPads in the wild that support the main profile. Edit: it's not just iOS devices, either. The Playstation Portable supports the main profile too. There are around 62 million of them out there.

VP8 needs to skate to where the puck is going to be, as it were.

The iPad really should have supported High Profile. No-one's going to encode a 3rd version for the iPad when everyone else jumped straight from Baseline to High, which means it's effectively Baseline.

Seems strange that the iPhone 4 got better specs so shortly after (much like the 256MB memory). I'm sure they'll fix it in the next rev though, which just increases the chance that rev. 1 devices will be served Baseline.

edit: I just checked and the iPhone's only 720p Main Profile too? I'm confused now, I was sure iPhone 4 went to High Profile.

when everyone else jumped straight from Baseline to High

Interesting. Which mobile device(s) did that, and what decoder chip(s) did they use?

He is talking about content providers, not devices. It is really diificult to find main@ bitsreams in the wild.

What? Who told you that? H.264 baseline is definitely superior to VP8. The 8x8 transform block basically ensures that.

The x264 developer often cited by H.264 proponents. He wrote, that VP8 is slightly better than H.264 baseline.

Jason GG? Yes. He did. When he agreed with me. He even confirmed my suspicion about 8x8[1].

[1] http://x264dev.multimedia.cx/archives/377

Quote from your link:

"VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”

I believe this was written before the update that acknowledges that VP8 has a partial analogue for B-Frames (which aren't present in Baseline H.264).

Another quote:

"The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264"

I guess it's arguable what he actually means because he's not explicit but I read both quotes together (and indeed the whole piece) as saying the VP8 spec is better than the H.264 Baseline spec. Whether that translates in the actual encoders, depends mostly on the particular H.264 encoder.

> "This license is fundamentally incompatible with software freedom. It requires developers to restrict how their software can be used, and to collect royalties in many situations."

According to the FSF's definition of software freedom. The FSF has quite a radical view in this regard. A Microsoft exec once described the GPL as "viral' [1] and it's a fair point. Many view licenses like MIT and Apache as being more free simply because they're not as restrictive.

This ambiguity is more pronounced when you use words like "open" because it means different things to different people.

So it would be more accurate to say that H.264 is incompatible with the FSF's idea of software freedom.

> if it gets entrenched

What do you mean "if"? It already has.

> Why wait until a fiasco?

Because anyone who writes software knows that writing code to solve problems you may never have is a recipe for wasted effort if not outright disaster.

It's a bit like the standoff between the (former) Soviet Union and the USA: not a single shot was ever (directly) fired between the two but the threat of escalating conflict kept them in check (resulting in proxy conflicts in Korea, Vietnam, Afghanistan, etc but I digress).

Think about it this way: MPEG-LA could announce tomorrow that licenses now cost $1 trillion. The result? Obviously no one would pay and a new standard would arise pretty quickly. What if it was $1 billion? $100 million? The point here it is simply a question of degree.

So what keeps (and will keep) MPEG-LA in check is market forces, the limits of what people can and will pay and the threat of a free or cheaper alternative... much like any market. Switching formats is a process that can be automated so the transition cost isn't really that high.

[1]: http://en.wikipedia.org/wiki/GNU_General_Public_License#Vira...

Ok, here is how I define minimal software freedom - I give you a piece of software, along with source code, you are free to use it in anyway you please, or make your modifications and distribute it to as many people as you like. With H.264 bundled with a piece of software, that is not possible.

> This ambiguity is more pronounced when you use words like "open" because it means different things to different people.

I never once used the word in my post.

>What do you mean "if"? It already has.

You're arguing for the status quo. Everything seems entrenched until an alternative comes along.

You seem to completely ignore that the H.264 license is directly opposed to free software. There's a reason Chromium never supported H.264, while only Chrome did. Nobody except the patent holders benefits from a de facto patent-encumbered codec.

With H.264 bundled with a piece of software, that is not possible.

The decision to only support bundled codecs and refuse to let the user use anything else was made by Mozilla, Google, and Opera. It is not a spec requirement or technical necessity. The idea that a browser would be forced to bundle h.264 is quite evidently mistaken, as the browsers that do support it don't bundle it.

The browsers that do support it run on the platform by the same vendor. IE9 runs only on Vista/7, where MS provides H.264 decoder. Safari runs only with Quicktime, where Apple provides H.264 decoder. So although the browsers do not come with decoders, they use their vendor's decoder and nothing else.

On the other hand, if Mozilla/Opera/Chrome used third party decoder, that would be support nightmare ("It works on my computer, but not on friend's! Please fix it!").

The browsers that do support it run on the platform by the same vendor.

I don't understand the significance. The same APIs are accessible to any other browser. If someone has evidence that Mozilla, et al. have been technically locked out of using the media APIs on Windows or Mac OS X, I'd be interested in the details, and if someone has evidence that they've been locked out of using the media APIs on Linux, I'll eat my hat.

they use their vendor's decoder and nothing else

I'm not sure what you mean. If you mean something like "Windows will only support h.264 and you can't use anything else", then that is exactly wrong.

It is not only about APIs, but also about control.

Microsoft can always rely, that IE9 will supports whatever formats they want it to support. They know, that it will play H.264, because they ship H.264 with Vista and 7 and IE9 supports only Vista and 7.

Apple can also always rely, that Safari will display formats they want it to display. They know, that Safari will play H.264, because Quicktime ships with H.264 and Quicktime is bundled with OSX, or with Safari for Windows.

If Mozilla/Google/Opera outsource this to OS, they lose control. They will not know, what the browser will display (imagine handing off control about HTML/CSS/JS to Microsoft, when IE6 was going down and Firefox up. It would be like Firefox using IE HTML control to display HTML).

Another problem from the control perspective is inconsistent support among platforms. Platform A, it will play formats X and Y. On platform B, formats Y and Z. On C, X a Z. Do you see problem here?

The handling of a <video> is outsourced to the OS.

For IE9 and Safari (except Safari for Windows) is is exactly the case. And because the OS vendor is the same as browser vendor, the effect is the same as bundling with the browser.

That is not the case for browser vendor without their OS. They cannot achieve the same effect.

If all browsers did that, web codec development would move at the same glacial pace as Windows version updates, not to mention losing any semblance of uniformity and all possible hope of changing the status quo in any meaningful way away from patent-encumbered codecs.

web codec development would move at the same glacial pace as Windows version updates

I'm not convinced that that is the case, but even if it were, the state of things with bundling codecs is being limited to what Google and Mozilla say is ok for them. You, the user, have no say in what you can view. This might be acceptable if you have supreme confidence in them (where is the next free codec going to come from, anyway?) but frankly I don't think they've earned it.

not to mention losing any semblance of uniformity

I find this extremely dubious. The incentive to publish in a format viewable by the widest audience applies regardless of what format that happens to be. Flash became ubiquitous for web video precisely because it was the most useful at achieving this aim, not because any browser decided to forbid other plug-ins. I see no reason to think that this incentive would dissolve if codec support was left open-ended.

changing the status quo in any meaningful way away from patent-encumbered codecs

This is is an ideological demand, not a spec requirement or a technical necessity. Which is my point: that is why these browser vendors are doing this. Not because they are forbidden from supporting h.264 (compare Epiphany) but because they're trying to push an ideology under which h.264 is heathen.

The whole point of moving things to the browser was to remove any lockin advantages a specific platform might have. That is the reason Flash gets so much hate from anybody who doesn't use Windows. Going back to OS-specific codecs would limit codec choice to what the OS vendor considers kosher. And lest we forget, its far harder to switch operating systems than it is to switch browsers. If you don't like Chrome, Firefox or Opera, nobody's stopping you from using IE or Safari.

> bundling codecs is being limited to what Google and Mozilla say is ok for them

What you are suggesting merely takes the power out of the hands of browser vendors and puts it in the hands of the os vendors. I trust Mozilla, and to a far lesser extent Google, more than I ever will trust Microsoft.

Going back to OS-specific codecs would limit codec choice to what the OS vendor considers kosher.

Not true. e.g.: http://xiph.org/dshow/ http://xiph.org/quicktime/

Why am I not free to do this with h.264 in "open" browsers?

Using operating system facilities to support video codecs, font rendering, image decoding, etc. is an unnecessary security risk. Independent browser vendors don't want to be blamed for someone else's bad code.

> So it would be more accurate to say that H.264 is incompatible with the FSF's idea of software freedom.

It depends on how you define "compatible", but H.264 is only sort of compatible with MIT-style licensing as well. It's compatible in the sense that, if you start with MIT-licensed software, you can slap on the required H.264 license and not violate any laws (MIT-licensed software can be relicensed under more restrictive terms). But it's incompatible in the sense that you can't actually choose to ship your software under the MIT license and the MIT license alone. In that sense, H.264's license is viral: any software that supports H.264 in any form must incorporate the the H.264 license.

> A Microsoft exec once described the GPL as "viral' [1] and it's a fair point.

It's not. Plain old copyright is viral. A derived work's copying can only be done with permission of original and deriving author. If you use a commercial library, the license you paid for is that permission. If someone then creates a new work from yours, permission is needed from all three authors unless the original library came with those particular redistribution rights.

> Except that it further entrenches Flash in the short to medium term, possibly longer.

Only because Microsoft and Apple choose not to support WebM. Prior to Google's choice, Firefox (with rather significant browser usage stats) wasn't supporting H.264 either, which kept Flash on the web. Also, people keep referring to IE, but it still needs Flash. Sure, IE9 is coming, but we'll see what the adoption rates will be like.

Point is, Google throwing out H.264 didn't change the short or medium landscape much.

> Everyone points to the GIF fiasco. The net result? PNG was born.

You completely miss the point. GIF is a lesson, and we should learn from it. More importantly, PNG wasn't adopted over night. You can't just flip a switch and make everything alright.

> If the screws are ever put to us on H.264, you'll see exactly the same thing, only quicker.

Or, you can avoid the entire problem, put effort into free formats now. Don't repeat past mistakes.

> The elephant in the room here is that the fundamental problem is software patents. They need to be completely abolished.

Yes. Supporting them doesn't help matters.

> Only because Microsoft and Apple choose not to support WebM.

When they made their choice WebM wasn't an option because it didn't even exist yet.

Microsoft might be a different issue, but Apple has now shipped almost 150M devices with hardware h.264 support and no webm support at all.

> You completely miss the point. GIF is a lesson, and we should learn from it.

GIF is completely irrelevant to the issue at hand (or, if you want to reach for it, WebM is actually more at risk of a GIF-type scenario than h.264)

> When they made their choice WebM wasn't an option because it didn't even exist yet.

IE9 is still in development. They can still choose to support WebM.

Apple could still choose to WebM support.

The point isn't that Apple and Microsoft can choose. Rather, you can't expect to ask Google to support H.264 and not ask Microsoft and Apple to support WebM. Apple and Microsoft don't want to support it. Fine. Google doesn't want to support it. Fine.

Neither H.264 and WebM are written into the standard. Fine.

Let the competition begin. The best technology that meets all the needs of the various groups will win.

> GIF is completely irrelevant to the issue at hand (or, if you want to reach for it, WebM is actually more at risk of a GIF-type scenario than h.264)

No, and no. I'd explain more, but I can't follow your logic. (Nor do I really want to try. Sorry, but you seem far too emotional about the topic. I'm probably wrong, but your comment comes off that way).

> Apple could still choose to WebM support.

In fact, Imagination Technologies, the people who make the GPUs for the iPhone(and the iPad as well, I think), have already announced full vp8 support in their next-gen hardware decoders, so it would be really easy for Apple to include webm support in the next iPhone or the one after that. And they're safe from any patent threats as well, since they're already MPEG-LA licensees. It will be interesting to see if they do.

> it would be really easy for Apple to include webm support

And Matroska support. Building container parsers that are resilient to fuzzing attacks is non-trivial. Can I assume you'd like trick play (ffw, rew, scrub), too?

Container parsing: it's not that hard. Besides which, they can use one of the freely licensed existing parsers to solve that problem.

Trick play is already implemented. If you have to do major rework of that area to support a new format, you're doing it wrong.

>IE9 is still in development. They can still choose to support WebM.

I was talking with a friend yesterday and mentioned how hilarious it'd be if Microsoft decided to adopt WebM on WP7 and then attack Apple for being too closed. :)

I love the people shouting to the roof for standards support and how H.264 is a proper standard and how we should support it because it's being used everywhere.

I just can't help think of the OOXML debacle.

Yep, antimatter15 had to call it out.

> Apple could still choose to WebM support.

Not in any meaningful way: as far as I know, there is no hardware decoding support for WebM in production. That leaves 150M iOS devices dead in the water, and a bunch of Macs having to decode HQ videos in software instead of relying on existing, well-supported and well-understood hardware.

> The point isn't that Apple and Microsoft can choose.

Apple and Microsoft also have been investing in h.264 for a long time. They're the least likely players to be able to change and (especially Microsoft) they're not very good at turning on a dime.

> you can't expect to ask Google to support H.264 and not ask Microsoft and Apple to support WebM

Why not? Google already had h.264 support, h.264 is the current leading video standard and enjoys wide support across the board, from hardware to software, from embedded to full-blown computers.

> No, and no. I'd explain more, but I can't follow your logic.

So you'd explain why I'm wrong even though you don't understand what I say? Original.

> No, and no. I'd explain more, but I can't follow your logic.

You'd explain why you disagree with what I say even though you don't even understand what I say?

Uh... right.

It's very simple:

> WebM wasn't an option because it didn't even exist yet.

And when WebMx is released, everybody will hound those who don't immediately change their product strategy to fit this. This is also a good reason for why Apple isn't using WebM: it's not a standard, it's as controlled by Google as Flash is controlled by Adobe.

They're essentially giving a bunch of control of their device to an outside company.

The webm spec is frozen, and all patents are irrevocably licensed. Webm is not 'controlled' by Google.

The patent thing is just FUD by Apple proponents. But, I won't support WebM until it's an ISO standard, frozen is just a promise at this point.

Their own site says "dedicated to developing a high-quality..." which, taken literally, means that the project is still underway. Also listed on the front page: "Submit patches and improvements" Yet again, saying that it's a work in progress.

The encoder is being improved, and the decoder is being optimised for speed on various platforms but the spec defines what the decoder does and it was effectively frozen as soon as Google converted a bunch of Youtube videos and got hardware manufacturers on board. Any change to the format would break existing content (most of Youtube) and shipping hardware.

The fact that the standard is frozen is not incompatible with them improving their implementation.

ISO leads something to be desired: witness the glacial pace of C++0x (now C++1x). I'd prefer some standardization of VP8 - don't get me wrong - but going through ISO would likely be a mistake.

I think you are wrong to project the failings of the C++ committee on ISO as a whole.

For H.264/AVC, it was less than 4 years from the first draft to final ratification. It was a joint effort of ISO and ITU-T.

Still, if that's too slow, SMPTE seems to go faster when they start with an existing codec. VC-1 and VC-2 (a profile of Dirac) were both done there.

BTW, there is an effect at ISO to do a royalty-free ("Option 1") MPEG: http://www.robglidden.com/tag/mpeg/

They're not irrevcably licensed. If you find that WebM does actually violate your patents you can't sue otherwise you lose your license to all of the other patents.

Realistically Google should not revoke your licenses unless you lose the lawsuit (not when filed), because if they have legitimately infringed your patent then it seems like blackmail to keep them from acting on it by such a method.

You're quite right, but I think its ridiculous to ask Google to give you a free license to their patents even as you are suing them for infringing yours.

They're the ones pushing that this be the defactor standard for web video. If that's the case then they shouldn't attempt to block a party from exercising their patent rights by effectively threatening that if they do so they won't have any access to video on the web.

Could you imagine MS saying in their Windows license agreement saying that they can revoke your licenses if you sue them over a patent?

Yes, I can imagine that quite clearly. It wouldn't be the most repressive clause in that license agreement.

AFACT there is no clause in the Windows license that MS could invoke that would prevent you from entering a complete industry.

Google's position is literally... screw with us, and if WebM catches on, you can't do video on the internet.

And that's why nobody sane will try to screw with them. Nobody wants to lose the ability to do video on the internet during next 20 (plus/minus) years.

And that doesn't bother you? They're basically saying, "We may have stolen your technology... oh well, it's ours now. We run the internet."

I guess as long as Google is pushing the technology that "you" like they can do no evil.

That "We may have stolen your technology" is pushing it.

Google did due diligence before buying On2 with VP8. They did patent search. If anyone appears now with some patent claim against VP8, suing left and right users of VP8, it does not show good faith on their part.

>Exactly. H.264 isn't going away anytime soon so having a Web browser without Flash gets that much harder.

This is short term thinking. Flash isn't going away in the short term anyway; why should we kneecap the future of HTML5 <video> before it gets off the ground because it might temporarily extend the life of an already entrenched format?

Because the way I see it, there's zero chance of replacing it when your alternative had nearly 20% of the market guaranteed to be segmented due to Mozilla's refusal to adopt H.264. Everybody would have kept using Flash+H.264 anyway.

> Flash isn't going away in the short term anyway

I disagree completely. One of the things I love about my iDevices is that they don't support Flash. Some consider this a problem. I consider it a feature.

For me personally, very few times is this frustrating and most of those are when sites use Flash-wrapped video with no HTML5 fallback, which is still relatively common (but decreasingly so).

I wish I could use Chrome without Flash. But it's preinstalled, which I'm vehemently opposed to. What's worse, if you uninstall it almost every page bugs you about missing plugins. The only solution (which I use) is to use a Flashblock plugin, which is far from optimal (eg sites use a Flash overlay over the entire page to trigger all the Flash on the page).

And for the record, I don't hate Flash because it's closed. I hate it because it's buggy, creates extra security vulnerabilities, is used for some quite nefarious practices (eg zombie cookies) and, in the modern era of HTML/JS, is basically not needed anymore (where it once was) for RIAs.

> why should we kneecap the future of HTML5 <video> before it gets off the ground because it might temporarily extend the life of an already entrenched format?

Because in real terms this move does absolutely nothing to the future of H.264. Want to watch H.264 in Chrome? You use Flash. So the net result is now I have to use Flash where before I didn't.

> Mozilla's refusal to adopt H.264. Everybody would have kept using Flash+H.264 anyway.

If Firefox users choose to use Flash (by choosing Firefox) then that's their choice. I also understand why Mozilla doesn't support H.264. Beyond the political arguments a license would be a huge slice of their revenues.

So all this move does is force me, as a Chrome user, to use Flash, where before the browser supported the format of most relevance in the video market. Unlike Mozilla, who have valid financial reasons, Google already has a H.264 license so this move is purely philosophical/political.

I object to being drafted into a war that I have no interest in and (imho) is both premature (for WebM as a format), too late (considering H.264 entrenchment to date) and unnecessary (given the cost of changing later and that the FUDed Armageddon scenarios are at best overblown and at worst disingenuous).

> One of the things I love about my iDevices is that they don't support Flash.

You know, they make real computers that don't support flash too.

Can you name a few? They may ship some without Flash player preinstalled, but that's very different from not supporting Flash in the way iDevices don't.

Well, I suppose I meant "real computers that support the feature of not having Adobe Flash installed", but PPC Linux is one I've used that comes to mind. I'm sure there are ARM-powered ones for which that's also true.

>I disagree completely.

Then, frankly, you're not paying close enough attention. Video is only one part of why Flash is popular. One area that HTML5 isn't even close to replacing Flash is in webgames, and a big reason for that is something fundamental to HTML5: HTML5 behavior is at the mercy of the rendering and JavaScript engine the browser running it. Flash is the same everywhere.

All these fancy HTML5 demos you see everywhere? They pretty much universally have "Runs Best on [Browser X]" somewhere on the page. We're partying like it's 1999 all over again.

Like it our not, Flash is going to be around in the near-term regardless.