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. |
27th November 2013, 19:29 | #20981 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
So here's a new test build:
http://madshi.net/madVRanotherTestBuild1.rar (overwrite the official build with the files from this rar) Here's a list of changes compared to the last deband test build: (1) some calibration related fixes and improvements (2) madVR doesn't dither, anymore, when a pixel doesn't need dithering (3) fade in/out detection should have less false positives now (4) fade in/out rerendering shouldn't result in dropped frames, anymore (Please note that the included madHcNet64.dll is only for calibration purposes. It is *not* a sign of upcoming 64bit support. 64bit support is still not planned any time soon.) |
27th November 2013, 20:28 | #20982 | Link | ||
Registered User
Join Date: Sep 2013
Posts: 919
|
Quote:
Neeto! Thanks. Quote:
Last edited by James Freeman; 27th November 2013 at 20:32. |
||
27th November 2013, 21:05 | #20984 | Link |
Registered User
Join Date: Oct 2011
Posts: 41
|
With the new test build I get a "creating shader file failed" when opening any video (but the video works fine).
I also get a corrupted and green component only image when using DXVA for downscaling (did not test upscaling). Using Intel HD 4000 with driver version 10.18.10.3316. Everything was working fine with the previous (deband) test build. |
27th November 2013, 21:25 | #20985 | Link | ||
Registered User
Join Date: Nov 2012
Posts: 167
|
Quote:
EDIT: The OSD needs to be open for this to happen. Also happens when opening the OSD (CTRL+J) with the file already playing. Quote:
Worked while tested with 4:2:2/4:4:4 8bit, 4:2:0 10bit and RGB output from LAVFilters. Last edited by michkrol; 27th November 2013 at 21:34. |
||
27th November 2013, 23:42 | #20988 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Yes, madVR uses triangular dither, but it's applied pixel by pixel without looking at neighbors. So basically every pixel is handled totally separately. The new algorithm still applies dither the same way as before. However, before applying dither it now checks whether the final 8bit output value happens to be a simple cardinal number with no fractional part. If that is the case, dithering doesn't really help because the pixel is already perfectly reproducing the needed value even without dither. So in that situation dither for that pixel is simply not applied, any longer.
|
27th November 2013, 23:44 | #20989 | Link | |
Registered User
Join Date: Nov 2011
Location: Denmark
Posts: 137
|
Quote:
12 minutes in the movie: 18 presentation glitches 121 dropped frames Last edited by MSL_DK; 27th November 2013 at 23:50. |
|
27th November 2013, 23:49 | #20990 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
You can contribute a much more detailed description. When. Where. Under which circumstances. With all videos or some. Which OS. Which GPU. Are any queues (near) empty in the madVR debug OSD (Ctrl+J) when the frame drops occur etc...
|
28th November 2013, 00:12 | #20991 | Link |
Registered User
Join Date: Nov 2011
Location: Denmark
Posts: 137
|
With all movies. Windows 7 x64, ATI HD 4800 (1080p, 60 Hz), Intel E8500, 8 GB of RAM. Yes .. render queue 0-6, pressent queue 0-1. I can not manage to see if it's right before I experience dropped frames, or after.
FSE: Yes Smooth motion: Yes, always I have not made any changes. But experience a lot of dropped frames with the latest test build. EDIT: I have gone back to version 0.86.11 and did not experience a single dropped frame after 40 minutes playback vs 121 dropped frames after 12 minutes playback with the test version. Last edited by MSL_DK; 28th November 2013 at 00:29. |
28th November 2013, 06:58 | #20993 | Link |
Registered User
Join Date: Mar 2009
Posts: 3,650
|
Technically yes with PQ, but even with dithering disabled I never saw any differences, the color changes are so subtle that I don't think anyone would really notice it. As far as lower GPU usage goes, I'm not seeing a difference with full HD content, maybe 4K might show something. I'm all for efficiency and PQ improvement even if I can't measure it and see it, I know it's there, one step closer to perfection I guess.
Maybe something was corrupt or there were incompatible versions of things mixed together, I've updated to the new build and I no longer experience the crashes. It was happening on both my machines, oh well. Fixed. Last edited by ryrynz; 28th November 2013 at 07:09. |
28th November 2013, 09:28 | #20995 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
It should actually ever so slightly *increase* the GPU load because I had to add a check for whether dithering is needed or not. The GPU load increase is probably rather small, though. The disabling of dithering for pixels which don't need it is has 3 potential benefits: (1) With full black or white video areas, dithering ever so slightly increased the black level and decreased peak white brightness. This also meant that some displays didn't "recognize" full black video areas, due to dithering, and thus they didn't turn off the local dimming LEDs etc. With the new test build, hopefully this problem should be solved. (2) The LightSpace CMS calibration developer told me that he prefers dithering to be off during display profiling. So I made this possible this way now. (3) Having dithering disabled if it's not needed might slightly decrease the overall noise floor, but this is not a planned benefit, just a side effect, and the difference might be nearly invisible in most situations. |
|
28th November 2013, 10:08 | #20996 | Link | |
Registered User
Join Date: Dec 2008
Posts: 496
|
Quote:
What I am also wondering about is that I always thought that dithering is basically applied to better represent the source as a whole (by adding noise), while still living with the limits of the actual bitdepth. Now, if madVR selectively decides that based on individual pixels on real content (not talking about just pure black or pure white here), wouldnīt that lead to "uneven" areas inside the actual picture itself? Or is that effect almost neglectable, because madVR is processing at a lot higher bitdepth, before dithering gets applied at the very last stage before sending it out to the display? Thanks a lot for still adding such important core functionality even this late into development. Last edited by iSunrise; 28th November 2013 at 10:27. |
|
28th November 2013, 10:23 | #20997 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
The pixel shader simply checks for each pixel if the final 8bit value has a fractional part or not, without looking at neighbor pixels. Yes, it's some sort of "if" processing, and due to the way HLSL works, dithering is still calculated for all pixels but then simply discarded for some, so GPU load increases instead of decreasing. However, madVR is mostly memory bandwidth limited, so some extra code in the shaders which doesn't consume additional memory bandwidth usually doesn't harm all that much. GPUs don't like dynamic branching a lot, but simple "if" statements which result in using either value A or value B can be implemented without dynamic branching, so they're not too expensive.
|
28th November 2013, 10:46 | #20999 | Link | |
Registered User
Join Date: Dec 2008
Posts: 496
|
Quote:
Last edited by iSunrise; 28th November 2013 at 11:09. |
|
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
|
|