madVR - high quality video renderer (GPU assisted)

[huhn]

and how do you tell a display to not tone map.

the closes to that is a HDR 3D LUT.

[Asmodian]

This user wants to know if you can somehow send the PQ transfer function to the display to trigger HDR mode and use madVR's adjustable and sometimes superior tone mapping to replace the display's tone mapping? Sounds technically impossible, but would be nice.

Isn't that what both "process HDR content by using pixel shader math" and "process HDR content by using an external 3DLUT" are for? At least as far as it can go, you cannot tell the display to turn off its tone mapping. However, you do get some of the benefits from madVR's superior tone mapping, or DisplayCal's when using a 3DLUT, and you can set the metadata so you can influence the display's tone mapping.

[Polopretress]

Running x86-64 (AMD64) Windows applications requires both a CPU with x86-64 instruction set and a 64-bit code variant of a Windows operating system (optional and common as private user OS since Vista, more or less mandatory since 8).

Thanks to the extended compatibility in the x86-64 architecture developed by AMD (in contrast to the Itanium IA-64 architecture by intel which is incompatible to x86 / IA-32), 32-bit x86 processes still run in a SysWoW64 (Windows on Windows-64) environment, but all DLL's used by a 32-bit process must also be programmed for 32-bit x86 architecture, and all DLL's used by a 64-bit process must be programmed for 64-bit x86-64 architecture. Windows will check the DLL header and refuse to load libraries not matching the bitness of the calling process.

To be able to load the 64-bit variant of madVR (and LAV Filters), you have to run a 64-bit player application on a 64-bit Windows.

64-bit code can already be faster simply because CPU registers in 64-bit mode have a) twice the width and b) twice the number, compared to the 32-bit mode. Every instruction which can avoid RAM access by using data still stored in another CPU register is a little improvement.
OK, i was maybe not enough clear.
System is in Win10 64 bits.
The installation included lav32bits, reclock32bits, mpc-be32bits and madVR.
Linked to the issue with CPU 4k hevc decoding (multiple drop with "queue decoder" at 1 while CPU is not above 40% of usage), player potplayer64 bits has been installed without any other modification and fixed the problem.
Lav is still in 32 bits. Reclok also (of course)

It seems to work fine. i was surprised.

Question is : in this case, what is the mode used by madVR (32 or 64 bits) ?

[huhn]

if you use a 64 bit player everything else it 64 bit too.

[thighhighs]

I still think using 2.4x would be more appropriate, direct 4x does take a little more GPU power than 2x and it would be consistent. Upscaling to 4x and then downscaling to 2.05x is not ideal.


I agree. Because "always" quadrupling in some cases does not improve the quality, but it might hurt performance.

[Warner306]

Isn't that what both "process HDR content by using pixel shader math" and "process HDR content by using an external 3DLUT" are for? At least as far as it can go, you cannot tell the display to turn off its tone mapping. However, you do get some of the benefits from madVR's superior tone mapping, or DisplayCal's when using a 3DLUT, and you can set the metadata so you can influence the display's tone mapping.

I see. Are you still stuck with the backlight and contrast settings of the display's SDR mode? I don't completely understand how this works. Can you toggle the display's HDR mode by sending it the correct metadata by 3D LUT? Many calibration topics are not completely clear to me.

[Asmodian]

No, you are not stuck in SDR mode. You set the metadata with madTPG (madVR when the 3DLUT is used), measure the display as it responds given that metadata, and construct the 3DLUT based on that. For best results I have found you really need a 3DLUT for every movie, this can be done with DisplayCal's 3DLUT creating utility but it is a bit crazy. Because the TV is always in the same mode you only need to profile once but given that the mastering display's peak white and the video's peak white both influence the 3DLUT most videos would use a different 3DLUT. That said I get decent results as long as the peak whites for the 3DLUT are higher than the peak white in the video (if not they clip generating nasty banding artifacts).

What we need is pixel shader math that takes the source's metadata into account to convert to a specific set of metadata and then send that through an HDR 3DLUT. If that makes sense? :p

[BetA13]

Ha, nice one...You sneaky little developer....
Where there some performance improvements?
Because for me its like an early birthday present cause i can use NGU Medium now :) and still be under 20ms.
Before i could only use NGU Low.

Im impressed..I also think i did understand the whole MadVR now..what each setting does,, how it works, etc..
Using and understanding MadVR is like a study Project at the University, it took me allmost 5 years to figure it all out..
And i learned so freaking much about Video processing and upscaling filters, etc etc..
Everytime theres a new version, i get sweaty hands and start to test and fiddle wich each setting to see whats changed and such, and when iim finished i allways wonder where the Time did go..Its easy for me to get lost for hours while fiddling around with your awesome Programm.. :)
Damn, nothing, really nothing comes close to the quality of MadVR..
Ever since i started using madvr i wondered what all the TV´s use for up and downscaling, because it looks soo bad..

anyway, what i wanted to say to you @madshi, THANK you for all youve done, and thank you for sparking my interesst in this area, this is kinda my hobby now, setting up Home cinemas for my friends haha..

have a good night :)

[sauma144]

I'm gonna have some more crazy dreams about this new algorithm. :D

[Grimsdyke]

Hi Madshi, nice to have you back and thank you for all the hard work !!
I have an issue with a few PAL-SD files in the following configuration:
-> MPC-BE + LAV (Hardware device to use: Automatic(Native)) + MadVR => File plays normally for a few seconds then screen turns completely green !! File keeps playing and I hear sound.
-> MPC-BE + LAV (Hardware device to use: (GPU selected)) + MadVR => File plays normally
Unfortunately I can' keep this configuration because the drop in performance is too big for 4K. Not that important but maybe you could look into this when you have the time. Thx !!

[nevcairiel]

As a workaround there is always the option to disable HW acceleration for SD files, any half-competent CPU should be able to decode that. Of course it would be best if madshi can figure out whats going wrong with D3D11-Native there, but he may need a sample file that fails for you.

[zaemon]

Hi Madshi, nice to have you back and thank you for all the hard work !!
I have an issue with a few PAL-SD files in the following configuration:
-> MPC-BE + LAV (Hardware device to use: Automatic(Native)) + MadVR => File plays normally for a few seconds then screen turns completely green !! File keeps playing and I hear sound.
-> MPC-BE + LAV (Hardware device to use: (GPU selected)) + MadVR => File plays normally
Unfortunately I can' keep this configuration because the drop in performance is too big for 4K. Not that important but maybe you could look into this when you have the time. Thx !!

Same problem for me with 10-bit files. Disabling HW acceleration is not an option with HEVC for me unfortunately. And I still got this pink/green blinking at start when HW decoding is running.

[e-t172]

A general question about achieving proper 24p cadence:

I recently realized after discussing it with someone else that neither 24 Hz nor Smooth Motion is required to achieve proper cadence with modern TVs/projectors. That's because they are capable of automatically recovering a 24p signal from a 24p@60Hz (3:2 pulldown) input, i.e. they are capable of IVTC/decimation. Rtings calls this "Judder-Free 24p via 60p (https://www.rtings.com/tv/tests/motion/24p#comparison_1790)". In theory, if the TV does this right, the process is completely lossless and one has no reason to expect any loss in quality compared to "native" 24p@24Hz.

Of course this still leaves open the issue of audio/video clock mismatch when playing from a PC, causing random hiccups. AFAICT, this can be solved using ReClock or similar (which will "nudge" the clock towards perfect 3:2 pulldown cadence with no discontinuities), or by using custom modes to achieve perfect audio-clock-synchronized 59.940 Hz, which is easier than trying to achieve perfect 23.976 Hz (higher numbers mean higher relative precision).

I don't have a modern TV/projector to test this on right now, but I'm curious about this approach. Has anyone tried it? Are there downsides that I'm missing? This seems interesting to me because this setup is more user-friendly - no need to switch between 24 Hz and 60 Hz when playing video. Also, I seem to remember madshi saying at some point that madVR is not designed to generate a "perfect" 3:2 pulldown cadence when playing 24p@60Hz, which would prevent this solution from working. Is that true?

[huhn]

this is mostly for interlanced content and you can't get the interlaced content out untouched using a PC.

this often doesn't work in PC mode.
it will obviously increase input lag and you need some kind of motion interpolation.

as far as i know madVR is fine by repeating frame and really bad when it comes to show like 50 FPS at 25 HZ.

[e-t172]

this is mostly for interlanced content and you can't get the interlaced content out untouched using a PC.

No, it's not about interlaced content. It works for both 60i and 60p. (https://www.rtings.com/tv/tests/motion/24p#comparison_1790)

this often doesn't work in PC mode.

Interesting, thanks.

it will obviously increase input lag

Makes sense.

and you need some kind of motion interpolation.

No. When Rtings tests for 24p recovery from 60 Hz their protocol (https://www.rtings.com/tv/tests/motion/24p#comparison_1790) states "we never use interpolation during these tests".

as far as i know madVR is fine by repeating frame and really bad when it comes to show like 50 FPS at 25 HZ.

Okay, that's good news then.

[huhn]

No, it's not about interlaced content.It works for both 60i and 60p. (https://www.rtings.com/tv/tests/motion/24p#comparison_1790)

i said mostly

No. When Rtings tests for 24p recovery from 60 Hz their protocol (https://www.rtings.com/tv/tests/motion/24p#comparison_1790) states "we never use interpolation during these tests".

so it will just randomly increase input lag as soon as it thinks it get's a 3:2 cadance as input? you need at least 3 frame to make this work that's over 48 ms.

as i said you need >some kind of motion interpolation<
To activate judder removal, set 'Auto Motion Plus' to 'Custom', 'Judder Reduction' to 0 and 'Blur Reduction' to 0; this will remove judder without adding soap opera effect.

and rtings is far from perfect they give a PC screen i have here an 8 bit deep rating even through it is the dirtiest 6 bit panel i have seen in my life it's like an ant farm.

[e-t172]

so it will just randomly increase input lag as soon as it thinks it get's a 3:2 cadance as input? you need at least 3 frame to make this work that's over 48 ms.

That's not necessary. The TV can simply switch to this mode when it detects that, say, the past N (say, 60) frames exhibited a 3:2 pattern. Then, once it's in this mode, it stays in it until it detects that the past N frames do not have the pattern anymore. The TV doesn't need to react immediately - no one cares if it takes a second or so to switch into the proper 24p cadence.

When in this mode, the TV will display in 24p by discarding identical frames. The TV can discard a frame as soon as it gets it because it knows which frames are redundant and when a new 24p frame starts - it knows the cadence. I would expect the minimum required input lag to be around 16 ms (one 60 Hz frame).

What's more, 48 ms input lag is actually very typical of TVs (https://www.rtings.com/tv/tests/inputs/input-lag) when used in 60 Hz outside "low input lag" mode. It's not a concern for video playback as the lag can be compensated on the audio side. (Although I agree it's a concern in "dual use" scenarios where the TV is used for gaming as well.)

as i said you need >some kind of motion interpolation<

Decimation/IVTC (which is what the TV is doing in this case) has nothing to do with motion interpolation at all. It's not trying to compute motion vectors or anything like that, it's just decimating frames that are identical, which is a much simpler operation, and can be lossless when done correctly.

[huhn]

That's not necessary. The TV can simply switch to this mode when it detects that, say, the past N (say, 60) frames exhibited a 3:2 pattern. Then, once it's in this mode, it stays in it until it detects that the past N frames do not have the pattern anymore. The TV doesn't need to react immediately - no one cares if it takes a second or so to switch into the proper 24p cadence.
so it supposed to switch between different audio delays?
ok we detected a 3:2 judder let's hold playback until we have enough frames buffered to do IVTC?

no you have to run it all the time or not at all.

When in this mode, the TV will display in 24p by discarding identical frames. The TV can discard a frame as soon as it gets it because it knows which frames are redundant and when a new 24p frame starts - it knows the cadence. I would expect the minimum required input lag to be around 16 ms (one 60 Hz frame).
these frames are often not bit identical so can not blindly discard duplicates.

and if you do this you will still get a 3:2 judder the complicated part of IVTC is the frame time correction.
if you just discard frames the frame times will stay the same meaning a with a 3:2 source it will take 48 ms before the next frame come that only shown for 32 ms but both needs to be shown for about 42 ms.

What's more, 48 ms input lag is actually very typical of TVs when used in 60 Hz outside "low input lag" mode. It's not a concern for video playback as the lag can be compensated on the audio side. (Although I agree it's a concern in "dual use" scenarios where the TV is used for gaming as well.)
that's just 48 ms ontop of the rest of the input lag. easily reaching 100+

Decimation/IVTC (which is what the TV is doing in this case) has nothing to do with motion interpolation at all. It's not trying to compute motion vectors or anything like that, it's just decimating frames that are identical, which is a much simpler operation, and can be lossless when done correctly.
that doesn't change that it is on option under motion interpolation.

[nevcairiel]

so it supposed to switch between different audio delays?
ok we detected a 3:2 judder let's hold playback until we have enough frames buffered to do IVTC?

You don't need to delay anything when decimating 60 fps to 24 fps, you just throw away some frames in between. This is not like encoded 30 fps IVTC content where you get fields that need re-combining into frames. Its full frames on a 3:2 repeat pattern.

[e-t172]

so it supposed to switch between different audio delays?
ok we detected a 3:2 judder let's hold playback until we have enough frames buffered to do IVTC?

You do not need to "hold back" any frames to do IVTC if you already know the cadence. At least not on 60p (not sure about 60i). I think I've made that clear.

these frames are often not bit identical so can not blindly discard duplicates.

They often are. Why wouldn't they be? They're coming from the same framebuffer on the source side, and there is no lossy temporal processing in between. (Though I guess maybe dithering steps could throw a wrench into this assumption.)

Even if they're not, any IVTC algorithm worth its salt will not assume they are identical. Instead it will compute some kind of difference metric (such as simple RMS) to provide at least some resilience to noise.

And again, please keep in mind that duplicate detection is only used to detect cadence changes. Once you know the cadence, you don't need to do any measurements to know which frames should be discarded and which should be kept.

and if you do this you will still get a 3:2 judder the complicated part of IVTC is the frame time correction.

I don't see how that's complicated - it's just arithmetic. Detecting the cadence is the complicated part. The decimation part is trivial in comparison. Once the TV knows the cadence (i.e. it knows when the 3:2 pattern starts and when it ends), it knows that it needs to switch to 24p, and it knows which frames need to be displayed and when.

The only case where you incur massive input lag is if you want to detect cadence changes in advance so that you can seamlessly transition from one cadence to the next. That indeed requires you to look far into the future. About 10 years ago I wrote my own IVTC filter (https://forum.doom9.org/showthread.php?p=1505171#post1505171) that did something like that, and I believe that's also how madVR IVTC works to some extent. The video player can afford to do that because it can preprocess frames in advance; the TV can't. But that's only a "nice to have", not a requirement, especially for high-quality 60p. You can do without it as long as you're not after perfect transitions between different cadences, which is really not a problem for the scenario that this discussion is about (stable 24p@60Hz).

if you just discard frames the frame times will stay the same meaning a with a 3:2 source it will take 48 ms before the next frame come that only shown for 32 ms but both needs to be shown for about 42 ms.

You can deduce from your own numbers that in the worst case scenario the minimum required input lag is about 6 ms in your very own example. (The worst case scenario is when you're in the middle of the 3:2 pattern, at t+42ms, where you need to display the second 24p frame right now but it will only come at t+48ms - a 6 ms delay.) That's even better than the 16 ms number I mistakenly put forward initially.

that's just 48 ms ontop of the rest of the input lag. easily reaching 100+

What makes you think that it can't be done in parallel with the rest of image processing? I can very easily imagine an implementation where images can be removed from the internal processing pipeline queue during or after other processing steps have been done.

that doesn't change that it is on option under motion interpolation.

Oh so we trust the terminology used in TV OSD menus now? Since when?

[huhn]

You do not need to "hold back" any frames to do IVTC if you already know the cadence. At least not on 60p (not sure about 60i). I think I've made that clear.

because you don't know the cadance with out it.
and the real trick of TVs is that they can do both at the same time by displaying at 120 HZ. the transition has to be smooth and that'S important so the switch between movie and CM is not a judder party.
so the real trick is not switch between modes it is stay in one.
and that's most likely the reason 60 HZ sonys can'T do it even though they can display 24 p correctly

They often are. Why wouldn't they be? They're coming from the same framebuffer on the source side, and there is no lossy temporal processing in between. (Though I guess maybe dithering steps could throw a wrench into this assumption.)
it's made for broadcast not us HTPC user.
and broadcast is far from bit identical and a simply comparison is not enough.
Even if they're not, any IVTC algorithm worth its salt will not assume they are identical. Instead it will compute some kind of difference metric (such as simple RMS) to provide at least some resilience to noise.

and that's why you should buffer frames to make sure it's a better result.

And again, please keep in mind that duplicate detection is only used to detect cadence changes. Once you know the cadence, you don't need to do any measurements to know which frames should be discarded and which should be kept.

you have to check for changes. braodcast changes all the time.

I don't see how that's complicated - it's just arithmetic. Detecting the cadence is the complicated part. The decimation part is trivial in comparison. Once the TV knows the cadence (i.e. it knows when the 3:2 pattern starts and when it ends), it knows that it needs to switch to 24p, and it knows which frames need to be displayed and when.

The only case where you incur massive input lag is if you want to detect cadence changes in advance so that you can seamlessly transition from one cadence to the next. That indeed requires you to look far into the future. About 10 years ago I wrote my own IVTC filter (https://forum.doom9.org/showthread.php?p=1505171#post1505171) that did something like that, and I believe that's also how madVR IVTC works to some extent. The video player can afford to do that because it can preprocess frames in advance; the TV can't. But that's only a "nice to have", not a requirement, especially for high-quality 60p. You can do without it as long as you're not after perfect transitions between different cadences, which is really not a problem for the scenario that this discussion is about (stable 24p@60Hz).

why should a Tv use a lower quality and not simply adds input lag?

TV mostly display braodcast that'S the opposite of high quality.

You can deduce from your own numbers that in the worst case scenario the minimum required input lag is about 6 ms in your very own example. (The worst case scenario is when you're in the middle of the 3:2 pattern, at t+42ms, where you need to display the second 24p frame right now but it will only come at t+48ms - a 6 ms delay.) That's even better than the 16 ms number I mistakenly put forward initially.

if you have duplicated frames that are nearly or even bit perfect you could do it faster but what end device is outputting something like that except a PC?
why would you write an algorithm for that.

so yes you can do it faster by blindly following a cadance pattern and dropping/repeating frames as they pleases and ignore transitions.
very limited use case at best.

What makes you think that it can't be done in parallel with the rest of image processing? I can very easily imagine an implementation where images can be removed from the internal processing pipeline queue during or after other processing steps have been done.


because you just start rendering images after the IVTC algo is done with it to be save.
the calculation for zones over drive and so many other stuff needs to be made and can be totally screwed over if you change the frame that needs to be displayed.
Oh so we trust the terminology used in TV OSD menus now? Since when?

this cadance detection is very important for frame interpolation. it's basicly the first step and part of it.

[nevcairiel]

because you don't know the cadance with out it

You can however safely assume that the cadence is not going to change all the time, so that you can just analyze the cadence and act on it once you know - without any buffering. Sure, it may result in the cadence processing to take a second or so to turn on, but thats not a problem in real-world usage - because its just not changing repeatedly.

No extra latency required. Buffering requires extra hardware, this costs money, hence easy to imagine that its best avoided.

[huhn]

You don't need to delay anything when decimating 60 fps to 24 fps, you just throw away some frames in between. This is not like encoded 30 fps IVTC content where you get fields that need re-combining into frames. Its full frames on a 3:2 repeat pattern.

you can assume a perfect situation here that a very dangerous.

you assume the pattern doesn't change ever.
this adds at least 8 ms delay this is the pure minimum.
because the 3:2 part has a frame that needs is 48 ms in these 48 ms you don't even have the frame you need to display after 42 ms you have to wait for the frame with 33 ms length.

[huhn]

You can however safely assume that the cadence is not going to change all the time, so that you can just analyze the cadence and act on it once you know - without any buffering. Sure, it may result in the cadence processing to take a second or so to turn on, but thats not a problem in real-world usage - because its just not changing repeatedly.

No extra latency required. Buffering requires extra hardware, this costs money, hence easy to imagine that its best avoided.

because TV are made for broadcast which changes all the time.
and you have the buffer for frame interpolation anyway the hardware is present.

[e-t172]

because you don't know the cadance with out it.

Sure, that means that it might take some time for the TV to switch into the proper cadence. Let's say that it takes 6 patterns for it to detect a cadence, i.e. 30 frames. That means it will take around 0.5 sec for the TV to detect a cadence change. That's quite acceptable for most use cases IMHO. People don't spend their time switching between 24p and other types of content constantly, and if they do, they probably don't care about it being silky smooth around transitions.

and the real trick of TVs is that they can do both at the same time by displaying at 120 HZ. the transition has to be smooth and that'S important so the switch between movie and CM is not a judder party.
so the real trick is not switch between modes it is stay in one.
and that's most likely the reason 60 HZ sonys can'T do it even though they can display 24 p correctly

I'm sceptical. AFAIK the reason why changing modes take time is because the HDMI connection is being reset (handshake, etc.) But here there is no HDMI connection - the TV is changing modes internally (not because of the source). Therefore I would expect the TV to be able to seamlessly switch between 24 Hz and 60 Hz in this scenario. Maybe the internal processing pipeline of typical TVs prevent them from doing that, but I honestly wouldn't know. Do you have evidence for these statements?

it's made for broadcast not us HTPC user.

Nowadays I would expect plenty of non-broadcast sources to output 24p over 60 Hz simply because they don't know better or can't be bothered to do better. PCs of course, but also dongles, phones/tablets, streaming apps, etc. My guess is that's why modern TVs pay extra attention to it and try to convert it to proper 24p before display. I don't think they're doing it solely because of broadcast sources. In fact, if you look at the Rtings results you'll notice that most pre-2017 TVs can't do this trick - it's only very recent TVs that are capable of doing this on-the-fly decimation thing. Which is why I find this phenomenon especially interesting and worth discussing now.

and broadcast is far from bit identical and a simply comparison is not enough.

You don't need to tell me. Again, I wrote my own IVTC filter specifically designed for broadcast TV. I have first-hand experience of the issues involved, and yes, it's a mess. But we're not dealing with broadcast here, we're dealing with a much cleaner stream.

and that's why you should buffer frames to make sure it's a better result.

You don't have to buffer frames to achieve a good result. You only need to do that if you want perfect transitions, which a very specific, less important requirement.

you have to check for changes. braodcast changes all the time.

Not really, no. The worst I've seen is a TV broadcast constantly switching between soft telecine and hard telecine (which is bonkers), but even that can be handled without buffering by making the algorithm a bit more clever. And even then I've only seen this kind of crazyness with 30i (because interlacing makes everything more fun!). 60p is usually broadcast as a perfectly clean 3:2 pattern. And again, this is not about broadcast.

why should a Tv use a lower quality and not simply adds input lag?

Because engineering tradeoffs? Because algorithms that use larger buffers require more memory and are often more complicated? Because TV manufacturers are aware that people use their devices for things other than video playback?

TV mostly display braodcast that'S the opposite of high quality.

I think that assumption is becoming weaker and weaker. This is 2018 - it's all about Netflix and friends now.

if you have duplicated frames that are nearly or even bit perfect you could do it faster but what end device is outputting something like that except a PC?

It would be faster, but not that much faster. Computing something like an RMS difference between two frames is not much slower than comparing them byte by byte. Both operations are pretty fast compared to other image processing tasks, especially on specialized hardware. In both cases I would expect memory bandwidth to be the bottleneck anyway.

why would you write an algorithm for that.

I wouldn't. I would just compute some metric for the difference.

so yes you can do it faster by blindly following a cadance pattern and dropping/repeating frames as they pleases and ignore transitions.
very limited use case at best.

You don't ignore transitions. There is just a small reaction delay (less than a second) when a transition occurs. Which is very reasonable, even for broadcast.

because you just start rendering images after the IVTC algo is done with it to be save.
the calculation for zones over drive and so many other stuff needs to be made and can be totally screwed over if you change the frame that needs to be displayed.

I'm not sure I agree, but I don't think that discussion is relevant anyway because I've already shown you multiple times that IVTC can be done with negligible delay as long as you're happy with it not being perfect over a short window around transitions.

this cadance detection is very important for frame interpolation. it's basicly the first step and part of it.

I guess that makes sense. It doesn't necessarily mean that enabling cadence detection results in motion interpolation being forcibly enabled, though.

you assume the pattern doesn't change ever.

No, we're not assuming that. We're assuming that the user is okay with the cadence being slightly wrong for a short period of time (<1 second) right after a cadence change occurs.

this adds at least 8 ms delay this is the pure minimum.
because the 3:2 part has a frame that needs is 48 ms in these 48 ms you don't even have the frame you need to display after 42 ms you have to wait for the frame with 33 ms length.

I had calculated 6 ms, but that's neither here nor there, I think we agree on principle.

because TV are made for broadcast which changes all the time.

I think you're exaggerating things. Content type might change every few minutes. It certainly won't change every few seconds.

and you have the buffer for frame interpolation anyway the hardware is present.

If you want to perfectly predict cadence changes in advance on noisy TV broadcasts you need a much larger buffer than the one required for frame interpolation. Back in the days when I was writing an IVTC filter for TV broadcasts, I had to buffer at least a dozen frames in advance or something like that.

huhn: I really think this discussion is going nowhere and I'm not sure we'll be able to convince each other unless we start reverse engineering TV processing pipeline internals (which would be, well, hard). I don't even understand why we're having this discussion, because Rtings clearly demonstrated (https://www.rtings.com/tv/tests/motion/24p#comparison_1790) that at least a dozen 2017 TVs from a variety of manufacturers are, in fact, capable of decimating 24p@60Hz on the fly and these TVs don't have more input lag than other models (you can add "Input Lag" columns to the table if you're not convinced). It's not a question of "if they can" - there is a mountain of evidence that they, in fact, can. My original question was "how can we exploit this to simplify or improve our playback systems", which I think is the more relevant question here. Can we get back to that please?

[huhn]

huhn: I really think this discussion is going nowhere and I'm not sure we'll be able to convince each other unless we start reverse engineering TV processing pipeline internals (which would be, well, hard). I don't even understand why we're having this discussion, because Rtings clearly demonstrated (https://www.rtings.com/tv/tests/motion/24p#comparison_1790) that at least a dozen 2017 TVs from a variety of manufacturers are, in fact, capable of decimating 24p@60Hz on the fly and these TVs don't have more input lag than other models (you can add "Input Lag" columns to the table if you're not convinced). It's not a question of "if they can" - there is a mountain of evidence that they, in fact, can. My original question was "how can we exploit this to simplify or improve our playback systems", which I think is the more relevant question here. Can we get back to that please?

these numbers are done with gaming mode none of these TVs is know to be able to do it in gaming modes.
outside of gaming mode they have something like 40-160 ms input lag exactly my point. and to top it of they even show you that you have to use setting from interpolation. (i'm not saying you are getting a soap opera on your screen).

i say it out laud now this feature comes from frame interpolation because it is needed for it. they got it for free.

the reason this is hard to use for a HTPC user is here i repeat my self.
high input lag no PC mode.

and here some new ones it will die as soon as you move your mouse. usually loss of chroma resolution lot's of other processing quirks.
"how can we exploit this to simplify or improve our playback systems"
you set your TV to 60 HZ in windows and active the option in the interpolation settings. and live with the problems of it.

[Asmodian]

I know my 2017 LG OLED (touted as low input lag) only has low input lag in PC or Game mode, and in that mode it switches off most processing. It even does worse tone mapping in PC HDR modes, though I think this might be due to not wanting to over-saturate sRGB games rather than not having enough time.

Measuring input lag in game or PC mode but then using other modes to test things like 24p in 60Hz can give misleading impressions. :(

In its other modes my TV's input lag is very high, the mouse cursor feels connected by long rubber bands. I haven't measured it but it is too high to use it as a monitor.

[e-t172]

these numbers are done with gaming mode none of these TVs is know to be able to do it in gaming modes.

Rtings measures TV input lag in a dozen different modes (https://www.rtings.com/tv/tests/inputs/input-lag). Not all are gaming modes.

My point was not really that TVs can do this with no input lag, just that the non-gaming-mode input lag is similar between TVs that have this "24p@60Hz" feature and those that do not. I should have been clearer about this.

outside of gaming mode they have something like 40-160 ms input lag exactly my point.

Okay. Let me rephrase your point as follows:

"You will only get true 24p from 60 Hz with these TVs if you use them outside low-input-lag mode. Therefore you cannot use that approach and have low input lag at the same time."

I agree with that statement. I will add, however, that this only matters if you care about input lag.

(That said, I have not seen actual evidence that TVs are unable to recover the 24p stream when running in low-input-lag mode. I agree that it makes sense though, so I'm happy to accept this assumption.)

Can we move past this now?

and to top it of they even show you that you have to use setting from interpolation. (i'm not saying you are getting a soap opera on your screen).

Sure.

i say it out laud now this feature comes from frame interpolation because it is needed for it. they got it for free.

Okay.

the reason this is hard to use for a HTPC user is here i repeat my self.
high input lag no PC mode.

This is not something everyone necessarily cares about, but sure, I agree.

and here some new ones it will die as soon as you move your mouse.

I think moving a very small blob of pixels like the mouse is unlikely to confuse the decimation process. Also the issue will disappear as soon as the mouse stops moving. But I get your point - any use of the UI can cause this problem. On the other hand, you wouldn't want to mess with the UI when playing a movie anyway - at native 24 Hz that would be painful too. The only scenarios where the UI is perfectly usable during playback is when running at 48/72/120/etc Hz or when using Smooth Motion.

usually loss of chroma resolution lot's of other processing quirks.

Agreed.

I think we're going somewhere :)

[zaemon]

Do you guys think it is worth investing in a CPU that can (software) decode HEVC 4K in order to leave some room for madVR GPU processing? I tested software decoding with my Threadripper and it handled it very easily thus I think with a Coffee Lake i5 or i7 I could use software decoding for not a huge pile of money. Probably better to get a faster GPU but I already got a GTX 1080 so not much room in that regard (until GTX 11xx maybe). Also I’m a big fan of software decode as I feel it provides a more smooth experience.

[madshi]

I still think using 2.4x would be more appropriate, direct 4x does take a little more GPU power than 2x and it would be consistent. Upscaling to 4x and then downscaling to 2.05x is not ideal.
So 2.4x, regardless of whether we're talking about "direct quad" or "double twice"?

FSE is now required for 10-bit HDR passthrough, from madVR to GPU to display? I didn't know FSE was a requirement.
FSE has always been a requirement to allow madVR to pass 10bit to the GPU driver (and further to the display), in all OSs. Doesn't matter if it's SDR or HDR. There's only one exception to this rule: When you activate the OS HDR switch, 10bit suddenly is also possible in windowed mode - but only if fullscreen.

The reason for all this is that without FSE everything runs through DWM (desktop window manager), and DWM is limited to 8bit. However, if you turn the OS HDR switch on, suddenly DWM runs in 10bit. Whether or not you switch the GPU control panel to 12bit doesn't make any difference here. The limitation to 8bit is in DWM, switching GPU control panel options doesn't help with that.

That said, dithered 8bit should work very well, even for HDR.

And one more thing...I assume the Windows OS is sending the metadata to the display untouched and isn't altering it to change the tone mapping, just like the private APIs do?
I don't know, I've no way to verify that.

IMHO the OS HDR switch is pure evil, and should be avoided at all cost, until Microsoft gets off their high horse and finally learns how to do things right. But that's just my personal opinion, of course.

This user wants to know if you can somehow send the PQ transfer function to the display to trigger HDR mode and use madVR's adjustable and sometimes superior tone mapping to replace the display's tone mapping? Sounds technically impossible, but would be nice.

Edit: I forgot about "process HDR content by using pixel shader math" as pointed out by Asmodian. How far would that get him? Are all of the YCbCr values tone mapped and stripped of illegal color values and then sent to the display to be tone mapped again? Does the metadata remain the same? Is this recommended?
"process HDR content by using pixel shader math" will tone map according to the settings you've chosen, and then pass the tone mapped result further to the display - still in HDR format, with updated metadata. As a result the display should switch to HDR mode, and hopefully disable its own tone mapping. However, many TVs are rather dumb, so they might not disable their internal tone mapping, even if it's no longer needed, which may result in some further gamma alterations. I can't predict the exact result, because it heavily depends on the display's behaviour, so every user has to simply try.

Where there some performance improvements?
I changed some "let madVR decide" settings for better performance, but the algos themselves shouldn't have changed their speed. If you can use NGU Medium now instead of Low, that's probably an improvement in the GPU drivers, I would guess...

I'm gonna have some more crazy dreams about this new algorithm. :D
:D

I have an issue with a few PAL-SD files in the following configuration:
-> MPC-BE + LAV (Hardware device to use: Automatic(Native)) + MadVR => File plays normally for a few seconds then screen turns completely green !! File keeps playing and I hear sound.
-> MPC-BE + LAV (Hardware device to use: (GPU selected)) + MadVR => File plays normally
Unfortunately I can' keep this configuration because the drop in performance is too big for 4K. Not that important but maybe you could look into this when you have the time. Thx !!
Same problem for me with 10-bit files. Disabling HW acceleration is not an option with HEVC for me unfortunately. And I still got this pink/green blinking at start when HW decoding is running.
D3D11 native support is still in somewhat "rough" shape. I wish I had more time for madVR development. I'm planning to improve D3D11 native support "soon".

A general question about achieving proper 24p cadence:

I recently realized after discussing it with someone else that neither 24 Hz nor Smooth Motion is required to achieve proper cadence with modern TVs/projectors. That's because they are capable of automatically recovering a 24p signal from a 24p@60Hz (3:2 pulldown) input, i.e. they are capable of IVTC/decimation.
I think you are a bit too optimistic here. You make it sounds as if all modern TVs/projectors could do that. Probably some can, but I highly doubt *all* can do that. I also don't know how reliable that mode is. E.g. my JVC projector is pretty bad even doing basic things as detecting video mode vs film mode deinterlacing. When I watch soccer and there are overlays, everything starts juddering. It's awful! So I'm not very confident that such a 60p -> 24p decimation algorithm in the TVs will be perfect.

Anyway...

Also, I seem to remember madshi saying at some point that madVR is not designed to generate a "perfect" 3:2 pulldown cadence when playing 24p@60Hz, which would prevent this solution from working. Is that true?
Yes, that is still the case. It's been on my to do list for ages to tune madVR to produce a repeatable 3:2 pattern when smooth motion is turned off, but I still haven't found the time to do that yet.

Do you guys think it is worth investing in a CPU that can (software) decode HEVC 4K in order to leave some room for madVR GPU processing? I tested software decoding with my Threadripper and it handled it very easily thus I think with a Coffee Lake i5 or i7 I could use software decoding for not a huge pile of money. Probably better to get a faster GPU but I already got a GTX 1080 so not much room in that regard (until GTX 11xx maybe). Also I’m a big fan of software decode as I feel it provides a more smooth experience.
I've also been a long time fan of software decoding. However, 4K HEVC decoding is *really* hard on the CPU, and it will depend on the bitrate and framerate, too. Low-bitrate 24fps HEVC is much easier to decode than high-bitrate and/or 60fps HEVC. I don't know which kind of CPU you need to decode even the most difficult HEVC videos. Maybe fast CPUs can do that today, I've no idea. But you'll probably get a bigger bang for the buck if you keep a budget CPU and upgrade your GPU instead.

Decoding on the GPU is usually done on a dedicated hardware circuit, so it shouldn't slow down pixel shader processing at all. The only problem with hardware decoding atm is that DXVA native decoding has all sorts of technical limitations, and D3D11 native decoding is still not in great shape in madVR. But hopefully D3D11 native decoding will improve in a future madVR build.

[Warner306]

FSE has always been a requirement to allow madVR to pass 10bit to the GPU driver (and further to the display), in all OSs. Doesn't matter if it's SDR or HDR. There's only one exception to this rule: When you activate the OS HDR switch, 10bit suddenly is also possible in windowed mode - but only if fullscreen.

The reason for all this is that without FSE everything runs through DWM (desktop window manager), and DWM is limited to 8bit. However, if you turn the OS HDR switch on, suddenly DWM runs in 10bit. Whether or not you switch the GPU control panel to 12bit doesn't make any difference here. The limitation to 8bit is in DWM, switching GPU control panel options doesn't help with that.

That said, dithered 8bit should work very well, even for HDR.


Now I am further confused. In one update, you said 10-bit output was now possible with windowed mode in Windows 10. I am only outputting in 8-bits, so I have never tested this.

I was talking to one user who has HDR passthrough set like this with an AMD card:

madVR (10-bits, HDR passthrough) -> GPU (10-bits) -> projector

His projector reports it is receiving 10-bits, RGB, HDR. If he changes the GPU to 12-bits, it reports 12-bits, RGB, HDR. So what is going wrong with this signal chain? He doesn't appear to be having any issues with banding, either.

Also, is it now possible to output 8-bit HDR passthrough with AMD cards, or are they still forced to use a complete 10-bit pipeline to get the HDR signal to the display?

I find I am always providing advice at two other forums, so it would be good to get this clear. Problems with FSE make windowed mode necessary for some users.

[madshi]

Now I am further confused. In one update, you said 10-bit output was now possible with windowed mode in Windows 10.
Oh wait, my bad. I got confused myself for a moment. I guess it's been too long that I worked on madVR.

So yes, 10bit output is supposed to be working with Windows 10 in windowed mode, regardless of whether the OS HDR switch is on or off. However, it only works if madVR is in fullscreen mode, because then the OS switches the GPU driver into "direct scanout" mode, which bypasses DWM. Thanks to that, the DWM 8bit limitation is no longer an issue. This "direct scanout" mode is currently only supported by Nvidia and AMD GPU drivers, though, but not by Intel GPUs, AFAIK.

[sauma144]

It seems there are some bugs in madVR 0.92.11 and 0.92.12.
Ranpha downgraded madVR in his latest LAV Filters Megamix setup.
https://www.videohelp.com/software/LAV-Filters-Megamix/comments#13925

[Siso]

It seems there are some bugs in madVR 0.92.11 and 0.92.12.
Ranpha downgraded madVR in his latest LAV Filters Megamix setup.
https://www.videohelp.com/software/LAV-Filters-Megamix/comments#13925

What sort of bugs?

[sauma144]

I don't know, I want to know if madshi is aware.

[Warner306]

So yes, 10bit output is supposed to be working with Windows 10 in windowed mode, regardless of whether the OS HDR switch is on or off. However, it only works if madVR is in fullscreen mode, because then the OS switches the GPU driver into "direct scanout" mode, which bypasses DWM. Thanks to that, the DWM 8bit limitation is no longer an issue. This "direct scanout" mode is currently only supported by Nvidia and AMD GPU drivers, though, but not by Intel GPUs, AFAIK.

You might want to look into the banding problems with Nvidia cards when set to HDR passthrough with 12-bits at the GPU. This could be the display, driver or madVR.

The only AMD user I've spoke to says 10-bit HDR passthrough seems to be fine without any banding, but I think he needs to run some tests to be certain.

[Asmodian]

So 2.4x, regardless of whether we're talking about "direct quad" or "double twice"?

Yes. I do not believe it is enough better to quadruple and then downscale to e.g. 2.3x, compared to doubling and then upscaling, to justify the performance hit. The small upscale looks very good after all, and the upscaling algorithm selector scales very well with GPU power (e.g. the luma quality selected).

I do see the rational of being more willing to use direct 4x, compared to double twice. However the performance difference is still significant enough that "if any upscaling required" is not a great default. On my GPU (a Titan XP) the time difference between direct 4x and 2x is similar to that between double twice and direct 4x. It is easy to tune a profile that works for doubling 1080p and quadrupling 720p, but then doesn't work for quadrupling slightly cropped 1080p. SSIM 1D100 downscaling exacerbates this issue. :)

Maybe set double again to 3.0x for "let madVR decide" to maintain the delta? Not that consistency is necessarily a bad thing. ;)

Do you guys think it is worth investing in a CPU that can (software) decode HEVC 4K in order to leave some room for madVR GPU processing?

No, I have a i9-7900K @ 4.7 GHz and I use software decoding for everything except 4K HEVC. It is easy for me to keep the decoding queues full watching UHD blurays, using either 32-bit or 64-bit LAV 0.71.0. The 140 Mbps jellyfish sample takes 32-50% CPU with 32-bit and 25-33% CPU with 64-bit. With 64-bit even the 400Mbps jellyfish sample only uses 40-60% total CPU.

However, hardware decoding adds almost nothing to the GPU's workload and the power/heat difference is significant. Also, both startup and seeking are more responsive when using hardware decoding, even without "delay playback start until render queue is full." On modern GPUs, like Nvidia's 10 series, 10-bit HEVC has pure hardware decoding, dedicated silicon for everything required, so the shaders madVR uses are idle. The only resources shared are the PCI-bus and some GPU memory bandwidth, both of with are usually not the bottleneck for madVR. Checking just now it seems my rendering times are identical between the two.

You might want to look into the banding problems with Nvidia cards when set to HDR passthrough with 12-bits at the GPU. This could be the display, driver or madVR.

The only AMD user I've spoke to says 10-bit HDR passthrough seems to fine without any banding, but I think he needs to run some tests to be certain.

I noticed this too but I assumed it was a problem with my TV when given content dithered to >8-bit. I do not see it even when sending 12-bit RGB when madVR is set to 8 bit. I also need to do more testing, the TV isn't off the hook yet. :p

I should also mention that the OSD reports it is using my SDR BT.2020 3DLUT when using "passthrough HDR content to the display" but it is not actually doing so (changing the 3DLUT does not change the output).

[stefanelli73]

I noticed yesterday too watching the film ALLIED, in the opening scene of the desert, looking at the blue sky the banding but coming out at 12 bit ... I use an AMD RX480 ....... something else like never when I get the subtitles I have a slowing down of the image and the two renderings rise in value?

[madshi]

It seems there are some bugs in madVR 0.92.11 and 0.92.12.
Ranpha downgraded madVR in his latest LAV Filters Megamix setup.
I don't know which bugs he's refering to.

You might want to look into the banding problems with Nvidia cards when set to HDR passthrough with 12-bits at the GPU. This could be the display, driver or madVR.
I've just tested this. With the Nvidia GPU driver set to 12bit, if I disable FSE mode and then switch MPC-HC to fullscreen mode, with the "smallramp.ytp" test pattern stretched to fill the whole screen, madVR OSD displays "D3D11 fullscreen windowed (10 bit)", and there are no banding problems. Then, if I move the mouse down to show the MPC-HC seekbar, I can see banding for a second, until madVR detects that playback is not fullscreen, anymore. In that moment madVR switches back to "D3D11 fullscreen windowed (8 bit)" and the banding goes away. If I move the mouse back up, the seekbar disappears, madVR one second later switches back to "D3D11 fullscreen windowed (10 bit)" and no banding.

So as far as I can tell, it works perfectly on my PC. This is with 390.65 drivers. Maybe there's a bug in newer drivers? I don't know.

P.S: I've only tested this with my SDR test pattern. Maybe things are different in HDR passthrough mode? I don't really know how to test it there, though, because banding problems are easy to see with my test pattern, but harder to see with true HDR content.

Yes. I do not believe it is enough better to quadruple and then downscale to e.g. 2.3x, compared to doubling and then upscaling, to justify the performance hit. The small upscale looks very good after all, and the upscaling algorithm selector scales very well with GPU power (e.g. the luma quality selected).

I do see the rational of being more willing to use direct 4x, compared to double twice. However the performance difference is still significant enough that "if any upscaling required" is not a great default. On my GPU (a Titan XP) the time difference between direct 4x and 2x is similar to that between double twice and direct 4x. It is easy to tune a profile that works for doubling 1080p and quadrupling 720p, but then doesn't work for quadrupling slightly cropped 1080p. SSIM 1D100 downscaling exacerbates this issue. :)

Maybe set double again to 3.0x for "let madVR decide" to maintain the delta? Not that consistency is necessarily a bad thing. ;)
Ok.

I should also mention that the OSD reports it is using my SDR BT.2020 3DLUT when using "passthrough HDR content to the display" but it is not actually doing so (changing the 3DLUT does not change the output).
Looks like a bug, thanks.

I noticed yesterday too watching the film ALLIED, in the opening scene of the desert, looking at the blue sky the banding but coming out at 12 bit ... I use an AMD RX480 .......
Could be anything, could be hard coded into the movie. Try setting madVR to 8bit, does the banding go away?

[stefanelli73]

Actually I've tried only 12 bit today I will go to 10bit and 8bit ....... Madshi you have a solution to the problem that I have subtitles? In practice when forced subtitles come out in a scene or when I use subtitles normally the image slows down and the ms of the two renderings increase from 30ms up to 110ms, when the subtitles disappear it returns all right.....my player is JRIVER.

[kalston]

Actually I've tried only 12 bit today I will go to 10bit and 8bit ....... Madshi you have a solution to the problem that I have subtitles? In practice when forced subtitles come out in a scene or when I use subtitles normally the image slows down and the ms of the two renderings increase from 30ms up to 110ms, when the subtitles disappear it returns all right.....my player is JRIVER.

JRiver's subtitle engine is quite demanding for some reason... On my Surface 3 (Atom CPU/IGPU) it makes DVDs unwatchable unless I give up on quality upscaling completely (blu-rays are ok because no upscaling needed other than chroma). MPC's subtitle engine is fine on the other hand, doesn't seem to hurt rendering times.

On my desktop though, no difference between the 2 in rendering times (i7 8700k/1080 ti).

[brazen1]

Hi madshi. Re: Banding and your 390.65 drivers.
NVidia introduced a pretty significant Windows audio bug starting with 390.65 through the present. I don't think any of these drivers retain a 12bit setting after a reboot either. All drivers prior to 390.65 have various dynamic HDR switching problems except 385.69 and 385.28. Those two and only those two are HDR switching and Audio switching correct. They also retain a 12bit setting after a reboot, not that it matters.

Nvidia does not offer an RGB 10bit setting. Only 8 or 12. So, I always selected 12bit believing it would dither down to 10bit as needed. Then I discovered banding on the UHD HDR title Allied as one example. I presented the example quirk here. After testing by a few members it was determined some displays handle 12bit better than others because they are native 12bit. They get no banding using 12bit. This leads me to believe the banding is not built in to the title. My Samsung native 10bit for example handles it poorly and introduces banding. If NVidia provided a 10bit setting I could simply use that but they don't. So, I'm required to use 8bit. The banding is no longer present. Of course we'd all like to use 10bit for 10bit sources like UHD HDR on our 10bit displays with a perfect chain but we are limited to 8bit until NVidia introduces RGB 10bit. This I don't count on.

Warner quizzed an AMD user about this banding quirk suggesting he set his driver to 10bit since AMD offers RGB at 10bit. He reported no banding using 10 or 12bit. Perhaps his display is 12bit native or he really isn't looking or admitting to banding proud of his new setup? Today a user here reports AMD banding with 12bit although again we don't know if this display is native 10bit causing the banding nor results at a 10bit setting.

The point is, can madVR work around NVidia's fault for not supplying RGB 10bit which affects native 10bit (not 12bit) displays? I wouldn't ask if I thought NVidia would eventually step up but the fact is, they've NEVER offered it afaik. If we could get detailed positive confirmations from AMD users who have no banding using 10bit settings and displays, then the fix could be relatively simple; Dump NVidia and concentrate on AMD or use a 12bit display. Personally, given the price gouging going on, I will continue to use what I have at 8bit and replacing my display is out of the question at this point. I read the eye is not going to discern 8bit vs 10bit anyway but I have no way of concluding that for myself. I will trust that coming from you if indeed that is your opinion. I assume many more colors within the gamut would be visible especially blends which are now bands of ugliness.

We all realize you are concentrating on other things and don't expect anything anytime soon if ever. Just some ammo to consider when and if you find any of this worthy of your powers. Thank you as always for providing what you have. If you never update madVR again, it's still a brilliant software just as it is.

[mclingo]

i'll test it on my AMD rig, what do I need to look at exactly?, full full chain is 10 bit so I should spot it if its there.

[Warner306]

The only way to understand the difference in bit depths is to find a grayscale test pattern. Set madVR to 8-bits and 10-bits. The gradient should get smoother at 10-bits, but it doesn't. In fact, the effect of dithering at 8-bits can make the gradient look smoother than 10-bits, but with a little more noise. And this noise is difficult to notice. That is all the bit depth does; it makes things smoother, not more colorful.

There are no 12-bit flat panels (maybe projectors), but there are displays which handle 12-bit inputs more gracefully. This would depend on whether dithering is used and the quality of that dithering.

[madshi]

Madshi you have a solution to the problem that I have subtitles? In practice when forced subtitles come out in a scene or when I use subtitles normally the image slows down and the ms of the two renderings increase from 30ms up to 110ms, when the subtitles disappear it returns all right.....my player is JRIVER.
JRiver's subtitle engine is quite demanding for some reason... On my Surface 3 (Atom CPU/IGPU) it makes DVDs unwatchable unless I give up on quality upscaling completely (blu-rays are ok because no upscaling needed other than chroma). MPC's subtitle engine is fine on the other hand, doesn't seem to hurt rendering times.

On my desktop though, no difference between the 2 in rendering times (i7 8700k/1080 ti).
It's really the rendering times in madVR which slow down with the JRiver internal subtitle renderer? I'm not sure why that would happen, to be honest. How high is the CPU usage when that occurs?

Nvidia does not offer an RGB 10bit setting. Only 8 or 12. So, I always selected 12bit believing it would dither down to 10bit as needed. Then I discovered banding on the UHD HDR title Allied as one example.
There can be multiple causes of banding. It could be hard coded in the source. It could be a bug in the GPU drivers. It could be a dozen other things.

-------

Just found out that the Nvidia GPU drivers have a bug in Windows 10 which stop 10bit from working properly in fullscreen windowed mode, but only when using HDR passthrough. Works fine without HDR passthrough. Works fine in FSE mode.

The next madVR build will force 8bit in HDR fullscreen windowed mode for Nvidia GPUs. For now, to workaround this issue, either use FSE mode, or manually switch the madVR monitor settings to 8bit.

[kalston]

It's really the rendering times in madVR which slow down with the JRiver internal subtitle renderer? I'm not sure why that would happen, to be honest. How high is the CPU usage when that occurs?

Yeah rendering times, I just checked.

On the files I tried (DVD and blu-ray rips I made) I got an extra ~10ms rendering time from enabling subtitles alone (and have to restart the playback to reset it, hiding the subtitles isn't enough). It's hard to measure CPU usage on this laptop though, CPU clock keeps going up and down etc. But without subs, I was at 15-20% CPU usage with very low clocks, enabling subs doesn't seem to increase it by that much, maybe 5-10%.

Probably just a JRiver issue with some specific hardware though (Atom x7-Z8700 in my case). On my desktop enabling subs adds maybe 0.3ms to rendering times, if that...

[pankov]

P.S: I've only tested this with my SDR test pattern. Maybe things are different in HDR passthrough mode? I don't really know how to test it there, though, because banding problems are easy to see with my test pattern, but harder to see with true HDR content.
A few days ago I found a very good HDR video to test the banding in Mehanik's HDR10 calibration and test patterns set that can be found here
http://www.avsforum.com/forum/139-display-calibration/2943380-hdr10-test-patterns-set.html
In the "04. Colors" folder there is a file called "01. Banding_Rotating-gradients_23.976.mp4" and with it I think I found an issue ... or it's technical limitation? ... in madVR's HDR to SDR conversion by using pixel shader math.
It looks terrible in the blue a little bit better in the magenta and almost OK in the green and yellow.
I know that this conversion/process is not lossless but this looks horrible and I simply can't believe that it's by design.

madshi,
a while ago there was a quite detailed/heated discussion how should we configure madVR in regards to the display calibration options. In the past when we had only SDR content it was widely accepted the the best choice would be to select BT.709 and "pure power curve" 2.20 ... or 2.40 depending on the display/viewing conditions ... and then correctly configure/calibrate the display to the same params and let madVR do the needed conversions in the rare cases of SMPTE C/PAL/etc. content.
But with the introduction of HDR and wider color gamut displays (usually not wider than DCI-P3) I'm starting to doubt this rule. Especially having in mind that the TVs/displays usually switch their color mode for HDR content ... and I think that this is correct since we don't want to use the much wider color space but still send data in a subset of it ... and in 8bit ... which might introduce banding.
So what is madVR doing when it's rendering HDR content in BT.2020 container with usually up to DCI-P3 data (99.99% of the HDR content) and I have my display set to "already calibrated" to BT.709/2.40? Is it trying to squeeze the content in the narrow BT.709 space or it presumes that if I want HDR content (in passthrough mode) than my display should accept and be calibrated correctly to BT.2020?
Don't we need a second calibration config for HDR (wide color gamut) content?
... or have I totally lost it and talking nonsense now?

P.S.
Can someone ... or you madshi ... remind me why when accessing madVR's filter properties from the player there is a need to open this small window with madVR's version and the two buttons where the user has to click one more time (and one more to close it)? Isn't it possible to directly open the settings from madHcCtrl.exe as it happens when I press the "Edit Settings" button? If it's some kind of a DirectX requirement to have such a window isn't it possible to just briefly create the window, internally call madHcCtrl and then automatically close the small window?

[Manni]

Just found out that the Nvidia GPU drivers have a bug in Windows 10 which stop 10bit from working properly in fullscreen windowed mode, but only when using HDR passthrough. Works fine without HDR passthrough. Works fine in FSE mode.

The next madVR build will force 8bit in HDR fullscreen windowed mode for Nvidia GPUs. For now, to workaround this issue, either use FSE mode, or manually switch the madVR monitor settings to 8bit.

Can you elaborate on this bug? Is it there with all driver versions, or only recent ones? I use HDR passthrough in 12bits with Windows 10 and there is no banding that I can see in fullscreen windowed mode (I don't use FSE except in 3D). My projector is native 12bits though, with 12bits support from the inputs to the panels.

I have tested the "Allied" clip mentioned in HDR passthrough, there is zero banding here.

As you know recent drivers seem to have borked levels (not sure when that happened), so I've reverted to 385.28 which is the last driver where everything works (12bits selectable in custom refresh mode, ASIO4All compatibility, and proper levels). The only bug (HTPC-wise) that I'm aware of with this version is in Dolby Atmos speaker config, the SBs and the SRs are inverted. I use 7.1 so I don't mind.

[el Filou]

A few days ago I found a very good HDR video to test the banding in Mehanik's HDR10 calibration and test patterns set that can be found here
http://www.avsforum.com/forum/139-display-calibration/2943380-hdr10-test-patterns-set.html
In the "04. Colors" folder there is a file called "01. Banding_Rotating-gradients_23.976.mp4" and with it I think I found an issue ... or it's technical limitation? ... in madVR's HDR to SDR conversion by using pixel shader math.
It looks terrible in the blue a little bit better in the magenta and almost OK in the green and yellow.
I know that this conversion/process is not lossless but this looks horrible and I simply can't believe that it's by design.Just had a look at that video, and it renders much better when unchecking 'preserve hue' in madVR's HDR processing settings.

[madshi]

Yeah rendering times, I just checked.

On this DVD I used (Dersu Uzala), I got an extra ~10ms rendering time from enabling subtitles alone (and have to restart the playback to reset it, hiding the subtitles isn't enough). It's hard to measure CPU usage on this laptop though, CPU clock keeps going up and down etc. But without subs, I was at 15-20% CPU usage with very low clocks, enabling subs doesn't seem to increase it by that much, maybe 5-10%.

Probably just a JRiver issue with some specific hardware though (Atom x7-Z8700 in my case). On my desktop enabling subs adds maybe 0.3ms to rendering times, if that...
Strange. I'm not sure exactly how JRiver draws subtitles. I think it uses one of my OSD interfaces, but I'm not sure which one.

Can you elaborate on this bug? Is it there with all driver versions, or only recent ones?
I don't know, I've only tested the one driver I have currently installed (390.65). It's 100% reproducable for me with this driver. I get banding free 10bit output in SDR, but as soon as I activate Nvidia's HDR passthrough, I get banding when I try to render to 10bit.

A few days ago I found a very good HDR video to test the banding in Mehanik's HDR10 calibration and test patterns set that can be found here
http://www.avsforum.com/forum/139-display-calibration/2943380-hdr10-test-patterns-set.html
In the "04. Colors" folder there is a file called "01. Banding_Rotating-gradients_23.976.mp4" and with it I think I found an issue ... or it's technical limitation? ... in madVR's HDR to SDR conversion by using pixel shader math.
It looks terrible in the blue a little bit better in the magenta and almost OK in the green and yellow.
The official build has a bug which can sometimes introduce a bit of banding when doing HDR -> SDR conversion. That's already fixed in this test build from AVSForum:

http://madshi.net/madVRhdrTest5.rar

This build still shows some weirdness for the blue, but the other colors should be fine. I'm not completely sure why the problem with blue happens, will have to investigate.

a while ago there was a quite detailed/heated discussion how should we configure madVR in regards to the display calibration options. In the past when we had only SDR content it was widely accepted the the best choice would be to select BT.709 and "pure power curve" 2.20 ... or 2.40 depending on the display/viewing conditions ... and then correctly configure/calibrate the display to the same params and let madVR do the needed conversions in the rare cases of SMPTE C/PAL/etc. content.
But with the introduction of HDR and wider color gamut displays (usually not wider than DCI-P3) I'm starting to doubt this rule. Especially having in mind that the TVs/displays usually switch their color mode for HDR content ... and I think that this is correct since we don't want to use the much wider color space but still send data in a subset of it ... and in 8bit ... which might introduce banding.
I've said it a thousand times. 8bit doesn't introduce banding. Even 4bit doesn't introduce banding. That's what we have dithering for.

HDR calibration is a mess. IMHO the best workaround is probably to let madVR convert HDR to SDR, and then you can just run the converted SDR video through a conventional SDR 3dlut.

So what is madVR doing when it's rendering HDR content in BT.2020 container with usually up to DCI-P3 data (99.99% of the HDR content) and I have my display set to "already calibrated" to BT.709/2.40? Is it trying to squeeze the content in the narrow BT.709 space or it presumes that if I want HDR content (in passthrough mode) than my display should accept and be calibrated correctly to BT.2020?
That depends. Are we talking about passing HDR through to the display? Or letting madVR convert HDR to SDR?

Can someone ... or you madshi ... remind me why when accessing madVR's filter properties from the player there is a need to open this small window with madVR's version and the two buttons where the user has to click one more time (and one more to close it)? Isn't it possible to directly open the settings from madHcCtrl.exe as it happens when I press the "Edit Settings" button?
Just double click on the madHcCtrl tray icon.