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
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
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.
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
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