Google statement on codecs | Hacker News Reader

Google statement on codecs

ietf.org

51 pointsvamsee30 comments

"We believe that legacy hardware for hardware video encode and decode acceleration should all be thrown out and everyone should embrace our new standard which has no such support"

Yeah, that'll fly.

I don't know why this got downvoted - we all know it's true, even if we don't want it to be.

Does anyone really believe Apple are going to support a codec that they can't hand off to power-saving silicone?

edit: it was gray when I replied

why can't apple hand off vp8 to silicon?

http://www.webmproject.org/hardware/

Does the A4/A5 support WebM?

Why should they, if they have to support H.264 encode/decode in hardware already? WebM hardware support would be an extra cost, and you'd better believe that they've got those parts spec'd down to the fraction of a cent. WebM offers nothing to Apple -- certainly not video quality, and they participate in the MPEGLA patent pools, so they're not paying for the licensing.

If WebM became a mandatory codec, they'd implement it, but they'd prefer not to.

Being in Patents Pools doesn't mean they dont need to pay licensing. It just means they are on both paying and receiving ends. Since there are thousands of patents on H.264, Apple are only recieiving a tiny amount compared to what they paid out.

The Google WebRTC team argue that differential between encoding and decoding video at web-conferencing rates is negligible compared with having the screen turned on and sending and receiving data so I wouldn't accept that argument from Apple without some numbers.

And the latest post to the mailing list provides some numbers for the other side:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg04980...

"To summarize, using a single core of the iPad3's dual core processor, software decoding of HEVC (forthcoming H.265) at 720p30 resolution and 1.5 Mbit/s bitrate is possible. A fully charged battery is empty after 8 hours. This compares to 10 hours when decoding H.264 using hardware acceleration. My take from this data point is that battery life is not all that much affected by hardware-based decoding, at least not for tablets and larger devices. If your screen and battery are considerably smaller, but your processing demands similar, hardware decoding may become more beneficial, relatively speaking. However, if you scale down video resolution with screen size, things ought to be approximately in the same ballpark.

While at this discussion, let me reiterate two other points made in the meeting. First, AFAIK, there are no hardware-accelerated encoders in today's products that could meaningfully be used for conversational applications; encoders run software-only, and their complexity is necessarily considerably higher than that of a decoder (because an encoder includes all features of a decoder exept the entropy decoding, plus all the search/mode decision mechanics, forward transform/quantization, assorted filters i.e. for motion compensation, and the entropy encoder). And second, today's hardware based decoding is not well suited for video conference decoding use, as it does not offer functionalities such as error control or concealment beyond re-sychronization after IDR pictures—and one should avoid IDR pictures in conversational applications because of their size and resulting delay."

I don't think people would be enthusiastic about the larger file sizes and extra visual noise with VP8 in fast moving videos or those with a lot of contrast comaired to H264 Encode times were much longer too. My experience may not be typical but I could not get my videos to look as good even with much larger files. I could not find anyone with real world video using it. Unless they have made some big advances recently I just don't understand how they can claim parity.

Also, Ericsson, in a different thread.

http://www.ietf.org/mail-archive/web/rtcweb/current/msg04938...

No other companies so far, apparently.

From reading Wikipedia, the choice of G.719 sounds awful, since it needs licenses from not one but two companies and Ericsson pushing it sounds like something that would benefit them a lot.

As expected of a telecoms company - they want to use the standards that are already implemented in silicone.

Has anyone blogged the feasibility of hardware acceleration of Opus? I know they have an integer implementation already, but it seems we still don't even have Vorbis support anywhere...

silicon. please.

I read the thread, no responses from Apple nor Microsoft a.t.m.

But considering WebRTC could potentially ruin much of Skype's business, a cynical guess would be that they won't make this easy.

> But considering WebRTC could potentially ruin much of Skype's business

How?

Apparently Microsoft plans to use WebRTC in the Skype Web client [1]

[1] http://gigaom.com/2012/06/26/skype-webrtc-web-client/

Yep. Skype's selling point isn't its uniqueness. There are plenty of reasonable VoIP options out there, of course. Skype's selling point is its established user base. WebRTC can only help that.

VP8 is already used in Skype, and half the tech for the audio codec Opus came from Skype's Silk codec so it's not a forgeone conclusion. Possibly Microsoft control changes that equation, but clearly Skype thought this was the future when it was a standalone entity.

Skype's value isn't a particular technical implementation, it's the install base, directory and related network effects.

WebRTC is likely to increase Skype's business (assuming the do a WebRTC implementation), at the expense of traditional telecoms and conference call providers.

Install base doesn't matter nearly as much when "installing" is just visiting a web page.

> WebRTC is likely to increase Skype's business (assuming the do a WebRTC implementation),

How so? Are their servers for sale and somehow they can license them so web clients can conference via them. Otherwise I don't get. Or are you assuming they will buckle and would be forced to implement the WebRTC protocol.

Skype makes money from call-out (to traditional telecom services), call-in (give a traditional telephone number to a Skype address) and additional features (conference calls).

WebRTC increases the potential market for all of those things by decreasing the friction - people won't even need to install the Skype client anymore.

Skype is already using VP8. But I'd really hate it if Microsoft (or Apple) acted like assholes and tried to force h.264 or some other proprietary technology into yet another web protocol. Web technologies should be free of patent-encumbered technologies. It's the only way you can ensure its sustainability and you don't run into patent problems a few years down the road.

So when is Google dropping H.264 in Chrome, as they indicated they would a year and a half ago? (http://blog.chromium.org/2011/01/html-video-codec-support-in...)

The website is down, here's cache:

http://webcache.googleusercontent.com/search?hl=en&newwi...

I could understand reasons for their support for VP8. But "superior quality" is definitely not a strength on VP8 side.

I was hoping Google would adopt Mozilla's Opus codec for audio, but I can't believe they are actually going to do it. Well done, Google!

Will Opus replace Vorbis in WebM as well, though?

This pretty much confirms what I suspected earlier ( http://news.ycombinator.com/item?id=4274757 ), namely that licensing issues are the reason for Google not having committed to it, yet. And as they said they recommend it if and only if the "remaining licensing issues can be resolved."

> I was hoping Google would adopt Mozilla's Opus codec for audio,

Is Opus Mozilla's codec? I didn't know that. I thought it was Xiph's with an effort to create an IETF draft for it.

Isn't it closer now to "Microsoft's codec" since it uses SILK (Skype's codec) for speech mode. Last time I looked at it I thought it was Xiph's codec with an effort do create an IETF standard...

Looks like Mozilla's talking about WebM while implementing hardware-accelerated H.264. https://bugzilla.mozilla.org/show_bug.cgi?id=714408

I feel like the assertion that VP8 is royalty-free needs to be taken with some skepticism given that (to my knowledge) it has not been tested in court. If Google is willing to indemnify the whole Web from liability that might be created if VP8 is found to infringe patents, then I'd say, let's make that the standard. I don't think they've done this though (or even could).

Reply on news.ycombinator.com