madVR - high quality video renderer (GPU assisted)

[agustin9]

Maybe the display is delivering "fake" 48hz, you should try 60hz with smooth motion on

[huhn]

Originally Posted by huhn

yeah why not discussing this first. but it may be better to drop frames at least if the file fps is a multiply of the display refresh rate (no judder)but let's see what other people on doom9 think after seeing/reproducing this problem.

source: http://bugs.madshi.net/view.php?id=172

the "problem" i see with HFR files on "low" frame rate display is a lot of blur and even ghosting. so i'm question if this is the right way to handle these files.
so a realistic case is a 60 fps file on a max 30 fps screen. (4k hdmi 1.4 displays)

here is a file i created to trigger a bug in madvr(you may encounter it too, but it is reported and fixed in 87.5) it's a real vfr ~ 119 fps 5 sec sample: file

you should be able to reproduce the blur and ghosting from smooth motion.
you only have to actived smooth motion, all smooth motion settings trigger on a 60 fps screen

so what did the reader of this thread think about this? i'm totally aware that this is NOT a serious problem because 120 fps file are very rare and 30 fps max displays even more.

i may created a CFR 120 fps file with really high motion later if i find the time. higher motion= higher effect.

[madshi]

Originally Posted by Francois76l

I'm already in fullscreen exclusive mode.
I will try to desactivate Aero in the MadVr options.

If you're already in FSE mode then you don't need to disable Aero.

Originally Posted by Francois76l

I don't have tearing problems but since a few days I have a lot of jerking especially during rapid movements. I was thinking it could be a VSYNC problem

Please have a look at the debug OSD (Ctrl+J) while you have that jerking. Do any of the queues get near empty at those times? Do you get any dropped or delayed frames listed in the OSD, or presentation glitches? Also please try to increase the size of the CPU and GPU queues (e.g. 16 CPU, 12 GPU) and also the number of pre-presented frames for exclusive mode (I'd suggest at least 8, maybe 12, currently you have 4).

Originally Posted by jaju123

Maybe if enough people submit a bug report here then the issue with d3d9 - opencl interop cost will be fixed by AMD:

http://www.amdsurveys.com/se.ashx?s=5A1E27D25AD12B1A

I don't have much hope, but it might be worth a try. I wish I could still contact AMD devrel. There used to be an email available for that, but it doesn't work, anymore. So I've no way to contact AMD developer relations, anymore.

Originally Posted by annovif

Hello, i've got a light version of windows 8 , can i know what kind of microsoft net framework or other microsoft software i have to load for 0.87.4 madvr full functionality?

You may need to update/install Direct3D9. Windows 7 and 8 only come with a subset of D3D9 functionality, so installing D3D9 might be helpful. Other than that I'm not aware of anything you have to install.

Originally Posted by Shiandow

Does anyone know of a way to apply a shader after smooth motion but before dithering? I made a shader which uses a trick to gamma correct the dithering algorithm, and I'd like to see if this solves the 'blinking' but to do that I need to apply it after the frames are blended.

In the long run I might make things like this possible, but currently it's just not possible.

Originally Posted by huhn

the "problem" i see with HFR files on "low" frame rate display is a lot of blur and even ghosting. so i'm question if this is the right way to handle these files.
so a realistic case is a 60 fps file on a max 30 fps screen. (4k hdmi 1.4 displays)

here is a file i created to trigger a bug in madvr(you may encounter it too, but it is reported and fixed in 87.5) it's a real vfr ~ 119 fps 5 sec sample: file

you should be able to reproduce the blur and ghosting from smooth motion.
you only have to actived smooth motion, all smooth motion settings trigger on a 60 fps screen

so what did the reader of this thread think about this? i'm totally aware that this is NOT a serious problem because 120 fps file are very rare and 30 fps max displays even more.

i may created a CFR 120 fps file with really high motion later if i find the time. higher motion= higher effect.

FWIW, after trying your 120Hz sample, I'm not sure whether I prefer smooth motion to be on or off for this sample (monitor set to 60Hz). With SM FRC on, the whole experience is definitely much smoother. With SM FRC off, it's sharper. But we're talking about aliased game graphics here. Do we really want graphics to be aliased? Then you may want to turn off SM FRC, and you may turn on Nearest Neighbor sampling, too... Ok, just kidding.

I do wonder, though, how filmed 120Hz content looks with smooth motion frc on/off. I think for filmed content it might have less visible disadvantages than game content has. But as I said above, I'm not even sure if I prefer smooth motion frc to be off for game content.

If you do make another sample, please make it a lot longer, like at least 30 seconds or so. Thanks.

[DigitalLF]

MadShi: i got a ATI 5750 and I'm about to get my self a 4k projektor and i think i need a new GPU for MadVR mostly for 1080p processing. What card would you recommend? is it still at the red team? or have you joined the darkside green team (nvidia)?

my signature is very old btw. i will get it fixed.

[Shiandow]

Originally Posted by madshi

In the long run I might make things like this possible, but currently it's just not possible.

That's a shame, although I suspected it wasn't possible yet (since it is very rarely useful). Anyway, I have been able to show that, in principle, you can 'gamma correct' the dithering by changing the input of the dithering algorithm. And I've confirmed that this correction generally doesn't affect the first 16 bits, although for very dark colours it could in theory affect the 10th bit, but this doesn't seem to be very noticeable. I'm also pretty sure that you should use the same 'gamma correction' for smooth motion and dithering otherwise you can get the 'blinking' effect, but I haven't been able to confirm this.

[madshi]

Originally Posted by DigitalLF

MadShi: i got a ATI 5750 and I'm about to get my self a 4k projektor and i think i need a new GPU for MadVR mostly for 1080p processing. What card would you recommend? is it still at the red team? or have you joined the darkside green team (nvidia)?

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.

AMD and NVidia have their own set of advantages and disadvantages, so I can't give a clear recommendation for either one, either. If you decide to get something from AMD, you should definitely get a 7xxx series GPU.

Originally Posted by Shiandow

That's a shame, although I suspected it wasn't possible yet (since it is very rarely useful). Anyway, I have been able to show that, in principle, you can 'gamma correct' the dithering by changing the input of the dithering algorithm. And I've confirmed that this correction generally doesn't affect the first 16 bits, although for very dark colours it could in theory affect the 10th bit, but this doesn't seem to be very noticeable.

Ok, but does this improve overall image quality? Last time I tried, linear light dithering looked worse than gamma light dithering. I think the answer to this question might depend on the output bitdepth. At very low bitdepths, using gamma light is so wrong that any sort of linear light hack will probably improve things. But at higher bitdepths (say 5bit+) using gamma light dithering is probably good enough to avoid obvious gamma problems, and the dithering patterns might look better than when using linear light. This is just a guess, though...

Originally Posted by Shiandow

I'm also pretty sure that you should use the same 'gamma correction' for smooth motion and dithering otherwise you can get the 'blinking' effect, but I haven't been able to confirm this.

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...

[huhn]

new 120 fps test file looks with and without SM terrible.

[iSunrise]

Originally Posted by huhn

new 120 fps test file looks with and without SM terrible.

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. If I pause and play, I get a new still picture and the OSD just updates the dropped frames count.

I tried to dial down all available settings to the bare minimum, but still, I can´t play that file with smooth motion at all.

GPU load without smooth motion is only about 18% in windowed fullscreen, so it´s definitely not the GPU, also CPU is at about 30% max. during playback without SM.

GPU is a GTX580 with 327.23 drivers, CPU is a i7 920@4GHz and display at 60Hz.

EDIT: Found the problem, I had to re-adjust my queue sizes, especially the CPU queue, because the backbuffer queue always went down to 0-2/4 or 0-2/8, which caused permanent drops without madVR even having the chance to update the frames to the display. Works fine now.

[huhn]

sounds ike a bug for the bug tracker.

i got some problems on my gaming pc too (nvidia 760 gtx) but in the end it works.

[cyberbeing]

Kinda strange, it seems like randomly that 120fps file huhn posted wants to playback @ double speed in FSE + Smooth Motion (CTRL+E a few times in FSE with MPC-HC), but only when using a 60hz refresh rate. Probably the same thing causing iSunrise's issue.

With and without Smooth Motion, that 120fps file looks fine when playback is normal speed. It appears to be a human controlled run though, so there are many sudden movements.

[Shiandow]

Originally Posted by madshi

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).

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 .

[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]

Originally Posted by huhn

new 120 fps test file 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.

Originally Posted by iSunrise

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).

Originally Posted by huhn

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.

Originally Posted by Shiandow

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.

Originally Posted by Shiandow

#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.

Originally Posted by 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.

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.

Originally Posted by cyberbeing

@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]

Originally Posted by madshi

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]

Originally Posted by madshi

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 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.