madVR - high quality video renderer (GPU assisted) [Archive] - Page 602

James Freeman

15th May 2015, 17:13

Found a thoroughly compressed video with lots of night sky content, banding, blocking and what not; did some testing.

Well, my conclusion as before, both the default and shiandow's are doing fine job.
I would be happy with either one.

Both remove from the smallest banding to the biggest macroblocking without apparent "detail" loss.
If the video is so compressed that the detail becomes banding or blocking I don't think we should call it "detail" because there is none, nor should this "detail" should be somehow restored.
You can't restore something that looks like an ugly gradient into a cloud, or a square block into a dog can't you?...
Basically what I'm saying is that if the video is so compressed that there are visible blocking and banding, the 1-3 RGB steps of detail that create the black cat in the shadows, cannot be restored by any algorithm.
IMO, what a good debanding algo should do is remove the banding without effecting the clearly visible detail, the square macroblock cat is not there anymore no matter what you do.

If you ask me specifically about the edges of clear objects near the already debanded gradient (what I think is actual detail loss), I would say they look just as good as without debanding on all settings.
Maybe I'm just not observant enough, but to me it's all good, I am satisfied with the default or with shiandow's.

That's my take.

daert

15th May 2015, 17:14

2) Or you have the number of video frames which shall be presented in advance set to 16. I've just found out after releasing v0.88.7 that 15 is that max I can do. Using 16 means the D3D11 device creation fails. So lower this option to 14 (15 isn't currently supported), and D3D11 should start working again.

That's it! It works with 14 frame presented in advance. Thanks

So your blurred mode is known to Windows as 23p and your "good" mode is known to Windows as 24p? Which modes did you add to the madVR display mode changing list?

Yes, it's correct but in madvr display mode I have to set 1080p23 even if the "good" mode is 24p. If I set 1080p24 it will create a brand new resolution with exact 24.000 Hz which also has a blurred image like the original "bad" 23p.
In d3d9 (windowed and FSE) and d3d11 (windowed only) madvr treats the 1080p23 mode as the "good" one. Only in d3d11 FSE there is the switch with the "bad" one.
This switch occours even if I disable the display modes and set the "good" mode through the nvidia control panel

pie1394

15th May 2015, 17:34

I actually saw your comment and tried that before I posted last night. Thank you though.

Even with the default setting, it still shows FSE 8-bit mode before the monitor's native's bit depth is changed from 8-bit to 10-bit. After that change, FSE 10-bit mode works fine on mine with madVR 0.88.7.

- Core i5-3550K, Z87, DDR3-2400 8GB
- Win7x64 SP1
- HD7970/3GB + Catalyst Omega 14.12
- Sony 65HX920 @ 1920x1080p23~p60 (always) 10-bit signal modes.

QBhd

15th May 2015, 17:39

That's due to PotPlayer wanting to draw animations and stuff during paused playback. It's madVR's fault, really, but if you turn the PotPlayer madVR specific OSD off, this problem should go away for now. Of course then you'll probably lose the FSE compatible OSD, as well. The high GPU load in paused state with PotPlayer will probably be fixed in a future build, but it has low priority for now.

I had figured this out quite quickly when using D3D11... pressing the TAB key to pull up the OSD of PotPlayer would sort of kick madVR out of whack and it couldn't recover without a playback restart. Selecting "display messages on image itself" helped with the TAB OSD message... put pausing still borks madVR, even just clicking on the other desktop can do it. So I have resorted to not using D3D11.

QB

aufkrawall

15th May 2015, 17:59

I hope Shiandow will provide us with a shader so that we won't have to wait until Sunday for his new deband filter in madVR.

Other PP tests shouldn't be blocked for too long, I'm still very sure that SuperRes for chroma gives unwanted results and that NNEDI3 + SuperRes for luma beats everything by far and have found a nice demonstration.

MysteryX

15th May 2015, 17:59

SuperRes appears to work on 288p videos but not on 720p videos. Here are some screenshots. With the 720p video, rendering stats are unaffected by SuperRes. These are displayed on 768p display.

288p Normal
http://s8.postimg.org/ffdsynxjl/288p_Normal.jpg (http://postimg.org/image/ffdsynxjl/)

288p SuperRes (higher rendering time as expected)
http://s8.postimg.org/sxkpay9ox/288p_Super_Res.jpg (http://postimg.org/image/sxkpay9ox/)

720p Normal
http://s8.postimg.org/3stoxja8h/720p_Normal.jpg (http://postimg.org/image/3stoxja8h/)

720p SuperRes -- SuperRes isn't working!
http://s8.postimg.org/5957fod5d/720p_Super_Res.jpg (http://postimg.org/image/5957fod5d/)

Here I'm setting quality to high so that rendering times are more obvious.

That's in addition to very high rendering times on 1080p display. For the 288p video, with SuperRes 2 passes medium quality, rendering time goes from 6ms to 11ms in windowed mode. At 1080p, it was going from 14ms to 39ms! I'd have to take screenshots next time the TV is hooked up.

huhn

15th May 2015, 18:03

Sorry, can't help with that due to my colorblindness.

i'm pretty sure this has nothing to do with seeing banding.
you can easily get banding on a gray ramp.

huhn

15th May 2015, 18:06

I think there is something strange at play in madVR resulting in artifacts. Starting by setting both programs to defaults, then configuring both for 10-bit, using the same upscalers, DX11, Shiandow's debanding (with identical settings), SuperChromaRes, and SuperRes (with identical NEDI settings in both), and ordered dithering in both I am seeing more artifacts in madVR than MPDN in the same video scenes. I've included a screen shot below.
Anyone have theories as to what may be causing the additional artifacts in madVR?

http://s17.postimg.org/lznm6e7j1/madvr_vs_mpdn.jpg
In particular I notice the additional artifacts around the Japanese characters/letters, edge and teeth of the creature, and floating green debris. While its not a huge overall difference it is noticeable to me.

MPDN and madVR doesn't have the same JINC resizer. but i agree left is sharper and has a little bit more artifacts. should be easier to compare on 2 screens.

kasper93

15th May 2015, 18:09

720p SuperRes -- SuperRes isn't working!

Of course it isn't working, because you are downscaling image.

If you want to sharpen source image do it in "image enchantments" section.

MysteryX

15th May 2015, 18:27

Of course it isn't working, because you are downscaling image.

If you want to sharpen source image do it in "image enchantments" section.

When I play 720p in 768p full-screen, it is upscaling and isn't working either.

http://s2.postimg.org/9v4jfr439/720p_Upscale.jpg (http://postimg.org/image/9v4jfr439/)

huhn

15th May 2015, 18:29

madshi

15th May 2015, 18:33

I hope Shiandow will provide us with a shader so that we won't have to wait until Sunday for his new deband filter in madVR.
I don't think the new shader is "compatible" with the current madVR build. Unfortunately madVR is rather limited in its flexibility with custom shaders at the moment. (That is something I plan to work on in a future version.) So it will have to wait, I fear. Oh well, maybe I'll work on a new build today. <sigh> At some point I need to earn some money, too, though... :scared:

Other PP tests shouldn't be blocked for too long, I'm still very sure that SuperRes for chroma gives unwanted results and that NNEDI3 + SuperRes for luma beats everything by far and have found a nice demonstration.
There'll be a new SuperRes for chroma shader, too. The problem is if I collect feedback for everything from everyone, it will be a mess. The best thing would have been for me to introduce one new feature at a time. Then it wouldn't have "itched" you to discuss the other features now. But I didn't want to be so cruel to hold some new features back, just to get more orderly feedback!

i agree left is sharper and has a little bit more artifacts. should be easier to compare on 2 screens.
Yes, for a fair comparison it needs to be:

1) Same sharpness.
2) Same video frame.
3) Separate screenshots with 1:1 same pixel position.

Yes, it's correct but in madvr display mode I have to set 1080p23 even if the "good" mode is 24p. If I set 1080p24 it will create a brand new resolution with exact 24.000 Hz which also has a blurred image like the original "bad" 23p.
In d3d9 (windowed and FSE) and d3d11 (windowed only) madvr treats the 1080p23 mode as the "good" one. Only in d3d11 FSE there is the switch with the "bad" one.
This switch occours even if I disable the display modes and set the "good" mode through the nvidia control panel
Unfortunately there's only so much control I have over this. Direct3D has different ways to ask the GPU driver to switch to a specific display mode, and madVR tries to "fix" that, and that usually works, but in your case things seem to be somewhat confusing. I don't really know how to solve it, unfortunately. So I would say, stick with D3D9 for now. Maybe you can use this tool to cleanup the whole mess?

http://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU

If you ask me specifically about the edges of clear objects near the already debanded gradient (what I think is actual detail loss), I would say they look just as good as without debanding on all settings.
Maybe I'm just not observant enough, but to me it's all good, I am satisfied with the default or with shiandow's.
Ok, thanks for your feedback.

madshi

15th May 2015, 18:36

When I play 720p in 768p full-screen, it is upscaling and isn't working either.

http://s2.postimg.org/9v4jfr439/720p_Upscale.jpg (http://postimg.org/image/9v4jfr439/)
If the upscaling factor is very near to 100% then upscaling refinement doesn't become active. The key purpose of upscaling refinement is to get rid of softness caused by upscaling. If you only upscale by a tiny amount, there's almost no sharpness loss, so upscaling refinement is not needed then. Maybe I'll give you more control over this in a future build. But for now I've fixed upscaling factors which activate or deactivate SuperRes in specific situations.

Dogway

15th May 2015, 19:28

Let me know what you find!

So great, I tested the 10-bit ramps and my panel happens to be 10-bit, thanks for all the amazing work in madvr. Also tested the shaders without success. I'm not sure the MPC version has something to do with that, I use version 1.6.9.7418.

http://i.imgur.com/z2ggSgUt.png (http://i.imgur.com/z2ggSgU.png)

edit: nevermind, fixed with the hlsl files of finesharp 1.12. Will report later what I find.
edit2: did 6 conversions back and forth between YUV and RGB, indeed very transparent conversions, the next is a (exaggerated) diff sample for a very clean anime source, on a 720p slightly grainy live footage it was even less difference.
http://i.imgur.com/zi8CsMt.png

Thunderbolt8

15th May 2015, 19:45

At some point I need to earn some money, too, though... :scared:would you like us to send you some food? :D

madshi

15th May 2015, 20:33

edit2: did 6 conversions back and forth between YUV and RGB, indeed very transparent conversions, the next is a (exaggerated) diff sample for a very clean anime source, on a 720p slightly grainy live footage it was even less difference.
So you would agree that it's not a big issue that madVR performs one additional RGB -> YCbCr -> RGB conversion step (only when doing NNEDI3)?

would you like us to send you some food? :D
Haha! No, that wouldn't help much. It's not the food I'm concerned about, but my monthly bills. Well, I'll manage, just need to step away from madVR development and do some commercial stuff again in the next couple of days/weeks.

madshi

15th May 2015, 20:38

MS-DOS

15th May 2015, 20:46

You forgot to mention a nice small change to the OSD :)

Moony349

15th May 2015, 20:47

madVR v0.88.8 released

http://madshi.net/madVR.zip

* updated to latest Shiandow deband script
* fixed: D3D11 didn't activate with "frames presented in advance" set to 16
* fixed: ConfigureDisplayModeChanger(allowResolutionChanges = false) bug
So here's the latest Deband update again. Please retest - thank you! :)

(P.S: And you can set the number pre presented frames in advance back to 16 for D3D11, if you like. madVR will then automatically reduce it to 15.)

I must have tried changing every setting I could find...

Except for present frames in advance.

DX11 works now; thanks!

luk008

15th May 2015, 21:15

In D3D11 exclusive (10 bits), the render queue and the upload queue stay at 2-4 / 15. Why 2-4? Am I doing something wrong?

madshi

15th May 2015, 21:17

You forgot to mention a nice small change to the OSD :)
I didn't find it important enough to mention it in the changelog... :o

In D3D11 exclusive (10 bits), the render queue and the upload queue stay at 2-4 / 15. Why 2-4? Am I doing something wrong?
Which GPU? Which OS? Is that only a problem with 10bit? Or also with 8bit? Is it also a problem in windowed mode? Or only in FSE?

luk008

15th May 2015, 21:21

Which GPU? Which OS? Is that only a problem with 10bit? Or also with 8bit? Is it also a problem in windowed mode? Or only in FSE?

AMD R9 270 (driver 15.4)
Windows 8.1 x64
It only happens in D3D11 exclusive (10 bits). 8 bits, windowed and others are fine.

madshi

15th May 2015, 21:24

AMD R9 270 (driver 15.4)
Windows 8.1 x64
It only happens in D3D11 exclusive (10 bits). 8 bits, windowed and others are fine.
Can't reproduce that on my AMD HD7770 in Windows 8.1 x64. Have you tried resetting madVR to default settings? Also try rebooting, just to be safe.

mogli

15th May 2015, 21:31

luk008

15th May 2015, 21:33

Can't reproduce that on my AMD HD7770 in Windows 8.1 x64. Have you tried resetting madVR to default settings? Also try rebooting, just to be safe.

I've reboot and resetted madVR to default settings, but still the same problem. :(
Maybe a driver issue? Are you using 15.4 as well?

PS: How can I print the screen in FSE to show you the issue?

XMonarchY

15th May 2015, 21:36

Ok, let's do some more tests:

1) Leave all your settings just as they are, but rename one of the 3dlut files to something else (e.g. add "dummy" to the file name). madVR should then complain about the missing file. If you do this with a Rect.601 video file, then which file do you have to remain to make madVR complain?

2) If you toggle through the primaries (Ctrl+Alt+Shift+P), does that make madVR load the correct 3dlut?

OK I solved the problem. My content was actually labeled SMPTE 170M, not SMPTE C. When I toggled to SMPTE C using ctrl+alt+shift+p command, My Rec.601 3DLUT in SMPTE C line was used properly. The problem was that SMPTE 170M aws not detected as SMPTE C, even though ctrl+j menu reported that my SMPTE 170M content had "matrix BT.601". Its all a bit confusing...

Do you think you could add SMPTE 170M standard support for SMPTE C line or make an extra line for SMPTE 170M? AFAIK SMPTE C is the color gamut that uses Rec.601 primaries, while SMPTE 170M is the actual standard, not just the color gamut name. I mean its no big deal really, since I can toggle now.

MysteryX

15th May 2015, 21:39

Since SuperRes is being applied after resizing, shouldn't it have a similar performance hit no matter whether the source material is 288p or 480p?

For 288p material, SuperRes 2 pass causes rendering time to go from 6.2 to 11.9ms on 768p display

For 480p material, same setting causes rendering time to go from 9.3 to 20.2ms!

480p Normal
http://s9.postimg.org/j8u96o1yz/480p_Normal.jpg (http://postimg.org/image/j8u96o1yz/)

480p SuperRes
http://s9.postimg.org/qnjkz1nuj/480p_Super_Res.jpg (http://postimg.org/image/qnjkz1nuj/)

Output resolution is exactly the same.

MysteryX

15th May 2015, 21:43

Btw, is AMD driver 15.4 good? For Radeon HD 7670M, the best driver I found is LeeKM's modded driver v12.200 BETA. It is more stable than any other driver I tried, and whenever I try any other set of driver, I get worse performance so I always revert back to that one (which isn't available for download anymore). And apparently the late 13.x drivers work best for madVR.

Is 15.4 any faster or better than the 14.x or 13.x series?

luk008

15th May 2015, 21:45

Is 15.4 any faster or better than the 14.x or 13.x series?

15.4 is faster than 14.12. But I haven't tested 13.x or 12.x

cyberscott

15th May 2015, 21:57

Just tried 88.8. Previous to this version, the original debanding was beating out Shiandow deband script, even with the clear improvements since its' introduction into madVR
I can now say that Shiandow deband script included in 88.8 has now edged out madVR's deband to my eyes using Power 0.50 and Margin 0.02. :)

madshi

15th May 2015, 21:59

Small bug report:

Most movies finish without any drop or glitch. However since v0.88.x with D3D11 activated (and frame for every VSync off) very rarely randomly in a movie drops and glitches start to occur at about 20 per second (both per OSD and visible on screen). This happens only in FSE mode and doesn't stop by itself but only by switching to windowed mode once and back to FSE. It seems to occur more often with some interlaced NTSC DVDs then with 24p BDs but it isn't reproducible.
I guess some rare conditions can drive the D3D11 logic nuts.

Windows 8.1 x64, NVIDIA 350.12
I suppose you've unchecked the option "present a frame for every VSync"? This option is enabled by default. Re-enable it, and the problem will probably go away.

I've reboot and resetted madVR to default settings, but still the same problem. :(
Maybe a driver issue? Are you using 15.4 as well?

PS: How can I print the screen in FSE to show you the issue?
I don't know which driver version I'm using, it's pretty old. Definitely much older than 15.4. You can't print screen in FSE, unfortunately.

Ctrl+alt+shift+P during Rec.601 content playback shows "Source primaries: Auto-detect SMPTE (170M)
SMPTE 170M is not the same as SMPTE-C, I think. madVR at least treats them differently. That also explains why madVR is using the BT.709 3dlut.

But that cannot be the case because ctrl+J menu reports BT.601 primaries for my SMPTE 170M content...
That sounds strange that Ctrl+Alt+Shift+P shows something different than the debug OSD! Can I see a screenshot of the debug OSD with Ctrl+Alt+Shift+P overlayed on top of it?

Just tried 88.8. Previous to this version, the original debanding was beating out Shiandow deband script, even with the clear improvements since its' introduction into madVR
I can now say that Shiandow deband script included in 88.8 has now edged out madVR's deband to my eyes using Power 0.50 and Margin 0.02. :)
Ok, thanks for the feedback. Are you talking about madVR's "high" preset, only? Or do you find Shiandow's deband also better than madVR's "low" and "medium" settings? If so, which settings would you then suggest for "low" and "medium"?

More votes/opinions, please?

madshi

15th May 2015, 22:01

Since SuperRes is being applied after resizing, shouldn't it have a similar performance hit no matter whether the source material is 288p or 480p?

For 288p material, SuperRes 2 pass causes rendering time to go from 6.2 to 11.9ms on 768p display

For 480p material, same setting causes rendering time to go from 9.3 to 20.2ms!
Good question. I would say your comment makes sense. Don't know why the increase is higher for 480p material. But current priority is on debanding, not SuperRes.

luk008

15th May 2015, 22:03

I'll try to downgrade the driver.

I've taken a photo of my issue with FSE 10 bits: http://i.imgur.com/6dntf5u.jpg

bacondither

15th May 2015, 22:05

Arrgh... so many new versions in such short time, i'm drowning in them! :)

I'll do some deep testing with this new debanding majigger this weekend and i will hopefully come to some conclusion.

MysteryX

15th May 2015, 22:15

Good question. I would say your comment makes sense. Don't know why the increase is higher for 480p material. But current priority is on debanding, not SuperRes.
It's probably the same thing that is causing rendering on 1080p to go from 14ms to 39ms with SuperRes.

Btw, this new version allows me to add SuperRes for SD content on laptop, and Debanding on 1080p content (that needs no upscaling) looks great!

Is there a way to add this SuperRes effect to an AviSynth script? I like the effect it gives for upscaling SD to HD.

luk008

15th May 2015, 22:16

Older drivers have worse performance for R9 270 and don't solve the issue.

cyberscott

15th May 2015, 22:22

Ok, thanks for the feedback. Are you talking about madVR's "high" preset, only? Or do you find Shiandow's deband also better than madVR's "low" and "medium" settings? If so, which settings would you then suggest for "low" and "medium"?

More votes/opinions, please?

Oops, forgot to mention that I have always used High/High in madVR deband settings as this always looked best on the content I watch. Shiandow's deband default settings of Power 0.50 and Margin 0.00 is very close to madVR High/High settings to my eyes.

XMonarchY

15th May 2015, 22:23

That sounds strange that Ctrl+Alt+Shift+P shows something different than the debug OSD! Can I see a screenshot of the debug OSD with Ctrl+Alt+Shift+P overlayed on top of it?
More votes/opinions, please?

I edited my thread like 20 times to make it as clear as possible, so I am not sure which edition of my reply you're replying to, lol!

Just to recap, my content was labeled SMPTE 170M, which madVR treated differently from content labeled SMPTE C. When I toggled and enabled SMPTE C through ctrl+shift+alt+p, proper Rec.601 3DLUT in SMPTE C line was applied. 3DLUT's in SMPTE C line simply do not apply to SMPTE 170M content...

Here's a screenshot of the original ctrl+j menu WITHOUT toggling. It is how madVR "auto-detected" content I guess. madVR applied Rec.709 3DLUT from BT.709 line to this content.

https://dl.dropboxusercontent.com/u/93831976/madVR.jpg

I can't find how SMPTE 170M and SMPTE C differ in terms of primaries. They both use Rec. 601 primaries, gamma and D65 white point, don't they? I wonder if ArgyllCMS can create SMPTE 170M 3DLUT. Any ideas? I know this is madVR forum (not Display Calibration forum), but I figured you may know...

leeperry

15th May 2015, 22:24

Is 10bit supposed to work via DVI-SL on AMD with 13.12 and W7SP1?

I tried 88.7 and 88.8, enabled desktop composition in W7SP1, D3D11 10bit output in mVR with 8 frames in advance and I don't have desktop composition disabled in mVR.

I also tried to reboot after enabling Aero, reset mVR's defaults and run the latest nightly build of MPC-HC and I'm still stuck in DX9 land :(

The only reason I could think of is that I'm using a DVI-SL cable to my HDMI Sammy TV but 10bit is apparently supported via DVI (http://forum.doom9.org/showpost.php?p=1721414&postcount=29698) huh:
my Eizo CG243W does indeed accept full 10bit input over a single-link DVI-D connection (it doesn't have dual-link).

I didn't try 10bit earlier as I don't like Aero Peek, Aero's reflections effects on windows and when I switch from FSE to FSW in PotP with Aero off I get flashing black frames but when it's enabled I get zombie previous frames from the movie which is plain annoying.

NEDI has much stronger fractal artifacts than NNEDI3. However, SuperRes really helps there. So a combination of NEDI+SuperRes *may* be able to compete with NNEDI3. However, you can also combine NNEDI3 with SuperRes, too! So there's a lot of things to try out to find the best quality. But as I said, it's too early to discuss that. We'll come to SuperRes discussion sooner or later, but we're not there yet.
Using SR, EE is just too strong with NNEDI3 to my eyes as in moving objects feeling like cel shading, the picture screams DIGITAL(using ED2@8bit). Downscaling it with SR enabled on 720p content using CR AR LL is seriously too sharp whatever anime or live action, J3AR looks the most natural but is also way too soft.....NEDI makes for a nice in-between to my eyes, me like :)

I guess I could tame down SR'ed NNEDI3's über-sharpness with a softer downscaler as CR AR LL is too sharp and Softcubic50 AR LL obviously too soft but CR AR LL looks great with NEDI, the latter requiring far less ressources and also taking care of chroma kinda being the icing on the cake :cool:

I had figured this out quite quickly when using D3D11... pressing the TAB key to pull up the OSD of PotPlayer would sort of kick madVR out of whack and it couldn't recover without a playback restart. Selecting "display messages on image itself" helped with the TAB OSD message... put pausing still borks madVR, even just clicking on the other desktop can do it. So I have resorted to not using D3D11.
What's the "other desktop"? I only use PotP's D3D GUI, no other OSD.

I wouldn't need to break a sweat about 10bit no workee on my box if PotP becomes unusable to begin with.

i'm pretty sure this has nothing to do with seeing banding.
you can easily get banding on a gray ramp.
That's the thing, we're judging colorful banding and colorblinds see less tints.

XRyche

15th May 2015, 22:27

madVR v0.88.8 released

http://madshi.net/madVR.zip

* updated to latest Shiandow deband script
* fixed: D3D11 didn't activate with "frames presented in advance" set to 16
* fixed: ConfigureDisplayModeChanger(allowResolutionChanges = false) bug
So here's the latest Deband update again. Please retest - thank you! :)

(P.S: And you can set the number pre presented frames in advance back to 16 for D3D11, if you like. madVR will then automatically reduce it to 15.)

The frames in advance set to 16 was precisely the issue that I was having. Thank you for fixing it. When I got home i started tinkering with it and found that this was the exact issue and was just about to post it :) . It is now working for me exactly the way you described it. Set FSE pre-presented frames to 16 and it automatically sets it to 15.

aufkrawall

15th May 2015, 22:34

I still think that the old deband implementation is more efficient in terms of quality:
At high, it softens the image less than Shiandow's at 0.5 and fights banding still partially better (but also partially worse).
:) :(
imho there's not much room for highering the values when even 0.5 softens the image more than old algo@high.

Anyway, thank you two for your continuous great work! :thanks:

XRyche

15th May 2015, 22:44

I've reboot and resetted madVR to default settings, but still the same problem. :(
Maybe a driver issue? Are you using 15.4 as well?

PS: How can I print the screen in FSE to show you the issue?

I am currently using 15.3 and didn't have a que issue in FSE D3D11 10 bit. I'm downloading 15.4 now and will verify whether 15.4 is giving me the same issue as you, as soon as I restart.

madshi

15th May 2015, 22:44

The problem was that SMPTE 170M aws not detected as SMPTE C, even though ctrl+j menu reported that my SMPTE 170M content had "matrix BT.601". Its all a bit confusing...
Not at all. The matrix is a totally different thing from the primaries. E.g. EBU/PAL and SMPTE-C have different primaries, but use the same BT.601 matrix.

Do you think you could add SMPTE 170M standard support for SMPTE C line or make an extra line for SMPTE 170M? AFAIK SMPTE C is the color gamut that uses Rec.601 primaries, while SMPTE 170M is the actual standard, not just the color gamut name. I mean its no big deal really, since I can toggle now.
Hmmmm... Have checked the numbers. It does seem as if the primaries are the same. So probably I should use the SMPTE-C 3dlut for SMPTE-170M files. Btw, SMPTE-240M seems to use the same primaries, too - but a different matrix <sigh>.

Is 10bit supposed to work via DVI-SL on AMD with 13.12 and W7SP1?

I tried 88.7 and 88.8, enabled desktop composition in W7SP1, DCD11 10bit output in mVR with 8 frames in advance and I don't have desktop composition disabled in mVR.
Do you get D3D11 mode working at all? In windowed mode? Or with 8bit display bitdepth? I rather think that the problem is D3D11 mode in general, and not the 10bit.

Do you have the Windows 7 Platform Update installed? That's a requirement for madVR's D3D11 presentation path.

Using SR, EE is just too strong with NNEDI3 to my eyes as in moving objects feeling like cel shading, the picture screams DIGITAL(using ED2@8bit). Downscaling it with SR enabled on 720p content using CR AR LL is seriously too sharp whatever anime or live action, J3AR looks the most natural but is also way too soft.....NEDI makes for a nice in-between to my eyes, me like :)
There are different SR defaults for NNEDI3 compared to NEDI. Have you adjusted them? Also you can tame SR further down, if you still find it too sharp.

I'll try to downgrade the driver.

I've taken a photo of my issue with FSE 10 bits: http://i.imgur.com/6dntf5u.jpg
Looks like the presentation times are the problem. They probably slow rendering down so much that the rendering queue doesn't fill. Don't know why that happens - especially only in 10bit! Strange...

Arrgh... so many new versions in such short time, i'm drowning in them! :)

I'll do some deep testing with this new debanding majigger this weekend and i will hopefully come to some conclusion.
Great - looking forward to your feedback!

(Use only the latest version, ignore the older versions. Maybe that will stop you from drowning... :))

Oops, forgot to mention that I have always used High/High in madVR deband settings as this always looked best on the content I watch. Shiandow's deband default settings of Power 0.50 and Margin 0.00 is very close to madVR High/High settings to my eyes.
Ah ok. So probably no vote from you about old low/medium vs Shiandow?

The frames in advance set to 16 was precisely the issue that I was having. Thank you for fixing it. When I got home i started tinkering with it and found that this was the exact issue and was just about to post it :) . It is now working for me exactly the way you described it. Set FSE pre-presented frames to 16 and it automatically sets it to 15.
Good to hear!

I still think that the old deband implementation is more efficient in terms of quality:
At high, it softens the image less than Shiandow's at 0.5 and fights banding still partially better (but also partially worse).
:) :(
imho there's not much room for highering the values when even 0.5 softens the image more than old algo@high.
Thanks for your feedback!

I've done a quick comparison myself and also found that the old high algo works partially better and partially worse at debanding, while keeping slightly higher detail. Wasn't sure which I preferred overall...

sneaker_ger

15th May 2015, 22:47

Earlier someone pitched the idea of adding a fourth option ("ultra"/"very high") instead of replacing the current "high". Maybe that's viable solution?

madshi

15th May 2015, 22:58

Earlier someone pitched the idea of adding a fourth option ("ultra"/"very high") instead of replacing the current "high". Maybe that's viable solution?
As a last resort maybe, but only if that ultra option would deliver better debanding in all situations. Currently Shiandow's deband seems to be sometimes a bit stronger and sometimes a bit weaker in debanding strength compared to madVR's old "high" preset.

I would still prefer to keep just low/medium/high, and just replace some or all of the old presets with the new algorithm - of course only if the new one is really better. So, still waiting for more feedback!

aufkrawall

15th May 2015, 23:11

Maybe both algos can be combined at "ultra"?
There is hardly an additional detail loss when I enable old high and Shiandow's at 0.1/0 at the same time, but Shiandow's algo clearly reduces banding left by madVR's old one.

BetA13

15th May 2015, 23:21

Maybe you need to reapply the fix suggested by cyberbeing, which IIRC was clearing the madVR OpenCL registry storage key and then recreating the kernel with the 64bit madVR build.

Which modes do you have listed in the madVR display mode changer? And which exact mode does either D3D9 or D3D11 switch to? (Using the same video file)

wooow, that openCL reg fix worked flawless :) Perfect.

to the second part..
i have no modes listed there, i use the automatic detection. i think...

Picture...
http://s4.postimg.org/x6ge8tc21/sdfsfsdfsdfsdfsdfsdfsdf.jpg (http://postimg.org/image/x6ge8tc21/)

ill try to explain it a bit better...
i have an toshiba hd tv connected via HDMI.
Res. is 1920x1080 (i) ?, at 30hz. BUT in FSE its at 60hz/fps(with d3d9 new path)
Also, i had to resize the resolution with nvidia panel, when i set 1920x1080 i have stuff missing on top, sides, etc.. so i have to resize with nvidias tool...i dont know if this resizing is important to mention, so i just wrote it also...

pic:

[img=http://s10.postimg.org/l8ihbnqw5/dsfsdfsdfsdfsdfsdf.jpg] (http://postimg.org/image/l8ihbnqw5/)

its an old TV, but it works fine and the picture is awesome thanks to your fine work..

anyway, when i go into fullscreen exclusive mode usually what happens is that it displays 60hz/60fps also in OSD.

And thats what im used to, works perfect..

now when i enable this d3d11 mode, it goes to 25hz, changes the system resolution to TRUE 1920x1080 @ 25hz, wich is not what should happen, i guess.. and therefore teh picture isnt as fluid anymore..

greetz

edit:

i see tehres an new update, i shall try this first and report back :)