should we rename the option to av1DecodingSupport (or add libaom as well)?

Imo this is mostly a closure size issue, it looks like we can amend the libaom derivation the reduce the closure size enough that adding libaom is a no-brainer.
If that's really the case we should just add libaom too. I'll investigate!

is AV1 decoding relevant enough to enable it by default? The file contains the following note:

Yes, my take at least on the ffmpeg packages is that ffmpeg_4 should support playback of pretty much anything not too esoteric. The fact that youtube now serves av1 is reason enough alone to enable it by default.

@adisbladis thanks for the feedback :)

Imo this is mostly a closure size issue, it looks like we can amend the libaom derivation the reduce the closure size enough that adding libaom is a no-brainer.
If that's really the case we should just add libaom too. I'll investigate!

Any updates?

Yes, my take at least on the ffmpeg packages is that ffmpeg_4 should support playback of pretty much anything not too esoteric. The fact that youtube now serves av1 is reason enough alone to enable it by default.

Sounds good :)

And the adoption of AV1 will hopefully progress "fast" (for a codec): https://en.wikipedia.org/wiki/AV1#Adoption

I'm just a bit concerned about the performance without proper hardware acceleration, but that'll hopefully change soon as well :)

If that's really the case we should just add libaom too. I'll investigate!

@adisbladis I just gave libaom a quick test with a few AV1 videos (Netflix/YouTube) and wasn't able to play any of them. At least the decoder currently doesn't seem to perform well at all (I didn't test the encoder though). See #54990 (comment) and #54990 (comment).

The stable version of libaom is unusable grade outdated. On my personal system I build it from a git snapshot (rev 32185d165e0a238a32b20c5bbd59e360bd46d067 currently. Could probably go a bit newer). At least for my mpv closure.

See: https://github.com/xantoz/nixconfig/blob/80d35cbac842e1a47ffdf72b1cca648655a6629c/overlays/local/pkgs/default.nix#L65

Unfortunately libaom API seems to be quite unstable, and bumping it globally might break other users of libaom (that expect 1.0.0) than ffpmeg.

My proposal would be that we either build ffmpeg_4 with a known good git revision of libaom, or simply don't support libaom in ffmpeg_4 for the time being (so no encoding, unfortunately), and focus on libdav1d which is both more stable API-wise and faster at decoding. The latter has the benefit of making dav1d the default decoder for AV1 in e.g. mpv (last time I checked it would default to the slower libaom unless you run mpv --vd=libdav1d)

Edit: Misc clarifications. Change the link into my nixconfig, as it was pointing to a revision of it with not quite working libaom

The stable version of libaom is unusable grade outdated.

Agreed, I already checked what other distributions are doing but it seems like most distributions are also packaging the stable releases: https://repology.org/project/aom/versions
IIRC there where ~2.5k commits between v1.0.0-errata1 and master (AFAIK also many performance improvements).

Unfortunately libaom API seems to be quite unstable, and bumping it globally might break other users of libaom (that expect 1.0.0) than ffpmeg.

Most packages would hopefully only use it indirectly via ffmpeg which should be fine if ffmpeg still builds (AFAIK).

Currently, the only other package with a direct dependency on libaom is apparently gst-plugins-bad:

michael@jarvis> git grep libaom
pkgs/development/libraries/ffmpeg-full/default.nix:, libaom ? null # AV1 encoder
pkgs/development/libraries/ffmpeg-full/default.nix:  patches = [ ./prefer-libdav1d-over-libaom.patch ];
pkgs/development/libraries/ffmpeg-full/default.nix:    (enableFeature (libaom != null) "libaom")
pkgs/development/libraries/ffmpeg-full/default.nix:    libjack2 ladspaH lame libaom libass libbluray libbs2b libcaca libdc1394 libmodplug libmysofa
pkgs/development/libraries/ffmpeg-full/prefer-libdav1d-over-libaom.patch: extern AVCodec ff_libaom_av1_decoder;
pkgs/development/libraries/ffmpeg-full/prefer-libdav1d-over-libaom.patch: extern AVCodec ff_libaom_av1_encoder;
pkgs/development/libraries/gstreamer/bad/default.nix:, libaom
pkgs/development/libraries/gstreamer/bad/default.nix:    libaom
pkgs/development/libraries/libaom/default.nix:  name = "libaom-${version}";
pkgs/top-level/all-packages.nix:  libaom = callPackage ../development/libraries/libaom { };

My proposal would be that we either build ffmpeg_4 with a known good git revision of libaom, or simply don't support libaom in ffmpeg_4 for the time being (so no encoding, unfortunately), and focus on libdav1d which is both more stable API-wise and faster at decoding.

I'll update this PR to focus on AV1 decoding via dav1d for now, but I have no objections if anyone else wants to look into adding libaom as well.

The latter has the benefit of making dav1d the default decoder for AV1 in e.g. mpv (last time I checked it would default to the slower libaom unless you run mpv --vd=libdav1d)

Yeah, that's a bit annoying - would be great if dav1d would be the upstream default. I've added a small patch to ffmpeg-full to prefer dav1d (which we could use here as well).