madVR - high quality video renderer (GPU assisted)

[DarkSpace]

Originally Posted by ryrynz

I can honestly say I'll be moving flash3kyuu out of the Avisynth chain.
I like that a lot because now I can deband 10bit content without dropping down to 8bit.

Uhm, just for your information, dropping down to 8 bit is not necessary, there's Dither Tools for high-bitdepth AviSynth output...

Also, the debanding works well here, but I think I'm getting some kind of spike in rendering times (default: ~14ms, spike ~154ms) every time it is activated from its disabled state or increased from low to high... I suppose that is expected?
Just to be clear, I get maybe 1 or two dropped frames because of this, if at all, and the rendering times do go down again relatively fast, I just want to make sure it's not a bug.

[madshi]

Originally Posted by ryrynz

do you happen to have any of the test images that included this extra check vs without?

Yes, see the f3kdb() thread.

Originally Posted by ryrynz

BTW your low setting isn't that far off the detail retention of my flash3kyuu settings. It's a bit softer but it does a better job overall..

Is the whole image softer? Or just certain areas? In the first case it's probably not the debanding itself, but f3kdb() by default adds random grain/noise to the image. For no benefit other than to make the image noisier. I've removed that part from madVR because madVR adds noise for the last dithering step, anyway. If you like the added noise, you could simply switch your display to 7bit instead of 8bit in the madVR device settings. That will increase the amount of noise madVR adds.

Originally Posted by GCRaistlin

As I wrote above, sometimes madVR incorrectly changes or, on the contrary, doesn't change monitor refresh rate.

I've already replied to your "above" post.

Originally Posted by DarkSpace

Also, the debanding works well here, but I think I'm getting some kind of spike in rendering times (default: ~14ms, spike ~154ms) every time it is activated from its disabled state or increased from low to high... I suppose that is expected?
Just to be clear, I get maybe 1 or two dropped frames because of this, if at all, and the rendering times do go down again relatively fast, I just want to make sure it's not a bug.

When switching any settings, madVR resets the whole rendering setup which can take a tiny bit of time. Rendering times may spike. But changing debanding settings shouldn't take more time than e.g. changing scaling algorithms.

[SHaKOL]

Originally Posted by madshi

Avi is the container not the codec. Judging from your screenshot the codec is CRAM. Try simply blocking "AVI Decompressor".

hmmm i blocked "AVI Decompressor" and then i played the video it says "cannot render the file" shows this:

[madshi]

Both LAV Video Decoder and ffdshow can handle CRAM files on my PC. In LAV Video Decoder the format is called "msvideo1".

[SHaKOL]

thanks madshi it worked

[DarkSpace]

Originally Posted by madshi

When switching any settings, madVR resets the whole rendering setup which can take a tiny bit of time. Rendering times may spike. But changing debanding settings shouldn't take more time than e.g. changing scaling algorithms.

Thank you for the confirmation. I guess I simply didn't notice so far because I don't usually switch scaling algorithms...

[6233638]

Originally Posted by madshi

Not sure: Is that irony, or did you really expect better?

I was being sarcastic; it's very impressive!



I will say that after having done quite a bit of testing last night, I'm not sure that it's something I would leave enabled by default, but for specific sources it can work very well.

It works surprisingly well for macroblocking in addition to banding, but I suppose that's really just another type of banding.

I was somewhat disappointed to see that it did not take care of the banding at the beginning of The Fountain Blu-ray, but when I actually brightened that up to look at it, it's clear why - it's a terrible encode; an old MPEG-2 disc.




When you look at what the debanding option actually does for the image, it's still impressive:



That said, especially on high, it does seem to act like "noise reduction" some of the time, obscuring fine details. If you look at the images above, you will see that the fingernail disappears.
With some content it may eliminate a lot of the banding/macroblocking, but actually look worse, because what's left now stands out against an otherwise clean image, and is a distraction.

And there are some cases where I thought it would work well, but it hardly does anything:




But overall, very impressive and a good addition to madVR.

[madshi]

Originally Posted by 6233638

I was being sarcastic; it's very impressive!

Thought you meant that, but wasn't sure.

Originally Posted by 6233638

I will say that after having done quite a bit of testing last night, I'm not sure that it's something I would leave enabled by default, but for specific sources it can work very well.

I definitely wouldn't leave "high" on by default, except maybe for Anime content. But did you find "low" to eat away details, too? I would like to have a setting which is low enough to never harm, but to sometimes help. Is the current "low" setting still too agressive for that? I guess I could rename the current "low" setting to "medium" and add a "low" setting which is even more careful. Such a "low" setting probably wouldn't really remove ugly banding artifacts, but it could at least smooth the rough edges away from clean non-dithered 8bit encodes.

Originally Posted by 6233638

That said, especially on high, it does seem to act like "noise reduction" some of the time, obscuring fine details. If you look at the images above, you will see that the fingernail disappears.
With some content it may eliminate a lot of the banding/macroblocking, but actually look worse, because what's left now stands out against an otherwise clean image, and is a distraction.

Yeah. We humans have such a big advantage because we know what a fingernail is supposed to look like. So we know which part of the image is real detail and which is an artifact. A simple debanding algorithm has no way of knowing that. So at least in "high" mode it's always a balance act between debanding and detail removal. I do think in "low" mode usually details are left well enough alive.

Originally Posted by 6233638

And there are some cases where I thought it would work well, but it hardly does anything

Hmmmm... Yes, that one is a bit surprising. I'll have a look at that later when I find some time.

[Thunderbolt8]

Originally Posted by Asmodian

CUVID doesn't use the GPU to decode video. It uses the VPU which is a different chip on the card and another sensor in GPU-Z or Nvidia Inspector (I believe it defaults to not displayed in Nvidia Inspector). CUVID will also use memory bandwidth on the video card.

I still dont understand why the load on the nvidia is less when using CUVID and not at least as high as when not using it. the workload of the GPU needed for madvr, this shouldnt change when using CUVID, should it? so in that case the load should be at least be the same as when not using CUVID? or does CUVID indeed influence madvr performance?

aside from that, there are two things Id like to achieve: have my system be as silent as possible when watching movies, but also trying to maximize the length of life of my GPU (because that one of my former laptop died after ~3 years of itensive usage).

so Id say if my CPU and GPU load is lower when using CUVID, then this should mean less heat and less fan noise.

but what about endurance? I guess its a bit of speculation, but would the constant use of CUVID rather lead to an increase or decrease of my nvidia card?

[6233638]

Originally Posted by madshi

I definitely wouldn't leave "high" on by default, except maybe for Anime content. But did you find "low" to eat away details, too? I would like to have a setting which is low enough to never harm, but to sometimes help. Is the current "low" setting still too agressive for that? I guess I could rename the current "low" setting to "medium" and add a "low" setting which is even more careful. Such a "low" setting probably wouldn't really remove ugly banding artifacts, but it could at least smooth the rough edges away from clean non-dithered 8bit encodes.

I would have to do more testing with good sources before I made a decision on that. On principle alone, I would be inclined to leave it disabled with a good source, but maybe Low would not have any negative effects.

Low seemed to help with banding, but not so much with macroblocking. I was mostly just going through all my bad sources where I remembered banding/macroblocking being a problem than testing with higher quality sources.

[madshi]

Well, the debanding algorithm was not meant for macroblocking, although at really high levels it fixes some of them, too.

One thing with current Blu-Ray sources is that as clean as they might be, they are still 8bit encodes. That means on a really big screen, there should be some banding in some scenes. Of course the studio can dither the source down before encoding it, but usually the encoder swallows some of that dithering, or even all of it (depending on the bitrate etc). So a very mild debanding might even help with rather clean Blu-Ray sources. This might change when we get to 4K Blu-Ray which will hopefully introduce 10bit or even 12bit encoding. So one thing worth investigating is to find a clean Blu-Ray which shows very mild banding which is caused by nothing else but the limitation of 8bit encoding. Then when we have such samples to test with, we could look for debanding parameters which are low enough to fix just that kind of banding, without changing anything else. I'm pretty sure that at such levels the debanding should almost never harm and could stay active all the time.

[Boltron]

madshi, you are awesome. That is all.

[dansrfe]

Originally Posted by madshi

Well, the debanding algorithm was not meant for macroblocking, although at really high levels it fixes some of them, too.

One thing with current Blu-Ray sources is that as clean as they might be, they are still 8bit encodes. That means on a really big screen, there should be some banding in some scenes. Of course the studio can dither the source down before encoding it, but usually the encoder swallows some of that dithering, or even all of it (depending on the bitrate etc). So a very mild debanding might even help with rather clean Blu-Ray sources. This might change when we get to 4K Blu-Ray which will hopefully introduce 10bit or even 12bit encoding. So one thing worth investigating is to find a clean Blu-Ray which shows very mild banding which is caused by nothing else but the limitation of 8bit encoding. Then when we have such samples to test with, we could look for debanding parameters which are low enough to fix just that kind of banding, without changing anything else. I'm pretty sure that at such levels the debanding should almost never harm and could stay active all the time.

This sounds awesome.

What should we look for in providing samples of banding due to 8bit encoding?

[huhn]

Originally Posted by madshi

Well, the debanding algorithm was not meant for macroblocking, although at really high levels it fixes some of them, too.

One thing with current Blu-Ray sources is that as clean as they might be, they are still 8bit encodes. That means on a really big screen, there should be some banding in some scenes. Of course the studio can dither the source down before encoding it, but usually the encoder swallows some of that dithering, or even all of it (depending on the bitrate etc). So a very mild debanding might even help with rather clean Blu-Ray sources. This might change when we get to 4K Blu-Ray which will hopefully introduce 10bit or even 12bit encoding. So one thing worth investigating is to find a clean Blu-Ray which shows very mild banding which is caused by nothing else but the limitation of 8bit encoding. Then when we have such samples to test with, we could look for debanding parameters which are low enough to fix just that kind of banding, without changing anything else. I'm pretty sure that at such levels the debanding should almost never harm and could stay active all the time.

the eva 3 bd has 40 mbit vbr and a sceen like this

http://picload.org/image/olpdcil/00002.m2ts_snaps.png

on my very cheap iiyama (~150€) i can see some branding. on an good ips there should be a lot. on my asus vg 248there is no branding to see but tons of dithering noise. so don't judge this with an normal tn panel. on my tv is was huge but no time for this now.

[DeadlyEmbrace]

Madshi, you're the man!
Did some rapid testing with the deband test version and the result is amazing! Really looking forward to the next release

[clsid]

madshi, have you considered running post-processing algorithms such as Deband in software using the CPU before copying the data to the GPU?

GPU resources are very scarce, while most here will have plenty of CPU resources to spare. Playing a 1080p video uses less than 10% on a decent CPU.
I know it wouldn't work with DXVA native, but that is hardly a necessity on modern systems. Plus you could offer a Shader implementation as well.

[Werewolfy]

Hi, this is my first post here. I've tested the new deband function and I think that even at its low setting, it blows away too many details in dark areas.

Here some examples :

deband off http://img12.imageshack.us/img12/5824/jyf5.png

deband low http://img707.imageshack.us/img707/1378/kgsi.png

deband high http://img28.imageshack.us/img28/7330/qf2q.png

Look at the jackets and on the sleeves of the characters, it smooths a little too much details so I would like a very low setting that doesn't blow away any (or almost any) details even if the debanding is a little less effective. I'm using the deband on Ffdshow for many years and I think this function needs many levels of tweaking because it depends a lot of the quality of the video. 4 or 5 levels would be a good choice .

Sorry if I make some mistakes, I'm not used to write in English.

[turbojet]

madshi: f3kdb(31,dynamic_grain=true,random_algo_ref=2,random_algo_grain=2)
vs. low: f3kdb has more effective debanding but reduced details and more noise, preference depends on the situation
vs. high: f3kdb isn't as effective at debanding, about the same detail, more noise, prefer high over f3kdb
I'm only using f3kdb now for convenience, switching debanding to high every time a new player is opened is annoying when that's no longer an issue high will be default here. Also F2 and Ctrl+J conflict with potplayer without key remapping in madvr or potplayer.

clsid: madshi's reasoning is explained here but I also hope at some point there's an option or auto shift to offload some things to the cpu. Are writing shaders much different then cpu code? JanWillem and madshi seem to be the only two doing the former on this board, the latter has many. Luckily debanding isn't a heavy load compared to anti-ringing and smooth motion.

[6233638]

Originally Posted by Werewolfy

Hi, this is my first post here. I've tested the new deband function and I think that even at its low setting, it blows away too many details in dark areas.

You're right. I did some more testing tonight with Blu-rays rather than poor quality content, and it's definitely blurring things too much in dark areas. I need to start collecting some good examples.

On the other end of the scale, I'm also finding things where I expected the debanding to work well, but it had minimal effect.



And it seems that quite a few films must be using the same tools to add an artificial vignette effect at the start of them, because I found another disc which looks like The Fountain example I posted before:



It would be nice to have a test build where the variables could be adjusted to have a play around and see what works well for different content.

[Coldblackice]

In MPC, what variables and measures within madVR's information printout should we watch to determine what might be causing "laggy" playback? For example, I gather that "dropped" (28) and "delayed" (20) frame readouts are important. However, those two counts seem to be staying fairly static.

What else should I look to, to determine what might be the culprit?