Bump libjpeg to 3.0.3

[vrabaud]

The CI started failing like in
#2033

[vrabaud]

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.

[wantehchang]

The SEH exception code is different: 0xc0000005 vs. 0xc000001d in #2033. So we should not assume this is the same Visual Studio 2022 bug.

I haven't found a webpage that tabulates the SEH exception codes, but my web searches shows that 0xc0000005 is access violation and 0xc000001d is illegal instruction.

[vrabaud]

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]

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

[wantehchang]

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:
#2191
#2195

[vrabaud]

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

[wantehchang]

Vincent: I did some experiments in my pull request #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.

2. 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]

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]

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]

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]

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

[wantehchang]

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

I am testing a workaround now.