madVR - high quality video renderer (GPU assisted)

[daglax]

How do you apply Avisynth after upscaling?

That's not possible, if you use madvr for upscaling. But you can apply the sharpen depending on your video heigth/width

[TheShadowRunner]

But why would changing the subtitle track result in an exclusive -> windowed switch? Sounds weird to me. Anyway, please create a bug tracker entry for this with an exact description of the situation, e.g. exclusive mode or not. Also please try other subtitle renderers, to find out whether the problem also occurs with e.g. xy-vsfilter, or XySubFilter. Thanks.
Sure, I reported the bug here (http://bugs.madshi.net/view.php?id=187).
I tried with xy-vsfilter as well, same issue.
I attached a sample that can be used to recreate the issue.
Thanks for your support!

[iSunrise]

...My biggest surprise is that 780 performs much closer to the 280x, in fact it's slower than 280x in some occasions, especially with ED turned on. We all know 780 is faster than 280x in every game, so I am guessing the MadVR performance has something to do with memory bus width? 290 is noticeably faster than the 780.
Keep in mind that for NV we still have to use a rather old driver so that everything in madVR works correctly. You can expect noticably better performance from NV with later drivers with madVR in some cases, since NV optimized their OpenCL/OpenCompute compilers quite a bit since 327.23. At least that's what I've been told. I hope that I soon get an update on the reported driver issue, they have been pretty silent the last couple of weeks.

[DarkSpace]

That sounds like your best option would be to disable dithering altogether (use simple rounding)
No. Please don't ever do that.
In my defense, please note that I did not recommend that, I merely noted that if dithering noise really threw off the Motion Estimation algorithm, getting rid of the noise would improve the Motion Estimation.
That sounds like your best option would be to disable dithering altogether (use simple rounding), as even static dithering introduces some patterns. And that sounds just wrong.
I guess I really should work on wording stuff less... misunderstandable, because now that you mention it, I, too, see how that can be misunderstood. :o

[Cinemancave]

You didn't say whether you use NNEDI for luma doubling or chroma upscaling, so I can't really answer your question.

In any case, why don't you simply try all possible combinations and then report back here which one produces the best overall image quality in your opinion? Please also try sharpening via a custom pixel shader (e.g. see LumaSharpen) or via AviSynth, as an alternative to the Darbee sharpening. Would be interesting to have a shootout between those different options.

I use NNEDI for chroma upscaling. I almost only watch 1080p content. So, in theory, should I still benefit from MadVR's high quality RGB output even if an external processor later on in the chain converts to YcBcR color space?

I will be doing some tests next week and report back with my findings. However, since I am not as knowledgeable as some of you guys at this stuff, my results will probably be very subjective as I am not sure how to set up such a comparison test in a more objective kind of way. I'm open to suggestions on how to best do it though. So feel free to give me some advice :)

[turbojet]

If I wanted to keep some more of the sharpness effect from nnedi, is there anything "wrong" with using Lanczos 4 AR for downsizing after nnedi doubling instead of CR AR? All I ever see recommended for downsizing is CR AR.

I've never understood CR-AR-LL for downscaling. To my eyes, only softcubic, bilinear and NN look worse but it's all subjective.


I believe sharpening *after* upscaling is usually much better than *before* upscaling. E.g. see here for a small comparison:

| -- original (http://madshi.net/castleOrg.png) -- | -- NNEDI3 doubling (http://madshi.net/sharpenDisabledNNEDI.png) -- | -- sharpen before NNEDI3 doubling (http://madshi.net/sharpenBeforeNNEDI.png) -- | -- sharpen after NNEDI3 doubling (http://madshi.net/sharpenAfterNNEDI.png) -- |

Ok, this is rather strong sharpening (probably too strong), using some AviSynth algorithms. But it nicely shows how sharpening after upscaling works much better than sharpening before upscaling - at least when using NNEDI3.

I don't think I should recommend whether sharpening should be used or not. I think everybody should decide for himself. I do think when using large upscaling factors, some sharpening might make sense to get rid of the softness caused by upscaling.

The artifacts on high contrast edges, due to very strong sharpening, in the presize pic make this comparison convincing. My criticism with post resize sharpening is it doesn't have much effect even with really strong sharpening for some odd reason. Here's a comparison with the original castle pic. NNEDI3 doubled to 800x600 then upscaled to 1080p with lanczos4ar, lumasharpen 1.0 strength, pattern 3, clamp 0.5.

pre resize (http://someimage.com/CmPwxUj)
post resize (http://someimage.com/o2jmqKt)
pre and post resize (http://someimage.com/speT3um)

Max strength, 3.0, with post resize (http://someimage.com/s9MDEaB) doesn't have much more effect but it's unbearable watching anything with this and preresize. (http://someimage.com/mKKw309)

Also my focus is on lower contrast edges, like faces, preresize has a great effect on this while postresize has very little, it mostly effects high contrast edges.

[Asmodian]

I don't think that's a good idea. E.g. 480p60 could mean that NNEDI3 is used for frame doubling, and that 60 times per second. While 720p30 might disable NNEDI3 and at the same time only require 30 frames per second to be rendered. Generally the framerate is much more important for rendering performance than the source resolution. Because of that I don't think "pixels-per-second" is a good metric. I could of course add support for multiplications, but that would cost quite a bit of time to implement, so I have to say "no" for the time being, because only few users would use that, and I've lots and lots of other things to do.

The whole point of this suggestion was to account for frame rate and resolution with one number. Using "pixels-per-second" 480p60 has 89% of the pixels-per-second of 720p30 so would probably use the same profile as 720p30. So each frame of a 480p60 clip takes 44.4% of the time to render compared to a 720p30 frame but there are twice as many frames. My testing has shown rendering time per pixel to be pretty static; with a constant output resolution the rendering time is proportional to input resolution.

As it is now I need two If statements for each resolution, one for 30p and one for 60p that points to the profile for the next resolution. No worry though, it is easy enough to copy the Ifs and just have lots of them. :)

[6233638]

I've never understood CR-AR-LL for downscaling. To my eyes, only softcubic, bilinear and NN look worse but it's all subjective.Linear light scaling is the only way to accurately represent the original image when downscaling.

When using linear light in madVR, only Catmull-Rom with the anti-ringing filter enabled avoids significant ringing around high contrast areas.

Even without linear light scaling enabled, all the other algorithms have a lot of aliasing and ringing when downscaling.

[leeperry]

It's hard to deny that CR AR LL truly provides stunning looking results when downscaling 64x NNEDI. The lower the source resolution, the more striking its gets.

HDTV channels should seriously start using mVR for their upscales because even arteHD(that very much seem to care about PQ) broadcast ugly upscales compared to what mVR can do.

[DragonQ]

I've never seen any real-time upscaling on HDTV other than basic bilinear. :(

[StinDaWg]

You should not use MPC's built-in sharpeners, because they are really bad.
Try Avisynth with ffdshow instead and you can have your profiles for sharpening plus sharpening with avisynth allows far more superior quality (just look at madshis images)
Like others have said, you can't use ffdshow raw post-resize. Unless madshi is able to incorporate one of these algorithms directly into madVR there is really no way to take advantage of these properly.

Linear light scaling is the only way to accurately represent the original image when downscaling.

When using linear light in madVR, only Catmull-Rom with the anti-ringing filter enabled avoids significant ringing around high contrast areas.

Even without linear light scaling enabled, all the other algorithms have a lot of aliasing and ringing when downscaling.
Can you provide some real world examples of this? I don't see it with Lanczos4 AR downsize, at least with 720p->1440p->1080p scaling.

[6233638]

Can you provide some real world examples of this? I don't see it with Lanczos4 AR downsize, at least with 720p->1440p->1080p scaling.There was quite a bit of discussion on downscaling here a while back if you read this post an a few further down the page: http://forum.doom9.org/showthread.php?p=1597447#post1597447
There is some general information on the problem of scaling in gamma-light here: http://www.4p8.com/eric.brasseur/gamma.html

And this is why I would only recommend using Catmull-Rom with anti-ringing enabled, if you plan on using Linear Light scaling: http://forum.doom9.org/showpost.php?p=1606829&postcount=16482
I would not recommend using any other algorithms due to this ringing.


Here is one of the images Nicolas recommended for testing: (https://upload.wikimedia.org/wikipedia/commons/8/85/Calliphora_sp_Portrait.jpg)

Lanczos 4 AR (http://abload.de/img/fly-l4arsljmq.jpg)
Catmull-Rom AR LL (http://abload.de/img/fly-crll9yjwb.jpg)
Mitchell-Netravali AR LL (http://abload.de/img/fly-mnllx1klu.jpg)


Mitchell Netravali actually seems to have less aliasing here, but Catmull-Rom is the best balance between aliasing, ringing, and sharpness when downscaling.
You can see that the eyes have lost their silvery color if you are not using linear light when downscaling.


Another image Nicolas recommended for testing: (http://www.mediafire.com/view/?uz8dphpj6q0y6n5#)

Lanczos 4 AR (http://abload.de/img/backpack-l4arfrkbm.jpg)
Catmull-Rom AR LL (http://abload.de/img/backpack-crlli8kir.jpg)

[StinDaWg]

Ya, I don't know. I can see the aliasing in the insect pic on Lanczos4 but it also looks sharper and more detailed, and CR still has aliasing its just not as defined. On the backpack pic they basically look the same other than I think the logo might be a bit sharper on Lanczos4 but it's really hard to tell. On the fireworks pic Lanczos looks sharper and CR looks softer, I'm not sure how that is supposed to actually show which method is better. If you want a sharper picture I'm assuming you already know you're going to get more ringing in exchange for that sharpness. CR has less artifacts but is also visibly softer. There is a trade off with both methods, and I'm not sure anyone can prove one way or another which is the correct way to go.

[turbojet]

I prefer Lanczos on the insect and especially the backpack, don't care about some zoomed in comparison, don't watch video like that.

While the insect's eyes has much more silvery stuff with LL then the source, which is not good, the other details are much closer to the original with lanczos. However the whole picture seems a bit darker with lanczos then it does with LL. I've never noticed that comparing originals to lanczos resized, is there something else going on there?

With the backpack, again lanczos is a little darker for some reason but the colors are much closer to the original. CR AR LL, the dark gray is now light gray and the other colors on the backpack are brighter then the source.

As for artifacts they're jpg files nothing really stands out to me from a normal viewing distance.

[Asmodian]

Wow, I am surprised we see things so differently. The LL samples look much more like the originals to me. I see the lanczos as much darker than the sources. In the backpack image without LL downscaling all the tiny white spots from the sun shining off the weave in the straps are pretty much gone. Switching between the two resized images it almost looks like a light is turned off or the backpack is in the shade without LL.

[turbojet]

I can't reproduce lanczos being darker then source here, but crarll is definitely lighter.

CR AR LL (http://someimage.com/tgxiRa1)
Lanczos 4 AR (http://someimage.com/eWK1uQI)

Look at the red and green curves on the eyes, they almost disappear with CR AR LL.

I couldn't play backpack original with madvr, it locks up both systems here, evr cp works fine.

I remember a few years ago someone asked if there was advantages of LL and madshi replied most people don't seem to like it.

[omarank]

@ Madshi: When playing a DCI video, I can see a colour cast in the image. Even when playing a Bluray video, if primaries are forced as DCI-P3 or "this display is calibrated to the following primaries/ gamut: DCI-P3" is selected, the colour cast can be seen in the image.
Forcing a Blu-Ray to DCI-P3 primaries must introduce a serious color cast because that's not how Blu-Rays are encoded. And setting your display "is calibrated to DCI-P3" must also introduce a serious color cast - unless that's really how your display is calibrated. However, if you have a real DCI-P3 video, switching the primaries to DCI-P3 should produce proper colors, I would think.


Yes I have a DCP sample, but the problem with playing the real DCI-P3 video is that LAV video decoder converts it from XYZ space to sRGB, which madVR receives as content with BT.709 primaries. In this case whether or not I force DCI-P3 primaries, colour cast is there.

So, in order to check whether madVR is doing the gamut conversion correctly, I used a 100% white pattern clip (BT.709) and forced the primaries as DCI-P3. If the gamut conversion is done correctly with white point matching, 100% white should appear the same for any primaries being forced.

As I mentioned earlier too, this problem is not there if I force BT.2020 primaries. BT.2020 comes with D65 white point so no white point matching is required and thus no colour cast is seen. Forget the larger gamuts, even if you force the primaries as SMPTE 470M (whitepoint C), a colour cast is seen. This happens due to the same reason that white point is not being matched correctly.



I think it's due to a shift in the white point, if there is no bug in madVR (this doesn't happen with BT.2020). So I was wondering if madVR could also do white point matching of the source with the display white point while performing gamut conversion so that DCI content can be viewed on regular monitors without any colour cast in the image.

The white point is taken into account somehow in the math I'm doing. But it's been a while since I looked into that, so I don't remember the details. Maybe something is wrong there. Maybe I would need more complicated math to properly change the white point. If you have a true DCI-P3 video which you know for a fact should look correct when played properly, and which looks incorrect in madVR with primaries set to DCI-P3, then please create a bug tracker entry. However, please don't do that if you're not sure yourself. I don't have the time to go guessing how the video should look. So it should be very clear and without any doubt how it should look, so I can really see if there's anything wrong, and if maybe a fixed madVR build corrects the problem.


I think I can check whether my DCI-P3 video sample plays correctly only if either LAV video decoder converts from XYZ space to DCI-P3 space, or it outputs XYZ content which madVR takes as input and the conversion to DCI-P3 happens in madVR. Presently, LAV video decoder uses a matrix for the conversion from XYZ space to sRGB, which apparently doesn't take white point in cosideration and that's why colours don't look correct.

From what I've read, the conversion from DCI-P3 XYZ to Rec709 RGB should be done using a LUT as this is not a simple colour space conversion. The LUT should take input as XYZ content encoded with gamma 2.6 with DCI white point and peak white at 48 cd/m2, and output Rec709 RGB encoded with gamma 2.2 with D65 white point and peak white at 120 cd/m2. IMHO such a conversion should be done in madVR. But before we get there, the gamut conversion in madVR should be corrected so that any ripped video with DCI-P3 RGB can be played without any colour cast.


BTW, does 3dlut take the source white point as input or it always assume the source white point to be D65?

You can select a separate 3dlut for every colorspace, including DCI-P3. Obviously madVR expects the 3dlut to have a white point matching the colorspace it was made for.


Please see the above point regarding the LUT input and output. I think if you are feeding DCI-P3 RGB to the 3dlut, either the 3dlut should assume a gamma of 2.6 and DCI white point with peak white at 48 cd/m2 or if it assumes the standard 2.2 gamma and D65 white point with peak white at 120 cd/m2, madVR should do the appropriate conversion before 3dlut processing.

[Asmodian]

I can't reproduce lanczos being darker then source here, but crarll is definitely lighter.

CR AR LL (http://someimage.com/tgxiRa1)
Lanczos 4 AR (http://someimage.com/eWK1uQI)

Look at the red and green curves on the eyes, they almost disappear with CR AR LL.

I couldn't play backpack original with madvr, it locks up both systems here, evr cp works fine.

I remember a few years ago someone asked if there was advantages of LL and madshi replied most people don't seem to like it.

Well again, not what I see. The red and green curves on the eyes look almost the same to me and without LL the shine has been de-emphasized compared to the original. Most people like oversharpened and over saturated colors too. :p

[6233638]

It shouldn't need saying, but I assume you are all comparing at 100% size, and not viewing an image scaled down by your browser.

Perhaps this will make the comparison easier:

Source (https://upload.wikimedia.org/wikipedia/commons/8/85/Calliphora_sp_Portrait.jpg)
Catmull-Rom with linear light scaling and anti-ringing (http://abload.de/img/crllsmkvs.png)
Lanczos 4 with anti-ringing (http://abload.de/img/l4arolklx.png)

Now which looks closer to the source?


Edit: Just noticed that my levels were set to 0-250 rather than 0-255 when doing these comparisons. Updated the images to fix this.
It shouldn't affect the other comparison, only this new one.

Catmull-Rom is not perfect, but sharper algorithms introduce a lot of aliasing and very bad ringing artifacts when used with linear light scaling, so you either use use Catmull-Rom with linear light or don't use linear light at all, in my opinion.

[StinDaWg]

Catmull-Rom is not perfect, but sharper algorithms introduce a lot of aliasing and very bad ringing artifacts when used with linear light scaling, so you either use use Catmull-Rom with linear light or don't use linear light at all, in my opinion.
I wasn't making the case for Lanczos4 AR with linear light, just saying I preferred Lanczos for down scaling in general. I don't see aliasing or ringing with video in motion, just a sharper more pleasing picture overall. Even when I pause the video I don't see aliasing on text. NNEDI 32 doubling completely takes care of that. It's easy to see the difference compared to Jinc upscaling, NNEDI is so much better in that regard. Diagonal lines are almost perfect.

[e-t172]

News from the frame drop extermination Task Force©®™ (http://forum.doom9.org/showthread.php?p=1675292#post1675292):

I did additional testing but this time using the integrated Intel IGP (HD 4600) on my Haswell Core i7 4770, for comparison with my test nVidia GPUs (770 and 780 Ti). The results are quite interesting:

I can reproduce the exact same issue on the Intel integrated GPU. Exact same symptoms: one lone frame drop happening at random times, every 30 minutes or so in average.
This indicates that the problem is not specific to nVidia GPUs or drivers. Considering that every other hardware and software component has been swapped/reinstalled, the only remaining constant across all tests is madVR itself.
However, XPerf results indicate that the GetRasterStatus() issue that I was investigating does *not* occur with the Intel GPU. This seems to indicate that this weird GetRasterStatus() behavior only happens with nVidia hardware. The fact that I still get frame drops on Intel despite this indicates that the two phenomena are likely unrelated.


During my latest rounds of testing I have been using GPUView (http://graphics.stanford.edu/~mdfisher/GPUView.html) (a tool related to XPerf but specialized in low-level GPU profiling) to try to get more information. On Intel neither XPerf nor GPUView were able to provide me with any "smoking gun" evidence of any abnormal behavior, even after dissecting the period of time where the drop happens. The GPU doesn't seem frozen or blocked in any way for any extended period of time, and neither does any madVR or player thread.

madshi: could you please take a look at this log (https://drive.google.com/file/d/0B4SHVPm2DfK5RVFrOFBlVFUyMWs/edit?usp=sharing)? It illustrates a frame drop using the Intel GPU as opposed to an nVidia one. Contrary to the last log you looked at, it doesn't contain any evidence of the rendering pipeline getting frozen (at least as far as I can see). The frame drop happens at timestamp 390193 in the log. I also have a GPUView trace for this particular run if you're interested, though it is difficult to accurately correlate the timestamps in the trace with those in the log (as I've already reported). The only weird thing I could find in the trace is that approximately ~0.5s before the drop, the kernel thread in charge of D3D hogs a CPU for ~8ms while processing one of the commands madVR sent (which from looking at the rest of the trace is unusual), which in turned delayed a Present() call, as it happened in the middle of the VSync interval instead of immediately after the VSync event. However, since all this happens long before the drop I am not sure it is relevant.

[mindbomb]

@e-t172
this is just a shot in the dark, but have you tried use separate device for presentation?

[e-t172]

Oh yes. Several times in a bunch of scenarios. In fact I tried one Intel GPU test with that option because IIRC it had some effect on Intel IGPs.

[Fadeout]

Does anyone knows how to fix vsynch issues?

I just installed everything from scratch, no weird configuration, just a 75hz LCD monitor.

Out of the box MadVR is BROKEN: everything's fine in windowed, but as I go fullscreen I get MASSIVE tearing AND hundred of dropped frames. I tried to fiddle with the options but nothing seems to affect this.

Any clue?

[Fadeout]

My mistake, I had Dxtory active and it interfered with the FPS problem.

But now I don't have frame dropped BUT exclusive mode still shows massive screen tearing even if it shows no glitches/dropped frames.

So how to fix screen tearing in exclusive mode (windowed is fine).

[turbojet]

Lanczos is still the closest to the source for me, it's no longer darker than the source now but LL is lighter then the source and that's the most major difference, second would be the eyes, curves, too much silver, etc. There are a few very minor things like the small silver dots on the black part of the left leg that are a little closer to the source with LL but that is something I certainly wouldn't notice at 24 fps.

Like I said it's all subjective and one person may like others may not. At 24fps LL is definitely noticeable to my eyes and there's some noticeable issues like the insect eyes (like light reflecting off glass) in faces and such whether I'm downscaling or upscaling and it's very distracting and not realistic. I've tried ResampleHQ and that also has the same issues.

[6233638]

I wasn't making the case for Lanczos4 AR with linear light, just saying I preferred Lanczos for down scaling in general.Yes, but do you now agree that linear light scaling is closer to the source material?

And if you do agree that linear light is better, I would avoid using Lanczos with it. Catmull-Rom is still sharp enough to exhibit some aliasing - which means it is already sharper than it ought to be.

I don't see aliasing or ringing with video in motion, just a sharper more pleasing picture overall.That's surprising, I find aliasing to be more obvious when things start moving.

Lanczos is still the closest to the source for me, it's no longer darker than the source now but LL is lighter then the source and that's the most major difference, second would be the eyes, curves, too much silver, etc. There are a few very minor things like the small silver dots on the black part of the left leg that are a little closer to the source with LL but that is something I certainly wouldn't notice at 24 fps.

Like I said it's all subjective and one person may like others may not. At 24fps LL is definitely noticeable to my eyes and there's some noticeable issues like the insect eyes (like light reflecting off glass) in faces and such whether I'm downscaling or upscaling and it's very distracting and not realistic. I've tried ResampleHQ and that also has the same issues.Did you view the updated comparison (http://forum.doom9.org/showpost.php?p=1675410&postcount=25428) I posted, at 100% size?
Ignore the fact that it's Lanczos and Catmull-Rom. Open all three images in browser tabs and switch between them, paying attention to the brightness of the image (particularly in the eyes) or the appearance of fine details.

It should be clear that linear light is required when downscaling to be an accurate representation of the source, no matter what scaling algorithm you choose.
Linear light is not brighter than the source, the issue is that downscaling without using linear light is making the image darker.


It just happens that Catmull-Rom+AR is the only scaling algorithm which avoids most of the artifacts that can be introduced when using the linear light option, while still keeping a sharp image.
Not as sharp as an image with the aliasing and ringing that Lanczos introduces, but still a sharp image.

Linear light will show the same differences with any scaling algorithm though - it does a much better job of keeping the appearance of the original image when downscaling.
You can use Lanczos 4 with it if you prefer, but there are some obvious (to me) artifacts introduced, which is why I don't recommend it.

exclusive mode still shows massive screen tearing even if it shows no glitches/dropped frames.

So how to fix screen tearing in exclusive mode (windowed is fine).Have you disabled Desktop Composition (Aero) or made a global change to your driver's V-Sync settings? (such as using adaptive v-sync)

[yok833]

Is it normal that when I apply lumasharpen several times in post or pre resize, there is no difference as if I had made it only once? I really would like to try this shader but I do not see any real difference (unlike of when I am using complex 2 or finesharp) so I am not sure to use it well...
However everything seems to be well configured (V 1.4.1) and I have also tried to rise the sharpening in the lumasharpen.hlsl file....
Maybe the sharpening is more light or subtle with this shader?



Envoyé de mon GT-I9300 en utilisant Tapatalk

[romulous]

Now which looks closer to the source?


Lanczos.

[The 8472]

@madshi would it be possible to blank/standby all other screens when madvr goes into FSE mode? For dark room viewing experience.

Or is that something the player should do?

[markanini]

Catmul-Rom Looks closer to the source here.

[6233638]

Lanczos.You're definitely viewing the images at 100% size in your browser?

Because the image without linear light (Lanczos) should be clearly darker than the source.

[cyberbeing]

You're definitely viewing the images at 100% size in your browser?

Maybe something cropped like this (http://i.imgbox.com/Jz4ZsOmC.png) comparing 50% vs 50% vs Original in the same image would help.

[romulous]

You're definitely viewing the images at 100% size in your browser?


Yup, certainly am.

[6233638]

Maybe something cropped like this (http://i.imgbox.com/Jz4ZsOmC.png) comparing 50% vs 50% vs Original in the same image would help.I had hoped it would be obvious enough in those images.

Perhaps this comparison makes it easier to see?
http://thumbnails110.imagebam.com/31767/e72827317663292.jpg (http://www.imagebam.com/image/e72827317663292)

It requires a browser that supports animated PNGs. (e.g. Firefox)
If you stand at a distance from your display, it should hopefully be quite noticeable that the gamma image is much darker than the source.

[StinDaWg]

I've tried Ordered Dithering, Error Diffusion 1 and 2, and I don't see any difference between the three. Is there something specific I'm supposed to be looking for? Is one better than the others for preventing banding? If not, I'll just use Ordered Dithering and save GPU power for something else.

[ryrynz]

I've tried Ordered Dithering, Error Diffusion 1 and 2, and I don't see any difference between the three. Is there something specific I'm supposed to be looking for? Is one better than the others for preventing banding? If not, I'll just use Ordered Dithering and save GPU power for something else.

Dithering doesn't prevent banding (use the deband function for that) If you can't see a difference then pick the one that's the least demanding.

[StinDaWg]

Dithering doesn't prevent banding (use the deband function for that) If you can't see a difference then pick the one that's the least demanding.
But am I supposed to? Do you?

I do use debanding, but I thought I remembered madshi saying dithering/noise helps prevent banding as well. I know if I turn dithering off, I get banding on the AVS test patterns.

[6233638]

Dithering will help prevent any banding due to things like the YCC to RGB conversion or other processing that madVR is doing.

It will not reduce any banding that is due to compression in the source - that's what debanding is for.

I use Ordered Dithering with the "use colored noise" and "change dither for every frame" options enabled.

Error diffusion is better, but I would be surprised if anyone noticed it at 8-bit. It's probably not worth the performance hit unless you have performance to spare.

[turbojet]

I see lanczos closer to the source at original size, 100% in chrome and firefox, windowed picture viewer, fullscreen picture viewer. It's not just me, I asked 4 others earlier today and they thought it was the closest on 3 different displays. I also see something still wrong with your new pics, lanczos is still darker then my image, cr still brighter and the pattern on the eyes isn't close to original or in my pics. The animated png is the same way.

[EncodedMango]

Lanczos here too.

[ryrynz]

Dithering will help prevent any banding due to things like the YCC to RGB conversion or other processing that madVR is doing.


Surely this is only really worth mentioning when dithering is off vs on but since it's recommended dithering never be disabled any discussion about the debanding properties of any of the dithering options (which while technically performing some debanding behavior) shouldn't really be used in a discussion about debanding at all.

I feel when anyone is discussing banding removal, the strength of that banding goes well beyond whatever minimal or near imperceptible conversion banding introduced in the rendering process.

[kasper93]

I had hoped it would be obvious enough in those images.

Because it is, at least on my calibrated monitor. Catmul-Rom AR LL looks better. Anyway no need to force it. Everyone can choose which algorithm they think is best for them :)

[ryrynz]

But am I supposed to? Do you?


I haven't updated my graphics so can't answer that, the difference would be minor but it's generally regarded as being better so I'd ideally want it enabled regardless.

You really have to have a trained eye to spot differences when looking at subjectively minor changes in dithering patterns.

[qduaty]

Have you just blocked the clReleaseMemObject() calls? Or did you do something else?I also replaced clCreateFromD3D9TextureNV() with a function that keeps existing instances in a map:
std::map<IDirect3DTexture9*, cl_mem>mappings;
and only calls the original clCreateFromD3D9TextureNV() if necessary.

[dansrfe]

Because it is, at least on my calibrated monitor. Catmul-Rom AR LL looks better. Anyway no need to force it. Everyone can choose whoever algorithm they think is best for them :)

I'm also in favor of CR-AR-LL. The difference is clear when I put them side by side on my monitor (calibrated with i1DP).

[kalston]

News from the frame drop extermination Task Force©®™ (http://forum.doom9.org/showthread.php?p=1675292#post1675292):

I did additional testing but this time using the integrated Intel IGP (HD 4600) on my Haswell Core i7 4770, for comparison with my test nVidia GPUs (770 and 780 Ti). The results are quite interesting:

I can reproduce the exact same issue on the Intel integrated GPU. Exact same symptoms: one lone frame drop happening at random times, every 30 minutes or so in average.
This indicates that the problem is not specific to nVidia GPUs or drivers. Considering that every other hardware and software component has been swapped/reinstalled, the only remaining constant across all tests is madVR itself.
However, XPerf results indicate that the GetRasterStatus() issue that I was investigating does *not* occur with the Intel GPU. This seems to indicate that this weird GetRasterStatus() behavior only happens with nVidia hardware. The fact that I still get frame drops on Intel despite this indicates that the two phenomena are likely unrelated.


During my latest rounds of testing I have been using GPUView (http://graphics.stanford.edu/~mdfisher/GPUView.html) (a tool related to XPerf but specialized in low-level GPU profiling) to try to get more information. On Intel neither XPerf nor GPUView were able to provide me with any "smoking gun" evidence of any abnormal behavior, even after dissecting the period of time where the drop happens. The GPU doesn't seem frozen or blocked in any way for any extended period of time, and neither does any madVR or player thread.

madshi: could you please take a look at this log (https://drive.google.com/file/d/0B4SHVPm2DfK5RVFrOFBlVFUyMWs/edit?usp=sharing)? It illustrates a frame drop using the Intel GPU as opposed to an nVidia one. Contrary to the last log you looked at, it doesn't contain any evidence of the rendering pipeline getting frozen (at least as far as I can see). The frame drop happens at timestamp 390193 in the log. I also have a GPUView trace for this particular run if you're interested, though it is difficult to accurately correlate the timestamps in the trace with those in the log (as I've already reported). The only weird thing I could find in the trace is that approximately ~0.5s before the drop, the kernel thread in charge of D3D hogs a CPU for ~8ms while processing one of the commands madVR sent (which from looking at the rest of the trace is unusual), which in turned delayed a Present() call, as it happened in the middle of the VSync interval instead of immediately after the VSync event. However, since all this happens long before the drop I am not sure it is relevant.

At this point I have to ask: are you getting this with a specific file(s) or just ANY file? Are you watching rips or full blu-rays/dvds?

This makes no sense to me because ever since I switched to a Kepler GPU I've never had to deal with glitches or drops/delays regardless of settings (although I'm sure I could abuse my hardware with crazy settings on high bit rate files but I have obviously never bothered to try that :p) The only times I have issues is with things I've downloaded. And even then it's not that common.

I'm not using default settings but there's nothing extraordinary about my settings either. I'm on win 7 64 as well (and always latest nvidia whql drivers). Only real difference I see is I'm not using smooth motion. Not really needed when my display supports all the refresh rates I need for video playback though.

And I'm really picky about that kind of thing. Yesterday while watching Excalibur blu-ray I noticed what looked like a frame drop, so I instantly checked madVR stats... nothing. I seeked back a few seconds to watch the scene again... and sure enough the "drop" was part of the film.

I can watch Apocalypse Now Redux (~3h40) edition without a single glitch, drop or delayed frame. I don't think I have any longer film than that but you get the point :p Not even using Reclock or JRiver VideoClock but 72.929 is close enough to 23.976x3 so it works fine (I can also have 72.00 or 75.00 for 24fps/25fps content etc).

[yok833]

I also replaced clCreateFromD3D9TextureNV() with a function that keeps existing instances in a map:
std::map<IDirect3DTexture9*, cl_mem>mappings;
and only calls the original clCreateFromD3D9TextureNV() if necessary.

Sounds good :) maybe a fix soon for NVIDIA users ?

Envoyé de mon GT-I9300 en utilisant Tapatalk

[madshi]

I have a 60hz Panasonic plasma. When using 24p content at 60hz there is a lot of ghosting with smooth motion on. There is some judder normally, but with smooth motion turned on everything just has a weird look to it.
Ok. As I said, it might have to do with the display technology. It's also possible that the way smooth motion FRC works is bad for the eyes/brain of some people while it works good for others. In the end, all I can say is that it's working great on my displays for my eyes/brain. If it doesn't work for you, that's sad, could be your display or could be your eyes/brain just doesn't like frame blending. Can't say for sure...

Yes, I am always using the madVR defaults. Reading your reaction I think you didn't notice that this is the same problem as the one I reported days ago, for which I already provided logs.
Ah, yes, I remember now...

What is the status on 0000158: Green image when NNEDI3 chroma scaling is used with video deintelacing (http://bugs.madshi.net/view.php?id=158)? It's been quite a few releases now, and it's still marked as new.
"new" means I haven't looked into it yet.

I can confirm this 'cosmetic' change in behavior, and would somewhat agree that having a frozen frame is a bit more visually pleasing for these graph stop/start events required for switching embedded subtitles at the splitter level.

madVR 0.87.4 = brief frozen video frame when switching subtitle tracks
madVR 0.87.5-0.87.7 = brief frozen black frame when switching subtitle tracks

It's not a exclusive -> windowed switch. It occurs even in windowed mode without any subtitle renderer. Whatever the case, going from 'frozen video frame' to 'frozen black frame' when these graph restarts occur, seem to be a side-effect of some change you made in 0.87.5+
That's probably the "show black screen when playback is stopped" change. Seems that the VSFilter type subtitle renderers stop the graph when the user changes the subtitle tracks. I'm not sure if there's anything I can do about that without removing the "show black screen when playback is stopped" feature - which I think is useful. But I'll see if I can detect the situation somehow...

I use NNEDI for chroma upscaling. I almost only watch 1080p content. So, in theory, should I still benefit from MadVR's high quality RGB output even if an external processor later on in the chain converts to YcBcR color space?
If it's YCbCr 4:4:4 then I'd say yes. If it's only 4:2:2 then probably the benefit of using NNEDI for chroma upscaling is mostly lost. Probably using a simpler/faster algorithm would produce similar image quality in this situation. Whether madVR overall still produces better image quality compared to other playback solutions I can't say, that's up for your eyes to judge.

The artifacts on high contrast edges, due to very strong sharpening, in the presize pic make this comparison convincing. My criticism with post resize sharpening is it doesn't have much effect even with really strong sharpening for some odd reason. Here's a comparison with the original castle pic. NNEDI3 doubled to 800x600 then upscaled to 1080p with lanczos4ar, lumasharpen 1.0 strength, pattern 3, clamp 0.5.

pre resize (http://someimage.com/CmPwxUj)
post resize (http://someimage.com/o2jmqKt)
pre and post resize (http://someimage.com/speT3um)

Max strength, 3.0, with post resize (http://someimage.com/s9MDEaB) doesn't have much more effect but it's unbearable watching anything with this and preresize. (http://someimage.com/mKKw309)

Also my focus is on lower contrast edges, like faces, preresize has a great effect on this while postresize has very little, it mostly effects high contrast edges.
To be honest, I don't like your "pre resize" images. They have the typical digital "sharpened" look with strong EE, IMHO.

The whole point of this suggestion was to account for frame rate and resolution with one number. Using "pixels-per-second" 480p60 has 89% of the pixels-per-second of 720p30 so would probably use the same profile as 720p30. So each frame of a 480p60 clip takes 44.4% of the time to render compared to a 720p30 frame but there are twice as many frames. My testing has shown rendering time per pixel to be pretty static; with a constant output resolution the rendering time is proportional to input resolution.
I would have to do tests on my own to make sure (and I don't have the time for that), but I strongly doubt that the rendering times would be proportional to input resolution. But it also depends on which exact algorithms you're running.

Yes I have a DCP sample, but the problem with playing the real DCI-P3 video is that LAV video decoder converts it from XYZ space to sRGB, which madVR receives as content with BT.709 primaries. In this case whether or not I force DCI-P3 primaries, colour cast is there.
Ouch, I don't like that!! @nevcairiel, you there? Why is LAV doing that? FWIW, madVR interprets VIDEOINFOHEADER2 primary index 9 as BT.2020 and index 10 as DCI-P3. So there's really no reason to convert the gamut when sending data to madVR.

So, in order to check whether madVR is doing the gamut conversion correctly, I used a 100% white pattern clip (BT.709) and forced the primaries as DCI-P3. If the gamut conversion is done correctly with white point matching, 100% white should appear the same for any primaries being forced.
I'm confused. If the white point is different and DCI-P3 is encoded with R=235, G=235, B=235, then after gamut conversion to BT.709, the data can't be 235/235/235, anymore, or am I wrong?

From what I've read, the conversion from DCI-P3 XYZ to Rec709 RGB should be done using a LUT as this is not a simple colour space conversion. The LUT should take input as XYZ content encoded with gamma 2.6 with DCI white point and peak white at 48 cd/m2, and output Rec709 RGB encoded with gamma 2.2 with D65 white point and peak white at 120 cd/m2.
Is that so? Where did you read that? I'm not really an expert on this, and I'm getting headaches every time I work on this stuff...

But now I don't have frame dropped BUT exclusive mode still shows massive screen tearing even if it shows no glitches/dropped frames.

So how to fix screen tearing in exclusive mode (windowed is fine).
Have you disabled Desktop Composition (Aero) or made a global change to your driver's V-Sync settings? (such as using adaptive v-sync)
^

Usually exclusive mode is always tearing free - unless you've changed some GPU control panel VSync options?

@madshi would it be possible to blank/standby all other screens when madvr goes into FSE mode? For dark room viewing experience.

Or is that something the player should do?
I'm not sure if it's something madVR or the media player should do. In any case, I'm not accepting feature requests until madVR has reached v1.0.

I've tried Ordered Dithering, Error Diffusion 1 and 2, and I don't see any difference between the three. Is there something specific I'm supposed to be looking for? Is one better than the others for preventing banding? If not, I'll just use Ordered Dithering and save GPU power for something else.
I'm not seeing a difference myself at 8bit. You can try lowering the bitdepth to 4bit in the madVR display setup, then you should see a difference. Some people do see a difference, though. In theory at least error diffusion should provide the best quality, but it also costs extra performance. Probably the default setup is "good enough" for the majority of users.

madshi: could you please take a look at this log (https://drive.google.com/file/d/0B4SHVPm2DfK5RVFrOFBlVFUyMWs/edit?usp=sharing)? It illustrates a frame drop using the Intel GPU as opposed to an nVidia one. Contrary to the last log you looked at, it doesn't contain any evidence of the rendering pipeline getting frozen (at least as far as I can see). The frame drop happens at timestamp 390193 in the log.
Hmmmm... Thanks for the log. This looks like it could actually be a bug in madVR. On a quick check it looks like it's dropping a frame because it thinks there's no room for it, but it looks like it's a wrong decision and there is room after all. But I'm not 100% sure right now. Interpreting the logs can be quite difficult. I'll have a deeper look at this when I find some time...

I also replaced clCreateFromD3D9TextureNV() with a function that keeps existing instances in a map:
std::map<IDirect3DTexture9*, cl_mem>mappings;
and only calls the original clCreateFromD3D9TextureNV() if necessary.
Hmmmm... I had tried that, but it didn't work. But I've now tried again and it *does* work. The reason it didn't work before was that madVR decided to render on the Intel GPU instead of the NVidia GPU on my development PC, although the display was connected to the NVidia GPU. This problem seems to be caused by the Intel driver claiming to support rendering on the output port although it shouldn't. But that's a different issue. After forcing madVR to use the NVidia GPU, using your workaround does work. Interestingly, I only need to prevent the deletion of the interop images for the output texture. I can delete the interop images for the input texture. Furthermore I can also delete the output interop images if I do it before rendering the next image (meaning: with a delay). It seems that the driver claims to be done with the rendering+interop (I'm calling clFinish() and only afterwards I delete the interop images), but it's not really finished at all. Looks like a clear driver bug to me. In any case, this should be easy enough to work around (needs some work to do it cleanly, though), now that I know what the problem is.

Thanks a lot for investigating this. And that without having my source code, great job!! :)

[e-t172]

At this point I have to ask: are you getting this with a specific file(s) or just ANY file? Are you watching rips or full blu-rays/dvds?

I've tried different files and they are all from very high-quality sources (such as original Blu-rays). Besides, if it came from the file it is likely the drop would always happen at the same position. It doesn't.

This makes no sense to me because ever since I switched to a Kepler GPU I've never had to deal with glitches or drops/delays regardless of settings

As I said before, some hardware/software/settings combinations seem fine. Personally I am able to reproduce this on 4 different PCs. My working theory is that this a very subtle, probably timing-related madVR bug that affects everyone but doesn't actually result in frame drops for some people because their combinations are the "lucky" ones.

I'm not using smooth motion.

I suspect that not using smooth motion would make the issue disappear or happen very rarely because there are much more opportunities for a subtle timing bug to manifest itself at 60 i/s as opposed to 24 i/s.

And I'm really picky about that kind of thing. Yesterday while watching Excalibur blu-ray I noticed what looked like a frame drop, so I instantly checked madVR stats... nothing. I seeked back a few seconds to watch the scene again... and sure enough the "drop" was part of the film.

I follow a rigorous testing protocol. All my results are based on the madVR dropped frames counter, not from watching the video.

Hmmmm... Thanks for the log. This looks like it could actually be a bug in madVR. On a quick check it looks like it's dropping a frame because it thinks there's no room for it, but it looks like it's a wrong decision and there is room after all. But I'm not 100% sure right now. Interpreting the logs can be quite difficult. I'll have a deeper look at this when I find some time...

Thank you. Quite frankly, I've been doing tests for days on multiple hardware and software platforms and "bug in madVR" is the only reasonable explanation I can come up with. Problems with hardware or the OS have been ruled out so many times I lost count.

I came to the same conclusion as you while examining the log (with my limited understanding of it) - it looks like madVR just decides to drop a frame for no reason, while the underlying hardware is doing just fine.

Some aspects of the GPUView traces make me wonder if this could be caused by some unintended lock contention in madVR that blocks some critical presentation thread for some extended period of time while another madVR or player thread is sitting on the lock for no good reason. This would explain why the issue happens at random times and seems timing-related. It's just a hunch though.

I'm going to open a bug report on the tracker, it will be easier to follow the discussion there.