FFmpeg Has A Native VP8 Decoder

Thanks to David Conrad and Ronald Bultje who committed their native VP8 video decoder to the FFmpeg codebase yesterday. At this point, it can decode 14/17 of the VP8 test vectors that Google released during the initial open sourcing event. Work is ongoing on those 3 non-passing samples (missing bilinear filter). Meanwhile, FFmpeg’s optimization-obsessive personalities are hard at work optimizing the native decoder. The current decoder is already profiled to be faster than Google/On2’s official libvpx.

Testing
So it falls to FATE to test this on the ridiculous diversity of platforms that FFmpeg supports. I staged individual test specs for each of the 17 test vectors: vp8-test-vector-001 … vp8-test-vector-017. After the samples have propagated through to the various FATE installations, I’ll activate the 14 test specs that are currently passing.

Initial Testing Methodology
Inspired by Ronald Bultje’s idea, I built the latest FFmpeg-SVN with libvpx enabled. Then I selected between the reference and native decoders as such:

$ for i in 001 002 003 004 005 006 007 008 009 \
 010 011 012 013 014 015 016 017
do
  echo vp80-00-comprehensive-${i}.ivf
  ffmpeg -vcodec libvpx -i \
    /path/to/vp8-test-vectors-r1/vp80-00-comprehensive-${i}.ivf \
    -f framemd5 - 2> /dev/null
done > refs.txt

$ for i in 001 002 003 004 005 006 007 008 009 \
 010 011 012 013 014 015 016 017
do
  echo vp80-00-comprehensive-${i}.ivf
  ffmpeg -vcodec vp8 -i \
    /path/to/vp8-test-vectors-r1/vp80-00-comprehensive-${i}.ivf \
    -f framemd5 - 2> /dev/null
done > native.txt

$ diff -u refs.txt native.txt

That reveals precisely which files differ.

6 thoughts on “FFmpeg Has A Native VP8 Decoder”

  1. Robert Swain

    David claimed it to be ~10% faster than libvpx for intra-only VP8 and 40-50% faster for normal VP8 with predicted frames. That was before review and before SIMD, so only with C code. Jason has indeed been hammering the SIMD quite a bit so I expect when that lands it will be hella-fast.

  2. Fabio

    I tried the decoding speed with:

    #!/bin/sh
    FILE=/webm-or-ivf-file/file.webm
    FFMPEG=/path-to-ffmpeg/ffmpeg
    for i in vp8 libvpx
    do
    echo “33[1;31m=== ${i} ===33[0m”
    time $FFMPEG -an -vcodec ${i} \
    -i $FILE \
    -f null – > /dev/null
    echo
    done

    and I found that the native decoder is about 2x slower than libvpx (tested on 360p and 720p random video from youtube and a 176p ivf file).

  3. anonymous

    Jason says that the optimizations he did to the ffvp8 decoder were ported to ffh264, thus making it even faster as well.

    Anyway, according to my tests, VP8 isn’t bad at all. It ranks second after H.264. Even though we still have a bad, unoptimized encoder (libvpx) it is still doing really nicely in spite of being optimized for PSNR. Wonder how much difference will be if Google start doing some psychovisual optimizations.

  5. Reimar

    Just for the record: The better performance of the native FFmpeg VP8 decoder is for pure C code.
    Which btw. means e.g. “for PowerPC”, at least the Debian libvpx obviously has no altivec optimization whatsoever.

Comments are closed.