rav1d fails or incorrectly decodes AV1 sample videos

[ahomescu]

Depending on the build profile, rav1d will incorrectly decode or just fail on some online videos, e.g., https://caraya.github.io/av1-video-demo/footloose.mp4. The sample at https://bitmovin.com/demos/av1/ also fails in Firefox, but I'm not sure how to download it to a file.

To reproduce, pull my enable_cdylib branch to create a librav1d.so shared library then run:

$ cargo build --release
$ LD_PRELOAD=./target/release/librav1d.so ffmpeg -i footloose.mp4 -vcodec vp9 footloose.vp9.mp4

In release or checked-release builds this fails with

[vist#0:0/av1 @ 0x57eb9e252dc0] [dec:libdav1d @ 0x57eb9e2b4b00] Error submitting packet to decoder: Invalid data found when processing input
    Last message repeated 4 times
[vist#0:0/av1 @ 0x57eb9e252dc0] [dec:libdav1d @ 0x57eb9e2b4b00] A decoder returned an unexpected error code. This is a bug, please report it.
[vist#0:0/av1 @ 0x57eb9e252dc0] [dec:libdav1d @ 0x57eb9e2b4b00] Error processing packet in decoder: Internal bug, should not have happened
[vist#0:0/av1 @ 0x57eb9e252dc0] [dec:libdav1d @ 0x57eb9e2b4b00] Task finished with error code: -558323010 (Internal bug, should not have happened)
[vist#0:0/av1 @ 0x57eb9e252dc0] [dec:libdav1d @ 0x57eb9e2b4b00] Terminating thread with return code -558323010 (Internal bug, should not have happened)

while in debug builds it produces a full but garbled output video.

[kkysen]

Do you know how to reduce this to a CLI command?

[ahomescu]

Do you know how to reduce this to a CLI command?

Not yet, because converting footloose.mp4 to another format then passing it to the rav1d CLI doesn't reproduce the issue.

[kkysen]

Not yet, because converting footloose.mp4 to another format then passing it to the rav1d CLI doesn't reproduce the issue.

Hmm, interesting.

[ahomescu]

Just found #1322 relevant to the cdylib discussion.

[ahomescu]

This is what the output looks like with my debug build.

[kkysen]

For me, it always segfaults during logging. But there's invalid reads before that in the alloc_picture_callback, so somewhere in ffmpeg. Which is probably why it doesn't break when run through our CLI.

[fbossen]

For me, it always segfaults during logging. But there's invalid reads before that in the alloc_picture_callback, so somewhere in ffmpeg. Which is probably why it doesn't break when run through our CLI.

I had a segfault on Ubuntu 22.04 but not on 24.04 (which has a more recent version of ffmpeg)

[kkysen]

It might be that we changed something in the API slightly and it doesn't work with some versions? I did change things slightly to make it work in Rust more safely, but I checked the uses, but I probably only checked the most recent version. Maybe that's it?

[ahomescu]

For me, it always segfaults during logging. But there's invalid reads before that in the alloc_picture_callback, so somewhere in ffmpeg. Which is probably why it doesn't break when run through our CLI.

Yeah that might be a clue, the CLI does not seem to use either a custom allocator or logger.

[fbossen]

The garbled video is caused by an incorrect table. src/tables.c contains an #if ARCH_X86 statement that impacts the construction of some tables. ARCH_X86 therefore needs to be defined when compiling src/tables.c for x86.