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

I fully agree with the article. Google's move makes me very angry, for two reasons:

1) Google uses us as tools in its battles and wars, because it is us who will be inconvenienced for years to come if companies continue to fight over video codecs. Sure, the explanations are grandiose — "we fight for openness" and the like — but the fight is being done by our expense.

2) Google's hypocrisy is unbelievable. H.264, an ITU/ISO standard, documented, with reference implementations, with a free/oss encoder (x264) and hardware support in a bazillion devices is called "closed and proprietary". Meanwhile, Adobe Flash (which this whole fight will just strengthen) is just fine, thank you. Oh, MP3 and AAC are fine, too.

I'll skip over technical details in this post, suffice it to say that I know and understand why H.264 (especially Main and High profiles) is vastly superior to On2 VP8 (now renamed WebM).



Google's move is not about "open". The term "open" here is just used as a horse upon which the knight is riding. The long-term ulterior motive is to dominate video on the web.

The h264 removal in Chrome is probably an experiment more than anything else. It will make people remember the h264/WebM debate again, and it will show that Google takes a stance for WebM.

The long term goal is to fragment h264. First move is this. The next move is to play an alliance with Adobe: We can make your Flash survive for 5 more years if you include WebM playback in it. Then you play the piece where you force Apple to adopt WebM by virtue of Youtube: you let it hint that Youtube will in the future only play back WebM. At this point in time, all Android devices have WebM hardware decoding circuits (notice that mobile phones have an incredible short half-life time. You don't see a 3-4 year old mobile phone much these days).

At this point, all of the internet is WebM capable and h264 has been limited to every device which is non-internet. The MPEG-LA consortium will have been marginalized by this time and will have to bite the apple and add in WebM support as well.

/conspiracy


And this is a bad thing?


Let's see, international ITU/ISO standard designed by video professionals (not web search people) vs. WebM de facto "standard" controlled by Google.

I think I know which one the world is behind and which one Google is behind. I vote: world.


I am not particularly on a side here though my bias is that I lean slightly towards WebM.


I think I agree with you, but what does Google stand to gain from controlling the video standard that they don't get from h264?


A couple of things:

First, Google is interested in boosting the web indirectly because it puts their technology (adwords) out there in the right place. If you watched most of your video over WebM over the net, it would indirectly benefit Google. They also know that a large part of their power stems from the fact that they do "nice" things for their users, while their customers pay Google to facilitate a link between googles users and googles customers through adwords. Using their market share for the "greater good" is highly valuable to them in the long term.

Second, if you own the WebM format, you could use it to bully the MPEG-LA members individually. MPEG-LA is an alliance with the sole purpose of keeping everyone else out of the alliance. The patent pool in MPEG-LA is a defensive measure - not an offensive one.

None of the things Google does seem to be short-term invested. It rather looks like they are shooting for 5-10 years ahead.


x264 may be free software to download, but you are still obliged to pay MPEGLA license fees under most circumstances if you actually use the videos you encode with it.


It depends on how you use them and what you use them for. But in general, yes.

So perhaps Google should start saying openly it's about the money, not about "openness" (which seems to be defined every week as something different by one company or another).


Once money/licensing is involved, it does become an issue of openness. Think of it as the letter of the spec versus the spirit of the spec.

If h.264 becomes the de facto standard for HTML5 video encoding, then a browser such as Firefox, or any free/open browser, will be financially unable to implement a completely standards compliant browser due to the cost of licensing.

Yes, one could supply other codecs to support the video tag since no codec is specified in the spec but if the majority of content out there is focused on h.264 then the effect is the same as not supporting the video tag at all.


> you are still obliged to pay MPEGLA license fees under most circumstances

As far as I am aware software patents only hold in the USA and a few other countries that the US has strong armed into accepting them. So I don't think you need to worry about the MPEGLA coming after you if you are somewhere on the other 90% of the planet.


I am far from a lawyer, but there are several international patent treaties, signed by a wide range of countries. See - http://en.wikipedia.org/wiki/List_of_parties_to_internationa...

Also there's the World Intellectual Property Organization (http://en.wikipedia.org/wiki/World_Intellectual_Property_Org...) of which the majority of counties are members.

Yes, specifically software patents may be considered a bit of an unconfirmed area, but I doubt it's something many people would want to risk going up against.


The last person they list as being sued on their news page is Lidl, a european supermarket chain.

http://www.mpegla.com/main/Pages/Media.aspx


The licenses fees don't kick in until you ship something like 10,000 units, then it is something like $0.25 per unit for decoders. (numbers from memory, consult mpeg-la for accuracy).

So anyone is free to tinker with x264 as much as they like. The people who have trouble are the free OS distribution folks, e.g. Debian, who ship enough to trip the license… and google chrome.

Maybe they just got tired of paying a quarter for each download.


While you are right pointing out the notion of triggering a limit breach and thus having to pay out the dues, that is exactly what needs to be avoided. This is not a home-brew, I made a tinker-toy use case that Mozilla and Google are describing. They are defending a ubiquitous tool such as a browser, that is prevailing as the de facto standard of accessing information. That channel needs to be kept free.

Imagine a scenario where an ink/printer producer patents blending of the colors and every newspaper in the world has to pay $0.25 for every paper they print after 10,000 units.

What I hope that people understand, and I'm aiming high by including the well connected writers and media personnel, that tools that serve as backbones for information flow need to stay free. There are software engineers working on that tirelessly. To undo their effort or trip them up, is to hurt the very rights to freedom to information.


Imagine a scenario where an ink/printer producer patents blending of the colors and every newspaper in the world has to pay $0.25 for every paper they print after 10,000 units.

It's far worse than that! My city's newspaper is printed with patented ink[1]. They pay for every drop they use, even for papers they don't sell, even for ink they wash down the drain.

And your numbers are way off. Imagine if I had to pay a one time $0.25 fee to read my $22/month newspaper would be more like it.

I look forward to a time when I can code and not worry about patents[2], but hobbling people to make a strategic move is not the path to that end.

  Cost                         Thing
  ################             Computer hardware: $400/year
  #######                      Computer software: $200/year
  ##                           Power for computer: $50/year
  ############################ Internet connection: $720/year
  .                            H.264 license: $0.25 

  (Note: The graph is probably off. I have 26 pixels in a #
         so the '.' would need to be a single pixel, but is four.
         So, mentally expand the '#' lines by 4 to get the
         perspective right. Oh, and that is not annual, so 
         maybe another three times.

         And while we're at it, notice that video is probably your
         biggest bandwidth need and that by using a more efficient 
         encoding you can use the next tier down at your ISP or 
         pay for fewer bits and save 100 times the cost of the 
         H.264 license.)
[1] Probably. They announced switching to the new eco friendly ink with great fanfare. I suspect if they went back to a traditional ink I would not hear.

[2] I've personally cancelled a lucrative product after development was completed over patent fears (needlessly it turns out, the patent owner in question never elected to go hunting and we probably didn't infringe but were unwilling to endure the legal distraction), and just this week was discussing picking the bones of a local company that briefly stepped on a ridiculous software patent and had their plug pulled by the parent company instead of fighting the lawsuit.


Google uses us as tools in its battles and wars

Every company does. Or do you really believe that Apple is actively preventing Flash just because they really care about the consumer?

Google's hypocrisy is unbelievable

Google is a big company. The world is full of crazy and complicated choices, and there are many shades of gray.

I'll skip over technical details in this post...

Um...okay. Thanks.


> Or do you really believe that Apple is actively preventing Flash just because they really care about the consumer?

Microsoft (Exchange), Cisco (VPN), Yahoo (Mail and Weather), and Google (Mail and Maps) all have code and/or data provided by the OS in iOS. In all of these cases, these third parties improve the iOS experience without any significant trade off.

Flash on the other hand has a huge trade off in application responsiveness and battery life. These are features Apple touts as being important to how their device is the best device for their customers. Flash would undermine those features, and Adobe has had a poor track record of delivering on promises regarding Flash (significant performance improvements are always one release away, for example), especially for non-Microsoft OSes.


Also, of those companies, most have contributed specifications (Microsoft, Cisco, Yahoo), and one contributed code (Google, with the initial version of Maps). All of that code is now under Apple's control, and if Apple needs to fix it or update it or debug it they can do so.

Flash, on the other hand, is closed-source. Adobe could, at best, provide Apple with a binary plugin to drop in. Apple would not be able to fix any bugs or track down any problems, and judging from their performance on OS X, it would be the source of a lot of crashes Apple couldn't do anything about. Apple might announce iOS 5.0 in June, a few days before or after Flash 11 comes out. Now what does Apple do? Rush to incorporate a major version change into a minor version release? Hold off on releasing until Adobe can get them a stable version? What if it's buggy? Now users who bought a new iPhone with iOS5, or users who updated to iOS5, think that Apple's released a buggy release, when in reality they've released a (probably good) release with a crappy version of Flash. This is exactly what happened with Snow Leopard already, and Apple caught flak for distributing buggy software because Adobe had released security fixes after SL went gold.

It's not about control, but determination. Adobe for years hasn't been able to show off a stable, reliable, and performant release, and so in exchange for Apple accepting Adobe's crappy code into the OS, Apple would also lose the ability to speak for the quality of the OS and experience as a whole. It's lose-lose for Apple, so where's the incentive? They got screwed with Snow Leopard, they'd get screwed with iOS, and in the end the ones who suffer are the end users, who can either wonder why their browser is so slow/crashy/laggy/jittery when scrolling, or who can wonder why they don't have Flash, but then shrug it off because most sites don't need it.




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

Search: