mpv
mpv copied to clipboard
mpv-player
Linux: True/exclusive fullscreen mode
On Windows with a FreeSync/G-Sync monitor and supporting GPU, variable refresh rate works out of the box in (exclusive?) fullscreen mode - and that is a good thing if Low Framerate Compensation works correctly (or the monitor's VRR range is sufficiently low). On Linux, there does not seem to be any way to achieve this.
VRR otherwise works on my Linux system (FreeSync monitor, Vega 64, Manjaro Testing, 5.10 kernel, KDE Plasma 5.20@X11), https://github.com/Nixola/VRRTest and Doom (in both Vulkan and OpenGL modes) run flawlessly.
I have tried both Vulkan implementations for AMD, various outputs/apis and options (opengl-swapinterval=0, vulkan-swap-mode=immediate, x11-bypass-compositor=yes, override-display-fps...), disabling the compositor etc.
It seems that there is simply no support for actual/exclusive fullscreen mode on Linux. I would love for this feature to be added (for instance utilizing Vulkan's VK_EXT_full_screen_exclusive).
Well, this is kind of funny. I want a way to disable it... Nvidia gpu over here and kubuntu.
My findings are that when using mpv directly __GL_VRR_ALLOWED=0 does not work, gsyng is still engaged when mpv goes fullscreen. Now if I use smplayer gui with mpv gsync does not engage when in fullscreen, good, at least in KDE.
I can see stutters when using mpv directly and none with smplayer gui. I use LG C9 TV set to 119.88Hz refresh rate because 23.976fps * 5 = 119.88fps / hz so no need to change tv refresh rate to 23.976hz. (Besides, I could not use 23.976, 24, 25, 29.96 and 30hz because nvidia drivers are not disabling gsync like they do in windows automatically at that low Hz resulting in black screen for me)
My explanation is that when using interpolation and video-sync=display-resample + gsync is a recipe to stutters and that is what i am seeing. either way, mpv could have some setting to help with this.
Well, reading more about e.g. issues with older versions of Chrome regarding this: It seems that Nvidia is more aggresive in applying VRR/*Sync than AMD, both on Windows and Linux. On Linux, the only way to get VRR working on AMD (among other things, like having a single monitor & proper X11 config) is a true fullscreen mode. Honestly, after a quick look at mpv's sources, fullscreen in X11 (OpenGL or Vulkan) means just _NET_WM_STATE_FULLSCREEN, if that triggers VRR on Nvidia, then they really are aggresive.
My monitor has Low Framerate Compensation and it seems to work well in both Windows and Linux (it kicks in when at ~52 Hz and turns off when at ~58 Hz), on Windows that includes mpv in fullscreen, so if AMD behaved like that, it would probably work great on my monitor, but I can see why they apply it in true fullscreen modes only.
That being said - have you tried setting max refresh rate possible, video-sync=audio (should be default) and override-display-fps to a multiple of 23.976 that is within your monitor's VRR range? For videos with that framerate, it should work well, if VRR works as it should.
I don't have issues with my playback as long gsync is not engaged. It engages with mpv but not with smplayer-gui.
That being said - have you tried setting max refresh rate possible, video-sync=audio (should be default) and override-display-fps to a multiple of 23.976 that is within your monitor's VRR range? For videos with that framerate, it should work well, if VRR works as it should.
" I use LG C9 TV set to 119.88Hz refresh rate because 23.976fps * 5 = 119.88fps / hz so no need to change tv refresh rate to 23.976hz. "
I do not think you understood or I'm not following.
I understand, I was just suggesting settings that might work even with GSync - and would be worth testing for the purposes of this feature request - though the point of this FR is to implement some some sort of true/exclusive FS mode.
Properly implemented VRR is potentially the holy grail of smooth video playback, better even than e.g. autosetting refresh rate to multiples of video FPS (due to audio/video clock desync issues etc.).
My hypothesis is that you've encountered stuttering issues due to the absence of Low framerate compensation on your TV. The override-display-fps=71.928 (or whichever multiple is within the VRR range of your TV) and removal of the video-sync option might avoid that. Also see: #6137
I'm not sure, if you don't want to fiddle with mpv (completely understandable), just ignore this FR - it really is about implementing e.g. VK_EXT_full_screen_exclusive or some other sort of true/exclusive FS mode. I will remove VRR from the title, as VRR is the reasoning behind the feature request rather than the feature request itself.
Did some testing and the thing is, your suggestion does not work with interpolation so that is a no go for me. I really need interpolation to help with oled fast pixel response that makes 23.976 videos, especially pans, jumpy...
..and I kinda don't agree that any kind of vrr is the way to go for stable stutter free videos as long you have some kind of audio videoclock,reclock,display-resample mechanism. VRR works fine for variable frequency like games but videos that are 100% sensitive to a fly flying around we should want the most stable setting available and I wont even mention gamma flickering that gsync does in some situations.
mpv with gsync -> https://youtu.be/0t2gJpiyYQs mpv without gsync -> https://youtu.be/bnXfz99ZjpY
you can see that estimated jumps around a lot more with gsync and that is causing stutters for me. The same happens in windows, I disable gsync for videos or nvidia driver does it for me if selecting 23Hz refresh rate instead of using 119.88Hz. In linux selecting 23Hz I get black screen if gsync is enabled. Have to disable it in the TV menu.
I was asking you to test whether GSync works correctly when forced to push frames within VRR range of your TV, not really suggesting actual settings for you to permanently use...
The point of VRR (aside from the ability for irregular vblanks, obviously useful in games) in video playback is that generally, you can achieve any (regular) refresh rate you want for current content (though high-precision timing of stuff is a bit tricky, might be the case here), without actually reducing the actual (maximum) from the maximum supported by the display, with black screen pauses due to mode changes etc. If you like interpolation, then instead of override-display-fps=71.928, you should probably use the HIGHEST multiple of the content's FPS to achieve as many frames as possible while retaining the same amount of interpolated frames between actual (original) frames. With a good *sync implementation, you should be able to achieve as stable settings through VRR as through actual display mode - with the added bonus of actually being able to use audio clock without any kind of audio resampling. Of course if the display has bad implementation of VRR that suffers from issues you have mentioned, fixed refresh rate is the better way to go.
There is absolutely no reason for VRR not to work with interpolation, on Windows, SVP (x2, x3, x4 depending on the original content) works well in combination with FreeSync. Whether mpv currently supports interpolation in combination with VRR is another thing entirely. Maybe override-display-fps=119.88 and set video-sync to whatever it was before?
Anyway, again, VRR is not, strictly speaking, the point of this FR.
Did a mistake on previous reply..
with override-display-fps interpolation is working but i only get stutter stutter stutter. tried override-display-fps=95.904 , 119.88 is what it defaults to already.
While I do understand your point, i have been there, forcing video to play inside VRR range to not have to change screen refresh rate and go through that black screen you mention, I never got 100% stutter free video that way. I am lucky that my TV accepts both 119.88Hz and 120Hz making my life easier for 23.976 and 24 movies. Then for 25 xrandr.lua changes screen to 50Hz, I don't know why but it does ignore my script-opts=xrandr-blacklist=[23.98,24,25,29.97,30,50] and still sets it to 50 while it should be 100Hz but that is for another topic.
So that is why I would like to know how to make mpv disable gsync
EDIT: well I kinda know one way but it is very clumsy.. nvidia-settings --assign="AllowVRR=0" && mpv video.mkv && nvidia-settings --assign="AllowVRR=1"
Have you tried stuff like opengl-waitvsync (if using OpenGL API)?
Do you have a refresh rate counter in your TV/display? To actually see the average amount of frames being pushed to the TV? That stutter seems like presented frames rate vs. refresh rate mismatch.
Anyway, for me, VRR is working well in mpv, on Windows that is. So I'd like to definitely see the same on Linux.
__GL_VRR_ALLOWED=0 does not work
It works, just not for Vulkan. Did you try to google? https://forums.developer.nvidia.com/t/gl-vrr-allowed-only-affects-opengl-applications-and-is-ignored-with-vulkan/79594
I use LG C9 TV set to 119.88Hz
That will not work for 24.000 integer framerate content.
Yes I did. Nothing works with mpv. Gsync keeps enabled for mpv unless I disable it in the nvidia settings.
For 24.000, 30 and 60 you use 120Hz 23,976, 29.97 and 59.94 -> 119.88Hz 25 and 50 -> 100Hz
I haven't once seen a video that does not stutter with gsync working.
video that does not stutter with gsync working
Well, I did. On Windows 😜
Yeah, until you see gamma flickering because of it.😐😐😑😑 . Until I see gsync 100% locked to what ever frequency we tell it to be, there will be issues, as of now, it jitters slightly. Really seams like mpv video-sync and gsync are playing mouse and cat. You can see it on my 2 YouTube links above.
In windows I have profile in nvidia settings to disable gsync for video player, force vsync to on and make sure sure gpu clocks are locked (maximum performance setting instead of normal for me). Then it is perfect.
video-sync=display-resample + gsync causing stutter has nothing to do with exclusive fullscreen on Linux, in fact, it also happens on Windows because display-resample is trying to match the framerate of the display and the display is trying to match the framerate of mpv and they just get into a race to the bottom. If you have gsync, you do not need display-resample. The reason why you don't see it happening with smplayer is probably that in true smplayer fashion, it completely breaks display-resample.
I am interested in seeing VK_EXT_full_screen_exclusive in mpv just to see how many compositor bugs it either causes or works around.
video-sync=display-resample + gsync causing stutter has nothing to do with exclusive fullscreen on Linux, in fact, it also happens on Windows because display-resample is trying to match the framerate of the display and the display is trying to match the framerate of mpv and they just get into a race to the bottom. If you have gsync, you do not need display-resample.
I am interested in seeing
VK_EXT_full_screen_exclusivein mpv just to see how many compositor bugs it either causes or works around.
And I said exactly that 100 times. They are racing but HOW do you enable interpolation WITHOUT video-sync=display-resample ? Originally OP asked how to enable VRR and I asked how to disable it. It just spiraled beyond that.
We do not use display-resample. Obviously, interpolation should be off for VRR, though there was a proposal for a fix for that.
Understandably but once I saw interpolation smooth out the video jumps caused by oled screens, screw everything else. I want this always on.
Interpolation does not specifically require display-resample, it requires one of the display- video-sync modes, which includes other options such as display-vdrop, display-adrop, display-desync, etc. See mpv --video-sync=help for a full list. Try the ones starting with display-. I recommend trying display-vdrop, as this should act like audio but should work with interpolation, which is what you want.
Interpolation does not specifically require display-resample, it requires one of the display- video-sync modes, which includes other options such as
display-vdrop,display-adrop,display-desync, etc. Seempv --video-sync=helpfor a full list. Try the ones starting withdisplay-.
I think I already did but with so much shit I did try, I'll give it another go because I do not remember everything. Thank you for the ideas
For what it's worth, fullscreen in wayland is (probably) exclusive in most compositors. It's not a hard requirement or anything, but in wayland it is natural to implement opaque (the vast majority of stuff you open in mpv will be opaque) fullscreen surfaces as exclusive so you can then leverage direct scan-out (no composition). With direct scan-out, you of course do not want windows or other things rendering over the fullscreen state. I know sway is currently implemented like this. Most likely, GNOME and Weston work the same way. Dunno about Plasma but probably they're working on this.
tl;dr: Not sure about x11, but you basically have this in wayland because of how compositors work.
Interpolation does not specifically require display-resample, it requires one of the display- video-sync modes, which includes other options such as
display-vdrop,display-adrop,display-desync, etc. Seempv --video-sync=helpfor a full list. Try the ones starting withdisplay-. I recommend tryingdisplay-vdrop, as this should act likeaudiobut should work with interpolation, which is what you want.
OK. I need more time but video-sync=display-resample-desync OR video-sync=display-adrop seam to work. Need more testing. Going to use video-sync=display-resample-desync firth for a while.
Thank you for the suggestion!
ok. Both video-sync=display-resample-desync and video-sync=display-adrop give no video stutters but with ...desync, audio and video does really get out of sync and with adrop audio has clicks presumably because it drops audio frames.
So i am out of ideas. I just need a simple way to disable gsync with mpv and I have found none.
Any other thing i should try ?
@drujd mpv is on Mesa's default blacklist for VRR (we don't know why. No one asked).
Arch wiki link to identify the file to edit, but this is relevant for any distro: https://wiki.archlinux.org/title/Variable_refresh_rate#Remove_applications_from_Blacklist
If you remove it, then VRR will kick in in fullscreen mode. I've tested here on Intel, but all the config is the same for AMD.
https://lists.freedesktop.org/archives/mesa-dev/2018-September/205885.html Of course video players are completely unlike some "random refreshes" GUI application (in fact you could probably argue watching a movie has even more rigorous timings than gaming).
https://lists.freedesktop.org/archives/amd-gfx/2018-April/021103.html https://lists.freedesktop.org/archives/dri-devel/2018-September/189434.html https://lists.freedesktop.org/archives/dri-devel/2018-October/194899.html https://youtu.be/ajBf_b4Aw98?t=975 But for whatever the reason, I believe developers were waiting on a userspace api to expose frequency "requests". Perhaps they just implicitly lumped together every "video" use case, and thought to the prototypically windowed browser scenario. (or put in an even more simple theory, maybe it's just that they got cold feet on something that was already quite the big step)
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44 I would expect once this lands, the block may be lifted? Or maybe you could already push on them, since a lot of people still use X too (AFAIR that's still just fullscreen only, right? and as you said that's confirmed to be working)
