madVR - high quality video renderer (GPU assisted)

[jkauff]

Yes, it disappears but stays that way even when I move the mouse around. Shouldn't it come back so I can see where I want to seek to?
Yes, it should, and it does for me in MPC and Zoom Player using DXVA2 and madVR, so I don't think that's where the issue is. I'm using Win7 64 Aero, but PowerDVD turns off Aero and the pointer still reappears when the mouse is moved, so I don't think Aero is the issue. Maybe your video driver?

[Matching_Mole]

IVTC is done on the CPU at the moment. If madVR doesn't report any dropped frames and no presentation glitches then my best guess is that for some reason the timings are screwed up so that instead of having every frame being shown for 2 vsyncs, some are shown for 3 vsyncs and some only for 1. Maybe if you create a debug log, I could confirm that guess.

Is there a reason you can't use simple 1080p24 output? That way the problem would probably go away. You could also try different video decoders and/or splitters, just to make sure it's not related to that.

:thanks:

I made 2 different tests where you will find the attached log:
- the first one at 48hz:
http://www.mediafire.com/?twb7bhva342auqd
- the second one at 47.952hz:
http://www.mediafire.com/?41dndx6bjszhb4o

I have stuttering for this two configurations. Unfortunately, I can't use 1080p24 with my projector (Mitsubishi HC3100). its 1080 mode is interlaced and I try to have 24hz in its 768p mode and it reacted not very well.

I will take time to try with different decoders, splitters and players as you suggest.

[oddball]

Has anyone been playing with Complex Sharpen 2? I find it a bit agressive and causing ringing/aliasing on detailed images. Has anyone edited the shading code in MPC to see if they can get a nicer and less aggressive shader algorithm? Something that works nice with Jinc 3 tap perhaps?

[madshi]

I can't get screenshots with Overlay enabled
Screenshots with Print-Screen? Those never work with Overlay. However, using the media player screenshot functionality should work.

Oh yeah, someone asked me a question in my MPC guide thread:

"It it possible to use Floating Point Processing and 10-bit output together, or is it only one or the other? Again, it sounds stupid, and I'd like to go into more detail but I'm not good at wording tech stuff even though my brain can process it pretty well. And which one would be the best in terms of quality? 10-bit would give better colours, I know that, and that's something I'd like to check out, but would the 32-bit processing give an overall better-looking result, even when dithered to 8-bit? I know that's how MadVR works.

I am aware that you need a 10-bit monitor and compatible card for 10-bit output."
madVR always use floating point processing. 10bit output has nothing whatsoever to do with the way the processing is done. So if/when madVR gets 10bit output capability, it will be together with (and not instead of) floating point processing.

10bit output will *not* give better colors. The only thing it will do is lower the dithering noise. You can play with the native bitdepth of the display in the "device" part of the madVR settings dialog. If you set the display to 7bit the dithering noise will be stronger. If you set it to 6bit, it will be stronger again. You should easily see the noise at 6bit. Probably even still at 7bit. The difference between 6bit and 7bit should be more obvious than the difference between 7bit and 8bit. Now just imagine there were 9bit and 10bit options available. If you go from 6bit to 7bit, then to 8bit. The same difference you see there you will also see when going to 9bit and then 10bit. Just the noise level will be lower, but the colors will stay identical.

I made 2 different tests where you will find the attached log:
- the first one at 48hz:
http://www.mediafire.com/?twb7bhva342auqd
- the second one at 47.952hz:
http://www.mediafire.com/?41dndx6bjszhb4o

I have stuttering for this two configurations. Unfortunately, I can't use 1080p24 with my projector (Mitsubishi HC3100). its 1080 mode is interlaced and I try to have 24hz in its 768p mode and it reacted not very well.

I will take time to try with different decoders, splitters and players as you suggest.
Yeah. Here's an extract from the log:

337: (567.95-567.95 568 112529078), 339: (571.16-571.16 571 113196412), 340: (571.96-571.96 572 113363246), 341: (573.96-573.96 574 113780329),
342: (575.97-575.97 576 114197412), 344: (579.18-579.18 579 114864745), 345: (579.98-579.98 580 115031580), 346: (581.99-581.99 582 115448662),
347: (583.99-583.99 584 115865745), 349: (587.19-587.19 587 116533078), 350: (588.39-588.39 588 116783329), 351: (589.99-589.99 590 117116996)
You can see, that the planned vsync numbers for the frames 337 to 351 are:

568, 571, 572, 574, 576, 579, 580, 582, 584, 587, 588, 590

The ideal vsync numbers for smooth playback should be:

568, 570, 572, 574, 576, 578, 580, 582, 584, 586, 588, 590

The cause of the "uneven" vsync numbers are the timestamps which are a result of the timestamps coming from the decoder combined with the IVTC processing. Currently madVR takes these timestamps and calculates the vsync number at which each frame should be shown. In your case that results in non-smooth playback, unfortunately. I guess I could add some sort of "smoothing" algorithm which, after looking at those vsync results, tries to achieve more regular vsync intervals. But then what happens with true VFR (variable framerate) content? I guess I'd first have to write an algorithm to detect whether the decoded (and IVTC'ed) content is VFR or CFR. But this can all become relatively complicated fast.

I do have on my to do list to revisit the whole presentation logic and find more optimal solutions for when the display refresh rate is significantly higher than the movie framerate (as in your case). But it will take some time before I get to that. So for now I'd suggest to try different splitter and decoders to see if any of them make a difference. If not then I don't have a quick solution available right now...

[nub234]

Can't reproduce that here. A freeze report might help. Reproduce the freeze, then press Ctrl+Alt+Shift+Break maybe 3 times, with 5 seconds in between, then on your desktop should be 3 freeze report text files. Zip them and upload them somewhere for me to look at.

I've uploaded both a debug log as I finally managed to produce one, and I've also produced freeze reports. I noticed that the debug log seemed to log everything, so just incase it helps, the freeze occured once at 1second into playback, and once at end of playback which was also when I closed the player, so should be towards the end of the log. Both times I was frame stepping in mpc-hc.

http://www73.zippyshare.com/v/92141861/file.html

[madshi]

I've uploaded both a debug log as I finally managed to produce one, and I've also produced freeze reports. I noticed that the debug log seemed to log everything, so just incase it helps, the freeze occured once at 1second into playback, and once at end of playback which was also when I closed the player, so should be towards the end of the log. Both times I was frame stepping in mpc-hc.

http://www73.zippyshare.com/v/92141861/file.html
I'm not sure, do we have a different definition of what "freeze" means? Please describe exactly what you mean. My understanding of a freeze is if the media player stops responding. The menu doesn't work, anymore, you can't press buttons anymore etc. Is that what happened? But usually such a freeze is "forever". Now you're saying there were 2 freezes. That doesn't really match my definition of a freeze. I guess I first need a detailed description of what happened exactly and what your definition of a "freeze" is.

In the debug log I can see that playback is paused about 1.5 seconds after madVR was created. Then about 7.5 seconds later you've pressed Ctrl+RightArrow to execute a frame step.

[leeperry]

The cause of the "uneven" vsync numbers are the timestamps
Indeed, and that's what's Reclock's for as it makes 24p@48.000Hz dead smooth on the HC3100.

[Matching_Mole]

Yeah. Here's an extract from the log:

337: (567.95-567.95 568 112529078), 339: (571.16-571.16 571 113196412), 340: (571.96-571.96 572 113363246), 341: (573.96-573.96 574 113780329),
342: (575.97-575.97 576 114197412), 344: (579.18-579.18 579 114864745), 345: (579.98-579.98 580 115031580), 346: (581.99-581.99 582 115448662),
347: (583.99-583.99 584 115865745), 349: (587.19-587.19 587 116533078), 350: (588.39-588.39 588 116783329), 351: (589.99-589.99 590 117116996)
You can see, that the planned vsync numbers for the frames 337 to 351 are:

568, 571, 572, 574, 576, 579, 580, 582, 584, 587, 588, 590

The ideal vsync numbers for smooth playback should be:

568, 570, 572, 574, 576, 578, 580, 582, 584, 586, 588, 590

The cause of the "uneven" vsync numbers are the timestamps which are a result of the timestamps coming from the decoder combined with the IVTC processing. Currently madVR takes these timestamps and calculates the vsync number at which each frame should be shown. In your case that results in non-smooth playback, unfortunately. I guess I could add some sort of "smoothing" algorithm which, after looking at those vsync results, tries to achieve more regular vsync intervals. But then what happens with true VFR (variable framerate) content? I guess I'd first have to write an algorithm to detect whether the decoded (and IVTC'ed) content is VFR or CFR. But this can all become relatively complicated fast.

I do have on my to do list to revisit the whole presentation logic and find more optimal solutions for when the display refresh rate is significantly higher than the movie framerate (as in your case). But it will take some time before I get to that. So for now I'd suggest to try different splitter and decoders to see if any of them make a difference. If not then I don't have a quick solution available right now...

Thanks for your answer, many things are more clear now!

But just for my understanding, the IVTC corrected frame rate is 23.976fps, right? I try to use the exact double framerate to achieve smooth playback and it work perfectly on progressive 23.976 framerate. Here you said that I should have no stuttering if I were able to have 24hz refresh rate. Why the double framerate is an issue for the IVTC Film Mode currently?

Anyway, thank you very much again for your help and for the IVTC film mode which is already the greater option for the watch "live" telecine Blu-ray (and DVD) even if it seems that it can be improved again.

[Matching_Mole]

Indeed, and that's what's Reclock's for as it makes 24p@48.000Hz dead smooth on the HC3100.

Thanks for the tip, I will try also.

[nub234]

I'm not sure, do we have a different definition of what "freeze" means? Please describe exactly what you mean. My understanding of a freeze is if the media player stops responding. The menu doesn't work, anymore, you can't press buttons anymore etc. Is that what happened? But usually such a freeze is "forever". Now you're saying there were 2 freezes. That doesn't really match my definition of a freeze. I guess I first need a detailed description of what happened exactly and what your definition of a "freeze" is.

In the debug log I can see that playback is paused about 1.5 seconds after madVR was created. Then about 7.5 seconds later you've pressed Ctrl+RightArrow to execute a frame step.

The player does indeed stop responding, and Windows 8 Displays a not responding window with End Task, but it then starts responding again and has skipped playback. I'll grab a screenie of exactly how it appears in a sec.

The exact steps I took to get the freeze are:

Start playback -> Pause -> Hit Frame Step a few times to try and get to a particular frame -> Freeze Occurs.

It occurs more often when holding down Frame Step to navigate over a longer period of time say a second or so, and like I mentioned in an earlier post this only happens with 0.85.2 onwards.

The screenshot: http://i.imgur.com/ytrOq.jpg

[Niyawa]

Screenshots with Print-Screen? Those never work with Overlay. However, using the media player screenshot functionality should work.
Yup, I actually realized that after I made my post and tried again using MPC-HC. I was using Sniping Tool because I wanted to get a particular part of the video, I thought it was going to be more easier than saving the whole screenshot, and then editing it... you know the drill.

Also the brightness thing was just a little issue with my own screen brightness, someone put it in 90 to 95 and I just realized after taking a look at it. Sorry if I got you worried for a second. Regarding the shaking effect I was talking about, I can still easily reproduce it, but I can't make a screenshot out of it unfortunately. I made some other observations and what happens seems to be that when DXVA2 and Overlay are active, and this issue triggers, the frames ahead (or maybe previously) keep showing on the screen in an infinite loop... It's like you have 24 frames, playing the video, 5-6 frames keep stuck in the present frame that is currently being seen causing a shaking effect since it's in a loop... It's hard to explain because I really don't know how. I'll probably end getting an actual camera and make a video of it since screenshots or recording can't show you how to reproduce it.

And again, it might be related to my Intel, since some friends of mine tried but never got anything and they have other GPUs.

madVR always use floating point processing. 10bit output has nothing whatsoever to do with the way the processing is done. So if/when madVR gets 10bit output capability, it will be together with (and not instead of) floating point processing.

10bit output will *not* give better colors. The only thing it will do is lower the dithering noise. You can play with the native bitdepth of the display in the "device" part of the madVR settings dialog. If you set the display to 7bit the dithering noise will be stronger. If you set it to 6bit, it will be stronger again. You should easily see the noise at 6bit. Probably even still at 7bit. The difference between 6bit and 7bit should be more obvious than the difference between 7bit and 8bit. Now just imagine there were 9bit and 10bit options available. If you go from 6bit to 7bit, then to 8bit. The same difference you see there you will also see when going to 9bit and then 10bit. Just the noise level will be lower, but the colors will stay identical.
I see, thanks for the explanation. I was really at loss because until today I haven't found anything giving a more detailed information on how that works. I mostly heard about FPP in audio but not video. Mind if I just copy-paste that? I really don't know how to put it in a better way in my guide, again thanks.

[Thunderbolt8]

There isn't really much information madVR can use for guessing at the moment, so the guess will be often wrong. It shouldn't matter too much, though, if your PC is fast enough. I guess you're GPU can't handle this content with the "double" framerate deinterlacing produced by DXVA2? Or do you have madVR set to forced film mode? There's also a switch in the madVR settings which allows you to fine tune whether madVR enabled/disables deinterlacing if it isn't sure what to do. Maybe you have that set the "wrong" way? Although there isn't really a wrong way there. But it might work better for you the other way, I don't know...the settings for that are the default ones. whats working best now for me is just turning off deinterlacing by definition and activating it manually for the rare cases in which it seems needed.

[ikarad]

:thanks:

I made 2 different tests where you will find the attached log:
- the first one at 48hz:
http://www.mediafire.com/?twb7bhva342auqd
- the second one at 47.952hz:
http://www.mediafire.com/?41dndx6bjszhb4o

I have stuttering for this two configurations. Unfortunately, I can't use 1080p24 with my projector (Mitsubishi HC3100). its 1080 mode is interlaced and I try to have 24hz in its 768p mode and it reacted not very well.

I will take time to try with different decoders, splitters and players as you suggest.

Have you tested with TIVTC or decomb avisynth filter and see if there is the same problem than with madvr?

[Matching_Mole]

Have you tested with TIVTC or decomb avisynth filter and see if there is the same problem than with madvr?

Long before IVTC was available I tried TVITC and I never succeed to have something usable. Surely, I never understood correctly how this filter works.

[glc650]

Hi,

Whats the minimum recommended Radeon for Jinc 3 AR scaling for 720p60, 1080p60 and 1080i60 (deinterlaced by madVR) playback at 1080p60?

Thanks,

->g.

[cyberbeing]

I've always had issues similar to Matching_Mole with certain transport streams (the type which only IVTC to 24fps smoothly using DScalerMod 'IVTC = Always Enable'). When using LAV Filters + madVR (forced Film mode), playback is only smooth during commercials where madVR detects 2:2 cadence, while during the show itself where 3:2 cadence is detected, all panning scenes stutter immensely, with frames feeling like they are being displayed out of order. The odd part is it seems 'normal' if I step frame by frame or hold CTRL + right arrow in MPC-HC.

madshi, here a few logs @ 96hz & 120hz:

TS #1 (~30 seconds 2:2 commercial -> ~36 seconds 3:2 show) (http://www.mediafire.com/?eota10nfqfyzss9)

TS #2 (~25 seconds 3:2) (http://www.mediafire.com/?86df8m8fz3mj33a)

TS #3 (seek -> ~35 seconds 3:2) (http://www.mediafire.com/?2y68wgdtv9vllhn)


Was IVTC functionality similar to DScalerMod something which you ever see yourself implementing, or was your current IVTC algorithm already supposed to handle such cases? I haven't been following the madVR Deinterlacing & IVTC discussions much, so probably already answered this at some point.

[turbojet]

I've already explained it in detail in one of my earlier posts.

Maybe I missed something this is what I've read: http://forum.doom9.org/showthread.php?p=1606398#post1606398

You found 3 parties at fault, not sure which should fix, couldn't reproduce it: http://forum.doom9.org/showthread.php?p=1606518#post1606518

You found it interesting later versions of mpc-be reproduced it but weren't sure why: http://forum.doom9.org/showthread.php?p=1606688#post1606688

Few days later I asked if you could let me know if it's mpc-be's responsibility to fix: http://forum.doom9.org/showthread.php?p=1606747#post1606747
That was all on the subject. Thinking you had missed it, I asked again a week or so later.

Must be some bottleneck in DXVA, I would guess. But I can't really say for sure. I don't think it's madVR's fault...

I think you are correct, 2 html5 videos don't play well at the same time either.

[madshi]

Indeed, and that's what's Reclock's for as it makes 24p@48.000Hz dead smooth on the HC3100.
Reclock doesn't improve screwed up timestamps.

But just for my understanding, the IVTC corrected frame rate is 23.976fps, right? I try to use the exact double framerate to achieve smooth playback and it work perfectly on progressive 23.976 framerate. Here you said that I should have no stuttering if I were able to have 24hz refresh rate. Why the double framerate is an issue for the IVTC Film Mode currently?
Yes, IVTC output is "roughly" 23.976p. However, timestamps seem to have a lot of jitter in them. That might depend on the splitter/decoder, but it could also be a "fault" of the IVTC algorithm. When using 23.976Hz display mode, the jitter in the timestamps doesn't matter so much because madVR is clever enough to avoid frame drops if the number of decoded frames is roughly identical to the display refresh rate - even if the timestamps aren't optimal. However, with 48Hz display mode, there are twice as many vsyncs as there are decoded frames, so there timestamp jitter can result in somewhat odd vsync presentation patterns.

Anyway, thank you very much again for your help and for the IVTC film mode which is already the greater option for the watch "live" telecine Blu-ray (and DVD) even if it seems that it can be improved again.
FWIW, the IVTC algorithm itself doesn't need improvement for this, but maybe the timestamp handling could be improved.

The player does indeed stop responding, and Windows 8 Displays a not responding window with End Task, but it then starts responding again and has skipped playback. I'll grab a screenie of exactly how it appears in a sec.

The exact steps I took to get the freeze are:

Start playback -> Pause -> Hit Frame Step a few times to try and get to a particular frame -> Freeze Occurs.
Ok, please try different splitters, decoders and different video files. Maybe this problem only occurs with a certain combination of video files, splitters and/or decoders. If you find that it only occurs with some video files but not with others, please upload a sample of a video file where it occurs most often. Thanks.

Regarding the shaking effect I was talking about, I can still easily reproduce it, but I can't make a screenshot out of it unfortunately. I made some other observations and what happens seems to be that when DXVA2 and Overlay are active, and this issue triggers, the frames ahead (or maybe previously) keep showing on the screen in an infinite loop... It's like you have 24 frames, playing the video, 5-6 frames keep stuck in the present frame that is currently being seen causing a shaking effect since it's in a loop... It's hard to explain because I really don't know how. I'll probably end getting an actual camera and make a video of it since screenshots or recording can't show you how to reproduce it.

And again, it might be related to my Intel, since some friends of mine tried but never got anything and they have other GPUs.
Well, I'm not sure but it could be a bug in your GPU drivers. Or it could be a bug in madVR. It's hard for me to say for sure. I'd need to have hardware similar to yours so I could test it myself.

Mind if I just copy-paste that? I really don't know how to put it in a better way in my guide, again thanks.
I don't mind at all. Feel free to use any explanation or comment I make for your guide.

Whats the minimum recommended Radeon for Jinc 3 AR scaling for 720p60, 1080p60 and 1080i60 (deinterlaced by madVR) playback at 1080p60?
Jinc3 for both chroma and luma? I think the 7850 should be able to do that. Maybe also the 7770, but I'm not sure. This is all a moving target, though. One of the recent builds just noticeably improved Jinc3 chroma upscaling performance. Maybe I'll find more ways to improve performance in the future, or maybe not. Maybe I'll make the anti-ringing filter even higher quality in the future, on the cost of some performance, or maybe not. So there's a chance performance could get either faster or slower in the future. Also there could be more/other algorithms coming to madVR in the future, too.

I've always had issues similar to Matching_Mole with certain transport streams (the type which only IVTC to 24fps smoothly using DScalerMod 'IVTC = Always Enable'). When using LAV Filters + madVR (forced Film mode), playback is only smooth during commercials where madVR detects 2:2 cadence, while during the show itself where 3:2 cadence is detected, all panning scenes stutter immensely, with frames feeling like they are being displayed out of order. The odd part is it seems 'normal' if I step frame by frame or hold CTRL + right arrow in MPC-HC.
It's not really odd. Probably only the timestamps are sub-optimal.

madshi, here a few logs @ 96hz & 120hz:

TS #2 (~25 seconds 3:2) (http://www.mediafire.com/?86df8m8fz3mj33a)
Same issue as Matching_Mole: timestamps aren't good. You tried different splitters/decoders? No difference?

Was IVTC functionality similar to DScalerMod something which you ever see yourself implementing, or was your current IVTC algorithm already supposed to handle such cases?
madVR's IVTC algorithm is way *WAY* better than DScalerMod. However, I've only ever really tested IVTC playback with 24p output. I guess timestamp handling might need improvement. But if you think about it, timestamp handling is like 0.1% of what an IVTC algorithm does.

I asked if you could let me know if it's mpc-be's responsibility to fix

[...]

You found 3 parties at fault, not sure which should fix, couldn't reproduce it
There is your answer. "Not sure which should fix" rather is "Probably all 3 parties should fix", though. Just one fix in one of the parties is needed to fix the issue.

[dansrfe]

What exactly does Reclock do?

[nevcairiel]

Yes, IVTC output is "roughly" 23.976p. However, timestamps seem to have a lot of jitter in them. That might depend on the splitter/decoder, but it could also be a "fault" of the IVTC algorithm. When using 23.976Hz display mode, the jitter in the timestamps doesn't matter so much because madVR is clever enough to avoid frame drops if the number of decoded frames is roughly identical to the display refresh rate - even if the timestamps aren't optimal.

Any Hard-Telecined content i've seen has pretty clean 29.97 fps timestamps.
Its the Soft-Telecined content which has really odd timestamps (its designed to fit 29.97 fps timestamps after the telecine flags are applied, so ignoring those flags, the timestamps aren't exactly 24 fps compatible)

[bugmen0t]

That doesn't really make much sense, but then, rendering times aren't always the most reliable measurements. Just check whether playback is smooth with no dropped frames.

No frame drops or any other problems. Only rendering times going down to about one third. Maybe madVR is recognizing the doubled and tripled frames as one each, computing rendering times divided by 2 and 3 and therefore 2.5 on average. That would fit the given timings.

[bugmen0t]

What exactly does Reclock do?
ReClock is an audio renderer which continuously resamples the audio to slow down or speed up the played video to match the display rate as much as possible and keep audio and video in sync without dropping or repeating frames.

[G_M_C]

[...]
It's not recommended for upscaling because it introduces more problems than it solves for most video content. For downscaling, especially when using rather large downscaling factors, it can help to produce more faithful results, but it also introduces quite a lot of additional ringing, so only use it in combination with the anti-ringing filter, and also use a 2-tap algorithm, only. E.g. Catmull-Rom is recommended for that specific purpose.
[...]

Thx madshi for answering my question.

Downscaling doesnt happen much in real world usage, up-scaling happens much more. And i like the Jinc scaler. So I've decided to switch of linear light scaling all together atm.

[e-t172]

Yes, IVTC output is "roughly" 23.976p. However, timestamps seem to have a lot of jitter in them. That might depend on the splitter/decoder, but it could also be a "fault" of the IVTC algorithm. When using 23.976Hz display mode, the jitter in the timestamps doesn't matter so much because madVR is clever enough to avoid frame drops if the number of decoded frames is roughly identical to the display refresh rate - even if the timestamps aren't optimal. However, with 48Hz display mode, there are twice as many vsyncs as there are decoded frames, so there timestamp jitter can result in somewhat odd vsync presentation patterns.

Oh. That may be why I've given up on madVR IVTC because of jerky playback, since I have a 48 Hz screen.

[madshi]

Yeah, guess I should put on my to do list to find a quick (eventually dirty) fix for IVTC timestamps.

[CiNcH]

Hey guys,

I am still playing around with Intel HD graphics and A/V timings. I once thought that with my Ivy Bridge CPU and Z77 chipset, HDMI Audio is somehow inserted via the onboard Realtek audio controller (which is driven by a different quartz). Because if I disable the 'HD Audio Controller' within the BIOS, both, 'Intel Display-Audio' and 'Realtek High Definition Audio', disappear from within the device manager. But if I just disable 'Realtek High Definition Audio' from within the device manager, HDMI Audio still works. So there has to be a controller within the CPU.

So I had a look at the madVR OSD statistics when using HDMI Audio with the Realtek disabled. I used DirectSound renderer and its clock as graph reference. madVR displays a clock deviation jittering around 0%. So I guess that the video and audio part are perfectly in sync. madVR still believes though that it has to drop a frame every 4.2 minutes. How is this calculated? Guess not from the clock deviation but rather from the display/composition rate discrepancy which is still 23.972 vs. 23976 Hz. And a frame indeed gets dropped every ~4 minutes according to the statistics. Is it really necessary? At 23.972 Hz, frame rate is just a bit lower but according to the clock deviation as is the audio speed. So everything should be in perfect sync, no?

[cyberbeing]

FWIW, the IVTC algorithm itself doesn't need improvement for this, but maybe the timestamp handling could be improved.
...
It's not really odd. Probably only the timestamps are sub-optimal.
...
Same issue as Matching_Mole: timestamps aren't good. You tried different splitters/decoders? No difference?
...
madVR's IVTC algorithm is way *WAY* better than DScalerMod. However, I've only ever really tested IVTC playback with 24p output. I guess timestamp handling might need improvement. But if you think about it, timestamp handling is like 0.1% of what an IVTC algorithm does.

The same madVR IVTC + Decimation stutter occurs when using any splitter/decoder combination with these videos.

When using DScalerMod IVTC, I've noticed I can make it stutter similar to madVR IVTC if I enable its 3:2 Playback Smoothing option, which I assume is timestamp smoothing, and obviously harmful for the samples I provided logs for.

[madshi]

So I had a look at the madVR OSD statistics when using HDMI Audio with the Realtek disabled. I used DirectSound renderer and its clock as graph reference. madVR displays a clock deviation jittering around 0%. So I guess that the video and audio part are perfectly in sync. madVR still believes though that it has to drop a frame every 4.2 minutes. How is this calculated? Guess not from the clock deviation but rather from the display/composition rate discrepancy which is still 23.972 vs. 23976 Hz. And a frame indeed gets dropped every ~4 minutes according to the statistics. Is it really necessary? At 23.972 Hz, frame rate is just a bit lower but according to the clock deviation as is the audio speed. So everything should be in perfect sync, no?
Well, the 4.2 minutes is just an estimate. This whole calculation is just there to give you a hint. It is not used *at all* during video rendering. Video rendering drops frames only when the calculated vsync timings require a frame drop to keep audio and video in sync. So the ultimate proof whether you get perfectly smooth playback is not the 4.2 minute estimate, but the number of actually dropped frames. Unfortunately I'm (currently) not counting the frame repeats yet, so even if you have zero actual frame drops reported in the OSD, playback could still be non-smooth if there are a frame repeats.

The 4.2 minutes estimate is based on comparing the measured refresh rate, corrected by the measured audio clock deviation, to the needed refresh rate. E.g. if the audio clock deviation is exactly 0% and the measured refresh rate is 23.972, then your GPU draws frames a bit too slowly. Since audio clock deviation is 0%, audio is played at a speed that requires video to be drawn at exactly 24/1.001. Since your measured refresh rate is slower, audio and video sync will get lost over time if madVR doesn't drop video frames once in a while. That's where the 4.2 minutes estimate comes from.

The same madVR IVTC + Decimation stutter occurs when using any splitter/decoder combination with these videos.

When using DScalerMod IVTC, I've noticed I can make it stutter similar to madVR IVTC if I enable its 3:2 Playback Smoothing option, which I assume is timestamp smoothing, and obviously harmful for the samples I provided logs for.
Could I have a sample which demonstrate this stuttering, please? It will be a couple of weeks before I find the time to look at this, though.

[cyberbeing]

Could I have a sample which demonstrate this stuttering, please? It will be a couple of weeks before I find the time to look at this, though.

PM sent which contains a download link for all three samples (trimmed with TSMuxer around panning scenes).

[DragonQ]

ReClock is an audio renderer which continuously resamples the audio to slow down or speed up the played video to match the display rate as much as possible and keep audio and video in sync without dropping or repeating frames.
The new MediaPortal Audio Renderer does this too, although I'm not sure why they decided to reinvent the wheel for this. MadVR support would've been a much better thing to work on, IMO.

[pei]

Does it work if i disable it and use what?

[leeperry]

Reclock doesn't improve screwed up timestamps.
Oops, my bad! I guess I'm mixing with AC3Filter that has a "smooth timestamps" option IIRC.

I guess he was talking about realtime IVTC'ed content (in mVR?) when I'm talking about 23.976/24/25fps files that were dead smooth with Reclock in 48Hz on the HC3100 IME, whatever natively progressive or offline IVTC'ed in Avisynth.

But if mVR can only smooth timestamps for realtime IVTC'ed stuff when running in 24Hz, I guess that's yet another good reason to give up on 48Hz....too bad the mouse cursor is so sluggish in 24Hz.

[Matching_Mole]

Yeah, guess I should put on my to do list to find a quick (eventually dirty) fix for IVTC timestamps.

Great news! If you need any specific samples from telecined blu-ray in addition of the sample of cyberbeing, I will be happy to provide them. Unfortunately I have several examples :D

I guess he was talking about realtime IVTC'ed content (in mVR?) when I'm talking about 23.976/24/25fps files that were dead smooth with Reclock in 48Hz on the HC3100 IME, whatever natively progressive or offline IVTC'ed in Avisynth

Yes, I have the stuttering issue only with IVTC'ed content. Otherwise I have a perfect smooth playback for any progressive video, and without Reclock Speed adaptation feature.

[leeperry]

Yes, I have the stuttering issue only with IVTC'ed content.
Well, Reclock has no idea whatsoever that mVR is messing with the frame rate so yeah, it's all gonna end up in stutter-land :p

I presume that LAV can't IVTC? I often play 29.97@59.94 1080i with LAV using CUVID, and Reclock sees 59.94 sees as expected.

[aufkrawall]

Which GPU, OS, decoder, splitter? Aero on/off?

GTX 670, Win 7 x64, LAV video & splitter, Aero on, MPC HC.

[nub234]

Ok, please try different splitters, decoders and different video files. Maybe this problem only occurs with a certain combination of video files, splitters and/or decoders. If you find that it only occurs with some video files but not with others, please upload a sample of a video file where it occurs most often. Thanks.

I'm using LAV Splitters/Decoders in PotPlayer and MPC's default splitters and decoders in MPC; both give the same freeze. I also performed a clean PotPlayer install, that is to say it was using its internal decoders/splitters, when selecting madVR the freeze occurred again.

The freeze actually occurs with all files equally, whether AVC1, XVID or WMV but if you still want a sample of a file let me know and I'll upload one.

[pei]

Then you ]jkauff said
[QUOTE]
Yes, it should, and it does for me in MPC and Zoom Player using DXVA2 and madVR, so I don't think that's where the issue is. I'm using Win7 64 Aero, but PowerDVD turns off Aero and the pointer still reappears when the mouse is moved, so I don't think Aero is the issue. Maybe your video driver?
Yesterday 06:44

Now I say:
Video is AMD Radeon 6310 latest available drivers

[Peuj]

The batch file should do the trick. Make sure the "settings.bin" file in the madVR folder is deleted, too.

Hi madshi,

Thanks, I've found the "settings.bin" file in C:\Users\Peuj\AppData\Local\VirtualStore\Program Files (x86)\LAV Filters\x86\madVR

I've looked in the bat file and the way it's written, the "settings.bin" file cannot found.

[pei]

That's weird. On my PC the mouse cursor disappears if you don't move it for a while. Then as soon as you move the mouse, the cursor comes back. Not sure why that doesn't work for you. Might have to do with the GPU/drivers. Does that not happen if you disable DXVA2?

Switching it to NONE also doesn't let the mouse cursor appear.

[SamuriHL]

Hi madshi,

Thanks, I've found the "settings.bin" file in C:\Users\Peuj\AppData\Local\VirtualStore\Program Files (x86)\LAV Filters\x86\madVR

I've looked in the bat file and the way it's written, the "settings.bin" file cannot found.



@echo off
echo.
echo.
title restore madVR default settings...
cd /d "%~dp0"
start /min reg delete HKEY_CURRENT_USER\Software\madshi\madVR /f
if exist "settings.bin" (
if exist "settings.bak" (del settings.bak >NUL)
rename settings.bin settings.bak >NUL)
echo settings were reset to default
echo.
pause >NUL


I fixed it by adding a line that should make sure that you're in the directory that the batch file is in when it executes.

[pei]

I really wanna use hardware decoding used by madVR, but this mouse cursor thing is kind of a deal breaker.

[manni500]

Madshi Video Renderer under PotPlayer 64-bit
--------------------------------------------

I have searched the forum - as well as Google - but could not find this issue addressed so I permit myself to post the query here.
Today, I changed from PotPlayer 32-bit to 64-bit sind I learned that madVR should work with that. However, I now can no longer configure the filter. When I go to Filters(in PotPlayer), the madshi no longer shows up as it did under the 32-bit version. What am I doing wrong? I reregistered the newest version of madVR, but to no avail.
Any help is much appreciated; thanks in advance

[DragonQ]

MadVR is 32-bit only so that'll be the problem...

[manni500]

Thanks for the prompt response !
But over at the download page it says that MadVR works well with Windows 8 64-bit. See for yourself : http://www.videohelp.com/tools/madVR

Afterthought:
let me add also that the filter is there; it shows under 'Preferences, Video' and there is an obvious difference to the built-in filter when Madshi is used. So the filter must be working with PotPlayer x64. But what is missing is the possibility to configure it

[ryrynz]

That's not the same thing though. 64-bit players have to use 64-bit renderers.

[DragonQ]

Windows 8 64-bit is an operating system. Nowhere does it say it works with 64-bit media players.

[manni500]

yes, you are right ryrynz, I realize that I misunderstood here. Yet I want to repeat that the filter is operational under Potplayer x64, if not configureable

[huhn]

the madvr filter is not operational in pot player 64 an backup video renderer is loaded. just use potplayer 32 bit on ur 64 bit system it isn't slower at all.

[manni500]

So you are saying the change I see when switching to the "Madshi Video Renderer" in the DPP video section is not coming from madVR but from some other built-in filter.
In any case, I have taken your advise and gone back to DPP x86 (although I don't quite understand: if there is no need for or improvement by a x64 version, why build it?)

[huhn]

pot 64 uses video renderer when madvr is selected (maybe know as old renderer in mpc hc?) but u can simple see in the filter that madvr is not used and it can't be used because it is 32 bit only.

a 64 bit player can handle "a lot" more then 2gb ram for avisynth scripts and things like that but normal user will never touch the 2 gb mark.

and 64 bit is faster when velues higher then 32 bit are used and trust me 32 bit is pretty big....

but that is another topic.