Merged
Conversation
Member
|
x265 and cmake patches should be in a separate PR since it benefits all builds. |
threexc
force-pushed
the
tgamblin/riscv64
branch
from
a879796 to
192fdf6
Compare
Contributor
Author
|
Looks like the musllinux build failed on a bad hash for the x265 tarball, which also happened to me once when I was working on the cmake/x265 PR. A retrigger should be enough... |
Disable cuda and amf for this mode (like arm64) since they don't seem to support riscv64 yet. Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
threexc
force-pushed
the
tgamblin/riscv64
branch
from
192fdf6 to
122b14d
Compare
Contributor
Author
|
It's just the riscv64 musllinux build that is failing. Let me see if I can figure that out. |
The real issue with musl builds seems to be:
| src/libavutil/riscv/cpu.c:43:24: error: use of undeclared identifier '__NR_riscv_hwprobe'; did you mean '__riscv_hwprobe'?
| 43 | return syscall(__NR_riscv_hwprobe, pairs, pair_count, cpu_count, cpus,
| | ^~~~~~~~~~~~~~~~~~
| | __riscv_hwprobe
| src/libavutil/riscv/cpu.c:39:12: note: '__riscv_hwprobe' declared here
but in the musllinux image, that's defined in unistd_32.h and/or
unistd_64.h:
|tgamblin@megalith ~/workspace/git/ffmpeg (master)$ docker run --rm --platform linux/riscv64 quay.io/pypa/musllinux_1_2_riscv64:2026.03.01-1 sh -c "grep -r 'riscv_hwprobe' /usr/include/"
|/usr/include/asm/hwprobe.h:struct riscv_hwprobe {
|/usr/include/asm/unistd_32.h:#define __NR_riscv_hwprobe 258
|/usr/include/asm/unistd_64.h:#define __NR_riscv_hwprobe 258
Tweak the existing ffmpeg.patch file to also include asm/unistd.h in
libavutil/riscv/cpu.c.
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Contributor
Author
|
@WyattBlue what do you think? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This makes the changes necessary to support riscv64 builds in pyav-ffmpeg. The work here is being done with the goal of supporting video_reader-rs using pyav-ffmpeg in its CI, which in turn is of interest to the RISE Project.
Note that there's a patch labeled
revertmewhich reduces the test matrix down to just riscv64 for testing purposes.I started by testing this on my fork: threexc#1
What I found there is that the manylinux build succeeds once cuda and amf are also disabled for riscv64, but musllinux is a different story. I looked to see what version of musl the musllinux_1_2 image includes:
Seems that the missing header (stdbit.h) is a C23 addition
I guess we'd need to wait for musl to support it, and then for a new musllinux_1_2 image to be built?
Alternatively, it looks like there's a compatibility layer for it in ffmpeg, which we could try to use.