vo: add --display-fps-limiter option #14625
Conversation
This is questionable but something like this has been commonly requested over the years. Using any display-* mode will make mpv render at the monitor's maximum refresh rate. This is correct given what the modes are supposed to do, but nowadays people have super high refresh rate monitors which means mpv can be rendering at 240fps or something crazy high. One could make a custom modeline or just use the default audio sync mode, but it might be nice to add in the ability to have an artificial limiter on the frame rate. The --display-fps-override option already exists to set a specific fps. All that is missing is a flag to use that number as a hard cap. Fixes mpv-player#11122.
Dudemanguy
force-pushed
the
display-fps-limiter
branch
from
13d3902
to
798cdd3
Compare
|
Download the artifacts for this pull request: |
This is already the case though? I'm not sure what this PR is doing. You can already use the display-fps-override option to achieve this |
|
I guess I should be more clear with the wording/naming here. This is like a generic |
|
I get the intention but I don't think this works as intended. With |
| int64_t forced_wait = 0; | ||
| if (vo->opts->display_fps_limiter && VS_IS_DISP(vo->opts->video_sync)) { | ||
| forced_wait = now + in->nominal_vsync_interval; | ||
| wait_until(vo, forced_wait); |
There was a problem hiding this comment.
I don't think this is useful. Aside from the inaccuracy of timing with system clock (which display-* modes try to avoid), nominal vsync interval rarely matches the real vsync interval in my experience. Combining these two means that this will pretty much cause stuttering, negating the major benefit of display-* modes.
|
I think for this to work, we'll need to make a lot of assumptions about the display and the media. I think we'll need an option to let the users specify the lower end of the VRR range of their displays, or detect it somehow. Then automatically set edit: I implemented that locally and I still can't say it's better than just video-sync=audio + VRR |
| int64_t forced_wait = 0; | ||
| if (vo->opts->display_fps_limiter && VS_IS_DISP(vo->opts->video_sync)) { | ||
| forced_wait = now + in->nominal_vsync_interval; | ||
| wait_until(vo, forced_wait); |
There was a problem hiding this comment.
I think you wanted to sleep before flip page. Also this will not be synchronized with vsync, so we will miss vsync points, causing stuttering, not sure how it solves things.
|
In theory this should be at least equivalent to audio mode with VRR in terms of presentation (e.g. it should be a consistent targets fps that is constantly rendered). If it's not, I'm not sure what can be done. |
On my end, it seems to be about the same as using
--opengl-swapinterval=2+--display-fps-override=30. But people with better monitors should test to make sure it actually works. Also, I'm pretty sure using this breaks interpolation so that's a gap item as well.