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

111–120 of 128 posts

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

#111

Post by rbanffy »

kenjackson wrote: post #103
rbanffy wrote: post #94

Earlier quoted context omitted.

> I just disagree that H264 is a worse standard than WebM. Both WebM and h.264 are imperfect solutions for the same problem. WebM has a image quality issue h.264 has not, but this can be corrected, as WebM can be improved over time. The problem h.264 has - being encumbered by patents you can borrow for free only for a limited time - will not be corrected. If we decide to store all our video in h.264 we risk being una…

I'm impressed you guys encode that much. I don't think you're the common case. The case where WebM dies is that everyone continues to encode with H264 (which is what they're doing now). If you're IE or an iOS device you get raw H264. If you're Chrome or Firefox you get H264 in Flash. You just encode H264 and that's it. Now dual encoding, and you work everywhere. Whereas with WebM there is NO delivery mechanism to iOS…

> I'm impressed you guys encode that much. I don't think you're the common case.

Compared to the effort it takes to produce the content, encoding is negligible. We have a complete studio and a dedicated team producing a couple hours of original material every week. Originals are kept as uncompressed as possible storage-wise and are captured at the highest quality the equipment allows. Encoding happens in a server that's nowhere near capacity.

I proposed a presentation on it at the last FISL but it didn't make the cut (for which I am glad - two others did and it was quite enough work preparing them).

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

#112

Post by beej71 »

MiguelHudnandez wrote: post #89
eordano wrote: post #31

Earlier quoted context omitted.

There is no Chrome for smartphones, and so far no one has said anything about dropping H.264 on Android (although you can see it happening as soon as WebM extensions for ARM start being more popular). (edited: typo)

You are correct, but why would you imagine Google would treat Android differently? Even though they haven't announced any changes specific to Android, I expect Google's left and right hands to work together... eventually.

That's a fine argument, but it's just not the one in the article.

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

#113

Post by varjag »

Locke1689 wrote: post #106
bzbarsky wrote: post #102

Earlier quoted context omitted.

> doesn't necessarily mean the entire browser has to be closed. Right. I did say that #1 can be worked around. If you you you approach, you still get the Chromium/Chrome model, where you can't release the actual source to the binaries you ship, and worse yet others can't easily fork your "open-source" app while keeping the functionality or redistribute your binaries. > The page you linked clearly says that non-commer…

"commercial use" in that context includes putting it up on a website that has ads. So yes, not everyone has to pay to create content. If you find someone who will give you a free encoder for which they paid the licensing fees, and you make sure that either you don't put your content on the web or if you do that there are no ads on the page and you don't charge for the videos, then you can get away with paying nothing…

You are left here on benevolence of MPEG-LA consortium. If they ever change their mind, you'll have to shell out.

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

#114

Post by ZeroGravitas »

alanfalcon wrote: post #100
jammur wrote: post #72

Earlier quoted context omitted.

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

Considering how the large corporations easily reach the annual cap (currently $6.5 Million per year until at least 2015), the footnote that the 10% maximum increase in royalties does not apply to the cap is a bit disconcerting.

Ah, that explains how the cap has managed to go from $5 to $6.5 million (a 30% rise) since the last time I looked at it, which certainly wasn't 15 years ago.

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

#115

Post by ZeroGravitas »

DrHankPym wrote: post #93
MiguelHudnandez wrote: post #89

Earlier quoted context omitted.

You are correct, but why would you imagine Google would treat Android differently? Even though they haven't announced any changes specific to Android, I expect Google's left and right hands to work together... eventually.

Because Android is open and developed with the cellular carriers and manufacturers. If they want to add a H.264 chip, why would Google stop them?

They'll almost certainly have an H.264 chip but the standard Android browser (and Firefox and Opera Mobile) might not take advantage of it when faced with an HTML5 video tag.

Maybe we'll see Apple and Microsoft release browsers for Android!

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

#116

Post by [deleted] »

kenjackson wrote: post #23
tomlin wrote: post #11

Earlier quoted context omitted.

Those who seem to be opposed to Google's decision are often in the Apple camp (disclosure: I am in the Apple camp) but are also the same people who wish Flash to die because of it's closed/proprietary nature. So why can't we just envision ourselves embracing H.264 and picture what it'll be like in 10 years? Which camp will be trying to push it out the door because of licensing issues? There will be licensing and roya…

There will be licensing and royalty issues. When a big company in Redmond says stuff like this, its called FUD. This is FUD, plain and simple. What technologies have patents, fees and/or licensing around them? H264, MP3, Flash, USB, Java, HDMI, CDMA, GSM, LTE, WiMax, Firewire, CD, DVD, BluRay, MP3, AMOLED, and many more. To argue that computing is going to collapse with the existence of all these is pure FUD. Its FUD…

[deleted]

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

#117

Post by tomlin »

tomlin wrote: post #24
kenjackson wrote: post #23

Earlier quoted context omitted.

There will be licensing and royalty issues. When a big company in Redmond says stuff like this, its called FUD. This is FUD, plain and simple. What technologies have patents, fees and/or licensing around them? H264, MP3, Flash, USB, Java, HDMI, CDMA, GSM, LTE, WiMax, Firewire, CD, DVD, BluRay, MP3, AMOLED, and many more. To argue that computing is going to collapse with the existence of all these is pure FUD. Its FUD…

Not so fast. These licensed technologies you speak of are not embedded within web browser standards. It's a big difference. Flash, for one, is a plugin. It hitches a ride with the browser, it's not part of its standardized, internal workings. Google probably will benefit financially from this change and the rhetoric from Google's camp probably is FUD. No different than what Apple is doing with it's proprietary App St…

To those who pointed out that a codec is not a part of the browser standards, you are correct. I misspoke. I don't know why since I remember that Mozilla also took this stand a while back. Apologies. :)

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

#118

Post by blasdel »

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…

You are spectacularly incorrect about how Chrome and Chromium are built — the only difference between the two regarding is which flags the bundled copy of ffmpeg's libavcodec was built with.

There is no secret source code. When you build Chromium, you can just swap in a symlink to your system's copy of libavcodec, and then it magically supports whatever codecs that one was built with.

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

#119

Post by blasdel »

bzbarsky wrote: post #102
Locke1689 wrote: post #78

Earlier quoted context omitted.

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%20…

> doesn't necessarily mean the entire browser has to be closed. Right. I did say that #1 can be worked around. If you you you approach, you still get the Chromium/Chrome model, where you can't release the actual source to the binaries you ship, and worse yet others can't easily fork your "open-source" app while keeping the functionality or redistribute your binaries. > The page you linked clearly says that non-commer…

You are again spectacularly incorrect, this time about the relationship between the distribution of open source code and patent law.

It is perfectly 100% legal to distribute uncompiled source code without a license to any related patents. After all, it's a description of the patented machine and not the machine itself, much like an ideal patent application. Where you run into trouble is distributing the compiled binaries, the actual machines covered by patents.

You can get into no trouble at all over source tarballs of ffmpeg, but Debian is deathly afraid of hosting usefully-compiled debs of it in their repositories for a reason.

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

#120

Post by bzbarsky »

Locke1689 wrote: post #106
bzbarsky wrote: post #102

Earlier quoted context omitted.

> doesn't necessarily mean the entire browser has to be closed. Right. I did say that #1 can be worked around. If you you you approach, you still get the Chromium/Chrome model, where you can't release the actual source to the binaries you ship, and worse yet others can't easily fork your "open-source" app while keeping the functionality or redistribute your binaries. > The page you linked clearly says that non-commer…

"commercial use" in that context includes putting it up on a website that has ads. So yes, not everyone has to pay to create content. If you find someone who will give you a free encoder for which they paid the licensing fees, and you make sure that either you don't put your content on the web or if you do that there are no ads on the page and you don't charge for the videos, then you can get away with paying nothing…

You're misunderstanding the statement. That seems to be pretty common.

H.264 has royalties that you need to pay to produce a licensed encoder.

Then it has _separate_ royalties you have to pay to take content encoded with a licensed encoder and send it to someone else.

Furthermore, whether an encoder is "licensed" depends on what you do with its output; the details are in the license that came with your encoder.

The statement you linked to is that the royalties on sending to someone else don't have to be paid as long as you're giving it to them for free and sending it over the internet _and_ your encoder is licensed for whatever else is going on (e.g. if you're making money in the process then your encoder has to be licensed for that).

I'm saying that to produce the content in the first place you have to pay money to the MPEG-LA. If you don't, then anyone you send it to has to pay money to the MPEG-LA. Here "has to" just means "they can sue you and will win if you don't, since the licensing terms don't allow you to do that". They might, of course, not sue you. That's up to them.

Further, most encoders out there are not licensed to produce content you make money from (note that this is NOT the same as charging users money). So you'd have to buy your camera, then pay the MPEG-LA for an encoder license that allows commercial use. This is a one-time payment. Then you could stream the resulting encoded media as much as you want and not have to pay for each download that happens. The per-download fees are what they waived.

Post reply on HN