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 14th May 2015, 11:08   #29921  |  Link
pirlouy
_
 
Join Date: May 2008
Location: France
Posts: 692
That's the reason why madshi wants to remove options. People like him (or me) just don't understand if it's good or bad.

@x7007: If you're unsure of these options, don't enable them now. For now, madshi only wants feedback on debanding. So if you want to test something, test only what he said in his post. You'll do tests on Upscaling refinement later.
pirlouy is offline   Reply With Quote
Old 14th May 2015, 11:35   #29922  |  Link
a8213711
Registered User
 
Join Date: Dec 2014
Posts: 34
Quote:
Originally Posted by huhn View Post
RGBA

red green blue and alpha channel.
it "is" 24 bit or 8 bit per channel.
So can I safely say it doesn't support 10bit simply looking at that image?




Another thing:
since I found some trade-off already enabled on a clean install (right after a format), I wonder how madVR detects which settings to apply (are these restrained only to trade-off?) and how are calculated.
a8213711 is offline   Reply With Quote
Old 14th May 2015, 11:47   #29923  |  Link
luk008
Registered User
 
Join Date: Aug 2011
Posts: 38
Madvr 0.88.6 is not using the whole render in FSE with D3D11. I'm using 8.1 x64.
luk008 is offline   Reply With Quote
Old 14th May 2015, 12:04   #29924  |  Link
GCRaistlin
Registered User
 
GCRaistlin's Avatar
 
Join Date: Jun 2006
Posts: 350
Quote:
Originally Posted by madshi View Post
Well, to be honest, I don't think this is a good time to add this feature. The whole refresh rate changing will be rewritten sooner or later and work quite differently to how to works now. It makes more sense to wait until then.
It is surely up to you but I'd be really grateful if you add this feature independently of rewriting the refresh rate changing - its current implementation works OK, and this means that rewriting will be rather "later" than "sooner".
__________________
Windows 8.1 x64

Magically yours
Raistlin
GCRaistlin is offline   Reply With Quote
Old 14th May 2015, 12:05   #29925  |  Link
pirlouy
_
 
Join Date: May 2008
Location: France
Posts: 692
@luk008: Answer is 3 posts earlier: known issue
pirlouy is offline   Reply With Quote
Old 14th May 2015, 12:45   #29926  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Shiandow, your new algorithm gives some interesting results.

madVR high:


Shiandow 0.2; 1:


Shiandow 0.7; 2:


Shiandow 1.0; 1:


0.2; 1 vs madVR high:
I'd say madVR high hardly vanishes any detail (Shiandow neither), but it looks much better with the upper blue gradient.

This is still the case with setting Shiandow threshold to 1.0: Upper gradient still looks better with madVR deband high, but now Shiandow's algorithm already reduces quite an amount of detail (e.g. the jacket is less sharp).
However, the blue gradient in the lower half of the image isn't processed well by madVR deband, there Shiandow now looks much better.

Detail loss can be prevented by highering the detail level. But the behavior for the upper image half needs to be improved.
It'd be great if your algorithm could cover it as well as the lower one, then it'd be probably better than madVR's older one.
aufkrawall is offline   Reply With Quote
Old 14th May 2015, 13:36   #29927  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
Quote:
Originally Posted by a8213711 View Post
So can I safely say it doesn't support 10bit simply looking at that image?
this is the desktop bit deep. the windows desktop can't do 10 bit.
so you will learn nothing about this topic in this place. you have to try and see it for your self.

Quote:
Another thing:
since I found some trade-off already enabled on a clean install (right after a format), I wonder how madVR detects which settings to apply (are these restrained only to trade-off?) and how are calculated.
they are just checked my default the same on any PC.
huhn is offline   Reply With Quote
Old 14th May 2015, 13:45   #29928  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Quote:
Originally Posted by huhn View Post
this is the desktop bit deep. the windows desktop can't do 10 bit.
Are you sure? DWM is always 8 bit, even if e.g. in the CCC 10 bit is selected?
aufkrawall is offline   Reply With Quote
Old 14th May 2015, 13:48   #29929  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
Quote:
Originally Posted by leeperry View Post
Oh my, thanks for the daily updates and killer features

If I check and then uncheck "octuple luma/chroma resolution", I can't uncheck "double chroma resolution" and "quad chroma resolution" anymore, bug?

This said, 8X is complete overkill for 1080p, I still would like to try it coz there used to be a feature in Avisynth where you would massively upscale, process and then downscale at the very last stage. NEDI is so GPU efficient than why not giving it a shot on 360*288@1080p+NEDI/SuperRes

I guess 8X luma only isn't possible due to the pixel shifts? I'm not too keen on wasting GPU cycles on chroma.

i can't get octuple to work what so ever.

and the pixel shift shouldn't matter at all it's not like you have to shift the picture in the same direction every time.
huhn is offline   Reply With Quote
Old 14th May 2015, 13:49   #29930  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
Quote:
Originally Posted by aufkrawall View Post
Are you sure? DWM is always 8 bit, even if e.g. in the CCC 10 bit is selected?
of cause.
you need FSE to get 10 bit.
this may change with windows 10.
huhn is offline   Reply With Quote
Old 14th May 2015, 14:02   #29931  |  Link
ibius
Registered User
 
Join Date: Jan 2005
Location: Germany
Posts: 52
Quote:
Originally Posted by madshi View Post

Quote:
Originally Posted by ibius View Post
Issues with D3D11:
2. After going windowed FS or FSE, render queue is always only 3-5/8, other queues are full, and I get increased CPU usage, e.g. from ~7% to ~30% on my 3,6GHz Intel Core2Duo.
3. Sometimes after seeking/stopping playback video gets stuck in a loop, jumping between few frames.
4. Render times are better compared to D3D9, but present times are way worse, e.g. going from 0.12ms to 0.9x/1.xx ms in windowed mode, in windowed FS or FSE they are even higher (although only chroma is scaled).
This is exactly the effect you would get with "Nvidia control panel 'Max. pre-rendered frames'" set to a fixed low value. So my best guess is that either the GPU uses a different setting for this behind your back, or there are profiles active somehow which set a low value for this, or there's some GPU driver bug, or something.
I never used profiles, and to be sure none were created by an application I double-checked in Nvidia control panel and in NvidiaInspector. Also, I tried two different driver versions besides the one I was on, I uninstalled previous driver and clean-installed new ones each time, didn't help.

So, I tried actually setting 'Max. pre-rendered frames' to a fixed value to see how madVR would behave, I had a choice between 1-4 frames.

With max. 4 pre-rendered frames my render queue was 2-4/8 and now also present queue wouldn't fill up staying at 4-5/8, with still unusually high CPU usage in fullscreen.

With max. 1 pre-rendered frame my render and present queues were both at 1-2/8, but without unusually high CPU usage in FS.

Note: in both tests I only got those queue values after going into FSE, in windowed/FS modes render queue was 3-5/8 and present queue was full.


I also did some tests with flush settings, where I found something interesting.

Note: Before these tests I had them all at 'Dont flush'.

First I set them to defaults: Flush, Flush and wait (sleep), Don't Flush and Don't Flush - nothing changed.

Then after experimenting with each one individually I found out that 'Flush and wait (sleep) after copy to backbuffer' lowers present times back down a little (from ~0.90ms to ~0.22ms), and no more high CPU usage, but render queue still remains at 3-5/8.

Also, setting 'after copy to backbuffer' to 'Flush' or 'Flush and wait (loop)', I get high CPU usage even in windowed mode, without going FS or FSE.


PS: I think issue 3 is fixed with 0.88.6 build, at least I didn't encounter it during my tests today, usually it happend at least once during 1-2 tests when seeking/pausing/stopping the video.
ibius is offline   Reply With Quote
Old 14th May 2015, 14:28   #29932  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Quote:
Originally Posted by huhn View Post
of cause.
you need FSE to get 10 bit.
this may change with windows 10.
What the heck is then the option for bitdepth in the CCC for?
aufkrawall is offline   Reply With Quote
Old 14th May 2015, 14:30   #29933  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 496
When doing tests, one should always re-test with madVR defaults. That would make configuration-based problems a lot faster to catch for madshi.

Also, I wonder since a lot of people are using >350 drivers, whether the newest Quadro ones (348.07) still show the same problems. I always use the newest Quadro release and besides crashes and apparent madVR bugs (which can be ruled out by returning to the last madVR release) they served me very well.

Also, I never once had driver-related crashes with them, not once. Every crashes that I had, clearly were a madVR bug which madshi fixed instantly.
iSunrise is offline   Reply With Quote
Old 14th May 2015, 14:36   #29934  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
Quote:
Originally Posted by aufkrawall View Post
What the heck is then the option for bitdepth in the CCC for?
what is send over HDMI/DP/DVI/otherstuff.
it's not that complicated. you can send 8 10 and 16 bit to a GPU using something like d3d11 FSE.
without d3d11 madVR is "only" outputting 8 bit to the GPU driver and the GPU driver is than outputting that as set in the GPU driver.
10 bit is for specialized software. on windows 7 adobe photo disabled aero to output 10 bit using openGL.
not sure how that works with windows 8 and newer but even windows 7 overlay doesn't care about DWM.

one thing is clear.
to get 10 bit out of madVR you need d3d11 10 bit mode with FSE.
huhn is offline   Reply With Quote
Old 14th May 2015, 14:43   #29935  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,352
Quote:
Originally Posted by Asmodian View Post
Isn't that the same thing?

1920x1080p 4:2:0 source.

step 1) 960x540 chroma to 1920x1080 using 'chroma upscaling'. This is the only step 'chroma upscaling' is used for. This converts the 4:2:0 to 4:4:4.
step 2) 1920x1080 chroma to 3840x2160 with NNEDI3 (chroma doubling) or, if not doubled, to the target resolution with 'image upscaling'.
it's not, you are describing a best scenario example.
this is what happens currently with 720p as far as I have been told here:

1280x720p 4:2:0 source.

step 1) 640x360 chroma to 1280x720 using 'chroma upscaling'. This converts source to 4:4:4
step 2) 1280x720 chroma doubling to 2560x1440 using NNEDI3.
step 3) 2560x1440 to target display resolution using chroma upscale/downscale kernel (a question is this one the same as step 1? this was the question I asked in my last post)

As you see this involves 3 resizes for chroma (not counting the resizes the source suffered first from rip)
I think a better approach -2 resizes- would be the next, although I know there might be obvious reasons not to do like this.

step 1) 640x360 chroma doubling to 1280x720 using NNEDI3. This converts source to 4:4:4
step 2) 1280x720 to target display resolution using chroma upscale/downscale kernel
Dogway is offline   Reply With Quote
Old 14th May 2015, 14:50   #29936  |  Link
ibius
Registered User
 
Join Date: Jan 2005
Location: Germany
Posts: 52
Quote:
Originally Posted by iSunrise View Post
Also, I wonder since a lot of people are using >350 drivers, whether the newest Quadro ones (348.07) still show the same problems. I always use the newest Quadro release and besides crashes and apparent madVR bugs (which can be ruled out by returning to the last madVR release) they served me very well.

Also, I never once had driver-related crashes with them, not once. Every crashes that I had, clearly were a madVR bug which madshi fixed instantly.
Same here, I also never had driver-related crashes. I don't play games so I don't bother with 'Game Ready' drivers, but I did test latest 350.12 to be sure. Before, I was on 340.52 which is one of the most stable drivers for the Fermi family, it also comes recommended from Windows Update on Win8.1, at least for my GTX 550Ti. I also tried 331.82 version, which with 314.22 (supports up to Win8 only) are the other stable drivers, and 331.82 gives me even lower render times (only by ~0.10-20ms) than 340.52.
ibius is offline   Reply With Quote
Old 14th May 2015, 14:55   #29937  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
Quote:
Originally Posted by Dogway View Post
it's not, you are describing a best scenario example.
this is what happens currently with 720p as far as I have been told here:

1280x720p 4:2:0 source.

step 1) 640x360 chroma to 1280x720 using 'chroma upscaling'. This converts source to 4:4:4
step 2) 1280x720 chroma doubling to 2560x1440 using NNEDI3.
step 3) 2560x1440 to target display resolution using chroma upscale/downscale kernel (a question is this one the same as step 1? this was the question I asked in my last post)

As you see this involves 3 resizes for chroma (not counting the resizes the source suffered first from rip)
I think a better approach -2 resizes- would be the next, although I know there might be obvious reasons not to do like this.

step 1) 640x360 chroma doubling to 1280x720 using NNEDI3. This converts source to 4:4:4
step 2) 1280x720 to target display resolution using chroma upscale/downscale kernel
madVR always converts to RGB first for debanding and other stuff that needs RGB.

so yes there are reasons for this.
huhn is offline   Reply With Quote
Old 14th May 2015, 15:06   #29938  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by Dogway View Post
it's not, you are describing a best scenario example.
this is what happens currently with 720p as far as I have been told here:

1280x720p 4:2:0 source.

step 1) 640x360 chroma to 1280x720 using 'chroma upscaling'. This converts source to 4:4:4
step 2) 1280x720 chroma doubling to 2560x1440 using NNEDI3.
step 3) 2560x1440 to target display resolution using chroma upscale/downscale kernel (a question is this one the same as step 1? this was the question I asked in my last post)

As you see this involves 3 resizes for chroma (not counting the resizes the source suffered first from rip)
I think a better approach -2 resizes- would be the next, although I know there might be obvious reasons not to do like this.

step 1) 640x360 chroma doubling to 1280x720 using NNEDI3. This converts source to 4:4:4
step 2) 1280x720 to target display resolution using chroma upscale/downscale kernel
"Chroma Upscaling" is only ever performed in the first step, 4:2:0 to 4:4:4. Its not used for anything else. This allows the chroma upscaler to be somewhat specialized, since it always does a flat 2x upscale, and will never do anything else.

All other scale operations that affect chroma are performed using the image up/down scaling algorithms, because scaling is usually performed in RGB (with the exception of NNEDI3, were Luma and Chroma can be split)

.. and the whole process is only a 2 step process, unless you use NNEDI3 and a final scale is required. If you don't want that, then don't enable NNEDI3 chroma doubling!

1) Chroma scaling 4:2:0 -> 4:4:4 using the "chroma upscaling" algorithm (which might be NNEDI3 if you set that, note however that this is not "chroma doubling", but "chroma upscaling"!)
(optional) 2) NNEDI3 chroma doubling
3) Scaling to final output size using image scaling algorithm

If you don't use NNEDI3, then its the two steps that you want, except that it uses different algorithms than you think.
Its important to note that you can also simply select NNEDI3 as a "chroma upscaling" algorithm, if thats something you want.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 14th May 2015 at 15:23.
nevcairiel is offline   Reply With Quote
Old 14th May 2015, 15:24   #29939  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Quote:
Originally Posted by huhn View Post
what is send over HDMI/DP/DVI/otherstuff.
So, if 8 bit are selected in the CCC, it will output a signal with this bitdepth, even though applications in FSE used 10 bit?

Quote:
Originally Posted by huhn View Post
not sure how that works with windows 8 and newer but even windows 7 overlay doesn't care about DWM.
Well, this was exactly my question, which remains open.

Quote:
Originally Posted by huhn View Post
one thing is clear.
to get 10 bit out of madVR you need d3d11 10 bit mode with FSE.
Why? Does madVR D3D11 automatically convert and dither in windowed mode, even if there was true 10 bit desktop output with DWM?
aufkrawall is offline   Reply With Quote
Old 14th May 2015, 15:27   #29940  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by aufkrawall View Post

Why? Does madVR D3D11 automatically convert and dither in windowed mode, even if there was true 10 bit desktop output with DWM?
It probably would, but there is no 10-bit desktop output in Windows. Once there is, madshi will probably support that for us.
It may be something MS is secretly working on for Windows 10, as some signs have hinted at that, but nothing is confirmed.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel 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 21:40.


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