madVR - high quality video renderer (GPU assisted)

[leeperry]

So I'm trying to put my GPU fan speed evil plan to action, using BarelyClocked.exe (https://bitcointalk.org/index.php?topic=16406.0) but it's no workee atm, any idea please?

http://thumbnails112.imagebam.com/31712/d4953d317110747.jpg (http://www.imagebam.com/image/d4953d317110747) http://thumbnails109.imagebam.com/31712/74a1aa317110749.jpg (http://www.imagebam.com/image/74a1aa317110749)

30% is only here to easily notice the fan speed increase but ideally I want mVR to set the fan speed to 20% while a movie is running and put it back to 18%(inaudible) once my media player is closed. The command lines do work fine on their own and the profile is properly loaded as it would appear :o

a single new variable instead, pixels-per-second.
This would help a lot with lower resolution interlaced material, I want to set higher neuron counts for 480p30 than 480p60 but I also don't want very complex or numerous if statements. I could use the pixels-per-second instead of width, height
Very good point, I can't do 64x NNEDI for any 720p29.97 or <2.35 720p25 so a "pixels-per-second" argument would hit the spot :)

I would also appreciate a way to disable the crash reporter of mVR as PotP would appear to make it crash randomly when using its seamless playback feature.

[seiyafan]

Speaking of color management and monitor calibration, there was a very active discussion on gamma a week ago, then it suddenly died, what was the conclusion? Is 2.2 still the best gamma to use to calibrate monitors instead of sGRB and L*?

[huhn]

How does color management work in the presence of BT.2020? How is BT.2020 content displayed on BT.709 monitors and vice versa? Do you intend to rely on the .3dlut being created against BT.2020? How will you transform into this space? Does madVR detect and respect the --primaries tag? What does it do in the absence of a .3dlut?

Do you do so with constant luminance? Which gamma transfer function do you use to de/encode BT.2020 and BT.709? How will it work moving forwards to a constant-luminance environment? How do plan on dealing with rounding/clipping artifacts on BT.709 and BT.2020 source 3dluts, especially for wide gamut profiles?

When will madVR support .ICC profiles, when will madVR support changing .ICC profiles at runtime (eg. if you move between monitors)?

madvr supports bt 2020. encode tag are readed and used. madvr treats your display as bt 709 so everything that's not bt 709 is transfert to it. you can change this in calibration and bt 2020 is there too, even DCI-p3.

so you don't need a 3d lut a 3d lut is just more accurate than a noraml calibration with a icc file.

[nand chan]

so you don't need a 3d lut a 3d lut is just more accurate than a noraml calibration with a icc file.

Okay, good to know that the monitor gamut is customizable. I don't understand this line though, what do you mean “normal calibration with a icc file”? I thought madVR *only* supports calibration via 3dlut, or has that changed? Won't it generate a 3dlut from the .icc either way? Doing the full ICC calculation at runtime on the GPU seems like an odd thing to do, or does it only extract the primaries/transfer characteristics and implement those, ignoring detailed stuff like LUT tables in the profile?

[e-t172]

Speaking of color management and monitor calibration, there was a very active discussion on gamma a week ago, then it suddenly died, what was the conclusion? Is 2.2 still the best gamma to use to calibrate monitors instead of sGRB and L*?

IIRC the discussion was about the gamma to use in internal madVR dithering/error diffusion algorithms, which has nothing to do with monitor calibration. Regarding monitor gamma the agreed upon standard is ITU-R BT.1886 (http://www.itu.int/rec/R-REC-BT.1886-0-201103-I) and I believe there is now wide consensus on that (at least I haven't seen any compelling arguments against it).

For comparison, BT.1886 is equivalent to 2.4 pure power law on a perfect screen with infinitely deep black levels, and is roughly similar to sRGB gamma on typical IPS screens that have a 1000:1 contrast ratio.

Besides, what the hell is "L* gamma"?

Okay, good to know that the monitor gamut is customizable. I don't understand this line though, what do you mean “normal calibration with a icc file”? I thought madVR *only* supports calibration via 3dlut, or has that changed? Won't it generate a 3dlut from the .icc either way? Doing the full ICC calculation at runtime on the GPU seems like an odd thing to do, or does it only extract the primaries/transfer characteristics and implement those, ignoring detailed stuff like LUT tables in the profile?

I believe when huhn wrote "noraml calibration with a icc file" he meant the vcgt (gamma ramps) that are often found in ICC profiles, which has nothing to do with gamut mapping.

madVR does not support ICC, and as far as I know madshi has no plans to implement it. You're stuck with 3DLUTs which are much less convenient to use. I have no idea how madVR does gamut mapping when you feed it BT.2020 content and ask it to convert it to BT.709. That being said, by generating a 3DLUT using a CMS such as Argyll you can get complete control over the gamut mapping since it becomes the responsibility of the 3DLUT, not madVR's.

[michkrol]

So I'm trying to put my GPU fan speed evil plan to action, using BarelyClocked.exe but it's no workee atm, any idea please?
(cut)
The command lines do work fine on their own and the profile is properly loaded as it would appear :o

I do remember madshi mentioning the command line execution for profiles is not implemented yet. Can't find the exact post right now.

[seiyafan]

IIRC the discussion was about the gamma to use in internal madVR dithering/error diffusion algorithms, which has nothing to do with monitor calibration. Regarding monitor gamma the agreed upon standard is ITU-R BT.1886 (http://www.itu.int/rec/R-REC-BT.1886-0-201103-I) and I believe there is now wide consensus on that (at least I haven't seen any compelling arguments against it).

For comparison, BT.1886 is equivalent to 2.4 pure power law on a perfect screen with infinitely deep black levels, and is roughly similar to sRGB gamma on typical IPS screens that have a 1000:1 contrast ratio.

Besides, what the hell is "L* gamma"?



Here are the options in my calibration software:
http://www.cmp-color.fr/images/nec_profile_5/500.jpg

[e-t172]

Okay, so from a quick Google search it seems L* is a weird gamma spec that has nothing to do with video (it seems more intended for printing or other editing work). Don't use it.

Your software doesn't seem to have an option for BT.1886, which is not surprising (maybe that's what "HDTV (ITU-R)" is referring to but that's not clear from your screenshot). In that case a good approximation is to use sRGB assuming you're using a typical IPS screen (1000:1 contrast ratio).

If you want to have complete control other what you're doing I would recommend using Argyll CMS to calibrate your screen and generate a 3DLUT, but that's more technically involved.

[Niyawa]

I respectfully disagree. Your own experience tells you about only...your own experience. And what is "eye training" anyway? 6233638 says he can easily see single frame drops, and I can too. I think it would be the exceptional case to find someone that cannot. Why do you think people complain about telecine judder? It's only a single field jerk compared to a full frame drop, and yet it is easily detected. Human vision is finely tuned for tracking motion; it's not surprising that we can detect gross discontinuities like frame drops.
Let my clarify. I once couldn't tell when a frame was dropped at all. I know many people close to me who can't either. Those same people can't tell the difference between a TN and IPS screen as well, hell some of my other friends can't even tell when a 4:3 movie was stretched to 16:9. In my case, I've watched many samples and situations where a frame was being dropped/not dropped with the same content, and after some time, it became easy for me to differ stutter and other issues that dropped frames brings (thus the 'eye training', maybe 'eye got used to it' would also be appropriate). There's not much I know, in a technical level at least, about video in general but from both an observation and my own experience I can say with clarity that not everyone perceives the same thing in the same way. So no, you shouldn't be surprised that some people can't tell that a frame is being dropped.

BTW using Bilinear with NNEDI3 is to fill the gap between Jinc3 and N16 x BC75AR, and the gap between N16 x BC75AR and N32 x BC75AR. Sometimes GPU may not be powerful enough for N16 x BC75AR, but enough for N16 x Bilinear. PQ is still better than Jinc3 in most cases.

Lanczos is very close to Bicubic in quality and I don't think it's worth its own level. Maybe level 2a = Bicubic, level 2b = Lanczos. There is a huge gap in both quality and speed between level 1, 2, 3, 4 and 5, while the difference in quality between a and b is very small (that's why I chose "a", "b"; "c' could be Jinc, but the difference between b and c is very small and NNEDI3 x c is too slow for most cases).
Thanks for that link and the summaries.

The only time bilinear made any outstanding difference for me when quality was concerned was with the upscale algorithm, but in chroma it shouldn't be much of a trade-off. madshi told me that the GPU power of bilinear vs any other algorithm is like day and night so if someone is looking to try NNEDI it makes sense. Unfortunately I don't currently possess the hardware to try all of those levels so I appreciate your thoughts on them.

Those graphs are also based on a 1080p>1440p upscale if I'm not wrong, if I could I'd scale the performance data but that's probably not the best way to go about it. I'd like to know what results 720p>1080p would give.

[daglax]

So i did a lot of testing today, if or if not NNEDI is really worth the trouble and i came to the conclusion, that it's not. I don't know what you guys are seeing or believe what you're seeing, but i sometimes think, i'm in a homeopathy-forum.

Here's is a test for you: I took 3 screenshots, one with NNEDI 32 neurons (bicubic upscaling and CR downscaling), one with JAR 4 taps and one with BC75AR upscaling Which one is NNEDI and which are the others?

Pic A (http://www.directupload.net/file/d/3574/j88ifxfg_png.htm)
Pic B (http://www.directupload.net/file/d/3574/435nnss8_png.htm)
Pic C (http://www.directupload.net/file/d/3574/xoqxs32d_png.htm)

All Pics are from a HQ-720p Source.

[*Touche*]

So i did a lot of testing today, if or if not NNEDI is really worth the trouble and i came to the conclusion, that it's not. I don't know what you guys are seeing or believe what you're seeing, but i sometimes think, i'm in a homeopathy-forum.

Here's is a test for you: I took 3 screenshots, one with NNEDI 32 neurons (bicubic upscaling and CR downscaling), one with JAR 4 taps and one with BC75AR upscaling Which one is NNEDI and which are the others?

Pic A (http://www.directupload.net/file/d/3574/j88ifxfg_png.htm)
Pic B (http://www.directupload.net/file/d/3574/435nnss8_png.htm)
Pic C (http://www.directupload.net/file/d/3574/xoqxs32d_png.htm)

All Pics are from a HQ-720p Source.

Haha, I know exactly what you mean :) Looking forward to trying these when I get home. It was reported, though, that NNEDI shows better when SD is upscaled.

[noee]

@daglax:
You should try some NNEDI goodness with SD source material... ;)

[soulkeeper]

So i did a lot of testing today, if or if not NNEDI is really worth the trouble and i came to the conclusion, that it's not. I don't know what you guys are seeing or believe what you're seeing, but i sometimes think, i'm in a homeopathy-forum.

Here's is a test for you: I took 3 screenshots, one with NNEDI 32 neurons (bicubic upscaling and CR downscaling), one with JAR 4 taps and one with BC75AR upscaling Which one is NNEDI and which are the others?



NNEDI 32 for what?
chroma upscaling?
luma doubling?
chroma doubling?
both of them?
720p source...what about screen resolution?

edit: nnedi is (a)
jinc is (b)

[seiyafan]

Here's is a test for you: I took 3 screenshots, one with NNEDI 32 neurons (bicubic upscaling and CR downscaling), one with JAR 4 taps and one with BC75AR upscaling Which one is NNEDI and which are the others?

Pic A (http://www.directupload.net/file/d/3574/j88ifxfg_png.htm)
Pic B (http://www.directupload.net/file/d/3574/435nnss8_png.htm)
Pic C (http://www.directupload.net/file/d/3574/xoqxs32d_png.htm)

All Pics are from a HQ-720p Source.

I am staring at my 19'' Eizo at work at 6 inches from the screen, I can see every individual pixel, but I can't see any difference. :o

I noticed that two of them seem to be sharper than the third one when I am 4 inches from the screen, but then that's not how I watch movies. LOL!

[wolfman2791]

Are my eyes deceiving me or does downsampling provide the best picture there is? Downsampling 3600x2025 60Hz.

[Thunderbolt8]

So i did a lot of testing today, if or if not NNEDI is really worth the trouble and i came to the conclusion, that it's not. I don't know what you guys are seeing or believe what you're seeing, but i sometimes think, i'm in a homeopathy-forum.

Here's is a test for you: I took 3 screenshots, one with NNEDI 32 neurons (bicubic upscaling and CR downscaling), one with JAR 4 taps and one with BC75AR upscaling Which one is NNEDI and which are the others?

Pic A (http://www.directupload.net/file/d/3574/j88ifxfg_png.htm)
Pic B (http://www.directupload.net/file/d/3574/435nnss8_png.htm)
Pic C (http://www.directupload.net/file/d/3574/xoqxs32d_png.htm)

All Pics are from a HQ-720p Source.
they are not the same frame. so this comparison is pretty void.

and they are not even full 1920p pics?

[Shiandow]

Here's is a test for you: I took 3 screenshots, one with NNEDI 32 neurons (bicubic upscaling and CR downscaling), one with JAR 4 taps and one with BC75AR upscaling Which one is NNEDI and which are the others?

Pic A (http://www.directupload.net/file/d/3574/j88ifxfg_png.htm)
Pic B (http://www.directupload.net/file/d/3574/435nnss8_png.htm)
Pic C (http://www.directupload.net/file/d/3574/xoqxs32d_png.htm)


You should probably correct for the fact that NNEDI shifts the image slightly, it's now pretty trivial to see which used NNEDI.

Edit: Also it would be easier if you could link to the full size image, having to manually search for the link in that page is somewhat tedious.

[Thunderbolt8]

these are not even full sized images. the file is 1080p resolution, but the part of the movie image is not -.-

[daglax]

Hey,
it's pretty hard to get every picture at the exact same frame. If you have a trick, be free to tell me :).

I choosed a better image hoster to allow fullscreen comparison, here are the links:
PIC A (http://postimg.org/image/56f7cnw1f/full/)
PIC B (http://postimg.org/image/42v30pbeb/full/)
PIC C (http://postimg.org/image/jab2l238z/full/)


Oh and someone asked, which NNEDI setting i choosed: It was luma image doubling. Chroma at BC75AR and Fullscreen Exclusive Mode off.

Maybe there is more difference on a SD-source, but to be honest: Most of us don't watch this anymore.
And maybe some of you guys can post screenshots to prove me wrong (and not from one of these stylized theoretical images, but from a true movie source). I'd be glad to notice a real impact on image quality as I'm seeking always for the best possible :)

PS: Be aware that these screenshots are taken on a rig with a single Nvidia 760 GTX with 327.23 drivers. All on a 1080p monitor.

[jkauff]

Maybe there is more difference on a SD-source, but to be honest: Most of us don't watch this anymore.

You're obviously not a movie collector. 75% of my collection is in SD, because those movies have never been released on Blu-ray.

I don't bother with doubling for Blu-ray (thanks for Profiles, madshi!), but it makes a huge difference with lower resolution sources.

[Ver Greeneyes]

Hey,
it's pretty hard to get every picture at the exact same frame. If you have a trick, be free to tell me :).In MPC-HC, go to the Navigate menu and select Go To..., then select the frame you want and press Go! :) The second number is the frame rate - just leave that set to whatever it currently is.

[daglax]

I will test that tomorrow and i'll test SD-sources, too. I tried NNEDI for a short time on a recorded LQ-football game today and i noticed a slight difference, but again not very apparent.

PS: I sold all of my DVDs due to switching to BluRay, so yeah :-D.

[QBhd]

It almost looks like NEDDI3 for luma doubling is NOT being used. Do you have the "always use" selected? And please, at least use the same frame... you can jump to any frame you want in almost any player.

QB

[daglax]

Of course it's enabled via "always use". And as i said i'll make some new screenshots tomorrow. Feel free to post some by yourself and prove me wrong. :)

[QBhd]

My target window is very different, so my results would be very meaningless to most here. I have a TV that has rectangular pixels at 1024x768 (720p plasma circa 2007) so for 720p sources I need upscaling and downscaling at the same time :)

QB

[renethx]

Those graphs are also based on a 1080p>1440p upscale if I'm not wrong, if I could I'd scale the performance data but that's probably not the best way to go about it. I'd like to know what results 720p>1080p would give.
The levels apply to all scaling factors like this:

http://cdn.avsforum.com/d/da/da027fcd_madVRR7260X.PNG

The main purpose is to give a quick performance chart of each GPU: buy a correct graphics card and get the most out of it by setting "profiles".

[Asmodian]

Hey,
it's pretty hard to get every picture at the exact same frame. If you have a trick, be free to tell me :).

I choosed a better image hoster to allow fullscreen comparison, here are the links:
PIC A (http://postimg.org/image/56f7cnw1f/full/)
PIC B (http://postimg.org/image/42v30pbeb/full/)
PIC C (http://postimg.org/image/jab2l238z/full/)

Thanks for the effort but not the same frame means a screenshot comparison does not work. I believe you that you don't notice the difference for 720p -> 1080 on your screen.

I like NNEDI for below or at 720p -> 1440, using 32 neuron doubling followed by downscaling for 1080p -> 1440p is very subtle. 32 neuron + CR-AR-LL, 1080 -> 2160 -> 1440 does give a very mild sharpening effect but the difference between NNEDI3 128 and Jinc3 for 720p -> 1440 is much more significant.

Personally I don't really like upscaling anything under 2.0 with NNEDI. Thanks for the options madshi. :)

[seiyafan]

For comparison, BT.1886 is equivalent to 2.4 pure power law on a perfect screen with infinitely deep black levels, and is roughly similar to sRGB gamma on typical IPS screens that have a 1000:1 contrast ratio.



So in MadVR I need to select "BT.709" "pure power curve" "2.40", right?

[James Freeman]

So in MadVR I need to select "BT.709" "pure power curve" "2.40", right?

There is no right or wrong here, there is personal chioce.
I find 2.4 is too dark in any of the environments I watch movies.

The default 2.2 is a good start.
If your room is dark and the picture looks "flat" and bright, you can raise gamma till you sense more depth.

Try doing this without actually looking on the gamma value, look only on the picture.
Don't be surprised if you go up and down only to settle back on 2.2.

[scollaco]

There is no right or wrong here, there is personal chioce.
I find 2.4 is too dark in any of the environments I watch movies.

The default 2.2 is a good start.
If your room is dark and the picture looks "flat" and bright, you can raise gamma till you sense more depth.

Try doing this without actually looking on the gamma value, look only on the picture.
Don't be surprised if you go up and down only to settle back on 2.2.

I played around for the longest time too...and settled on 2.2 looking the best. And I'm in a completely light controlled theater.

[e-t172]

So in MadVR I need to select "BT.709" "pure power curve" "2.40", right?

No. BT.709 should never be used for monitor gamma. BT.709 defines camera (capture) gamma, not rendering gamma. madVR doesn't provide an option for BT.1886 (nor sRGB). If you can use Argyll or other calibration software to achieve BT.1886 gamma, then do it. If not, then I suggest you keep madVR gamma options at their neutral values or you might just eyeball it (worse than nothing, I guess).

There is no right or wrong here, there is personal chioce.

No. There is a standard for this and it's called BT.1886 (http://www.itu.int/rec/R-REC-BT.1886-0-201103-I). It is best to follow the standards if you want to get as close as possible to the artist's intent. If you disagree, please provide actual arguments ("I don't like it" isn't one).

It is true that ideal gamma depends on viewing conditions, but if you want to go that route there are even more sophisticated options to compensate for that (such as CIECAM02 (http://en.wikipedia.org/wiki/CIECAM02)), which are backed by actual numbers. But I don't think there's a need for this if your room is already pitch black.

[StinDaWg]

If I wanted to keep some more of the sharpness effect from nnedi, is there anything "wrong" with using Lanczos 4 AR for downsizing after nnedi doubling instead of CR AR? All I ever see recommended for downsizing is CR AR.

[James Freeman]

BT.1886 sucks, and I don't like it. :D

Actually on a low-ish CR (1000:1) Monitor/TV I much prefer Black Compensated Power Curve, because it gives better apparent depth and darker shadows (not crushed, just denser), whether BT.1886 may be too bright.
Most Monitors/TVs are calibrated to power curve with black compensation anyway and not BT.1886.
On TV's, playing with the Brightness control will also change the gamma cure with it.

e-t172,
If seiyafan knew about BT.1886 he would not be asking about what basic settings to use, isn't he?
BT.709 he was referring to in his post is the Color Space, not the gamma curve.

[ryrynz]

If I wanted to keep some more of the sharpness effect from nnedi, is there anything "wrong" with using Lanczos 4 AR for downsizing after nnedi doubling instead of CR AR? All I ever see recommended for downsizing is CR AR.

Nothing wrong with it what-so-ever. Recommendations are generally based upon user preference.

[Vyral]

I may have miss something, is Linear Light not used anymore with Catmull-Rom + AR for downscaling ?

[6233638]

I may have miss something, is Linear Light not used anymore with Catmull-Rom + AR for downscaling ?I would use it if your system can handle that.

I had another look over the downscaling options again recently and it still seemed to produce the best image quality.


I would not suggest using linear light with any of the other options though - up or downscaling.

[seiyafan]

Sorry, I meant color space, the choice above the gamma options.

[e-t172]

e-t172,
If seiyafan knew about BT.1886 he would not be asking about what basic settings to use, isn't he?
BT.709 he was referring to in his post is the Color Space, not the gamma curve.

Sorry, I meant color space, the choice above the gamma options.

Yes, sorry, my bad. If I had paid more attention I would have noticed that "BT.709 pure power curve" in seiyafan's question doesn't actually make any sense in the way I interpreted it.

[madshi]

This in know problem with ISR and madVR and how they handle subtitles for DVD or timing in fact.

[...]

This build should resolve this issue
Thanks for the fix! :)

I'm using the vanilla MPC-HC standalone VSfilter v1.7.3 here
In 0.87.4 and all previous versions of madVR (and all the other video renderers), switching the subtitles language while a video is playing "froze" the image for an extremely small amount of time and subs started appearing.
In 0.87.5 and newer, switching the subtitle language while a video is playing has madVR display a black screen (!), then the image comes back with the newly selected subs.
But why would changing the subtitle track result in an exclusive -> windowed switch? Sounds weird to me. Anyway, please create a bug tracker entry for this with an exact description of the situation, e.g. exclusive mode or not. Also please try other subtitle renderers, to find out whether the problem also occurs with e.g. xy-vsfilter, or XySubFilter. Thanks.

another parallel random number implementation. I know, you've already found one and I don't know how this will perform or if it evenapplicable, just posting it here for info.
That doesn't look like it will give a uniform random number at all, especially when s_uRandSeed is small, and when s_uRandSeed is too large s_uRand won't have enough significant bits. As far as I know the random number generator that MadVR uses is faster and more reliable.
^

I have a problem with the full screen mode of madvr.
The default settings deactivate AERO in Windows 7 and my TV say that:

[...]

If I deactivate these settings in madVR, I don't get the problem.

[...]

I use madVR plugin of MeediOS.
Do you have madVR setup to switch display modes for you? Or do you have the display mode switcher disabled? madVR itself does not activate 3D modes. It seems that the NVidia driver does that somehow, when madVR goes fullscreen. But I can't see how that would be my fault, considering that I don't ask for 3D output. Your GPU seems to send 1080p60 in 3D to the display, or something like that...

does Nvidia's edge enhancement feature work with madVR. From what I did as a quick test it didn't. Once I switched to EVR it did. Is this a known thing. Sorry if the question is silly.
It does not. madVR intentionally by-passes all GPU processing algorithms.
^

Normally the GPU processing algorithms are not activate when using madVR, and that's intentional because I don't consider the GPU algorithms to be very good.

However, if you use DXVA deinterlacing or DXVA scaling, and if you force the edge enhancement setting on (instead of letting the application decide) in the GPU control panel, it might become active in madVR, too. I don't recommend to do that, though.

I noticed a strange behavior in madvr running an avisynth framedoubling script.
The avisynth-script doubles the source framerate, let's say to around 48 fps, but if i hit ctrl + j madvr still says, that the video frame rate is 23.976 fps.
It's not madVR's fault. ffdshow/AviSynth incorrectly reports 24fps to madVR in this situation. This should be fixed in ffdshow, but it will be hard to find a developer to do that.

Is this something easy to implement and actually worth it?

I like profiles a lot but I would like the ability to multiply in the if statement or maybe a single new variable instead, pixels-per-second.
This would help a lot with lower resolution interlaced material, I want to set higher neuron counts for 480p30 than 480p60 but I also don't want very complex or numerous if statements. I could use the pixels-per-second instead of width, height, and deintfps so 480p60 would automatically use my 720p30 profile and 720p60 would automatically use my 1080p30 profile. :D
I don't think that's a good idea. E.g. 480p60 could mean that NNEDI3 is used for frame doubling, and that 60 times per second. While 720p30 might disable NNEDI3 and at the same time only require 30 frames per second to be rendered. Generally the framerate is much more important for rendering performance than the source resolution. Because of that I don't think "pixels-per-second" is a good metric. I could of course add support for multiplications, but that would cost quite a bit of time to implement, so I have to say "no" for the time being, because only few users would use that, and I've lots and lots of other things to do.

First and last aren't exclusive to madVR. Pretty much any decent video player will have them, including MPC-HC out of the box. Smooth motion does more harm to the picture than good (IMO). I use IVTC all the time, very handy. Anyways...
FWIW, to my best knowledge the FSE mode in most other video renderers is a very simple implementation. It's almost the same as windowed mode, the renderer just tells Direct3D to go exclusive. Doing so does have benefits: No tearing, and better rendering performance. However, it's no comparison to what madVR is doing: In FSE mode, madVR is rendering many frames in advance and feeding them to Direct3D, a "long" time before they actually need to be displayed. As a result the GPU driver can simply flip to the next frame with every consecutive VSync hardware interrupt. Even if you suspend the media player via taskmanager, video playback will still continue to run smoothly for several frames in madVR FSE mode. This is very different to what most other players do in their FSE implementation, AFAIK.

The effectiveness of smooth motion FRC depends on the source framerate and display refresh rate, and probably also on the display technology. On my computer monitor and my projector smooth motion FRC works *great*. With 24fps @ 60Hz it looks very near to native 24fps @ 24fps. However, I think if the LED backlight of an LCD display pulses in a "weird" way, it might conflict with the way smooth motion works, which could damage the effectiveness of the algorithm. FWIW, my computer monitor has a CCFL backlight.

i just upgraded my GPU from a 5750 to a 280x but my motherboard is a PCI-E 2.0 and when i tried NNEDI3 "64 neurons" it cant handle it but its ok at "32 neurons", material is 1080p24 High-Bitrate and ffdshow is set to output 16bit P016. Could that be that my PCI-E is to slow? Do i need to upgrade? I'm very bad at all this but i really try to learn.. :(

lost frames seems to be way better with P016 then at RGB32 if that makes any sense..... but i get artifacts in windows when i use P016 and NNEDI13.
Are you doing AviSynth processing, or why are you letting ffdshow convert the colorspace? If you don't use AviSynth scripts, I'd recommend using LAV Video Decoder instead of ffdshow, and then let LAV simply output NV12.

AMD GPUs have high OpenCL interop cost. I'm not sure how much the interop cost is a problem in your case. There's not much I can do about it, in any case. We'll have to hope for an AMD driver fix (I'm not optimistic), or maybe wait for NVidia to fix their driver problem (slightly more optimistic about that) and for faster Maxwell GPUs.

madshi, what are your thoughts on using sharpening filters in combination with nnedi doubling? nnedi gives a very nice, sharp, artifact and ringing/aliasing free picture, but I still prefer a bit more sharpness for 720p->1080p scaling. I'm using LumaSharpen at very low values pre-resize, just enough to take out the little bit of softness that is left over from upscaling, nothing more. I think the picture looks pretty much perfect, but I'm wondering if this works against nnedi at all or its just one of those things "do what you think looks best".
I believe sharpening *after* upscaling is usually much better than *before* upscaling. E.g. see here for a small comparison:

| -- original (http://madshi.net/castleOrg.png) -- | -- NNEDI3 doubling (http://madshi.net/sharpenDisabledNNEDI.png) -- | -- sharpen before NNEDI3 doubling (http://madshi.net/sharpenBeforeNNEDI.png) -- | -- sharpen after NNEDI3 doubling (http://madshi.net/sharpenAfterNNEDI.png) -- |

Ok, this is rather strong sharpening (probably too strong), using some AviSynth algorithms. But it nicely shows how sharpening after upscaling works much better than sharpening before upscaling - at least when using NNEDI3.

I don't think I should recommend whether sharpening should be used or not. I think everybody should decide for himself. I do think when using large upscaling factors, some sharpening might make sense to get rid of the softness caused by upscaling.

madshi, any thoughts about the impact of dithering on the motion interpolation algorithms in modern HDTVs?
No idea. I don't think it should make much of a difference, but I don't really know.

That sounds like your best option would be to disable dithering altogether (use simple rounding)
No. Please don't ever do that.

*Every* single hardware and software component has been swapped. Completely fresh hardware with fresh Windows install and testing multiple driver versions. These frame drops keep haunting me everywhere I go. At this point I'm starting to wonder if I'm not becoming insane.
Are you using FSE mode? In FSE mode with smooth motion FRC on, I would not expect any framedrops. If you do get them, upload a debug log for me to look at. Then maybe I can say something about possible causes...

Actually, the chance of seeing a dropped frame is very high, because your eyes are open much longer than they are closed. The chances that your blinks exactly match all the drops is minuscule.
Agreed. However, some movie scenes have a lot of motion, while others can be almost static. If there's only little motion (e.g. just a person talking without moving much), I guess it's possible to not notice a random frame drop once in a while. As soon as there's sufficient motion, though, I think most people would notice frame drops quite easily.

When playing a DCI video, I can see a colour cast in the image. Even when playing a Bluray video, if primaries are forced as DCI-P3 or "this display is calibrated to the following primaries/ gamut: DCI-P3" is selected, the colour cast can be seen in the image.
Forcing a Blu-Ray to DCI-P3 primaries must introduce a serious color cast because that's not how Blu-Rays are encoded. And setting your display "is calibrated to DCI-P3" must also introduce a serious color cast - unless that's really how your display is calibrated. However, if you have a real DCI-P3 video, switching the primaries to DCI-P3 should produce proper colors, I would think.

I think it's due to a shift in the white point, if there is no bug in madVR (this doesn't happen with BT.2020). So I was wondering if madVR could also do white point matching of the source with the display white point while performing gamut conversion so that DCI content can be viewed on regular monitors without any colour cast in the image.
The white point is taken into account somehow in the math I'm doing. But it's been a while since I looked into that, so I don't remember the details. Maybe something is wrong there. Maybe I would need more complicated math to properly change the white point. If you have a true DCI-P3 video which you know for a fact should look correct when played properly, and which looks incorrect in madVR with primaries set to DCI-P3, then please create a bug tracker entry. However, please don't do that if you're not sure yourself. I don't have the time to go guessing how the video should look. So it should be very clear and without any doubt how it should look, so I can really see if there's anything wrong, and if maybe a fixed madVR build corrects the problem.

BTW, does 3dlut take the source white point as input or it always assume the source white point to be D65?
You can select a separate 3dlut for every colorspace, including DCI-P3. Obviously madVR expects the 3dlut to have a white point matching the colorspace it was made for.

I think I found a bug. When I enable BOTH NNEDI3 chroma upscaling and luma doubling, I get frame drops (2 frames per second) when the rendering time is less than the dropping theshold (~41ms), however if I choose a chroma upscaling other than the NNEDI3, I don't get frame drop even if the rendering time is longer than that of the above, as long as it's less than the threshold.
While I don't doubt your observations, I don't think there's anything I can do about this. This is not likely a bug in madVR, but some sort of effect of mixing D3D9 with OpenCL and having interop involved etc etc...

Since I've been using NNEDI3 and Error Diffusion I have really noticed a jump in quality in my front projection setup. I have just purchased an Oppo 103D and plan to use its Darbee processing in combination with MadVR. Now I've just read that the Darbee in the Oppo automatically converts any signal to YcBcR 4:2:2, where it does its internal processing (I earlier thought that the processing was done in the color space that was sent into the unit, but appareantly only the standalone Darblet does this).

So my question is if using MadVR to output RGB to the 103D is worthless because of the 103D's internal color space conversion? Or am I still going to take advantage of some of MadVR's greatness? :confused:
You didn't say whether you use NNEDI for luma doubling or chroma upscaling, so I can't really answer your question.

In any case, why don't you simply try all possible combinations and then report back here which one produces the best overall image quality in your opinion? Please also try sharpening via a custom pixel shader (e.g. see LumaSharpen) or via AviSynth, as an alternative to the Darbee sharpening. Would be interesting to have a shootout between those different options.

I do remember madshi mentioning the command line execution for profiles is not implemented yet.
Correct.

So i did a lot of testing today, if or if not NNEDI is really worth the trouble and i came to the conclusion, that it's not. I don't know what you guys are seeing or believe what you're seeing, but i sometimes think, i'm in a homeopathy-forum.
The benefits of a good scaling algorithm are visible only with reasonably high scaling factors. Whether 720p -> 1080p is a large enough scaling factor I don't know. It's your job to judge that, not mine, I'm just giving you all the options. Of course the bigger the scaling factor, the more difference you will see.

Consider playing back a 720p video on a 4K display. Suddenly it's not an 1.5x scaling factor, but 3.0x. And this going to be needed sooner or later...

I have nnedi3 working on GTX660/GK106 and Nvidia 335.23 drivers (and, it's 20% faster). I blocked deleting of OpenCL/D3D interop images between frames (madvr gets existing instances mapped to IDirect3DTexture9*) and it seems to fix the problem entirely.
Sneaky!! :sly:

Just tried that here, using 335.23 with my NVidia 650, using Windows 8.1 x64, but I can't seem to get it to work. Have you just blocked the clReleaseMemObject() calls? Or did you do something else?

[daglax]

Wow thanks for that HUGE answer!
the thing about sharpening was very interesting indeed. How did you get avisynth to sharpen after resize, if you do upscaling with madvr? That's iafaik not possible due to the fact, that madvr is always the last "filter" in the row.

[leeperry]

Hi madshi, sorry to ask again but would you know whether the command-line thingie will work in the next build? Or it low-priority? I'd really love to get this graphic board inaudible when my media-player closed :)

:thanks:

[madshi]

How did you get avisynth to sharpen after resize, if you do upscaling with madvr?
I did not. For those screenshots I let AviSynth do NNEDI3 upscaling.

would you know whether the command-line thingie will work in the next build? Or it low-priority? I'd really love to get this graphic board inaudible when my media-player closed :)
I don't know. In any case, the command line stuff will be activated when profiles change, it's not activated when the media player closes.

[StinDaWg]

The effectiveness of smooth motion FRC depends on the source framerate and display refresh rate, and probably also on the display technology. On my computer monitor and my projector smooth motion FRC works *great*. With 24fps @ 60Hz it looks very near to native 24fps @ 24fps. However, I think if the LED backlight of an LCD display pulses in a "weird" way, it might conflict with the way smooth motion works, which could damage the effectiveness of the algorithm. FWIW, my computer monitor has a CCFL backlight.
I have a 60hz Panasonic plasma. When using 24p content at 60hz there is a lot of ghosting with smooth motion on. There is some judder normally, but with smooth motion turned on everything just has a weird look to it. As yes, I am aware of what proper 24p playback is supposed to look like.

I believe sharpening *after* upscaling is usually much better than *before* upscaling. E.g. see here for a small comparison:

| -- original (http://madshi.net/castleOrg.png) -- | -- NNEDI3 doubling (http://madshi.net/sharpenDisabledNNEDI.png) -- | -- sharpen before NNEDI3 doubling (http://madshi.net/sharpenBeforeNNEDI.png) -- | -- sharpen after NNEDI3 doubling (http://madshi.net/sharpenAfterNNEDI.png) -- |

Ok, this is rather strong sharpening (probably too strong), using some AviSynth algorithms. But it nicely shows how sharpening after upscaling works much better than sharpening before upscaling - at least when using NNEDI3.

I don't think I should recommend whether sharpening should be used or not. I think everybody should decide for himself. I do think when using large upscaling factors, some sharpening might make sense to get rid of the softness caused by upscaling.
The reason I am using it pre-resize is because I don't like what sharpening does to a 1080p source that does not need re-sized. It just makes the video oversharpened since it doesn't need sharpening in the first place. There is no way to set up profiles in MPC-HC for shaders, so I either have to have it always on or always off. Perhaps if shaders could be incorporated directly into madVR options it would allow us to set up rules for when to use them or not like we currently have with the other options.

I'm still looking for a good sharpen algorithm that does not touch contrast and brighten the image. Even LumaSharpen does this and I am not a fan of it.

[jmonier]

But why would changing the subtitle track result in an exclusive -> windowed switch? Sounds weird to me. Anyway, please create a bug tracker entry for this with an exact description of the situation, e.g. exclusive mode or not. Also please try other subtitle renderers, to find out whether the problem also occurs with e.g. xy-vsfilter, or XySubFilter. Thanks.

When I saw the original post, I checked my system and it was indeed showing a brief black when switching between subtitles or from no subtitles to a subtitle. It did NOT show when going from subtitles to NO subtitles. I am using xy-vsfilter (xySubFilter in Zoomplayer is a pain right now so I'm not going to try it).

There is no reason that I can see (in my setup, at least) for it to switch to windowed at this time. I'm not even sure that it happens in madVR, it might be in LAV Splitter, for instance.

That said, I had never even noticed it before my attention was called to it. For me, it's not a problem. It's actually something that I would expect when making switches of this sort.

[e-t172]

Are you using FSE mode? In FSE mode with smooth motion FRC on, I would not expect any framedrops. If you do get them, upload a debug log for me to look at. Then maybe I can say something about possible causes...

Yes, I am always using the madVR defaults. Reading your reaction I think you didn't notice that this is the same problem as the one I reported days ago, for which I already provided logs. This should ring a bell (http://forum.doom9.org/showthread.php?p=1673653#post1673653). It's surely difficult to keep track of things considering the frenetic activity in this thread :) Maybe I should start a Google doc describing the huge list of steps I've taken to isolate this problem (with no success so far).

I've tried all suggestions I could find including the latest ones in this thread, and they don't help. Again, to put this into perspective, this problem is reproducible even after swapping the *entire* hardware chain (GPU, motherboard, CPU, RAM, PSU, monitor, system drive, I've even tried keyboard and mouse), all software (fresh Windows install, across widely-spaced nVidia driver versions, across different media players, across different madVR versions), and after trying a long list of hacks (madVR configuration changes, Windows kernel changes, disabling power management, disabling BIOS features, enabling MSI in the driver etc.).

What's really puzzling is that I seem to be the only one in this thread who's experiencing this problem: how likely is that considering that even a complete hardware and software replacement (at that point it's equivalent to testing on another fresh PC entirely) doesn't fix the issue? To add insult to injury, I asked a friend to try to reproduce this and he got the exact same issue on TWO different machines (both with nVidia GPUs as well), bringing the successful independent reproduction count to a whopping 4! At this point I am completely flabbergasted that some people in this forum manage to make it work.

I know people in this thread will disagree with me on this, but my extremely thorough testing points very strongly to either a bug within madVR, or an extremely persistent nVidia driver bug that's been there since at least 321.10 (from December), affecting at least the 770 and the 780 Ti. I'm leaning towards the former because I've recently realized that using my Haswell's integrated Intel HD IGP produces the exact same issue as well (!) though I need to confirm that.

Remember the 10-15 millisecond GetRasterStatus() latency spikes I was seeing in XPerf from my linked post above? I still get them even after the aforementioned hardware and software changes. I don't have any proof of this, but it really smells like they are, in fact, the cause of this issue, or at least a highly-correlated phenomenon. Consider the following:

Every 5-7 seconds or so, GetRasterStatus() blocks for an abnormally long amount of time in the 10-15 millisecond range.
Let's assume that during that time the GPU is frozen and unable to swap buffers for frame presentation. The blocking GetRasterStatus() could be a cause or a symptom of that.
The refresh rate is 60Hz, which means that we should still be fine as long as the GPU does not block for more than 16.6 milliseconds.
Race conditions, clock variations, timing issues, jitter and the like cause small variations in the amount of time the GPU blocks. Let's assume that, statistically, for every "block" event (which happens every 5-7 seconds) there is a ~0.3% probability that the GPU will block for more than 16.6 ms, resulting in a frame drop.
That would result in one lone frame drop every 30 minutes or so, which is exactly what I'm seeing.

Of course I still have no way to know for sure if that is actually what's happening but it sure fits. It might be a bit of a stretch, but I would go so far as to postulate that everyone have this GPU freeze problem, and the reason why some people never actually see frame drops is because their freezes get close but never above 16.6ms because they got "lucky" with some hardware/software combination. One argument that corroborates this is that I seem to be able to reduce the frequency of frame drops (but never remove them entirely) by disabling CPU power management in BIOS (which arguably would have the effect of slightly reducing timing variations). However I would expect that frame drops become absolutely unavoidable when using high refresh rates such as 120Hz.

My scenario also neatly explains why some people need to use weird tricks to remove frame drops, like forcing their GPUs into P0 mode (again, reducing timing variations that make GetRasterStatus() cross the deadly threshold).

I've tried using API Monitor (http://www.rohitab.com/apimonitor) to get another perspective but apparently it has a known issue of not being able to intercept most D3D calls.

madshi: here are a few things that you can provide that might help me investigate further:
I can provide another set of logs for you. The ones that I provided in my linked post might not provide completely reliable information because I suspect an unrelated nVidia driver regression got mixed up in there.
Debugging symbols for madVR.ax so that I can get better visibility as to what madVR is doing when the issue occurs (stack traces in XPerf)
A build with extra-verbose logging centered around GetRasterStatus() calls (especially time spent), and ideally some human-readable timestamps to accurately anchor the start-time-based millisecond counter for comparison with XPerf results
What would be perfect would be to have a test-only build that never calls GetRasterStatus() - maybe emulate it using a dumb clock, even if that results in tearing? - but I'm guessing that would probably be tricky and take too much of your time

I'm planning on spending this week-end (again) to continue this investigation, but having access to more detailed logging and profiling information would really help me here.

[cyberbeing]

@madshi

What is the status on 0000158: Green image when NNEDI3 chroma scaling is used with video deintelacing (http://bugs.madshi.net/view.php?id=158)? It's been quite a few releases now, and it's still marked as new.

I'm using the vanilla MPC-HC standalone VSfilter v1.7.3 here
In 0.87.4 and all previous versions of madVR (and all the other video renderers), switching the subtitles language while a video is playing "froze" the image for an extremely small amount of time and subs started appearing.
In 0.87.5 and newer, switching the subtitle language while a video is playing has madVR display a black screen (!), then the image comes back with the newly selected subs.But why would changing the subtitle track result in an exclusive -> windowed switch? Sounds weird to me. Anyway, please create a bug tracker entry for this with an exact description of the situation, e.g. exclusive mode or not. Also please try other subtitle renderers, to find out whether the problem also occurs with e.g. xy-vsfilter, or XySubFilter. Thanks.

I can confirm this 'cosmetic' change in behavior, and would somewhat agree that having a frozen frame is a bit more visually pleasing for these graph stop/start events required for switching embedded subtitles at the splitter level.

madVR 0.87.4 = brief frozen video frame when switching subtitle tracks
madVR 0.87.5-0.87.7 = brief frozen black frame when switching subtitle tracks

It's not a exclusive -> windowed switch. It occurs even in windowed mode without any subtitle renderer. Whatever the case, going from 'frozen video frame' to 'frozen black frame' when these graph restarts occur, seem to be a side-effect of some change you made in 0.87.5+

[leeperry]

In any case, the command line stuff will be activated when profiles change, it's not activated when the media player closes.
Alright, thanks for the reply. I'll cook a custom fan speed curve in MSI Afterburner then :)

[daglax]

The reason I am using it pre-resize is because I don't like what sharpening does to a 1080p source that does not need re-sized. It just makes the video oversharpened since it doesn't need sharpening in the first place. There is no way to set up profiles in MPC-HC for shaders, so I either have to have it always on or always off. Perhaps if shaders could be incorporated directly into madVR options it would allow us to set up rules for when to use them or not like we currently have with the other options.

I'm still looking for a good sharpen algorithm that does not touch contrast and brighten the image. Even LumaSharpen does this and I am not a fan of it.
You should not use MPC's built-in sharpeners, because they are really bad.
Try Avisynth with ffdshow instead and you can have your profiles for sharpening plus sharpening with avisynth allows far more superior quality (just look at madshis images)

[Shiandow]

You should not use MPC's built-in sharpeners, because they are really bad.
Try Avisynth with ffdshow instead and you can have your profiles for sharpening plus sharpening with avisynth allows far more superior quality (just look at madshis images)

How do you apply Avisynth after upscaling?

[seiyafan]

Here's a list of high-end graphics card I have had grouped according to their MadVR performance.

Tier 1: 290, 290x
Tier 2: 780, 280x
Tier 3: 770
Tier 4: 270x

My biggest surprise is that 780 performs much closer to the 280x, in fact it's slower than 280x in some occasions, especially with ED turned on. We all know 780 is faster than 280x in every game, so I am guessing the MadVR performance has something to do with memory bus width? 290 is noticeably faster than the 780.