The FFmpeg team has completed the initial implementation of their new VP8 decoder and early benchmarks are showing it up to 62% faster than Google’s own VP8 decoder: libvpx.
A few weeks ago we covered the announcement that the FFmpeg video-codec team had decided to build their own VP8 decoder and did an initial implementation in just 1400 lines of C-code.
The FFmpeg team is responsible for some of the highest-quality and highest-performing open-source video codecs in use today in everything from Chrome’s browser to set-top boxes and mobile devices. In-short, they know what they are doing when it comes to codec development.
Last year, when Google bought On2 Technologies, the creators of the VP8 codec, they did it with the intent of open-sourcing the technology as a replacement for the patent-encumbered H.264 codec that is used by most online video hosts and video-devices (cameras) in general.
Google created the WebM Media Project to host the new technology as an open video platform for the web of tomorrow. After assessing the initial code drop from the original VP8 codec, the FFmpeg team decided they could do their own VP8 decoder in a much more compact way with battle-tested code that had already been refined and tightened for years from their own H.264 implementation.
As it turns out, the techniques used in H.264 and VP8 for video encoding/decoding are very similar, which allowed the FFmpeg team to call on a lot of their existing, high-performance code-base to build the foundation for their new VP8 codec: ffvp8.
The FFmpeg team rolled in all the “interesting” optimizations from Google’s source tree in addition to rolling in their own. An example of some of their optimizations is described in the announcement:
A simple example in the case of x86 is abs(a-b), where a and b are 8-bit unsigned integers. The result of “a-b” requires a 9-bit signed integer (it can be anywhere from -255 to 255), so it can’t fit in 8-bit. But this is quite possible to do without unpacking: (satsub(a,b) | satsub(b,a)), where “satsub” performs a saturating subtract on the two values. If the value is positive, it yields the result; if the value is negative, it yields zero. Oring the two together yields the desired result. This requires 4 ops on x86; unpacking would probably require at least 10, including the unpack and pack steps.
The jury is still out on whether Google will ditch their own libvpx decoder implementation and ship with FFmpeg’s ffvp8 implementation or if Google will continue to maintain their own decoder.
“Dark Shikari” points out that Google has already begun referring people to the FFmpeg team’s VP8 decoder as a documentation source for the VP8 codec and already ships FFmpeg’s other decoders with Chrome already. So it wouldn’t be an unheard of step for Google to combine efforts with the FFmpeg team on the VP8 front at some point.
Our only concern is that we get a high-performance alternative to the damnable H.264 codec.
