madVR - high quality video renderer (GPU assisted)

[madshi]

Originally Posted by Egh

Does it perform X and Y scaling in the first step if target resolution is less than 50% on each dimension?

No, it does that if the chroma resampling filter needs to work with more than 4 input samples per pixel.

Originally Posted by Egh

Does it also mean that Y scaling is essentially "free" as it is done with the RGB conversion?

No, not at all. There might be a small benefit doing it in the same pass as RGB conversion, because every saved pass helps. But then the overhead per extra pass seems to be surprisingly low. So I don't think there's much difference between doing Y scaling as an extra pass or doing it in the RGB conversion pass. A pass doesn't have a fixed "runtime". It can run through fast or slow, depending on how much work the shaders have to do.

Originally Posted by Egh

There is one other technical issue I wonder: Haali doesn't accept YV12, only YUY2 (or RGB). I was under impression this is done for performance reasons.

I don't know why he's done it that way. Of course if YUY2 or even RGB is sent to the renderer, the renderer has to do less work - but then the CPU has to do more work. The purpose of madVR is to do everything in best possible quality. So madVR does not let decoders do YV12 -> YUY2 upsampling, because all decoders I know are doing this is inferior quality compared to madVR.

[nijiko]

>>madshi

I wonder to know if use 41 for less h/w usage, that, can it be smoothly like 40?

[Mike5]

Originally Posted by madshi

Resample textures:
This is a first processing step which uploads the YCbCr 4:2:0 data (coming from the decoder) to GPU RAM, then usually resamples chroma in X direction and (only if X luma scaling is needed) scales luma in X direction. Under certain circumstances there is a 2nd processing step added, which still falls in the "Resample textures" category, which resamples chroma in Y direction and (only if Y luma scaling is needed) scales luma in Y direction. So this stage consists of at least 1 and at most 4 shader passes. Each shader pass stores the resulting data in 16bit (per channel) buffers.

Interesting. I thought that a chroma resampling algorithm would always resample in Y direction first, to give 4:2:2 and to X direction after that, to give 4:4:4.

[nijiko]

>>madshi

Because I think, end-users always do not care about how much usage and what method to enable effect, but finally what presentation just is the fact.
And it's also what you finally want to do, isn't it?

[nijiko]

Important BUG!!!

Can't step the video and get snapshots...

[tetsuo55]

Originally Posted by nijiko

Important BUG!!!

Can't step the video and get snapshots...

Use the "print screen" button on your keyboard and paste in paint.exe

[mark0077]

Hi, Ran a Test DVD today to check some recent changes to ffdshow, but noticed some badish banding on the gradient test (probably my TV causing alot of this) but wanted to try madVR.

Surprised the "macrovision failed" error still occurs in the latest version. this stopped me using haali for playing back all of my ripped DVD's also... did you get a chance to look into this error madshi? When i ripped these DVD's I removed all protection's and using AnyDVD doesn't have any effect on it..

[nlnl]

Originally Posted by madshi

Resample textures:
This is a first processing step which uploads the YCbCr 4:2:0 data (coming from the decoder) to GPU RAM, then usually resamples chroma in X direction and (only if X luma scaling is needed) scales luma in X direction. Under certain circumstances there is a 2nd processing step added, which still falls in the "Resample textures" category, which resamples chroma in Y direction and (only if Y luma scaling is needed) scales luma in Y direction. So this stage consists of at least 1 and at most 4 shader passes. Each shader pass stores the resulting data in 16bit (per channel) buffers.

Clear:
Simply clears the "backbuffer". madVR skips this step if it's safely possible to do so. However, if the final rendering process only covers a part of the backbuffer, clearing is necessary to avoid garbage pixels at the borders of the backbuffer.

Init Samplers:
This is just some setup work, telling Direct3D which textures we want to use for the final rendering pass. Usually this step should not consume any noticeable resources.

Render:
This is the final rendering step, which eventually upsamples chroma in Y direction and eventually scales luma in Y direction (only if not already done in the "Resample textures" stage). Furthermore, still in the same shader pass, the fully scaled YCbCr 4:4:4 data is converted to RGB, either by using the 3dlut file or by using shader math (depending on the settings). Finally, dithering noise is added. The "Render" stage is always executed in exactly one shader pass.

I have read somewhere that the best way to do resizing is to resize in RGB colorspace (and maybe in "linear light").
And MadVR resizes in YCbCr colorspace if I get your algorithm correctly.
Performance is the problem? What do you think about that?
Thanks!

[nijiko]

Originally Posted by tetsuo55

Use the "print screen" button on your keyboard and paste in paint.exe

I know this way, but it's a bug ,isn't it?

[cyberbeing]

Originally Posted by nijiko

I know this way, but it's a bug ,isn't it?

I would consider it an unsupported feature, rather then a bug.

[nijiko]

Originally Posted by cyberbeing

I would consider it an unsupported feature, rather then a bug.

"Can not step" is also an unsupported feature?
And if snapshot is an unsupported feature, I suggest to disable the menu item, instead to popup a wrong msg.

[Hypernova]

Originally Posted by nijiko

"Can not step" is also an unsupported feature?
And if snapshot is an unsupported feature, I suggest to disable the menu item, instead to popup a wrong msg.

I think madshi already said in this very thread that screeshot is middle priority feature, so you'll have to wait. As a renderer, I don't think it has control over MPC-HC (or other players for that matter) to enable/disable taking screenshot feature either.

[Quark.Fusion]

Originally Posted by madshi

My controls are for *output* levels. CoreAVC has both input and output levels. Haali's Renderer only has controls for *input* levels (which I find backwards). That's why the controls sometimes behave unexpected. IMHO output level control is what we really need, because 99.99% of all content has video input levels, anyway. So controls for input levels is mostly useless, as far as I can see...

User-encoded content can have PC levels. Why we should limit to TV levels in digital era?

[nijiko]

Originally Posted by Hypernova

I think madshi already said in this very thread that screeshot is middle priority feature, so you'll have to wait. As a renderer, I don't think it has control over MPC-HC (or other players for that matter) to enable/disable taking screenshot feature either.

I see. So I just report the problem~ Aha.
But about the step button is invalid, that's a real problem.

[ericgur]

Originally Posted by nlnl

I have read somewhere that the best way to do resizing is to resize in RGB colorspace (and maybe in "linear light").
And MadVR resizes in YCbCr colorspace if I get your algorithm correctly.
Performance is the problem? What do you think about that?
Thanks!

If the video was 4:4:4 format (Y Cb & Cr are of equal dimensions) than using the currently implemented algorithms you'd get the same or very similar results. Since 99.999% of the video is 4:2:0, the resolution of the chroma (Cb & Cr) is half of that of luma (Y) in both directions. RGB only exists in 4:4:4 format so upscaling should be done in YCbCr color space. Scaling in linear light should be avoided. Here's a simple example:
You have 2 samples/pixels with values [0, 100] and you want to find the samples between them. The result should be a linear gradiant. In linear light the sample will be (assuming Gamma of 2 for simplicity):
[0, 100^2] == [0, 10000]
Let's resample the value exactly between 0 and 100 or 0 and 10000.
In gamma corrected space the value will be 50 and in linear space it will be 5000 which is ~71 in gamma corrected space.
The result will not appear linear at all.

[madshi]

Originally Posted by nijiko

I wonder to know if use 41 for less h/w usage, that, can it be smoothly like 40?

From your screenshots I can't see which one is 41 and which is 40. But the one with the lower average GPU rendering times should produce the smoothest result with the "final" madVR version (but not necessarily with the current madVR version).

Originally Posted by nijiko

Can't step the video and get snapshots...

Both problems are already known.

Originally Posted by Mike5

I thought that a chroma resampling algorithm would always resample in Y direction first, to give 4:2:2 and to X direction after that, to give 4:4:4.

It doesn't matter in which direction you scale first. The end result is the same.

Originally Posted by mark0077

Surprised the "macrovision failed" error still occurs in the latest version. this stopped me using haali for playing back all of my ripped DVD's also... did you get a chance to look into this error madshi?

I did look into it and made the one (demo) DVD I have work for me. But it seems that it still doesn't fix the issue for most other DVDs. I'll need to find a real movie DVD. You know, I don't have any DVDs, anymore. Only watching HD content these days...

Originally Posted by nlnl

I have read somewhere that the best way to do resizing is to resize in RGB colorspace (and maybe in "linear light").
And MadVR resizes in YCbCr colorspace if I get your algorithm correctly.
Performance is the problem? What do you think about that?

Performance is the problem with what? With the current algorithm? It doesn't matter much in which colorspace I scale, the scaling performance is the same. However, converting between different colorspaces costs performance.

[madshi]

Originally Posted by ericgur

Scaling in linear light should be avoided. Here's a simple example:
You have 2 samples/pixels with values [0, 100] and you want to find the samples between them. The result should be a linear gradiant. In linear light the sample will be (assuming Gamma of 2 for simplicity):
[0, 100^2] == [0, 10000]
Let's resample the value exactly between 0 and 100 or 0 and 10000.
In gamma corrected space the value will be 50 and in linear space it will be 5000 which is ~71 in gamma corrected space.
The result will not appear linear at all.

Don Munsil and Stacey Spears (the guys who gave the CUE - chroma upsampling error - its name) disagree with you. They actually have a patent on linear light scaling, which is now owned by Microsoft. See here for a post by Don Munsil where he explains why ~71 is actually the value we should get in his opinion:

http://www.avsforum.com/avs-vb/showt...8#post16313488

Here's an extract:

the concept of "perceptual linearity" isn't applicable here, because when we scale an image we are effectively modeling what happens when we take bunch of photons in one set of buckets (pixels) and redistribute them into different buckets. Scaling an image by 50% in both dimensions should produce similar results to taking a picture of the same scene with a digital camera with 50% fewer pixels in both dimensions. It's pretty obvious that this is a physical process, not a perceptual one.

Maybe you could post on AVSForum and discuss with Don? Would love to read the both of you discussing this...

[pirlouy]

About subtitles, you said you would work on it at some point. But are you interested in jfs stuff ? Or do you prefer to implement it your way ?

I know subtitles support is not a priority for you, but for those simple users as me, it's the only thing which prevents your rendered from being used as the default one and then, to help reporting bugs.

Anyhow, your motivation and your work (no problem since v0.1) are really appreciated. Thank you for that.

[nlnl]

madshi

Originally Posted by nlnl View Post
I have read somewhere that the best way to do resizing is to resize in RGB colorspace (and maybe in "linear light").
And MadVR resizes in YCbCr colorspace if I get your algorithm correctly.

Performance is the problem? What do you think about that?
Performance is the problem with what? With the current algorithm? It doesn't matter much in which colorspace I scale, the scaling performance is the same. However, converting between different colorspaces costs performance.

ericgur

If the video was 4:4:4 format (Y Cb & Cr are of equal dimensions) than using the currently implemented algorithms you'd get the same or very similar results. Since 99.999% of the video is 4:2:0, the resolution of the chroma (Cb & Cr) is half of that of luma (Y) in both directions. RGB only exists in 4:4:4 format so upscaling should be done in YCbCr color space. Scaling in linear light should be avoided.

I have found where I read about it.
I am not a video expert. So I just quote recognized authority Don Munsil.

dmunsil
http://archive2.avsforum.com/avs-vb/...2&page=3&pp=30 #88 (very interesting thread by the way)

For best results, scaling should in fact be done with linear-light values, not gamma-corrected values. And of course it should be done in RGB, not Y'CbCr, since Y'CbCr values aren't even gamma-corrected values, they're a linear combination of gamma-corrected values. Mathematically, processing in Y'CbCr is a complete abomination. Practically, it works sorta OK and requires a lot less CPU, so people go ahead and do it.

The best pipeline for scaling images in a Y'CbCr space is:

Y'CbCr->R'G'B'->RGB->[scale]->RGB->R'G'B'->Y'CbCr

Obviously the downsampling and upsampling of the chroma channel for 4:2:0 or 4:2:2 has an effect on the final image, but it can't be helped (other than by not using 4:2:0 or 4:4:4). There's no way to linearize Y', Cb, or Cr.

Don

[nijiko]

>>madshi

Just the picture's name is the version of madVR.