madVR - high quality video renderer (GPU assisted)

[James Freeman]

Anyone else experience "render queue" does not fill up?
Mine stays at 3-5/8.

[YxP]

With 88.2 starting a clip on screen 1 and moving it to screen 2 crashes the player (MPC-HC) every time. Windows 8.1 64bit windowed mode d3d11, using 3dlut. 88.1 is fine.

[nevcairiel]

it seems to me it may even create unecessary latencies or add incaccuracies compared to the source.

If you use HDMI to a modern TV, chances are that its already using 10 or even 12-bit for the HDMI picture. My Sony TV reports a 12-bit input for the HDMI connection on 1080p, which means the GPU always sends a 12-bit image, even if the desktop is only rendered in 8-bit.

The same may be true for DisplayPort connections, but none of my monitors give such information.
Plus, a monitor, and especially TV, may process the image at all times anyway.

[huhn]

d3d11 present a frame every v-sync works fine on my nvidia system no problems at all. no tearing or other issues yet nothing.

edit: found a bug.
with a dual monitor system madVR unloads the windows calibration of the main display if it leaves FSE D3D11 fullscreen on the second monitor.
this only happens with 9 or more bit.

[omarank]

Direct3D doesn't support 12bit output. 16bit is supported, but in a weird way and different GPUs produce different results. Rather weird results, sometimes. So I decided not to support 16bit output for now.
Hmm, I hope they fix 16 bit output in Windows 10.


Seekbar doesn’t appear in FSE mode D3D11 presentation after a couple of seeks. I am using Windows 8.1 and it happens with x86 madVR build only.
Can't reproduce that here. It just doesn't show? And this problem did not occur with madVR v0.87.21?
As reported by others, seekbar issue is fixed in v0.88.2.

[madshi]

For the record: It happens also in FSE.
Oh, that's interesting. And this problem only occurs with D3D11, but not with D3D9?? Have you tried turning your PC off for a minute, then turn it back on? Almost sounds like a hardware or GPU driver problem. But if it's a hardware problem it should occur in D3D9, too. So it's most likely to be a GPU driver problem.

I have tested a few things out, results below

Resizing mpc-be window with mouse: No difference between 9 and 11, both seem to stay on a static image (last frame that was shown, being scaled basically) until I stop mouse movement. Not sure should D3D11 immediately / continuously output image while my mouse is moving or maybe this is the players fault? Not a big issue for me either ways, but no difference between the two here.

Moving player window around: No difference both look perfectly smooth to me. No drops or glitches with either.

Switching between FSE and Windowed: I don't notice a difference, both seem very very fast for me, there is that slight flicker where the screen goes black for a few milliseconds, but I guess thats just how it has to be. Speed wise both are equally as fast to my eyes.

If I spot any differences I'll post back.
Ok, thanks.

What is overlay mode? Is it not Direct3D?
Is there any way to go Overlay in window but d3d11 in FSE?
Overlay is D3D9. I won't mix D3D9 with D3D11. Either one or the other.

Sorcery!
This is incredibly new and alien to me!
I've not used Aero since Vista came out.
:D

FWIW, I hated it when I heard that Aero couldn't be turned off in Windows 8. But I have to say, it really works so well in Windows 8 that I never had a need to turn it off. In Windows 7 Aero sometimes has problems, unfortunately...

Just realized something that, in retrospect, is pretty obvious but just in case anyone else is having high present times:

I had my Nvidia control panel "Max Pre-Rendered Frames" set to 1 to reduce input lag in certain online games.

Changing this to use application setting fixed the present times. This setting had no effect in using d3d9 but apparently does for dx11.
Good find. Funny enough, I found exactly the same thing on my HTPC at the same time as you. I had it set to 3, though. Don't even know why.

0.88.2
"present a frame for every VSync"

Confirmed fix working.
Skipping time will no longer cause presentation glitches.
Great!

Anyone else experience "render queue" does not fill up?
Mine stays at 3-5/8.
Do you have an NVidia GPU? If so, in your NVidia control panel set "Max Pre-Rendered Frames" to "application controlled".

With 88.2 starting a clip on screen 1 and moving it to screen 2 crashes the player (MPC-HC) every time. Windows 8.1 64bit windowed mode, using 3dlut. 88.1 is fine.
Strange. Does that happen with D3D11, only, or also with D3D9? Do you get a madVR crash report box?

d3d11 present a frame every v-sync works fine on my nvidia system no problems at all. no tearing or other issues yet nothing.
Good.

edit: found a bug.
with a dual monitor system madVR unloads the windows calibration of the main display if it leaves FSE D3D11 fullscreen on the second monitor.
this only happens with 9 or more bit.
What is a "windows calibration"? Do you mean the GPU gamma ramps? This bug sounds complicated. Can you add it to the bug tracker, please? I won't have time to fix it quickly.

[aufkrawall]

Oh, that's interesting. And this problem only occurs with D3D11, but not with D3D9?? Have you tried turning your PC off for a minute, then turn it back on? Almost sounds like a hardware or GPU driver problem. But if it's a hardware problem it should occur in D3D9, too. So it's most likely to be a GPU driver problem.

Ha, D3D9 FSE gives me lots of presentation glitches (windowed seems to work fine).
Seems like there's definitely something wrong with this particular driver on Windows 10. I could install a non WDDM 2.0 driver and see if situation improves.

[huhn]

What is a "windows calibration"? Do you mean the GPU gamma ramps? This bug sounds complicated. Can you add it to the bug tracker, please? I won't have time to fix it quickly.

i loaded a ICC file with the windows color management system.
i guess that's the GPU gamma ramps.
it is way easier to reproduce this issue. but it is added in the tracker.

[YxP]

Strange. Does that happen with D3D11, only, or also with D3D9? Do you get a madVR crash report box?

Did quick testing, it happens also with D3D9 and with or without 3dlut. The crash is instant and doesn't provide the report box.

[aufkrawall]

Ha, D3D9 FSE gives me lots of presentation glitches (windowed seems to work fine).
Seems like there's definitely something wrong with this particular driver on Windows 10. I could install a non WDDM 2.0 driver and see if situation improves.
With Geforce 350.12 driver, the tearing problem is entirely gone.

However, in FSE D3D11, renderer queue is almost empty (2-4 / 8).
In windowed mode or D3D9 FSE, it's stable 7-8 / 8.

[XMonarchY]

10 bit output needs FSE d11.
you have set it under your device properties.
in FSE d11 you will see a line in the OSD like ~ fullscreen exclusive mode, 10 bit



ok i try it again.
don't use a smpte c 3d LUT in bt 709 line you will get wrong colors.
use a smpte c 3d LUT in smpte C line. i know that is broken right now so you can't do that. are you creating a bug entry in the bug tracker? i can do that just say so.
so in the meanwhile you have to use a bt 709 3D LUT. just take your measuring and create a bt 709 3D LUT and add this in bt 709 so everything should work fine. you can addionally add a smpte c 3D LUT now. but this is not needed madVR will make sure the rest is ok.


leave lavfilter at defaults.

madVR is outputting RGB and RGB is kind of 4:4:4.

But I do get the right colors. I verified with HCFR Calibration when I placed Rec.601 3DLUT into Rec.709 line and selected Rec.709 in madTPG for verification. 3DLUT already sets the colors for you. I don't think madVR messes with them...

[luk008]

In 0.88.2, madVR don't restore the original display refresh rate after the player is closed. If I choose "when media player leaves full screen" the player crashes when I leave fullscreen.

Windows 8.1 x64
MPC-HC x64
R9 270

[XMonarchY]

OK, more updates:

I managed to get 720p video to run fine on my 1080p display using old madVR 87.21 settings without Quadrupling. BUT now I cannot run 1080p content on 1080p monitor (with doubling/quadrupling disabled) using the same settings as in madVR 0.87.21. I get consistent and constant frame drops, delays, etc. I tried with DirectX 11 and without, Exclusive mode and without.

Am I the only one who's getting severe performance problems with the latest releases??? I went back to 0.82.21 release and all is back to normal, no issues!

[cyberbeing]

Strange. You do have the Windows 7 Platform Update installed, right?
Yes I do. For whatever reason the render queue just seems hard limited to ~6 and doesn't fill. The strange part as mentioned, is that if I lower the Present in Advance frames from 16 to say 8, the render queue then won't fill beyond ~4. Only occurs in Windowed mode. Neither flush, Use Separate Device for Presentation, or Present Every Vsync settings make any difference. Occurs with madVR reset defaults + DX11 Windowed as well.

Aside from the Render Queue not filling properly in DX11 Windowed, playback seems fine with normal GPU load. I've not seen any presentation glitches, dropped frames, or other playback anomalies with DX11 Windowed while this occurs.

Same issue occurs in 0.88.1 & 0.88.2

[tobindac]

Wrong. Source can be even 4 bit. The trick is madVR converts source YUV > RGB in 16fp. Then it rounds 16fp to either 8int or 10int and adds dither for output. Needless explain in higher output bitdepth we keep more processed data. If display has 16fp processor with perfect dithering, it would be best to output 16fp to it from madVR. Its all about internal conversions and transport, it has nothing to do at all to source and panel bitdepths.

I mentioned that possibility in the text you deleted from that quote. I suspected that. Madvr may use it for conversions internally and get a minor benefit (are you a co-programmer of this by the way, because it's closed source).

To what extend that can be ever noticed is another question.

I wouldn't be surprised if it's humanly impossible to see.

[tobindac]

Anyone else that gets a big blank delay of about 2 seconds once 10bit output is on? It happens at the moment when going to full screen. The GPU is an R9 290 and the monitor a regular 8bit IPS.

[LoRd_MuldeR]

With 88.2 starting a clip on screen 1 and moving it to screen 2 crashes the player (MPC-HC) every time. Windows 8.1 64bit windowed mode d3d11, using 3dlut. 88.1 is fine.

Same here with DVBViewer and Windows 7. Not using 3dlut.

(I tried "debug mode", but it crashes instantly)

[madshi]

it is way easier to reproduce this issue. but it is added in the tracker.
Thanks.

Did quick testing, it happens also with D3D9 and with or without 3dlut. The crash is instant and doesn't provide the report box.
Ok, can you please add this to the bug tracker?

However, in FSE D3D11, renderer queue is almost empty (2-4 / 8).
In windowed mode or D3D9 FSE, it's stable 7-8 / 8.
In the NVidia control panel, have you set "Max Pre-Rendered Frames" to "application controlled"?

In 0.88.2, madVR don't restore the original display refresh rate after the player is closed. If I choose "when media player leaves full screen" the player crashes when I leave fullscreen.

Windows 8.1 x64
MPC-HC x64
R9 270
Ok, can you please add this to the bug tracker?

I managed to get 720p video to run fine on my 1080p display using old madVR 87.21 settings without Quadrupling. BUT now I cannot run 1080p content on 1080p monitor (with doubling/quadrupling disabled) using the same settings as in madVR 0.87.21. I get consistent and constant frame drops, delays, etc. I tried with DirectX 11 and without, Exclusive mode and without.

Am I the only one who's getting severe performance problems with the latest releases??? I went back to 0.82.21 release and all is back to normal, no issues!
I already replied to you some pages ago, but you ignored my reply.

Yes I do. For whatever reason the render queue just seems hard limited to ~6 and doesn't fill. The strange part as mentioned, is that if I lower the Present in Advance frames from 16 to say 8, the render queue then won't fill beyond ~4. Only occurs in Windowed mode. Neither flush, Use Separate Device for Presentation, or Present Every Vsync settings make any difference. Occurs with madVR reset defaults + DX11 Windowed as well.

Aside from the Render Queue not filling properly in DX11 Windowed, playback seems fine with normal GPU load. I've not seen any presentation glitches, dropped frames, or other playback anomalies with DX11 Windowed while this occurs.

Same issue occurs in 0.88.1 & 0.88.2
In the NVidia control panel, have you set "Max Pre-Rendered Frames" to "application controlled"?

[tFWo]

0.88.2 Win8.1x64

MPC-HC (32bit) fails to exit properly. I have to end task manualy. Also when I'm just closing the opened file, MPC freezes and its window turns black. This didn't happen with previous versions (0.88, 0.88.1).

Presentation glitches still happen in windowed mode when seeking or unpausing with d3d11, even with the new "present a frame" option turned on. They also still happen in fullscreen when seeking, but only when I click really fast a couple of times on the seek bar.

[Schwartz]

Running with a backported Windows 10 AMD 'VSR' driver from guru3d.com, NNEDI3 works once again for chroma upscaling as well as image doubling. Though I'm still wondering why Omega Catalyst 14.12 broke the way it did on 64-bit.

[madshi]

MPC-HC (32bit) fails to exit properly.
Which MPC-HC version?

Presentation glitches still happen in windowed mode when seeking or unpausing with d3d11, even with the new "present a frame" option turned on. They also still happen in fullscreen when seeking, but only when I click really fast a couple of times on the seek bar.
Do they happen only at the moment when seeking or unpausing? Or do they continue to pile up during playback? If they only occur at the moment when you seek/unpause, there's nothing to worry about.

[MS-DOS]

Freeze reported doesn't say anything. FWIW, I can let MPC-HC sit minimized with D3D11 on my PC without any problems. Zero frame drops. Which OS were you on again? If win7: Do you have Aero disabled or enabled?

When the next build is released, can you upload a debug log for me with that, just with frame drops caused by running in minimized state, doesn't have to be the freeze. Doesn't also have to be 30 seconds. Just long enough so that I can see that there's any kind of trouble in minimized state...

PM'ed you a log.

Another find: If I start playback (MadVR not loaded) in D3D11 with presented frames set to exactly 1, it falls back to D3D9 new path. And if I set it to 1 from anything higher while it's already playing in D3D11 then guess what happens - instantly about a hundred of presentation glitches followed by a totally frozen video, while the sound continues to play normally.

[cyberbeing]

In the NVidia control panel, have you set "Max Pre-Rendered Frames" to "application controlled"?
Yes I do.

[tFWo]

Which MPC-HC version?


Do they happen only at the moment when seeking or unpausing? Or do they continue to pile up during playback? If they only occur at the moment when you seek/unpause, there's nothing to worry about.

Ah, it was 1.7.8.152. Downloaded 1.7.8.162 and it doesn't happen anymore :)

Glitches only happen in those moments, they don't accumulate. :thanks:

[dbcooper]

16.7mil is by definition the 8bit RGB because (8bit, 8bit, 8bit) -> 16.7mil. 24bit RGB would be an absolute overkill. 10bit is already very hard to justify for regular movie screenings since most people would not see any difference above 6bit (try the madvr settings and set it low, 1bit and 2bit are hilarious, they remind of old video games).



Can anyone confirm that makes sense? Because it seems to me it may end up either adding latency for no reason or even "rounding" to an even more inaccurate representation of the original.

When the DCI standards were developed, tests were made on audience ability to see differences in luminance gradient levels. IIRC, many could see differences equivalent to 10bit gradients, and some could see 11bit gradient differences. Accordingly, the DCI standards require 12bit output.

Another benefit of 10bit output from MadVR is with the use of 3D LUTs. With RGB gamma ramps or a 3DLUT, you need to change the spacing between RGB values from the default unity, to values that minimize display error. In doing so, banding can be introduced (you only have 0 to 255 to represent all 256 levels in 8bit). Using 10bit output to a 10bit display for 8bit material can reduce this banding, and give a better calibration.

[Sparktank]

I previously thought an issue I was having was from MPC-HC, so I decided to downgrade madVR to 0.87.21 and found out I wasn't having the same issues I have now since 0.88.x.

Taken (and modified) from MPC-HC thread:


1.7.8-152-g3f78c2a
1.7.8-162-g0c83d4e
All x86 versions (as I often use Avisynth+FFDShow/SVP).

madVR 0.88.x

Switching to fullscreen on secondary monitor (HDTV) will crash MPC-HC instantly.
This is with/without D3D11 and with/without Error Diffusion dithering. Bit depth also makes no difference.
Even with the new default settings in .2 it still crashes MPC-HC.

If I change settings to launch video in fullscreen on secondary monitor, it won't crash and will play normally.
However, if I exit FSE, player crashes.

Sometimes MPC-HC stays in process after it crashes. I can't figure out the conditions for this. I remember one time I opened task manager and there were nearly a dozen instances of MPC-HC that didn't exit process. The icons in task tray were all gone, however.

Selecting any other renderer except madVR will give me a green screen this time (unlike earlier situation where I had a white screen).

[Sparktank]

Ah, it was 1.7.8.152. Downloaded 1.7.8.162 and it doesn't happen anymore :)

I actually haven't tried .162 since I downgraded. I should check this first.
Glad I'm not the only one experiencing this.

Will upgrade to 162 and report back.

.152 definitely has crashes with 0.88.2.
Both .152 + .162 crash on 0.88.1.

[VenomousNinja]

Presentation glitches gone (0.88.2) on Win 7 x64,MPC-BE with new fix. They only appear with "settings" menu brought from the tray to the top of playing video.So possibly some glitch reports could be post "can I play with settings?" effect. Just a thought...

[Sparktank]

:rolleyes: I supposed I should spend more time reading a lot of the posts before posting.

.162 does not crash when switching to FSE on secondary monitor.
Nor when you exit FSE on secondary monitor.
D3D11, no D3D11, it all works on .162 now.

Time for more coffee. :cool:

[tobindac]

many could see differences equivalent to 10bit gradients, and some could see 11bit gradient differences.

I do not believe this claim of the movie industry without further evidence. Do you have any idea how many colors are in 10bit and how many in 11bit? 10 Already has more than 1 billion, that's already 64 times more than 8bit!

Start by doing some tests between 7bit and 8bit.

If those two are hard to see, imagine 10->11bit!

[huhn]

But I do get the right colors. I verified with HCFR Calibration when I placed Rec.601 3DLUT into Rec.709 line and selected Rec.709 in madTPG for verification. 3DLUT already sets the colors for you. I don't think madVR messes with them...

you verified a smpte C calibration treated as bt 709 with bt 709.

if you got correct results fine but... that's not how it should work.

[XMonarchY]

Madshi, sorry, I did not see your answer, but I previous posted my exact settings. Here they are again:
3DLUT
Artifact Removal = Low for default, Medium for fade in/out + Shiandow's Deband with default settings
Image Enhancement = none
Chroma Upscaling = NNEDI3 32n + SuperRes Filter with default settings
Image Downscaling = Catmull-Rom + AA + Scale in Linear Light
Image Doubling = NNEDI3 32n (set to Always) if the content is sub-1080p on my 1080p monitor/TV
Image Upscaling = Jinc 3tap + AA
Image Refinement = SuperRes with High setting for 1080p content only
D3D11 & Exclusive mode = disabled

Problems:
Image Quadrupling = severe frame drops for sub-1080p content, even when SuperRes is disabled for Image Refinement and Chroma Upscaling. Used to use-able (both Chroma and Luma) in madVR 0.87.21 without frame drops.
Image Refinement = SuperRes can only be enabled IF Chroma Upscaling SuperRes filter is NOT activated for sub-1080p content, regardless of High/Medium setting selected for Image Refinement. For 1080p content, both Filter and Refinement can use SuperRes without problems.
D3D11 = severe presentation glitches, even without frame drops and/or delays.

Some questions I had:
1. Why is Quadrupling creating frame drops in the latest version of madVR, but not in the older version, where I had both Luma and Chroma Doubling and Quadrupling, all set to NNEDI3 32n? This occurs regardless of whether I use SuperRes Chroma Upscaling filter and/or SuperRes in Image Refinement. I tried with no SuperRes enabled anywhere, but Quadrupling still produced severe frame drops.
2. Why can I not enable SuperRes in both places - Image Refinement and Chroma Upscaling for sub-1080p content? Is it just too heavy on my system?
3. What is the benefit of using D3D11?
4. What are D3D11 presentation glitches? They often occur without dropped and/or delayed frames. Should they be ignored?
5. Is there any point to use D3D11 "present a frame for every VSync" option if one is running ReClock?
6. Are there any comparisons of how SuperRes Chroma Upscaling filter and SuperRes Image Refinement compare against each other?

[aufkrawall]

In the NVidia control panel, have you set "Max Pre-Rendered Frames" to "application controlled"?

No, it was set to 1. With app controlled, it says 7-8 / 8 now.
I was about to write that it's working well, but when switching from FSE to windowed via hotkey, MPC HC x64 crashed without error description.

Btw: When using e.g. FineSharp as an upscaling refinement together with NNEDI3 image doubling, an issue with the Nvidia driver is triggered: The image gets corrupted as shown in the following (dark & red) and the NV driver fails to enter fast clock states, it can't go any higher than P5 state (faster P2 state would be correct for OpenCL/CUDA):
http://abload.de/thumb/hang5mu1o.png (http://abload.de/image.php?img=hang5mu1o.png)
Often MPC HC also crashes when this issue occurs.

[tobindac]

Demonstrating what big leap is one extra bit. It's an 8-fold increase every step. But that also means if you can already not see differences after 7, 8 or 9, the diminishing returns would be enormous, unless of course you're only getting rounding error improvements.

https://i.imgur.com/5AnsELY.png

[JarrettH]

0.88.2 Win8.1x64

MPC-HC (32bit) fails to exit properly. I have to end task manualy.

I noticed MPC fails to exit as well and posted about it:

http://forum.doom9.org/showthread.php?p=1721141#post1721141

[tFWo]

I noticed MPC fails to exit as well and posted about it:

http://forum.doom9.org/showthread.php?p=1721141#post1721141

Download the latest version 1.7.8.162 and it should be fixed.

[e-t172]

When the DCI standards were developed, tests were made on audience ability to see differences in luminance gradient levels. IIRC, many could see differences equivalent to 10bit gradients, and some could see 11bit gradient differences.

Without dithering, maybe. With proper dithering, I would be very, very surprised if this is actually true.

Another benefit of 10bit output from MadVR is with the use of 3D LUTs. With RGB gamma ramps or a 3DLUT, you need to change the spacing between RGB values from the default unity, to values that minimize display error. In doing so, banding can be introduced (you only have 0 to 255 to represent all 256 levels in 8bit). Using 10bit output to a 10bit display for 8bit material can reduce this banding, and give a better calibration.

AFAICT, when using a 3DLUT within madVR, dithering is done after the 3DLUT and before conversion to integer, effectively removing the banding introduced by the coarse steps.

[dbcooper]

Demonstrating what big leap is one extra bit. It's an 8-fold increase every step. But that also means if you can already not see differences after 7, 8 or 9, the diminishing returns would be enormous, unless of course you're only getting rounding error improvements.

https://i.imgur.com/5AnsELY.png

That is for all colours, not for gradients. Gradients go in one bit steps. i.e. 256, 512, 1024.

[Qaq]

are you a co-programmer of this by the way, because it's closed source.I'm not involved in madVR development, but I do programm some stuff at my work (measurements & automation).
madVR code is closed, but its technology was explained and discussed in details many times.
To what extend that can be ever noticed is another question.

I wouldn't be surprised if it's humanly impossible to see.
Well, we can spend tons of precious time on tests (then upgrade our software/hardware and start it again) or just use insine precision and call it a day. 10-12 bits don't cost anything to us.
I think I've made myself clear now, so I stop right here to not mess with the actual discussion.

[XMonarchY]

AFAICT, when using a 3DLUT within madVR, dithering is done after the 3DLUT and before conversion to integer, effectively removing the banding introduced by the coarse steps.

Correct! Even I know that :helpful:

[Hprd]

Not sure if this has been reported, but I get a total freeze/crash (have to kill MPC-BE with task manager) when entering fullscreen with super res enabled for upscaling (chroma is fine) with image quadrupling (nnedi3, any setting) regardless of FSE mode (d3d11/9, 8-10bit). With no super res, video plays fine with quadrupling. On this screen (1920x1200) only affects DVD resolution videos obviously.

[Zachs]

Hi madshi,

MadVR is currently in violation of MPDN_Extension's license which is LGPLv3. Can you please correct this violation?
For more information, see MPDN's thread here - http://forum.doom9.org/showthread.php?p=1721194#post1721194

Thanks.

[har3inger]

Has anyone with switchable graphics managed to get the dx11 working? I get a black screen with audio, and no OSD.

(Same thing has always happened if I try to use a separate rendering device)

[ryrynz]

Well, we can spend tons of precious time on tests (then upgrade our software/hardware and start it again) or just use insine precision and call it a day. 10-12 bits don't cost anything to us.

Exactly. Set to 10 bit, avoid dithering to gain some performance if u want as chances are u won't see any benefit enabling it (tests required) and call it a day.
I think dithering looks a bit messy on a plasma less noise = cleaner/clearer picture.

[James Freeman]

Adding to the discussion about 8bit vs 10bit;

You are forgetting that Contrast Ratio has a huge influence on whether you'll see the difference between steps or not.
8bit on a typical 1000:1 display is almost enough to not see the gradients, but on a 20,000:1 plasma the gradients are clear as day, 10bit on a 1000:1 is an overkill.
Now if HDR display will have a contrast ratio or 100,000:1 it most definitely will benefit from 10bit+ we'll see.
This on a smooth gradient pattern which is far from what real video is;
Quality (original -> not re-compressed) bluray video has its own dithering done when it was converted from 12bit DCI to bluray, so the chances anyone will see banding is slim.
On a super compressed anime where smooth color changes are almost like a test pattern, is a different story.

I wonder what is the visible bit depth of Dithered 10bit... maybe like 14bit?
And to think that madVR is capable of that right now... :cool:

madshi,
I'm totally satisfied with the current 3 Debanding options.
They are doing to job just fine, from 1GB super compressed flicks to full 50GB remuxes.
I don't see any detail loss or banding when it is doing its job.

[ladersu]

madVR 0.88.2 32bit
ati 5770 13.12
Win7 64bit

d3d11 render queue doesn't fill up, and present time is 0.26 vs 0.07 for d3d9.

[harshal_rio91]

Has anyone with switchable graphics managed to get the dx11 working? I get a black screen with audio, and no OSD.

(Same thing has always happened if I try to use a separate rendering device)

Works fine on my laptop with Intel HD 4600 + GTX 860M

[baii]

0.88.2 seem to broke next/skip file for me, tried default setting, both mpc-hc and pot player does it. revert back to 0.88.1 and it is fine.

64bit nnedi3 will make image darken, it that known issue?

[ryrynz]

8bit on a typical 1000:1 display is almost enough to not see the gradients, but on a 20,000:1 plasma the gradients are clear as day, 10bit on a 1000:1 is an overkill.


Overkill that costs you nothing. Disable dithering and gain performance.

[Schwartz]

It appears that homemade VfW H.264 put into .avi files cannot be played in 0.88.2 anymore without an ugly green bar at the top of the video. It used to be good with 0.87.X. And yeah, I realize you're not supposed to record H.264 in .avi, but it used to work fine. (and I put them in .mkv afterwards, but still no dice)

Edit: Looks as if the chroma part of the image is 'pushed downwards' by X amount of pixels. Smaller video, bigger bar.

Link to a small test video. (http://www.filedropper.com/test_2)