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. |
14th May 2015, 11:08 | #29921 | Link |
_
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. |
14th May 2015, 11:35 | #29922 | Link | |
Registered User
Join Date: Dec 2014
Posts: 34
|
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. |
|
14th May 2015, 12:04 | #29924 | Link |
Registered User
Join Date: Jun 2006
Posts: 350
|
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 |
14th May 2015, 12:45 | #29926 | Link |
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. |
14th May 2015, 13:36 | #29927 | Link | ||
Registered User
Join Date: Oct 2012
Posts: 7,903
|
Quote:
so you will learn nothing about this topic in this place. you have to try and see it for your self. Quote:
|
||
14th May 2015, 13:48 | #29929 | Link | |
Registered User
Join Date: Oct 2012
Posts: 7,903
|
Quote:
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. |
|
14th May 2015, 14:02 | #29931 | Link | ||
Registered User
Join Date: Jan 2005
Location: Germany
Posts: 52
|
Quote:
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. |
||
14th May 2015, 14:30 | #29933 | Link |
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. |
14th May 2015, 14:36 | #29934 | Link | |
Registered User
Join Date: Oct 2012
Posts: 7,903
|
Quote:
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. |
|
14th May 2015, 14:43 | #29935 | Link | |
Registered User
Join Date: Nov 2009
Posts: 2,352
|
Quote:
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 |
|
14th May 2015, 14:50 | #29936 | Link | |
Registered User
Join Date: Jan 2005
Location: Germany
Posts: 52
|
Quote:
|
|
14th May 2015, 14:55 | #29937 | Link | |
Registered User
Join Date: Oct 2012
Posts: 7,903
|
Quote:
so yes there are reasons for this. |
|
14th May 2015, 15:06 | #29938 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
|
Quote:
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. |
|
14th May 2015, 15:24 | #29939 | Link | |
Registered User
Join Date: Dec 2011
Posts: 1,812
|
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:
Why? Does madVR D3D11 automatically convert and dither in windowed mode, even if there was true 10 bit desktop output with DWM? |
|
14th May 2015, 15:27 | #29940 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
|
Quote:
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 |
|
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|