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?
Google's web video ambitions bump into hard reality
31–37 of 37 posts
Re: Google's web video ambitions bump into hard reality
#32Right 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.
Re: Google's web video ambitions bump into hard reality
#33The 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.
Re: Google's web video ambitions bump into hard reality
#34Re: Google's web video ambitions bump into hard reality
#35I 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…
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...
Re: Google's web video ambitions bump into hard reality
#36If 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 i…
Wow. Wait... so if someone does not support whatever Google wants, they are anti-competitive?
Re: Google's web video ambitions bump into hard reality
#37Earlier quoted context omitted.
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…
> * 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…
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.