Display Refresh Rate possibly not correctly applied with display-resample

[FIX94]

mpv version and platform

mpv 0.19.0-git-ef2d6ed, Windows 10 x64

Reproduction steps

have a display set to a weird refresh rate (in this case around 48.426Hz) and play back a video with having display-resample set.

Expected behavior

mpv adjusting to that weird setting and playing back the video without any problems.

Actual behavior

while the estimated refresh rate is indeed correct it does have quite a few timing issues which lead to frames not being displayed on the screen, I took these screenshots as example with stats on screen without having display-fps manually set and with it set, both taken after playing a test video for a minute.
https://s4.postimg.org/l692s0rzh/pic1.png
https://s4.postimg.org/p3wchfest/pic2.png

Log files

http://sprunge.us/ifQR?txt
http://sprunge.us/LAQZ?txt

[ghost]

The vsync-jitter value would be interesting.

Are you sure mpv-stats is not causing issues? Especially when playing lower frame rate video without interpolation the tighter timing can make mpv-stats cause timing issues when enabling DS because it has less time to render text.

Using dxva2 on win 10 is not ideal.

[FIX94]

I only enabled mpv-stats for this test to see some actual values, normally I just play them back without any scripts and it still has very visible issues. Also for testing I did disable dxva2 and it made no difference for me.

[FIX94]

Just made 2 logs with dump-stats, the first one without display-fps manually set, and the second with it set.
out1.txt
out2.txt
also just for testing I've added in vsync-jitter into mpv-stats and without having display-fps set that value is around 0.011 and with it set its around 0.007.

[ghost]

http://sprunge.us/ifQR?txt
http://sprunge.us/LAQZ?txt

Which is which? You posted incomplete log files, so I can't tell.

[FIX94]

the first one is without having display-fps manually set and the second one is with having display-fps manually set, I dont know why they would be incomplete since I just sent over the full txt. also you can tell which is which, line 275 in the first one shows the display-fps and line 262 in the second one shows it too.

[ghost]

So there are two problems:

• it doesn't read the correct refresh rate from windows (although it certainly should)
• it can't cope with the incorrect refresh rate correctly (although it should, maybe)

I dont know why they would be incomplete since I just sent over the full txt.

Maybe you've put the log-file option into your config file, which actually discards some parts of the log (like version info and option parsing).

also you can tell which is which, line 275 in the first one shows the display-fps and line 262 in the second one shows it too.

Not sure what you're looking at, but these line numbers don't seem to point to anything interesting here.

[FIX94]

well windows itself only saves refresh rates as integer so the .426 part cant be read out, so that part should be done by the player, as an example if I use mpc-hc and reclock it does also start out with 48.000 but reclock quickly figures out the actual refresh rate using direct3d and adjusts the playback speed in mpc-hc to match that, which is all very similar to the behavior I see in mpv when using display-resample, with the main difference being that mpc-hc plays it back smooth after that adjustment and mpv has these frame skips every so often.

[Hrxn]

Forgive me for being dumb, but what is the point of setting your display to 48.426Hz in the first place?

What is the benefit? Given that this works at all, and I have some doubts here with your average display. How can the display electronics make sense of such unusual refresh rate inputs?

[FIX94]

well, my display can technically only do 50 and 60hz, basically I pushed down the 50hz mode as far as I could until it desyncs itself, that is just the lowest possible value I can set it to. while I doubt many people actually have odd refresh rates like this it still is something which a player should be able to sync to in my opinion, thats all.

[FIX94]

alright, I just compiled this from source with that latest commit regarding this issue and while the jitter value is around 0.050 now when I keep mpv-stats around it seems like there are no missed frames at all anymore, playback seems to go on fine.

[kevinlekiller]

@Hrxn Monitors have a limit on the horizontal and vertical sync frequencies, when you go under or over those limits they will say something like "Out of range", 48.426 is probably the lowest FIX94 can go without getting that message, and is a close multiple to 24.

On my monitor for example, the range is reported by the edid as 50-76, if I go down to about 49.5 it will show the "Out of range" message.

[ghost]

Anyway, we use an API that is supposed to return the real FPS, so that needs to be investigated. I think @rossy added that code.

[Hrxn]

Yes, I've heard about display sync frequencies and EDID, that was not really my point. Why would someone want to use such a low refresh rate at all? A close multiple of 24?
That is the usual film/cinema frame rate, I know, but what is the added benefit here?

[rossy]

Yeah, mpv uses Display Config to get the refresh rate, which supports fractional rates. I don't think the reported rates are guaranteed to be correct, though they're pretty accurate for me (eg. I had a laptop with a ~60.1Hz display and this was reported correctly.) Maybe they aren't correct for custom display modes?

[mia-0]

Can’t reproduce with current mpv. Deliberately passing the wrong refresh rate to mpv doesn’t cause much trouble either, just a few mistimed frames before it matches the estimated rate.

For the record: I have displays at 71.93 Hz and 47.89 Hz.