mpv-player
gpu-next: interpolation black flashes/flickering
Important Information
Provide following Information:
- mpv version : v0.37.0-81-g443c2487
- Platform and Version : Windows 11 Pro 23H2
- Source of the mpv binary : shinchiro
- If known which version of mpv introduced the problem : unknown, always present?
- GPU model, driver and version : RTX 4070Ti, 546.29
- Possible screenshot or video of visual glitches
Reproduction steps
mpv --no-config --vo=gpu-next --video-sync=display-resample --interpolation=yes HYbJ.mkv
Black flashes are present in certain scenes.
mpv --no-config --vo=gpu --video-sync=display-resample --interpolation=yes HYbJ.mkv
Normal playback without issue.
It's been suggested to try --correct-downscaling=no unfortunately it has no positive effect here. Using, e.g., --tscale=mitchell, instead of the default oversample does fix the problem however.
Expected behavior
No black flashes during video playback.
Actual behavior
Black flashes during video playback.
Log file
Sample files
The issue is especially noticeable at a certain distance from the screen in a dimly lit room.
https://0x0.st/HYbJ.mkv : note the porch railing on the left & right https://0x0.st/HYbv.mkv : around the trees in the foreground
I doubt it's related to such severe artifacting/corruption. It's not visible on screenshots at all, motion only. I'm not well versed in video capture either so above is the best i can do.
I believe I see what you are referring to and indeed it doesn't happen in vo_gpu. I checked some of the recent commits related to interpolation, but the behavior looks the same. I suppose this means libplacebo's oversample does something different than vo_gpu's implementation.
I took a couple of poor quality screen recordings where you can sort of see the flicker. It's hard to describe in words but if you see it you'll know what I mean. It's more apparent when you actually watch it on your own screen. This is from the HYbJ.mkv video.
gpu: gpu-2023-12-15_19.00.39.webm gpu-next: gpu-next-2023-12-15_18.59.44.webm
When watching these, I found it helpful to focus on this area of the picture. If you watch closely, you should be able to see that around the bars there's some black flickering (that's not compression artifacts) in gpu-next but not gpu as the video zooms out.
shouldn't a target refresh rate and such be added?
on my oled at 120 hz both flicker/ghost. can you check if one uses linear light blending and the other gamma light blending? just a blind guess.
i've been having this problem too. With vo=gpu is way less noticeable. A high tscale-blur fixes it tho, but ofc it makes everything blurry haha .
im using
tscale=sphinx
tscale-radius=0.49
tscale-blur=0.6991556596428412
It gets even worse with oversample
Just speculating here but VRR changes the gamma curve when framerate falls below the VRR range which can cause this 'flashes' in my experience. Solution here is to disable G-sync in NVCP either globally or only for mpv.
I can't reproduce it with the tscale=sphinx parameters on my end. VRR also isn't supported on my screen.
Just speculating here but VRR changes the gamma curve when framerate falls below the VRR range which can cause this 'flashes' in my experience. Solution here is to disable G-sync in NVCP either globally or only for mpv.
What on earth? Why would that be a thing? I've never seen that with Freesync. Then again, my monitor is just marketed as adaptive-sync and doesn't have LFC but I doubt that has anything to do with gamma.
I've been running oversample interpolation with display-resample on GPU-Next and haven't been able to reproduce on my AMD gpu in DX11, haven't tried with other interpolation scalers though.
Isn't there a different tscale-clamp default/behavior between gpu and gpu-next for oversample? (specifically, I seem to remember it being unclamped by default in libplacebo, while mpv defaults tscale-clamp to 1.0).
Just speculating here but VRR changes the gamma curve when framerate falls below the VRR range which can cause this 'flashes' in my experience. Solution here is to disable G-sync in NVCP either globally or only for mpv.
What on earth? Why would that be a thing? I've never seen that with Freesync. Then again, my monitor is just marketed as adaptive-sync and doesn't have LFC but I doubt that has anything to do with gamma.
I've been running oversample interpolation with display-resample on GPU-Next and haven't been able to reproduce on my AMD gpu in DX11, haven't tried with other interpolation scalers though.
@Jules-A you should really read up before disregarding this known issue.
https://www.google.com/search?q=vrr+gamma+flickering
Also an app to test this phenomena
https://github.com/MattTS01/VRR_Flicker_Test_OpenGL
Happens across all gpu-api.
@Jules-A you should really read up before disregarding this known issue.
I never said it was impossible, I just don't understand how it's possible. From what you linked it seems pretty much exclusive to OLED. I've never heard of gamma flickering but I have heard of brightness flickering. Thing is, how do you know it's gamma specifically and not just brightness? (well unless you have an OLED and specifically use that app). I think most people aren't using OLED though and honestly if this is related to VRR, people should be posting their monitor specs also.
@Jules-A you should really read up before disregarding this known issue.
I never said it wasn't impossible, I just don't understand how it's possible. From what you linked it seems pretty much exclusive to OLED. I've never heard of gamma flickering but I have heard of brightness flickering. Thing is, how do you know it's gamma specifically and not just brightness? (well unless you have an OLED and specifically use that app). I think most people aren't using OLED though and honestly if this is related to VRR, people should be posting their monitor specs also.
Dude you're the first person to mention brightness in this thread. OP's original issue was with flickering hence my suggestion of what could be the cause given that he has VRR, and provided a suggested solution for OP to try. Not sure why you are taking issue with me suggesting a potential fix, so weird.
Not sure why you are taking issue with me suggesting a potential fix, so weird.
I think you are just misreading or making too many assumptions, I never said anything of the sort, nor did I mean to imply your suggestion was invalid.
I've taken a look at this and I think gpu-next is doing thing correctly. I don't see flicker on my end though, but looking at the individual frames,
frame 277:
frame 278:
frame 279:
As we can see black area is blended with bright radiator fins. I suspect flicker is caused by monitor pixel response to such changes, because why only some people can reproduce/see it?
As for differences to vo_gpu. It is not perfect either and has own timing problems. libplacebo is more complete in its pipeline. Not sure what we can do here and if it is really desirable to force libplacebo to work like vo_gpu does.
As we can see black area is blended with bright radiator fins. I suspect flicker is caused by monitor pixel response to such changes, because why only some people can reproduce/see it?
This seems to be true, if I set my monitor to 60hz and set a really slow response time, I notice more flickers however it's about the same for both VOs. I don't really see any difference between vo_gpu or vo_gpu_next.
My monitor's response time is allegedly 5ms. Given that this is an old 4K IPS, I'd wager that it's extremely slow in practice.
I suppose it could be monitor specific. The most visible area of the flicker/flash/instability whatever you wanna call it actually isn't the radiator but the highlighted areas. Anyway the difference here between gpu-next and gpu / madVR is stark. I'm not too hung up on this issue though as i main madVR. Just wanted to point it out.
Out of curiosity, for the people who can "see" this problem, can you still see flickering if you use --tscale=sphinx --tscale-radius=0.50 ? This is an approximation of oversample, and should rule out the idea that there's something wrong with the oversample kernel.
Anyway the difference here between gpu-next and gpu / madVR is stark.
madVR's smoothmotion filter is blurrier and anti-aliases more than oversample IIRC, so the comparison isn't exactly 1:1 here.
Out of curiosity, for the people who can "see" this problem, can you still see flickering if you use --tscale=sphinx --tscale-radius=0.50 ? This is an approximation of oversample, and should rule out the idea that there's something wrong with the oversample kernel.
oversample is special case and working differently to anything else, in both gpu and gpu-next.
I'm aware, but I meant low-radius sphinx and oversample are visually ~~identical~~ similar in gpu-next, so the assumption here is if this is a problem where people are getting tricked by their monitor's response time, then you should be able to reproduce the problem with sphinx.
Now, whether or not gpu-next's oversample kernel is "correct" is a different story. I will just say this; when comparing the results to other software that offer similar "anti-aliased nearest-neighbor" filters, gpu's implementation is closer to them than gpu-next. But that wasn't really why I broached the topic.
can you still see flickering if you use --tscale=sphinx --tscale-radius=0.50
No flickering on my end with these settings. With --tscale=oversample (default) it's pretty obvious again.
Thanks for testing, I don't really have a good eye for this kind of stuff.
Though after spending a bit of time on this, I'm starting to think that --tscale-radius=0.5 might be too sharp and isn't doing any frame mixing (oops...? it's hard to tell honestly). A slightly larger radius around 0.56-0.57 might be closer to oversample in sharpness, but not necessarily identical since it's a 3D filter. Though, this might be a completely pointless goose-chase and still doesn't rule out monitor response times...