search

AOMediaCodec / libavif

libavif - Library for encoding and decoding .avif files
Other
1.44k stars 187 forks source link

Bump libjpeg to 3.0.3 #2194

Closed vrabaud closed 3 weeks ago

vrabaud commented 1 month ago

The CI started failing like in https://github.com/AOMediaCodec/libavif/issues/2033

vrabaud commented 1 month ago

Hmmm, this is erratic. It failed on my own actions but not here. https://github.com/vrabaud/libavif/actions/runs/9384941793/job/25841880554 It fails when encoding with SVT and decoding with gav1. GitHub images are probably being updated, let's wait.

vrabaud commented 1 month ago

Let's wait for the deployment of windows latest 20240603 to be done, it will have VS code 17.10 everywhere. We'll clear the caches and see if it still happens.

vrabaud commented 4 weeks ago

The windows-latest is fully deployed. I repurposed that PR by upgrading another library to see if the CI still fails.

wantehchang commented 4 weeks ago

Vincent: We still got the "SEH exception with code 0xc0000005 thrown in the test body." error in windows-latest.

On the other hand, two pull requests of Vignesh's passed all tests yesterday: https://github.com/AOMediaCodec/libavif/pull/2191 https://github.com/AOMediaCodec/libavif/pull/2195

vrabaud commented 4 weeks ago

Right, the windows CI was not run, only the windows-installed, and it does not include SVT.

wantehchang commented 3 weeks ago

Vincent: I did some experiments in my pull request https://github.com/AOMediaCodec/libavif/pull/2199 last night. I did not track this down, but I have two findings.

  1. The tests in avifcodectest fail whenever libgav1 is used as the decoder:
[  FAILED  ] All/CodecTest.EncodeDecode/2, where GetParam() = (1, 3)
[  FAILED  ] All/CodecTest.EncodeDecode/5, where GetParam() = (4, 3)
[  FAILED  ] All/CodecTest.EncodeDecode/8, where GetParam() = (5, 3)

The value of AVIF_CODEC_CHOICE_LIBGAV1 is 3. You can also verify this by inspecting avifcodectest.cc.

  1. The "Build aom" step failed, yet the "Build libavif (ninja)" step still succeeded. See

https://github.com/AOMediaCodec/libavif/actions/runs/9415816061/job/25937592690?pr=2194

This does not make sense, because the linking of the executable programs should fail (aom.lib is missing). This may indicate we are still using a cache file. Could you look into this? Thanks.

vrabaud commented 3 weeks ago

The cache is working properly. For 2, it unfortunately makes sense: libaom is built from ext and it fails (the CI should stop here ...). Then, it is told CMake to have a local libaom: it does not find one in ext, it therefore builds its own in CMake (which now works). So, the problem is therefore from ligav1, it narrows it down.

wantehchang commented 3 weeks ago

Vincent: In https://github.com/AOMediaCodec/libavif/actions/runs/9415816061/job/25937592690?pr=2194 I see the caches for ext and build/_deps are NOT used. Only the cache for ~/.cargo is used. So I can't explain why "Build aom" failed yet "Build libavif (ninja)" still succeeded.

I will try to reproduce the test failure on my Windows laptop later today.

wantehchang commented 3 weeks ago

Vincent: Thank you for your reply. I see the following in https://github.com/AOMediaCodec/libavif/actions/runs/9415816061/job/25937592690?pr=2194:

-- libavif(AVIF_CODEC_AOM=LOCAL): compiled library not found at D:/a/libavif/libavif/ext/aom/build.libavif/aom.lib, using FetchContent
-- libavif(AVIF_CODEC_AOM=LOCAL): ext/aom found; using as FetchContent SOURCE_DIR
-- libavif(AVIF_CODEC_AOM=LOCAL): configuring aom

We probably should not use an existing ext/aom as the libaom source dir.

vrabaud commented 3 weeks ago

It seems there are two LLVMs installed (16 and 17), cf https://github.com/actions/runner-images/issues/10001 . Not sure why one is preferred in one case though.

wantehchang commented 3 weeks ago

Vincent: I finally found a bug that matches what we are seeing in avifcodectest in the windows-latest image: https://github.com/actions/runner-images/issues/10004

I am testing a workaround now.