madVR - high quality video renderer (GPU assisted)

[Arm3nian]

When quadrupling chroma and luma with nnedi3, is it first best to max out neurons in doubling, and then increase quadrupling, or keep them equal? My guess is the first option.

[aufkrawall]

Doubling is more important, so use higher neuron count first.
You could also check if you really see an improvement compared to NNEDI3 doubling + super-xbr for quadruple.

[Arm3nian]

Doubling is more important

Quadrupling would double the already doubled image, so that makes sense to make the thing that is going to be doubled better quality.

You could also check if you really see an improvement compared to NNEDI3 doubling + super-xbr for quadruple.
super-xbr looks more pixelated.

[Sorrigotti]

Razoola and QBhd, tested what you suggested me but it did not work ...
I tried changing the settings.bin of properties, bin and allow full control according to the image and it worked for MPC-HC but for the KODI not ....
I do not know if it can be something of Windows 10 ...
Thank you for your help! :D

http://i.imgur.com/DYSdngN.jpg

[Asmodian]

I tried changing the settings.bin of properties, bin and allow full control according to the image and it worked for MPC-HC but for the KODI not ....
I do not know if it can be something of Windows 10 ...

I think I know what is happening to you.

KODI keeps its own madVR settings for some reason (can you turn this off?). These settings are written to madVR's settings every time you use madVR in KODI, maybe every time you open KODI. :p

You cannot solve this with madVR, you need to set the settings in KODI. If those settings do not save, you need to ask in the KODI forums. :)

[Sorrigotti]

I think I know what is happening to you.

KODI keeps its own madVR settings for some reason (can you turn this off?). These settings are written to madVR's settings every time you use madVR in KODI, maybe every time you open KODI. :p

You cannot solve this with madVR, you need to set the settings in KODI. If those settings do not save, you need to ask in the KODI forums. :)

Asmodian, I'm trying to address this issue now in the forum KODI.
Thank you so much for your help ! :)

[Warner306]

I think I know what is happening to you.

KODI keeps its own madVR settings for some reason (can you turn this off?). These settings are written to madVR's settings every time you use madVR in KODI, maybe every time you open KODI. :p

You cannot solve this with madVR, you need to set the settings in KODI. If those settings do not save, you need to ask in the KODI forums. :)

The post on the previous page describes this issue. madVR has a dummy profile because of the option you have selected in DSPlayer.

You have three options when using Kodi DSPlayer (only two are important):

Video -> DSPlayer -> - Manage settings with Kodi

Never: The Kodi madVR GUI is disabled and all madVR settings are loaded exclusively from the madVR control panel.

Load and Save with DSPlayer database: Enabling this option allows basic configuration of madVR from within Kodi. These settings are accessed during video playback by selecting Video Settings. Video settings are set on a per video basis but can be saved as a global profile for all videos. DSPlayer will create its own DSPlayer Profile Group in the madVR control panel when this setting is enabled. This is a dummy profile intended to separate DSPlayer settings from existing madVR profiles. This dummy profile is not meant for external configuration. Internal settings tables are saved by Kodi – no settings are saved in the madVR control panel.

Load from madVR active profile: Upon playback, the appropriate profile is loaded from madVR for the selected video. Changes made from within Kodi will change the same value in the madVR control panel. No dummy profile is created. These changes only impact the active madVR profile and profile rules cannot be created or saved. This is the best choice for those who have set-up profiles in madVR. Any changes made to the active profile are saved externally by madVR. External settings are always loaded in place of internal Kodi tables.

[SweetLow]

to madshi:
1. How to configure profile rules:
...
fps, deintFps, _bits_ - source frame rate, framerate after deinterlacing, bitdepth
...

"bits" is not worked, worked "srcbits" (and "bitdepth" too, no difference in my testing - both actually reflect bitdepth of stream on madVR input, actually no true _source_ bitdepth in case of "srcbits") so maybe you change help?

2. can i ask new string variable like "device" or "targetDevice" - the name of current rendering device taked from "devices->device name:" field of config?

[Razoola]

@sorrigotti, listen to what Warner306 and Asmodian have just told you and change the kodi setting to either 'Never' or 'Load from madVR active profile', I suggest this 2nd option for you.

That is the cause of your issue 100% given you said the suggestions worked for MPC-HC.

[markanini]

Quadrupling would double the already doubled image, so that makes sense to make the thing that is going to be doubled better quality.

super-xbr looks more pixelated.

I'm more bothered by the slight increase in haloing. This is a problem with only a small subset of my videos. Have you tried a lower sharpness value for super-xbr though?

[Sorrigotti]

The post on the previous page describes this issue. madVR has a dummy profile because of the option you have selected in DSPlayer.

You have three options when using Kodi DSPlayer (only two are important):

Video -> DSPlayer -> - Manage settings with Kodi

Never: The Kodi madVR GUI is disabled and all madVR settings are loaded exclusively from the madVR control panel.

Load and Save with DSPlayer database: Enabling this option allows basic configuration of madVR from within Kodi. These settings are accessed during video playback by selecting Video Settings. Video settings are set on a per video basis but can be saved as a global profile for all videos. DSPlayer will create its own DSPlayer Profile Group in the madVR control panel when this setting is enabled. This is a dummy profile intended to separate DSPlayer settings from existing madVR profiles. This dummy profile is not meant for external configuration. Internal settings tables are saved by Kodi – no settings are saved in the madVR control panel.

Load from madVR active profile: Upon playback, the appropriate profile is loaded from madVR for the selected video. Changes made from within Kodi will change the same value in the madVR control panel. No dummy profile is created. These changes only impact the active madVR profile and profile rules cannot be created or saved. This is the best choice for those who have set-up profiles in madVR. Any changes made to the active profile are saved externally by madVR. External settings are always loaded in place of internal Kodi tables.

@sorrigotti, listen to what Warner306 and Asmodian have just told you and change the kodi setting to either 'Never' or 'Load from madVR active profile', I suggest this 2nd option for you.

That is the cause of your issue 100% given you said the suggestions worked for MPC-HC.


Warner 306, Razoola and Asmodian thanks for the help!

Problem solved.

I discovered yesterday morning in the forum XBMC BRAZIL that could change the configs of madVR via KODI interface.

I came here to be able to explain how and now saw the post Warner306 detailing the same procedure.

Once again I thank the attention and elp of all!

thank you. :)

[XMonarchY]

Could someone please remind me which DXVA setting I should use in LAV Video? Copy-Back? I used to use CUVID until I found out it can cause problems and errors...

[huhn]

copyback or none.

[Warner306]

Can anyone comment on the usefulness of 10-bit output with current content? I have a 10-bit display but no 10-bit sources.

I am finding this topic confusing and would like some clarification. I am told the remapping of an 8-bit source to 10-bits will lead to an inaccurate color gamut and no gain in image quality.

[Asmodian]

Can anyone comment on the usefulness of 10-bit output with current content? I have a 10-bit display but no 10-bit sources.

I am finding this topic confusing and would like some clarification. I am told the remapping of an 8-bit source to 10-bits will lead to an inaccurate color gamut and no gain in image quality.

On a normal display (contrast < 5000:1) using a normal gamut (BT.709, BT.601, etc.) 10-bit offers basically no visual improvement over dithered 8-bit. Even displays with higher contrast or using wider gamuts will not benefit significantly. Lower dither noise is the benefit from going to 10-bit.

8 or 10-bit has nothing to do with the accuracy of the color gamut. The color gamut is calculated in 16-bit and dithered to 8 or 10 bit at a final output step. Actually more accuracy is lost going to 8-bit but this difference is extremely minor and not even measurable due to the dithering.

If I did have a 10-bit display I would still use 8-bit output because I like using overlay more than FSE.

[Warner306]

On a normal display (contrast < 5000:1) using a normal gamut (BT.709, BT.601, etc.) 10-bit offers basically no visual improvement over dithered 8-bit. Even displays with higher contrast or using wider gamuts will not benefit significantly. Lower dither noise is the benefit from going to 10-bit.

8 or 10-bit has nothing to do with the accuracy of the color gamut. The color gamut is calculated in 16-bit and dithered to 8 or 10 bit at a final output step. Actually more accuracy is lost going to 8-bit but this difference is extremely minor and not even measurable due to the dithering.

If I did have a 10-bit display I would still use 8-bit output because I like using overlay more than FSE.

I see. Can you comment on this article:

http://www.soundandvision.com/content/can-lcd-and-oled-tvs-display-rec-2020-color#8xv9y7bcb6kc7d2f.97

It claims TVs are currently incapable of display Rec. 2020. I thought 10-bit color and Rec. 2020 were one and the same, but it could be 10-bit output is only one of the specifications as stated by Wikipedia.

[nevcairiel]

10-bit output and BT.2020 are not strictly related, although for BT.2020 to work properly, you need at least 10-bit. But you can have BT.709 and use 10-bit as well.

[Asmodian]

It claims TVs are currently incapable of display Rec. 2020. I thought 10-bit color and Rec. 2020 were one and the same, but it could be 10-bit output is only one of the specifications as stated by Wikipedia.

Rec. 2020 requires 10-bit for decent quality (no banding) but 10-bit doesn't mean Rec. 2020 at all. Rec. 2020's gamut is defined by its primary colors, not the bit-depth, 100% green in Rec. 2020 is a much more saturated green than 100% green in BT.709. This means that Rec. 2020's green primary stimulates the red and blue receptors in the eye less than BT.709's.

10-bit output and BT.2020 are not strictly related, although for BT.2020 to work properly, you need at least 10-bit. But you can have BT.709 and use 10-bit as well.

They aren't related at all are they? 10-bit is simply using 10 bits to represent 0 (0) to 1 (1023). 1 (1023) represents full saturation of a primary color in the source or target gamut with 10-bit, the same as 1 (255) does with 8-bit.

You could output to Rec. 2020's gamut using 8-bit (or 1-bit), the only reason 10-bit is required by the spec is because banding would be very bad with only 256 steps due to the huge dynamic range. Isn't even 10-bit insufficient to avoid banding with Rec. 2020's increased luma range and the specs suggest/require 12-bit for that?

[Razoola]

As I understand it using 10bit with madVR as things currently stand means you do not have to use madVR's anti banding algorithms. Although my panel supports 10bit, my receiver does not so I have not investigated myself to be honest. Using 10 bit has nothing to do with the new colorspace spec (2020) currently in madVR.

[6233638]

As I understand it using 10bit with madVR as things currently stand means you do not have to use madVR's anti banding algorithms. Although my panel supports 10bit, my receiver does not so I have not investigated myself to be honest. Using 10 bit has nothing to do with the new colorspace spec (2020) currently in madVR.No - content should benefit more from debanding, since it is encoded with 256 steps (8-bit) and debanding can increase that to 1024 steps (10-bit) or more.
Using a 10-bit output means that dither is less visible.

[huhn]

SDR bt 2020 should be fine with 8 bit too.

bt 709 kind of works with 7 and 6 bit too if dithered properly.

so luma doesn't lose anything compared to bt 709 and PQ gamma should even help and make it better. and the chroma channel should survive with 8 bit too only green is a lot bigger.

HDR BT 2020 is of cause a whole different story.

[nevcairiel]

SDR bt 2020 should be fine with 8 bit too.

Not really, no. Full precision would require 12-bits even, and 10-bit dithered is probably going to be just fine. But 8-bit will easily band or require high dithering noise.

Unfortunately full testing will require much better screens than we have today. High-end screens can barely reach P3 color space, and are still far from full BT.2020 coverage.
Not to mention that the BT.2020 specification calls for 10 or 12 bits.. :)

HDR cannot really be compared directly, since it uses entirely different gamma curves, but HDR will definitely not work properly on lower bitdepth, thats for sure.

[huhn]

the 12 bit in bt 2020 comes from HDR.

with 100 CM² in mind the steps doesn't really increase in bt 2020 with 8 bit compared to 7 bit Bt 709.

only green got a lot bigger about 100 % so 1 more bit is needed to get the same number of steps between each color. but blue and red are only ~5-15 % further away from the white point.

so to get the same quality as 7 bit Bt 709 shouldn't be a problem with 8 bit.

[nevcairiel]

There are people much smarter than you and me that clearly mandate 10-bit for BT.2020. You are free to use it in 8-bit if you want, but I certainly won't. :)
It is correct that BT.2020 strictly needs 1 more bit than BT.709, but arguably 8-bit was not quite enough for BT.709 either. Visual tests by experts have confirmed that 11-bit is needed to cover the full visual spectrum of BT.2020.

But its all theoretical at this point still, consumer displays with such a high gamut are still far out. Hopefully next years TVs will at least get closer.

[Asmodian]

There are people much smarter than you and me that clearly mandate 10-bit for BT.2020. You are free to use it in 8-bit if you want, but I certainly won't. :)
It is correct that BT.2020 strictly needs 1 more bit than BT.709, but arguably 8-bit was not quite enough for BT.709 either. Visual tests by experts have confirmed that 11-bit is needed to cover the full visual spectrum of BT.2020.

But its all theoretical at this point still, consumer displays with such a high gamut are still far out. Hopefully next years TVs will at least get closer.

That is all assuming no-dithering though isn't it? Given how good dithering to 4 or 5-bit looks with BT.709 I can imaging madVR doing 4K Rec. 2020 quite well with only 8-bit. Not optimal but still happily watchable. :D

[Arm3nian]

Is 4K bluray supposed to use Rec. 2020? I think so.
But what's the point if there is no display with that gamut. Plus, how would you make such a high gamut display and not make everything else that is standardized look like crap? Would need dynamic LUTs or something.

[e-t172]

I can imaging madVR doing 4K Rec. 2020 quite well with only 8-bit.

I don't think it works that way. The dithering needs to be done in the source itself, which is typically not the case (I'm guessing for compression efficiency reasons). If you play an undithered 8-bit file and add dithering in the rendering chain, it will make each 8-bit step more accurate, but it won't magically recover the missing steps from the source.

[nevcairiel]

Is 4K bluray supposed to use Rec. 2020? I think so.
But what's the point if there is no display with that gamut. Plus, how would you make such a high gamut display and not make everything else that is standardized look like crap? Would need dynamic LUTs or something.

Future Blu-rays may also not use the entire full spectrum either, since movies right now are mostly mastered in DCI-P3 anyway, and in 2-3 years there will be displays which can support it.
And since the new spectrum is larger, you can still show any old content within the new spectrum, and it'll look like it always did - assuming the renderer knows what its doing, and hopefully madVR does. ;)

[Warner306]

I'm now clear on bit depths. Thanks for the discussion.

[Asmodian]

I don't think it works that way. The dithering needs to be done in the source itself, which is typically not the case (I'm guessing for compression efficiency reasons). If you play an undithered 8-bit file and add dithering in the rendering chain, it will make each 8-bit step more accurate, but it won't magically recover the missing steps from the source.

You are correct. I should have said 8-bit output, that is what I meant (like <8-bit BT.709 today). The source absolutely must be 10-bit or higher to store useful Rec. 2020 video; dithering in the source would not survive HVEC encoding well and is inefficient. The specs for the source format and the display format do not need to be the same, at least when using a sophisticated dithering video renderer like madVR. :cool:

[Nezil]

I think there is an interesting mis-understanding here, and it's something that's being mis-understood by almost everyone in the consumer space, and even many in the content creation industry...

BT.2020 isn't necessarily a goal to aspire to in making a display. Sure, it's great to have a wider colour gamut, but BT.2020 is intended to be a container format, rather than a gamut that displays would ever reach.

There is a very serious problem in getting to BT.2020, and that is one of metamerism. Displays today, and indeed those that could ever get to BT.2020 gamut, are based on a mixing of three primary colours, in order to represent the range of colours inside that gamut. BT.2020 specifies single wavelength primaries, whereas BT.709 and P3D65 (which will be used at least initially for Blu-ray) all have primaries that are relatively broad spectrum - they have many wavelengths of light that are mixed together to create 'Red'.

As you get closer to single wavelength primaries, the way a colour is perceived from person to person, and even the same person as they age, differs.

One of the widest gamut display technologies used today is laser based projection. Lasers, by definition, are single wavelength light sources, so they could theoretically be setup to produce a BT.2020 gamut. It quickly became apparent that for this (and other reasons), it is necessary to slightly alter the wavelength of each primary colour, making it less 'narrow-band'. Doing so reduced the colour gamut, but also reduced the rather large variations in colour that were being seen by different people.

The P3D65 displays in production now are already running into this issue, where a spectrophotometer can be used to set the white point to 0.3127, 0.3290, but the perception of the colour appears somewhat Green.

This colour science is a big and complex topic, but my point is... don't expect high quality BT.2020 displays in the next few years, and think of BT.2020 as a future proof container for data, not an aspirational goal for displays per se.

[MistahBonzai]

Nezil, thank you for the very informative and well stated overview. I only wish that display manufacturers would state the capabilities of their displays in such clear cut terms.

I can really appreciate your statement that the way a colour is perceived from person to person, and even the same person as they age, differs. I underwent corrective cataract surgery about 6 months ago and I have to confess, in hindsight, I preferred the slight 'sepia' tone my vision had acquired prior to the surgery over the blinding white that replaced it. However, I haven't missed the Vincent van Gogh halos in the least. ;)

[e-t172]

There is a very serious problem in getting to BT.2020, and that is one of metamerism. Displays today, and indeed those that could ever get to BT.2020 gamut, are based on a mixing of three primary colours, in order to represent the range of colours inside that gamut. BT.2020 specifies single wavelength primaries, whereas BT.709 and P3D65 (which will be used at least initially for Blu-ray) all have primaries that are relatively broad spectrum - they have many wavelengths of light that are mixed together to create 'Red'.

As you get closer to single wavelength primaries, the way a colour is perceived from person to person, and even the same person as they age, differs.

One of the widest gamut display technologies used today is laser based projection. Lasers, by definition, are single wavelength light sources, so they could theoretically be setup to produce a BT.2020 gamut. It quickly became apparent that for this (and other reasons), it is necessary to slightly alter the wavelength of each primary colour, making it less 'narrow-band'. Doing so reduced the colour gamut, but also reduced the rather large variations in colour that were being seen by different people.

That's quite interesting, thanks for the insight - I had no idea this could be an issue. I dug in a little further and found an experiment (http://www.cis.rit.edu/~yxa8513/Publications/Paper_CIC2014.pdf) that quantified the effect of metamerism with a laser projector (single-wavelength primaries), they came up with dE2000s in the order of 3 to 5, which is indeed pretty bad. The way I interpret this result is that observer variability for single-wavelength primaries is such that even an ideal, perfectly calibrated display would still appear "off" by 3-5 dE to most observers.

It seems like this problem could be solved by multi-primary displays (i.e. 4 primaries, 5 primaries - this book explains what that entails (http://eu.wiley.com/WileyCDA/WileyTitle/productCd-3527410406.html)). I'm guessing such displays would be prohibitively costly to produce, though.

That seems to suggest that one should definitely stay away from very wide gamut displays if one cares about color accuracy. In the world of BT.2020, will we see the emergence of communities of "purists" who deliberately watch BT.2020 content on standard BT.709 monitors (with gamut mapping of course) because they prefer color accuracy to gamut coverage? What about the monitors used for production (color grading)? Are we going to (again) end up in a world where one has to guess which color was meant by the artist because the content was mastered in a monitor with narrow primaries?

[madshi]

Not test with other conditions. This is one of conditions to trigger.
Ok, will probably be fixed in the next build.

It a way to deal with 29.97 sources which contain mostly 24p material.
From the manual: "Blend decimation of 30p sections into 24p and leave 24p untouched"
I would rather suggest to switch your display to 60Hz and enable smooth motion. That way you will get higher overall quality.

Basically "Blend decimation of 30p sections into 24p and leave 24p untouched" means the video is converted down to 24p by using frame blending. While running playback at 60Hz with madVR's smooth motion enabled means the video will be converted up to 60p by using frame blending.

All is well in the end, at least I learned something today. Sorry for creating more work for you
Np.

ah ok. Have you done some furhter investigations? Is there anything I could do to help you find out what is causing this error?
From what I've heard so far, the crash doesn't seem to be inside of madVR, but instead it's the media player which crashes. Could still be my fault. But it might make sense to ask for help from the media player devs first, in case it's their fault, after all. And they can at least get some information about the crash. Since the crash doesn't seem to run into madVR's crash analyzation sections, I don't have any useful crash information at all.

Is the error reporting working? I get the error message "Sorry sending the bug report didn't work"
Had madVR crash MPC-BE when I changed from fullscreen to windowed mode.

http://pastebin.com/fh0P5Y79
That looks quite strange. It's a crash related to DXVA processing (scaling or deinterlacing). Can you reproduce this issue? Or was it a one-time only crash?

Probably XYSubfilter
This occur even with EVR Custom but not with EVR.
Is it specific to the recent XySubFilter builds? Or does it occur with older builds, too?

I'm not too knowledgeable but I'm pretty sure XySubFilter is used in all the cases.
I can switch between subtitles while the video is playing while using XySubFilter context menu while in MPC-HC.
And I can see how embedded subtitles are correctly shown at the bottom of the screen while (some) external ones aren't.

Regarding madVR settings, under the zoom control tab, the only checked item is move subtitles: and the corresponding drop down is set to ... to bottom of the screen/window.
I also tried checking automatically detect hard coded black bars but it didn't help.
Indeed, since the videos don't have black bars in themselves it shouldn't do anything, right?
Can you show a screenshot from one typical situation where subtitles are where you think they should be, and another situation where subs are *not* where they're supposed to be? Please use videos with SRT subtitles for those screenshots. Thanks!

Can't reset "v0.89.12" to default settings Win10
What happens if you try? Do *not* use rightClick->run as admin. Just double click the batch file. That should normally do the trick.

madshi, any idea if you can implement something like this deblocking filter into madvr?

http://forum.doom9.org/showthread.php?t=132240
and
http://forum.doom9.org/showthread.php?t=134078

I mainly ask because deblocking MPEG-2, YouTube content, and pretty much any encoding will greatly improve the overall image quality much more than debanding ever did.
Those threads you linked to don't look like simple deblocking at all. They seem to be targetted at low quality Anime content, and they do all sorts of things, like removing noise, tighten up edges etc etc. You could use AviSynth via ffdshow raw video processor to do *exactly* what those 2 threads suggest in real time video playback (if your CPU is fast enough).

Whenever im watching a movie with a horizontal resolution of 1080 pixels and a fixed height there is no image upscaling done. There is chroma upscaling done, it does this not in DXVA (my standard setting for both chroma/luma) but uses the set algo from chroma upscaling (Bicubic 75AR). Shouldnt there be a DXVA setting be added to chroma, so that in this case the dedicated Intel hardware is still used for the chroma upscaling?
I've already changed the next build to do DXVA chroma upscaling, if you have selected DXVA image upscaling, and if chroma upscaling is set to Bilinear at the same time. But this only applies to Intel and NVidia GPUs. I'm not doing that for AMD GPUs. This is all rather complex because different GPUs have different behaviour/preferences with DXVA processing.

Is the problem with snapping image be pointed? Able to fix?
I don't know what you mean. If you want a reply, please either post a full description of the problem, or post a link to a post with a full description.

What were the settings used for the chroma upsampling and downscaling comparison in the second post?
I don't remember, too long ago.

what type of deinterlacing method does madvr use (vector or motion adaptive)?

I didn't find that much of a difference in the test patterns from the following site using software YADIF deinterlacing from MPC-HC and MADVR deinterlacing

yadif vs madvr deinterlacing used for the Live at Knebworth dvd showed almost the same result but with a big performance hit using madvr.
I'm using the highest quality algo the GPU offers. What performance hit do you mean? GPU power? YADIF is done by LAV via CPU, so the GPU doesn't suffer. DXVA deinterlacing is done by the GPU. So it's clear that the GPU has more work to do when doing DXVA deinterlacing. It depends on the GPU model, though, because some have dedicated hard wired circuits to do deinterlacing, while others use pixel shader power for that. When using YADIF, make sure you use 50p/60p (Video) output, because that's what DXVA does (by default), too.

using madvr with defaults settings will equal the quality of dedicated players using chips like faroudja or anchor bay (oppo players)?

there is a video benchmark and I wonder how madvr will do
I can't give you a definite answer there. A whole lot depends on whether we're talking about film content or native interlaced video content. And also which GPU we're talking about. AMD, NVidia and Intel all have different deinterlacing algorithms. AMD and NVidia has done well in those video benchmark tests, but that doesn't say a lot because it's easy to optimize for specific benchmarks. It's more important how deinterlacers handle real world content instead of some selected benchmarks.

Generally, madVR has a rather good film mode, which handles telecined movies very well. Which for my own use is the most important part of "deinterlacing". The majority of those benchmarks are about natively interlaced video content, though. Which is mainly sports and music concerts. I find that much less important than movies, so I haven't really done any serious image quality comparisons between DXVA deinterlacing and faroudja/anchor bay/hqv/gennum chips.

"bits" is not worked, worked "srcbits" (and "bitdepth" too, no difference in my testing - both actually reflect bitdepth of stream on madVR input, actually no true _source_ bitdepth in case of "srcbits") so maybe you change help?
Hmmmm... The old names like "srcbits" are still supported, so old profiles don't break. But I wanted to rename them to simpler names like "bits". I'll double check if "bits" works for me.

2. can i ask new string variable like "device" or "targetDevice" - the name of current rendering device taked from "devices->device name:" field of config?
What purpose would you use that for?

It is correct that BT.2020 strictly needs 1 more bit than BT.709, but arguably 8-bit was not quite enough for BT.709 either. Visual tests by experts have confirmed that 11-bit is needed to cover the full visual spectrum of BT.2020.
I would have loved for UHD Blu-Ray to use 12bits, especially for HDR. But it is what it is. I agree that 8bit was not enough for SDR / Blu-Ray, either. Which we can see in many Blu-Ray releases which show banding problems.

There's one important thing to note here, though, which Joe Kane and other experts usually ignore, although they shouldn't:

When encoding (SDR) BT.2020 in YCbCr, the luma channel is actually (more or less) identical to BT.709, because BT.2020 does not define a higher peak white! Practically that means that as long as we stick to YCbCr encoding, the size of the gamut does not matter at all for *luma* banding. A bigger gamut size with identical bitdepth will of course increase banding in the chroma channels. But I doubt that would be a real visible problem. The banding artifacts we see are usually caused by the luma channel, not by the chroma channels...

[kolak]

Well dithered Blu-rays are not that bad in terms of banding. Bigger problem is that many authoring studios don't use dithering at all!
I've done many titles where 8bit dithered uncompressed master was absolutely fine. More problems appeared after h264 encoding, but it was still acceptable.
10bit support in Blu-ray would make life easier for authoring houses. It would also increase quality, but not as much as many predict. Most of the film titles did not have any banding issues, even with plain 10bit->8bit conversion. It was a bigger problem for anime and some titles with specific picture nature.
HDR can cause more problems. NHK's study around this problem found that HDR needs somewhere between 11 and 12bit to avoid visible banding issues. 4K Blu-ray will be way less popular than current BD, so not many companies are willing to spent time an money to make it great. It may end up massive failure- time will show.

[XMonarchY]

I wanted to update images shown in Post #2 of this thread because madshi does not have the time to update them, but madVR has gone SO far past what version 0.5 could do and I think newbies need to see that.

All I need is the original images used and then I will use the highest quality madVR settings to render them, take screenshots, and post the links so madshi can update them.

I can update more, I think...

[madshi]

Well dithered Blu-rays are not that bad in terms of banding. Bigger problem is that many authoring studios don't use dithering at all!
I've done many titles where 8bit dithered uncompressed master was absolutely fine. More problems appeared after h264 encoding, but it was still acceptable.
10bit support in Blu-ray would make life easier for authoring houses. It would also increase quality, but not as much as many predict. Most of the film titles did not have any banding issues, even with plain 10bit->8bit conversion. It was a bigger problem for anime and some titles with specific picture nature.
I see banding problems in Blu-Rays quite often, and not limited to Anime. My impression is that authoring studios using dithering is rather the exception than the rule. I often see banding problems in dark scenes, or it's especially noticable in fade-to-blacks. Fade-to-blacks in 8bit without dithering almost always looks ugly and non-smooth.

Sometimes I'm wondering why dithering is often not used by authoring studios. Either they're just dumb. Or maybe they don't want to spend the additional video bitrate needed to encode dithering without getting compression artifacts.

HDR can cause more problems. NHK's study around this problem found that HDR needs somewhere between 11 and 12bit to avoid visible banding issues. 4K Blu-ray will be way less popular than current BD, so not many companies are willing to spent time an money to make it great.
Thanks to the totally different HDR transfer function, I think banding will be less a problem with HDR than it is with current 8bit Blu-Rays, because the transfer function moves the majority of the 10bits to SDR pixels. Still, I'd have loved to get 12bits to get totally rid of any banding once and forever.

[madshi]

fps, deintFps, _bits_

"bits" is not worked, worked "srcbits"
The error was in the help. The correct name of the field is now "bitDepth", not "bits". But the old "srcbits" still works, too.

[ma3743]

hi
which graphic card is better for madvr+SVP:
GTX TITAN BLACk 6GB or GTX 980?

on the other hand, which graphic card should I have for max madvr settings (around 1000$)?

thanks in advance

[huhn]

it's close but it's the 980.

[Thunderbolt8]

I'd have loved to get 12bits to get totally rid of any banding once and forever.do 12bits get rid of any banding per definition?

[madshi]

do 12bits get rid of any banding per definition?
If the studio master has no baked in banding, and if the authoring house doesn't do a major screw up, then yes, 12bit should avoid running into any banding problems. If the studio master already has banding baked in then even encoding in 12 million bits would not help.

[madshi]

madVR v0.89.13 released

http://madshi.net/madVR.zip

* added support for rotation (0°, 90°, 180°, 270°) via key shortcut and API
* videos are automatically rotated now, if the container/splitter says so
* improved chroma quality when using DXVA on Intel (and maybe NVidia) GPUs
* improved DXVA processing performance under specific circumstances
* if DXVA is used, brightness, contrast, hue etc is applied by DXVA now
* fixed a couple of DXVA processing related bugs
* Intel/NVidia: DXVA2 image + Bilinear chroma upscaling -> DXVA chroma up
* DVD Navigator AR has now priority over decoder / splitter / bitstream AR
* updated AdaptiveSharpen to 2015-10-29 (experimental) version
* added new profile rule script variables "display" and "variableAR"
* optimized RAM consumption a bit, maybe
* added option to not resume playback after lens memory change
* fixed lens memory activation problem for Sony projectors
* fixed: "runtime" profile variable didn't work properly

Edit: If any devs are interested, the rotation is available via the following APIs:

IMadVRCommand::SendCommandInt("rotate", 90); // supported values: 0, 90, 180, 270
IMadVRInfo::GetInt("rotation", &intVar);

Should usually not be necessary to call these APIs, though, since madVR auto-rotates if the container says so. Default keyboard shortcuts for rotation are "Ctrl+Alt+Shift+Right/Left" arrow keys.

[aufkrawall]

Thanks!

But are you sure that you put the right Adaptive Sharpen version into it?
It still gives me a very noticeable brightness increase with a strength of 0.5, which is not the case with the shaders linked by bacondither.

[Asmodian]

madVR v0.89.13 released
Should usually not be necessary to call these APIs, though, since madVR auto-rotates if the container says so. Default keyboard shortcuts for rotation are "Ctrl+Alt+Shift+Right/Left" arrow keys.

This is amazing! Thanks a lot! This is a very old problem for video on PCs, finally fixed properly. :thanks:

[FreeFall]

Thanks madshi and nevcairiel, subtitle positioning is working well. The keep black bars visible if they contain subtitles option has stopped working in newer builds, none of the settings are working.

The last working build was ver 0.89.9.

Cheers.

[Blackfyre]

As always, thanks Madshi.

[Arm3nian]

I've watched LOTR 1000 times, but now I can watch it 1000 more times upside down! Sweet :p

[ryrynz]

That looks quite strange. It's a crash related to DXVA processing (scaling or deinterlacing). Can you reproduce this issue? Or was it a one-time only crash?


Would be scaling, can't duplicate the issue with previous or latest build.

[mindz]

* Intel/NVidia: DXVA2 image + Bilinear chroma upscaling -> DXVA chroma up

Thanks! Works :).