madVR - high quality video renderer (GPU assisted)

[madshi]

Originally Posted by renethx

What's up with 1440x1080 HDTV files like this? With Jinc3+AR image upscaling algorithm (and Bicubic75+AR chroma upscaling), the rendering time is

- 1440x1080 --> 1920x1080: ~17.3ms
- 1440x1080 --> 1918x1079 (or any similar resolution such as 1900x1069 [1% zoom out]): ~10.4ms

I haven't seen such a drastic reduction of the rendering time by a slight change of resolution with any other file. A10-5800K+DDR3-2400+1080MHz iGPU.

The reason is that Jinc currently only works for *up*scaling but not for *down*scaling. Furthermore Jinc is a 2D operation, meaning you can't handle X and Y scaling separately. When upscaling 1440x1080 to 1920x1080 Jinc can be used. However, when doing 1440x1080 to 1918x1079 X requires upscaling while Y requires downscaling. Since Jinc does not support downscaling, it must be totally disabled in this situation. That's why the rendering times decrease because Jinc is not used, anymore...

Originally Posted by e-t172

By the way, due to the way LCDs work (they don't flicker like CRTs or film projectors do) and the way our eyes work (persistence of vision), shouldn't madVR smooth motion on 24p/60Hz brings LCDs closer to CRTs in terms of smoothness than native refresh rate (24p/24Hz or multiple) and no smooth motion? In other words, because the blended frames generated by madVR look close to the frames our brains "invent" between refreshes when looking at a CRT, I would expect smooth motion on a 60 Hz LCD to give superior results than native refresh rate on the same LCD. Does that makes sense?

I don't think our brain invents pictures. My personal opinion is that 24p/60Hz with smootion motion FRC turned on should ideally look nearly as good as 24p/24Hz, if all goes well, but it shouldn't look better. If it does look better on your display, then I think your display likely can't do 24Hz properly.

Originally Posted by e-t172

Maybe a good idea would be for us to put feature requests in the bug tracker, so that they can just sit there for some (possibly long) amount of time until you decide to consider them?

No. I don't want to be bothered with feature requests *at all* for now. There are already too many things on my to do list, and many of them are quite important. More important IMHO than 99.9% of the feature requests that are often posted here. So I'd rather ignore the "noise" of feature requests for a while...

Originally Posted by hdboy

Yes I am using overlay. Looks like the backbuffer queue is empty. It alternates between 0-8/8 and 7-8/8. The other queues never go to zero. On videos with no problem, backbuffer q is steady at 7-8/8.

Not sure why that happens. Is it possible that you have some browser running in the background with GPU acceleration enabled? That might explain the problem. You could try playing with the flush settings, but it might not help if there's some other software using the GPU behind madVR's back...

[truexfan81]

Originally Posted by madshi

The reason is that Jinc currently only works for *up*scaling but not for *down*scaling. Furthermore Jinc is a 2D operation, meaning you can't handle X and Y scaling separately. When upscaling 1440x1080 to 1920x1080 Jinc can be used. However, when doing 1440x1080 to 1918x1079 X requires upscaling while Y requires downscaling. Since Jinc does not support downscaling, it must be totally disabled in this situation. That's why the rendering times decrease because Jinc is not used, anymore...

in that case what scaler is used? just curious

[Vyral]

Originally Posted by iSunrise

BT.709 shares the same primaries as sRGB, which are needed for accurate color reproduction. If you don´t have the option/don´t want to calibrate your monitor and go with the sRGB mode that is implemented, you can enable "this display is already calibrated" under your monitor´s "calibration" tab setting in madVR and set "the display is calibrated to the following primaries / gamut:" to BT.709. That way, the primaries should match more closely, which should give you more accurate color reproduction. Also, choose "pure power curve" and "2.20" under the "the display is calibrated to the following transfer function / gamma:" option.

After that, you can also check with test patterns from e.x. AVS HD within madVR if your black levels are as they should be. If you need an adjustment you currently can either adjust gamma ("enable gamma processing" and set the target gamma" a bit (lower value = brighter, higher value = darker) or use the brightness slider under the "color & gamma" tab. You should stay away from the "saturation", "contrast" and "hue" slider if possible.

That´s as far as you´re able to go without actually doing any calibration yourself. Depending on the quality and native gamma of your panel and the careness of the implementation of the sRGB mode on your monitor, the results can vary though. It should however look a lot better than non-managed.

Note that you won´t see any difference when just playing with the calibration values themselves. They are however important so that madVR "knows" your settings for appropriate conversions to take place.

Thanks for the explanation. I also have a samsung monitor with sRGB. I'll try this settings later.

[toniash]

Originally Posted by leeperry

Well once in a while(like every 30/60 secs), my judder tests in mVR tend to move ever so slightly too fast.....hence ruining smoothness. That's usually when they reach the far right side of the screen, and often when Reclock's VSYNC indicator(spying on what mVR does ) isn't on the top of the screen either.

I think you have to disable Vsync correction in ReClock so it doesn't fight against Madvr Vsync and if you disable it you don't see ReClock's Vsync indicator

[leeperry]

Originally Posted by iSunrise

Here are two samples I´ve found that look perfect with smooth motion:
http://www.mediafire.com/?5xccccrs7109mjn
http://www.mediafire.com/?1zos93buokb981r

Indeed! No ghosting whatsoever on my CRT in 89.91Hz, I only wish that everything looked this good

Originally Posted by toniash

I think you have to disable Vsync correction in ReClock so it doesn't fight against Madvr Vsync and if you disable it you don't see ReClock's Vsync indicator

Yep, I shall try with Reclock disabled I guess...but I don't have VSYNC correction enabled in Reclock, but Reclock is a dirty hack at heart.

[Reino]

I have just installed madVR for the first time, so I'm totally new to this, but I'm facing some problems:

MPC-BE_______________MPC-HC
__
In both cases LAV Splitter Source and MPC-VD (FFmpeg) are used together with madVR at default settings. In MPC-BE everything seems fine, but obviously in MPC-HC there's something seriously wrong 'somewhere'.
This brings me to my next question: How come MPC-VD (DXVA) won't connect to madVR? It always falls back to "Video Renderer".

[madshi]

Originally Posted by truexfan81

in that case what scaler is used? just curious

IIRC Lanczos for upscaling and whatever scaler you specified in the settings for downscaling.

Originally Posted by CoRoNe

In both cases LAV Splitter Source and MPC-VD (FFmpeg) are used together with madVR at default settings. In MPC-BE everything seems fine, but obviously in MPC-HC there's something seriously wrong 'somewhere'.

Not sure what's going on there. My first guess would be that there's a bug in the MPC-HC decoder. These days most people don't use that decoder, anymore, anyway. Since you're already using LAV Splitter, why not also using LAV Video Decoder?

Originally Posted by CoRoNe

This brings me to my next question: How come MPC-VD (DXVA) won't connect to madVR? It always falls back to "Video Renderer".

Good question, I don't know. Could be that the decoder only connects to certain known renderers. Could be that the decoder requires a specific renderer behaviour which madVR might not fulfill. Could be a bug in the decoder or in madVR. It's hard to say without analyzing it in detail. Again I'd recommend to use LAV Video Decoder.

[Reino]

I can't use LAV VD for DXVA, because I'm on WinXP.

[madshi]

Ah! madVR only supports DXVA2, just like EVR, so that might be the cause of the issue? Is your decoder DXVA1 or DXVA2?

[Reino]

That explains it. Too bad, yet another piece of software I can't use .
Afaik DXVA2 isn't available on WinXP. MPC VD (DXVA) here is always DXVA1, yes.

[DragonQ]

Yeah, damn those developers ignoring a 12 year old OS!

[Niyawa]

Originally Posted by iSunrise

BT.709 shares the same primaries as sRGB, which are needed for accurate color reproduction. If you don´t have the option/don´t want to calibrate your monitor and go with the sRGB mode that is implemented, you can enable "this display is already calibrated" under your monitor´s "calibration" tab setting in madVR and set "the display is calibrated to the following primaries / gamut:" to BT.709. That way, the primaries should match more closely, which should give you more accurate color reproduction. Also, choose "pure power curve" and "2.20" under the "the display is calibrated to the following transfer function / gamma:" option.

After that, you can also check with test patterns from e.x. AVS HD within madVR if your black levels are as they should be. If you need an adjustment you currently can either adjust gamma ("enable gamma processing" and set the target gamma" a bit (lower value = brighter, higher value = darker) or use the brightness slider under the "color & gamma" tab. You should stay away from the "saturation", "contrast" and "hue" slider if possible.

That´s as far as you´re able to go without actually doing any calibration yourself. Depending on the quality and native gamma of your panel and the careness of the implementation of the sRGB mode on your monitor, the results can vary though. It should however look a lot better than non-managed.

Note that you won´t see any difference when just playing with the calibration values themselves. They are however important so that madVR "knows" your settings for appropriate conversions to take place.

Thanks! I'm going to do that and see how that works.

Edit: Okay. I did what you told me but I really didn't notice any difference in color (as expected). In fact, if I make a trade between enable and disable calibration nothing changes. The only thing that made the video a little more darker was gamma processing with "BT.709/601" but you said that "pure power curve" is the one to go, so I'm with that.

[Qotscha]

A little question. Have I understood correctly that "the display is calibrated to the following transfer function / gamma:" setting has no effect on anything if gamma processing is disabled?

[e-t172]

Originally Posted by madshi

I don't think our brain invents pictures. My personal opinion is that 24p/60Hz with smootion motion FRC turned on should ideally look nearly as good as 24p/24Hz, if all goes well, but it shouldn't look better. If it does look better on your display, then I think your display likely can't do 24Hz properly.

I agree that it might just be that my display has poor 24p support. I recently ordered a new colorimeter (X-Rite i1 Display Pro), and from what I've read it is capable of measuring refresh rate down to 0.05 Hz precision. This should remove this unknown from the equation.

I'm wondering why you seem so convinced that FRC 24p@60Hz will never look better than native 24p@24Hz. Keep in mind that 24p@24Hz on a LCD is nowhere near as smooth as a CRT at 24p@48Hz or 24p@72Hz, or a traditional film projector running at double or triple shutter speed. It is plausible that FRC is better at approximating the perceptual effect of the flicker/shutter of a CRT/projector, compared to just using native refresh rates. I'm not saying that's true - we don't have enough data to draw any conclusion yet - but I don't think it's as clear cut as you seem to think. I think we need more feedback on this, especially from people with 24p capable screens so they can compare native 24p with FRC 24p@60Hz. If you'd like to post feedback, please mention the precise model of your display so we can spot patterns (such as correlation with LCD pixel response time and overdrive).

[iSunrise]

Originally Posted by Qotscha

A little question. Have I understood correctly that "the display is calibrated to the following transfer function / gamma:" setting has no effect on anything if gamma processing is disabled?

Yes, that´s correct. madVR currently only uses it to calculate the target gamma if you´re doing gamma processing.

Originally Posted by e-t172

I agree that it might just be that my display has poor 24p support. I recently ordered a new colorimeter (X-Rite i1 Display Pro), and from what I've read it is capable of measuring refresh rate down to 0.05 Hz precision. This should remove this unknown from the equation.

Nice, it would be great if you could give me some feedback on it, since I also wanted to order the same probe, because supposedly it´s also a lot faster and a lot more gamma accurate than my current DTP94B. Also, since you also have an H-IPS results should be very comparable. Currently I´m not so sure if spending another 175 EUR is worth it. Thanks in advance!

[secvensor]

"Disable/Enable" ReClock botton please in menu!

[turbojet]

It's good to see frc works well with ips panels, especially since they are getting cheaper and more mainstream. I was messing around with overdrive and found out that turning it to minimum reduced the ghosting with frc, it was on default 3/5, turning it up increased ghosting with frc. Might be helpful to someone else.

With frc enabled, multiple videos play with out of order frames. If frc is disabled on one of the players the frames are in order but the backbuffers of both sit at 0 causing dropped frames. Is this a bug or a limitation?

[e-t172]

Originally Posted by turbojet

It's good to see frc works well with ips panels, especially since they are getting cheaper and more mainstream. I was messing around with overdrive and found out that turning it to minimum reduced the ghosting with frc, it was on default 3/5, turning it up increased ghosting with frc. Might be helpful to someone else.

It heavily suspect that RTC (Response Time Compensation) overshoot might be the direct cause of some reports of FRC ghosting. Indeed, without FRC you would only see the overshoot 24 times per second when the frame changes, and the duration of the overshoot is small compared to the length of a frame. However, with FRC it would overshoot 60 times per second, which would most likely register as flicker at the edge of moving objects.

As a matter of fact, RTC overshoot on my U3014 is quite bad according to reviews, and I do in fact see flicker when dark objects move on a bright background using FRC 24p@60Hz, compared to 24p@24Hz. Nevertheless, despite this, FRC 24p@60Hz still looks globally better than 24p@24Hz on my monitor.

It would be very interesting to compare FRC 24p@60Hz on a responsive monitor with finely tuned RTC (e.g. gaming monitor) on one side, and 24p@24Hz on a typical LCD TV on the other side. I bet the result would be very interesting.

[turbojet]

Probably is the overshoot mostly responsible. On 2 crt tv's frc works fine, no ghosting, but there you have really fast response without overdrive trickery but leeperry writes his crt's have ghosting with frc.

madshi: Is there a chance for a kb shortcut for toggle overlay and toggle frc for only on\off? I see there's enable and disable frc but that's more tedious than it needs to be, I vaguely remember reading something about this earlier.

e-t172: concerning the display issues at native refresh rates are you sure the monitor is really what it's changing to? When I set 72hz custom resolution there's judder, madvr shows 72hz but reclock shows 60hz. madvr refuses to change to it.

[iSunrise]

Originally Posted by turbojet

madshi: Is there a chance for a kb shortcut for toggle overlay and toggle frc for only on\off? I see there's enable and disable frc but that's more tedious than it needs to be, I vaguely remember reading something about this earlier.

Yes, you read about it before. I requested the toggle for FRC already, but madshi said that some people requested seperate controls and some wanted a toggle, so he wasn´t sold on the idea.

IMHO, a toggle should be for fast access in on/off or true/false cases, too. Seperate controls make a lot more sense when you need to go up as well as down, without having to hammer your keyboard with a toggle, because with a toggle you would (in the worst case) need to go all the way around again if you only wanted to go back/down again. But ultimately it´s madshi´s decision and I respect that.