madVR - high quality video renderer (GPU assisted)

[sunnah]

Originally Posted by edragon

I use mpc+madvr+ffdshow video audio+haali +SVP+reclock

but i do not use LAV
video use soft decoding

maybe gtx570 is much greater than gtx550ti.....

Of course the difference between the cards is truly big.

Well hardware decoding with CUVID could really help to decrease your processor intensity and it will put it into your graphic card. It's more efficient that way.

There are many tutorials, I think you should give it a try with your favourable MadVR settings.

[madshi]

Originally Posted by Moony349

If you set MadVR to 16-235 you're getting 1 video card up-conversion, 1 video card down conversion:

16-235 source
MadVR converts to RGB; upsamples chroma in 16-235 colorspace (No BTB/WTW color information at all)
After MadVR, video card converts 16-235 to 0-255, does its thing
Video card converts back down to 16-235 and outputs 16-235

If you set the video card to 0-255 then it does not do any conversion on its own. (At least it should not.) That's why I recommend to set the video card to 0-255. The only conversion should be done by madVR because it does it in high bitdepth with dithering. So set the video card to 0-255 and then switch between 16-235/0-255 in madVR, depending on whether your display supports 0-255 or not.

Originally Posted by turbojet

Thanks for considering. Speaking for myself, playing with resizers are the fun part, not the complicated part. The complicated part being the tweaks and queues needed to get it to work on various video cards. With the latest nvidia drivers out now the only default thing I need to change to work as expected is the queues to 4/4, rest being optional. Maybe a simple setting that hides all the tweaks and things that don't need to be touched by most with defaults could simplify the gui.

Bicubic's negative blur makes things 'pop' like the the aforementioned darbee darblet for free. Leaving default at 0 would behave as current bicubic and users may find something they really like by adjusting blur, like me. Negative blur is becoming a common suggestion to gain sharpness without affecting speed in avisynth.

Well, I would much rather implement a *real* sharpening algorithm, to be honest. That's why I'm also reluctant offering so many more tweaks: It costs many hours of my time which I could instead spend on doing the "real thing". Personally, I don't like Darbee pop at all. I much prefer something like Didee's FineSharp. So if you ask me to add this and that, and a couple of other tweaks in between, basically you're keeping me busy with so-so stuff, instead of allowing me to move on to bigger and greater things. I've said it so many times before: Let me first add all the missing features, before spending my time by twiddling with 1% improvements. I'm feeling held back at the moment, by all the constant requests for small tweaks and changes everywhere. Aren't you guys interested in getting things like custom shader support, 3D support etc?

Originally Posted by turbojet

It's a very interesting thread, would be nice to be able to test everything in it on videos, only thing I could find is an image reader based on an old imagemagick version. Like you said avisynth plugin devs haven't given it attention but it doesn't seem like many new or updated plugins in the past few years, mainly scripts to run plugins. Perhaps vapoursynth will pique their interest.

Interesting, never heard of vapoursynth yet.

Originally Posted by Thunderbolt8

regarding the seeking bar, would it be possible to add additional time information when seeking, the time within a movie the mouse is moving the seeking bar? would be way easier to find specific scenes or spots.

guess you could do it either when the mouse is dragging the seeking bar or also when hovering over different places of the seeking with the mouse.

Sure it's possible, but time consuming. So no, for now.

Originally Posted by andyvt

Is it possible to configure madVR to use different algorithms for different resolutions?

Not at the moment. Planned for a future version.

Originally Posted by blackjack12

The original problem you were reporting, on which of those 4 systems did it occur? On all 4?
On all systems except system 2. System 2 actually worked correctly with all content for the first time after testing with 0.83.x builds and has ever since. So whatever deinterlacing logic you changed at that point “fixed” this legacy 4000 series Radeon system but has caused problems with much newer 6000 series systems

But when using the official v0.84.2 build, the problems with 6000 series are not specific to deinterlacing, correct? They also occur with progressive content, correct? Could you please double check, just to be safe? It's important to know.

Originally Posted by blackjack12

Did the original problem only occur with interlaced content, btw, or also with progressive content?
Originally, I saw it with any content, just jump around with any file that I tested and it would eventually freeze the que/s and start dropping frames.

Not sure if I understand this correctly. So basically deinterlacing doesn't work, but progressive content plays perfectly. Did I get that right? Not sure why deinterlacing doesn't work. The test build was a quick hack of moving some v0.82.5 code back into the v0.84.2 source code. It's *really* difficult because there was a very big change between v0.82.5 and v0.83.0 in the source code. The change itself shouldn't do much, but it makes it hard for me to create versions that sit between v0.82.5 and v0.83.0.
With interlaced content, the test build madVR actually crashes and generates the crash reports that I gave a link to. It crashes and you get a black screen, no video at all and only sound with the AMD 6570 systems. With the NVidia system just massive frame drops.

With all other progressive content that I tested I did not see any problems, except that on a “qualitative” basis things seemed to take a little longer to load up and start.

So the special test build I created for you makes everything progressive work just fine, and the only problems left are when using deinterlacing? Is that correct? How about the official v0.84.2 then? Could you please double check if maybe the official v0.84.2 also plays progressive content fine? I'm asking because the only difference between the official v0.84.2 and your special test build is deinterlacing. So for progressive content v0.84.2 and your test build should behave identical.

I'm sorry that fixing this problem takes so long. If only I could reproduce it on my PC !!!

Originally Posted by jaagil

Can someone explain me what is the difference in Chroma and Luma(Now "Image") (Up)scaling? (Or link to it, I have a feeling it's been asked more than twice already)

Digital video is normally stored as 4:2:0, which means that brightness information is stored in full resolution, and color information is stored with half width and half height. So madVR in the first step has to upscale color information to the same resolution as brightness information, before converting both into RGB. The color information upscaling is named "Chroma upscaling". Then scaling the final RGB frames to whatever target resolution you need is "image upscaling".

Originally Posted by jaagil

When SoftCubic is set to 100 and you activate anti-ringing it makes SoftCubic go to 50 automatically.

I can't seem to be able to reproduce this problem. Can you write an exact step-by-step description on how to reproduce this bug?

Originally Posted by sunnah

Chroma upscaling: Jinc 8 taps
Image upscaling: Jinc 8 taps
Image downscaling: Lanczos 8 taps

(I have the anti-ringing option enabled on everyone of them.

All work great on the NVIDIA GTX 570M without dropped/delayed frames.

Cool! That said, please double check whether image quality is really better than Jinc 3 or 4 taps. More taps isn't always better. Yes, it's ever so slightly sharper, but there may be more ringing artifacts left. Anyway, your choice, of course.

[madshi]

@Nicolas, thanks for your continued input, I appreciate it!

Originally Posted by NicolasRobidoux

3) It is on my to-do list to provide high accuracy low flop approximations of the key Jinc functions

I'm looking forward to that. However, I'm now using a very small Jinc LUT for my pixel shaders, using linear LUT interpolation, and it works surprisingly well. For your interest: I started with a LUT with 8 * 1024 values. Then I lowered the LUT size and compared images. I was surprised how small the LUT could be without getting any visible differences. I went down as far as 32 values only and still couldn't see any difference with bare eyes, although in a hex editor I could see some colors changed by a value of 1 (in 8bit). I'm now using a LUT size of 64 values. GPUs seem to handle that really well (due to texture caching), so it will be interesting to see whether your low flop math will be any faster.

Originally Posted by NicolasRobidoux

Mathias:
RE: what de-blur to use.
Although I have no mathematical basis for this recommendation, it appears to me that a value somewhere between .95 and .97 is probably the sweet spot, at least with EWA Lanczos 3. But I have not tried these values enough to be sure. And at this point, this would have to be based on the "eyeball metric".

Thanks. I'll play around with the blur values once more.

Originally Posted by NicolasRobidoux

Your overshoot suppression method appears to work impressively well.

Thanks, I'm glad you like it.

Originally Posted by NicolasRobidoux

You are aware that such limiters are probably not desirable, or not as desirable, when downsampling, yes?

Actually, no. From what I can see, my anti-ringing filter seems to work just as fine for downsampling as it does for upsampling. If you're interested to see how it looks, just send a link to an image you want to see downsampled and I can show you how it looks with my downsampling anti-ringing filter. I don't support Jinc downsampling yet, though, so I'd have to downsample with Lanczos.

Originally Posted by NicolasRobidoux

Given how well your "overshoot limiter" seems to work, I understand better your use of many lobes.

Yeah. I personally do not really recommend 8-taps, though. I usually recommend either 3 or 4 taps.

Originally Posted by NicolasRobidoux

Note: I have never liked Jinc 4 (EWA Lanczos 4-lobe in ImageMagick speak) for natural images. Even with the deblur optimized, it is a very unusual scheme, very different in character from Jinc 3.
I may have to triple check on this, but my opinion right now is that if you are going to go higher than Jinc 3 lobes, skip 4 and go up to 5.

That's interesting! FWIW, when comparing Jinc 3 vs 4 taps I can't see much of a difference when using my anti-ringing filter. 4 taps is ever so slightly sharper, that's all the difference I can see. I can't really see a different character. Not sure whether that's because of the anti-ringing filter? Anyway, here's a comparison between 3, 4 and 8 taps, all with anti-ringing filter:

parking - jinc 3 taps -|- parking - jinc 4 taps -|- parking - jinc 8 taps

There's not really a different look, is there? I only see small changes in sharpness and ringing.

Originally Posted by NicolasRobidoux

Also: The "best" deblurs for Jinc depend on the number of lobes.
I'll try to be more specific in a future post.

Interesting. I'm now using the same value for all Jinc taps. I guess for more taps, a lower deblur value can be used (resulting in even sharper images)?

Originally Posted by NicolasRobidoux

IMHO, instead of adding more lobes to Jinc (3 is enough), I'd add quadratic B-spline-windowed Jinc 3-lobe with no deblur ("blur=1") or with the same deblur you use with Jinc if it's easier.

But why? It seems the only advantage of the quadratic B-spline window is less haloing, and that is of no use to me because my anti-ringing filter takes care of the halos, anyway. Or does quadratic B-spline windowing have any other advantages that I'm not aware of right now?

[sunnah]

Originally Posted by madshi

Cool! That said, please double check whether image quality is really better than Jinc 3 or 4 taps. More taps isn't always better. Yes, it's ever so slightly sharper, but there may be more ringing artifacts left. Anyway, your choice, of course.

Thanks I'll try what you said.

[sunnah]

Originally Posted by sunnah

Thanks I'll try what you said.

Madshi, what are your Chroma upscaling, image upscaling and image downscaling preferred settings, i'm just curious.

I tried the the change from linc 8 taps to 3, I saw the positive difference between the ringing so thanks for that tip.

[toniash]

Originally Posted by madshi

Aren't you guys interested in getting things like custom shader support, 3D support etc?

Of course we are VERY interested!

[madshi]

Originally Posted by sunnah

Madshi, what are your Chroma upscaling, image upscaling and image downscaling preferred settings, i'm just curious.

I guess I'll end up using Jinc 3 or 4 (not sure yet) for Luma and Chroma upsampling and Lanczos 4 for Luma downscaling. All with anti-ringing enabled, of course. But it's a matter of taste.

[madshi]

@NicolasRobidoux,

I've tried your suggestions:

(1) Ginseng looks exactly the same as standard Lanczos to me, at least when upscaling that parking lot image 400%. At first I thought I made a mistake because I saw no difference, but I double and triple checked. I can't really see any difference between standard Lanczos and Ginseng!

(2) I could see using a blur factor a bit lower than I'm using right now, but I'm not sure which exact factor I should be using. The difference is subtle, anyway. As you say, something around 0.96 might be a good compromise. Is there any theoretical disadvantage to using a "simple" number like "0.96000000"? I've also checked with 4 taps and 8 taps and from what I can see, similar blurring factors make sense there, too. I didn't feel the need to use a different blurring factor for 8 taps compared to 3 taps.

(3) I've retried your invert + sRGB -> RGB conversion trick, and I guess I made a mistake when originally testing this because the results I get now are better than when I originally tested this. Here's how it looks now with the parking lot image:

jinc 3-tap normal -|- jinc 3-tap "hacked"

Does that look as expected to you? Any comments anyone on which image you prefer? I guess the "hacked" image does look a bit better? At least it looks different.

@Nicolas, is the full Sigmoidal stuff better compared to the simple invert + sRGB -> RGB hack? If so, is the Sigmoidal math explained anywhere? Maybe a web article? Or a science paper or something?

[ryrynz]

Originally Posted by madshi

I guess the "hacked" image does look a bit better? At least it looks different.

I'm preferring the hacked image also.

[aufkrawall]

Sorry if this has already been discussed, madshi.
Are you aware of the problem that when using Win XP qdvd.dll for DVDs on Windows 7, the whole window of MPC HC gets unresponsive after seeking (nothing can't be clicked anymore)?
It doesn't happen with EVR CP, seeking multiple times seems to work just fine with it.
So, it might be a madVR issue?
Would be great if you would fix this since it seems to be the only reliable method to get DVDs working with madVR on Windows 7.

[namaiki]

Originally Posted by aufkrawall

Sorry if this has already been discussed, madshi.
Are you aware of the problem that when using Win XP qdvd.dll for DVDs on Windows 7, the whole window of MPC HC gets unresponsive after seeking (nothing can't be clicked anymore)?
It doesn't happen with EVR CP, seeking multiple times seems to work just fine with it.
So, it might be a madVR issue?
Would be great if you would fix this since it seems to be the only reliable method to get DVDs working with madVR on Windows 7.

Not sure about this, but I think it was possible to play DVDs without hacks if you didn't use ffdshow. If you aren't using ffdshow at the moment, then I guess not.

[patul]

Originally Posted by madshi

@NicolasRobidoux,
Any comments anyone on which image you prefer? I guess the "hacked" image does look a bit better? At least it looks different.

"hacked" image does look better to my untrained eyes. The perception of being 'clearer' is given by that image, specifically if I look to that "No parking at" and the green logo as well as the "Camden" areas.

[AndreaMG]

Originally Posted by madshi

Aren't you guys interested in getting things like custom shader support, 3D support etc?

Me VERY VERY interested!

[AndreaMG]

Originally Posted by edragon

I use mpc+madvr+ffdshow video audio+haali +SVP+reclock

but i do not use LAV
video use soft decoding

maybe gtx570 is much greater than gtx550ti.....

Try without SVP, which eats a lot of CPU, but also GPU if enabled to do so. I have a 460GTXM overclocked and with both chroma and luma upscale Jinc 3 taps and SVP I have drop frames...

[AndreaMG]

Originally Posted by aufkrawall

Would be great if you would fix this since it seems to be the only reliable method to get DVDs working with madVR on Windows 7.

I play dvds under MadVR without the "qdvd.dll" trick simply by adding in MPCHC external filters Cyberlink video decoder and Microsoft dvd navigator.

[Budtz]

Originally Posted by madshi

Well, I would much rather implement a *real* sharpening algorithm, to be honest. That's why I'm also reluctant offering so many more tweaks: It costs many hours of my time which I could instead spend on doing the "real thing". Personally, I don't like Darbee pop at all. I much prefer something like Didee's FineSharp. So if you ask me to add this and that, and a couple of other tweaks in between, basically you're keeping me busy with so-so stuff, instead of allowing me to move on to bigger and greater things. I've said it so many times before: Let me first add all the missing features, before spending my time by twiddling with 1% improvements. I'm feeling held back at the moment, by all the constant requests for small tweaks and changes everywhere. Aren't you guys interested in getting things like custom shader support, 3D support etc?

Yes i'd very much like a proper sharpener. The avysynth-ones are not very userfriendly plus it would be a better place in the chain to have it in madvr. I could also get rid of ffdshow and only use madvr and lav filters.

[AndreaMG]

Originally Posted by Budtz

Yes i'd very much like a proper sharpener. The avysynth-ones are not very userfriendly plus it would be a better place in the chain to have it in madvr. I could also get rid of ffdshow and only use madvr and lav filters.

And most of all it would be awesome to able to sharpen AFTER resizing, which is impossible via avisynth in conjunction with MadVR. In my opinion the integration (with pixel shaders?) of a sharpener in MadVR is priority N. 1

[NicolasRobidoux]

Mathias:
I'll try to address your questions without adding more noise and pointless things to program.
I see that you almost always try "the right things" and ask the right questions, so I can "chill" a little.

[NicolasRobidoux]

General warning:
Don't assume that increasing lobes and the like has quite the same effect when using Jinc ("EWA Lanczos") as it does when using Sinc ("tensor a.k.a. orthogonal a.k.a. 2-pass Lanczos").
EWA Jinc and tensor Sinc filtering are very different beasts. Some of the intuition you've built with Sinc carries over, but some does not. Actually, it mostly has to do with the difference between EWA and tensor methods.
Some tweaks that make EWA windowed-Jincs better make tensor windowed Sincs worse, and vice versa.
For example, in my book, there is generally little point going above 3 lobes with EWA. Less of a point than with tensor Lanczos. I'd actually say no point whatsoever when this is to be a default, unless possibly you want to reproduce the perceptual sharpness of tensor Lanczos and its relatives, which is most likely misguided UNLESS YOU ARE DOWNSAMPLING (because EWA is much better at moire reduction than tensor methods at roughly equivalent sharpness).
If you allow me to venture why, I'd say that it's because additional Sinc lobes compensate for the fact that you are using a tensor method, which does not dampen the checkerboard mode because it filters both directions separately. As as been noticed by some of the posters, EWA Jinc dampens the checkerboard mode more than a bit. It's built into the Jinc function, and the 2D frequency response plots make it obvious.
I realize that video upsampling (or downsampling) is a different context than cheap camera or scanned photographs or DSLR or line art resizing, but I'd be really surprised if what I've learned w.r.t. the latter does not carry over to the former. This being said, my back of the envelope hunches are often wrong, so don't take what I say too seriously.

[TheLion]

Originally Posted by ryrynz

I'm preferring the hacked image also.

I also prefer the "hacked image" by an ever so small margin.