Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rav1d fails or incorrectly decodes AV1 sample videos #1370

Open
ahomescu opened this issue Jan 27, 2025 · 13 comments
Open

rav1d fails or incorrectly decodes AV1 sample videos #1370

ahomescu opened this issue Jan 27, 2025 · 13 comments
Assignees
Labels
bug Something isn't working help wanted Extra attention is needed safety/correctness

Comments

@ahomescu
Copy link
Collaborator

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.

@ahomescu ahomescu added bug Something isn't working help wanted Extra attention is needed safety/correctness labels Jan 27, 2025
@kkysen
Copy link
Collaborator

kkysen commented Jan 27, 2025

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

@ahomescu
Copy link
Collaborator Author

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
Copy link
Collaborator

kkysen commented Jan 27, 2025

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

Hmm, interesting.

@ahomescu
Copy link
Collaborator Author

Just found #1322 relevant to the cdylib discussion.

@ahomescu
Copy link
Collaborator Author

Image

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

@kkysen
Copy link
Collaborator

kkysen commented Jan 28, 2025

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
Copy link
Collaborator

fbossen commented Jan 28, 2025

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
Copy link
Collaborator

kkysen commented Jan 28, 2025

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
Copy link
Collaborator Author

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
Copy link
Collaborator

fbossen commented Jan 29, 2025

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.

@kkysen
Copy link
Collaborator

kkysen commented Jan 30, 2025

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.

Ahh, so that's why #1367 works but not the other branch? This is the cause of the incorrect output, but I assume not the segfault, right?

@fbossen
Copy link
Collaborator

fbossen commented Jan 30, 2025

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.

Ahh, so that's why #1367 works but not the other branch? This is the cause of the incorrect output, but I assume not the segfault, right?

Yes, this should take care only of the incorrect output

@fbossen
Copy link
Collaborator

fbossen commented Feb 12, 2025

I got the ffmpeg command using rav1d to work fine on Ubuntu 22.04 after building/installing dav1d 1.5.1 from scratch and building ffmpeg n7.1 from scratch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed safety/correctness
Projects
None yet
Development

No branches or pull requests

3 participants