madVR - high quality video renderer (GPU assisted)

[huhn]

Originally Posted by ionutm80

ReClock is only possible in x86 chain where indeed it allows me to have 1 frame drop every 4.xy hours, however I'm using everything in x64 ...

I know about smooth motion but that is frame blending and not frame interpolation. I kinda like SVP effect but this is a matter of taste.

My question towards more skilled people here is how close NVidia can be to 59.94? Because for me is 59.937. If I force everything at 1080p60 only in madVR I get 59.974 so I'm either below or above the target of 59.94. With Intel HD4400 I'm close to perfection 59.94006.

getting close to 59.94 is a waste of time you are still off to the audio clock.

if you want to stop repeating/dropping frames you have to match the audio clock.

the reason why intel has a "perfect" clock comes most likely from sharing the system clock with the video clock so they may have the same clock generator.

in the end it doesn't matter if the audio clock is different.

there are 3 clock in a system (maybe a lot more).
the system clock, the video clock and the audio clock.
the system clock is not really important in this case.

the clock deviation in madVR is important not the shown HZ.

Damn, the new De-Ringer is quite heavy on my GPU. I had to lower SuperRes to 1 in both Image Refinement and in Chroma Upscaling for 21:9 content when using NNEDI3 Image Doubling. Still, I think it is worth it. I assume these specific ringing stuff in mostly in older films that were upscaled from SD to HD?

[ionutm80]

Originally Posted by huhn

getting close to 59.94 is a waste of time you are still off to the audio clock.
if you want to stop repeating/dropping frames you have to match the audio clock.

Originally Posted by Razoola

Although reclock will make madvr report a better framedrop interval the value reported by madVR becomes invalid because reclock is constantly adjusting the audio so the framedrop never actually happens. Pity you are using x64, I keep 32bit just for reclock.

Ok, thanks for clarifying ... in fact what you both are saying is that w/o ReClock (only possible on x86 chain) I have no chance of having an accurate playback of 23.976 material on 60Hz screen even if I try to interpolate frames with SVP as close as possible to video clock because audio clock will not be synchronized, isn't it?
Are there any other methods except ReClock that would allow me to match the audio clock and still use everything in x64?

[huhn]

Originally Posted by ionutm80

Ok, thanks for clarifying ... in fact what you both are saying is that w/o ReClock (only possible on x86 chain) I have no chance of having an accurate playback of 23.976 material on 60Hz screen even if I try to interpolate frames with SVP as close as possible to video clock because audio clock will not be synchronized, isn't it?
Are there any other methods except ReClock that would allow me to match the audio clock and still use everything in x64?

creating an custom resolution that is close to the audio clock.

madVR smoothmotion will take care of this too.

the sanear audio renderer has a planned feature like reclock.

[ionutm80]

Originally Posted by huhn

the sanear audio renderer has a planned feature like reclock.

Isn't this the backend for MPC-HC Internal Audio Renderer?

[huhn]

Originally Posted by ionutm80

Isn't this the backend for MPC-HC Internal Audio Renderer?

it is the new internal audio renderer in MPC-HC.
but this is a planned feature it is not implemented yet.

[Werewolfy]

Originally Posted by madshi

Oh well, I suppose I'll have to check where the artifact is coming from. Maybe I can fix it. I don't think modifying the thresholds it very promising. Maybe as a last resort, if everything else fails. But I'd much prefer not having a strength setting. The visible difference would be very small and users wouldn't know which setting to use.

It would be great if you can get rid of this kind of artifact This issue happens each times a character smiles in this video.

[Stereodude]

Originally Posted by huhn

if you want to stop repeating/dropping frames you have to match the audio clock.

the reason why intel has a "perfect" clock comes most likely from sharing the system clock with the video clock so they may have the same clock generator.

in the end it doesn't matter if the audio clock is different.

The R9 380 in my HTPC outputs the /1.001 framerates very accurately. I effectively don't get dropped or repeated frames from that. madVR generally shows somewhere >4 hours for the time per drop/repeat. It drifts around a little, but I don't have any issues. So, it's not just Intel.

[ionutm80]

Originally Posted by Stereodude

The R9 380 in my HTPC outputs the /1.001 framerates very accurately. I effectively don't get dropped or repeated frames from that. madVR generally shows somewhere >4 hours for the time per drop/repeat. It drifts around a little, but I don't have any issues. So, it's not just Intel.

Then only the green team has a problem in achieving a very accurate clock ???

[huhn]

Originally Posted by Stereodude

The R9 380 in my HTPC outputs the /1.001 framerates very accurately. I effectively don't get dropped or repeated frames from that. madVR generally shows somewhere >4 hours for the time per drop/repeat. It drifts around a little, but I don't have any issues. So, it's not just Intel.

this is luck because the audio clock can be totally different from system to system.

my r9 270 has an pretty good looking clock too but it doesn't match the audio clock what so ever.

[DragonQ]

Originally Posted by madshi

When that happens, simply drag & drop the new ID entry of the newly detected display to the original display. Afterwards you can remove the empty shell of the new display.

Thanks, I've done that for all 3 detected display IDs. We'll see if it happens again.

[Warner306]

Originally Posted by Betroz

@madshi, is there a way to compare super-xbr to NNEDI3 settings? Like super-xbr 100 gives the same image quality as NNEDI3 *** neurons?

It would be really nice to have some sort av list that compares the different settings, so people could have a general template to aim for according to the hardware capabilities their computers have.

All of the algorithms will give you a different image. There is no value of super-xbr that looks exactly like NNEDI3.

The chart below was made some time ago to compare the different algorithms. I have no idea if it is still accurate today. It compares each algorithm using its default settings:

[baii]

There is not much reason to use x64 except you have problem with decoding performance, especially when reclock is needed. Madvr still does not benefit from x64 performance wise iirc?

Sent from my 306SH using Tapatalk

[QBhd]

When I made the switch to Windows 10, I also made the switch to an x64 workflow (since AMD now has that nice Custom Resolution section). There was a nice little boost in performance and I could bump a setting or two up. Now was that a Windows thing or an x64 thing? If I get a chance late tonight I will test this since I'm considering going back to using Re-Clock.

QB

[ryrynz]

Originally Posted by XMonarchY

Damn, the new De-Ringer is quite heavy on my GPU.

With just the first option ticked? It didn't make much of an impact on my 960 at all. What are you using?

[ryrynz]

Originally Posted by aufkrawall

Well, looking forward to your grain detection.

I think that would be a nice addition, but I have to wonder if perhaps some content might be slightly better served with a lower power dehaloing or perhaps a variation a little kinder to animation.

[zvans18]

Originally Posted by ryrynz

With just the first option ticked? It didn't make much of an impact on my 960 at all. What are you using?

with 1080 movieed content on 1080 screen (nnedi3 16), it took a 12.xms average to ~15 with only first option on my 970

~33 to ~36 on 720 doubled and down to 1080, i could see needing to turn something lower if you're close to the edge

[Betroz]

Originally Posted by Warner306

All of the algorithms will give you a different image. There is no value of super-xbr that looks exactly like NNEDI3.

The chart below was made some time ago to compare the different algorithms. I have no idea if it is still accurate today. It compares each algorithm using its default settings:

Thanks for reply, but that was known to me

[QBhd]

Originally Posted by baii

There is not much reason to use x64 except you have problem with decoding performance, especially when reclock is needed. Madvr still does not benefit from x64 performance wise iirc?

Sent from my 306SH using Tapatalk

So as I mentioned above, I just tested this out. I ran both the x64 and x86 workflows for playback to test this out. I used the same version of PotPlayer with the same settings, the same GPU Driver, the only difference between the workflows being ReClock on the x86.... I also used a file that was 720p60 ==> 1024x768 with maxed out settings, which pushes my GPU to 93% (so close to the edge that even enabling a chroma supres of 1 pushes it over the edge).

Both workflows were able to keep up without dropped frames. So in conclusion, with the playback pushing the GPU to the very edge, there is no difference between x86 and x64 workflows. One caveat, this does not take into consideration decoding of any 4k files. I understand that x64 helps in that regard, but madVR does not benefit from it from what I see.

QB

[ionutm80]

Originally Posted by QBhd

Both workflows were able to keep up without dropped frames.
QB

Do you have some printscreens / pictures with madVR stats in both cases showing clock deviation?
For me the situation was different:
- x64 w/o ReClock, 1 frame drop every 19.48 minutes
- x86 w/. ReClock, 1 frame drop every 4.xx hours
for a 23.976 1080p blu-ray rip on a FullHD TV 60Hz with SVP in the middle interpolating to 59.94.