Google's H.264 decision: It's all about YouTube costs | Hacker News Reader

Google's H.264 decision: It's all about YouTube costs

zdnet.com

32 pointsTomOfTTB38 comments

This makes no sense. He seems to talking about the cost of having to store multiple formats. However, the only reason they have both WebM and H.264 is because they spent $100 million to acquire WebM. They could have simply not bought WebM, saved $100 million, and they would not have the storage problem.

It would make more sense if it is about the licensing cost of H.264, for the encoder they use and for their commercial streaming of H.264 video (does it count as commercial when they are not charging users for the video, but are monetizing the site with advertising?).

However, given the cap on annual license fees under the H.264 license, what they spent to acquire WebM would have covered their YouTube H.264 license fees through the remaining lifetime of the H.264 patents.

> They could have simply not bought WebM, saved $100 million, and they would not have the storage problem.

Is it not the case that even using just h264, Youtube currently has to store several encodings using different codec profiles in order to target different devices, including low power ones like the iPhone? See my reply to macrael for why this might not be the case with WebM: http://news.ycombinator.com/item?id=2098874

Confirmation bias, the author is a Infrastructure Architect, so he sees the problem as such.

> Infrastructure build-out and optimization strategy is something I know a great deal about. It’s what I do as my day job as an Infrastructure Architect at IBM — understanding what our customers need to do in order to minimize their infrastructure overhead in terms of systems, storage, networking and facilities as they plan for further growth.

And yet he seems to believe petabytes are bigger than exabytes. This and the rest of the text makes me believe he doesn't know perfectly his subjet, to say the least...

Storage is cheap, and getting cheaper by the day. I don't think there's any reason to believe it's not going to continue that way in the foreseeable future.

EDIT: to give some numbers to the argument, I know that two years ago you could buy one petabyte (that's one million gigabyte) worth of storage for less than a million $.

> (does it count as commercial when they are not charging users for the video, but are monetizing the site with advertising?

Yes.

The license[1] mentions both 'free television' and 'renumeration from other sources'

[1] http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsS...

They specifically grant a perpetual royalty-free license for internet broadcast where the end user doesn't pay a subscription or per-video fee, though:

In the case of Internet Broadcast AVC Video (AVC Video that is delivered via the Worldwide Internet to an End User for which the End User does not pay remuneration for the right to receive or view, i.e., neither Title-by-Title nor Subscription), there will be no royalty for the life of the License.

The AVC (h.264) licensing rate according to ( http://www.streamingmedia.com/Articles/ReadArticle.aspx?Arti... ) goes up to $100,000 per year for over a million subscribers and can not exceed $5 million a year per enterprise. AAC, the audio codec that usually goes along with AVC might be $1,200,000 per year ( http://www.vialicensing.com/licensing/aac-fees.aspx ).

Given that the last AVC patents expire at 2028, there's seventeen years left where Google might still have to pay the annual fee that wouldn't exceed a few million dollars (though at the last few years when there's something like one patent that's still valid, I doubt the patent pool really could be enforced). The On2 acquisition was $124.6 million ( http://www.computerworld.com/s/article/9159738/Google_closes... ) and probably a lot more for the ongoing development.

Assuming, rather reasonably that there's 12 years left for AVC (that's doubtful, it'll probably be ancient in a few years), the recurring fees for YouTube's licensing would need to exceed $10 million a year for the argument to make sense.

The license even perpetually exempts non-subscription, non-pay-per-view internet broadcast, so Google won't owe any royalties unless they start broadcasting on television, start offering a subscription version of YouTube, or start offering pay-per-view videos.

See the top of the last page of: http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsS...

This just doesn't make any sense. They still need to transcode to H.264 for Mobile Safari, Safari (using Youtube's HTML5 mode) and soon IE9 too; none of these have announced plans to support WebM. Not to mention the fact that the flash videos are generally H.264 wrapped in Flash. If they wanted to cut storage costs then they'd be better off dropping support for WebM.

Also, I'd imagine that the storage cost for Youtube doesn't come close to their bandwidth costs.

Exactly - I don't think they'd deprecate every hardware accelerated platform they already have (tens if not hundresds of millions of phone/computer/settop units shipped) for something with no shipping (only promised) hardware support.

I think Google's playing the long game here. So they won't switch tomorrow but they'll try to make WebM the defacto standard by getting everyone but Apple on board. Then they'll leverage the open nature of the codec and its new found market dominance to force Apple's hand.

This is the same strategy Apple's using against Flash by only supporting HTML5 and to my eyes it's working.

Apple's reasons for not supporting Flash on their mobile platform are primarily performance reasons.

It's not only Apple that isn't supporting WebM by the way, IE9 won't support it (unless you have a VP8 codec installed). In fact, the only browsers that currently support WebM in their latest stable versions are Chrome and Opera. Remember that flash doesn't support WebM yet either.

WebM might well become more popular than H.264 for web video in the next couple of years and I wouldn't be all that surprised if Apple supported WebM in their next Safari release. But… I'd still be very surprised if YouTube stopped encoding videos into H.264 in this decade.

Apple's primary reason for not supporting Flash is that there is not a "Browser Plugin Store", there is an "App Store", and Flash is decidedly not an "app".

Mozilla is also supporting it. Upcoming Firefox versions will support WebM. Even IE9 will support WebM with HTML5 when the codec is installed locally on windows.

As will Safari on Mac (it supports theora if a codec is installed).

> Apple's reasons for not supporting Flash on their mobile platform are primarily performance reasons.

But Apple also wants to protect its monopoly for iOS app developers and App Store distribution. The Flash plugin would allow application developers to write cross-platform apps and bypass the App Store.

He seems to harp on the costs of a SAN as one of the drivers(not surprisingly, he's an IBMer), but according to http://highscalability.com/youtube-architecture they're running off of BigTable.

BigTable is basically a (distributed) Google-proprietary SAN. Lots of Storage, distributed over a really big Area ;-), and lots of Networking.

BigTable is a SAN without the SAN cost. It's all software.

That is more accurate. In terms of hardware + software it is closest to the Sun storage appliances which are Solaris or Linux with ZFS plus management tools.

The Sun promotional literature[1] refers to 70%+ cost savings on their units over comparable systems from EMC (the old school market leader). It was the fastest growing product at Sun, as it allowed companies to cut down storage costs using a model similar to what Google pioneered with Big Table and GFS.

[1] http://www.oracle.com/us/products/servers-storage/storage/un...

Exactly. This is what google excels at. At most IT shops redundant SAN storage and massive server capacity is hugely expensive because there are such incredibly high maintenance and personnel costs associated with such things. Google solves the problem by automating the ever loving crap out of everything and using commodity hardware (rather than "server-grade" stuff). The result is dramatically lower costs for things like redundant, networked storage. Allowing google to do things like offer free multi-gigabyte email accounts to everyone in the world or like upgrading youtube from 10mb/10min videos at sub-analog TV quality to 1080p unlimited length videos in multiple codecs.

From Google's perspective making use of these massive storage capabilities is a plus for them. They are able to do it at much lower cost than just about anyone else, so when they find a business case where they can leverage their storage capabilities they are smart to do so because it can translate into a competitive advantage. When you've got the fastest dragster on the strip you don't go around figuring out how to use it the least, rather you try your damnedest to race every car that you can.

I'm starting to think the real reason behind this is that google hasn't been able to flesh out any of it's flash-based advertising products for html5, and know that it won't be easy to do so (people can hide ad divs or download the source videos trivially; no way for them to guarantee content protection to publishers). I think that they realize that the only way for them to stick with flash without being seen as behind the times or anti-"open" is for them to prolong the codec dispute by requiring flash for all of the h264 videos out there by removing native support. As a side effect, users of safari and IE who want to view youtube webm content will have to use a flash wrapper as well if I understand it correctly. This isn't to say that a long term goal of html5 video served via a patent-unencumbered coded isn't a motivation of theirs, I just think that the decision to remove native h264 right now is more of a way to keep flash a practical option than an ideological move.

This isn't to say that a long term goal of html5 video served via a patent-unencumbered coded isn't a motivation of theirs, I just think that the decision to remove native h264 right now is more of a way to keep flash a practical option than an ideological move.

If they want to achieve that long term goal, isn't it obviously better to act sooner rather than later?

I agree, but it depends on how much removing native support for h264 this soon advances the state of html5. We are still convincing content-publishers to adopt html5. Dropping support right now and forcing people who want to support html5 video to dual encode and wrap content in flash for the sake of compatibility might slow adoption more than waiting for more people to get on first, then pulling the plug.

If this is the truth and they are going to switch completely over to WebM on YouTube, I have one big question. What does Google gain from having control over the video format that they wouldn't get from h264? The only operative difference between the two codecs is that WebM is free. Surely, to justify being responsible for the enormous amount of money the world will spend to switch from one to the other, they have a better reason than "it's free."

Not being at another company's mercy seems like reason enough to me. Right now Google is a company that's sunk hundreds of millions into Android and it's all at risk because Oracle bought Sun. I'd imagine that wake up call made them look at other vulnerabilities in their product line.

But what company are they at the mercy of for online video? The whole point of the open standard that is H264 is for a group of companies not to be at each other's mercy. It seems riskier to switch to a new format created by one company than to go with the standard everyone else backs. I think there must be another answer.

MPEG LA can still change the terms whenever they please and theor recent behavior has been troubling (http://www.techdirt.com/articles/20100430/0232599255.shtml)

This. Look who are major patent holders at MPEG-LA: Microsoft and Apple. Do you trust your blood enemies to a gentleman's agreement? MPEG-LA has been decidedly vague and "don't worry, be happy" about their long-term royalty plans. One might assume they would never increase the price, but can you be sure?

In fact, MS and Apple could even pull out of MPEG-LA at some point and charge exorbitant fees. Google simply does not want to be at any risk for that sort of FUD in the marketplace. I think that, combined with their ideological DNA (Patents BAAD, open source GOOOD) explains the decision pretty well.

> This. Look who are major patent holders at MPEG-LA: Microsoft and Apple.

Do you have a source for that? I've read quite a few times that at least Microsoft pays more for licenses than they get back.

http://www.mpegla.com/main/programs/avc/Documents/avc-att1.p...

Microsoft: US patents: US 6,563,953 US 6,735,345 US 7,289,673 and a number of foreign filings, likely of the same IP.

Apple: US 7,292,636 US 7,548,584 US 7,551,674

US 7,339,991

doesn't matter if they pay in, the point is they are patent holders, and have a say in licensing terms.

Perhaps they have an idea on their hands that they project will make them craploads of money. Google TV might be one such product.

Perhaps they project that H264 might want a share of that money anyhow it can, so they decided to cut it off right away.

> The only operative difference between the two codecs is that WebM is free.

by moving many features of the codec into postprocessing, the video format becomes scalable; a decoder can do “less work” while still playing back the file, albeit at a lower quality. -- http://x264dev.multimedia.cx/archives/292

I have naively taken that to mean that the trade-off of resolution for battery life can be handled in the decoder; that fewer encodings need to be stored on the server to target the same wide range of devices, vs. h264.

I would love to know whether this is true, and what other practical differences there are between the two codecs from the POV of content producers.

edit: VP8 ... Technically, it produces output on par with H.264 High Profile, while maintaining a low decoding complexity on par with H.264 Baseline. -- http://diveintohtml5.org/video.html#vp8

I have naively taken that to mean that the trade-off of resolution for battery life can be handled in the decoder; that fewer encodings need to be stored on the server

No. The reason YouTube encodes different versions is mostly for bandwidth, not battery life. Postprocessing doesn't do anything about bandwidth; a 1 Mbps stream is 1 Mbps.

> The reason YouTube encodes different versions is mostly for bandwidth

No. For example, to support iPhone prior to v4, they have to encode using the Baseline profile because that's all those devices support. The less complex h264 profiles are designed for CPU-limited devices, not just bandwidth savings -- indeed the most obvious way to save bandwidth is to use the CPU more.

It's not about the Youtube servers. I think, it's about the Youtube clients. Licensing costs may be small for Google but they are not small for manufacturers of mobile phones.

Re: http://www.zdnet.com/blog/perlow/googles-h264-decision-its-a... This is a mostly idiotic article.

First of all, for an Infrastructure Architect the guy has his storage knowledge all backwards: “With YouTube, we’re talking about exabytes upon exabytes of storage. Maybe even petabytes.”

1 Exabyte = 1,024 Petabytes = 1,048,576 Terabytes

I’m sure that it was an innocent mixup, but good grief does it come across as someone who’s trying to appear important and knowledgeable simply by tossing in some obscure computer terms.

Second, as others have pointed out as well, the whole logic of his argument doesn’t make sense. Youtube, with all its massiveness, is probably never going to be able to drop H.264 simply because it would no longer be able to stream its videos to any of the Android [1], iOS, webOS and Blackberry devices out there today. That’s hundreds of millions of devices that would suddenly not be able to play Youtube videos anymore if Youtube goes WebM only.

( [1] side note: Only Android devices running 2.3 and higher are capable of WebM, but 1: that's with a battery-draining software renderer and 2: as we know, Android fragmentation is a pretty serious thing and millions of people are still running pre-2.3 OSes and there's no way that all of them will be upgraded at some point.)

Quoth the fool Jason Perlow: My guess is that in addition to Android licensees, Apple and other device manufacturers which use embedded browsers such as RIM are not going to deny their customers and end-users embedded YouTube video support if Google chooses to encode to to a VP8/Theora standard, and I would expect the same of Microsoft and Internet Explorer and its embedded variations as well. Mozilla and Firefox we already know is completely on-board.

Yes, I'm sure Apple, RIM, Microsoft and HP/Palm can somehow magically upgrade all the devices they have already sold to millions of customers and add WebM support to them. It’s not like if you're the owner of an iPhone 3G you can't install the very latest version of iOS on your device. Oh, wait. You can't.

Simply put, the chance of Youtube dropping H.264 entirely and only maintaining their videos in WebM container format using VP8 is about 0.01%. It's higher if you look WAY far into the future, when absolutely no one uses ANY of the 300+ million mobile computing devices we're using today anymore. But that's a whole lot of years into the future, and also depends entirely on Microsoft and Apple adding WebM support to their devices when they don't yet have much incentive to do so. Or at least, it won't be because of Youtube.

There should be no doubt that Google wants there to be only one format for video on the Web, 20–30 years from now, and that they prefer it to be WebM instead of H.264 if only so that they (and you, using their infrastructure) can sell video whenever and wherever they (and you) want without having to pay MPEG LA for it. Storage and technical specifics of the video format are secondary concerns which are actually great arguments against this logic, for the situation in the "short" term that is the coming 5 to 10 years.

So all in all, sure, Youtube is an obvious motivator for this kind of move, but the article has the entire thing backwards in explaining it.

nah, doubt it.

Reply on news.ycombinator.com