VideoRenderer
VideoRenderer copied to clipboard
Aleksoid1978
Deinterlacing not working well on high frequency displays (144 Hz)
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.
Developers don't have screen with high refresh rate and can't test/debug. On 60 Hz all is perfect.
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.
@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... )
@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 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.
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.
@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.
Have you tried with Direct3D11 in MPCVR? You can also try deinterlacing with LAV Video Decoder, to see if that gives better results.
@clsid2 It is enabled by default in klite cp and I don't use LAV for deinterlacing.
The whole point of those suggestions are to compare with different settings, to see if that makes any difference in behavior of MPCVR.
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. :)
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.
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.
Can confirm MPCVR is unsmooth on 144hz display. Changed to EVR and everthing's fine.
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?
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.
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?
Stupid question: Why don't you auto-switch to 120Hz for i60 content anyway? Or is anything wrong with i60 at 120Hz as well?
@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...
So what you're saying is, the frametime graph looks smooth on your end with interlaced content, yet it still feels janky to you?
@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:
@zhallgato okay, yeah, that looks like what I expected and experienced on my own system. Would you mind testing this build out and seeing how interlaced content feels: https://github.com/JTGaming/VideoRenderer/releases/tag/0.7.1v6
It should be auto-enabled, but just double check that "Frame Synchronization" is on in MPC VR settings (you can also use this to quickly toggle between having the fix on or off, which might help to compare).
NOTE: you might want to take a screenshot of your current settings, as my build has some UI changes. It shouldn't mess with stuff if you already have a profile, but if you press the 'default' button then it will be different.
@JTGaming I tested the build, and I can confirm the issue is fixed.
The interlaced content playback is perfectly smooth on 240 Hz.
@JTGaming it seems to work! Can you create a pull request with the fix? So it can finally be fixed on the main repo
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.
@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.