madVR - high quality video renderer (GPU assisted)

[Niyawa]

Originally Posted by madshi

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.

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by Matching_Mole

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]

Originally Posted by ikarad

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)

TS #2 (~25 seconds 3:2)

TS #3 (seek -> ~35 seconds 3:2)


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]

Originally Posted by madshi

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.ph...98#post1606398

You found 3 parties at fault, not sure which should fix, couldn't reproduce it: http://forum.doom9.org/showthread.ph...18#post1606518

You found it interesting later versions of mpc-be reproduced it but weren't sure why: http://forum.doom9.org/showthread.ph...88#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.ph...47#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]

Originally Posted by leeperry

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.

Originally Posted by Matching_Mole

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.

Originally Posted by Matching_Mole

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.

Originally Posted by nub234

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.

Originally Posted by Niyawa

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.

Originally Posted by Niyawa

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.

Originally Posted by glc650

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.

Originally Posted by 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.

It's not really odd. Probably only the timestamps are sub-optimal.

Originally Posted by cyberbeing

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

TS #2 (~25 seconds 3:2)

Same issue as Matching_Mole: timestamps aren't good. You tried different splitters/decoders? No difference?

Originally Posted by cyberbeing

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.

Originally Posted by turbojet

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by dansrfe

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]

Originally Posted by madshi

[...]
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]

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by CiNcH

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.

Originally Posted by cyberbeing

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]

Originally Posted by madshi

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]

Originally Posted by bugmen0t

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.