Hacker News Reader

Comment by jrabone | Hacker News Reader

...thus pissing off everyone using Hangouts for tech support to people who are only ever going to have Internet Explorer installed. Thanks a bunch, Google.

I really want to crack some skulls together over the state of video compression codecs and OS support. Same thing happened with all the circle-jerking about HTML5 video - Flash had AS STANDARD a bunch of useful codecs (eg. Screen Video) for which there is no HTML5 good replacement if you want to do a lossless screencast.

View on HN

It's a free service. They do what they want with it. I think supporting the Open Source codec is a good thing. edit: also from the article(First Paragraph) "The H.264 plugin will still be supported for browsers that do not support VP8: IE (of course), Safari, and older mobile clients." So... there's that.

Being "open source" has nothing to do with it. The H.264 specs are open, there are plenty of FOSS tools available, and its supported ecosystem is much more robust. The only advantage to VP8, from a developer's perspective, is in being royalty-free. But the cost borne by Google in acquiring and developing that IP dwarfs any potential royalty to MPEG-LA ($6.5mm/yr max).

Make no mistake about it, this move is a play for power under the guise of good intentions.

IIRC VP8 requires less processing power at the same bitrate.

This wasn't the case last I checked (with x264), especially if you consider video quality. Historically VP8 has been much slower, mostly because existing H.264 tools have had more time to mature.

I assume they mean power to decode, which makes sense if the article talks about decoding 10 other chat participant's video streams.

I also believe, based on stuff discussed regarding WebRTC that some H.264 advantages don't apply in realtime encoding, like B-frames and so it's a much closer comparison than encoding a movie for streaming. The various submissions to the IETF mailing list arguing for one or the other on technical merit basically came down to a tie.

I wrote one of the first de/packetizers for VP8 RTP back when the spec was released. My impression was that the codec isn't really designed for network transmission. The probability table for the entire frame is sent up-front, so any loss of that makes the entire frame undecodable, and there's no slicing/IDR or NAL-like layer. It's fairly unworkable without a reliability or error-correction layer on top.

More competition in the codec space is a very good thing, but VP8 is a relatively weak entry IMO.

> My impression was that the codec isn't really designed for network transmission

That seems unlikely since the major user of its predecessor VP7 was Skype (and before that VP6 was the "web codec" in Flash for a while). Maybe you could make a case that it has flaws that could make it better for this, but it seems silly to claim it was designed for a different use-case.

VP6 in Flash was always delivered losslessly over TCP, and never used for video capture in Flash. Skype is what makes VP8's shortcomings (for video chat) even more interesting, but On2's codecs show a very clear evolutionary path even from VP3. My guess is they didn't want to deviate too much from what was tried-and-true.

Doesn't change my opinion, though -- I think it's more the case of "Well, this works well enough for video chat, if you also do this and that" rather than "We designed this from the ground-up for low-latency, unreliable operation."

Who would want you to have more power though? Google or MPEG-LA?

That's a little disingenuous. H.264 ships with pretty much zero open source distros (the only exception I can think is the software codecs in the AOSP images -- but even there I strongly suspect it works only because Google paid a license as part of a bigger deal) because of the patent restrictions.

That's not true of VP8. So the complaint upthread (about VP8 not working on IE) flips on its head: if you care about video working out of the box on open source OSes, then H.264 is a non-starter. Maybe you don't (I can pretty much guarantee that you don't, actually -- in fact from your tone and the "side" you picked I basically assume you're running iOS and OS X exclusively).

But some of us do care, and are quite grateful for VP8 making that possible. I don't feel like getting into an argument as to whether this constitutes a "power play", but it certainly seems like "good intentions" to me.

> from your tone and the "side" you picked I basically assume you're running iOS and OS X exclusively

Please don't mistake technical pragmatism for ideology. I'm a big supporter of software freedom, most of my work involves codecs like these, and it's almost always on Linux, which is my daily machine. Don't get me started on how fucked up iOS is (both technically and ideologically!).

There's no argument from me that software patents are a plague, and that does make codec distribution tricky. But Google isn't doing this so users can avoid the step of apt-get'ing ffmpeg.

Mozilla too has fought against H.264 since the beginning. They'll be thrilled that Google is taking this new step towards VP8.

Also, it really doesn't take much brain to figure out why H.264 is dangerous:

1) no open-source software can ship with H.264 (so Firefox cannot ship with H.264, unless it fallbacks to the OS's codecs, which they now do, or if they cut a deal with MPEG LA). Also, Mozilla is lucky because they do make money and they could cut a deal, but most open-source projects don't have sponsors with pockets that big.

2) MPEG LA is not a real standards body, not like ISO. They are some firm in Denver. Those patents may be reasonably licensed (RAND) right now, but they can change those terms whenever they wish to do so. The only companies protected are those that had contributions in that pool (e.g. Apple, Microsoft)

3) See what happened with the GIF format and the LZW patent: http://en.wikipedia.org/wiki/Graphics_Interchange_Format#Uni...

And most importantly for people that care about the web - the web needs to stay open, where "open" in this case really doesn't mean open for companies and organizations with pockets full of millions of dollars.

MPEG-LA ($6.5mm/yr max)

I presume you're getting that from here:

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

But that specifically states that the maximum is per operating system.

Well, what if it turns out that's entirely too vague? What if MPEG-LA is telling Google that each ROM for each Android is a different operating system?

I don't know. Do you?

My reading is that the cap is per company, not per OS.

Fuck MPEG-LA, we are not paying them anything.

> The only advantage to VP8, from a developer's perspective, is in being royalty-free.

Good enough for me. Once it is in Chrome.

> Make no mistake about it, this move is a play for power under the guise of good intentions.

Make no mistake software patents are a scam disguised as way to "enhance and protect" innovation.

Hangouts works with all of the major browsers, including IE. What exactly is your complaint?

Read the article, they'll support both. Besides, hangouts requires a plugin already on windows so they could include vp8 in the plugin... but let's bash Google instead.

If IE will ever support WebRTC, then they'll have to support VP8, too, which is the standard codec for WebRTC.

So how about Microsoft moves quicker in adopting open standards, instead of backing proprietary ones, or dragging their feet? It took them 2 years to even decide they will use WebGL, finally. I guess it will take them another 2 years for WebRTC.

FYI, there is no official standard video codec for WebRTC. For audio, the MTI codec is opus. For video, none has been chosen. So far, the two browsers that implement the WebRTC API have choose to support VP8, but that's not mandated by the standard.

So far lobbying, from MSFT amongst others, has prevented VP8 being declared a mandatory codec for VP8. On the other hand, Chrome and Firefox are only implementing free codecs (which right now means VP8) so inter operability with the Billions of deployed browser endpoints will require VP8 support.

> then they'll have to support VP8, too, which is the standard codec for WebRTC.

It's not. There is no mandatory video codec in WebRTC at this point, only mandatory capabilities namely:

> o MUST support at least 10 frames per second (fps) and SHOULD support 30 fps

> o If VP8 is supported, then it MUST support the bilinear and none reconstruction filters

> o OPTIONALLY offer support for additional color spaces

> o MUST support a minimum resolution of 320X240

> o SHOULD support resolutions of 1280x720, 720x480, 1024x768, 800x600, 640x480, 640 x 360 , 320x240

Source: http://tools.ietf.org/html/draft-cbran-rtcweb-codec-02#secti...

Still hoping Daala can mature and take the throne. If its mathematics truly produce a next generation of compression efficiency in video, and it is open from xiph + Mozilla, that is the biggest kind of win.

I guess Microsoft's main concern is opening up another vector for patent lawsuits by shipping hundreds of millions of VP8 decoders. Google doesn't indemnify against VP8 infringements so why would Microsoft pick up the tab when they're already paying for H264?(Which they got sued over by Googorola btw).

As far as I am aware, Google have negotiated an agreement with MPEG-LA to ensure this.

http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html

No worries, unsupported platforms will fallback to the plugin: http://gigaom.com/2013/08/28/hangouts-hd-vp8-webrtc/

Reply on news.ycombinator.com