1 Topic by river (edited by river 24-10-2015 02:42:09)

  • Thanks: 8

Topic: Odd stuttering issue while using madVR 10bit output

My screen refresh rate is set to exact 59.94Hz, and everything works fine when I use 8bit output.

09:05:14.593 [i]: Screens: updating information, 1 screen(s) found
09:05:18.215 [i]: Screens: screen 0 - 3840x2160 @59.940 Hz [measured], 192 PPI
09:05:18.215 [i]: Screens: primary screen is 0
09:05:18.215 [i]: Playback [30772]: resulting video frame 1920x1080
09:05:18.215 [i]: Playback [30772]: 1 acceptible profiles, best is 'Automatic' [0]
09:05:18.215 [i]: Playback [30772]: keep previously selected profile 'Automatic'
09:05:18.215 [i]: Profile: using auto values [1]
09:05:18.217 [i]: Playback: playing at 59.94

But when using 10bit output, it seems that SVP can't detect the refresh rate, and uses 59.000Hz instead. Then stuttering begins.

09:05:01.287 [i]: Screens: updating information, 1 screen(s) found
09:05:01.504 [i]: Screens: screen 0 - 3840x2160 @59.000 Hz [using Windows refresh rate], 192 PPI
09:05:01.504 [i]: Screens: primary screen is 0
09:05:01.802 [i]: VideoPlayer: new ffdshow video [30772] in mpc-be.exe (32-bit) [MPC-BE 1.4.6.898] on screen 0
09:05:02.334 [i]: Media: video 1920x1080 [PAR 1.000] at 23.976 fps [constant]
09:05:02.334 [i]: Media: codec type is HEVC
09:05:02.335 [i]: FFDShow: clear AVS script previously set by SVP
09:05:02.336 [i]: Playback [30772]: Avisynth (32-bit) version 2.6.0.5, Avisynth 2.6, C:\WINDOWS\SysWOW64\avisynth.dll
09:05:02.336 [i]: Playback [30772]: resulting video frame 1920x1080
09:05:02.336 [i]: Playback [30772]: 1 acceptible profiles, best is 'Automatic' [0]
09:05:02.337 [i]: Playback [30772]: enabled while video is playing
09:05:02.337 [i]: Profile: using auto values [1]
09:05:02.340 [i]: Playback: playing at 58.608

I think there might be a way to "tell" SVP, 59.000Hz actually means 59.94Hz.

2 Reply by Nintendo Maniac 64 (edited by Nintendo Maniac 64 24-10-2015 04:34:48)

  • Thanks: 167
  • Thanks for the post: 1

Re: Odd stuttering issue while using madVR 10bit output

FYI, you made a typo in your first sentence - surely it's not "54.94Hz" tongue


EDIT: Alright, I see you've fixed it now.

  • Thanks: 153
  • Thanks for the post: 1

Re: Odd stuttering issue while using madVR 10bit output

Which SVP Version are you using? With the full version of SVP 4 you'll be able to force refresh-rate. You could also do it with the older SVP which remains free.

Also I see you're up-scaling to 4K from the above. If you're up-scaling using Madvr, you could go to Madvr settings, expand 'rendering' menu on the left, go to 'smooth motion', tick enable 'smooth motion frame rate conversion' and choose 'always'... This usually eliminates whatever jitter (micro-stuttering) left over from the missing frames that fill the monitor refresh-rate without forcing SVP's FPS.

  • Thanks: 8

Re: Odd stuttering issue while using madVR 10bit output

Blackfyre wrote:

Which SVP Version are you using? With the full version of SVP 4 you'll be able to force refresh-rate. You could also do it with the older SVP which remains free.

Also I see you're up-scaling to 4K from the above. If you're up-scaling using Madvr, you could go to Madvr settings, expand 'rendering' menu on the left, go to 'smooth motion', tick enable 'smooth motion frame rate conversion' and choose 'always'... This usually eliminates whatever jitter (micro-stuttering) left over from the missing frames that fill the monitor refresh-rate without forcing SVP's FPS.

I've tried smooth motion from madVR, it blends scenes, SVP can do better than that. I just need to force the monitor refresh at 59.94 and let SVP play at 59.94.
But things went wrong in this part: 

09:05:01.504 [i]: Screens: screen 0 - 3840x2160 @59.000 Hz [using Windows refresh rate], 192 PPI

I think SVP can retrieve refresh rate infomation from madVR, since madVR never fails to detect refresh rate. Or just guess a better refresh rate when detection fails, e.g. 23Hz=23.976Hz, 29Hz=29.97Hz, 59Hz=59.94Hz.

  • Thanks: 37
  • Thanks for the post: 1

Re: Odd stuttering issue while using madVR 10bit output

Is it happened with all 10-bit videos?
What about 10-bit h264 and 10-bit h265? Is it same?
Have you tried with different video player? Is it same?

  • Thanks: 1622
  • Thanks for the post: 1

Re: Odd stuttering issue while using madVR 10bit output

ok, I think I know how to fix this
wait for the next update smile

  • Thanks: 8

Re: Odd stuttering issue while using madVR 10bit output

mashingan wrote:

Is it happened with all 10-bit videos?
What about 10-bit h264 and 10-bit h265? Is it same?
Have you tried with different video player? Is it same?

This happens when using madVR 10bit output, no matter what the video is. I also tried MPDN, with 10bit outputs on, same thing happens

Chainik wrote:

ok, I think I know how to fix this
wait for the next update smile

That's great.

Re: Odd stuttering issue while using madVR 10bit output

Chainik wrote:

ok, I think I know how to fix this
wait for the next update smile

Brilliant smile That's great news.

Re: Odd stuttering issue while using madVR 10bit output

So out of curiosity here.... Is he trying to get this to play in 10bit because I was under the assumption that 10 bit still hasn't been supported by SVP that's the sole reason I haven't actually pre-ordered the program...

  • Thanks: 1622
  • Thanks for the post: 1

Re: Odd stuttering issue while using madVR 10bit output

This's not about "10 bit" actually.

madVR changes display mode to something, may be to "10 bit output", SVP tries to re-measure refresh rate and fails (because "full screen exclusive" renderer blocks SVP's ability to measure it) and takes "Windows refresh rate" (which is an integer value).
It this particular case refresh rate was not changed so SVP could keep previously measured value of 59.xxx instead of falling back to 59.000.

11 Reply by Nintendo Maniac 64 (edited by Nintendo Maniac 64 25-10-2015 16:14:27)

Re: Odd stuttering issue while using madVR 10bit output

I'm not a MadVR user, but that's very interesting since I thought MadVR's "full screen exclusive" renderer worked similarly to "D3D Fullscreen" (though I definitely can say it doesn't work exactly the same since the latter gives much better performance on old and really low-end Intel integrated GPUs).