madVR - high quality video renderer (GPU assisted)

[Shiandow]

I'm not convinced about this. Smooth motion blending could in theory mix a black pixel from frame A together with a white pixel from frame B, regardless of bitdepth. Obviously doing this in linear light will result in dramatically different results compared to doing it in gamma light. However, if we're talking about dithering, we're dealing with mixing two neighbor shades in the output bitdepth. The general position of these two shades on the overall gamma curve are not changed by the dithering process. Using linear light will only slightly change how many pixels are drawn with shade 1 and how many with shade 2. Because of that I don't think that smooth motion FRC and dithering would have to use the same gamma function. But I've not tested any of this, so I'm just brainstorming here...

I just confirmed that it also happens when smooth motion is disabled and only when dithering is dynamic. So indeed it seems that I was wrong that the blinking was caused by dithering and smooth motion using different gamma curves. It also seems to happen on places that don't even change colour which also suggests that smooth motion can't be the cause. Something doesn't seem to be as random as it should be.

That aside, I am convinced that it would be better if smooth motion and dithering used the same gamma curves. For instance assume that smooth motion attempts to blend two adjacent colours 1,2. Let's say that the result should be 50% shade 1 and 50% shade 2, if this processing is done in linear light then the resulting colour generally won't be precisely between colours 1 and 2. But then in the dithering step the resulting pixels won't be 50% shade 1 or shade 2 but will be biased towards one of them. You could solve this by changing the gamma curve of smooth motion to be linear in between adjacent colours, or you can change the fractional part of the resulting pixel value such that the right percentage is rounded up instead of rounded down. This last method should in theory give an exact result so that is the one I tried to achieve with the following shader:


#define depth pow(2,8)
sampler s0 : register(s0);

float4 f(float4 x)
{
return pow(x,1/0.45);
}

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
float4 low = floor(depth*c0)/depth;
float4 hi = ceil (depth*c0)/depth;
float4 c1 = (f(c0)-f(low))/(f(hi)-f(low));
return low+(c1/depth);
}


the value 'depth' should be 2^8 if the final output is 8 bits, 2^6 for 6 bits etc. This shader shouldn't change the behaviour of the dithering algorithms much, beyond correcting the colours. In particular the error diffusion algorithms still diffuse errors in gamma light (more or less).

[XMonarchY]

I subbmited OpenCL <-> D3D9 interop bug to the 3 possible places I could. I think everyone here should do the same! If at least 10-15 people do the same - I bet we'll get a fix in the next driver release.

I think we should have a generic letter, something like:
"Dear nVidia,
It has come to my attention that almost all drivers in the past 6 months had non-functional OpenCL <-> D3D9 interop. They all had a bug that affected and still affects one of the best, if not the best, video renderer in existence - madVR. The only driver sets that have a properly working OpenCL <-> D3D9 interop are 326.80 beta and 327.23 WHQL. This bug is 100% driver-caused and not madVR-caused. madVR is a very powerful and popular renderer, recently used by AnandTech to review HTPC performance of CPUs, GPUs, and Windows 8. This review can be found here - http://www.anandtech.com/show/6674/getting-the-best-out-of-an-ivy-bridge-htpc-windows-8-madvr-and-more/7 .

Te OpenCL <-> D3D9 interop bug can be easily reproduced if you:
1. Download and extract the latest madVR from here - http://forum.doom9.org/showthread.php?t=146228
2. Install the latest official 334.89 WHQL drivers, or any drivers other than 326.80 beta and 327.23 WHQL.
3. Activate madVR using the provided install.bat file
4. Select madVR as the main video renderer in any madVR supported player, such as Media Player Classic - Home Cinema, PotPlayer, JRiver, etc.
5. Select NNEDI3 for Chroma Upscalier in madVR settings
6. Play any video file supported by madVR
Since NNEDI3 chroma upscaler specifically utilizes OpenCL, the file video playback will have a heavy green tint to it, caused by OpenCL <-> D3D9 interop bug in nVidia drivers.

OpenCL <-> D3D9 interop bug has been reported before, but nVidia still hasn't fixed it. It is a shame that nVidia forces its graphics card owners and many videophiles to use much older drivers if they want to use madVR, which, again, is not the source of this problem. AMD drivers do not have this problem! If nVidia is to live up to its reputation as a brand that does care for and provide the best driver functionality, stability, and performance, in addition to the best image quality and video fidelity, then it should prompt;y prioritize fixing its OpenCL <-> D3D9 interop driver bug to have it fixed in the next upcoming beta drivers and official drivers. It should also continuously verify that OpenCL <-> D3D9 interop is fully functional before each and every beta and official driver release in the future."

How does this sound? Corrections are welcome since English is my 4th language and things started to get a bit confusing for me after I mastered 3 :stupid:.

[iSunrise]

@XMonarchY:
Sounds just fine.

Personally, I would use "chroma upscaling" instead of "chroma upscaler" so that the driver developers can understand what function in madVR you´re speaking of.

Keep in mind though, that NV has already reproduced the bug internally, after I reported it to Blaire (he´s a member of the NV beta program). They just didn´t come back to use, yet, with a fixed driver.

But I guess it won´t hurt if more people report it.

[madshi]

new 120 fps test file (http://www.file-upload.net/download-8681857/120fpssample2--1-.mkv.html) looks with and without SM terrible.
I don't find it terrible with SM FRC on. But I find it hard to judge. While this sample is nicely long (thanks!) the movements in the video are often very sudden and non-smooth, which makes it hard to judge overall smoothness. Do you have a racing game, maybe? That might be better suited to judge motion smoothness.

FWIW, it seems that VMR9 and EVR-Custom handle this relatively nicely, while madVR doesn't handle it well with SM FRC turned off. madVR is not optimized for showing videos with a frame rate higher than the refresh rate, with SM FRC turned off. I guess I could work on that, but to be honest I don't find it very important atm. I guess for now you could compare VMR9 or EVR-Custom to madVR's SM FRC to compare which you like better.

For some reason I can´t play that file at all here when I enable smooth motion. All I get is a still picture and a lot of dropped frames are showing up in the OSD.
Which is the first queue (from top to bottom) in the OSD which is empty? Probably the upload queue? Try again when v0.87.5 is released (probably in the next 1-2 days).

sounds ike a bug for the bug tracker.
At this point it makes sense to wait for v0.87.5 before posting new bugs to the tracker.

I just confirmed that it also happens when smooth motion is disabled and only when dithering is dynamic. So indeed it seems that I was wrong that the blinking was caused by dithering and smooth motion using different gamma curves. It also seems to happen on places that don't even change colour which also suggests that smooth motion can't be the cause. Something doesn't seem to be as random as it should be.
The blinking seems to occur if the movie framerate isn't identical to the display refresh rate. I think the blinking comes from seeing the dither pattern change in unregular intervals. If you make sure that the movie framerate and display refresh rate match, the blinking goes away. Which proves (I believe) that there's no problem with the randomness.


#define depth pow(2,8)
sampler s0 : register(s0);

float4 f(float4 x)
{
return pow(x,1/0.45);
}

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
float4 low = floor(depth*c0)/depth;
float4 hi = ceil (depth*c0)/depth;
float4 c1 = (f(c0)-f(low))/(f(hi)-f(low));
return low+(c1/depth);
}


the value 'depth' should be 2^8 if the final output is 8 bits, 2^6 for 6 bits etc. This shader shouldn't change the behaviour of the dithering algorithms much, beyond correcting the colours. In particular the error diffusion algorithms still diffuse errors in gamma light (more or less).
Your algorithm might work for ordered dithering, but not for error diffusion. Let me explain why: Error diffusion consists of 2 different parts:

(1) When the target value is between two shades, part 1 of the algorithm decides which shade to draw for the current pixel.
(2) Part 2 takes the pixel drawn by part 1, calculates the error to the original floating point pixel value and spreads the error to the surrounding pixels.

Now it's important to understand that for a big image area Part 2 is really the part which decides about the overall brightness of that image area. While part 1 only decides how the dither pattern looks like (worm artifacts or not etc). Practically that means that for error diffusion your shader only changes the look of the dithering pattern, but it doesn't change the overall image area brightness. So it does not actually do any gamma correction. If you want to do error diffusion gamma correction, you *have* to calculate the error in linear light. There's no way around it.

Let me show this with an example: Let's say in gamma light error diffusion would like to draw 50% of the pixels in shade 1 and 50% in shade 2. Now your linear light algorithm decides to draw shade 1 80% of the time. Initially it will work alright. But doing this will result in the cumulated error growing, because the error calculation is still done in gamma light. At some point the error will flow over so that it's no longer shade 1 and shade 2, but instead it will be shade 2 and shade 3. So basically all your linear light algorithm does for error diffusion is to have more noise because you'll have lots of shade 1 pixels, a few shade 2 pixels and a few shade 3 pixels. Without your linear light algorithm there would only be shade 1 and 2 pixels, so less noise. The overall image brightness would be the same in both cases.

I subbmited OpenCL <-> D3D9 interop bug to the 3 possible places I could. I think everyone here should do the same! If at least 10-15 people do the same - I bet we'll get a fix in the next driver release.
Well, that would be nice! But I somehow doubt it. But let's wait and see...

[cyberbeing]

@XMonarchY
The regression was introduced in the R331 driver branch (black screen + driver hangs).

Starting with 334.89 from the R334 driver branch, the symptoms have changed (green tint? + driver hangs?, I've not tested this driver).

All branches prior to R331 are unaffected, it's not limited to 327.23 & 326.80.

It's worthwhile to make such a distinction between branch-wide driver bugs/symptoms, and release-specific driver bugs/symptoms.

[XMonarchY]

@XMonarchY
The regression was introduced in the R331 driver branch (black screen).

Starting with 334.89 from the R334 driver branch, the symptoms have changed (green tint).

All branches prior to R331 are unaffected, it's not limited to 327.23 & 326.80.

It's worthwhile to make such a distinction between branch-wide driver bugs/symptoms, and release-specific driver bugs/symptoms.

Thank you for the info - I didn't know!

[Shiandow]

Let me show this with an example: Let's say in gamma light error diffusion would like to draw 50% of the pixels in shade 1 and 50% in shade 2. Now your linear light algorithm decides to draw shade 1 80% of the time. Initially it will work alright. But doing this will result in the cumulated error growing, because the error calculation is still done in gamma light. At some point the error will flow over so that it's no longer shade 1 and shade 2, but instead it will be shade 2 and shade 3. So basically all your linear light algorithm does for error diffusion is to have more noise because you'll have lots of shade 1 pixels, a few shade 2 pixels and a few shade 3 pixels. Without your linear light algorithm there would only be shade 1 and 2 pixels, so less noise. The overall image brightness would be the same in both cases.

You seem to assume that you would still calculate the error using the original image. Otherwise you're suggesting that changing the values of the image somehow doesn't change the resulting brightness. I do agree that the shader I suggested has some odd effects due to the fact that the error isn't distributed in linear light, but on average it should at least have the right values.

[iSunrise]

Which is the first queue (from top to bottom) in the OSD which is empty? Probably the upload queue? Try again when v0.87.5 is released (probably in the next 1-2 days).
Edited my original post, which probably was too late for you to see it, while you were writing yours. It was caused by the backbuffer queue (http://forum.doom9.org/showpost.php?p=1671890&postcount=24256) that went down to 0-2/4 or 0-2/8, when smooth motion was active. I solved it by increasing the general CPU queue and the GPU queue, while also increasing the backbuffers for both of the respective modes (windowed/exclusive) to 8, while I had them at 4 before.

It seems smooth motion and 1080p120 requires the queues to be (a lot) higher in general, while I could get away with relatively very low queues until now. But with 1080p120, this was just too much. Then again, 1080p120 content or even higher are not really a common thing (even though the iPhone 5s does 720p120), but I will just keep them for now to be safe. At least now I know why cyberbeing always went with the higher queues, because he wanted to avoid possible ill effects like that happening in the first place.

[seiyafan]

Just want to double check, in MPC under LAV video decoder, what's a good hardware decoder to use? Is it none?

I found out that with deinterlacing enabled, there's massive frame drop when the rendering time is actually less than the time when I disabled deinterlacing with a more difficult upscaling algorithm but noticed no frame drop. What's happening?

[Asmodian]

I prefer none for hardware decoding, software can handle almost anything while the various hardware options all have their different issues. Keep the GPU free for madVR. ;)

deinterlacing is probably doubling the frame rate so you require one half the max rendering times before you get dropped frames. Compare "movie frame interval" and average rendering times in madVR's OSD.

[seiyafan]

This is what I experienced:

http://s27.postimg.org/5zlwyqpf5/Capture.png

Not sure why I was dropping flies with half of the rendering time.

[jkauff]

I prefer none for hardware decoding, software can handle almost anything while the various hardware options all have their different issues. Keep the GPU free for madVR. ;)
There's one use case where hardware decoding makes sense. If you have an Intel iGPU as well as an NVIDIA/AMD dGPU, you can have LAV using the iGPU while madVR is using the dGPU (this is assuming you have a motherboard/BIOS that allows simultaneous use).

When I'm doing a Handbrake encode, the CPU is at or near 100%. If I want to watch a movie at the same time, off-loading the decoding to QuickSync works great. No dropped frames.

[yok833]

I would be happy to participate and send your message to the Nivdia developers.... Could you post 2 or 3 addresses where we can contact them ?

"Envoyé depuis mon GT-I9300 avec Tapatalk"

[THX-UltraII]

This question is asked a lot, and there's no simple answer. It all depends on which algorithms you want to use, which input/output resolutions need to be supported and which movie framerate and display refresh rate etc. Just as an example: If you need support for 60p, the GPU has to be almost 2.5x as fast as it would have to be if you limited yourself to 24p. So that shows clearly how much all of this depends on your exact requirements
My setup is a 4K projector and 99% of the content I use is 23,976fps Blu-Ray content.

I m running madVR with:
- OpenCL option in general settings disabled
- Image doubling disabled
- Luma and Chroma Upscaling @JINC 4taps with AR enabled.
- All trade quality for performance boxes disabled.
- Dithering option 2 with the 2 checkboxes disabled.
- Debanding at 'MID+HIGH'.
- GPU hardware decoding disabled (my CPU takes care of this because you want your GPU free for all other madVR options as much as possible)

My GPU is a AMD 280X oc-ed pretty heavy with the latest 14.2 beta driver. Besides this I m running a i7 2600K

With all these settings my OC-ed 280X (which is basically a HD7970 with a little more power) run @65% GPU usage.

[James Freeman]

- GPU hardware decoding disabled (my CPU takes care of this because you want your GPU free for all other madVR options as much as possible)

If I'm not mistaken, with Nvidia cards there is a separate Video Engine (PureVideo) decoder processor on the GPU for that.
So everything madVR uses as GPU processing is done on the main processor of the GPU and not on the Video Engine decoder.
Isn't that the case with ATI also?

On the other hand CPU decoding is "less buggy" and is constantly updated.
Maybe nevcairiel can clarify how it works.

[madshi]

You seem to assume that you would still calculate the error using the original image.
"newError = originalPixel + cumulatedErrors - drawnPixel". How else would you do it?

Otherwise you're suggesting that changing the values of the image somehow doesn't change the resulting brightness.
You're only changing the pattern, but not the overall brightness. I'm sure about this - unless you also change the way the error is calculated.

It was caused by the backbuffer queue (http://forum.doom9.org/showpost.php?p=1671890&postcount=24256) that went down to 0-2/4 or 0-2/8, when smooth motion was active. I solved it by increasing the general CPU queue and the GPU queue, while also increasing the backbuffers for both of the respective modes (windowed/exclusive) to 8, while I had them at 4 before.

It seems smooth motion and 1080p120 requires the queues to be (a lot) higher in general
Yes, smooth motion does often require higher queues values. To be honest, I don't really see any benefit (worth mentioning) of using short queues.

I found out that with deinterlacing enabled, there's massive frame drop when the rendering time is actually less than the time when I disabled deinterlacing with a more difficult upscaling algorithm but noticed no frame drop. What's happening?
deinterlacing is probably doubling the frame rate so you require one half the max rendering times before you get dropped frames. Compare "movie frame interval" and average rendering times in madVR's OSD.
I agree with Asmodian.

Look at your OSD screenshots: With deinterlacing disabled you have rendering times of 39.57ms, with 25fps. Now if you do the math (1000 / 25fps = 40ms), the rendering times are just small enough. With deinterlacing enabled you have combined rendering times + deinterlacing times of 21.95ms, and you get 50fps out of the deinterlacer. Do the math (1000 / 50fps = 20ms) and you'll see that the rendering times are too high. The deinterlacer doubles the framerate which means rendering times must be half as high to avoid dropped frames.

[James Freeman]

madshi,
The greater the rendering time, the more the video will lag behind the audio?
Is there synchronization between them even with higher rendering time?

Or is it how much time it takes for a single frame to be rendered, and if the time is longer than the video's single frame (1000/24 = 41.7ms), there will be dropped frame?
(as understood from your last post).

[iSunrise]

Yes, smooth motion does often require higher queues values. To be honest, I don't really see any benefit (worth mentioning) of using short queues.
I kind of liked it when the media player felt snappier (also the madVR OSD reacted way faster), that´s why I went with lower queues before, but I agree that after re-visiting the queue settings yesterday, the difference is almost non-existent now, because even though I upped the queues, I didn´t overdo it, so the OSD still reacts almost instantly when I enable/disable it and that test file should be a good worst case scenario to test against. Of course, I could probably just use the defaults and be done with it. Because that´s what I do when I do my bug reports, anyway.

And while we´re at it, I just got an answer from Blaire (current state of the NV madVR driver fix), who wrote me that NV is currently working on the fix. The exact phrase is "Yes. We are still working on it", so this seems to be good news for an upcoming fix in the next 1-2 driver releases hopefully.

[madshi]

The greater the rendering time, the more the video will lag behind the audio?
Is there synchronization between them even with higher rendering time?
As long as it's not a total slide show audio/video sync should always be maintained. If the rendering times are too high, this will just result in frames being dropped.

And while we´re at it, I just got an answer from Blaire (current state of the NV madVR driver fix), who wrote me that NV is currently working on the fix. The exact phrase is "Yes. We are still working on it", so this seems to be good news for an upcoming fix in the next 1-2 driver releases hopefully.
Great - thanks!

[James Freeman]

And while we´re at it, I just got an answer from Blaire (current state of the NV madVR driver fix), who wrote me that NV is currently working on the fix. The exact phrase is "Yes. We are still working on it", so this seems to be good news for an upcoming fix in the next 1-2 driver releases hopefully.

High hopes, fingers crossed, let it be true.

As long as it's not a total slide show audio/video sync should always be maintained. If the rendering times are too high, this will just result in frames being dropped.


Thanks.

[Shiandow]

You're only changing the pattern, but not the overall brightness. I'm sure about this - unless you also change the way the error is calculated.

There seems to be some kind of misunderstanding. The shader is meant to change the input of the dithering algorithm, it would be very odd if this didn't affect the output.

It would be nice if we could agree on a way to make the shader 'correct' since it then gives a way of estimating how 'wrong' the dithering algorithm currently is. If the shader, as I posted it, is correct then the mistakes caused by dithering in gamma light are almost insignificant (i.e. not noticeable with 16 bits) except in some very rare cases where a pixel value is inbetween two colours that are almost black.

[Aikibana]

And while we´re at it, I just got an answer from Blaire (current state of the NV madVR driver fix), who wrote me that NV is currently working on the fix. The exact phrase is "Yes. We are still working on it", so this seems to be good news for an upcoming fix in the next 1-2 driver releases hopefully.

Now let's start the same initiative at AMD for fixing the OpenCL-D3D9 Interop lag :)

Although I have high hopes a D3D9 > D3D10/11 > OpenCL routing might improve this, when Madshi finds the time.

[toniash]

What to look for if my render queues don't fill up completely?

[THX-UltraII]

If I'm not mistaken, with Nvidia cards there is a separate Video Engine (PureVideo) decoder processor on the GPU for that.
So everything madVR uses as GPU processing is done on the main processor of the GPU and not on the Video Engine decoder.
Isn't that the case with ATI also?

On the other hand CPU decoding is "less buggy" and is constantly updated.
Maybe nevcairiel can clarify how it works.Like you said, CPU processing is stable as hell and since I m not using SVP anymore I have loads of CPU power left.

Aren t you also using a Sony VW1000 as display device like me? What are you preferred settings for 2K to 4K Blu-Ray content upscaling with madVR? Something like the settings I use?

[James Freeman]

Aren t you also using a Sony VW1000 as display device like me?

:D No, It wasn't me (although I really wish it was).
I still don't have the 25,000$ (:scared:) to shed on a projector...

[THX-UltraII]

:D No, It wasn't me (although I really wish it was).
I still don't have the 25,000$ (:scared:) to shed on a projector...

I must have mistaken you for someone else. My bad.

But what is your thought about my settings when thinking '2K to 4K' upscaling.

[James Freeman]

But what is your thought about my settings when thinking '2K to 4K' upscaling.

Debanding (MID), softens your image.
If you watch original (non-internet) Blu-Rays, disable debanding (or set to Low if its a 10GB+ internet content).

JINC is good but, I still prefect Lanczos because it preserves the detail at higher frequencies, whether Jinc blurs them a little (as I see it).


One more (important) thing,
Use this (MPC LumaSharpen) shader Its the best sharpenning shader available (IMO), Yes way better (and smarter) than Sharpen Complex 2.
It will not touch the finest detail (add contrast) but will sharpen the not sharp enough detail/textures.

Copy into a .hlsl (if using MPC-HC) file and activate the pixel shader,


/*
_____________________

LumaSharpen 1.4.1
_____________________

by Christian Cann Schuldt Jensen ~ CeeJay.dk

It blurs the original pixel with the surrounding pixels and then subtracts this blur to sharpen the image.
It does this in luma to avoid color artifacts and allows limiting the maximum sharpning to avoid or lessen halo artifacts.

This is similar to using Unsharp Mask in Photoshop.

Compiles with 3.0
*/

/*-----------------------------------------------------------.
/ User settings /
'-----------------------------------------------------------*/

#define sharp_strength 0.65
#define sharp_clamp 0.035
#define pattern 8
#define offset_bias 1.0
#define show_sharpen 0

/*-----------------------------------------------------------.
/ Developer settings /
'-----------------------------------------------------------*/
#define CoefLuma float3(0.2126, 0.7152, 0.0722) // BT.709 & sRBG luma coefficient (Monitors and HD Television)
//#define CoefLuma float3(0.299, 0.587, 0.114) // BT.601 luma coefficient (SD Television)
//#define CoefLuma float3(1.0/3.0, 1.0/3.0, 1.0/3.0) // Equal weight coefficient

/*-----------------------------------------------------------.
/ Main code /
'-----------------------------------------------------------*/

float4 p0 : register(c0);
sampler s0 : register(s0);

#define px (1.0 / p0[0])
#define py (1.0 / p0[1])

float4 main(float2 tex : TEXCOORD0) : COLOR0
{
// -- Get the original pixel --
float3 ori = tex2D(s0, tex).rgb; // ori = original pixel
float4 inputcolor = tex2D(s0, tex);

// -- Combining the strength and luma multipliers --
float3 sharp_strength_luma = (CoefLuma * sharp_strength); //I'll be combining even more multipliers with it later on

/*-----------------------------------------------------------.
/ Sampling patterns /
'-----------------------------------------------------------*/
// [ NW, , NE ] Each texture lookup (except ori)
// [ ,ori, ] samples 4 pixels
// [ SW, , SE ]

// -- Pattern 1 -- A (fast) 7 tap gaussian using only 2+1 texture fetches.
#if pattern == 1

// -- Gaussian filter --
// [ 1/9, 2/9, ] [ 1 , 2 , ]
// [ 2/9, 8/9, 2/9] = [ 2 , 8 , 2 ]
// [ , 2/9, 1/9] [ , 2 , 1 ]

float3 blur_ori = tex2D(s0, tex + (float2(px, py) / 3.0) * offset_bias).rgb; // North West
blur_ori += tex2D(s0, tex + (float2(-px, -py) / 3.0) * offset_bias).rgb; // South East

//blur_ori += tex2D(s0, tex + float2(px,py) / 3.0 * offset_bias); // North East
//blur_ori += tex2D(s0, tex + float2(-px,-py) / 3.0 * offset_bias); // South West

blur_ori /= 2; //Divide by the number of texture fetches

sharp_strength_luma *= 1.5; // Adjust strength to aproximate the strength of pattern 2

#endif

// -- Pattern 2 -- A 9 tap gaussian using 4+1 texture fetches.
#if pattern == 2

// -- Gaussian filter --
// [ .25, .50, .25] [ 1 , 2 , 1 ]
// [ .50, 1, .50] = [ 2 , 4 , 2 ]
// [ .25, .50, .25] [ 1 , 2 , 1 ]


float3 blur_ori = tex2D(s0, tex + float2(px, -py) * 0.5 * offset_bias).rgb; // South East
blur_ori += tex2D(s0, tex + float2(-px, -py) * 0.5 * offset_bias).rgb; // South West
blur_ori += tex2D(s0, tex + float2(px, py) * 0.5 * offset_bias).rgb; // North East
blur_ori += tex2D(s0, tex + float2(-px, py) * 0.5 * offset_bias).rgb; // North West

blur_ori *= 0.25; // ( /= 4) Divide by the number of texture fetches

#endif

// -- Pattern 3 -- An experimental 17 tap gaussian using 4+1 texture fetches.
#if pattern == 3

// -- Gaussian filter --
// [ , 4 , 6 , , ]
// [ ,16 ,24 ,16 , 4 ]
// [ 6 ,24 , ,24 , 6 ]
// [ 4 ,16 ,24 ,16 , ]
// [ , , 6 , 4 , ]

float3 blur_ori = tex2D(s0, tex + float2(0.4*px, -1.2*py)* offset_bias).rgb; // South South East
blur_ori += tex2D(s0, tex + float2(-1.2*px, -0.4*py) * offset_bias).rgb; // West South West
blur_ori += tex2D(s0, tex + float2(1.2*px, 0.4*py) * offset_bias).rgb; // East North East
blur_ori += tex2D(s0, tex + float2(-0.4*px, 1.2*py) * offset_bias).rgb; // North North West

blur_ori *= 0.25; // ( /= 4) Divide by the number of texture fetches

sharp_strength_luma *= 0.51;
#endif

// -- Pattern 4 -- A 9 tap high pass (pyramid filter) using 4+1 texture fetches.
#if pattern == 4

// -- Gaussian filter --
// [ .50, .50, .50] [ 1 , 1 , 1 ]
// [ .50, , .50] = [ 1 , , 1 ]
// [ .50, .50, .50] [ 1 , 1 , 1 ]

float3 blur_ori = tex2D(s0, tex + float2(0.5 * px, -py * offset_bias)).rgb; // South South East
blur_ori += tex2D(s0, tex + float2(offset_bias * -px, 0.5 * -py)).rgb; // West South West
blur_ori += tex2D(s0, tex + float2(offset_bias * px, 0.5 * py)).rgb; // East North East
blur_ori += tex2D(s0, tex + float2(0.5 * -px, py * offset_bias)).rgb; // North North West

//blur_ori += (2 * ori); // Probably not needed. Only serves to lessen the effect.

blur_ori /= 4.0; //Divide by the number of texture fetches

sharp_strength_luma *= 0.666; // Adjust strength to aproximate the strength of pattern 2
#endif

// -- Pattern 8 -- A (slower) 9 tap gaussian using 9 texture fetches.
#if pattern == 8

// -- Gaussian filter --
// [ 1 , 2 , 1 ]
// [ 2 , 4 , 2 ]
// [ 1 , 2 , 1 ]

half3 blur_ori = tex2D(s0, tex + float2(-px, py) * offset_bias).rgb; // North West
blur_ori += tex2D(s0, tex + float2(px, -py) * offset_bias).rgb; // South East
blur_ori += tex2D(s0, tex + float2(-px, -py) * offset_bias).rgb; // South West
blur_ori += tex2D(s0, tex + float2(px, py) * offset_bias).rgb; // North East

half3 blur_ori2 = tex2D(s0, tex + float2(0, py) * offset_bias).rgb; // North
blur_ori2 += tex2D(s0, tex + float2(0, -py) * offset_bias).rgb; // South
blur_ori2 += tex2D(s0, tex + float2(-px, 0) * offset_bias).rgb; // West
blur_ori2 += tex2D(s0, tex + float2(px, 0) * offset_bias).rgb; // East
blur_ori2 *= 2.0;

blur_ori += blur_ori2;
blur_ori += (ori * 4); // Probably not needed. Only serves to lessen the effect.

// dot()s with gaussian strengths here?

blur_ori /= 16.0; //Divide by the number of texture fetches

//sharp_strength_luma *= 0.75; // Adjust strength to aproximate the strength of pattern 2
#endif

// -- Pattern 9 -- A (slower) 9 tap high pass using 9 texture fetches.
#if pattern == 9

// -- Gaussian filter --
// [ 1 , 1 , 1 ]
// [ 1 , 1 , 1 ]
// [ 1 , 1 , 1 ]

float3 blur_ori = tex2D(s0, tex + float2(-px, py) * offset_bias).rgb; // North West
blur_ori += tex2D(s0, tex + float2(px, -py) * offset_bias).rgb; // South East
blur_ori += tex2D(s0, tex + float2(-px, -py) * offset_bias).rgb; // South West
blur_ori += tex2D(s0, tex + float2(px, py) * offset_bias).rgb; // North East

blur_ori += ori.rgb; // Probably not needed. Only serves to lessen the effect.

blur_ori += tex2D(s0, tex + float2(0, py) * offset_bias).rgb; // North
blur_ori += tex2D(s0, tex + float2(0, -py) * offset_bias).rgb; // South
blur_ori += tex2D(s0, tex + float2(-px, 0) * offset_bias).rgb; // West
blur_ori += tex2D(s0, tex + float2(px, 0) * offset_bias).rgb; // East

blur_ori /= 9; //Divide by the number of texture fetches

//sharp_strength_luma *= (8.0/9.0); // Adjust strength to aproximate the strength of pattern 2
#endif


/*-----------------------------------------------------------.
/ Sharpen /
'-----------------------------------------------------------*/

// -- Calculate the sharpening --
float3 sharp = ori - blur_ori; //Subtracting the blurred image from the original image

#if 0 //New experimental limiter .. not yet finished
float sharp_luma = dot(sharp, sharp_strength_luma); //Calculate the luma
sharp_luma = (abs(sharp_luma)*8.0) * exp(1.0 - (abs(sharp_luma)*8.0)) * sign(sharp_luma) / 16.0; //I should probably move the strength modifier here

#elif 0 //SweetFX 1.4 code
// -- Adjust strength of the sharpening --
float sharp_luma = dot(sharp, sharp_strength_luma); //Calculate the luma and adjust the strength

// -- Clamping the maximum amount of sharpening to prevent halo artifacts --
sharp_luma = clamp(sharp_luma, -sharp_clamp, sharp_clamp); //TODO Try a curve function instead of a clamp

#else //SweetFX 1.5.1 code
// -- Adjust strength of the sharpening and clamp it--
float4 sharp_strength_luma_clamp = float4(sharp_strength_luma * (0.5 / sharp_clamp), 0.5); //Roll part of the clamp into the dot

//sharp_luma = saturate((0.5 / sharp_clamp) * sharp_luma + 0.5); //scale up and clamp
float sharp_luma = saturate(dot(float4(sharp, 1.0), sharp_strength_luma_clamp)); //Calculate the luma, adjust the strength, scale up and clamp
sharp_luma = (sharp_clamp * 2.0) * sharp_luma - sharp_clamp; //scale down
#endif

// -- Combining the values to get the final sharpened pixel --
//float4 done = ori + sharp_luma; // Add the sharpening to the original.
inputcolor.rgb = inputcolor.rgb + sharp_luma; // Add the sharpening to the input color.

/*-----------------------------------------------------------.
/ Returning the output /
'-----------------------------------------------------------*/
#if show_sharpen == 1
//inputcolor.rgb = abs(sharp * 4.0);
inputcolor.rgb = saturate(0.5 + (sharp_luma * 4)).rrr;
#endif

return saturate(inputcolor);
}

[THX-UltraII]

Debanding (MID), softens your image. If you watch original (non-internet) Blu-Rays, disable debanding.I thought that uncompressed Blu-Ray content can have debanding too?

JINC is good but, I still prefect Lanczos because it preserves the detail at higher frequencies, whether Jinc blurs them a little (as I see it).I took JINC because it is a newer algo :). What do you think about using NNEDI3 for Chroma Upscaling and Lanczos for Luma Upscaling? Or is it prefferable to always use the same algorithm for both luma and chroma upscaling? (why is NNEDI3 not available for Luma Upscaling btw?)

One more (important) thing,
Use this (MPC LumaSharpen) shader (Its the best sharpenning shader available (IMO)You say to use this on top of the scaling algorithms in madVR? Won t that cause any major artifacts?

[James Freeman]

I thought that uncompressed Blu-Ray content can have debanding too?
Seldom.
Not deserving MID Debaning treatment.

I took JINC because it is a newer algo :). What do you think about using NNEDI3 for Chroma Upscaling and Lanczos for Luma Upscaling?
Or is it preferable to always use the same algorithm for both luma and chroma upscaling? (why is NNEDI3 not available for Luma Upscaling btw?)

I use Lanczos 3 AR for all, NNEDI3 still does not work for me.
Maybe someone else can answer you that more specifically.

You say to use this on top of the scaling algorithms in madVR? Won t that cause any major artifacts?
Try it and thank me later. ;)
I updated the code, so be sure to copy the 1.4.1 version.


@madshi
Can MadVR load pixel shaders?
I think I hear something similar somewhere...

[madshi]

There seems to be some kind of misunderstanding. The shader is meant to change the input of the dithering algorithm
Oh, ok, I didn't understand it this way. Alright, it could be interesting to test this. I might release a test build which uses your pre-processing.

What to look for if my render queues don't fill up completely?
Render queues? There is only one render queue. Maybe post a screenshot of the debug OSD, then we might be able to say more.

Debanding (MID), softens your image.
If you watch original (non-internet) Blu-Rays, disable debanding (or set to Low if its a 10GB+ internet content).

[...]

One more (important) thing,
Use this (MPC LumaSharpen) shader Its the best sharpenning shader available (IMO), Yes way better (and smarter) than Sharpen Complex 2.
It will not touch the finest detail (add contrast) but will sharpen the not sharp enough detail/textures.
James, posting suggestions and recommendations is fine, but please make sure you mark these as your personal subjective opinion. You do sound a bit as if you your recommendations would be what everybody agreed on being the best settings. Which is definitely not the case here.

IMHO, using a deband setting of "low" can still make sense for Blu-Ray, but that's only my personal opinion and I know that some people will disagree. Sharpening is also very controversial. Some people hate it. Some people love it.

I thought that uncompressed Blu-Ray content can have debanding too?
Yes, it can happen.

I took JINC because it is a newer algo :)
FYI, from what I've seen, most people prefer Jinc. A minority of people prefer Lanczos. You may want to make up your own mind which you prefer.

Can MadVR load pixel shaders?
I think I hear something similar somewhere...
I don't understand what you mean. madVR does support custom pixel shaders, if that is your question.

[James Freeman]

James, posting suggestions and recommendations is fine, but please make sure you mark these as your personal subjective opinion. You do sound a bit as if you your recommendations would be what everybody agreed on being the best settings. Which is definitely not the case here.

Of course.
Everything I post is IMO only.
I'm thinking about putting a big disclaimer in my signiture.. Maybe...:D


I don't understand what you mean. madVR does support custom pixel shaders, if that is your question.
How?

[nevcairiel]

How?

Just load them in MPC-HC like you would with its built-in renderer (Options -> Playback -> Shaders), madVR accepts them the same way.

[Boltron]

I really would love to use a sharpen filter but I use JRiver and can't find a way to do it. Madshi did mention one or twice that he could add a means to include a filter that wouldn't be too difficult to do. I can only hope.

[James Freeman]

Just load them in MPC-HC like you would with its built-in renderer (Options -> Playback -> Shaders), madVR accepts them the same way.

Thanks, that's what I was doing.
I thought there was a way to load shaders directly to madVR.

P.S
madshi, I realize most people don't like the Ringing or other artifacts sharpening may give (I hate them too)... but not this one.
I'm not just saying that this is the best one there is when I say try it, I really mean it and urge people to try it (if they disliked sharpening before).

This post is IMO only. ;)

[Shiandow]

Oh, ok, I didn't understand it this way. Alright, it could be interesting to test this. I might release a test build which uses your pre-processing.

That would be nice. I think it would improve the contrast slightly for people who are using 6bit output (or even lower). For 8 bit output it will only cause minute differences for very dark colours, so in that case it probably won't be really noticeable. But, at least in theory, it should fix any problems caused by the fact that smooth motion and dithering don't use the same gamma curve.

Unfortunately it doesn't seem that it will fix the 'blinking' problem and the more I think about that the less sense it seems to make. I can't understand why it seems to work regardless of smooth motion, but only when the frame rate doesn't match the display frame rate.

[huhn]

I thought that uncompressed Blu-Ray content can have debanding too?
i can show you a lot of bd with banding. anime suffer a lot from this issue. bd are just weak encoded high bitrate h264 stream (in best case)
I took JINC because it is a newer algo :). What do you think about using NNEDI3 for Chroma Upscaling and Lanczos for Luma Upscaling? Or is it prefferable to always use the same algorithm for both luma and chroma upscaling? (why is NNEDI3 not available for Luma Upscaling btw?)

it is but nnedi can only double the resolution. it can upscale 480p to 960 but it can't do 720 -> 1080.
not sure if any gpu can handle nnedi32 neurons 1080 -> 2160 but give it a try. you find it under image doubling.
You say to use this on top of the scaling algorithms in madVR? Won t that cause any major artifacts?
it's sharping you never get this for free. same for debanding.

[THX-UltraII]

What do you prefer for debanding for Blu-Ray content Madshi?

LOW/LOW
LOW/MID
LOW/HIGH
MID/LOW
MID/MID
MID/HIGH
HIGH/LOW
HIGH/MID
or
HIGH/HIGH

[THX-UltraII]

James, why do you prefer LANCZOS over JINC exactly?

[kasper93]

What do you prefer for debanding for Blu-Ray content Madshi?

LOW/LOW
LOW/MID
LOW/HIGH
MID/LOW
MID/MID
MID/HIGH
HIGH/LOW
HIGH/MID
or
HIGH/HIGH

FIGUREOUTYOURSELF/DONTBELAZY

You haven't even bother to test it... You can't do HIGH/LOW and others...

It's a matter of taste. The same with scaling. If there were "best" option madshi wouldn't have include those settings.

Tapatalk 4 @ GT-I9300

[seiyafan]

What do you think about using NNEDI3 for Chroma Upscaling and Lanczos for Luma Upscaling?

Can your 280x handle NNEDI3 to 4k?

[James Freeman]

James, why do you prefer LANCZOS over JINC exactly?
I have done a bunch of testing with patterns and movies,
The remaining aliasing (ever so small) with Lanczos translates to better detail at higher frequency, whether Jinc will blur the detail.

Jinc will look better (smoother) on perfect diagonals only, on anything else it looks just like Lanczos.
Also, Lanczos 8 uses less juice than Jinc 3.

For Upscaling I use: Lanczos 3 + AR (no LL).
For Downscaling I use: Catmull-Rom (no LL).

This post is IMO only.

[seiyafan]

you can have LAV using the iGPU while madVR is using the dGPU (this is assuming you have a motherboard/BIOS that allows simultaneous use).


That's interesting. I have 4770k but Quicksync option shows up as inactive, I never knew that has something to do with motherboard.

I wonder if it's possible for Quicksync to do deinterlacing, because if I give the job to MadVR it would need twice the rendering power since it doubles the frames per second.

[THX-UltraII]

Can your 280x handle NNEDI3 to 4k?Yes. Keep in mind that I am talking about Chroma Upscaling NNEDI3@32, NOT talking about image doubling NNEDI3

[THX-UltraII]

FIGUREOUTYOURSELF/DONTBELAZY

You haven't even bother to test it... You can't do HIGH/LOW and others...

It's a matter of taste. The same with scaling. If there were "best" option madshi wouldn't have include those settings.

Tapatalk 4 @ GT-I9300Chill out a little dude.
I am NOT asking for what is better. I am specifically asking Madshi what he prefers when playing 1080p Blu-Ray content.

[THX-UltraII]

Jinc will look better (smoother) on perfect diagonals only, on anything else it looks just like Lanczos.
This post is IMO only.Interesting

[nevcairiel]

I wonder if it's possible for Quicksync to do deinterlacing, because if I give the job to MadVR it would need twice the rendering power since it doubles the frames per second.

Whatever you use for deinterlacing, it should always double the number of frames.

[iSunrise]

Chill out a little dude.
I am NOT asking for what is better. I am specifically asking Madshi what he prefers when playing 1080p Blu-Ray content.
He has a point, though, and a very good one. Why exactly would that help you, when madshi doesn´t have access to a 4K projector? And even if he did, he probably doesn´t have the same model you do, which also does make a difference.

Why don´t you just test it yourself, instead of posting 20 posts asking everyone about their respective opinions when everyone of us has a completely different setup than you do. Everyone has a different taste, too, which you can see when you actually followed our dithering discussion. I see that with you a lot. If a new build and feature comes out, you always ask for "the best" settings, but you never actually provide an opinion yourself. It´s like you don´t even exist and just copy blindly what other users prefer, instead of making up your own mind about it. I totally don´t get that at all. Especially since your high-end 4K projector should make some differences really obvious and make the differences clearly visible.

Personally, on a 4K device, NNEDI3 luma doubling should always be enabled in your case, NNEDI3 chroma upscaling always second. And I´m not even talking about NNEDI3 chroma doubling, because most of us don´t have a 4K device. Left are Lanczos, which is the sharpest with side-effects, while Jinc is sometimes more accurate, also with side-effects, so it´s all a matter of preference and the content that you feed madVR.

[QBhd]

Hi guys (and maybe gals, it's hard to tell)... I have a question regarding gamma correction and calibration settings. I have this info from Monitor Asset Manager's Real-time EDID:

Color characteristics
Default color space...... Non-sRGB
Display gamma............ 2.50
Red chromaticity......... Rx 0.640 - Ry 0.340
Green chromaticity....... Gx 0.300 - Gy 0.690
Blue chromaticity........ Bx 0.138 - By 0.038
White point (default).... Wx 0.282 - Wy 0.297
Additional descriptors... None

I was wondering if any of this info can or should be used in the device calibration settings for gamma.... and if so, what should be the corresponding gamma correction settings?

I have tinkered with a calibration setting of pure power curve of 2.5 gamma and pure power curve 2.35 in the gamma correction... but I wasn't happy with the results. I have also tried other combos, and currently have both set at disabled (again not happy with the results). I don't have access to calibration gear, but thought maybe I could get better results if I understood what my TV's gamma is (pure pc, bt.709, etc. etc.) and what the target should be for gamma correction.

I have included screen shots of the two settings in question if there is any confusion about what I am talking about :)

http://i.imgur.com/gBt908q.png

http://i.imgur.com/53KeFtd.png

Thanks in advance,

QB

[madshi]

I really would love to use a sharpen filter but I use JRiver and can't find a way to do it. Madshi did mention one or twice that he could add a means to include a filter that wouldn't be too difficult to do. I can only hope.
Maybe sooner or later, but not in the next build.

Unfortunately it doesn't seem that it will fix the 'blinking' problem and the more I think about that the less sense it seems to make. I can't understand why it seems to work regardless of smooth motion, but only when the frame rate doesn't match the display frame rate.
I'm not 100% sure about the exact cause of the blinking problem, either. I *think* it's just the irregular interval at which the dithering pattern changes, but I'm not totally sure...

Whatever you use for deinterlacing, it should always double the number of frames.
Exactly. Unless we're talking film content, of course.

Hi guys (and maybe gals, it's hard to tell)... I have a question regarding gamma correction and calibration settings.
Maybe someone else can help out. This is not my area of expertise.

[madshi]

madVR v0.87.5 released

http://madshi.net/madVR.zip

* error diffusion now uses DirectCompute (DX11 GPU needed) instead of OpenCL
* added fast and reasonably high quality "ordered dithering" algorithm
* added "rendering\dithering" settings page with many new options
* new default dithering is now ordered dithering instead of random dithering
* madTPG now always uses monochromatic ordered dithering
* fixed: #107: XySubFilter: reducing CPU queue size during playback -> crash
* fixed: #112: 120fps clip resulted in 23Hz being selected instead of 60Hz
* fixed: #119: installation resulted in "might not have installed correctly"
* fixed: #123: XySubFilter: Nearest Neighbor/Bilinear distorted subtitles
* fixed: #125: forced film mode with unsupported FOURCCs: graphical corruption
* fixed: #133: XySubFilter: opaque black box when smooth motion was enabled
* fixed: #136: when playback is stopped, madVR now always turns the video off
* fixed: #137: Nearest Neighbor/Bilinear has problems with post-resize shaders
* fixed: #138: smooth motion FRC flickered when using Nearest Neighbor
* fixed: #145: DCI-P3 was using an incorrect white point
* fixed: #155: screeshots sometimes had an added black border
* fixed: #159: speciying DCI-P3 as the calibrated gamut -> green screen
* fixed: #160: corruption with uncompressed 4096x2304 v210 in AVI
* fixed: #161: YUV 4:4:4 videos with weird resolutions crashed madVR
* fixed: #165: overlay mode restricted madVR to single player window
* fixed: #167: dithering produced dithering noise on pure black areas
* fixed: #169: dithering produced dithering noise on pure white areas
* fixed: #170: Overlay mode sometimes unnecessarily cleared GPU gamma ramps
* fixed: Overlay mode applied 3dlut and gamma ramps in wrong order
* fixed: crash reporting didn't catch exceptions in private threads, anymore
* fixed: crash when using XySubFilter with small GPU queue size
* fixed: DVD navigator was not released properly by madVR
* fixed: Run/Seek hooks also affected secondary DirectShow graphs
* fixed: profile key shortcuts only worked for "scaling" profiles
* fixed: full range YCbCr input produced slightly incorrect colors
* reduced Overlay mode graphical corruption when resizing media player
* exclusive -> windowed switch now shows a black frame instead of an old one
* removed XySubFilter auto-loading functionality, it's now XySubFilter's job
* disabled resolution based DCI-P3 auto detection
* changed default luma doubling value to 32 neurons
* display bitdepth can be be set to as low as 3bit (just for testing)
As you can see, this build contains a LOT of bugfixes. There are still some bugfixes left to do (see bug tracker), but I wanted to release a new official build with the new dithering algorithms now. There'll probably be a v0.87.6 in the near future with some more bugfixes.

Please note that there's also a new XySubFilter build which I recommend to use. See here:

http://forum.doom9.org/showthread.php?t=168282