View Single Post
Old 4th December 2012, 21:27   #15953  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
madVR v0.85.2 released

http://madshi.net/madVR.zip

Code:
* fixed: CoreAVC DXVA decoder didn't work (introduced in v0.85.1)
* fixed: ffdshow DXVA decoder didn't work
* fixed: when using DXVA2, sometimes BTB and WTW were lost
* fixed: thumbnail creation with MPC-HC sometimes didn't always
* fixed: Jinc option was sometimes incorrectly disabled
* fixed: 4:2:2/4:4:4 -> NV12 conversion routines used point sampling
* added dithering to 10/16bit -> NV12 conversion routines
* added SSE2 routine for P010/P016/P210/P216 -> NV12 conversion
* added options for custom display output levels
* added display specific color controls
* added volatile source color controls, with keyboard shortcuts
* brightness control now changes image gamma instead of white level
* contrast control now changes image contrast instead of black level
* custom shaders now run in PC levels (0-255) instead of TV levels
* added optimized DXVA copyback solution for NVidia and Intel GPUs
* optimized quality of DXVA2 NV12 -> HLSL NV12 conversion
* combined DXVA deinterlacing and DXVA scaling into one step
* modified DXVA scaling to now output RGB instead of NV12
* added color correction and auto-loading for new subtitle interface
* linear light processing might have gotten slightly faster
Some comments:

(1) madVR now supports 3 (!!) different color controls. I know, it's a bit confusing, but there's is some sort of sense to it: There are now (a) per-display color controls available in the madVR "device manager", which allows you to maybe optimize display setup/calibration. Then there are (b) "source" color controls available which you can only modify by assigning keyboard shortcuts to them. These "source" color control settings are not stored, so they reset themselves to neutral values when you close the media player or load a new video. You can change these source color controls to correct badly encoded videos without having to worry about resetting the color controls afterwards again. Then there are (c) the color controls of the media player. These don't really make too much sense because they are neither resetting themselves, nor are they really per monitor/display. But madVR supports them, nevertheless, just to have a complete solution.

(2) The "brightness" and "contrast" color controls now do not change the black and white levels, anymore. Instead they modify the look of the image to appear brighter/darker or more/less contrasty, while still keeping peak black and white identical. If you want to modify black and white output levels, you can now use the new custom output levels option in the madVR device manager. Or you can fix bad movie encodings by using the new "source black level" and "source white level" controls, which you can only modify by assigning a keyboard shortcut, and which auto reset themselves.

(3) I've totally reworked the way madVR deals with DXVA2 output. This is very very complicated, so let me try to explain:

A. When using DXVA2 scaling (regardless of whether DXVA2 deinterlacing and/or decoding is used), madVR asks DXVA2 to convert the NV12 source to RGB. madVR then auto analyzes what the GPU did and reverts the DXVA2 color conversion (RGB -> YCbCr 4:4:4), so that madVR can apply its own color conversion. This sounds bad? Yes, it is, but it seems to work nicely and it allows me to get rid of all the scaling problems like green lines with odd widths/heights which I had when asking DXVA2 to scale from NV12 -> NV12, and it also means that when using DXVA2 scaling now also chroma is always upsampled by DXVA2, too, which saves more power because madVR can then totally skip chroma upsampling. ATI and NVidia support output to high bitdepth RGB, so the whole process works nicely with ATI and NVidia (at least on Windows 7). Unfortunately Intel currently only outputs 8bit RGB, so there banding could be re-introduced. But I'm working with egur on that, maybe we can manage to get this fixed in the Intel drivers.

B. When not using DXVA2 scaling, but when using DXVA2 decoding and/or deinterlacing, madVR uses a different approach for NVidia and Intel GPUs compared to AMD GPUs. With AMD GPUs, madVR is able to access the DXVA2 NV12 output in lossless quality without needing to do fancy workarounds. With NVidia and Intel that's not possible, so with those I'm now using "copyback" to get lossless quality (only when your CPU supports SSE4.1, though). My copyback algorithm could/should be slightly more efficient than those used by external decoders, but I'm not sure by how much. Maybe someone can do a comparison test?

Generally I hope that colors are now always identical when using DXVA2 decoding, deinterlacing and scaling, compared to when not using any DXVA2 stuff at all. But I wasn't really able to test this in every filter & setting combination on every OS with every GPU, of course, so I'm relying on you guys to double check.

(4) Custom shaders should now produce 100% identical results to EVR/VMR9 (except for the broken "nightvision" shader script), except that madVR doesn't clip BTB/WTW, on the cost of probably slightly slower performance.

(5) madVR's 4:2:2/4:4:4 -> 4:2:0 and high-bitdepth -> 8bit conversion routines (when using DXVA2 deinterlacing and/or scaling) should now have highest possible quality with proper dithering + correct chroma handling. So banding should be noticeably reduced with e.g. 10bit encodes, when using DXVA2 scaling or deinterlacing.
madshi is offline   Reply With Quote