View Full Version : madVR - high quality video renderer (GPU assisted)
aufkrawall
11th May 2015, 23:10
Another issue: LumaSharpen doesn't seem to be active if strength isn't 1 or higher.
Moony349
11th May 2015, 23:59
It even tells you this in the second Chroma line.
First, 4:2:0 Chroma is upscaled to 4:4:4/RGB using your selected chroma upscaling algorithm. Then image doubling is used for Luma, and the chroma is upscaled further using Catmull-Rom AR.
Thanks!
I didn't quite understand the two stop process; now it makes sense.
XMonarchY
12th May 2015, 00:20
madshi, thank you for a prompt response regarding my inquiries. madVR 0.88.4 is not faster for me in regards to Image Doubling and Quadrupling than madVR 0.88.2. I changed Image Upscaling from Jinc 3 tap + AR to Lanczos 3 tap + AR per your advice, but that did not help at all. Doubling + Quadrupling, both @ NNEDI3 16 neurons + NNEDI3 16 neurons for Chroma Upscaling result in SEVERE frame drops... That is WITH and WITHOUT SuperRes Chroma Upscaling filter and SuperRes Image Refinement... Using D3D11 or not using it also made no difference. Could it be just nVidia drivers? I use the latest 350.12 nVidia drivers, LAV Filters 0.65 (LAV Video uses CUVID), MPC-HC 1.7.8, ReClock
I still want to figure these out in addition to figuring out how to resolve Image Quadrupling issue:
1. What about Direct3D 11? Does it improve quality or performance? When I enable it with or without the "present a frame for every Vsync" I get presentation glitches, but no delayed or dropped frames. What are the presentation glitches? Should presentation glitches be ignored if no frames are delayed and dropped?
2. Is there any comparison or reports from people regarding the difference between SuperRes for Chroma Upscaling filter VS. SuperRes for Image Refinement.
3. Does 10bit selection for "the native display bitdepth is" work for nVidia Maxwell owners who use 8bit+FRC monitors via DisplayPort? My Eizo Foris FG2421 is an 8bit+FRC panel, but nVidia lacks an option to enable 10bit depth in its settings. Should I select 10bit anyway?
To everyone else - I saw true 10bit IPS monitor gradients and my Eizo Foris FG2421 8bit+FRC panel gradients do not look as good, but my panel has 4700:1 contrast ratio after calibration. In the end, I DO think true 10bit panels show better gradation than 8bit+FRC monitors. Its like saying that 6bit+FRC TN panels are as good as true 8bit IPS panels in regards to gradation (not everything else though). On my FG2421, there is some "banding" visible in darker grayscale levels when I use ArgyllCMS 1D LUT for desktop/games, but its not so much banding as the actual dithering pattern that changes. I don't really like it to be honest. It makes it impossible to get a real accurate 1DLUT calibration, especially for darker gray levels. The dithering itself only works if the pixels turn a different color, one that is not accurate for that grayscale level, again, making it impossible to truly calibrate. 3DLUT is probably less affected since its being processed at higher bitdepth, but that dithering is ALWAYS there. I use dispcalGUI 3.0.0 with ArgyllCMS 1.7.0 x86 and i1Display Pro colorimeter.
Ok, disabling dithering is a valid test, but only for checking if there's any difference between 8bit and 10bit output at all. You should always have dithering enabled in real life. So that's what you should test with, in order to decide whether using 10bit output has any real benefit. So I would recommend to enable dithering again and then check if you can see any difference in image quality between 8bit and 10bit.
With most 10 bit monitor having a matte coating and FSE is needed (no on the fly switch), It is really hard to see if there is noise difference.
even with a artificial ramp that looks like this in 8bit w.o dither
http://i.imgur.com/zzSpKR7.jpg
dither on vs 10bit FSE, at a glance, I have no way to tell difference.
pirlouy
12th May 2015, 00:53
Sorry, I did not test 0.88 yet, since i did not have time to read bug reports, etc.
I just wanted to know if it's a 0.87.21 known bug.
With x64 build of 0.87.21 (and not x86), even if I disable "switch to matching display mode", madVR automatically changes refresh rate. Instead of 60Hz (define in Windows before launching movie), it automatically switches to 59Hz when I enter Fullscreen. I saw it because my TV becomes black and TV OSD shows resolution/refresh rate (even if it writes 60Hz instead of 59). With madVR stats, it's easily confirmed.
I think I'll test 0.88 tomorrow, but if someone would confirm it was a known bug, it would be nice.
PS: I've installed latest Beta Catalyst driver to be sure it was not drivers related, but it's the same problem.
edcrfv94
12th May 2015, 00:56
if use NNEDI3 double & quadruple image with superRes Player will stop only can be close
tobindac
12th May 2015, 02:15
10-bit Display Support Test
This test will make it easier to see if your display actually supports 10bit input to output.
We already know that D3D11 + FSE in madVR will output a 10bit signal in windows 7 and up.
Now we just need to provide a super smooth black to white test pattern to clearly be able to see with our eyes.
First download this Greyscale Ramp mp4 file which I copied from AVS709HD (all rights reserved to them):
http://www.mediafire.com/download/6e6jhmcgxie4ncv/Grayscale_Ramp.zip
Play the mp4 file and set madVR as follows:
display->properties->10bit
display->calibration->disable & disable GPU gamma ramp.
processing->artifact removal->reduce banding ON: High High.
rendering-> general-> Direct3D 11 ON
rendering->dithering->none
rendering->general->automatic exclusive fullscreen mode (FSE)-> off (for now).
When the strong Debanding is On and Dithering is Off the resulting output image will be a gradient in the bitdepth you set under properties.
You can switch between bit depths to see what I mean and go back to 10bit.
Now go fullscreen without FSE (windowed fullscreen) to see the 8bit banding which should be visible because there are only 256 gradients from black to white because the GPU is sending the image in 8bit to the display in this mode.
Now switch FSE On ("automatic exclusive fullscreen mode" under general) and go fullscreen again, now the GPU actually sends 10bit image to the display, and if your display supports 10bit input, you should now see 1024 gradients from black to white which is practically indiscernible (to me).
If you still see the 8bit gradients even though the GPU sends 10bit to your display in FSE+D3D11 mode, your display does not support 10bit.
* The Panasonic ST60 does not support 10bit at the input, I still see the 8bit gradients.
But the Dell U2410 flickers and switches to 10bit mode and the image is smooth (first time seeing 10bit mode after owning this display for 5 years).
Wow, my monitor does support 10bit display!1 I keep being impressed with this IPS monitor. I've managed to reliably overclock it to 76Hz and the image is so clear. In conjunction with SVP it's perfect for movies.
tobindac
12th May 2015, 02:19
I'm also not sure if the display dithers or maybe the GPU. It's really hard to say. In the end, we can only compare and use whichever mode looks best to our eyes.
Are we sure the panels aren't just capable of using 10bit?
Asmodian
12th May 2015, 02:41
v0.88.4 is running very well for me and I like the new D3D11 support a lot - it allows a faster transition into and out of FSE. :thanks:
edit: no performance hit with SLI on when using D3D11!
FineSharp is also quite nice for some content.
Thanks for these major updates!
Of course, at some point in the future, it would be great to have profile support for "image enhancements" and "upscaling refinement". :)
v0.88.4 is running very well for me and I like the new D3D11 support a lot - it allows a faster transition into and out of FSE. :thanks:
edit: no performance hit with SLI on when using D3D11!
FineSharp is also quite nice for some content.
Thanks for these major updates!
Of course, at some point in the future, it would be great to have profile support for "image enhancements" and "upscaling refinement". :)
i remember profile for new features were added in .88.2?
Make sure aero is turned on?
Make sure aero is turned on?
yes that was it, thank you.
I seem to be getting 10-bits only when my display is at 60Hz. When at 23Hz, I don't seem to be getting the 10-bit output.
I am using the following pattern in mpc-hc x64:
http://forum.doom9.org/showpost.php?p=1721458&postcount=11
win7x64, gtx970 connected to 10-bit TV via HDMI 2.0.
At 60Hz dithering disabled, I see a smooth pattern.
At 23Hz dithering disabled, I see the same banding 8-bits and up.
I am not sure who is at fault, madvr, nvidia or TV? Any ideas? Does anyone successfully produce 10-bit output in 23Hz?
Asmodian
12th May 2015, 05:12
i remember profile for new features were added in .88.2?
oops! you are right, they are profileable now. :o
Thanks. :)
Anime Viewer
12th May 2015, 05:19
Experimenting with the image enhancement and upscaling refinement settings it seems FineSharp and SuperRes provide similar image quality improvements to each other. The two together provide too many artifacts, so it seems (at least on my system) that its best to choose one or the other. SuperRes seems to provide slightly higher render times and faster present times while FineSharp has faster render times with higher present times. Given the 480 video upscaled to 1080 resolution I was testing there was only a small swing either way (SuperRes 15ms render 9ms present, FineSharp 8ms render, 12ms present). What are opinions on which is the better to keep low(er), or allow to drift high(er).
Edit: Tested 720p video upscaled to 1080p also. Finesharp was ~11ms on both render and present while SuperRes was 20ms render and 8ms present. Based on that I'll probably go with Finesharp for the moment.
Experimenting with the image enhancement and upscaling refinement settings it seems FineSharp and SuperRes provide similar image quality improvements to each other. The two together provide too many artifacts, so it seems (at least on my system) that its best to choose one or the other. SuperRes seems to provide slightly higher render times and faster present times while FineSharp has faster render times with higher present times. Given the 480 video upscaled to 1080 resolution I was testing there was only a small swing either way (SuperRes 15ms render 9ms present, FineSharp 8ms render, 12ms present). What are opinions on which is the better to keep low(er), or allow to drift high(er).
Edit: Tested 720p video upscaled to 1080p also. Finesharp was ~11ms on both while SuperRes was 20ms render and 8ms present. Based on that I'll probably go with Finesharp for the moment.
the present times shouldn't be affected. these settings have nothing to do with presentation.
something isn't working as it should i guess. you should usually have avg present times below 1 ms...
i usually have avg present times below 0.2 no matter what settings are used.
how are your present times with other presentation modes like old path or overlay?
agustin9
12th May 2015, 05:38
I'm having a small problem using D11. My refresh rate changes from 59.99 in windowed to 59.93 in FSE, which makes the transition somehow slow.
This happens on my TV, and not on my monitor. I tried with the TV as main screen and it happens the exact same way. With D9 no problem.
potomac
12th May 2015, 05:40
madshi thanks for this huge work
i tested 10 bit on my cheap lg ips235 and i can see the improvement in the gray scale :) but my 5850 doesn't work well in dx11 mode
I'm having a small problem using D11. My refresh rate changes from 59.99 in windowed to 59.93 in FSE, which makes the transition somehow slow.
This happens on my TV, and not on my monitor. I tried with the TV as main screen and it happens the exact same way. With D9 no problem.
i have the same problem could be this bug but for d3d11:
http://bugs.madshi.net/view.php?id=90
agustin9
12th May 2015, 05:54
i have the same problem could be this bug but for d3d11:
http://bugs.madshi.net/view.php?id=90
The thing is, I forgot to mention, that i have the display switcher off on both screens... I'm using Windows 8.1...
The thing is, I forgot to mention, that i have the display switcher off on both screens... I'm using Windows 8.1...
yeah display mode switcher is not needed to trigger this current bug. but i wouldn't be shocked if it's not needed for the old bug too.
i may load a old madVR version and give it a try.
and it doesn't seems to matter if it is windows 8, 8.1 in your case or 10 in my case.
James Freeman
12th May 2015, 06:15
i tested 10 bit on my cheap lg ips235 and i can see the improvement in the gray scale, but my 5850 doesn't work well in dx11 mode
This sentence contradicts itself in one go.
The LG IPS235V most definitely doesn't support 10bit input.
I beginning to think that madshi should include a simple test in madVR to make things clearer.
Please refer to this thread for more info and a simpler test:
http://forum.doom9.org/showthread.php?t=172128
cvrkuth
12th May 2015, 06:19
With Direct3D 11 presentation path enabled I have display switching issue again, now in madVR32 too (There was issue in the 32 bit version, v0.86.10. Madshi then do workaround and issue was gone).
Not any more
Display modes switch problem presents only if FSE enabled. When FSE is disabled Madvr switch display modes correctly
Finesharp vs superres. I only did double scaling with nnedi3 (as quadrupling with superres doesn't work anyways for me). With double scaling (nnedi3 for chroma as well with superres there on defaults) finesharp with slightly tweaked settings (all defaults except mode set to 3, and linear light turned on) gives a (subjectively) noticably better result than superres (nnedi3 default settings), and lower rendering times too (perhaps more important in some ways obviously). I honestly didn't think upscaling could be this sharp, detailed and clean (for virtually any content I've thrown at it).
This sentence contradicts itself in one go.
The LG IPS235V most definitely doesn't support 10bit input.
I beginning to think that madshi should include a simple test in madVR to make things clearer.
Please refer to this thread for more info and a simpler test:
http://forum.doom9.org/showthread.php?t=172128
even a cheap dispaly can easily support 10 bit or even 12 bit input.
the interesting part is what the display does with it to display it on it's 6 bit or 8 bit panel.
on AMD and the newest nvidia beta driver for windows 10 you have full control of the output bit deep. of cause this option give you only possibilities the screen can take as an input.
I seem to be getting 10-bits only when my display is at 60Hz. When at 23Hz, I don't seem to be getting the 10-bit output.
I am using the following pattern in mpc-hc x64:
http://forum.doom9.org/showpost.php?p=1721458&postcount=11
win7x64, gtx970 connected to 10-bit TV via HDMI 2.0.
At 60Hz dithering disabled, I see a smooth pattern.
At 23Hz dithering disabled, I see the same banding 8-bits and up.
I am not sure who is at fault, madvr, nvidia or TV? Any ideas? Does anyone successfully produce 10-bit output in 23Hz?
Proper 10-bit output seems to be only happening when at 60Hz with win7x64 + nvidia combination. Any other refresh rate, even though madvr reports 10-bits, only 8-bits is displayed (as evidenced by the test pattern). Are others seeing this also?
omarank
12th May 2015, 06:34
It's working fine here. However, with active 10bit output (in D3D11 FSE mode) error diffusion is disabled automatically and ordered dithering is used instead. The reason for that is that at 10bit, the quality of the dithering should play no role for image quality, anymore. This only applies to 10bit FSE mode, though. In windowed mode (which is always max 8bit) error diffusion is still used.
Well, you invested so much time in developing and fine tuning the error diffusion algorithms. They are a premium feature of madVR, but you have disabled them for another premium feature – 10 bit output. I completely agree that there would be hardly any benefit in using Error diffusion dithering over ordered dithering for 10 bit output, but I believe it doesn’t harm either. Also, HDR displays will be available sooner or later, and error diffusion dithering at 10 bit would be beneficial again.
ryrynz
12th May 2015, 08:12
Hey madshi could you allow for the bitdepth shortcut key to switch to 9 and 10 bit please? If I use the shortcut key it'll switch down from 10 to 9 and 8 bit
but it doesn't start back at 10 bit.
It would also be kinda cool for a shortcut to switch between two user specified bitdepths.. also could you add a shortcut to cycle dithering methods? Cheers.
I completely agree that there would be hardly any benefit in using Error diffusion dithering over ordered dithering for 10 bit output, but I believe it doesn’t harm either. Also, HDR displays will be available sooner or later, and error diffusion dithering at 10 bit would be beneficial again.
I like how error diffusion looks on 8 bit over ordered dithering, I too would like to see this enabled for 10 bit so I can see for myself how it looks on my TV.
Being a plasma madVR's dithering patterns seem to affect it more than LCD's, It would certainly help in that instance having the keyboard shortcut I suggested above for comparisons.
madshi
12th May 2015, 09:13
According to the GPU usage, I am afraid dithering fall back to ordered dithering all the time even with 8-bit output. Could you please double check?
I checked yesterday and error diffusion worked just fine for me. Except in 10bit FSE mode, where I intentionally disabled it. If you find the error diffusion doesn't work for you in other situations, as well, I'd need a way to reproduce that. Maybe you can find a specific set of circumstances in which it works and in which it doesn't? Try setting the display bitdepth to 2 bits. Then you can easily see the difference in the dither pattern when switching between different dither options.
I found out that my problem with NNEDI3 + FineSharp afterwards is caused by image quadrupling.
Doubling 64 + FS works fine, but additional quadroupling 64 produces corruption and NV driver failure.
Anyone confirm? Be sure that quadrupling is actually active.
if use NNEDI3 double & quadruple image with superRes Player will stop only can be close
Oooops, yes, there's a bug still in v0.88.4, will be fixed in the next build.
Another issue: LumaSharpen doesn't seem to be active if strength isn't 1 or higher.
Right! Thanks for letting me know. Will be fixed in the next build.
madVR 0.88.4 is not faster for me in regards to Image Doubling and Quadrupling than madVR 0.88.2. I changed Image Upscaling from Jinc 3 tap + AR to Lanczos 3 tap + AR per your advice, but that did not help at all. Doubling + Quadrupling, both @ NNEDI3 16 neurons + NNEDI3 16 neurons for Chroma Upscaling result in SEVERE frame drops... That is WITH and WITHOUT SuperRes Chroma Upscaling filter and SuperRes Image Refinement... Using D3D11 or not using it also made no difference. Could it be just nVidia drivers? I use the latest 350.12 nVidia drivers, LAV Filters 0.65 (LAV Video uses CUVID), MPC-HC 1.7.8, ReClock
Ok, can you please retry with v0.88.5? If that still isn't working for you, I'll need some more tests:
1) With v0.87.21, what happens if you disable Chroma doubling and Chroma quadrupling (right side of the image doubling page)? Do you then get similar results to v0.88.5?
2) What are your rendering times with: a) v0.87.21 with your original settings. b) v0.87.21 with disabled Chroma doubling/quadrupling. c) v0.88.5?
Please always keep the new features turned off for now, as not to complicate the performance comparison to v0.87.21.
I still want to figure these out in addition to figuring out how to resolve Image Quadrupling issue:
1. What about Direct3D 11? Does it improve quality or performance? When I enable it with or without the "present a frame for every Vsync" I get presentation glitches, but no delayed or dropped frames. What are the presentation glitches? Should presentation glitches be ignored if no frames are delayed and dropped?
2. Is there any comparison or reports from people regarding the difference between SuperRes for Chroma Upscaling filter VS. SuperRes for Image Refinement.
3. Does 10bit selection for "the native display bitdepth is" work for nVidia Maxwell owners who use 8bit+FRC monitors via DisplayPort? My Eizo Foris FG2421 is an 8bit+FRC panel, but nVidia lacks an option to enable 10bit depth in its settings. Should I select 10bit anyway?
I can't answer questions specific to your GPU or display. Just try out what looks best to your eyes and use that. If you get presentation glitches in D3D11 not only when seeking and pausing/playing, but also in the middle of straight playback, and if you don't get any in D3D9 then it might make sense to stick with D3D9. Although I would guess that in FSE mode D3D11 should show no glitches during straight playback. If it's only in windowed mode then you need to answer yourself whether it bothers you or not. If you don't want to use native 10bit output then there's no big loss by sticking to D3D9.
It is too early to discuss SuperRes and all the other new features. I've explicitly asked users to concentrate their tests on the new debanding feature for now.
I seem to be getting 10-bits only when my display is at 60Hz. When at 23Hz, I don't seem to be getting the 10-bit output.
That is possible, I guess. It could be the GPU or the display, I can't say. There's most probably nothing I can do about it.
Experimenting with the image enhancement and upscaling refinement settings it seems FineSharp and SuperRes provide similar image quality improvements to each other. The two together provide too many artifacts, so it seems (at least on my system) that its best to choose one or the other. SuperRes seems to provide slightly higher render times and faster present times while FineSharp has faster render times with higher present times. Given the 480 video upscaled to 1080 resolution I was testing there was only a small swing either way (SuperRes 15ms render 9ms present, FineSharp 8ms render, 12ms present). What are opinions on which is the better to keep low(er), or allow to drift high(er).
Edit: Tested 720p video upscaled to 1080p also. Finesharp was ~11ms on both render and present while SuperRes was 20ms render and 8ms present. Based on that I'll probably go with Finesharp for the moment.
Finesharp vs superres. I only did double scaling with nnedi3 (as quadrupling with superres doesn't work anyways for me). With double scaling (nnedi3 for chroma as well with superres there on defaults) finesharp with slightly tweaked settings (all defaults except mode set to 3, and linear light turned on) gives a (subjectively) noticably better result than superres (nnedi3 default settings), and lower rendering times too (perhaps more important in some ways obviously). I honestly didn't think upscaling could be this sharp, detailed and clean (for virtually any content I've thrown at it).
Thanks for the feedback, guys. But I do want to clear up debanding first, before moving to the other new options. FWIW, Shiandow is still working on maybe improving his debanding algorithm further. So let's give him a couple of days, and then retest, and then decide whether we keep his algorithm in madVR or not. And no, it will not stay as an option. It will either replace the current "high" preset, or it will go.
madshi thanks for this huge work
i tested 10 bit on my cheap lg ips235 and i can see the improvement in the gray scale :) but my 5850 doesn't work well in dx11 mode
In which way does it not work well?
Well, you invested so much time in developing and fine tuning the error diffusion algorithms. They are a premium feature of madVR, but you have disabled them for another premium feature – 10 bit output. I completely agree that there would be hardly any benefit in using Error diffusion dithering over ordered dithering for 10 bit output, but I believe it doesn’t harm either. Also, HDR displays will be available sooner or later, and error diffusion dithering at 10 bit would be beneficial again.
I like how error diffusion looks on 8 bit over ordered dithering, I too would like to see this enabled for 10 bit so I can see for myself how it looks on my TV.
Being a plasma madVR's dithering patterns seem to affect it more than LCD's, It would certainly help in that instance having the keyboard shortcut I suggested above for comparisons.
Of course error diffusion doesn't harm quality, it does harm performance, though. Maybe I'll add a trade quality option to disable error diffusion in 10bit FSE mode? And allow it to be enabled if the trade quality option is not activated?
Hey madshi could you allow for the bitdepth shortcut key to switch to 9 and 10 bit please? If I use the shortcut key it'll switch down from 10 to 9 and 8 bit
but it doesn't start back at 10 bit.
Oh well, this is not as easy as it might sound: The switch between true 10bit output and true 8bit output requires me to recreate the whole D3D11 devices etc. Currently when you use the shortcut keys to switch from 10bit down to lower bitdepths, madVR will still output native 10bit, just rounded/dithered to a lower bitdepth. That's not a really true comparison because the GPU and/or the display might behave differently between native 10bit output and native 8bit output. But switching between those on the fly isn't so easy.
also could you add a shortcut to cycle dithering methods? Cheers.
I guess that should be possible. But the two extra options ("colored noise" etc) will not be cycled, just the algorithms themselves?
With x64 build of 0.87.21 (and not x86), even if I disable "switch to matching display mode", madVR automatically changes refresh rate. Instead of 60Hz (define in Windows before launching movie), it automatically switches to 59Hz when I enter Fullscreen.
I'm having a small problem using D11. My refresh rate changes from 59.99 in windowed to 59.93 in FSE, which makes the transition somehow slow.
This happens on my TV, and not on my monitor. I tried with the TV as main screen and it happens the exact same way. With D9 no problem.
i have the same problem could be this bug but for d3d11:
http://bugs.madshi.net/view.php?id=90
FWIW, this is *not* a bug in madVR, but a bug in either D3D or in the OS itself. I partially succeeded in hacking the OS to fix this bug with D3D9, which may or may not work for D3D11. Maybe I'll find a way to fix this for D3D11, too. Just want it to be understood that it's *not* a bug in madVR.
with D3D11 for any settings I can use I get 3-5 rendered frames. Doesnt really affects me much, 0 glitches, 0 dropped frames. I tried changing the "max prerendender" from nvidia panel but nothing changes.
That said, should I set triplebuffering from nvidia panel?
madshi
12th May 2015, 09:14
madVR v0.88.5 released
http://madshi.net/madVR.zip
* fixed: image quadrupling was buggy, sometimes crashed
* fixed: LumaSharpen strength was truncated (0.99 -> 0.00)
Seems like the most important bugs are fixed now. At least I hope so...
madshi
12th May 2015, 09:21
For those of you with refresh rate switching problems when using D3D11, does this test build fix things or change anything?
http://madshi.net/madVR885refreshRate.zip
detmek
12th May 2015, 09:43
Thanks for the new features Madshi. But I have a small problem with 0.88 series.
I am testing all 0.88 versions and I have a problem with D3D11. When I switch from windowed mode to full screen or vice versa picture flickers for a few seconds (black frame/regular frame/black frame/regular ect). Also, it seams like frames are show out of order.
No problem with MPDN in D3D11 mode.
My PC spec:
Intel Pentium G3220 IGPU
4GB RAM
Windows 8.1 x64 updated
Driver: 10.18.14.4170 (latest)
MPC-HC/MPC-BE x64 latest nightly
ryrynz
12th May 2015, 09:45
madshi, are you seeing a ~90MB difference in GPU memory allocation when in 10 bit selecting ordered dithering vs error diffusion? (which shouldn't be the case considering error diffusion is disabled in 10 bit)
Of course error diffusion doesn't harm quality, it does harm performance, though. Maybe I'll add a trade quality option to disable error diffusion in 10bit FSE mode? And allow it to be enabled if the trade quality option is not activated?
Sounds good.
I guess that should be possible. But the two extra options ("colored noise" etc) will not be cycled, just the algorithms themselves?
Yeah that's fine.
omarank
12th May 2015, 10:14
Maybe I'll add a trade quality option to disable error diffusion in 10bit FSE mode? And allow it to be enabled if the trade quality option is not activated?
Yes, this will be ideal. Thanks!
pirlouy
12th May 2015, 10:55
FWIW, this is *not* a bug in madVR, but a bug in either D3D or in the OS itself. I partially succeeded in hacking the OS to fix this bug with D3D9, which may or may not work for D3D11. Maybe I'll find a way to fix this for D3D11, too. Just want it to be understood that it's *not* a bug in madVR.
Ok I totally believe you on the fact it is a Windows/driver bug. But on 0.87.21, I though there were not D3D11 yet.
What is strange is that this behavior is present in x64 build, not in x86.
I'll do tests with 0.88 later.
cvrkuth
12th May 2015, 11:08
For those of you with refresh rate switching problems when using D3D11, does this test build fix things or change anything?
http://madshi.net/madVR885refreshRate.zip
No success here
For those of you with refresh rate switching problems when using D3D11, does this test build fix things or change anything?
http://madshi.net/madVR885refreshRate.zip
Tried it, no difference, instead of 24Hz it still switches to 23.97.
thx for all the updates ;)
For those of you with refresh rate switching problems when using D3D11, does this test build fix things or change anything?
http://madshi.net/madVR885refreshRate.zip
doesn't work for me 60p switches to 59p
aufkrawall
12th May 2015, 14:14
LumaSharpen is fixed for me, but I'm still having the same issue when using NNEDI3 quadrupling + FS. :(
Btw: Could we have a trade quality option regarding the C-R chroma scaling with NNEDI3?
High end GPUs really don't care if chroma scaling is done via Jinc3 or C-R and chroma scaling isn't totally unimportant with extreme cartoon scaling (I know that's only regarding 2nd chroma scaling step).
agustin9
12th May 2015, 14:14
For those of you with refresh rate switching problems when using D3D11, does this test build fix things or change anything?
http://madshi.net/madVR885refreshRate.zip
Not working here :(
madshi
12th May 2015, 14:30
I have a small problem with 0.88 series.
I am testing all 0.88 versions and I have a problem with D3D11. When I switch from windowed mode to full screen or vice versa picture flickers for a few seconds (black frame/regular frame/black frame/regular ect). Also, it seams like frames are show out of order.
No problem with MPDN in D3D11 mode.
My PC spec:
Intel Pentium G3220 IGPU
4GB RAM
Windows 8.1 x64 updated
Driver: 10.18.14.4170 (latest)
MPC-HC/MPC-BE x64 latest nightly
Is that only when using 10bit output, or also when using 8bit output?
Uhm, Pentium G3320 IGPU? Never heard of that yet! My best guess is that the driver are at fault. I've no such problem as you report with my HD4000 on Windows 8.1 x64, at least. MPDN calls D3D11 APIs in a different way. IMHO my way is better. In your specific situation my way seems to make problems, though, but I believe the GPU drivers are at fault for that.
madshi, are you seeing a ~90MB difference in GPU memory allocation when in 10 bit selecting ordered dithering vs error diffusion? (which shouldn't be the case considering error diffusion is disabled in 10 bit)
The difference is probably due to needing higher bitdepth textures for 10bit output.
No success here
Tried it, no difference, instead of 24Hz it still switches to 23.97.
doesn't work for me 60p switches to 59p
Not working here :(
Ok, it was worth a try, but obviously didn't work.
Are all of you using Windows 8? Or some still on Windows 7?
LumaSharpen is fixed for me, but I'm still having the same issue when using NNEDI3 quadrupling + FS. :(
Now that's weird. There was a clear bug which I fixed. I could reproduce the issue every time with v0.88.4, but can't reproduce it at all with v0.88.5. Can you try to find out more information about which circumstances it occurs with exactly? E.g. try NEDI instead of NNEDI3. Does that make a difference? Or try NNEDI3 for doubling and NEDI for quadrupling. Or try FineSharp instead of SuperRes.
Btw: Could we have a trade quality option regarding the C-R chroma scaling with NNEDI3?
High end GPUs really don't care if chroma scaling is done via Jinc3 or C-R and chroma scaling isn't totally unimportant with extreme cartoon scaling (I know that's only regarding 2nd chroma scaling step).
Do you have a screenshot which shows a quality difference between Jinc3 and C-R for chroma doubling?
Ok, it was worth a try, but obviously didn't work.
Are all of you using Windows 8? Or some still on Windows 7?
windows 10
JarrettH
12th May 2015, 14:44
Why not choose a sharper upscaler instead of using post-processing?
I think I know the answer, I'm just wondering. For example, using a sharp upscaler in Photoshop isn't enough to make a sharp print.
aufkrawall
12th May 2015, 14:44
Now that's weird. There was a clear bug which I fixed. I could reproduce the issue every time with v0.88.4, but can't reproduce it at all with v0.88.5. Can you try to find out more information about which circumstances it occurs with exactly? E.g. try NEDI instead of NNEDI3. Does that make a difference? Or try NNEDI3 for doubling and NEDI for quadrupling. Or try FineSharp instead of SuperRes.
madVR doesn't crash, it's probably bugged behavior of the driver (kind of flickering with SuperRes, playback stops, reddish-dark tone with FS).
No problems with NNEDI.
Now I wonder why doubling works well under these circumstances, but quadrupling doesn't.
Do you have a screenshot which shows a quality difference between Jinc3 and C-R for chroma doubling?
How can I do this without a checkbox?
Well, I don't understand this kind of restriction. Image quadrupling uses tons of ressources and often the quality difference is neglectable. The option is there, though. We have lots of other checkboxes to force max quality, why not for this?
It worked well for me for a year now.
ryrynz
12th May 2015, 14:48
The difference is probably due to needing higher bitdepth textures for 10bit output.
I was testing in 10 bit both times, just switching dithering modes which should produce the exact same results considering ED falls back to OD.
madshi could you have the OSD actually display the dithered bitdepth set when it's less than 8 bit? say 'Full screen Exclusive mode 8 bit (6 bit)'
If I enable DXVA luma downscaling (HD 4000) and mouse click holding MPC-BE's window edge taking it down and then back out (downscaling further and then upscaling further whist staying in windowed mode) I get a DXVA processing failed message that disappears when I move switch to something other than MPC-BE's window (doesn't affect playback)
cvrkuth
12th May 2015, 14:56
Are all of you using Windows 8? Or some still on Windows 7?
Win8.1 Pro x64
madshi
12th May 2015, 15:02
Why not choose a sharper upscaler
Like what?
How can I do this without a checkbox?
By using v0.87.21.
Well, I don't understand this kind of restriction. Image quadrupling uses tons of ressources and often the quality difference is neglectable. The option is there, though. We have lots of other checkboxes to force max quality, why not for this?
It worked well for me for a year now.
Are you talking about removing the chroma doubling options, or about the limitation to Catmull-Rom instead of Jinc? There are several reasons for removing the chroma doubling options:
1) NEDI does all in one step, but NNEDI3 doesn't. So having separate chroma doubling options didn't make much sense when using NEDI.
2) Some users enabled chroma doubling because they thought it would benefit image quality, when they should have increased luma doubling neurons instead. So by removing the chroma doubling options I force users to make better decisions.
3) Less options = less frightening for new users.
4) For SuperRes I have to remove the 0.5 pixel shift caused by NEDI and NNEDI3. This gets awfully complicated if chroma is sometimes doubled with NNEDI3 and sometimes upscaled with a conventional algorithm. So removing the doubling options made my code quite a bit simpler. Which means it's also less error prone.
About Jinc3 vs. Catmull-Rom: I've yet to see even a difference between Jinc3 vs *Bilinear*, when talking a replacement for chroma doubling. But maybe I just didn't look at enough samples. If you can find a real life content sample where Jinc3 looks better than Catmull-Rom for chroma doubling, then I'm all for allowing Jinc3, once again. But if nobody can find any evidence for Jinc3 helping, then why allowing users to make a bad choice? Actually, it's not even that: If you upscale to an arbitrary resolution, which is not exactly doubling, then Jinc3 might be useful for the luma part, after doubling. So there's a good reason for users to select Jinc3 for luma upscaling, even if they use image doubling. But for chroma doubling it's a totally different topic. Of course I could add just another setting to let users select the chroma doubling algorithm (e.g. Catmull-Rom or Jinc3), but really, I want to *reduce* the number of similar options, not increase them. The number of scaling options is already larger than I like. I will probably decrease them further at some point, too.
I was testing in 10 bit both times, just switching dithering modes which should produce the exact same results considering ED falls back to OD.
Then it was probably something random.
madshi could you have the OSD actually display the dithered bitdepth set when it's less than 8 bit? say 'Full screen Exclusive mode 8 bit (6 bit)'
I don't think it's important enough to be added there. There are hundreds of things I could add there. But the space is limited.
If I enable DXVA luma downscaling (HD 4000) and mouse click holding MPC-BE's window edge taking it down and then back out (downscaling further and then upscaling further whist staying in windowed mode) I get a DXVA processing failed message that disappears when I move switch to something other than MPC-BE's window (doesn't affect playback)
Can you create a bug tracker entry for this?
-------
Probably v0.88.5 will stay the active version for a while now. Maybe I'll update it again when Shiandow has completed work on his Deband shader. Other than that further bugs will have to wait for fixes, unless something ultra urgent comes along...
Are all of you using Windows 8? Or some still on Windows 7?
Windows 8.1 64bit here.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.