Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th May 2015, 18:29   #30061  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
Quote:
Originally Posted by MysteryX View Post
When I play 720p in 768p full-screen, it is upscaling and isn't working either.

the scaling factor is to low to make a huge difference.
huhn is offline   Reply With Quote
Old 15th May 2015, 18:33   #30062  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by aufkrawall View Post
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...

Quote:
Originally Posted by aufkrawall View Post
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!

Quote:
Originally Posted by huhn View Post
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.

Quote:
Originally Posted by daert View Post
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/Th...on-Utility-CRU

Quote:
Originally Posted by James Freeman View Post
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 is offline   Reply With Quote
Old 15th May 2015, 18:36   #30063  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by MysteryX View Post
When I play 720p in 768p full-screen, it is upscaling and isn't working either.

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.
madshi is offline   Reply With Quote
Old 15th May 2015, 19:28   #30064  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,352
Quote:
Originally Posted by madshi View Post
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.



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.

Last edited by Dogway; 15th May 2015 at 19:58.
Dogway is offline   Reply With Quote
Old 15th May 2015, 19:45   #30065  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
Quote:
Originally Posted by madshi View Post
At some point I need to earn some money, too, though...
would you like us to send you some food?
__________________
Laptop Lenovo Legion 5 17IMH05: i5-10300H, 16 GB Ram, NVIDIA GTX 1650 Ti (+ Intel UHD 630), Windows 10 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64) (K-lite codec pack)
Thunderbolt8 is offline   Reply With Quote
Old 15th May 2015, 20:33   #30066  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Dogway View Post
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)?

Quote:
Originally Posted by Thunderbolt8 View Post
would you like us to send you some food?
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 is offline   Reply With Quote
Old 15th May 2015, 20:38   #30067  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
madVR v0.88.8 released

http://madshi.net/madVR.zip

Code:
* 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.)
madshi is offline   Reply With Quote
Old 15th May 2015, 20:46   #30068  |  Link
MS-DOS
Registered User
 
Join Date: Sep 2012
Posts: 77
You forgot to mention a nice small change to the OSD
MS-DOS is offline   Reply With Quote
Old 15th May 2015, 20:47   #30069  |  Link
Moony349
Registered User
 
Join Date: Sep 2012
Posts: 25
Quote:
Originally Posted by madshi View Post
madVR v0.88.8 released

http://madshi.net/madVR.zip

Code:
* 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!
Moony349 is offline   Reply With Quote
Old 15th May 2015, 21:15   #30070  |  Link
luk008
Registered User
 
Join Date: Aug 2011
Posts: 38
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?
luk008 is offline   Reply With Quote
Old 15th May 2015, 21:17   #30071  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by MS-DOS View Post
You forgot to mention a nice small change to the OSD
I didn't find it important enough to mention it in the changelog...

Quote:
Originally Posted by luk008 View Post
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?
madshi is offline   Reply With Quote
Old 15th May 2015, 21:21   #30072  |  Link
luk008
Registered User
 
Join Date: Aug 2011
Posts: 38
Quote:
Originally Posted by madshi View Post
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.
luk008 is offline   Reply With Quote
Old 15th May 2015, 21:24   #30073  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by luk008 View Post
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.
madshi is offline   Reply With Quote
Old 15th May 2015, 21:31   #30074  |  Link
mogli
Registered User
 
Join Date: May 2015
Posts: 106
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
mogli is offline   Reply With Quote
Old 15th May 2015, 21:33   #30075  |  Link
luk008
Registered User
 
Join Date: Aug 2011
Posts: 38
Quote:
Originally Posted by madshi View Post
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?
luk008 is offline   Reply With Quote
Old 15th May 2015, 21:36   #30076  |  Link
XMonarchY
Guest
 
Posts: n/a
Quote:
Originally Posted by madshi View Post
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.

Last edited by XMonarchY; 15th May 2015 at 22:08.
  Reply With Quote
Old 15th May 2015, 21:39   #30077  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,559
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


480p SuperRes


Output resolution is exactly the same.

Last edited by MysteryX; 24th June 2015 at 06:10.
MysteryX is offline   Reply With Quote
Old 15th May 2015, 21:43   #30078  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,559
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?

Last edited by MysteryX; 24th June 2015 at 06:10.
MysteryX is offline   Reply With Quote
Old 15th May 2015, 21:45   #30079  |  Link
luk008
Registered User
 
Join Date: Aug 2011
Posts: 38
Quote:
Originally Posted by MysteryX View Post
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
luk008 is offline   Reply With Quote
Old 15th May 2015, 21:57   #30080  |  Link
cyberscott
Registered User
 
Join Date: Oct 2007
Posts: 92
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.
cyberscott is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 22:45.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.