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.
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.
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.
> I'm not sure if I like Google's regular backwards-incompatible updates of their VPx codec family.
Interesting that you brought this up! I went to watch a video on YouTube for the first time in a while, and suddenly all of the VP9 video plays back out of sync with its audio track.
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?
Another interesting site is the Daala development team's https://arewecompressedyet.com which tracks Daala's in-development progress against other codecs.
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.