[FernetMenta]

Could you try a recent v17 alpha?

Done, no change.

Again, as mentioned at first, I have this problem in other media players too on Linux (when manually setting the refresh rate to 24Hz).

Could you paste the debug log from a run with v17?

[FernetMenta]

This is a NVidia issue. Without tweaking it, you won't get 23.976 but 23.971.
I don't understand how a company can be that stupid or arrogant as NVidia. This bug is around since ever and they don't fix it.

Well, displays (monitors / TVs) can only refresh at integers anyway, right?

A display can not refresh at 23,976 Hz, right? It can only display at either 23,000 Hz or 24,000 Hz, right?

So why would you want to have your NVIDIA GPU output at 23,976 Hz at all?

The only thing that would make sense would be to speed up the video from 23,976 fps to 24,000 fps and make the GPU output at 24,000 Hz, wouldn't it?

I never really got that 23,976 vs. 24,000 fps / 29,970 vs. 30,000 fps / 59,940 vs 60,000 fps stuff.

I mean, why? TVs / monitors can only refresh at integer refresh rates anyway, don't they?

You are wrong. Of course displays can refresh at 23.976 and this is certainly not bound to integer values.

[qp9013625]

You are wrong. Of course displays can refresh at 23.976 and this is certainly not bound to integer values.

And how would they do this?

They can only refresh one (integer) frame per refresh.

So, how would they refresh at 23,976 fps (Hz)?

If a display refreshes the frame is either there (1,000 frame) or it's not there (0,000 frame), but it's not 0,976 frame...

[Martijn]

You are wrong. Of course displays can refresh at 23.976 and this is certainly not bound to integer values.

And how would they do this?

They can only refresh one (integer) frame per refresh.

So, how would they refresh at 23,976 fps (Hz)?

If a display refreshes the frame is either there (1,000 frame) or it's not there (0,000 frame), but it's not 0,976 frame...

A frame doesn't need to last exactly a single second. Of course you cannot display 0,976 frame however you can absolutely define how long a single frame must be displayed.

[qp9013625]

A frame doesn't need to last exactly a single second. Of course you cannot display 0,976 frame however you can absolutely define how long a single frame must be displayed.

Okay, thanks.

Anyway, what exactly is the bug with NVIDIA GPUs?

They can not output at exactly 23,976 Hz?

So, what can they output at?

FernetMenta said they could output at 23,971 Hz.

Can they also output at 24,000 Hz?

And couldn't you just use that KODI feature which speeds up/slows down the video/audio to match the refresh rate and all would be fine?

[fritsch]

A frame doesn't need to last exactly a single second. Of course you cannot display 0,976 frame however you can absolutely define how long a single frame must be displayed.

Okay, thanks.

Anyway, what exactly is the bug with NVIDIA GPUs?

They can not output at exactly 23,976 Hz?

So, what can they output at?

FernetMenta said they could output at 23,971 Hz.

Can they also output at 24,000 Hz?

And couldn't you just use that KODI feature which speeds up/slows down the video/audio to match the refresh rate and all would be fine?

See the wiki. You just need proper modelines. This is a known nvidia issue since ever ...

[User 328513]

Please guys, let's keep the thread clean for anyone in the future who experiences the same problem and wants to read through it.

[User 328513]

Kodi 17 alpha log: http://pastebin.com/FRGHkUum

[wsnipex]

INFO: ID:0x1d1 Name:1920x1080 Refresh:23.970909 Width:1920 Height:1080
still missing a proper modeline for 23,976Hz

DEBUG: Window Manager Name: Mutter (Muffin)
still might be an issue as well

[FernetMenta]

Kodi 17 alpha log: http://pastebin.com/FRGHkUum

Thanks for the log. I requested v17 because it has reworked dropping and logging in this area. If anything went wrong at the level of Kodi, there would be something in the log. You already mentioned that it is not a Kodi issue and this does proof your assumption. Sorry that I wanted to be sure about this

Compositors have always been evil in regard to video playback and now even drivers started to get nasty. They maintain an internal queue of rendered frames and do drop frames without any notification to the application. Intel does this too, even without compositors, if options triple buffers and tearfree are enabled.

Even if playback did not show issues, those compositing window managers do harm. This additional buffering that is not reported to applications ruin a/v sync because video latency increases to an undefined value.

[fritsch]

Kodi 17 alpha log: http://pastebin.com/FRGHkUum

Thanks for the log. I requested v17 because it has reworked dropping and logging in this area. If anything went wrong at the level of Kodi, there would be something in the log. You already mentioned that it is not a Kodi issue and this does proof your assumption. Sorry that I wanted to be sure about this

Compositors have always been evil in regard to video playback and now even drivers started to get nasty. They maintain an internal queue of rendered frames and do drop frames without any notification to the application. Intel does this too, even without compositors, if options triple buffers and tearfree are enabled.

Even if playback did not show issues, those compositing window managers do harm. This additional buffering that is not reported to applications ruin a/v sync because video latency increases to an undefined value.

We bypass Mutter by setting special window property iirc. Has no influence at all?

[FernetMenta]

We bypass Mutter by setting special window property iirc. Has no influence at all?

We set only a hint that the compositing manager is not obligated to follow.

[User 328513]

Thanks. Do you know of any way I can alleviate this? Use another desktop environment with another window manager? (I'd rather not, of course; if I have to log out and back in again, I can just as well just boot into Windows where everything works. I just want to make do with as little Windows as possible.)

[fritsch]

Thanks. Do you know of any way I can alleviate this? Use another desktop environment with another window manager? (I'd rather not, of course; if I have to log out and back in again, I can just as well just boot into Windows where everything works. I just want to make do with as little Windows as possible.)

Use the xorg.conf our wiki suggests, that will help.

[SwedishGojira]

I needed to add these modelines on my PC with a GTX760.

Code:

# 1920x1080p @ 29.97Hz (EIA/CEA-861B)
ModeLine "[email protected]" 74.175 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
# 1920x1080p @ 23.976Hz (EIA/CEA-861B)
ModeLine "[email protected]" 74.175 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync
# 1920x1080p @ 24Hz (EIA/CEA-861B)
ModeLine       "1920x1080@24" 74.250 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync

I believe they are already in the recommended xorg.conf from the wiki.

But I also had to add these values to the end of the "ModeValidation" option, after "NoXServerModes":

Code:

AllowNonEdidModes, NoVertRefreshCheck, NoHorizSyncCheck

Without the "AllowNonEdidModes" Ubuntu just seem to ignore the added ModeLines completely, this is needed for it to add the ModeLines to the resolution list.

I also needed the "NoVertRefreshCheck, NoHorizSyncCheck" because somehow my TVs EDID reports incorrect values.
After I added these lines to my xorg.conf everything is working properly and no stutter.

You can see my complete xorg.conf here.