| Summary: | kimageformats-write-avif fails with 5.92.0 | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kimageformats | Reporter: | Heiko Becker <heiko.becker> |
| Component: | general | Assignee: | Alex Merry <alex.merry> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aacid, dnovomesky, kdelibs-bugs-null |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | test output | ||
|
Description
Heiko Becker
2022-03-07 21:30:06 UTC
Created attachment 147353 [details]
test output
Daniel any idea of what may be wrong? I have the same avif version and it seems to work fine for me :/ It would be good to know how libavif was configured. Libavif can use different encoders: libaom, rav1e, svt-av1. avifenc or avifdec utilities can print such information about libavif encoders and their versions. Version: 0.9.3 (dav1d [dec]:0.9.2, rav1e [enc]:0.5.1 (0.5.1)) libyuv : unavailable So it happens with rav1e encoder. Perhaps the reason is that rav1e doesn't have lossless mode? As the following issue indicate: https://github.com/xiph/rav1e/issues/151 (In reply to dnovomesky from comment #5) > So it happens with rav1e encoder. > > Perhaps the reason is that rav1e doesn't have lossless mode? As the > following issue indicate: > > https://github.com/xiph/rav1e/issues/151 Possibly. Can't test with SVT-AV1 because libavif fails to build with that, but with aom the test passes fine. I'd say then we should close this bug, it is actually a good way to find if libavif is "compiled with the wrongly expected backend". Sounds fair? (In reply to Albert Astals Cid from comment #7) > I'd say then we should close this bug, it is actually a good way to find if > libavif is "compiled with the wrongly expected backend". I may be a bit ignorant here, but how am I supposed to know the wrongly expected encoders? libavif enables none by default (it seems to prefer aom at runtime if multiple encoders are present though). Btw. after patching libavif to build with recent SVT-AV1, it shows the same problem (and it doesn't support lossless too: https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1636) > Sounds fair? How if I come up with a patch instead, that includes a configure check, that checks if aom is available as encoder and if it isn't the write test is skipped (with a message/warning, or maybe even only the two files)? What if we just print a message (about known issue with other AV1 encoders) when avif write test fails? I don't think skipping the test is good, the situation you're in is bad, you have a plugin that when reading the file and saving it again makes changes to the file itself, and that's "bad", so having the test just be skipped or passed is suboptimal, having it fail is a way of saying "you should contact to whoever gave you your libavif and ask them to 'fix it' " Daniel: If we can detect somehow that people are using a "wrongly configured" libavif and give that as error instead of the current failure, sure that's much better It is possible to detect encoders via libavif C API. Do you want to detect it in the write test or in the plug-in? I think that would be good, Heiko does that satisfy you? (In reply to Albert Astals Cid from comment #12) > I think that would be good, Heiko does that satisfy you? Not really sure which part of the "or" question above is meant, but I'm fine with either. The plug-in will print (example): You are using rav1e encoder. It is recommended to enable libAOM encoder in libavif for better near-lossless compression. It will print only when quality==100 is requested, which is the situation used on the write test. For quality below 100, there is no warning because other encoders are good with lossy compression. https://invent.kde.org/frameworks/kimageformats/-/merge_requests/53 Can we close this now that 53 is merged and we warn users that their setup is "wrong"? Yes, thanks for the patch. |