The AMF SDK is AMD's multimedia framework for C++ pipelines

A multimedia framework whose abstraction still knows about AMD

AMF is a light-weight, portable multimedia framework that abstracts away most of the platform and API specific details, and allows for easy implementation of multimedia applications using a variety of technologies such as DirectX 11, OpenGL and OpenCL, while facilitating an efficient interop between them.

That interop claim is the real subject of the project. DirectX 11 on Windows, Vulkan and OpenCL elsewhere, and OpenGL for interop with existing 3D pipelines, are three different worlds with three different resource models. A team that has to hand a decoded frame to a scaler and then to an encoder and then to a display path is otherwise writing adapter code for each combination. AMF's component model is the answer to that: a pipeline of components with an interop layer between them.

The repository layout shows the scope of what ships. The top level holds the amf directory with the SDK itself, a Thirdparty directory for the bundled third-party code, a LICENSE.txt, and a .github directory. The project is C++, and it lives under the GPUOpen-LibrariesAndSDKs organisation, which is AMD's public repository for the libraries and SDKs it publishes.

There is a caveat about that abstraction that runs through everything else in this article. AMF is not a general multimedia framework that happens to run well on AMD cards. It is AMD's framework, it talks to AMD drivers, and each release of the SDK is tied to a specific driver release. The README states it directly: the AMF SDK is backward compatible with all previous driver versions, but each SDK version requires a named minimum driver.

The homepage field for the repository is empty, but the README links the AMD support download page for the Windows driver and the Radeon repository for the Linux driver, so the drivers come from AMD rather than from the SDK repository.

Prerequisites: operating systems, toolchains and one driver table

The prerequisites section is short and specific.

On Windows the requirement is Windows 10 or Windows 11, plus Visual Studio 2022. There is a separate line for the Windows Subsystem for Linux, marked as DX12 Decoder and Converter Only, which tells you that WSL is not a general target but a narrow one where only those two components are expected to work.

On Linux the supported distributions are:

RHEL 9.8 / 10.2
Ubuntu 24.04.4 / 26.04.1
SLED/SLES 15.7 / 16

Then comes the part that decides whether you are in scope, the driver table showing from which driver version the AMF runtime is included in the Linux pro driver, and otherwise the runtime has to be installed separately. Two rows of that table are worth quoting:

| SLE 15                    | 18.40                             |
| Ubuntu 20.04.0            | 20.20                             |

And the note that all supported distros include the AMF runtime starting driver version 20.40.

Two warnings sit alongside that table. The 25.10 Linux driver has a known installation bug, with details on the Linux Driver Install wiki page. And starting with the 25.20 Linux driver, the AMF runtime is released separately, so the instructions on that wiki page have changed for the most recent drivers.

That second point is the practical trap for a new user. A tutorial written against a 2023 driver will tell you to install nothing extra, and a 2026 driver will leave you without a runtime unless you fetch it separately.

Driver and AMF component installation instructions are available on the wiki page, which is where the SDK sends you for the parts it cannot do for you.

The version history is a feature catalogue with driver floors

The longest part of the README is the version history, and reading it tells you what the framework can actually do and what it costs you in driver version.

The current release is 1.5.3, which requires AMD Software: Adrenalin Edition 26.9.2 (26.20.15.02) or newer. It added color matrix support for VideoConverter and VideoDecoder, initial VPE support for VideoConverter, cursor embedding support for DirectCapture, rotation support for VideoConverter, and updated FFmpeg to 8.1.2. There is a note attached to that entry: rotation is currently available when VPE is not enabled.

That single sentence is a good example of how this project works. VPE, the video processing engine, is a hardware pipeline on recent AMD silicon, and some features are not yet wired into it. So a feature can exist in the SDK and still be unavailable depending on which hardware path your pipeline selects.

Working backwards, 1.5.2 required Adrenalin 26.5.1 (26.10.07.01) and updated FFmpeg to 8.0.1. Version 1.5.0 required 25.10.1 (25.20.21.01) and added 4:4:4 and 4:2:2 chroma subsampling support for VideoConverter color space conversion and scaling. The 1.4.x line added the FRC component and its API doc, the VQEnhancer component, AV1 encoding support, 12-bit AV1 decoding, new rate control methods, PSNR and SSIM score feedback, HDR support for the HEVC encoder and the color converter, AMD Direct Capture, a new pre-encode filter within the pre-processing component, SmartAccess Video for AVC, HEVC and AV1, native DX12 support for encoding and pre-analysis, and support for AMD Pro Vulkan on Linux with experimental support for RADV drivers.

Two entries in that list are worth isolating. Multi-HW instance encoder mode and split frame encoding arrived in 1.4.35, which is the kind of capability that matters on a high-end card with multiple compute units. And the switch to public Vulkan Khronos extensions for the decoder in 1.4.33 is a portability decision that affects anyone running against a non-AMD Vulkan implementation.

Third-party dependencies: FFmpeg, Vulkan SDK and OCL SDK Light

The SDK ships third-party code and expects some tools on your machine, and the rules changed over the versions.

FFmpeg is bundled and versioned with the SDK. The history records updates to 5.1.2 in 1.4.30, 6.0 in 1.4.32, 7.0 in 1.4.35, 8.0.1 in 1.5.2 and 8.1.2 in 1.5.3. AMF also added wrappers for the AVC, HEVC and AV1 FFmpeg software encoders in 1.4.30, which means the software path is reachable through the same component API as the hardware path.

The external requirements have been reduced over time rather than increased. Version 1.4.4 or later requires OCL_SDK_Light from the GPUOpen OCL-SDK releases, and previous versions of AMF required the AMD APP SDK, version 3.0 or later, and the Windows 10 SDK, version 10586. Version 1.4.9 or later requires the Vulkan SDK for some samples, with the link to the LunarG site, and it is the point at which the project added Linux support.

So a current user needs the Vulkan SDK for some samples and OCL SDK Light, and no longer needs the AMD APP SDK. The GitHub Actions and wiki tooling aside, the samples are the part that needs the most local setup, which is worth knowing before you plan an evaluation around them.

The Linux side has a parallel wrinkle in the graphics driver rather than the SDK. In 1.4.34, support for RADV drivers for AMF on Linux became stable for VideoConverter, HQScaler and VideoEncoder, and experimental for the decoder. In 1.4.33, AMF on Linux could be used with AMD Pro Vulkan, and experimentally with RADV. The wording matters if you plan to run on a non-AMD-pro GPU stack.

Where AMF is the wrong tool

The boundaries are sharp, and they are all consequences of tying a media framework to one vendor's drivers.

It is not portable across hardware vendors. Everything AMF exposes is implemented by the AMD driver, so an NVIDIA or Intel GPU is out of scope by construction. If your product has to run on whatever GPU the customer has, AMF is one backend of your pipeline rather than the pipeline itself.

The driver coupling is a real cost. Each SDK release names a minimum driver, so upgrading the SDK can mean upgrading the driver on every machine you ship to. The 25.10 Linux installation bug and the separate runtime release from 25.20 add operational steps that are not your code's fault and not your team's fault.

Feature availability is conditional on hardware path. Rotation is available when VPE is not enabled. The DX12 decoder and converter are the parts supported under WSL. RADV support was experimental for the decoder. VQEnhancer and FRC exist only on parts of the AMD range, and the README's own hardware compatibility statement starts at the Southern Islands family for most recent Radeon GPUs, which is a floor rather than a ceiling on what you will find unsupported.

There is also a scope limit that is easy to miss. AMF is a set of components for decode, encode, conversion, scaling and video processing. It is not a container, a demuxer, an audio stack or a playback engine, and the framework does not give you a timeline, a file writer or a network sender. You will be assembling those yourself around it.

The alternative approach, and the difference in approach, is to build the pipeline on FFmpeg's own filters and codecs and use the vendor acceleration only where it pays. The README itself contains that comparison, because the FFmpeg software encoders are wrapped in AMF and versioned with it. A team that needs one predictable code path across many machines will often find the FFmpeg path simpler, accepting hardware acceleration as an optional optimisation rather than the foundation. A team that needs AMD specific hardware features, AMD Direct Capture, FRC or VQEnhancer has no such choice, and for them AMF is the only route.

Licence, packaging and the maintenance record

The licence needs reading rather than assuming. The licence is shown as Other in the repository metadata, a custom licence GitHub cannot classify, so LICENSE.txt at the root is the text that governs. For a project that bundles FFmpeg and third-party code, the Thirdparty directory at the top level is where the notices for that bundled code live, and any product that ships AMF will need to carry those attributions forward. The README has an attribution section for exactly this purpose.

On maintenance, the release record is steady. The recent releases are AMF Release v1.5.0 on 2025-10-29, v1.5.2 on 2026-05-06 and v1.5.3 on 2026-09-29, so roughly two releases a year on a version line that is still in the 1.5 range. The last push was on 2026-10-16 and the repository is not archived.

The upgrade cost of moving between SDK versions is not really the code. It is the driver floor moving, the FFmpeg version moving with it, and the occasional behaviour change such as rotation becoming unavailable once VPE is enabled in your pipeline. Those are the three things to check in the version history entry before you take a new SDK release into a shipping product.

The starting point for any of this is the wiki, which the README points to for driver and component installation instructions, the Linux Driver Install page for the current driver caveats, and the per-component documentation that the changelog references, including the new FRC component and API doc and the VQEnhancer doc.

Editorial conclusion

C++ teams building video encode, decode or scaling pipelines that target AMD hardware should evaluate AMF, because it hides the DirectX, Vulkan and OpenCL differences behind one component API and it is the only way to reach AMD specific features such as VQEnhancer, the FRC component and AMD Direct Capture. It is the wrong tool if your pipeline has to run on NVIDIA or on CPU only, if you cannot accept a driver-version floor, or if you need rotation together with VPE, since the README notes rotation is available when VPE is not enabled. Before adopting, check the driver table in the README for your distribution, read the Linux Driver Install wiki page because the 25.10 driver has a known installation bug and the runtime is released separately from 25.20, and confirm your target is covered by AMF release v1.5.3, which requires AMD Software: Adrenalin Edition 26.9.2 or newer.

Frequently asked questions

Official sources

1. GPUOpen-LibrariesAndSDKs/AMF on GitHub
2. Issues
3. README
4. Releases