Deinterlacing not working well on high frequency displays (144 Hz)

[bobdig]

I am a user of MPC-HC and one gripe I have with the now default MPC Video Renderer is how unsmooth the deinterlacing is still looking. I "tested" this with a nvidia 1060 and 3060 mobile on a 144 Hz Screen (monitor and laptop). The result is always the same, with EVR(CP) it is much smoother. I wish we could get some progress with that.

[Aleksoid1978]

Developers don't have screen with high refresh rate and can't test/debug. On 60 Hz all is perfect.

[bobdig]

see further down

[clsid2]

Are those extra frames different, or just repeats?

Playing 50 fps at 144 Hz means that 44 of those frames are displayed 3 times, and 6 frames 2 times.

[bobdig]

@clsid2 Those extra frames are different, hence the better visuals. But I haven't counting frames because of my bad math skills, the many double and triple frames and the method in the first place (capturing with windows xbox bar, which says it is doing max. 60, when doing in fact 72 of a i50 source... )

[bobdig]

@clsid2 Your question made me test something again.
I searched for such an extra frame and I found it in MPCVR 60 Hz, EVR(CP) 144 Hz but not in MPCVR 144 Hz (haven't searched in EVR(CP) 60 Hz)
So that is probably explaining it, there must be some bug in MPCVR that deinterlacing with 144 Hz is worse then with 60 Hz!!

[clsid2]

Can you also test with madvr?

[bobdig]

@clsid2 I never use madvr and I have not installed it.

[clsid2]

Can you upload the two 144Hz recordings?

[bobdig]

@clsid2 I could but the problem is probably something hard coded or a bad divider, making 144 looking worse then 60.
And those recordings are janky as it gets, it is really no fun comparing them but I am working on it.

[clsid2]

If you can see any pattern on how frames are repeated in both recordings, then that might give a clue about what is happening and what is different.

[bobdig]

@clsid2 Those recordings have different time stamps so it is really no fun. Also you can't look at those colored blocks because they are added artificially, you have to look at the presenters movements. There you can see, that some frames are missing in MPCVR 144. There is also one glitch at the end, but that was in the original file.
Here is a Link, pw is my username here.

[clsid2]

Have you tried with Direct3D11 in MPCVR?
You can also try deinterlacing with LAV Video Decoder, to see if that gives better results.

[bobdig]

@clsid2 It is enabled by default in klite cp and I don't use LAV for deinterlacing.

[clsid2]

The whole point of those suggestions are to compare with different settings, to see if that makes any difference in behavior of MPCVR.

[bobdig]

I can watch it several times and I hope my feelings won't be wrong, but I have enough of frame peeping one by one. :)

[v0lt]

I previously wrote that deinterlacing will not work well in MPC VR on high frequency displays. You have checked and confirmed this. Thank you.

In the first post, you didn't specify the version of MPC VR. I will ignore such bug reports in the future.

[bobdig]

It is a persistent problem. I am user of the klite codec pack, so the version on my system of today is: MPC Video Renderer 0.5.7.1812 (git-2022.01.10-7488a3c) x64.

[eebssk1]

Can confirm MPCVR is unsmooth on 144hz display. Changed to EVR and everthing's fine.

[NBruderman]

I actually have a 144Hrz sceen, and recently I thought about switching from MadVR TO MPCVR, but should I do it?
Is this a major issue in day to day viewing experience?

[v0lt]

Is this a major issue in day to day viewing experience?

We do not have the ability and desire to watch your video on your display.

[JTGaming]

Is this the bug you are referring to?
Where, when enabling the 'double the frame rate when deinterlacing' option (which is enabled by default), the frametimes fluctuate wildly and aren't being presented in a steady fashion?

If yes, could you try turning that feature off and seeing if that at least helps somewhat? Also, could you provide some screenshots of the debug screen (like the one above) when the issue is occurring?

[janos666]

Stupid question: Why don't you auto-switch to 120Hz for i60 content anyway? Or is anything wrong with i60 at 120Hz as well?

[bobdig]

@janos666 @JTGaming It has nothing to do with 144Hz, the problem occurs with everything above 60 Hz.
I can't see it in the graphs, I see it on the screen. If you don't double the frame rate then it is really bad in general, so it doesn't make sense your asking about this...

[JTGaming]

So what you're saying is, the frametime graph looks smooth on your end with interlaced content, yet it still feels janky to you?

[zhallgato]

@JTGaming I also have this issue with a 240Hz monitor.

Here is the screenshot of the debug screen when this issue occurs to me on 240Hz:

If I disable the 'double the frame rate when deinterlacing' option, then it looks like this:

This helps with the issue, because there are no spikes, but the overall experience is not smooth, because there is less frames as @bobdig already mentioned.

Also if I switch back to 60Hz the graph looks okay again and the playback is smooth:

[JTGaming]

That's good to hear. If anyone else would like to test it out themselves, please report back your findings here (preferably with screenshots of the frametime graph).

I'll try and submit a PR sometime later when I am free to get this fixed and into the hands of everyone.

[bobdig]

@JTGaming Thank you, I can confirm, this is fixed for me with your version too.
One thing I like to mention about the graphs, when I was using EVR (CP), the line also looks noisy to me but maybe the scaling is different, idk.

@clsid2 I really would like to see this fix in the klite codec pack.

[Aleksoid1978]

Trying this build.
MpcVideoRenderer-0.7.2.2195_git2024.02.15-192e205.zip

[bobdig]

Trying this build. MpcVideoRenderer-0.7.2.2195_git2024.02.15-192e205.zip

L̶o̶o̶k̶i̶n̶g̶ ̶g̶o̶o̶d̶ ̶t̶o̶ ̶m̶e̶,̶ ̶t̶h̶a̶n̶k̶ ̶y̶o̶u̶.̶

[Aleksoid1978]

Trying this build. MpcVideoRenderer-0.7.2.2195_git2024.02.15-192e205.zip

Looking good to me, thank you.

How does it compare to the version from JTGaming?

[Aleksoid1978]

Another build with very small difference
MpcVideoRenderer-0.7.2.2195_git2024.02.15-192e205-2.zip

[bobdig]

How does it compare to the version from JTGaming?

Looks like I was to quick, not so good. Although I make my comparison mostly to the EVR CP.

[Aleksoid1978]

What's bad ? What's compare ?

[bobdig]

What's bad ? What's compare ?

Still not fixed with this one. But I used your "(Un)install_MPCVR_**.cmd" Now I have problems "installing" JTGaming ones. Will have to do a clean install of klite now.

[Aleksoid1978]

Why uninstall ? Replace files from archive.

[Aleksoid1978]

Another version
MpcVideoRenderer-0.7.2.2195_git2024.02.15-192e205-3.zip

[bobdig]

Another version MpcVideoRenderer-0.7.2.2195_git2024.02.15-192e205-3.zip

It does create a flat line but it doesn't is as fluid as EVR CP or the fix from JTGaming. But I am getting tired of testing this at this point. Also I don't have good source to test this, I only use interlaced video I have laying around.

[zhallgato]

@Aleksoid1978

I also tested the third version, and here are my results:

It looks much better than the original master version, but not as smooth as @JTGaming version.

Also I got sometimes a spike in the graph which resulted in some stuttering:

[bobdig]

but not as smooth as @JTGaming version.

@zhallgato Do you have a favorite, JTGaming version or EVR CP? Maybe we can have a discussion @JTGaming but I can not open an "issue" there. It would be nice to solve this problem once and for all in the best way possible.

[Aleksoid1978]

MpcVideoRenderer-0.7.2.2195_git2024.02.15-192e205-4.zip

[NBruderman]

but not as smooth as @JTGaming version.

@zhallgato Do you have a favorite, JTGaming version or EVR CP? Maybe we can have a discussion @JTGaming but I can not open an "issue" there. It would be nice to solve this problem once and for all in the best way possible.

@JTGaming said in their PR that the solution he posted to here covers around 90% of the problem, as he wanted to keep the code simple, because the one he implemented in his fork is much more complicated, and covers more edge cases. Maybe it's worth using a more comprehensive solution here too, in order to end this issue once and for all.

[zhallgato]

Do you have a favorite, JTGaming version or EVR CP?

@bobdig Sorry, but I don't use EVR CP. I use MPCVR for everything except for the interlaced content, because of the above-mentioned issue.
For the interlaced content I use madvr, because that looked the best option for me until yesterday.

But after testing JTGaming version I think I will be able to switch to MPCVR entirely, because it looked to me as smooth as madvr.

@Aleksoid1978

The fourth version looks better than the third, there are no spikes:

[Aleksoid1978]

Why use look at graph, test without and watch video.

[zhallgato]

I test it without it and just simply watch the video. :)

But JTGaming asked the graph before, so I thought it is useful for you if I keep posting it. (but I won't do it anymore then)

So as I said before the fourth version looks good enough, I don't see too much difference compared to JTGaming version (it feels like JTGaming version is still a little bit smoother, but maybe I'm just imagining it)

[JTGaming]

Weirdly enough, on my slower laptop the fourth version seems to be behaving less ideally.
It seems like not all frames are being synced correctly, some staying on the screen for a frame longer than they should.

[v0lt]

If you have not enabled WaitForVBlank, then the graph most likely does not show small frame jitters.
If you enable WaitForVBlank, the graph will be closer to reality, but users are scared of the sawtooth graph.

The most reliable way to understand whether there is a problem is to see it yourself without displaying statistics on a suitable video. It also makes sense to compare with WaitForVBlank disabled and enabled.

[Aleksoid1978]

"Final" version.
MpcVideoRenderer-0.7.2.2195_git2024.02.15-192e205-5.zip

[JTGaming]

Seems fine enough from my testing.
I'm guessing you're doing the waiting inside the Render() function itself, right before the call to Present()?
Interested to see the code once you push your commit.

[Aleksoid1978]

Yes - calculate diff and sleep if need just before call present().

[NBruderman]

@JTGaming the commit is out
a2fb8ea

[JTGaming]

Seems like the issue is finally fixed.
If anyone would like to double-check and confirm that, then this issue could finally be closed.

[zhallgato]

I double-checked, and I can also confirm that the problem is fixed. This issue can be closed.

[v0lt]

I made a slightly modified version.
mpcvr-0.7.2.2207_minimizing_sleep_calls_1.zip
This version will not call Sleep if there is less than half of the display refresh interval left before presentation time.