obsproject
obs-ffmpeg: AMD Support on Linux with AMF
Description
Adds support for the AMF encoders on Linux.
Motivation and Context
- Support AMF encoders on Linux
- Feature parity with Windows
How Has This Been Tested?
- Tested on Ubuntu 24.04 on RX 9070, RX 7800, and Ryzen 9 7940HS.
- Tested on Windows 11 on RX 7800
Types of changes
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [ ] I have included updates to all appropriate documentation.
https://www.amd.com/en/resources/support-articles/release-notes/RN-AMDGPU-UNIFIED-LINUX-25-10-1.html
AMF will no longer be included in the release. AMF users are advised to transition to VA-API / Mesa Multimedia.
This PR looks contradictory to the recent announcements.
https://www.amd.com/en/resources/support-articles/release-notes/RN-AMDGPU-UNIFIED-LINUX-25-10-1.html
AMF will no longer be included in the release. AMF users are advised to transition to VA-API / Mesa Multimedia.
This PR looks contradictory to the recent announcements.
New versions of AMF will continue to be released for supported Linux distros. Installation procedure will be different. Please stay tuned.
Tagging related question on GPUOpen/AMF: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/557
supported Linux distros
Flatpak/Flathub is not supported, and the subset that the actual Radeon™ Software does support is not really fitted to enable AMF to a wide range of users.
Installation procedure will be different.
If the method is not Flathub for the Flatpak and/or the distro own packages (like it is done for NVENC most of the time) or if the user has to go through hoops to enable AMF, there is not much point for this.
I agree, adding support for these things if installation method for the drivers is out of reach for a majority of Linux users—not to mention not available in flathub, an official way OBS is distributing to Linux—is kind of pointless.
AMD should really work on packaging their in-house drivers more widely first.
Sorry just wanted to give my two-cents on driver availability, which i think has been a long overdue issue for AMD's in-house drivers.
Made AMF encoder build optional and rebased on top of latest base branch.
AMF headers will be provided as a package from a repo as well as AMF runtime, please stay tuned. This will support building on Flatpak/Flathub.
In the meantime, AMF encoders will be skipped during the build while the AMF headers are not found.
Discussions going on:
- https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/28039
- https://github.com/flathub/flathub/pull/6871
- https://github.com/flatpak/flatpak/pull/6287
Your—AMD staff—input would be appreciated.
Made AMF encoder build optional
No revert that change or fix it (as it is, it is just a mean to have a green CI). Adding AMF headers is a non-issue, don't add unnecessary complexity to the build system.
@RushingAlien, I would heavily preferred that all of this was started by AMD themself.
How should we add AMF headers to the OBS build in the preferred way?
Let's not do things out of order. Ensure that AMF is clearly available to a wide range of users without going through hoops, then the discussion about how headers could be provided for OBS can start.
Let's not do things out of order. Ensure that AMF is clearly available to a wide range of users without going through hoops, then the discussion about how headers could be provided for OBS can start.
AMF is currently available as part of Radeon driver installation. With the upcoming installation change it would be a separate small set of packages installed on top of the driver. Potentially AMF runtime binaries could be included in flatpak, but update would be an issue: AMF needs to be updated with VCN FW update which is coming from driver update. Because of that, AMF could be considered a driver rather than a library. With this in mind what advice can you make to provide wide availability?
AMF needs to be updated with VCN FW update which is coming from driver update.
With the upcoming installation change it would be a separate small set of packages installed on top of the driver.
Most of users don't use Radeon™ Software, only Mesa, so if AMF still requires Radeon™ Software ("driver update") to work properly even if RADV can be used, this is not okay.
Depending on how your firmware update works (e.g. "flash on EEPROM") you might have to try to see if LVFS with fwupd(/gnome-firmware) would a better option for those firmware updates.
If it's loaded in the GPU at runtime like linux-firmware (so maybe in GPU's volatile memory), you need to check if a sandbox environment with access to DRI device can do it.
With this in mind what advice can you make to provide wide availability?
- Don't assume that users will go to your website (to install your software), all distro provides Mesa which is a perfect fit for most of the cases.
- Making AMF available in Flathub's runtime/SDK would be a big coverage since Flatpak works on most of distros. But this is a sandboxed environment.
- Ask Freedesktop and Mesa community on how it could be done, I'm not a driver developer.
AMF needs to be updated with VCN FW update which is coming from driver update.
Sorry but, firmware update is a bit ambiguous here. Do you mean linux-firmware blobs or on-device firmware?
Also sorry, i'll stop suggesting things and just ask questions.
Most of users don't use Radeon™ Software, only Mesa, so if AMF still requires Radeon™ Software ("driver update") to work properly even if RADV can be used, this is not okay.
Mesa (and AMF) is relying on Linux kernel driver (amdgpu part of it) and several user-mode libraries like libdrm (libdrm_amdgpu). Encoder (VCN) FWs come as blobs with Linux kernel driver and can be updated. ( RushingAlien : https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu). "Driver update" means Linux kernel update as well as these firmwares. Beside that, AMF doesn't require anything from Radeon Software.
Depending on how your firmware update works (e.g. "flash on EEPROM") you might have to try to see if LVFS with fwupd(/gnome-firmware) would a better option for those firmware updates.
If it's loaded in the GPU at runtime like linux-firmware (so maybe in GPU's volatile memory), you need to check if a sandbox environment with access to DRI device can do it.
AMF relies on GPU kernel driver to load FW so it should not be a problem in sandbox. But AMF version should match FW version, at least for now.
With this in mind what advice can you make to provide wide availability?
- Don't assume that users will go to your website (to install your software), all distro provides Mesa which is a perfect fit for most of the cases.
- Making AMF available in Flathub's runtime/SDK would be a big coverage since Flatpak works on most of distros. But this is a sandboxed environment.
- Ask Freedesktop and Mesa community on how it could be done, I'm not a driver developer.
With that it seems there are three ways of delivery AMF runtime. Corrent me if I am wrong or missing something:
- AMD repo - available now with some changes later. Works for native OBS, need to test Flatpak OBS.
- Flathub - needs to be added and tested. I will initiate work on this.
- Via distros. Could be an issue as they prefer open-source components. Making AMF open source is a different issue.
So the whole firmware part is a non issue if you properly commit to update linux-firmware.
AMF relies on GPU kernel driver to load FW so it should not be a problem in sandbox. But AMF version should match FW version, at least for now.
You need to avoid/reduce the scenario where everything was fine and then broke because AMF updated and expect a newer linux-firmware that the distro will not provide.
This also mean that the encoder must not be registered if AMF can't work with the available firmware.
AMD repo - available now with some changes later. Works for native OBS, need to test Flatpak OBS.
Consider it mostly unused, this is a "hoops".
Flathub - needs to be added and tested. I will initiate work on this.
You'll need to discuss with Freedesktop SDK and Flathub for the best way, a specific extension for AMF similar to LinuxAudio, Intel VAAPI and NVENC VAAPI is a possibility.
Via distros. Could be an issue as they prefer open-source components. Making AMF open source is a different issue.
If you enable them to re-bundle your binaries this should be a lesser problem (sorry but NVIDIA driver is an example).
The Ubuntu PPA build, it is likely to be disabled since we need really recent AMF headers most of the time. A copy could be provided at build time but this is not up to me to decide on that.
For Ubuntu CI, AMF needs to be disabled if the AMF header from the distro is too old.
This also mean that the encoder must not be registered if AMF can't work with the available firmware.
This works already with help of obs-amf-test.
AMD repo - available now with some changes later. Works for native OBS, need to test Flatpak OBS. Consider it mostly unused, this is a "hoops".
Understood, but this is a starting point, similar to HB.
You'll need to discuss with Freedesktop SDK anf Flathub for the best way, a specific extension for AMF similar to Intel VAAPI and NVENC VAAPI is a possibility.
I see how NVENC headers are delivered to freedesktop-sdk. This should not be a problem for AMF. Also, NVIDIA GL binaries come from here: https://github.com/flathub/org.freedesktop.Platform.GL.nvidia/tree/master. But I don't see NVENC binaries.
If you enable them to re-bundle your binaries this should be a lesser problem (sorry but NVIDIA driver is an example).
Could you please point to NVENC binaries delivered from distros?
For Ubuntu CI, AMF needs to be disabled if the AMF header from the distro is too old.
AMF is fully backward compatible. Headers need to be updated only if you need a new feature.
I see how NVENC headers are delivered to freedesktop-sdk. This should not be a problem for AMF. Also, NVIDIA GL binaries come from here: https://github.com/flathub/org.freedesktop.Platform.GL.nvidia/tree/master. But I don't see NVENC binaries.
Flathub got authorized by NVIDIA to directly re-bundle their driver, so most of its userspace files is copied in the extension (including libnvidia-encode.so).
A GL extension might be overkill for AMF usecase, a simpler extension might be more fitted (since it's just a library).
Could you please point to NVENC binaries delivered from distros?
In Arch Linux case, libnvidia-encode.so is re-packaged in nvidia-utils(src).
For distro, it's really a question of allowing distro to re-bundle AMF binaries (a.k.a. redistributable). They would not have too much trouble providing a package if there is a need.
But you really need to fix your communication mishap, right now people might think that AMF is dead since a few release of Radeon™ Software.
Flathub got authorized by NVIDIA to directly re-bundle their driver, so most of its userspace files is copied in the extension (including
libnvidia-encode.so).
For distro, it's really a question of allowing distro to re-bundle AMF binaries. They would not have too much trouble providing a package if there is a need.
OK, will work on this.
But you really need to fix your communication mishap, right now people thinks that AMF is dead since a few release of Radeon™ Software.
Yea, AMD is big. Will communicate with the next AMF release. Thanks.
In Arch Linux case,
libnvidia-encode.sois re-packaged innvidia-utils(src).
I don't see libnvidia-encode.so in these links.
In Arch Linux case,
libnvidia-encode.sois re-packaged innvidia-utils(src).I don't see libnvidia-encode.so in these links.
Their installer is extracted then re-bundled. https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/blob/main/PKGBUILD?ref_type=heads#L185
What advantages does AMF have over Mesa's VAAPI and Vulkan Video support?
AMF, exposes more features like pre-analisys including lookahead, high-quality rate control modes, split frame encoding, low latency mode and parity with windows when a new feature is exposed or new HW released. Eventually AMF preprocessor could be added further improving quality. It seems AMF has better performance in multi-stream mode.
Was that tested on AMF with RADV, AMDVLK or vulkan-amdgpu-pro as a backend?
What advantages does AMF have over Mesa's VAAPI and Vulkan Video support?
AMF, exposes more features like pre-analisys including lookahead, high-quality rate control modes, split frame encoding, low latency mode and parity with windows when a new feature is exposed or new HW released. Eventually AMF preprocessor could be added further improving quantity. It seems AMF has better performance in multi-stream mode.
@cyanreg @nowrep You might have an opinion on this?
Was that tested on AMF with RADV, AMDVLK or vulkan-amdgpu-pro as a backend?
Since we expect user to only use Mesa, I hope and expect testing being mainly done on RADV.
What advantages does AMF have over Mesa's VAAPI and Vulkan Video support?
You might have an opinion on this?
VAAPI and Vulkan Video will never be able to make a perfect common encoding API, every vendor will do their own stuff.
Intel created VAAPI but they still do QSV, NVIDIA even used VDPAU rather than implementing decoding through VAAPI.
@eszlari, now this question is off-topic and pinging people is maybe not welcome by them.
Was that tested on AMF with RADV, AMDVLK or vulkan-amdgpu-pro as a backend?
All three
While I appreciate the discussion around the larger AMF/VAAPI/Vulkan ecosystem, let's please move this conversation to a discussion or otherwise off-thread, as it's largely off-topic to the content of the PR itself and will make this more difficult to review long-term.
Recap of the situation about AMF:
- [ ] A new release of AMF standalone of the rest of Radeon™ Software needs to happen
- The licensing needs to be cleared out since it is bound to not be the AMDGPU-PRO EULA since standalone
- The Flatpak side needs preparation which would fix the issue of wide access AMF to users:
- [x] A new extension endpoint (not GL) meant for AMF (or AMD in general) which adds the its library path in the ld paths
- This change is likely bound to be released in 2026, but we can temporarily support the extension point in our manifest which uses 24.08 (or 25.08).
- https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/29132
- [ ] Flathub needs to have the AMF extension published with preferably the authorization to directly re-bundle AMF (so no extra-data).
- https://github.com/flathub/flathub/pull/7104
- [x] A new extension endpoint (not GL) meant for AMF (or AMD in general) which adds the its library path in the ld paths
- For Ubuntu CI test-building (PPA is a separate thing), it will depend on the availability of AMF headers in Ubuntu official repo if we disable building AMF or not
- Until Ubuntu provide AMF re-bundled in its repo, having it enabled for users is not really useful since it would make users go through "hoops".
I'm considering rebasing #11334 since the AMF codebase is getting bigger with this PR and the AMF is not related at all to FFmpeg (NVENC was split in earlier versions).
What advantages does AMF have over Mesa's VAAPI and Vulkan Video support?
AMF, exposes more features like pre-analisys including lookahead, high-quality rate control modes, split frame encoding, low latency mode and parity with windows when a new feature is exposed or new HW released. Eventually AMF preprocessor could be added further improving quantity. It seems AMF has better performance in multi-stream mode.
@cyanreg @nowrep You might have an opinion on this?
Yeah, use Vulkan Video. The code to use it is already in OBS, since OBS uses the hwcontext/encoding infrastructure of FFmpeg, which can be trivially changed to use Vulkan. Additionally, we have more Vulkan Video features upcoming that cover all of the features.
At the end of the day, you don't use hardware encoders because of their efficiency, because it will never match what a software encoder can do.
Recap of the situation about AMF:
After internal conversations we are going ahead with all items recapped by tytan652. It may take some time to put headers and binaries into Ubuntu. But Flatpak extension can be done quite fast by AMD as soon as new way of distributing AMF binaries is online. With that few questions:
- For AMF extension, to avoid extra-data method, would it be sufficient if AMF binaries are available in a TAR file?
- To fix CI builds, how to deliver AMF header files before they are included in Ubuntu? AMF publishes TARs with headers here: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/releases and it is already used for Flatpak in this PR.
- For AMF extension, to avoid extra-data method, would it be sufficient if AMF binaries are available in a TAR file?
The extra-data method is only if redistribution/repackaging is not allowed by the AMF library binaries license. In any case even the Ubuntu deb could be used.
But maybe ask Flathub/Freedesktop if they have a preference.
If redistribution/repackaging is explicitly allowed (e.g. license, "e-mail allowing it") to Flathub or Freedesktop, then extra-data can be skipped.
- To fix CI builds, how to deliver AMF header files before they are included in Ubuntu? AMF publishes TARs with headers here: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/releases and it is already used for Flatpak in this PR.
It depends on what Ubuntu provides in its official repo, if its too old then AMF is to be disabled on Ubuntu CI.