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. |
4th December 2012, 04:46 | #15941 | Link | |
Registered User
Join Date: Jun 2012
Posts: 5
|
Quote:
|
|
4th December 2012, 04:47 | #15942 | Link | |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
Quote:
1920x1080 -> 2560x1440 Default (lanc3 AR / bilinear) renders at around 41ms. Last edited by ajp_anton; 4th December 2012 at 04:51. |
|
4th December 2012, 05:25 | #15943 | Link | ||
Registered User
Join Date: Apr 2009
Posts: 1,019
|
Quote:
I'd really need to have one myself to use the same material and settings to do a proper comparison/test though. I would be interested in seeing what your numbers are for Bicubic 75 Chroma & Lanczos 3 without AR for Luma with the same material though. I really think that using Bilinear for Chroma is too much of a compromise, even if it would let you use Lanczos 3 AR. In the test I posted above, those settings almost halved rendering times - as good as it can look, I think the anti-ringing filter is probably too demanding to have enabled as a default. Quote:
EDIT: And from doing some extra testing, at least with some scale factors (I don't know if it will change dynamically) Nvidia basically using Bilinear scaling with the DXVA2 option. (results are slightly different) So it's even worse than I thought, considering that with madVR's Bilinear Luma scaling I was getting render times of about 3ms compared to the 50ms+ of DXVA2. EDIT2: Actually, it's worse than that - if you use DXVA2 for Luma upscaling, Chroma upscaling is basically ignored. Unless DXVA2 is handled a lot better on AMD/Intel, I wonder if it should actually be removed. It's maybe not identical to the bilinear option in madVR, but the results are still equally bad.
Render times are considerably higher with DXVA2 scaling as well. Last edited by 6233638; 4th December 2012 at 06:14. |
||
4th December 2012, 16:14 | #15944 | Link | |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
Quote:
Remember I upscale 1080p to 1440p, not what most people do, so I'd say speedwise 41ms it's just fine. And today it's 38ms. It seems to depend a little on what's in the actual image (which I find a little strange, unless it's because of the AR). 720p -> 1080p: Lanc3 AR + bilinear: 28ms Lanc3 + bicubic: 27ms Last edited by ajp_anton; 4th December 2012 at 16:16. |
|
4th December 2012, 17:58 | #15945 | Link |
Registered User
Join Date: Aug 2010
Posts: 576
|
I have an interesting problem. With hardware deinterlacing on my radeon, it doubles the frame rate, and thus, halves the movie frame interval, requiring even faster rendering than I can manage. Can I disable this in the registry somehow to keep the frame rate the same?
|
4th December 2012, 18:04 | #15946 | Link |
Registered User
Join Date: Mar 2007
Posts: 934
|
If the material is interlaced, that's what's supposed to happen (50/60p after deinterlacing). If it's progressive material in an "interlaced wrapper" (e.g. films or dramas in a TV stream) then it should be detected as such and deinterlaced using "weave", reproducing the original progressive image (25/30p after deinterlacing).
__________________
TV Setup: LG OLED55B7V; Onkyo TX-NR515; ODroid N2+; CoreElec 9.2.7 |
4th December 2012, 19:50 | #15949 | Link |
Registered User
Join Date: Oct 2011
Posts: 204
|
Many thanks for this piece of work, it's really great! However, I'd like to report a possible bug:
When switching the screen refresh rate (manually, not using the automatic Refresh Rate Changer) to 120Hz on my Laptop's internal 1080p screen, madVR stops outputting a picture. The Media Player window still changes its size to the video resolution in Windowed Mode, but both Fullscreen Exclusive and Windowed Mode only show a black picture. Interestingly, the Debug OSD (already enabled from before swit) doesn't display in Windowed mode, but in FSE, it briefly shows an additional line Code:
Desktop Composition Rate: 120.000Hz [there are a few trailing zeros, but I couldn't count them] Code:
display 0.000000Hz I should mention that EVR-CP works perfectly fine. My Setup: Code:
AMD Radeon HD 670M with up-to-date drivers Windows 7 Ultimate MPC-HC 1.6.5.6291 LAV Filters 0.54.1 ReClock 1.8.7.9 madVR 0.85.1 |
4th December 2012, 20:54 | #15950 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Quote:
|
|
4th December 2012, 20:57 | #15951 | Link | |||||||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Some day in the future I hope to be able to automatically switch between DXVA deinterlacing and madVR's IVTC. But that won't come any time soon. Quote:
Quote:
Quote:
Quote:
|
|||||||||||||||
4th December 2012, 21:27 | #15953 | Link |
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 (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. |
4th December 2012, 21:43 | #15954 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
I get huge DXVA2 decoding issues with this one. Usually the video area will just be transparent upon opening a file. Also, the MPC-HC process does not exit correctly and stays up and running.
The funny thing is that the debug version works better than the normal version, so I cannot just upload a log. (Well, I could anyways, of course.) |
4th December 2012, 21:54 | #15955 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
Care to elaborate why?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
4th December 2012, 22:10 | #15956 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Because external decoders have to first download the whole video frame from GPU RAM to CPU RAM, then put the data into an IMediaSample. Then the renderer has to upload it back to the GPU. So basically it's GPU -> CPU. Then CPU -> GPU. madVR can internally do this better because I have direct access to both the DXVA surface and the target texture at the same time. So I can directly copy from one GPU surface to the other GPU surface. So basically I only have to do half of the work compared to an external copyback decoder (GPU -> GPU). However, the whole frame has to go twice over the PCIe bus with my solution, too, so I'm not sure how much more efficient my solution really is. |
|
4th December 2012, 22:28 | #15958 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Quote:
Win 7 x64 LAV Splitter 0.54.1 MPC-HC 1.6.5.6187 madVR 0.85.2 (settings reset to standard settings) The decoder does seem to make a difference. In general LAV Video seems to be the most problematic, MPC's internal works best and Microsoft decoder is somewhere in between. Sometimes video doesn't start, sometimes seeking makes the player freeze. It's erratic and I have trouble narrowing it down further, but I will keep trying. Now even LAV Video works sometimes. Even if it does work, it takes about 0.5 seconds for the video to start. Does madVR do any checks at start up that could result in such a long delay? |
|
4th December 2012, 22:55 | #15960 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Now i cannot even reproduce the problem with LAV Video anymore. Maybe it was just the driver acting up again. I will keep an eye on the problem.
What still remains is the 0.5 seconds of transparent video area/delay until start. |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
|
|