Google Hangouts goes HD
plus.google.com
plus.google.com
http://arstechnica.com/gadgets/2013/08/google-hangouts-upgra...
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.
Make no mistake about it, this move is a play for power under the guise of good intentions.
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.
More competition in the codec space is a very good thing, but VP8 is a relatively weak entry IMO.
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.
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."
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.
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.
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.
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?
> 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.
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.
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...
You are aware that there are open source H.264 encoders and decoders?
> In countries where patents on software algorithms are upheld, vendors and commercial users of products that use H.264/AVC are expected to pay patent licensing royalties for the patented technology that their products use. [...] All other royalties remain in place, such as royalties for products that decode and encode H.264 video.
1. http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Controversies
edit: s/free/not free/
This is one of the main problems with software patents: they are so broad and numerous that it's impossible to write non-trivial software without infringing on something without even realising it.
[1] http://www.digitaltrends.com/computing/google-fined-5-millio...
On the other hand, patents really aren't so broad and those that are can be and have been overturned in court for being too general - with exceptions of course, of which you hear because they are so outrageous (like Amazon's 1-click patent).
In reality, it's really hard to prove that something is infringing on a patent, if the infringement wasn't intentional. In the Oracle versus Google case, Oracle was hoping they'd get Google with copyright infringement (of APIs no less), the patents involved being just in case the copyright infringement claims wouldn't work. Google won on all fronts.
The reason for why threats of patents infringement are so dangerous is because few companies are willing to make a stand and would rather settle.
http://x264dev.multimedia.cx/archives/377
Addendum C: Summary for the lazy
VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1. It’s not even close to competitive with H.264 Main or High Profile. If Google is willing to revise the spec, this can probably be improved.
VP8, as an encoder, is somewhere between Xvid and Microsoft’s VC-1 in terms of visual quality. This can definitely be improved a lot.
VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much; VP8 as a whole is similar in complexity to H.264.
With regard to patents, VP8 copies too much from H.264 for comfort, no matter whose word is behind the claim of being patent-free. This doesn’t mean that it’s sure to be covered by patents, but until Google can give us evidence as to why it isn’t, I would be cautious.
VP8 is definitely better compression-wise than Theora and Dirac, so if its claim to being patent-free does stand up, it’s a big upgrade with regard to patent-free video formats.
VP8 is not ready for prime-time; the spec is a pile of copy-pasted C code and the encoder’s interface is lacking in features and buggy. They aren’t even ready to finalize the bitstream format, let alone switch the world over to VP8.
With the lack of a real spec, the VP8 software basically is the spec–and with the spec being “final”, any bugs are now set in stone. Such bugs have already been found and Google has rejected fixes.
Google made the right decision to pick Matroska and Vorbis for its HTML5 video proposal.
Funny that he himself wrote a ffmpeg VP8 decoder that was between 25 and 33% faster than the libvpx decoder, which had already been improved from when he reviewed it. He said at the time it was faster than ffh264 even with more work to be done.
http://x264dev.multimedia.cx/archives/499
Some recent Google tests suggests that the two ffmpeg decoders basically are the same speed when using one core (2% advantage to VP8) which rises to a 32% advantage to VP8 when using 8 cores.
http://downloads.webmproject.org/ietf_tests/vp8vsh264-decode...
Orignal link: http://gigaom.com/2013/08/28/hangouts-hd-vp8-webrtc/
http://venturebeat.com/2013/08/28/webrtc-gets-a-boost-google...
"That’s why, moving forward, Vidyo actually wants to support WebRTC and open video codecs. The company is announcing Wednesday that it will contribute client-side scalable video coding technology to VP9, the next generation of Google’s open video codec. Vidyo will also cooperate with Google to incorporate some of its technology into enterprise versions of Hangouts."
On another note, I find it really annoying how people equate video resolution with video quality, when the only thing the resolution really tells is how much detail the video could potentially have. Bitrate and encoding settings will matter much more - if you're using low bitrates (like what you'd tend to see in real-time video calls) a HD video can easily end up looking worse than a lower-resolution video at the same bitrate. This dual move to HD and the switch to a worse format (compression-wise) might just end up doing exactly that (though I haven't actually used Hangouts myself so I can't speak for its current video quality).
Then again, it takes this kind of thing to push hardware makers and ISPs forward. If a lot of people want to use google hangouts with HD, it will create a call for internet connections with fast upload speeds (rather than a bias towards download as we see now).
As for if they have enough bandwidth for HD, there's only one way to find out :)
They may not bump up the bitrate exactly proportionately to the increase in resolution, so the effect may not be as pronounced as you think.
Dammit Google, quite making amazing products. I'm trying to move away from using American products with NSA backdoors.
The other thing I should have mentioned is that I'm also concerned with sharing a hangout to YouTube for later viewing. That, right now, is only supported for 480p, which is completely unusable for screencasts that contain text.
I'm hoping Daala + Opus conferencing and streaming can enter Jingle in the next few years, see it mainlined in jabber, and that could be a good alternative. Self-host your own xmpp server if you want, or use a web service that provides it (like Talk did).