
VP9 is now available in WebRTC - genediazjr
https://developers.google.com/web/updates/2016/01/vp9-webrtc
======
lxgr
As a user of open source software, I really appreciate Google's open source
codec efforts and their continuous improvements of the VP codec family.

However, as an end user, I'm not sure if I like Google's regular backwards-
incompatible updates of their VPx codec family. It usually takes a while for
SoC/GPU/CPU manufacturers to update their designs to support the new version,
and for the case of desktop or laptop computers, it takes (on average) more
than three years for them to finally show up in my devices.

During that time, for example Chrome will fall back to software decoding for
Youtube videos, which causes increased power consumption and lower battery
life. As long as it doesn't factor available hardware acceleration into codec
selection, I will continue to highly recommend extensions like h264ify to all
my video-watching friends and family.

I can see that real-world market share is an important factor in convincing
chip designers to implement a given codec, but I am not willing to pay for
that with my mobile battery life.

~~~
ZeroGravitas
I believe in the context of WebRTC and video chat generally this is less
relevant, as many hardware implementations are limited to the "play a video"
use case, and while in theory they may have enough silicon to decode 4 small
videos of other participants, while encoding another of the user, all at the
same time they don't often in practice support that use case.

When it was discussed in one of the WebRTC meetings the only video chat
application that anyone could name that used hardware acceleration was Apple's
Facetime, if I recall correctly.

~~~
quicklyfrozen
Considering that encoding is more expensive then decoding, then hardware
support for that outgoing stream should still be helpful even if the inbound
streams are decoded in SW.

The main issue I've run into trying to handle say 4 streams on a mobile device
is that it will work fine for a minute or so until the device needs to
throttle back due to heat.

~~~
ZeroGravitas
Yes, in theory it's really helpful. It's the reality that's the problem:

[http://www.nojitter.com/post/240169541/reports-on-
availabili...](http://www.nojitter.com/post/240169541/reports-on-availability-
of-h264-hardware-encoding-greatly-exaggerated)

------
fsiefken
I would be interested in a codec performance video quality / bandwidth
benchmark. I remember the comparisons between realvideo open source helix
encoding tools, xvid and vp6 a decade ago, nowadays x265, x264, vp9... how do
the old and new compare for example at low bandwidth of 300 Kbps at 640x400 at
12 fps?

~~~
clouddrover
See Moscow State University's recent codec comparison which uses various
metrics to measure codec performance:
[http://compression.ru/video/codec_comparison/hevc_2015/](http://compression.ru/video/codec_comparison/hevc_2015/)

Another interesting site is the Daala development team's
[https://arewecompressedyet.com](https://arewecompressedyet.com) which tracks
Daala's in-development progress against other codecs.

