Google's web video ambitions bump into hard reality | Hacker News Reader

Google's web video ambitions bump into hard reality

cnet.com

47 pointsxooyoozoo36 comments

There is an odd contrast between this article and the announcement in January of broad support for VP9 from hardware manufacturers:

As Google announced today, however, virtually all major hardware vendors will soon support VP9 natively in their products and allow Google’s YouTube to stream HD content up to 4K directly to computers, TVs and mobile devices.

These new hardware partners include ARM, Broadcom, Intel, LG, Marvell, MediaTek, Nvidia, Panasonic, Philips, Qualcomm, RealTek, Samsung, Sigma, Sharp, Sony and Toshiba.[1]

I wonder if the VP9 situation changed for the worse since January, or if the article is simply misleading. It's hard to tell as the quotes in the article are mostly anectodal.

[1] http://techcrunch.com/2014/01/02/googles-vp9-video-codec-get...

Given a release announcement and an article citing multiple independent sources, I'd guess the article is more likely to give a balanced view of reality…

If the test of a technology/codec is its ability to transport pornography; I'd say this is being successfully adopted via webm.

http://blog.4chan.org/post/81896300203/webm-support-on-4chan

It's also replacing GIF in places and seems to nullify the claims that missing support in Safari or IE is a problem. My gut feeling is that Microsoft and Apple have competitive (destroy Google) or ulterior motives and financial gains in mind in terms of actively blocking WebM. This stinks of anti-competitive behavior in need of regulation. If Google had actually acted on their plans to push WebM and phase out H.264 it could have either destroyed YouTube (highly unlikely) or fixed the video codec situation.

You have it completely backwards there. It is Google that has the ulterior motive/financial gain in not adopting H.264/H.265. They are the only major player who has not adopted it. And if Google decided to force WebM in YouTube it would absolutely destroy it.

This whole weird misadventure Google has embarked on will be abandoned sometime soon. There simply is nothing to be gained from it.

Codec licensing costs are an impediment to innovation in the video space and another example of controlling the market and keeping out newcomers without deep pockets. If you had only two brands of paper that licensed the one paper+pen "technology" (H.26*) available and anyone with an alternative pen+paper combination that isn't out to make money only with licensing fees is kept out of the market - that's the situation we are in with video codecs. Regulatory bodies play a vital role but fail by sometimes overregulating and in this case ignoring abuse of power. The widespread myth spread by ISPs that want to invest once and milk the network as long as possible while maintaining it as little as possible is also the reason why we haven't managed to declare internet connectivity as just another utility like water and electricity. To think that those broadband companies got tax breaks and want tax breaks while searching for loopholes to prevent municipal fiber installations...

Both of those companies have been around long enough to remember the hell caused by there being a bunch of competing codecs in the 90s before the two main bodies that make video standards agreed to go the same direction. Google is the new kid that wants them to try something they have already watch fail again.

If you want one standard for everybody it better not exclude innovators without deep pockets and require licensing fees to use the standard everybody's supposed to use. The world doesn't just consist of TV stations, video production workstations and iPhones or Samsung TVs all licensing H.26*. Participators in creating a technical standard must be compensated for the their work but if it's a standard for everyday use by everyone what are the arguments for requiring licensing fees?

Having a license pool incentives continued research into video compression and provides a less risky environment for all participants (this a problem that Google bought their way out of).

Overall the licensing structure and costs are reasonable IMO except that software decoders that are given away for free shouldn't incur licensing costs.

Wow. Wait... so if someone does not support whatever Google wants, they are anti-competitive?

Not a single word about daala: too bad.

https://gigaom.com/2013/10/15/monty-montgomery-joins-mozilla...

was there any news of daala recently?

Good question: not that I know, but I don't think this should imply anything about the project.

I think HEVC, or H.265 is moving to much better terms in licensing. Instead of requiring license fees for Software decoder, They are collecting a small fees for Hardware decoder / encoder. Since every Mobile devices will be getting it and devices are going to ship units in billions in the life time of the codec. It is going to get back all the investment. Meanwhile a free ( in price ) software decoder can be included in Browsers / Software.

Correct me if I am wrong on the licensing issue. And BTW VP9 / 10 isn't patents free, Google is just paying for it and you get to use it for free.

And aside of patents issues, VP10 doesn't stand against HEVC in quality. VP9 quality never got close to H.264 AVC best encoder. And even VP10 will come close or exceed it, HEVC is here already. VPx ( The one after VP10, For some reason they dont call it VP11 ) will hopefully rival HEVC.

What metric is being used to compare VPxyz with H264 and HEVC? PSNR? SSIM? Double-blind tests? Encode/decode performance? Hardware complexity? Patent encumbrance?

There's a recent paper comparing subjective performance between HEVC and VP9.

http://www.scribd.com/doc/238049197/HEVC-H-265-VP9-AVC-subje...

The idea of producing new codecs every 18 months seems to fly in the face of the idea of getting broad hardware support.

Not if the new versions preserve compatibility. But it's true that the technology with the longer view, with fewer major changes, might prevail on that basis alone.

The broadcast media is absolutely H.264/5's home ground. Even if Google's codec play is wildly successful, this will be last place to fall.

Google has been fairly forthright about this e.g. WebM project has Web right there in the name, not TVM or BroadcastM or PlasticDiscM.

And as such, regular refreshes of the codec is a very Webby, a very Googly, and a very Open Source-y thing to do.

It seems odd that Google would expend effort to make web video patent-free while at the same time pushing for closed-source DRM in HTML5.

Patent-free video is good for the web, and makes it more likely to get broad support. So good for Google.

DRM in HTML5 means that you don't need Flash/Silverlight to play Netflix, etc. Which means that you can support video more easily. So good for Google.

Except that VP9 isn't patent-free. MPEG LA and other patent holders simply haven't bothered to flex their muscles because VP9 adoption is pretty much non-existant.

That's why I much prefer H.265. It is a defacto standard.

I'm not sure I understand what you mean. MPEG LA sue Google for a technology invented/bought(and patented) by Google? Is that it? I think I need more details to understand what you truly mean.

http://en.wikipedia.org/wiki/VP8#History

> In March 2013, MPEG LA announced that it had dropped its effort to form a VP8 patent pool after reaching an agreement with Google to license the patents that it alleges "may be essential" for VP8 implementation, and granted Google the right to sub-license these patents to any third-party user of VP8 or VP9.[26][27] This deal has cleared the way for possible MPEG standardisation as its royalty-free internet video codec, after Google submitted VP8 to the MPEG committee in January 2013.

I think you may be confusing de facto with de jure. And MPEGLA has been very noisy about VP8 and 9.

> DRM in HTML5 means that you don't need Flash/Silverlight to play Netflix, etc. Which means that you can support video more easily.

You still need a closed-source DRM module, as a replacement for Flash or Silverlight. It doesn't make it any easier in that respect. It does provide a standard API between such DRM modules, though.

But yes, this is good for Google, as it does own one such DRM module (Widevine). So Google can push its own DRM and does not need to rely on third parties like Flash or Silverlight.

Yes, you still need the closed module - but all it does is decoding, which means that it's much smaller than Flash/Silverlight.

I wish the video companies didn't insist on it, but if we need to have something to keep them happy, I'd rather it was a simple decoder than a whole plugin runtime.

You have to look at it in context. The alternative to HTML5 EME is not un-DRMed content but rather the entire commercial video industry mandating non-web technology. That leads to vendor lock-in, security problems and increases the barriers to entry for everyone involved in video:

* Cool device? Now you need to convince (read pay) Adobe or Microsoft to port Flash/Silverlight to it or develop a native app and make it non-horrible e.g. for Netflix users to find and use. * Create a new video codec? You have to add support to Flash/Silverlight before most people can use it * Want to put video online? If any of it's for sale, you have to build out a full Flash/Silverlight stack to support it.

That's expensive and as we've seen it's a huge security hazard and generally holds technology back – e.g. neither Flash nor Silverlight play back H.264 anywhere near as efficiently as the native OS despite having years to add decent hardware acceleration.

From the perspective of a web-focused company like Google, that's a lot of downside with no advantage. Even Microsoft and Adobe aren't interested in doing much with Flash and Silverlight and they're expensive to keep alive as niche media playback platforms. That's why we ended up with EME in the first place – it allows every single component except for the actual decryption to use the standard web stack.

If Firefox shipped Daala tomorrow, YouTube could start serving it next week rather than wait a year or two for it to go through the release cycle at Adobe/Microsoft.

If a video site needs to support both open and encumbered media (a given for all but a few markets) this allows them to keep every single part the same except for the encryption stage without a degraded or inconsistent user experience.

DRM won't go away overnight, so we're going to see sites selling both and making that process as easy as possible will hasten the time where we can see an actual market response to restrictions – both from consumers being less willing to pay full price for encumbered content and from sites who are tired of DRM licensing eating into their revenue. If that's as simple as unchecking the “Use EME” box, you'll see a lot more willingness to experiment that you will if it's “Change our video production and serving pipeline away from the expensive Flash Media Server setup we already paid for”.

> * Cool device? Now you need to convince (read pay) Adobe or Microsoft to port Flash/Silverlight to it or develop a native app and make it non-horrible e.g. for Netflix users to find and use.

This is still true with EME. EME is just an API, you still need the closed-source proprietary DRM module itself, the CDM. You would need to convince/pay one of the very short list of such modules to port it to your device, and you would need to do so with a module that the content creators support.

The same is true for the other things in that list. EME simply does not even try to solve those problems - it just provides a standard HTML5 API to what remains a closed-source proprietary DRM module. There are very few companies with such modules - Adobe, Microsoft, and Google are the prominent ones. Without partnering with at least one of those, you can't bring DRM'd content using EME to a new device.

The difference is that you're talking about something which is MUCH smaller: someone can port the CDM to a new platform in far less time than it'd take for a complex platform like Flash or Silverlight because all you're dealing with is the DRM, not things like networking, display, sound, hardware accelerated video decoding, OpenGL, etc. Both Flash and Silverlight are to a first approximation as complicated at the entire web stack and almost none of that functionality is needed for a simple video player.

Yes, it sucks that it's proprietary but since consumers don't show any sign of refusing to buy DRMed content it makes sense to restrict the footprint as much as possible rather than letting the requirement for DRM drive your entire platform.

Right now HEVC encoding is slow as molasses as is VP9. If Google improves libvpx encoding and pushes it into the same ballpark as libx264 there's a much higher chance of adoption. VP8 encoding is also slow and I don't know why Google can't manage to speed up libvpx with a team of experts vs the libx264 dev team.

I think it's because Google is trying to avoid patents, libx264 doesn't.

x264 doesn't use any more patents than other encoders. It's simply better because the volunteer/contracting development model is better for software quality than corporate closed-allocation.

You're freed from short term thinking and team headcounts, so everyone who works on it can be a world-class expert… if you can find them.

I'd say, it is more of a bandwidth problem not a compression problem, web video is not as widespread as it could have been because people don't have the bandwidth to stream it, not because google failed to compress 4k video.

Every couple of years we seem to have to re-learn the lessons from the VHS versus BetaMax wars.

I wonder what it's Weissman score is :)

Reply on news.ycombinator.com