Closed kalev closed 1 year ago
I think what might be happening here is that libheif was built with AOM and SVT decoder for av1 enabled, and the tests of libheif-rs are not prepared for this?
So it might be fixed by replacing the loop with an .any()
check or something similar.
What if I will fix this test in next "major" release of libheif-rs (v0.21)? Is it worth fixing the test in v0.20?
Thanks! Looks like it's indeed the case that libheif is built with both aom and svt enabled: https://src.fedoraproject.org/rpms/libheif/blob/rawhide/f/libheif.spec
For context, I'm interested in libheif-rs because it's a dependency for loupe. Loupe is a new image viewer that @sophie-h is developing and we are planning on shipping in Fedora 39.
This issue here isn't much of a problem for packaging libheif-rs for Fedora; I just noticed it in passing. No need to do a new 0.20 release just for that. There is another issue that I just filed that is a bit of a blocker though: https://github.com/Cykooz/libheif-rs/issues/15
I have released v0.21 with fixed get_encoder_for_format
test.
Thanks a lot! I can confirm that it now builds fine.
When running libheif-rs tests on Fedora, I get:
Any ideas what's going wrong here?