madVR - high quality video renderer (GPU assisted)

[clsid]

Originally Posted by kstuart

What does madVR do when the "movie resolution" is close to the "target resolution", e.g. 1916 x 1076 and 1920 x 1080, due to cropping ?

Does it still do luma upscaling as if it were a big change like 720p to 1080p ?

Is there a way to have it not bother, i.e. just output black bars for the 4 pixels ?

I think this is a valid suggestion.

madVR should of course still respect the size requested by the player. Doing padding instead of resizing could be beneficial for quality (and performance). It could be a "Trade quality for performance" option to do padding when size difference is <16 pixels in both dimensions.

[DarkSpace]

Originally Posted by clsid

madVR should of course still respect the size requested by the player. Doing padding instead of resizing could be beneficial for quality (and performance). It could be a "Trade quality for performance" option to do padding when size difference is <16 pixels in both dimensions.

What if you want to zoom into the picture by a bit (e.g. pressing NUMPAD-6 in MPC-HC) and that happens to fall into these 16 pixels? I foresee complications...

[madshi]

Originally Posted by drew_afx

setting native display bitdepth to 6bit in madvr results in cleaner gradient (less banding artifacts) than setting it to 8bit!
e-ips is 6bit native yet I thought the monitor would handle 8 bit madvr output with its own dithering method

I think the same may happen some time in the future (probably not soon) when madVR gets native 10bit output: With some displays it will look worse than letting madVR dither down to 8bit. So basically every user will have to test which produces the better overall quality.

Originally Posted by Matching_Mole

Yesterday evening, I watched an upscaled DVD to 720p48hz (old projector) using Jinc 3 AR either for Luma and Chroma.

NL6 made video noise really stronger and so less pleasant that DC3 ED version that I used previously. However NL1 was far much better than DC3 (and so NL6) because the video noise was not increased but the picture looked sharper. So I vote personally for NL1 at least in case of DVD upscale.

I will check this result using a blu-ray.

Thanks, appreciated.

Originally Posted by clsid

I think this is a valid suggestion.

madVR should of course still respect the size requested by the player. Doing padding instead of resizing could be beneficial for quality (and performance). It could be a "Trade quality for performance" option to do padding when size difference is <16 pixels in both dimensions.

I haven't said this yet, but I did already plan to support something like this in a future version, together with some other related changes.

Originally Posted by 6233638

I've not had the time spare to do proper testing lately.

Would still like to hear your feedback. If you don't have time to test all the builds, at least I'd love to hear your opinion about how nl1 and nl6 compare, because those are the 2 builds mentioned most often by other users.

[clsid]

Originally Posted by DarkSpace

What if you want to zoom into the picture by a bit (e.g. pressing NUMPAD-6 in MPC-HC) and that happens to fall into these 16 pixels? I foresee complications...

It will work just fine. The size of the video surface will be exactly the same, it is just filled differently.

I haven't said this yet, but I did already plan to support something like this in a future version, together with some other related changes.

Cool.

[trip_let]

Originally Posted by drew_afx

Looks like I've been setting up my display wrong the entire time...
setting native display bitdepth to 6bit in madvr results in cleaner gradient (less banding artifacts) than setting it to 8bit!
e-ips is 6bit native yet I thought the monitor would handle 8 bit madvr output with its own dithering method

Looks like if you set 6 bits, madVR dithers down to 6 bits, which should make gradients better at the expense of definitely noticeable extra noise. Just because banding is lower doesn't mean overall quality is better.

Maybe setting 7 bits is a good compromise? In any case, it might be worth a try as well for those on 6 bits + AFRC displays. At least, try all the options.

edit: I tried it and setting 6 bits and 7 bits looks worse at least on the display I used. There's just too much difference between the pixels. Maybe the more appropriate solution would be dithering with even higher noise, allowing values like 10.4 -> 12 sometimes? I don't know if that's of much interest in general.

[Shiandow]

Originally Posted by Ver Greeneyes

I believe using a setting other than 8-bit also disables error diffusion (you'll get random dithering instead), so that's something to keep in mind. It would be nice if ED worked for 6-bit as well considering that should benefit even more.. I can't remember if madshi has said whether it would be feasible to offer 6-bit and 7-bit versions of ED.

FWIW since it is now impossible for error diffusion to round something like 127.81 to 129 it should be possible to achieve this by simply dividing all pixel values by 2 or 4. As far as I know error diffusion uses pure power gamma correction which would mean that relative distances are still correct.

Edit: After thinking about it you may need to divide by a value slightly larger than 2 or 4 to completely prevent 'out of range' values like 128 or 64 but it should still be quite easy to do error diffusion for 6 and 7 bits.

[MistahBonzai]

Originally Posted by Matching_Mole

...NL6 made video noise really stronger and so less pleasant that DC3 ED version that I used previously. However NL1 was far much better than DC3 (and so NL6) because the video noise was not increased but the picture looked sharper...

I had settled on NL6 while viewing a HBR monochrome 720p video shot with a "RED M".

All AVIsynth off. MadVR at default settings except Chrome Upscaling=Jinc 3 tap, Image Upscaling=Jinc 3 tap.

Play video full screen (with NL1 and NL6) and navigate to frame 1420 of each. Full screen capture (Alt+Printscreen). Open in editor, 200% zoom and cropped the upper left corners (1920-1440, 0-405). Performed this twice to insure conformity of process.

What I discovered was that NL6 is noticeably sharper while NL1 provides 'smoother' dithering. See attachments (hopefully). edit: Darn..second capture runs 225KB. Using smaller crop.

nl1a-frame1420
nl6a-frame1420

[iSunrise]

@MistahBonzai
Just FYI, attaching something to this forum does take a really long time to get approval, so even the people in say usually recommend to use an external image host.

[madshi]

Originally Posted by Shiandow

FWIW since it is now impossible for error diffusion to round something like 127.81 to 129 it should be possible to achieve this by simply dividing all pixel values by 2 or 4. As far as I know error diffusion uses pure power gamma correction which would mean that relative distances are still correct.

Edit: After thinking about it you may need to divide by a value slightly larger than 2 or 4 to completely prevent 'out of range' values like 128 or 64 but it should still be quite easy to do error diffusion for 6 and 7 bits.

The problem is that with 6bit or 7bit panels I'm not sure where the exact "border" is when a pixel is displayed as different. E.g. for 6bit should I output 8bit values 0, 4, 8? Or should I output 2, 6, 10? And is this identical over the whole gamma range? I'm not really sure about all this, that's why I'm currently simply using random dithering instead of error diffusion if the user selects 6bit or 7bit.

Originally Posted by MistahBonzai

I had settled on NL6 while viewing a HBR monochrome 720p video shot with a "RED M".

All AVIsynth off. MadVR at default settings except Chrome Upscaling=Jinc 3 tap, Image Upscaling=Jinc 3 tap.

Play video full screen (with NL1 and NL6) and navigate to frame 1420 of each. Full screen capture (Alt+Printscreen). Open in editor, 200% zoom and cropped the upper left corners (1920-1440, 0-405). Performed this twice to insure conformity of process.

What I discovered was that NL6 is noticeably sharper while NL1 provides 'smoother' dithering. See attachments (hopefully). edit: Darn..second capture runs 225KB. Using smaller crop.

Hmmm... Did you try the other test builds, too? Or just NL1 and NL6? Thanks...

[MistahBonzai]

Originally Posted by madshi

Hmmm... Did you try the other test builds, too? Or just NL1 and NL6? Thanks...

Commencing to do so..

[kstuart]

As always, all input is appreciated.

Originally Posted by madshi

As the other users have already said, madVR does what the media player tells it to do. madVR reports to the media player which resolution the video has and the media player tell madVR which target resolution to use.

It would be helpful if someone (not a developer, since they have better uses of their time) creates a flow chart of exactly which piece of software and hardware asks for which piece of information.

(I certainly understand that it is a kludge based on what giant corporations have decided they are willing to do.)

Between the monitor, the GPU, the GPU driver, GPU software package, other Windows drivers & APIs, media player, video filters, audio filters, video renderer, you really need a pre-existing "scorecard" to know what asks for what (and that is without extra complications like Reclock).

If a 1280x720 video is upscaled to 1920x1080 then your media player is *NOT* set to 100% zoom. With 100% zoom 1280x720 video would play letterboxed in 1280x720 resolution in the middle of your 1920x1080 screen.

Actually, if I play a 1280x720 video and then click on the "100%" setting, it does just that.
It turns out that Jriver has a bug whereby it displays a checkmark next to "100%" when "Fit Window" is also checked, so a casual glance indicates that the former is in effect, when it is actually the latter.
But, actually, I don't want to manually set it to "100%" only for these corner cases, so it is a moot point. (In fact, manually checking each file with MediaInfo before playing, and then manually changing settings during playback, is contrary to the whole point of profiles - and software in general - which is to automate complex tasks.)

Originally Posted by clsid

Doing padding instead of resizing could be beneficial for quality (and performance). It could be a "Trade quality for performance" option to do padding when size difference is <16 pixels in both dimensions.

Originally Posted by madshi

I haven't said this yet, but I did already plan to support something like this in a future version, together with some other related changes.

That would be appreciated, and I can use my workaround in the meantime.

[bacondither]

I used the 16-bit "gradient-perceptual.mkv" at the specific frame of "59, 29.970" and clipped the histogram at 4.
A random dither and a non dither version is included as comparison.

nl? testbuilds

The blurred version is blurred by paint.net, gaussian blur, radius 2.

nl? testbuilds blurred

I vote for NL6.

[huhn]

It would be helpful if someone (not a developer, since they have better uses of their time) creates a flow chart of exactly which piece of software and hardware asks for which piece of information.

think like this change with decoder not all decoder giving all informations and dxva runs on gpu like other decoder. render types overlay fullscreen exclusive, adding deinterlacing change a lot too. thinigs change with content codecs and a lot more... and this is a very very short list.

just take things as they are or you have to read a lot...

[Shiandow]

Originally Posted by madshi

The problem is that with 6bit or 7bit panels I'm not sure where the exact "border" is when a pixel is displayed as different. E.g. for 6bit should I output 8bit values 0, 4, 8? Or should I output 2, 6, 10? And is this identical over the whole gamma range? I'm not really sure about all this, that's why I'm currently simply using random dithering instead of error diffusion if the user selects 6bit or 7bit.

Intuitively you'd think that at the very least 0 should still correspond to black and just use increments of 4, which suggests that MadVR should output values of 0,4,8 over the whole gamma range. But I can't figure out how it would then handle values above 252. In the worst case each channel has a separate list of possible levels and these differ per manufacturer.

I think it's worth a try to see if dividing all values by 4, performing error dithering, and then multiplying all values by 4, improves the image for people with 6-bit panels.

[DarkSpace]

Originally Posted by bacondither

I used the 16-bit "gradient-perceptual.mkv" at the specific frame of "59, 29.970" and clipped the histogram at 4.
A random dither and a non dither version is included as comparison.

nl? testbuilds

The blurred version is blurred by paint.net, gaussian blur, radius 2.

nl? testbuilds blurred

I vote for NL6.

I did some tests today, but those tests were far from extensive. As such I was a bit hesitant about giving my vote (my screen isn't calibrated and such either), but thanks to your more extensive tests, I now believe it is justified if I also vote for NL6 as the medium-noise algorithm. Thank you!

P.S. Just to clarify: Before, I would also have chosen NL6, I just wasn't too certain if it was objective enough.

[leeperry]

Now the big question is whether madshi could work his magic once again and improve on NL6 to infinity...and beyond!

I'm getting kinda hooked to my pretty much daily "free lunch" drastic PQ improvement

[Shiandow]

By the way I was wondering, in the random number generator:

Originally Posted by madshi

float random(inout uint randomHelper)
{
  randomHelper = 18000 * (randomHelper & 0xffff) + (randomHelper >> 16);
  return ((float) (randomHelper & 0xffff)) / 65535.0f;
}

Shouldn't you divide by 65536.0f instead of 65535.0f? I don't think it will change the outcome much but dividing by 65536.0f doesn't cause rounding errors and as far as I know the convention is to generate random numbers strictly less than 1.

The random number generator I wrote has the same 'bug' by the way, I divided by 2147450880.0f (0x7fff8000) which should be 2147483648.0f (0x80000000).

[The 8472]

Originally Posted by Shiandow

Intuitively you'd think that at the very least 0 should still correspond to black and just use increments of 4, which suggests that MadVR should output values of 0,4,8 over the whole gamma range. But I can't figure out how it would then handle values above 252. In the worst case each channel has a separate list of possible levels and these differ per manufacturer.

I think it's worth a try to see if dividing all values by 4, performing error dithering, and then multiplying all values by 4, improves the image for people with 6-bit panels.

I think the only correct answer is to measure it. Worst case is that they always FRC on all colors, no matter which you pick.

[kstuart]

* added IMadVRSettings2 interface to enumerate settings and manage profiles
* settings can now be edited without madVR running (only on local PC)

Any more information on how to do this (edit of settings) ? Edit of madVR settings on Jriver in exclusive mode is a bit of a pain.

Thanks !

[MistahBonzai]

Originally Posted by MistahBonzai

I had settled on NL6 while viewing a HBR monochrome 720p video shot with a "RED M".

All AVIsynth off. MadVR at default settings except Chrome Upscaling=Jinc 3 tap, Image Upscaling=Jinc 3 tap.

Play video full screen (with NL1 and NL6) and navigate to frame 1420 of each. Full screen capture (Alt+Printscreen). Open in editor, 200% zoom and cropped the upper left corners (1920-1440, 0-405). Performed this twice to insure conformity of process.

What I discovered was that NL6 is noticeably sharper while NL1 provides 'smoother' dithering. See attachments (hopefully). edit: Darn..second capture runs 225KB. Using smaller crop.

nl1a-frame1420
nl6a-frame1420

I'm very sorry to have posted invalid test results. Please disregard the comparison between NL1a and NL6a. No idea what I did but the results after testing NL1 through NL8 didn't agree with that of the previous tests.

The odd thing was that I performed the tests twice - once cropping a 480*405 of each of the 2 and again with 282*405 and both exhibited the same size and sharpness differences.

What appears to have happened is that avisynth in ffdshow raw was activated. but I can't believe it did so 2x during the tests.

After performing the retest I discovered that avisynth was active..so I suspect all the retest was done with avisynth active. However I see the file sizes (and appearances) are a far better match than the 1st 2 images (NL1a and NL6a).

Once again my sincere apologize.