Repository navigation
Bug: RFI test fails on ANV (Intel) and RADV (AMD) #39
Description
Found a bug that seems to predate any of my work while running tests.
On ANV (Intel Arc A310):
Generating testdata/test_frames_320x240_yuv420p.yuv...
H264: FAIL: post-recovery PSNR 18.76 dB below 30 dB (decoder desynced)
H265: PASS — recovered with a P-frame, full-stream PSNR 62.08 dB
AV1: FAIL: post-recovery PSNR 9.09 dB below 30 dB (decoder desynced)
Error: "RFI verification failed: H264: post-recovery PSNR 18.76 dB below 30 dB (decoder desynced); AV1: post-recovery PSNR 9.09 dB below 30 dB (decoder desynced)"on RADV (AMD Radeon 9060 XT)
Generating testdata/test_frames_320x240_yuv420p.yuv...
H264: FAIL: recovery frame 12 fell back to a keyframe (RFI did not engage)
H265: FAIL: recovery frame 12 fell back to a keyframe (RFI did not engage)
AV1: FAIL: recovery frame 12 fell back to a keyframe (RFI did not engage)
Error: "RFI verification failed: H264: recovery frame 12 fell back to a keyframe (RFI did not engage); H265: recovery frame 12 fell back to a keyframe (RFI did not engage); AV1: recovery frame 12 fell back to a keyframe (RFI did not engage)"
Activity
hgaiser commentedon Sep 18, 2026
Is this from a recent commit? The tests seem to work fine for me :\ (NVIDIA)
DatCaptainHorse commentedon Sep 18, 2026
I tried both the commit where it was introduced and latest, same deal. Seems that it "works on my machine" situation but for NVIDIA?
hgaiser commentedon Sep 18, 2026
That'd be a rare 'W' for NVIDIA 🤔
DatCaptainHorse commentedon Sep 18, 2026
Hm.. what's your
ffmpegversion?hgaiser commentedon Sep 18, 2026
9.0
DatCaptainHorse commentedon Sep 18, 2026
Same for me.. hm, I'll leave the issue open, see if I get time to dig into it since I got Intel + Radeon here.
DatCaptainHorse commentedon Sep 21, 2026
RADV only supports 2 references for H.264 and AV1, but only 1 for H.265, causing the RFI test to fail since it invalidates all the frames instead of calculating the supported amount from device info. This is hardware limit of AMD GPUs from looking into Mesa sources.
ANV is just plain neglected from looks of it, not supporting even rate-control methods (atleast on Alchemist), which I feel pixelforge could check against (it currenty assumes CBR,VBR,QP and such exist, ANV has none).
porkloin commentedon Nov 2, 2026
Reproduced on RADV with a different GPU and a newer Mesa, on current main (0c462fe) while testing #50:
cargo test --test rfi -- --ignored --nocapture --test-threads=1, with the validation layer on (no validation errors from this test)This matches the 9060 XT output above line for line, so it looks like it affects RADV in general, not one card.
hgaiser commentedon Nov 4, 2026
I added a commit on top of #50 to decouple the amount of reference frames we store from the amount of frames we actually intend to use, which mimics nvenc. That should also fix the issue reported here 🤞 . I couldn't test it explicitly because I have no RADV GPU nearby, but I could simulate it on my RTX GPU.
@DatCaptainHorse could you test again ?
ps. I don't expect this to change AV1 behavior, but we'll see.
DatCaptainHorse commentedon Nov 5, 2026
@hgaiser Here, looks like it fixes most, AV1 is expected with how ANV is currently.
hgaiser commentedon Nov 5, 2026
Awesome, thanks @DatCaptainHorse . Are we comfortable saying the ANV AV1 issue is in the ANV driver and therefore we can close this issue?
DatCaptainHorse commentedon Nov 5, 2026
Yep I agree with that, I'll try to keep up with news regarding ANV Vulkan Video support and see if it (ever) improves 👍