AMD AMF Video Upscaler Diagnostics

Here's a scenario that will make sense to anyone who's used this pack: you drop in AMD Video Super Resolution, run it, and get an error that mentions sr_amf, a missing hwaccel, or an ffmpeg executable that apparently doesn't exist. Is the node broken? Is your FFmpeg wrong? Is your GPU too old? The AMD AMF Video Upscaler Diagnostics node answers that in one run, before you burn an hour testing workflows.

It's the third node in the AMD Video Upscaler pack (Yasei-no-otoko/ComfyUI-AMD-Video-Upscaler), and it exists for exactly this: it probes your FFmpeg binary, checks whether it has the AMF pieces the upscalers need, and - optionally - runs a real smoke test on your hardware.

What it checks

Two inputs, both easy:

• ffmpeg_path - which binary to probe. Defaults to ffmpeg (i.e. whatever's on PATH). If you've been pointing the advanced upscaler at a full path like C:\Tools\ffmpeg\bin\ffmpeg.exe, pass the same value here - that's the point: diagnose the exact binary you'll actually run.
• run_amf_smoke_test - default true. When on, it goes beyond probing and actually pushes a tiny 32×32 test image through sr_amf to prove the filter works end-to-end on your GPU and driver.

The output is a single diagnostics string, one line per finding. Wire it into a text display or just read it in the node's output - it looks like this:

ffmpeg: C:\Tools\ffmpeg\bin\ffmpeg.exe
version: ffmpeg version 8.1.1-full_build-www.gyan.dev
AMF hwaccel: True
sr_amf filter: True
vpp_amf filter: True
amf_sr smoke test OK: (1, 64, 64, 3)

Reading the lines is where the value is:

• AMF hwaccel false means your build doesn't support the AMF hardware device - wrong FFmpeg build, full stop.
• sr_amf filter false means no Video Super Resolution filter. The main node will fail with auto backend and the default error fallback.
• vpp_amf filter false means the amf_vpp_bicubic fallback won't work either.
• smoke test OK is the good ending - the filter actually ran on your GPU and produced a 64×64 result. smoke test: skipped because sr_amf is unavailable is the diagnosis in one line.

If probing itself fails - say the binary doesn't exist - the node catches it and returns a short traceback instead of a wall of broken assumptions. That's useful: it tells you the path is wrong, not the pack.

What to do with the answer

This is where it connects to the rest of the pack. All three nodes share the same requirements - Windows 10/11, an AMD Radeon driver with AMF runtime, and an FFmpeg build compiled with --enable-amf (the author tests the gyan.dev 8.1.1-full_build). If the diagnostics show sr_amf is missing, the fix is a different FFmpeg build, not a different node setting:

ffmpeg -hide_banner -filters | Select-String -Pattern 'sr_amf|vpp_amf'
ffmpeg -hide_banner -hwaccels | Select-String -Pattern '^amf$'

If the probe passes but the smoke test fails, you've narrowed it to the GPU/driver side of AMF - and the README's advice applies: try the advanced node with sr_algorithm set to sr1-0, since some hardware doesn't handle sr1-1.

Install

Same as its siblings: ComfyUI Manager (search "AMD Video Upscaler") or

cd ComfyUI/custom_nodes
git clone https://github.com/Yasei-no-otoko/ComfyUI-AMD-Video-Upscaler.git

Restart, search for AMD AMF Video Upscaler Diagnostics. No pip dependencies; the whole pack is pure Python that shells out to ffmpeg. For most people this node is a 30-second sanity check you run once when setting up. For everyone else - the ones whose AMF setup is a patchwork of builds and drivers - it's the difference between "this pack is broken" and "your ffmpeg has no AMF, here's the line."