Hi everybody,
Intrigued by the new ability to export AVIF, I’ve been playing around and building some data that I thought some others might be interested in. After my first export seemed to take forever, I decided to take a look at what options might be available for speeding up the encoding process (initially, I just wanted to see how much library choice mattered, and ended up going down this rabbit hole 
).
The hardware setup:
Dell inspirion laptop
Intel Core i5 4210U
RAM: 8GB
The software setup:
OS: Kubuntu 19.10
Kernel: 5.3.0-42generic
CPU governor: performance
Energy governor: performance
OpenCL: OFF/NO
darktable-cli 3.1.0+816~g396bf2aec-dirty
Libavif – v0.6.2-1-g56ffea3
AOM – v1.0.0-errata1-avif-404-g01c7a6602
RAV1E – p2020026-63-gde515e0
DAV1D – v0.6.0-12-g3f18519
Test file: 6032 X 4032 14-bit lossless compressed NEF from a Nikon D750
Method: I built two versions of libavif one with AOM and DAV1D, the other with RAV1E and DAV1D, swapping between them as necessary. Used “/usr/bin/time --format=‘Encode took %E’ darktable-cli test.nef output.xxx” for time and filesize testing. Modified speed variable in avif.c accordingly to see if there was any difference there.
Test 1: 8-bit Lossless encoding time and filesize (AOM vs RAV1E)
AVIF_SPEED_FASTEST seems to have huge implications on encoding time. Currently, AOM is consistently faster at the coded default of SLOWEST+1 and FASTEST (AOM @ FAST was overall winner), yet gets crushed at DEFAULT; making me think that AOM’s DEFAULT is set to pure SLOWEST while RAV1E uses a more middle value (I think the scale is 1-10 if I remember). Filesize differentiation is a little odd with RAV1E, I thought using faster speeds should produce larger files, as was the case with AOM.
Test 2: 8-bit Lossy encoding time and filesize (AOM vs RAV1E) default compresson (91%)
Using lossy AOM is quicker at the coded default, but RAV1E is quicker set to DEFAULT and FASTEST (RAV1E @ FAST was overall winner). Weird filesize anomaly with AOM set to FASTEST, it was repeatable and doesn’t show errors importing back into dt however.
Test 3: Lossless 8,10,12-bit filesize difference RAV1E
This was kind of interesting in that I would expect the largest file to be from the FASTEST setting but the opposite was true. I couldn’t get AOM to complete an export at 10 or 12 bit (it would get killed with a signal 9, unless I cropped the test file smaller), I think this was due to it’s brute force use of resources. It seems like AOM will use all available memory even filling swap when trying 10 or 12-bit. As a result, encoding with AOM may make your machine VERY unresponsive until the encode finishes. RAV1E seems to work much more nicely, behaving much like the other export formats:
Test 4: Comparison vs some common formats
Narrow margins vs scale of graph makes it a bit hard to judge so here’s the actual results:
The overall speed winner was jpeg @ 19.9s, overall filesize went to Lossy RAV1E @ 6.2MB. Interestingly, lossless avif seems to be smaller than the lossless png and tiff formats.
Hopefully this data can help anyone else interested in checking out this new file format.
