madVR - high quality video renderer (GPU assisted)

[6233638]

Originally Posted by madshi

Ouch. I suppose Jinc3AR doesn't work for image upscaling? (Something cheap for chroma.)

I was actually just doing some similar testing last night; not specifically about GPU load, but power consumption (which is related to GPU load) when I noticed that it seemed excessively high with 720p60 playback.

Luma		Chroma			Power
Jinc 3 AR	Jinc 3 AR		270W
Jinc 3 AR	Bicubic 75 AR		256W
Jinc 3		Bicubic 75 AR		222W
Jinc 3		Bicubic 75		221W
Lanczos 3 AR	Bicubic 75 AR		150W

Idle					125W

I've said in the past that there's very little benefit to using Jinc 3 AR for chroma, and if your display processes in less than 4:4:4 it's absolutely pointless, but considering it's eating ~15W for little-to-no practical benefit, I would now recommend everyone use Bicubic 75 AR, unless anyone can produce samples where Jinc 3 AR chroma is better.

And while there are certainly examples where Jinc 3 AR is better than Lanczos 3 AR for luma scaling, it's less apparent when starting with an HD source, and I wonder if it's worth the additional 70-120W power consumption.

When scaling DVDs, the results are quite different. There's only 10W between Jinc 3 AR luma, and anything else.
I have suggested it before, but I really think we could do with resolution specific scaling options, though I know that would require a lot of UI changes.

I also found that hardware accelerated decoding (DXVA2 copy-back) was a bit hit-and-miss. When the GPU was being taxed and in a high power state, it saved me 10W, so the top number dropped to 260W. But when playing back DVDs, power consumption varied a lot, fluctuating between 145-170W. With CPU decoding, it was fixed around 150-155W. I should probably have checked DXVA2 Native, which I'm sure would have produced lower numbers, but I would never use that for quality reasons.
And the "trade quality for performance" options may help for low power GPUs, but barely made a dent in power consumption.

I must say though, if Intel brings the power consumption improvements they made with the mobile Haswell chips over to the desktop next year, that alone is probably going to be enough for me to upgrade. 125W at idle is rather high these days.

Originally Posted by THX-UltraII

I m thinking about getting the AMD 7950. Will this card give me perfect playback with madVR?

Aren't you better off with one of the new GPUs? I know they're mostly "rebranded" but there are often smaller changes that people overlook. (possibly upgraded hardware decoders, for example)

Originally Posted by THX-UltraII

What is THE best PQ algorithm to use for 1080p when sending out 1080p to my projector? (I ll stay with 1080p outputting for now and let my vw1000 do the 4k upscaling)

The reviewer David Mackenzie posted here a while back that Jinc 3 AR looked a lot better than Sony's "digital reality creation" scaling which incorporates image sharpening in its upscaling algorithms. You might be better outputting 4K and scaling in madVR.

[Asmodian]

Originally Posted by madshi

Ouch. I suppose Jinc3AR doesn't work for image upscaling? (Something cheap for chroma.)

Well Jin3AR might work for upscaling but I am actually downscaling the image (2160p->1440p), hence my confusion.

[Zachs]

Originally Posted by madshi

Works fine here with both LAV Video Decoder and the internal madVR video decoder. Which decoder are you testing with? Probably a bug with that decoder.

I'm running MPC-HC x86 v1.7.0 from mpc-hc.org.
It has LAV Video Decoder / Audio and Splitter built-in, *not* using any external filters.
Only setting I changed was to make it use MadVR as renderer. MadVR settings untouched. This is on a newly installed Win7 x64.

Switching between the different renderers, only MadVR exhibits this odd behaviour -- the whole green colour plane was shifted down vertically by some pixels. Doesn't happen with all sources, just some.

EDIT: The plane shift results in thick green line appearing at the top of the video.
I tested the same config on a different computer (different hardware but still NVidia GPU) but I can't replicate the problem.

[mzso]

I get a crash with potplayer when I try to make a bookmark, if the video is zoomed enough so that the height is at least as tall as the screen. If I change to EVR there's no crash. Can madVR be somehow responsible for the crash?
(Contacting the potplayer dev didn't lead to anything useful...)

[StephaneM]

Originally Posted by madshi

I'm not sure why you would have problems with bilinear but not with SoftCubic. Usually it's the other way round. Bilinear is ultra-cheap, SoftCubic consumes quite a bit more resources. So something is weird here.

Yep indeed, after further testing it does this only on a specific content (here is a sample of this content), and the more I see it the more I think it's a bug related to this particular content regarding deinterlacing (It looks a lot like when you have a bad packet on the DVB stream and the decoder is really confused and doesn't recover)

Could it be possible that you changed the scaling settings to bilinear in the wrong section? E.g. you changed it for upscaling instead of downscaling or something like that? A stupid question

I triple checked and it's when I change the downscaling to bilinear or nearest neighbor.

But it isn't a big deal really.

[Soukyuu]

Originally Posted by Asmodian

Well Jin3AR might work for upscaling but I am actually downscaling the image (2160p->1440p), hence my confusion.

For some reason, downscaling eats a lot more resources than upscaling. I remember not having any problems upscaling DVD to 1080p but downscaling 1080p to DVD size totally killed my 8600m GT back then (EVR renderer). Maybe it's the same thing here.

[6233638]

Originally Posted by Soukyuu

For some reason, downscaling eats a lot more resources than upscaling. I remember not having any problems upscaling DVD to 1080p but downscaling 1080p to DVD size totally killed my 8600m GT back then (EVR renderer). Maybe it's the same thing here.

Linear light downscaling is very demanding, and it only looks good when you are using the anti-ringing filter as well.

Try downscaling using catmull-rom without those options, and it should drastically reduce the GPU load.

[James Freeman]

I have been trying for weeks now to makes MadVR & 3DLUT to look anything simmilar to MPC-HC native Color Management.

I have registered to AVSForum to participate in the "MadVR - ArgyllCMS" thread and tried EVERYTHING (believe me).

Still... no matter what settings or teaks I use, nothing looks or behaves like MPC-HC native Color Management (It loads itself from Windows Profile ICM).

I have given-up on 3dlut with ArgyllCMS (collink), because no matter what setting I try, I can't use my calibrated gamma from my .ICM profile.
I am forced to use BT.1886 setting (which I don't like), otherwise the gamma curve is off.

I found a simple solution for my Wide Gammut monitor:
Read the Primaries with HCFR and put them into the yCMS tab in MadVR.
This did the trick perfectly (correcting the Colors & letting windows handle the Gamma).
One step closer to what MPC-HC does natively.

But, I have encountered a problem.

Loading a 3DLUT into Madvr (yCMS) fixes the colors, but something goes wrong with the contrast.

Moreover, playing with the Contrast slider in Madvr disables the 3DLUT altogether.


@Madshi
I have asked for it already in the past,
Is there any way to implement a simple (automatic) Color Management code like in MPC?

I really wish it would be easy and accurate as just "turning a button on" like in MPC.
Without the need for Conversions, Compilations, Command prompts, Multiple Software (not to mention weeks of tweaking).
Simple does it.
Something like "Use OS Profile" in the Calibration tab will be nice.

[ryrynz]

Originally Posted by drmpeg

The blocks or Miley?

It's almost a tie. Almost.

[turbojet]

I'm surprised palladia looks that bad, usually one of the better looking channels here. Is that during a very complex scene or is the significant amount of red causing a blocky frame? NBC is notorious for the latter and AMC used to be.

If pics of the red block issue would help madshi I could keep a look out for it.

[THX-UltraII]

Originally Posted by 6233638

The reviewer David Mackenzie posted here a while back that Jinc 3 AR looked a lot better than Sony's "digital reality creation" scaling which incorporates image sharpening in its upscaling algorithms. You might be better outputting 4K and scaling in madVR.

This may sound interesting to do some testing with for me. But first I would like to know something else. Let s say I m just going to put out 1080p from my HTPC with madVR. If I let ANY algorithm do it s work in madVR won t this cause any serious artifact? I mean, first madVR will do something with the picture because of it s algorithm and after this my Sony VW1000 projector does the 2K=>4K upscaling with Reality Creation. This sounds bad to me but maybe it s just me

IF i m right. Is it also possible that madVR does not do ANY algorithm adaption to the picture? If so, how? I just looked in the madVR settings and I have to choose SOMETHING for Chroma and Luma upscaling? (what is the difference anyway between Chroma and Luma upscaling?)

[THX-UltraII]

madvr outputs rgb and your intel card transforms this to ycbcr with is bad...

huhn, you have any idea how to check if this is true? Not that I don t believe you but I have reasons to think that my Sony VPL-VW1000ES projector DOES get feed with rgb from my HTPC.

if i remenber correct there was a way to output ycbcr with madvr but don't ask me how.

IF my intel card outputs ycbcr to my projector, it might be interesting to know how to-do this exactly.

I ask this because I m still in doubt whether I m going to use the 7950 I just bought.

[madshi]

Originally Posted by Zachs

I'm running MPC-HC x86 v1.7.0 from mpc-hc.org.
It has LAV Video Decoder / Audio and Splitter built-in, *not* using any external filters.
Only setting I changed was to make it use MadVR as renderer. MadVR settings untouched. This is on a newly installed Win7 x64.

Switching between the different renderers, only MadVR exhibits this odd behaviour -- the whole green colour plane was shifted down vertically by some pixels. Doesn't happen with all sources, just some.

EDIT: The plane shift results in thick green line appearing at the top of the video.
I tested the same config on a different computer (different hardware but still NVidia GPU) but I can't replicate the problem.

Are you using DXVA decoding? Or CUDA decoding? I can only guess that this is related to hardware decoding somehow.

Originally Posted by mzso

I get a crash with potplayer when I try to make a bookmark, if the video is zoomed enough so that the height is at least as tall as the screen. If I change to EVR there's no crash. Can madVR be somehow responsible for the crash?
(Contacting the potplayer dev didn't lead to anything useful...)

Is the crash inside of PotPlayer.exe or inside of madVR? Usually if it's inside of madVR you should get a madVR crash report box and should have the option to send a bug report to me. If the crash is in PotPlayer then chances are it's their problem to fix and not mine. It could still be my fault, but I can't do much without a proper crash report.

Originally Posted by James Freeman

I have given-up on 3dlut with ArgyllCMS (collink), because no matter what setting I try, I can't use my calibrated gamma from my .ICM profile.
I am forced to use BT.1886 setting (which I don't like), otherwise the gamma curve is off.

You could try using LightSpace or Calman to create an eeColor 3dlut and then import that in madVR. Those two tools are not free, though.

Originally Posted by James Freeman

Loading a 3DLUT into Madvr (yCMS) fixes the colors, but something goes wrong with the contrast.

Moreover, playing with the Contrast slider in Madvr disables the 3DLUT altogether.

Can you define "something goes wrong" a bit better?

Playing with the contrast slider should *not* disable the 3dlut. Are you totally sure on that? What about the other sliders, like brightness, saturation and hue? Do they also disable the 3dlut for you?

Originally Posted by James Freeman

I have asked for it already in the past,
Is there any way to implement a simple (automatic) Color Management code like in MPC?

I really wish it would be easy and accurate as just "turning a button on" like in MPC.
Without the need for Conversions, Compilations, Command prompts, Multiple Software (not to mention weeks of tweaking).
Simple does it.
Something like "Use OS Profile" in the Calibration tab will be nice.

I'm not an expert in calibration or profiles. If you have installed an OS Profile, shouldn't it automatically be applied to everything, including video rendering? Why would madVR have to do some extra processing? Isn't it the OS' job to apply the Profile that is installed in the OS?

What kind of profile is that, anyway? A simple matrix profile? Or is some sort of 3dlut contained? Or 3 separate 1dluts for the GPU VideoLUTs?

Originally Posted by StephaneM

Yep indeed, after further testing it does this only on a specific content (here is a sample of this content), and the more I see it the more I think it's a bug related to this particular content regarding deinterlacing (It looks a lot like when you have a bad packet on the DVB stream and the decoder is really confused and doesn't recover)

This is a simple telecined movie broadcast. You can force madVR into film mode to get perfect progressive playback. Playback also works perfectly fine with DXVA deinterlacing and bilinear scaling here on my Intel HD4000, though. However, when using DXVA deinterlacing, if you step through the frames, you'll notice that every frame is shown exactly twice. With madVR's film mode, every frame is only shown once (decimation).

[e-t172]

Originally Posted by madshi

I'm not an expert in calibration or profiles. If you have installed an OS Profile, shouldn't it automatically be applied to everything, including video rendering? Why would madVR have to do some extra processing? Isn't it the OS' job to apply the Profile that is installed in the OS?

When using a system-wide ICC profile (and assuming it is loaded correctly), the only thing that's being changed system-wide are the GPU gamma ramps, which are RGB 1D-LUTs. Besides, this method of calibration cannot really do much because it is not aware of the source colorspace.

To achieve full (i.e. 3DLUT) calibration, it's not enough to have the ICC profile configured in the Windows color options, the software needs to be ICC-aware as well (e.g. Gimp, Photoshop, Chrome, etc.). madVR isn't, but the (madVR + Argyll + 3DLUT) combination is.

Ideally, the way it's supposed to work is that madVR is supposed to automatically pick up the ICC profile configured in the Windows color options (using the Windows color API) and use a CMS (e.g. LittleCMS, Argyll) to generate a device link transform (i.e. a 3DLUT) between the source colorspace (e.g. BT.709) and the destination colorspace (the monitor's configured ICC profile). That's how most ICC-aware applications (Photoshop, etc.) work. Unfortunately, madVR doesn't have this feature yet - for now you have to generate the 3DLUT by hand.

Originally Posted by madshi

What kind of profile is that, anyway? A simple matrix profile? Or is some sort of 3dlut contained? Or 3 separate 1dluts for the GPU VideoLUTs?

Profiles contain either a matrix or a 3DLUT. They can additionally contain calibration 3x1DLUTs (vcgt tag, "Video Card Gamma Tables") - most monitor profiles do. The matrix/3DLUT part of the profile is only valid if the vcgt tag is applied beforehand (usually system-wide as I descrived above). It doesn't really matter if the profile contains a matrix or a 3DLUT: ICC-aware software should be able to correctly handle both. It does make a difference in terms of quality, though.

I can't really comment on the MPC-HC color management feature since I have no idea how it works internally.

[madshi]

That's all much too complicated for my taste, to be honest. I prefer leaving all the calibration work to external tools and just apply the 3dlut in madVR.

[e-t172]

Actually, from a developer point of view, as long as you're using a CMS library, it's not complicated at all.

For example with LittleCMS automatically generating a 3DLUT can be done in just a few lines: you just give it the source colorspace (BT.709, etc.), the monitor's ICC profile, and it will happily give you a ready-to-use 3DLUT. That's basically equivalent to Argyll's "collink" command. This basic solution can then be improved by having some UI for customizing the result, such as custom BT.1886 gamma, rendering intent, etc. - these are just parameters for the CMS library.

Here's some code from the mplayer2 project that does exactly that. It creates a BT.709 profile from the primaries, uses LittleCMS to convert from BT.709 to a user-provided profile and generates a 3DLUT. The code that does all that is less than 100 lines long. In a separate function the resulting 3DLUT is loaded into GPU memory and applied on real-time video using shaders, just like madVR.

Ideally, madVR could have such a feature alongside the manual 3DLUT calibration (for people who want to use another CMS or precisely fine-tune the results).

[StephaneM]

Originally Posted by madshi

This is a simple telecined movie broadcast .../... Playback also works perfectly fine with DXVA deinterlacing and bilinear scaling here on my Intel HD4000 .../... when using DXVA deinterlacing, if you step through the frames, you'll notice that every frame is shown exactly twice.

If it works fine on the Intel GPU then it's a bug within the AMD HD 4600 GPU (they are used to have bugs in their deinterlacing process for PAL content : I remember the infamous temporal denoise issue on 1800 XT, or the half picture issue : only the top part was deinterlaced, this was fun )

Anyway everything is crystal clear now : madVR does allow hardware deinterlacing to work fine with AMD GPU (despite LAV Filters making you think it's not possible)

[Zachs]

Originally Posted by madshi

Are you using DXVA decoding? Or CUDA decoding? I can only guess that this is related to hardware decoding somehow.

I managed to root cause the problem. It was due to an old NVidia GeForce driver that I've been using for my HTPC -- v258.96. This was the version recommended for HTPC as it doesn't stutter with EVR+DXVA (my TV tuner app uses this). Apparently all problems have been fixed with the latest driver, so all is good!

[James Freeman]

@Madshi

MPC-HC uses "Little CMS" which is an opensource color management code to implement in other Software like MadVR.

http://www.littlecms.com/
There is even a well written Tutorial PDF on the homepage.
The short FAQ answers important questions a new developer/user may have.

Here is the original short article form the coder (Attila Áfra) on his blog:
http://voxelium.wordpress.com/2010/0...c-home-cinema/

Quote from the Article:

The ideal solution would be to write a GPU-optimized CMS from scratch, but that’s a lot of work and I’m too busy right now with my ray tracing stuff. A much easier way is to build a 3D LUT with an existing CMS (I’ve opted for Little CMS), which you can sample in a little pixel shader to transform the pixels. 3D LUTs are frequently used in the film industry and are starting to get serious attention in the gaming industry too.

I’m using a 64x64x64 LUT with 16-bit per channel floating point entries, which provides results virtually indistinguishable from those obtained directly with Little CMS. Trilinear interpolation is crucial, and it’s natively supported for this texture format by most (if not all) GPUs released in the past few years. I’ve also added dithering as a final pass to avoid introducing banding artifacts.

Madshi,
Please implement "Little CMS" into MadVR, this will be the best solution for Color Management.

Thanks

[James Freeman]

I got a mail form the official coder of MPC-HC Color Management System (Attila Áfra):

Hi James,

Thanks for the positive feedback! The full source code for the color management is available in the mpc-hc repository:

The renderer code is here (see DX9RenderingEngine.*):
https://github.com/mpc-hc/mpc-hc/tree/master/src/filters/renderer/VideoRenderers

And the shaders (see final.psh):
https://github.com/mpc-hc/mpc-hc/tree/master/src/mpc-hc/res/shaders

It uses the LittleCMS library to generate the 3D LUT.

I'm quite surprised (and disappointed) that MadVR still supports only explicit LUTs. Implementing an ICC-based solution would be quite easy, and it would be very convenient for the users. I don't use MadVR at all because I simply don't want to bother with LUTs. ICC just works, and I think it's the proper way to do color management in a consumer video application. If it's good enough for professional image editing, then why not use in a video player as well?

Regards,
Attila

@Madshi
Its time.
It can't be easier now.

James.