Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google's dropping H.264 in Chrome is not a step backward for openness.

my.opera.com

Post reply on HN
Print view View original

71–80 of 128 posts

Re: Google's dropping H.264 in Chrome is not a step backward for openness.

#71

Post by vetinari »

alanh wrote: post #38
k33l0r wrote: post #15

Earlier quoted context omitted.

It's worth pointing out that MPEG-LA also doesn't offer patent indemnification on H.264 or any of its other formats. I can't find where I originally read this, but EETimes mentions it at the end of this article: http://www.eetimes.com/design/other/4012977/MPEG-licensing-b... "Also, MPEG LA does not offer any indemnification guaranteeing that its patents do not infringe someone else's patent rights."

Worth pointing out? Sure, but let’s not forget that what MPEG-LA actually does is license to you all the patents which H.264 is known to use — so you’re probably not infringing anything, barring of course the insanity the USPTO perpetuates… If you have a patent for part of the H.264 process, chances are, you’re part of the MPEG-LA and getting royalties through that organization already, legitimately, without suing an…

Microsoft also thought that they properly licensed MP3, until they were forced to pay additional $1.52B to Alcatel-Lucent...

MPEG-LA does not provide any protection agains patent holders coming out of the blue.

Re: Google's dropping H.264 in Chrome is not a step backward for openness.

#72

Post by jammur »

jokermatt999 wrote: post #65
irons wrote: post #53

Earlier quoted context omitted.

MPEG-LA cannot be a patent troll let alone a known one, because it's a loose organization of companies that agree on a standard to prevent fragmentation of video and let people deal with one entity instead of a thousand. Also, the licensing terms are fixed at a maximum 10% rise per five-year renewal. Given the lifespan of patents, that's a low ceiling.

Also, the licensing terms are fixed at a maximum 10% rise per five-year renewal. Given the lifespan of patents, that's a low ceiling. This is the first I've heard of this. Since one of the main concerns I've heard is that MPEG-LA could raise fees to unacceptable levels, do you mind providing a source for this? I'm still less comfortable with H264 being the standard rather than WebM, but this makes me less worried. (A…

He's probably referring to the last paragraph of this: http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsS...

Re: Google's dropping H.264 in Chrome is not a step backward for openness.

#73

Post by rbanffy »

kenjackson wrote: post #62
rbanffy wrote: post #59

Earlier quoted context omitted.

And not embedding h.264 may prevent it from becoming a de-facto standard while pushing WebM, a fully open competitor (that's not perfect yet), may give it a chance of becoming, rightfully, part of a standard.

This was a spit in the face of Apple, and Jobs is the type to hold grudges. iOS devices won't use WebM. And no matter how you slice it, iOS devices will be popular in the formative years of HTML5. At best WebM splits into a state where its really not much more useful than it is today. Or H264 just kills it anyways, and Chrome dies. In no case does WebM become the defacto standard.

Having a fragmented standard or no standard at all is usually better than having a very bad one. People can always encode to multiple file types if they want to serve the increasingly large audience that doesn't support h.264.

And, BTW, Android phones just passed their iOS competitors, so, it doesn't matter how popular they will be, Android devices will be more popular. If Google decides they won't support h.264, it will be a serious hit.

Re: Google's dropping H.264 in Chrome is not a step backward for openness.

#74

Post by recoiledsnake »

vetinari wrote: post #71
alanh wrote: post #38

Earlier quoted context omitted.

Worth pointing out? Sure, but let’s not forget that what MPEG-LA actually does is license to you all the patents which H.264 is known to use — so you’re probably not infringing anything, barring of course the insanity the USPTO perpetuates… If you have a patent for part of the H.264 process, chances are, you’re part of the MPEG-LA and getting royalties through that organization already, legitimately, without suing an…

Microsoft also thought that they properly licensed MP3, until they were forced to pay additional $1.52B to Alcatel-Lucent... MPEG-LA does not provide any protection agains patent holders coming out of the blue.

Very true. But by shipping WebM, MS would be vulnerable not to the patent holders coming out of the blue on H.264, but also ALL the mpeg-la companies AND patent holders coming out of the blue. It would greatly increase their risk.

I think they have reached a good compromise by developing support for IE9 to pickup WebM codecs installed by the user and playing HTML5 video through it.

Re: Google's dropping H.264 in Chrome is not a step backward for openness.

#75

Post by kenjackson »

rbanffy wrote: post #73
kenjackson wrote: post #62

Earlier quoted context omitted.

This was a spit in the face of Apple, and Jobs is the type to hold grudges. iOS devices won't use WebM. And no matter how you slice it, iOS devices will be popular in the formative years of HTML5. At best WebM splits into a state where its really not much more useful than it is today. Or H264 just kills it anyways, and Chrome dies. In no case does WebM become the defacto standard.

Having a fragmented standard or no standard at all is usually better than having a very bad one. People can always encode to multiple file types if they want to serve the increasingly large audience that doesn't support h.264. And, BTW, Android phones just passed their iOS competitors, so, it doesn't matter how popular they will be, Android devices will be more popular. If Google decides they won't support h.264, it…

I agree with your thesis. I just disagree that H264 is a worse standard than WebM.

On marketshare, while Android just passed up iPhone, something happened this past Tuesday which will probably tighten up the race a fair bit more. On top of that, the report counted iPhone subscriptions. Not iPad or iPod Touch devices. I've heard estimates that iPod Touch + iPad sales == iPhone sales.

And iPad2 is likely hitting the market in a few months.

In anycase the road we're going down is a fragmented one. Maybe people will get it right for HTML6. But I think most of the vendors at this point take the view that they'd rather have a fragmented web, rather than one dictated by their competitor.

Re: Google's dropping H.264 in Chrome is not a step backward for openness.

#76

Post by [deleted] »

bzbarsky wrote: post #69
Locke1689 wrote: post #56

Earlier quoted context omitted.

Both of those things are misleading or wrong. There's no reason why they would have to make it closed source, especially if they use x264. H264 patents don't require everyone to pay to create content, you should read the MPEG licensing agreement.

> There's no reason why they would have to make it closed > source, especially if they use x264. That's not what the lawyers said. In the US, at least; things may be different in your jurisdiction. Note that this is the route Chrome used to take: Chromium did not support H.264, while the Chrome binaries, built from some source that was not public, did. > H264 patents don't require everyone to pay to create > content…

[deleted]

Re: Google's dropping H.264 in Chrome is not a step backward for openness.

#77

Post by nitrogen »

sjwright wrote: post #60
recoiledsnake wrote: post #49

Earlier quoted context omitted.

Why doesn't Google release the source code of the flavor of Linux that it uses after earning tens of billions basically leveraging Linux code? Google open sources things that are not central to it's business, just like every other company out there. MPEG-LA cannot be a patent troll let alone a known one, because it's a loose organization of companies that agree on a standard to prevent fragmentation of video and let…

> Why doesn't Google release the source code of the flavor of Linux that it uses after earning tens of billions basically leveraging Linux code? Because the GPL does not require them to do so. If the GPL required them to do so, nobody would licence their code with it, and only the most batshit-insane people would dare use code licensed under it. Would YOU want to run a Linux server if it obligated you to provide a co…

It makes one glad that Linux isn't licensed under the AGPL.

Re: Google's dropping H.264 in Chrome is not a step backward for openness.

#78

Post by Locke1689 »

bzbarsky wrote: post #69
Locke1689 wrote: post #56

Earlier quoted context omitted.

Both of those things are misleading or wrong. There's no reason why they would have to make it closed source, especially if they use x264. H264 patents don't require everyone to pay to create content, you should read the MPEG licensing agreement.

> There's no reason why they would have to make it closed > source, especially if they use x264. That's not what the lawyers said. In the US, at least; things may be different in your jurisdiction. Note that this is the route Chrome used to take: Chromium did not support H.264, while the Chrome binaries, built from some source that was not public, did. > H264 patents don't require everyone to pay to create > content…

That's not what the lawyers said. In the US, at least; things may be different in your jurisdiction.

http://mailman.videolan.org/pipermail/x264-devel/2010-July/0...

Even if you decide to use a closed-source decoder, just because the decoder has to be closed source doesn't necessarily mean the entire browser has to be closed. What exactly was the lawyers' reasoning behind this?

http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachme...

They do require you to pay to produce an encoder. Of course someone can then distribute said encoder for free if they want, so the end user doesn't technically _have_ to pay. But in practice they do. And if you use an unlicensed encoder, then you're infringing on the patents. So is anyone who views any videos that were produced with the unlicensed encoder, even if their decoder is licenced.

What are you talking about? The page you linked clearly says that non-commercial content is free. I didn't say that no one has to pay to create content, I said not everyone has to pay to create content.

Re: Google's dropping H.264 in Chrome is not a step backward for openness.

#79

Post by vetinari »

recoiledsnake wrote: post #74
vetinari wrote: post #71

Earlier quoted context omitted.

Microsoft also thought that they properly licensed MP3, until they were forced to pay additional $1.52B to Alcatel-Lucent... MPEG-LA does not provide any protection agains patent holders coming out of the blue.

Very true. But by shipping WebM, MS would be vulnerable not to the patent holders coming out of the blue on H.264, but also ALL the mpeg-la companies AND patent holders coming out of the blue. It would greatly increase their risk. I think they have reached a good compromise by developing support for IE9 to pickup WebM codecs installed by the user and playing HTML5 video through it.

The WebM patent grant contains insurance against this. If any "new" patent holder sues anyone or makes available their patents for suing by other party, he will be excluded from the (VP8) patent grant.

Any CE or IT company will think twice, whether it is worth it. Can you imagine Samsung or LG suing someone over VP8 and in return losing access to VP8 content on Youtube? What it will do to their CE business?

Re: Google's dropping H.264 in Chrome is not a step backward for openness.

#80

Post by nitrogen »

podperson wrote: post #68
Pewpewarrows wrote: post #20

Earlier quoted context omitted.

You clearly haven't read the article. Flash is a sandboxed plugin running alongside the browser. It's not the internals of a new and heatedly debated HTML tag, which ultimately has to be an open standard and format, and supported until HTML6 comes around in another decade. Choosing to drop experimental support for a closed, proprietary, and royalty-encumbered codec in a tag's specification that hasn't even been final…

How is supporting arbitrary codecs via the tag any different from supporting arbitrary fonts through CSS font-family?

Supporting arbitrary codecs is more like supporting arbitrary font formats. Each separate codec uses its own (potentially vastly) different way of encoding video, and requires its own code to handle. Using the operating system facilities is too risky from a security standpoint (such as if someone finds an exploitable bug in the ancient Indeo codec).
Post reply on HN