Asynchronicity 24Hz/23.98Hz for 24Hz content

[mkin1337]

Hi everyone,

I stumbled upon an issue that is bothering me for quite some time. It is the often discussed 24Hz/23.98Hz topic that is driving me crazy. I run MPV under Debian and although having set the NVidia config to 4K@24Hz (GeForce 1050Ti connected via HDMI to a JVC X7900 projector), the actual display refresh rate seems to be 23.98Hz which is perfectly fine for most of the content that is 23.98Hz but with content that is 24Hz, I get the dropped frames regularly.

My config:

audio-device=alsa/hdmi:CARD=NVidia,DEV=1
audio-spdif=ac3,eac3,dts-hd,truehd
audio-channels=7.1,5.1,stereo

profile=gpu-hq
fs=yes
video-output-levels=full
fbo-format=auto

glsl-shaders-clr
glsl-shaders="/home/player/.config/mpv/shaders/FSRCNNX_x2_8-0-4-1.glsl"
glsl-shaders-append="/home/player/.config/mpv/shaders/adaptive-sharpen.glsl"

scale=ewa_lanczossharp
dscale=ewa_lanczossharp

I read about --video-sync=display-resample but I would miss audio passthrough and I want to keep HD-Audio and 3D-Audio so that does not seem like an option for me. The dynamic tone mapping and HD-Audio is the main reason why I switched from an Apple TV to MPV on a HTPC and I am sure there is a solution somewhere out there. 😄

What options do I have? Is there a way to set the display to real 24Hz instead of 23.98Hz (or any other refresh rate to always match content)?

Appreciating any help! Thanks a lot in advance.

Important Information

Provide following Information:

• mpv version: 0.34.1
• Linux Debian version: Bookworm (Linux 5.15.0-2-amd64)
• GPU driver: NVidia 470.86 CUDA Version: 11.4

Expected behavior

No dropped frames and actually setting the display to 24p instead of 23.98p

Actual behavior

Dropped frames due to framerate mismatch between 24Hz and 23.98Hz.

Log file

Will be supplied as soon as I am at home!

Sample files

Basically every material in 24p (not 23.98p)

[haasn]

video-sync=display-resample

[pillepalle1234]

I read about --video-sync=display-resample but I would miss audio passthrough and I want to keep HD-Audio and 3D-Audio so that does not seem like an option for me.

[haasn]

Oh, I see. (My bad for missing that bit)

You could try making a custom EDID mode and seeing if your display accepts it.

[mkin1337]

I’d try that. Do you have any resources on how this could be done?

[Takehaniyasubiko]

I have an issue on Debian even when using 23.98Hz refresh rate and 23.98 FPS videos.

mpv doesn't report any dropped frames, yet I can see micro-stutter. I tried every possible config I could think of and NOTHING fixes it. VLC plays the same files perfectly, so I know it's not my hardware. It's driving me crazy because this is the only thing stopping me from using mpv.

The opening of AKIRA is a perfect test for this behavior. On VLC, the camera moves with no stutter whatsoever. On mpv, it will always micro-stutter at least two times before the blast scene. This is happening despite mpv reporting 0 dropped frames.

[LaserEyess]

@makinitright could you try --video-sync=display-vdrop and ensure --video-sync-max-video-change=1? That should do two things:

1. Work like --video-sync=audio in terms of keeping audio in sync so passthrough will (should?) still work
2. Allow dynamically retiming 23.976 fps content to 24 fps and vice versa

[mkin1337]

@makinitright could you try --video-sync=display-vdrop and ensure --video-sync-max-video-change=1? That should do two things:

1. Work like --video-sync=audio in terms of keeping audio in sync so passthrough will (should?) still work
2. Allow dynamically retiming 23.976 fps content to 24 fps and vice versa

Thanks for the input. I tried that and it did not help. What’s interesting though is that when trying it with the resample flag it still happens but audio Passthrough remains functional. I assume that the audio part in the config somehow disabled the resample parameter?

First screenshot is your settings and second one is from resample (or not).

[LaserEyess]

Well nevermind then. No idea how the passthrough code works so maybe it has to do a lot of dumb things to make A/V receivers happy. Because, in general, they tend to be garbage and frail.

Another stupid idea: speed=0.9990009990009991 (1 / 1.001)

[mkin1337]

I'd rather try to modify the EDID. Acquiring it (.bin/ASCII) is not an issue. I just have to find out how to modify and activate it afterwards.

[aufkrawall]

If you got a Windows system at hand, you can use Custom Resolution Utility for that. It can save the adjusted EDID binary, which can be used anywhere. CRU can estimate actual refresh rate when changing timings etc., should make life a lot easier for cases like this (if you want to make your life hard by not using display-resample ;) ).

[mkin1337]

So I could edit the EDID with CRU and then "import" it on my Debian system again, you say?

[aufkrawall]

So I could edit the EDID with CRU and then "import" it on my Debian system again, you say?

Yes. With FOSS drivers you could also simply add a new custom modeline resolution for Xorg, but of course this doesn't work with the proprietary Nvidia driver (at least it never did so for me).

With it, you gotta add e.g.

Section "Device"
Option         "CustomEDID" "HDMI-1:/usr/lib/firmware/edid/2560x1440_24.bin"
EndSection

to the Xorg config.

Though if you're unlucky, the driver won't ever let you hit 23.976Hz well enough regardless.

[bugrepo]

--vf=lavfi=[fps=24]

[bugrepo]

Or, if you need 23.976 fps, then --vf=lavfi=[fps=23.976]

[kokoko3k]

If, for whatever reason you are unable to use another mode, you can consider:

1. re-encode the audio on the fly to 640kbps ac3 and sent it to hdmi. That way you will have 5.1 channels (are enough?) and the ability to change the speed of the stream.
   --af lavcac3enc=bitrate=640
2. use --video-sync=display-adrop
   Not tested lately, but it was compatible with spdif passthrough:
   On the deprecation of video-sync=display-adrop and audio passthrough. #7400

[Dudemanguy]

Is this solved by --video-sync=tempo? I don't know how the passthrough stuff works.

[MaKin211]

@aufkrawall

If you got a Windows system at hand, you can use Custom Resolution Utility for that. It can save the adjusted EDID binary, which can be used anywhere. CRU can estimate actual refresh rate when changing timings etc., should make life a lot easier for cases like this (if you want to make your life hard by not using display-resample ;) ).

It's been a while but I wanted to tackle the issue again and try your suggestion. This is what CRU presents re resolutions.

And the resolution extension block. As you can see there, 24 Hz is already available. This does translate to 23.98Hz though at least in Linux, so how can I make clear that there is a difference between these resolutions?

This is what I can select from the drivers menu on Windows:

I am aware of the fact that the displays native resolution is 1920x1080p which makes "just adding the modeline" very difficult. Can you guide me through the process? I do not want to give up yet. :(