Windows 11 stuttering ?

[AuRiMaS666]

This sounds exactly like the HAGS issue that was introduced by 24H2 update in late 2024. Before, even with HAGS on, video playback was fine, but immediately after upgrading issue presented itself in both madVR and MPCVR.

[kirakami]

The only way fix judder on panning shots and slideshow motion in low fps videos currently if you have High Hertz Monitor is using Motion Interpolation.
Try enabling AMD Fluid Motion Frames or Nvidia Smooth Motion.
In MPC-BE, enable Exclusive Fullscreen in MPC Video Renderer.
In MPV, you need to add gpu-context=winvk vo=gpu-next gpu-api=vulkan hwdec=vulkan to mpv.conf and then add mpv.exe to Nvidia App to enable Smooth Motion or to AMD App to enable Fluid Motion Frames.
Same with adding mpc-be64.exe to Nvidia or AMD App.
That's how i fixed it in my case.

[pirlouy]

@AuRiMaS666: Too bad you did not see my thread quicker, it would have helped me finding the cause ! :p
The worst part is that I've tried every settings, including this one, but it looks like I've overlooked it. Now it won't be enabled for the rest of my life !

@kirakami: Just to be clear, when I created this thread, it was to confirm that with Windows 11, if you don't have the video framerate identical to monitor frequency, then you'll have stuttering. Especially visible with half fps.

The issue you describe seems to be the infamous panning shots judder inherent to 24 fps video. And that is not linked at all to Windows 11.
For AMD Fluid motion, I did not hear good stuff about it, but theoretically it should also works with DirectX, no ?
For nVidia solution, I did not know people were using it. I though they used svp for that.

[pirlouy]

Now that you mentioned it, I've read a bit and it appears AMD Fluid motion has just been integrated in mpv.
To test it easily, use latest nightly and just this setting:
vf=amf_frc

Or you can enable/disable it with a shortcut in input.conf for comparison:
F10 vf toggle amf_frc

You'll have soap-opera effect with occasional artefacts inherent to frame generation. Some will like it, some will headbutt their monitor.

https://mpv.io/manual/master/#video-filters-amf-frc

[huhn]

i already recorded smoothmotion.

it is typical nvidia quality:
https://drive.google.com/file/d/1arhPLG8QFLKw4qgRCI9034F-LZrmw1mD/view?usp=drive_link

this is 24 to 48 (smoothmotion can't do anything else like you know 24 to 120) in 144 cause judder. so on many system this will create judder not remove it. so every 3 frame is different the quality speaks for it self.

BTW. it needs HAGS like many stuff in the future will.
and nvidia blocked it for mpc-hc and there is a reason for that.

i can do amd trash next if you want.

[pirlouy]

Just to be sure, when we speak of smoothmotion, I tend to think about madVR version (the frame created is "2 frames with blur"), so I prefer to speak of "frame generation" when the frame generated is totally new, calculated between 2 frames around.

With 144 Hz, since it's a matching refresh rate, you should not have judder. But remember with Windows 11, you have to display 144 fps in order not to have judder. Have you tried with mpv and "display-resample" ?
In my case, I've tried with a 165 hz monitor, so no matching refresh rate, but with mpv "display-resample" and mpv interpolation, I don't notice judder.

Here are the parameters I've found on the web for interpolation (I guess it comes from Haasn originally):
video-sync=display-resample
interpolation=yes
tscale=sphinx
tscale-blur=0.6991556596428412

[huhn]

the mpv amd frc documentation is wrong for the moment it said --hwdec=d3d11 >or< --vf-pre=format=d3d11 . it needs hwdec=d3d11va so this took me way to long again to get something simple to work. this is a massive limitation if hardware decoding is necessary!

mpv sells an option like smooth motion it even nick names it the same but it doesn't have it. what you are doing is not the same but more like convertfps in avisynth both technically fix judder so...
i'm testing real frame interpolation here not frame rate mismatch fixes like smoothmotion.

the nvidia test was done using mpcVR which usually just works the nvidia frame interpolation/creation thing or what ever you want to name it is horrifically bad at it's job and doubles the frame rate that why i needed to use 144 HZ because at 120 i would have gotten judder cause not 24 to 120 like even SVP can do for like ever. this is just more and more "AI" slob. i mean you can look at the frames would you really call that frame creation and not mix two frames and mess it up?

the amd thing does exactly the same 24->48 so judder on most setups... on a first view it is just a mess asking for an image stabiliser. cause it is 48 again i have to change refreshrate and setup the recoding software...

i record these things lossless having frame blending in there is very counter productive these video are there to look at the frames individual and to make fun of them because every single frame they produce is trash.


edit: it will not work with madVR because madVR in d3d11 always outputs the display frame rate no matter what so that is doubled.

[pirlouy]

Why would you not use d3d11va on Windows 10/11 ?
It's the default if you use hwdec=auto. Or you don't use hardware decoding at all ? I though it was working well with d3d11va (contrary to DXVA).

I'm aware of mpv SmoothMotion not being the same as madVR (I had an issue closed for this on their tracker), that's why I prefer to keep the term "SmoothMotion" to madVR, and not frame generation, or mpv interpolation or svp etc.

If you use mpcVR, you will have the judder explained at the beginning of this thread. You need to present a frame for each Vsync, that's not what mpcVR does.
In you recently uploaded video, I noticed the judder, but if I play your original video, with mpv and display-resample, even if it's not madVR smoothmotion, I have a frame for each Vsync and then I don't notice judder.

Not to say AMD FRC is good, because on judder test videos, there are plenty of artefacts, but for those who like soap-opera effect, I'm not sure they will complain about such artefacts.

[v0lt]

You need to present a frame for each Vsync, that's not what mpcVR does.
And when the renderer drops Vsync, you see black frames? :eek:

IMHO, you are writing nonsense.

[pirlouy]

I'm sure you're right and I am writing nonsense. I have limited vocabulary and my knowledge is far from yours.

But despite this, I know that I have judder with mpcVR because the "framerate presented" is the one from the video (60 fps for example), whereas with mpv for the same video it will be 120 fps (with display-resample option), if the monitor is in 120 Hz.

And Windows handles 60 fps on 120 Hz badly. It was what I was trying to understand at the beginning of this thread.

[huhn]

And when the renderer drops Vsync, you see black frames? :eek:

IMHO, you are writing nonsense.

not what he meant and that's sadly an issue with "mpcVR".

if you are not presenting a frame for every vsync windows 11 MAY present them out of order creating judder in the process. this is a windows bug not an mpcVR bug but as usually software has to fix that.

if i have a very accurate frame rate match mpcVR works flawless on my system with vblank setting at 120 HZ. with a slight difference you already read the issue and no changing that setting isn't going to fix that.

for madVR to avoid these issues we literally starting to do very wired stuff... it turns into a religion at this point everything to please the windows 11 DWM devil.

Why would you not use d3d11va on Windows 10/11 ?
It's the default if you use hwdec=auto. Or you don't use hardware decoding at all ? I though it was working well with d3d11va (contrary to DXVA).

I'm aware of mpv SmoothMotion not being the same as madVR (I had an issue closed for this on their tracker), that's why I prefer to keep the term "SmoothMotion" to madVR, and not frame generation, or mpv interpolation or svp etc.

If you use mpcVR, you will have the judder explained at the beginning of this thread. You need to present a frame for each Vsync, that's not what mpcVR does.
In you recently uploaded video, I noticed the judder, but if I play your original video, with mpv and display-resample, even if it's not madVR smoothmotion, I have a frame for each Vsync and then I don't notice judder.

Not to say AMD FRC is good, because on judder test videos, there are plenty of artefacts, but for those who like soap-opera effect, I'm not sure they will complain about such artefacts.

the problem is mpv is made to fail as hard as possible.
i couldn't make worse default setting if i wanted to.

if a file tells mpv i'm interlaced it will be default ignore that.
if you play a file hardware decoder are ignored by default.

i used a blank config in the hope nothing breaks and well as usually it breaks and follow the error messages to debug you are still doomed.

mpv is that utterly terrible it can not do a grey scale correctly and a bug report will just be close while hassn already confirmed that there is an color issue of some kind... this is then ignored for so long until the ticket creator gives up...
maybe they fixed that... i doubt that.

they up to this day use a buffered key to open the info screen making the next thing you type wrong. let me make you an example i open the debug console now`and that's the result a random `in the next place you type. having this as default behaviour forever breaks me...you can write an è (which result in a mess cause the forum can not handle it that'S an e with ` on top) have fun debugging ffmpeg with that in there. how often did i add that after checking the config and immediately fixing it.

mpcVR does all of this correctly out of the box.
it doesn't ignore interlace flags and it can also place Chroma correctly unlike madVR.

here is an video of AMD FRC took me over an hour cause OBS is bugged followed by ffmpeg with a similar bug and a bug in x264.

obs is currently bugged again to use normal x264 when you select libx264rgb and ignores colormatrix=gbr
so i had to reencode it get that back in there.
ffmpeg told me colormatrix is not an argument and so is fullrange on

so x264 it is which also told me fullrange is not an argument
--fullrange <string> Specify full range samples setting ["off"]
- off, on
you too my bro so x264.exe --output chargerrgb.mkv --colormatrix GBR --range PC --crf 0 --preset placebo --output-csp i444 "2026-01-06 10-29-42.mkv" to get the RGB flag in there... which obviously is GBR what else...

because obs had to ignore colormatrix plus the RGB encoder and encode RGB as yuv444p as you do...

FUN

here you go:
https://drive.google.com/file/d/1WWiMKnDSn23KQRzjaIt8zXF5mTD5FYID/view?usp=sharing

yes it is short because i recorded many many GB until i gave up on obs doing it correctly and fixing it in post.

[pirlouy]

Ah, default mpv options, it is a complicated subject.
https://mpv.io/manual/master/#options-hwdec
Hardware decoding is not enabled by default, to keep the out-of-the-box configuration as reliable as possible
There is also a big paragraph to explain some risks (a bit lower in the doc):
If you run into any weird decoding issues, frame glitches or discoloration, and you have --hwdec turned on, the first thing you should try is disabling it.

For deinterlacing, another complex subject.
How to choose between software or hardware decoding ?
https://mpv.io/manual/master/#options-deinterlace
Because of false positive, they chose not to enable software deinterlacing. But that's good for those with decent GPU, they can use hardware deinterlacing instead. Also as you pointed out in the past, you are not convinced by GPU deinterlacing solution.
So it is a user choice to enable it, by software or hardware.

By default, I don't enable it, I prefer to use a hotkey instead (hardware decoding):
t vf toggle "d3d11vpp=deint=yes:interlaced-only=yes"

For chroma misalignment, fortunately, it is not something I can perceive (or understand).

And for your final video, I don't see that much judder. At least, I don't see it like I was noticing it with your nVidia video.

[huhn]

Ah, default mpv options, it is a complicated subject.
https://mpv.io/manual/master/#options-hwdec[quote]
just nonesense hardware decoding is sued everywhere by default there reasoning is outdated at best. they also have fallback if it fails so...

[QUOTE]For deinterlacing, another complex subject.
How to choose between software or hardware decoding ?
https://mpv.io/manual/master/#options-deinterlace
Because of false positive, they chose not to enable software deinterlacing. But that's good for those with decent GPU, they can use hardware deinterlacing instead. Also as you pointed out in the past, you are not convinced by GPU deinterlacing solution.
So it is a user choice to enable it, by software or hardware.

it is not complicated at all they just made it complicated.
if a file says it is interlaced you deinterlace. what deinterlacer is used is not important here cause interlaced content isn't watchable without deint the option should be to disable it not to enable. like any settop box any TV any other video player anything.

lavfilter/mpc internal code have this mastered for decades.
if you give lavfilter a soft tleecien DVD it will output progressive if you use a hardware decoder that decoder may turn that to hard telecine likely the spec defines.
By default, I don't enable it, I prefer to use a hotkey instead (hardware decoding):
t vf toggle "d3d11vpp=deint=yes:interlaced-only=yes"
then this AMD FRC will not work and be disabled at start up.

i also have no problem that you can disable that. my problem was it that OR while it is clearly needed. i was literally looking for newer GPU driver...
And for your final video, I don't see that much judder. At least, I don't see it like I was noticing it with your nVidia video.

yeah they are quite different the palms a flickering like crazy in the AMD case and the nvidia case is just terrible all around there is nothing good to say about it it is clearly not made for that.