Samstag, 29. April 2017

FFV1 - some compression results

In a pilot we got some retrodigitized films and videos in Matroska/FFV1 format. In the following table I summarized the results:

description8mm, positive, b/w8mm, positiv, b/w16mm, positive, b/w35mm, combined, color35mm, combined, color
bits per pixel4848484848
duration in s121211,4592,52,5
original size658368000065836800005136682844,1651019776004388290560
compressed size38619438803790690517368077971939084753443576745774
compression ratio1,7041,7361,3951,3051,226
with audionnnyn

description35mm, combined, colorvhs, colorbetacam, colorbetacam, colorDigi-beta, color
bits per pixel4820202020
duration in s1088,042280280280280
original size2053610510745,67257600000725760000072576000007257600000
compressed size15754151756113565437155383850093434493722804451325952
compression ratio1,3032,0351,8902,1041,630
with audionyyyy

All files are encoded with FFV1v3 with slices, slice-crc, GOP=1. If audio exists, it is (lin. PCM 48kHz, 16bit) included in compression-size, but not in original size, because original size is calculated by width*height*pits_per_pixel*frames and compression-size is equivalent to filesize. The count of frames is calculated with the duration value of the MKV-files. The files 1 to 5, and 7-10 are first parts of the movies (each 4GB splits).

Hint: Once the project is completed, rights must be clarified. If possible, I will publish the sources.


The files 1-3 are all originally b/w. It seems to be that the codec does not decorrelate the color channels. Also the material 1-6 is retrodigitized from film and are noisy. The file 1 is very special. In decoding the FFV1 produces a very high load on the CPU (eight cores at 100%). The most decoding time is spent in method get_rac(). The original film has the highest noise level in contrast to the other files.

I think the compression-ratio difference between video- and film files comes from the different pixel format. A ratio between 1,5 - 2 was expected, but 1,3 is a surprise.