[ISSUE] libavif: defective packaging prevents avifenc from being useful

[ISSUE] libavif: defective packaging prevents avifenc from being useful

[IcedQuinn]

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

New issue by IcedQuinn on void-packages repository

https://github.com/void-linux/void-packages/issues/42272

Description:
`libavif` is built in such a way that its companion program `avifenc` is included within system-wide PATH but is unable to encode. No encoders are bundled with it. It only includes a decoder (`dav1d`.)

You can verify the availability of encoders and decoders as in:
```
icedquinn@astaraline ~/Pictures> avifenc -h | grep Version
Version: 0.11.1 (dav1d [dec]:1.0.0)
```

`avifenc` is able to be built with other encoding libraries such as `libaom` (which is the absolute slowest but preserves the most image detail per byte.) A custom build depending on `libaom` shows a different result:
```
icedquinn@astaraline ~/Pictures> ~/code/external/libavif/build/avifenc -h | grep Version
Version: 0.11.1 (aom [enc/dec]:v3.5.0)
```

Now this part is tricky because the dependencies are *build-time optional* but not auto detected at run time. As I recall it supports SVT-AV1 (the fastest), `rav1e`, and `libaom`, with an additional subdependency that if `libaom` is built with JPEG-XL it will allow use of the butteraugli metric which further preserves image fidelity.

In ideal cases:
- `libaom` would include its optional JPEG-XL dependency for access to the butteraugli metric. Otherwise you are stuck with SSIM which is good and usable but is still somewhat worse. (SSIM is only concerned about preserving edges while butteraugli is a full psychovisual metric.)
- `libavif` would also have its optional `rav1e`, SVT-AV1, and `libaom` dependencies--or at least `libaom` and one other to allow for fast and slow options.

FFMPEG already depends on most/all of this so they will already be in the repository for that. This would likely just be some tweaks to build flags and dependencies. However those are foundational libraries so there is *very likely* to be a high amount of resistance to making these simple tweaks.

Currently you need to do a custom build of some of these libraries to actually encode AVIF. However, binaries are provided that are intended to do this but are misconfigured so as to be present but worthless.

Re: libavif: defective packaging prevents avifenc from being useful

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/42272#issuecomment-1445062633

Comment:
Thanks, feel free to test https://github.com/void-linux/void-packages/pull/42438
Let me know if you run any issues.

Re: libavif: defective packaging prevents avifenc from being useful

[github-actions]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

New comment by github-actions[bot] on void-packages repository

https://github.com/void-linux/void-packages/issues/42272#issuecomment-1565146665

Comment:
Issues become stale 90 days after last activity and are closed 14 days after that.  If this issue is still relevant bump it or assign it.

Re: [ISSUE] [CLOSED] libavif: defective packaging prevents avifenc from being useful

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]

Closed issue by IcedQuinn on void-packages repository

https://github.com/void-linux/void-packages/issues/42272

Description:
`libavif` is built in such a way that its companion program `avifenc` is included within system-wide PATH but is unable to encode. No encoders are bundled with it. It only includes a decoder (`dav1d`.)

You can verify the availability of encoders and decoders as in:
```
icedquinn@astaraline ~/Pictures> avifenc -h | grep Version
Version: 0.11.1 (dav1d [dec]:1.0.0)
```

`avifenc` is able to be built with other encoding libraries such as `libaom` (which is the absolute slowest but preserves the most image detail per byte.) A custom build depending on `libaom` shows a different result:
```
icedquinn@astaraline ~/Pictures> ~/code/external/libavif/build/avifenc -h | grep Version
Version: 0.11.1 (aom [enc/dec]:v3.5.0)
```

Now this part is tricky because the dependencies are *build-time optional* but not auto detected at run time. As I recall it supports SVT-AV1 (the fastest), `rav1e`, and `libaom`, with an additional subdependency that if `libaom` is built with JPEG-XL it will allow use of the butteraugli metric which further preserves image fidelity.

In ideal cases:
- `libaom` would include its optional JPEG-XL dependency for access to the butteraugli metric. Otherwise you are stuck with SSIM which is good and usable but is still somewhat worse. (SSIM is only concerned about preserving edges while butteraugli is a full psychovisual metric.)
- `libavif` would also have its optional `rav1e`, SVT-AV1, and `libaom` dependencies--or at least `libaom` and one other to allow for fast and slow options.

FFMPEG already depends on most/all of this so they will already be in the repository for that. This would likely just be some tweaks to build flags and dependencies. However those are foundational libraries so there is *very likely* to be a high amount of resistance to making these simple tweaks.

Currently you need to do a custom build of some of these libraries to actually encode AVIF. However, binaries are provided that are intended to do this but are misconfigured so as to be present but worthless.