4 ms·

...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 r

by jrabone 13y ago

...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.

soperj 13y ago
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.
- jallmann 13y ago
  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.
  - Shooti 13y ago
    IIRC VP8 requires less processing power at the same bitrate.
    - jallmann 13y ago
      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.
      - ZeroGravitas 13y ago
        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.
        jallmann 13y ago
        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.
        ZeroGravitas 13y ago
        > 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.
        jallmann 13y ago
        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."
  - dannyr 13y ago
    Who would want you to have more power though? Google or MPEG-LA?
  - ajross 13y ago
    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.
    - jallmann 13y ago
      > 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.
  - bad_user 13y ago
    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#Unisys_and_LZW_patent_enforcement 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.
  - VikingCoder 13y ago
    MPEG-LA ($6.5mm/yr max) I presume you're getting that from here: http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf 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?
    - wmf 13y ago
      My reading is that the cap is per company, not per OS.
  - rdtsc 13y ago
    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.
anxiousest 13y ago
No worries, unsupported platforms will fallback to the plugin: http://gigaom.com/2013/08/28/hangouts-hd-vp8-webrtc/ http://gigaom.com/2013/08/28/hangouts-hd-vp8-webrtc/
pthatcherg 13y ago
Hangouts works with all of the major browsers, including IE. What exactly is your complaint?
- drivebyacct2 13y ago
  Facts aren't really required for rants on HN anymore. And that's entirely regardless of who it's aimed at.
devx 13y ago
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.
- pthatcherg 13y ago
  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.
- ZeroGravitas 13y ago
  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.
- masklinn 13y ago
  > 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#section-3.2 http://tools.ietf.org/html/draft-cbran-rtcweb-codec-02#secti...
  - zanny 13y ago
    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.
patrickaljord 13y ago
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.

by jrabone 13y ago

soperj 13y ago

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.

jallmann 13y ago
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.
- Shooti 13y ago
  IIRC VP8 requires less processing power at the same bitrate.
  - jallmann 13y ago
    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.
    - ZeroGravitas 13y ago
      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.
      - jallmann 13y ago
        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.
        ZeroGravitas 13y ago
        > 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.
        jallmann 13y ago
        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."
- dannyr 13y ago
  Who would want you to have more power though? Google or MPEG-LA?
- ajross 13y ago
  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.
  - jallmann 13y ago
    > 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.
- bad_user 13y ago
  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#Unisys_and_LZW_patent_enforcement 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.
- VikingCoder 13y ago
  MPEG-LA ($6.5mm/yr max) I presume you're getting that from here: http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf 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?
  - wmf 13y ago
    My reading is that the cap is per company, not per OS.
- rdtsc 13y ago
  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.

anxiousest 13y ago

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

pthatcherg 13y ago

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

drivebyacct2 13y ago
Facts aren't really required for rants on HN anymore. And that's entirely regardless of who it's aimed at.

devx 13y ago

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.

pthatcherg 13y ago
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.
ZeroGravitas 13y ago
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.
masklinn 13y ago
> 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#section-3.2 http://tools.ietf.org/html/draft-cbran-rtcweb-codec-02#secti...
- zanny 13y ago
  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.

patrickaljord 13y ago

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.