Quote:
Originally Posted by truexfan81
|
I can reproduce it. It should be fixed in the next build.
Quote:
Originally Posted by mark0077
Is there any way that you can think of, of figuring out from the audio clock deviation and display rate, a playback rate that should produce no drops?
|
The key problem is that the audio clock is very jittery, which makes it hard to measure the exact audio clock deviation correctly. If we knew the exact audio clock deviation, calculating the "perfect" refresh rate would be easy.
Quote:
Originally Posted by Jong
Whilst this might be true on any given day, I'd be concerned that to the very high accuracy we are talking about here it would deviate over weeks/months/years and need constant recalibration.
|
Maybe you're right, but I'm not sure. I don't know if hardware clocks drift (in any meaningful way) over weeks/months/years, when configured the same way.
Quote:
Originally Posted by glc650
Almost all of the 23/24 fps content I play is actually 23.976. Should I still be aiming for 24Hz? My TV/video card can do both 23.976 (madVR reports 23.977) and 24.000 (madVR reports 24.001). So what I've been doing is using madVR's display mode switcher to switch to either 23 or 24 based on the fps of the media.
|
Switching between 23.976 and 24.000 depending on the fps of the media is perfectly fine. When I say "24.000/1.001" then that's the proper way to calculate the 23.976 refresh rate. 23.976 is not actually correct. It's 24.000/1.001 = 23.976023976[...]. But again, we have to take audio/video clock deviation into account, too.
Quote:
Originally Posted by glc650
Sorry I was just wondering what the alternative was to madVR's own IVTC. I figured it wouldn't be as good as madVR's implementation.
|
When using native DXVA decoding, there is no good alternative. I might eventually move madVR's IVTC algorithm to the GPU sooner or later, then it will also work together with native DXVA decoding. But that's future talk...