Experiment: consider switching from aom to dav1d+rav1e/svt-av1

[lovell]

The dav1d decoder provides a meson build script and is straightforward to cross-compile.

https://github.com/lovell/sharp-libvips/tree/dav1d

The rav1e encoder does not provide build tooling and relies on cargo cinstall, which is not that simple to get working with cross-compilation. It causes rust symbol conflicts as we also statically-link the rust-based librsvg, so requires the slightly dangerous -Wl,--allow-multiple-definition linker flag.

https://github.com/lovell/sharp-libvips/tree/rav1e

Could consider the C-based svt-av1 as the encoder, perhaps the svt-av1-psy fork that prefers SSIM over PSNR - see https://github.com/lovell/sharp/issues/4276

Also need to determine by how much the shared library binary file size would increase, if any, with separate decoder/encoder.

[grantbeattie]

Is there any performance difference between aom and dav1d+rav1e?

[lovell]

@grantbeattie The latter are sold on performance and the former is the reference implementation, which would historically suggest that there will be, however these libraries are all under heavy development so this is probably one of those "it depends" situations.

[adityapatadia]

I would like to comment that latest rav1e has some issue: https://github.com/xiph/rav1e/issues/2662

Due to this, we had to revert to 0.3.4 version and eventually to libaom.

[kleisauke]

rav1e v0.5.0 was just released, which contains a fix for the issue mentioned above. The slightly dangerous -Wl,--allow-multiple-definition linker flag is still needed as https://github.com/rust-lang/rust/issues/44322 isn't fixed (yet).

As for the Windows builds, the dav1d-rav1e branch integrates this. Unfortunally, this requires a patched cargo-c that allows the use of the -Zbuild-std feature flag and provides support for the ARM/ARM64 llvm-mingw dlltool targets.

[faradaytrs]

Any progress on this?

[kleisauke]

In addition to build difficulties, https://github.com/strukturag/libheif/issues/554 (SEGV when encoding AVIF images with transparency) can also be a blocking issue. Given all this, my feeling is that it would be easier to only switch the decoder to dav1d and still use libaom for encoding. Of course, this change must be done in OSS-Fuzz first.

FWIW, librsvg is also considering using cargo-c (https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/657), so it's likely that we'll have to include that build dependency anyway.

[lovell]

libaom has made a number of performance improvements during the last year e.g. encoding is ~2x faster, and I've not seen any recent comparative benchmarks against dav1d or rav1e.

Adding dav1d for decoding with libaom compiled for encode-only increases the resultant binary size by ~6%.

We will revisit this, perhaps later in the year.

[adityapatadia]

Libaom still seems slow on decoding front. Can you let me know switches to disable encoding and how to build dav1d? May be we can give it a try for decoding.

[Sandy-Garrido]

Do we know of any current workarounds? I'm currently running into issues beyond 10bit.

heif-info -d image.avif | grep bit
| | | high_bitdepth: 1
| | | twelve_bit: 1
| | | bits_per_channel: 12,12,12