[Enhancement] Support for CUDA

[ToshY]

I was trying to run FFmpeg and passing --gpus all flag to the docker container, just to realise that the image does not support it yet (which I later read in the "todos" section in the README).

Any chance to compile FFmpeg with CUDA?

https://docs.nvidia.com/video-technologies/video-codec-sdk/12.0/ffmpeg-with-nvidia-gpu/index.html#compiling-for-linux

---

If you do not have time to do it yourself, I can try to take a shot at it (but it might take me a while to understand and fix it). Let me know.

[wader]

Hey, yes that would be nice to support. I've only briefly looked at it some years ago but then concluded that at least for some of the GPU and CUDA libraries it didn't seem possible to produce a static binary. But please if you feel motivated have a look again and see how it looks!

[wader]

Now i remembered another possible issue: libs not linked with musl might be challenging.

[examedia-video-engineering]

Can also Intel drivers be added for Intel ARC GPUs transcoding acceleration?

[wader]

@examedia-video-engineering Hello, i have no experience using them but if the software needed is open source, can be built with musl libc and be link statically it should be work. Want to look into it? either do a PR or do research what packages would be needed and so on. I'm happy to help out.

[examedia-video-engineering]

Sounds good, i'll gather Intel ARC driver information, add it to your Dockerfile to test, and will report back if it works.

Off topic: What would you reccomend to troubleshoot docker build ? If there's an error with "checkdupsym" for example.
Any way to open up alpine build docker and shell into it?

[wader]

👍 When working on something i usually take the Dockerfile and strip out everything unrelated and also strip away everything after building ffmpeg, this way the build state kept and also have a shell. Now build the image and run it to get a dev env. In your case i think you can strip all tests for now, including checkdupsym. checkdupsym should only be needed to check for dup syms for rust based libraries.

[maxpain]

any updates?

[maxpain]

I usually use this static build with NVENC, but it would be better to use some docker image to copy binary from.

[wader]

@maxpain hey sorry for delayed answer. no update, it's not something i've needed myself. if nvenc is binary only libs it might be that they depend on glibc which might make it tricky to use with musl libc which alpine uses. but i think there are other glibc based ffmpeg docker images out there but don't know if they include nvenc.

[ToshY]

I usually use this static build with NVENC, but it would be better to use some docker image to copy binary from.

After giving Claude context of wader/static-ffmpeg and BtbN/FFmpeg-Builds, it denotes the following regarding this.

Claude: BtbN's "static" Linux builds are still glibc-dynamic ELF binaries (-static-libgcc/-static-libstdc++ only bake in GCC's runtime, not libc) and rely on the glibc loader plus Implib.so dlopen-stub trickery for things like NVENC/X11/libdrm, whereas wader's :8.1 is a true -static-pie musl binary with zero runtime dependencies that runs on FROM scratch.

---

From time to time I come back to this issue to check if someone was able to build an image here that supports this. Seeing no progress, last weekend I've been trying with AI to create a working docker image without much success either. I gave context of this repo alongside the docs Using FFmpeg with NVIDIA GPU Hardware Acceleration to several different AI tools, but the best it could do is 1) showing that it can create a docker image for this but it will not be fully static anymore and that the best option would be to build it as an additional new image, mwader/static-ffmpeg:8.1-cuda, and 2) it was only able to build it by removing basically all --enable flags (which basically defeats the point). The Dockerfile lives in a fork here.

I could live with point 1, but point 2 seems to be the actual problem.

ChatGPT: Static linking wants everything known at build time, but CUDA depends on runtime loading via dlopen, and musl enforces this mismatch strictly—causing fragile builds and missing symbols.

---

While I'm still interested in having an image that supports this, I am not sure how to proceed. 🙁

[wader]

Hey, thanks for the update. I see, if it uses dlopen at runtime i guess it is possible to build it fine but it will fail at runtime if the *.so files that gets loaded depends on glibc. Did you try? how did it fail?

Not sure if have any good ideas, building an executable that links with both musl and glibc sounds bad idea and or impossible.

[ToshY]

Hey, thanks for the update. I see, if it uses dlopen at runtime i guess it is possible to build it fine but it will fail at runtime if the *.so files that gets loaded depends on glibc. Did you try? how did it fail?

Not sure if have any good ideas, building an executable that links with both musl and glibc sounds bad idea and or impossible.

Hey @wader 👋

I was finally able to build a working image in PR #749 . I have tested it and I have not found a problem with it yet, however as I basically have zero knowledge in this field, it would require someone to take a good look at it to verify the integrity of the changes that were made.

[wader]

That PR reminds of a line from the Terminator, it's impressive but not sure what to think about it 😬 think my main issues with this is:

• The original "spirit" of the image is to be dead simple, both in end usage and how to build works. There are already some some hacks and workaround i wish/hope can go away in the future, adding even more feels not great.
• As we both lack understanding how the shims, wrappers and various hacks work i feel uncomfortable shipping it.
• I fear it will be hard to maintain and test this. Will new versions of the drivers require more shims and hacks? will CI be able to detect breakage?

Maybe a solution is that you maintain a fork/derivative of this image that is specifically just the cuda parts?

[ToshY]

That PR reminds of a line from the Terminator, it's impressive but not sure what to think about it 😬 think my main issues with this is:

* The original "spirit" of the image is to be dead simple, both in end usage and how to build works. There are already some some hacks and workaround i wish/hope can go away in the future, adding even more feels not great.

* As we both lack understanding how the shims, wrappers and various hacks work i feel uncomfortable shipping it.

* I fear it will be hard to maintain and test this. Will new versions of the drivers require more shims and hacks? will CI be able to detect breakage?

Maybe a solution is that you maintain a fork/derivative of this image that is specifically just the cuda parts?

I understand your concerns. While I thought using alpine as base image for the cuda target instead of scratch was still reasonable, the moment it started adding wrappers and shim hacks in order to resolve the different issues it encountered along the way, I started questioning if this would be actually maintainable as well.

So yes, I agree to not put something this hacky in here. Your suggestion to keep it the fork might be for the best (although I am not sure if it can be easily maintained).