Lair Of The Multimedia Guru

2014-01-28

FFmpegs Huffyuv

In the last few weeks FFmpegs huffyuv codec has grown the ability to encode and decode a much broader list of pixel formats. From planar rgb variants 4:4:4 YUV to 4:1:0 YUV and bit depths up to 16bit and alpha support.
One might ask why anyone cares about all this, the awnser is simple

1 thread YUV420 10bit, matrixbench
FFv1 Huffyuv
encode fps 63fps 281fps
decode fps 82fps 418fps
filesize 478mb 765mb

Encoding parameters used:
-an -threads 1 -pix_fmt yuv420p10le -strict -2 -vcodec ffvhuff -context 1
-an -threads 1 -pix_fmt yuv420p10le -strict -2 -vcodec ffv1

6 threads YUV420 10bit, matrixbench
FFv1 Huffyuv
encode fps 269fps 1173fps
decode fps 386fps 2675fps
filesize 480mb 771mb

Encoding parameters used:
-threads 6 -an -pix_fmt yuv420p10le -strict -2 -vcodec ffvhuff -pass 2 test.nut
-threads 6 -an -pix_fmt yuv420p10le -strict -2 -vcodec ffv1 -level 3 -slices 6 test1.nut

As can be seen above huffyuv while it doesnt even get close to ffv1 in terms of compression even though i used per frame huffman tables and 2pass mode in the 2 tests, its simply much faster.

Filed under: Entropy Coding,FFmpeg,VideoCoding — Michael @ 02:27

2 Comments »

  1. great! it may be useful for proxy editing.

    btw, Blender users need floating-point rgba(+z-depth+…) for many places in Linear Workflow.
    if we can convert openexr sequence to lossless video format, it would be very meaningful.

    Comment by n — 2014-01-28 @ 10:52

  2. if people know how much faster huffyuv is, they’ll never use ffv1! :P

    great work to all involved. wasnt huffyuv decoding actually slower than huffyuv encoding a few years ago? i had no idea that had changed.

    Comment by compn — 2014-04-25 @ 13:58

RSS feed for comments on this post.

Leave a comment

Powered by WordPress