madVR - high quality video renderer (GPU assisted)

[madshi]

image upscaling - Jink 4 or 8 select
go to
croma upscaling - Jink 3
go to
image downscaling - Spline 4
go to
image upscaling - Jink 4 or 8 be in false
Thanks, this will be fixed in v0.85.2.

Don't know if this has been mentioned yet, but DXVA decoding with default settings crashes MPC-HC for me about 50% of the time when viewing 23.976p material. This only happens when skipping forward or backward, however if the player does not crash, I can skip forward safely as many times as I please. I am using LAV filters and a laptop with ATI 4670.
Does this occur with all 23.976p movies for you, or just with some? Does it e.g. depend on the codec? Have you updated to the latest LAV version? I've not heard about such instability by anyone else yet, so I wonder why it only seems to affect you. Maybe it's just with some specific video files?

I'm not sure if I understand completely yet. Can increasing or decreasing queue sizes help reduce dropped frames? Ever since I set up yCMS color calibration with madvr, I've had a good amount frame dropping, and I need to do something to make up for the performance loss. Is there anything I can do other than get another GPU (not an option, as I'm on a laptop).
You could try turning down the scaling algorithms. In the worst case you could try bilinear (ouch). Tuning the queue sizes might have minor effects, but nothing major, so I don't think it will help.

I really don't think that having Bilinear as the default for Chroma is a good choice. As Chroma is only ever a 2x scaling operation, the performance impact of using a better scaling algorithm seems to be minimal in most cases.
Interesting. I haven't really measured performance, but it makes some sense. Chroma upsampling is cheaper because I hard coded it to do exactly 2x which allowed me to write more efficient shader code. Maybe using Bilinear as default for chroma upsampling isn't necessary. But then we come back to the very old discussion about which algorithm to use instead, and we never seem to be able to agree there...

While not related to selecting good defaults, in my testing, I also happened to come across a use-case for Jinc 8. There are some images I came across where using Jinc 8 AR for Chroma was the only option that looked really good, being the only choice that avoided aliasing and maintained the correct brightness/saturation for Chroma. This is not an endorsement of using it, as there are most likely problems using it with other images (as there tends to be with higher-tap filters) but I thought it was interesting.

The only other algorithm that looked decent with this image was SoftCubic 100, which was too dull/desaturated, but avoided most of the aliasing.
Yeah, my preference for using SoftCubic 100 is exactly that it avoids aliasing quite nicely with problematic sources. I've recently found a broadcast where a guy was wearing a black/red patterned jacked and it looked so much less bad with SoftCubic 100 compared to e.g. Bicubic or Lanczos.

Now I don't suggest that SoftCubic 80 be the default for Luma at all, but I worry that Lanczos 3 AR will be too taxing for a lot of hardware.
I really hoped that going from Lanczos 4 (original default) to Lanczos 3 would allow me to activate AR by default, but maybe you're right and it's too taxing. However, from HD 4000 reports it seems that Lanczos 3 AR is not really a problem. So the big quesion is which hardware to use as reference.

From looking at those numbers, I think that it would probably be best to use Bicubic 75 Chroma, which can be a significant visual improvement over Bilinear in many cases (often a close visual match to Lanczos or Jinc) for a minimal performance hit compared to Bilinear.
I'm still not sure which chroma algorithm to use. With some content I prefer SoftCubic, but in the meanwhile I've also run into real life content where a sharper chroma algorithm looks noticeably better.

And now that I've overclocked the card (1GHz GPU/720MHz RAM) I seem to be able to play Blu-ray downscaled in linear light using Catmull-Rom AR without any problems, though it is probably still too taxing on some systems.
Interesting. So Catmull-Rom AR downscaling in linear light is less taxing than Lanczos 3 AR upscaling?

That's interesting, I was under the impression that all the Bicubic variations (Mitchell-Netravali, Catmull-Rom, Bicubic, and SoftCubic) were all the same algorithm with adjusted values, that wouldn't change the load they put on the GPU.
All 2-tap algorithms should have exactly the same performance. And all 3-tap algorithms should have exactly the same performance. Etc...

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.
madVR v0.85.2 will change from NV12 -> NV12 DXVA2 scaling to NV12 -> RGB DXVA2 scaling. Maybe NVidia will use a better algorithm then? I don't know, but a retest might make sense.

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?
There are different types of content. If you have native video content, doubling the framerate is the only right thing to do. If you have native movie sources (telecined to 25i/30i) you can switch madVR into film mode (see keyboard shortcuts) and you'll get 24p/25p output instead of 50p/60p.

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.

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).
Unfortunately DXVA2 is not telling anybody which content type it detected during deinterlacing. At the same time it's not DXVA2 which decides the framerate, but the renderer. So madVR always outputs double framerate when deinterlacing with DXVA2.

I do not know if it's ycms who fails or it is the way madVR handle ycms ... but something's wrong
Unfortunately I don't have access to the yCMS sources so I can't say what's wrong exactly or fix the problem myself. However, I would guess that inconsistencies in your measurements might be the problem.

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 lineDesktop Composition Rate: 120.000Hz [there are a few trailing zeros, but I couldn't count them]before that line vanishes, but the interesting part is that it showsdisplay 0.000000Hz It doesn't update during playback at all, and when the playback is paused, it only updates the Render Queue. I have included a Debug Log of a few seconds of video playing for both Windowed Mode (http://www.mediafire.com/?b5uad99uxu19q69) and FSE (http://www.mediafire.com/?9oav500tz05zv6k). Also interesting is that while the screen stays blank except for the Debug OSD, the FSE seekbar does show up, albeit with a delay of a few seconds. Also, after a while, it seems MPC-HC just hangs, because audio also stops playing. In the case of the Debug logs, the audio stopped at around 25 seconds.
I should mention that EVR-CP works perfectly fine.
My Setup:

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

I did use the search and didn't find anything alike. Unfortunately, I don't have any other screens capable of 120Hz at all, so I can't test if it's maybe my drivers' fault.
There was one other user with 120Hz which reported the same problem many months ago. The problem is that madVR tries to find a pattern in the VSync scanline position readings (which are done in high frequency by madVR) and it seems that sometimes when using 120Hz madVR has a problem finding a reliable pattern. As a result madVR is unable to figure out the exact refresh rate and when exactly the VSync interrupts will occur in the future. This is needed for playback, though, because the whole madVR presentation logic is based on syncing the frames to the future VSync interrupts. I would really like to fix this problem, but it's going to be hard without having a 120Hz display for testing, and unfortunately all my displays top out at 60Hz at the moment... :scared:

I'm sure I've mentioned this before but auto-detection of deinterlacing seems to be broken for some HDTV (UK) streams in MKVs (maybe other types of files too, dunno). The same streams in TS files deinterlace fine, and the MKVs deinterlace fine in EVR too. Using LAV Splitter/Video/Audio.

EDIT: On second thoughts, I think this is probably an issue in MKV Merge. My older MKVs work fine, newer ones don't. If it is, Mosu needs to know why the interlacing isn't detected properly so can you help with this please madshi?
The problem is the framerate in the MKV header. It says 50p. LAV Splitter reads that and passes it on to the decoder. The decoder passes that forward to madVR and that's why madVR decides not to deinterlace the video because madVR generally does not deinterlace 50p or 100i content.

[madshi]

Catalyst 12.11 beta 11 seems to have fixed the issue.
Oh, that's cool!!

[madshi]

madVR v0.85.2 released

http://madshi.net/madVR.zip

* 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.

[sneaker_ger]

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.)

[nevcairiel]

My copyback algorithm could/should be slightly more efficient than those used by external decoders, but I'm not sure by how much.

Care to elaborate why? :)

[madshi]

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.)
Which GPU, which OS, which driver, which splitter, which decoder, which media player? Have you tried different decoders? Different splitters, different media players? Thanks!

Care to elaborate why? :)
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.

[aufkrawall]

My issue with DXVA2 scaling and display mode switch is gone with .2. :)

[sneaker_ger]

Which GPU, which OS, which driver, which splitter, which decoder, which media player? Have you tried different decoders? Different splitters, different media players? Thanks!

HD 5850 (Cat 12.11 beta 11)
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?

[aufkrawall]

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?
It doesn't take that long for me on Nvidia, not even with playback delay enabled.

[sneaker_ger]

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.

[DragonQ]

The problem is the framerate in the MKV header. It says 50p. LAV Splitter reads that and passes it on to the decoder. The decoder passes that forward to madVR and that's why madVR decides not to deinterlace the video because madVR generally does not deinterlace 50p or 100i content.
I see. That's kinda strange because in MKVMerge I always tell it to make the frame rate "50i", not "50p".

[madshi]

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.
Can you reproduce the 0.5 second delay with the debug build? If so, a log might help. Do you have the "delay playback start ..." option activated? Does that 0.5 second delay result in frame drops?

I see. That's kinda strange because in MKVMerge I always tell it to make the frame rate "50i", not "50p".
Well, at least now you have something to report to Mosu. It's a clear bug, IMHO.

[sneaker_ger]

http://www.mediafire.com/?y7sao03466s4sd6

[DragonQ]

Well, at least now you have something to report to Mosu. It's a clear bug, IMHO.
Agreed. Mosu has asked you to post in his thread (http://forum.doom9.org/showthread.php?p=1603929#post1603929) with more specifics, if you don't mind?

Hopefully fixing that will solve both the AAC and AC3 file issues, otherwise you'll be getting another set of samples soon! :D

[6233638]

Interesting. I haven't really measured performance, but it makes some sense. Chroma upsampling is cheaper because I hard coded it to do exactly 2x which allowed me to write more efficient shader code. Maybe using Bilinear as default for chroma upsampling isn't necessary. But then we come back to the very old discussion about which algorithm to use instead, and we never seem to be able to agree there.
...
I'm still not sure which chroma algorithm to use. With some content I prefer SoftCubic, but in the meanwhile I've also run into real life content where a sharper chroma algorithm looks noticeably better.Yes, unfortunately it does introduce that problem. I still maintain that Bicubic 75 is probably the best Chroma algorithm to use as the default though. It has a minimal impact on performance, and looks almost the same as Lanczos 3 with less ringing in most cases. Most importantly, it also maintains the correct brightness/saturation for Chroma.

SoftCubic on the other-hand, desaturates and blurs Chroma, often causing it to bleed out the edges of things. SoftCubic 100 is the exception where it might work well in cases of extremely bad Chroma, but so far I have only been able to collect two samples of that, and all algorithms but SoftCubic 100 and Jinc 8 AR fail with them to equally bad levels. The problem there is the source. (I wonder if there was some version of a commercial encoder that did something wrong with Chroma)

In most cases, I think Bicubic 75 is the safest bet, and is also a clear improvement over Bilinear as used for Chroma elsewhere. I can find many more examples where SoftCubic 100 looks bad (most of them!) than ones where Bicubic 75 is a poor choice.

I really hoped that going from Lanczos 4 (original default) to Lanczos 3 would allow me to activate AR by default, but maybe you're right and it's too taxing. However, from HD 4000 reports it seems that Lanczos 3 AR is not really a problem. So the big quesion is which hardware to use as reference.
...
Interesting. So Catmull-Rom AR downscaling in linear light is less taxing than Lanczos 3 AR upscaling?I should have been clearer, but I was testing upscaling 1080p content to push the rendering numbers up and make the comparisons easier, to see which features (like Bicubic Chroma) could be enabled with a minimal performance hit on any system.

Using the same material and scale factor as I did last night, where Bicubic 75 Chroma & Lanczos 3 AR Luma are at 88ms, switching to Lanczos 4 Luma drops render times to 58ms, so it's still a big difference.
It just seems that the anti-ringing filter and linear light downscaling are both big performance hits on lower-end hardware.

I thought I could maybe get away with using the anti-ringing filter for Chroma, as the performance hit seemed minimal at or below 720p, but it became a much bigger hit at 1080p.
Downscaling in linear light using Catmull-Rom AR is still the biggest performance hit on my system though.

It has roughly 35ms render times (1080p at 50% size) and would constantly drop frames before I overclocked my card.
Upscaling 720p30 or 576i DVDs are roughly 30ms with Bicubic 75/Lanczos 3 AR.

At the factory speeds, I was unable to get smooth playback with these settings, and had to overclock the card.


I think that Bicubic 75 Chroma, and either Mitchell-Netravali (low performance requirement) or Spline/Lanczos 3 (medium performance requirement) would be your best choice for Luma upscaling.

For Luma downscaling, I would have to do more testing, but I think that Catmull-Rom without the AR filter or Linear Light option is probably still the best choice to have a sharp image without a lot of ringing or aliasing.
All 2-tap algorithms should have exactly the same performance. And all 3-tap algorithms should have exactly the same performance. Etc...That's what I thought, thanks.

madVR v0.85.2 will change from NV12 -> NV12 DXVA2 scaling to NV12 -> RGB DXVA2 scaling. Maybe NVidia will use a better algorithm then? I don't know, but a retest might make sense.I'll have a look later tonight, sounds like there are a lot of improvements again.

Unfortunately I don't have access to the yCMS sources so I can't say what's wrong exactly or fix the problem myself. However, I would guess that inconsistencies in your measurements might be the problem.I've been seeing this as well, and I just use the standard BT.709 primaries as my gamut, only using yCMS to fine-tune the gamma response on my display. I'm not sure when it happened (whether it's recent or not) as there was a long time where I was not using yCMS.

[leeperry]

:thanks: for the new build!

(4) Custom shaders should now produce 100% identical results to EVR/VMR9
O-M-G, it's a-l-i-v-e! https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcSD7vijkH0ARO9tQTbH1OSXFtmCNVd9VeTh263xgqfkNjkfQEu1Cg


Only tried 0-255 RGB32 so far but I would guess that 16-235 YV12 would work equally well. I'm now more than ever eagerly awaiting the next build of PotP http://forum-images.hardware.fr/images/perso/5/zoreil974.gif

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.
Ouh, messing with colorimetry blindly without a meter? All I know is that the brightness/contrast/saturation settings all seem to work fine in PotP but these can't convert levels apparently so I don't really understand their point.

The custom levels hotkeys are great news though, but pressing the same hotkeys 20/30 times in a row(for really broken encodes) doesn't really sound too manageable :o

Jinc 8 AR for Chroma was the only option that looked really good, being the only choice that avoided aliasing and maintained the correct brightness/saturation for Chroma.
Jinc8 AR chroma, alright bring the pain! We all needed an excuse to buy a new GPU anyway :D

PS: oh BTW, it seems that some ppl can't really stand 48p (http://www.dailymail.co.uk/news/article-2241758/Hobbit-film-wizardy-left-feeling-sick--Cinema-goers-complain-camera-speeds-3D-effects-caused-headaches-queasiness.html) after all.

[daltonm]

Thanks for the new build.
Working perfectly.

settings;
Chroma upscaling; Softcubic softness 100
Image upscaling; Lanczos 4 taps + AR filter.
AMD 7750 12.10 and 1080p TV.

[BetA13]

I LOVE YOU madshi !!!!!!!!!!!!!!!!!!!!

* added options for custom display output levels

Thanks so much for this option..i always had probs with the standart ranges on my hdtv, now with custom settings (10 - 255) its PERFECT..
madvr is now the best renderer out there for me..nothing can beat it in tearms of quality, functionality and more..

Thanks so much madshi...

-BetA-

[DarkSpace]

There was one other user with 120Hz which reported the same problem many months ago. The problem is that madVR tries to find a pattern in the VSync scanline position readings (which are done in high frequency by madVR) and it seems that sometimes when using 120Hz madVR has a problem finding a reliable pattern. As a result madVR is unable to figure out the exact refresh rate and when exactly the VSync interrupts will occur in the future. This is needed for playback, though, because the whole madVR presentation logic is based on syncing the frames to the future VSync interrupts. I would really like to fix this problem, but it's going to be hard without having a 120Hz display for testing, and unfortunately all my displays top out at 60Hz at the moment...:scared:
In that case, I guess I'll have to switch back to 60Hz refresh rate until you are able to figure something out... anyway, all this really means is that I should read the thread (it's on my To-Do list, but the thread is huge...).
In any case, thank you very much for your continued work on this!

[6233638]

(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.I'm not sure how I feel about the "contrast" adjustment - it seems like it might not be done with much precision, or it's just highlighting compression etc. very quickly.

But the revised controls seem good, and I need to check out the input/output levels options. (though I shouldn't have to change the output levels from 0-255)

(3) I've totally reworked the way madVR deals with DXVA2 outputThis seems to work well - the colour matrix is correct for up and downscaling with DXVA2 now.
There is some minor colour shifting left though. With this overscan pattern, 128,128,128 becomes 129,128,130 for example:
DXVA2 (http://www.abload.de/img/dxva2vrk3o.jpg), Lanczos 3 AR (http://www.abload.de/img/lanczosrpk4z.jpg)
You will also see that there's still some of the sides being cropped off.

However, I still don't find DXVA2 to be much use on Nvidia. It's basically Bilinear scaling with a sharpening filter applied, and render times are still very high for how it looks.

With 1080p at 2x, I get 6ms for Bilinear Chroma & Luma.
With DXVA2 I get a large spike at the start of playback (over 1100ms) and then it settles at 56ms.

DXVA2 also has worse image quality than Bilinear Luma & Chroma in madVR due to the increased ringing and aliasing from the sharpening used.

With 1080p at 2x, I can run Bicubic 75 AR Chroma with Lanczos 3 Luma at 37ms total, or with Mitchell-Netravali Luma for 27ms.

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?If I understand things correctly, if I set LAV Video to "DXVA2 Native" you now perform your own "copy-back" function, instead of using LAV Video's copy-back function, is that right?

From a two minute sample clip:

DXVA2 N: 84% GPU, 72% MCU, 24% VPU peak usage.
DXVA2CB: 83% GPU, 71% MCU, 20% VPU peak usage.

So it's not identical, but the difference between them is much smaller now.

Ouh, messing with colorimetry blindly without a meter? All I know is that the brightness/contrast/saturation settings all seem to work fine in PotP but these can't convert levels apparently so I don't really understand their point :oI find having keyboard shortcuts to directly adjust saturation quite useful. I am generally all for watching as intended etc. but there have been some recent releases shot on digital that look anaemic to me and need a little boost in saturation to look right in my opinion:
Before (http://www.abload.de/img/withoutalql1.jpg), After (http://www.abload.de/img/with0urid.jpg)

There have also been a few films I've come across from a particular group that, rather than being black and white, are encoded with a blue tint, that saturation controls can easily fix:
Before (http://www.abload.de/img/blueexi88.jpg),After (http://www.abload.de/img/bwz1i9s.jpg)

I don't think I have any examples to hand, but there have definitely been one or two films in the last year that I've seen where a slight gamma bump would be useful. (-contrast in the new controls)
Jinc8 AR chroma, alright bring the pain! We all needed an excuse to buy a new GPU anyway :DI'm not saying that I recommend it. In fact, I bet it would do very poorly in some tests. It's just that with bad chroma samples - of which I have two out of all my testing so far - Jinc 8 and SoftCubic 100 are the only two algorithms that "pass".

[JarrettH]

Why the need for brightness/contrast settings? I already calibrate with a Spyder 2 :cool:

[manma]

God, I have a lot to learn apparently. Just how necessary is yCMS calibration? Also, how taxing is it on the GPU? It feels like I was having no trouble playing back most things until I went and set it up.

[crotecun]

I really hoped that going from Lanczos 4 (original default) to Lanczos 3 would allow me to activate AR by default, but maybe you're right and it's too taxing. However, from HD 4000 reports it seems that Lanczos 3 AR is not really a problem. So the big quesion is which hardware to use as reference.



Going forward, the Intel HD 4000 as the reference hardware seems reasonable.


Ivy Bridge laptops almost always have HD 4000 as their graphics, with varying max clocks of 1 to 1.15 ghz.
Anandtech has an HTPC review using madVR for the HD 4000 (http://www.anandtech.com/show/5773/intels-ivy-bridge-an-htpc-perspective/4) (tables here (http://www.anandtech.com/show/5773/intels-ivy-bridge-an-htpc-perspective/6)) so we have a general idea on how it performs.
According to Tom's Hardware graphics card hierarchy (http://www.tomshardware.com/reviews/gaming-graphics-card-review,3107-7.html), HD 4000 is only one step below the Radeon HD 6450 and three steps below the GT 430. Granted this metric is for gaming, but since madVR taxes the video card like a game would then it can be assumed that if the scaling settings perform acceptably on HD 4000 then it should also work fine on Radeon HD 6450 and GT 430 or higher.

[mindbomb]

There are different types of content. If you have native video content, doubling the framerate is the only right thing to do. If you have native movie sources (telecined to 25i/30i) you can switch madVR into film mode (see keyboard shortcuts) and you'll get 24p/25p output instead of 50p/60p.


I understand that it is ideal to have the doubled framerate, but if I can't manage it without dropped frames, I would prefer to not have it if possible.
In this case, yea, I think film mode would be appropriate, but I can't get it to work without changing the fps to 50p. Do I have to turn off deinterlacing first?

[dansrfe]

It would be nice if someone wrote up a mini guide on how to calibrate madVR via yCMS with hfcr from scratch for people like me who are relatively new to hardware calibration and somewhat clueless.

[pie1394]

Going forward, the Intel HD 4000 as the reference hardware seems reasonable.


Ivy Bridge laptops almost always have HD 4000 as their graphics, with varying max clocks of 1 to 1.15 ghz.
Anandtech has an HTPC review using madVR for the HD 4000 (http://www.anandtech.com/show/5773/intels-ivy-bridge-an-htpc-perspective/4) (tables here (http://www.anandtech.com/show/5773/intels-ivy-bridge-an-htpc-perspective/6)) so we have a general idea on how it performs.
According to Tom's Hardware graphics card hierarchy (http://www.tomshardware.com/reviews/gaming-graphics-card-review,3107-7.html), HD 4000 is only one step below the Radeon HD 6450 and three steps below the GT 430. Granted this metric is for gaming, but since madVR taxes the video card like a game would then it can be assumed that if the scaling settings perform acceptably on HD 4000 then it should also work fine on Radeon HD 6450 and GT 430 or higher.


With MS DTV-DVD decoder + madVR 0.82.5 + Bi-linear Chroma (actually DXVA2 scaling ?) + DXVA2 Luma scaling + DXVA2 deinterlace, SandyBridge Core i5-2467M (1.6GHz, Turbo Boost 2.3GHz) + HD3000 is now capable of processing 1440x1080i30 --> 1920x1080p60 FSE. I think this is an important achievement for madVR to be useful on less powerful GPU HW.

With madVR Bi-linear Luma option, there is frame dropping when the interlaced HDTV content is played.

[toniash]

@madshi Thanks for the new version!
I have some questions:
1-The "device controls" colour ,brigthness , etc appear grey and do nothing, I'm I missing something?
2- Where can I find the names for "special" keys to use in shortcuts?
the keystrokes are not detected I must write them

[manma]

Is it normal for madvr to make your GPU usage shoot up intermittently while watching a video? Like, say I get 30 minutes of smooth playback, and then out of nowhere my GPU usage jumps up to 99% and madvr starts dropping frames every which way. I can't seem to pinpoint the "type" of video it does this too either. It just seems random. If it matters, I'm having this problem on both my GTX 460 and my Intel HD3000 (Jinc4 on the former and Spline3 on the latter).

[khanmein]

@6233638, bro i'm using mobility HD5650. can u suggest what setting for chroma, image up & downscale? thanks~

my setting
chorma 3 jinc AR
luma up 3 jinc AR
down Catmull-Rom AR + linear

[disto]

Thank You madshi for all of your work.I have one feature request.Can you please add an option for custom Gamma correction like you did for brightness and saturation.Maybe something with slider or something like ffdshow or potplayer.

[madshi]

http://www.mediafire.com/?y7sao03466s4sd6
I can't see anything wrong in the log, except that the rendering of the first two frames takes 113ms and 56ms. All remaining frames are rendered in < 5ms. Not sure why this happens.

Does madVR v0.85.1 behave differently on your PC? You do not have that 0.5 seconds of transparent window with v0.85.1?

Ouh, messing with colorimetry blindly without a meter? All I know is that the brightness/contrast/saturation settings all seem to work fine in PotP but these can't convert levels apparently so I don't really understand their point.
If you don't find these controls useful, you don't have to use them... ;) I'll probably not use the "display color control" settings myself, but some people might find them useful, what do I know. I've added them for completeness sake and because some displays do not have good controls for that.

The custom levels hotkeys are great news though, but pressing the same hotkeys 20/30 times in a row(for really broken encodes) doesn't really sound too manageable :o
Well, you can press the key and hold it.

Thanks so much for this option..i always had probs with the standart ranges on my hdtv, now with custom settings (10 - 255) its PERFECT..
madvr is now the best renderer out there for me..nothing can beat it in tearms of quality, functionality and more..
:)

I'm not sure how I feel about the "contrast" adjustment - it seems like it might not be done with much precision, or it's just highlighting compression etc. very quickly.
It's done with the highest precision the GPU allows (32bit float). I'm not sure myself how useful such a contrast adjustment is, but it does exactly what it's supposed to do (from what I can see). Maybe nobody will use it, but it's there, because all the color control dialogs have a contrast setting, so I need to offer some algorithm for that.

However, I still don't find DXVA2 to be much use on Nvidia. It's basically Bilinear scaling with a sharpening filter applied, and render times are still very high for how it looks.

With 1080p at 2x, I get 6ms for Bilinear Chroma & Luma.
With DXVA2 I get a large spike at the start of playback (over 1100ms) and then it settles at 56ms.

DXVA2 also has worse image quality than Bilinear Luma & Chroma in madVR due to the increased ringing and aliasing from the sharpening used.

With 1080p at 2x, I can run Bicubic 75 AR Chroma with Lanczos 3 Luma at 37ms total, or with Mitchell-Netravali Luma for 27ms.
Ok, seems DXVA scaling is not all that useful for NVidia users. But for Intel users, the situation is very different, I think.

If I understand things correctly, if I set LAV Video to "DXVA2 Native" you now perform your own "copy-back" function, instead of using LAV Video's copy-back function, is that right?

From a two minute sample clip:

DXVA2 N: 84% GPU, 72% MCU, 24% VPU peak usage.
DXVA2CB: 83% GPU, 71% MCU, 20% VPU peak usage.
That's correct. Hmmmm... I wonder why Native consumes more GPU power than Callback. Anyway, what does CPU usage say? Is it higher with Native, too?

I don't think I have any examples to hand, but there have definitely been one or two films in the last year that I've seen where a slight gamma bump would be useful. (-contrast in the new controls)
Gamma change would be "brightness", not "contrast".

Why the need for brightness/contrast settings? I already calibrate with a Spyder 2 :cool:
Well, you don't have to use the madVR brightness/contrast settings. Just set them to 0, then madVR will even disable the shader code, so there's no disadvantage for you.

I understand that it is ideal to have the doubled framerate, but if I can't manage it without dropped frames, I would prefer to not have it if possible.
In this case, yea, I think film mode would be appropriate, but I can't get it to work without changing the fps to 50p. Do I have to turn off deinterlacing first?
The problem is that deinterlacing in half framerate will also seriously damage deinterlacing quality. So I don't think offering that is a good idea. Film mode only works with software decoding (or CUDA or "copyback" in LAV). It doesn't work when using native DXVA2 decoding.

With MS DTV-DVD decoder + madVR 0.82.5 + Bi-linear Chroma (actually DXVA2 scaling ?) + DXVA2 Luma scaling + DXVA2 deinterlace, SandyBridge Core i5-2467M (1.6GHz, Turbo Boost 2.3GHz) + HD3000 is now capable of processing 1440x1080i30 --> 1920x1080p60 FSE. I think this is an important achievement for madVR to be useful on less powerful GPU HW.
:)

And colors are alright? FWIW, this way you only get 8bit YCbCr to RGB conversion with the current Intel drivers, unfortunately. I hope this will be fixed with a future Intel driver version. And yes, chroma upsampling is done by Intel/DXVA2 in this configuration, too.

1-The "device controls" colour ,brigthness , etc appear grey and do nothing, I'm I missing something?
The edit boxes are grey, but the left/right buttons should work.

2- Where can I find the names for "special" keys to use in shortcuts?
the keystrokes are not detected I must write them
Here's a list of currently supported special keys. Your keyboard may not have all of these keys:

Back, Tab, Clear, Return, Pause, Break, Esc, Space, PageUp, PageDown, End, Home, Left, Up, Right, Down,
Select, Print, Execute, Insert, Delete, Help, Win, Apps, Sleep, NumPad0..9, Multiply, Add, Decimal, Substract, Divide,
F1-F24, NumLock, Scroll, BrowserBack, BrowserForward, BrowserRefresh, BrowserStop, BrowserSearch, BrowserFavorites, BrowserHome,
VolumeMute, VolumeDown, VolumeUp, MediaNextTrack, MediaPrevTrack, MediaStop, MediaPlayPause,
LaunchMail, LaunchMediaSelect, LaunchApp1, LaunchApp2, Play, Zoom

Is it normal for madvr to make your GPU usage shoot up intermittently while watching a video? Like, say I get 30 minutes of smooth playback, and then out of nowhere my GPU usage jumps up to 99% and madvr starts dropping frames every which way. I can't seem to pinpoint the "type" of video it does this too either. It just seems random. If it matters, I'm having this problem on both my GTX 460 and my Intel HD3000 (Jinc4 on the former and Spline3 on the latter).
No, this is not normal at all. Maybe you have some other applications which use the GPU? E.g. some newer browsers do. Or maybe some software like SETI running in the background?

Thank You madshi for all of your work.I have one feature request.Can you please add an option for custom Gamma correction like you did for brightness and saturation.Maybe something with slider or something like ffdshow or potplayer.
madVR "brightness" control = Gamma adjustments.

[nevcairiel]

The problem is that deinterlacing in half framerate will also seriously damage deinterlacing quality. So I don't think offering that is a good idea.

The way this works in CUVID is that it always deinterlaces at full rate, but discards one of those instead of using it for output. The quality is the same, you just lose some of the smoothness.

Not sure if thats a viable alternatve for madVR. Deinterlacing stays the same, but it essentially "drops" half of the frames to reduce the load on madVRs processing.

[omarank]

Hi Madshi

In MPC-HC, I can rotate an image by pressing Alt + Num 1, when using EVR-CP. When I use madVR, the key combination doesn't work. It seems madVR does not allow image rotation. Could you please implement that functionality too?

[toniash]

madVR "brightness" control = Gamma adjustments.
so what is different in "source brigthness" and "desired display gamma value" shortcuts?

[madshi]

The way this works in CUVID is that it always deinterlaces at full rate, but discards one of those instead of using it for output. The quality is the same, you just lose some of the smoothness.

Not sure if thats a viable alternatve for madVR. Deinterlacing stays the same, but it essentially "drops" half of the frames to reduce the load on madVRs processing.
Yeah, that might be a possibility. It's a bit sad, though, to let DXVA do all the heavy lifting to create those nicely deinterlaced frames, just to throw them away again... :scared:

In MPC-HC, I can rotate an image by pressing Alt + Num 1, when using EVR-CP. When I use madVR, the key combination doesn't work. It seems madVR does not allow image rotation. Could you please implement that functionality too?
It's on my to do list. But not with a very high priority at the moment.

so what is different in "source brigthness" and "desired display gamma value" shortcuts?
The "desired display gamma value" is for setting up your display. You should in theory do that once and then leave the setting alone. The "source brightness" is meant to allow you to improve badly encoded movies. E.g. if one specific movie was encoded too brightly, just increase the "source brightness". madVR will automatically reset the "source brightness" changes you do when you load the next video, so you don't have to remember to reset the controls manually after the movie has finished playing.

[DragonQ]

I'm interested to know what kind of hardware can't handle proper deinterlacing to 50p/60p (besides broken Arrandale of course :p). A low-end nVidia GT 430 can handle it perfectly well. That'd have to be some ancient Radeon....either that or he's chosen algorithms too demanding for his GPU, in which case it'd surely be better to choose a less demanding algorithm than lose half of the temporal resolution of the image.

[leeperry]

BTW, I've just been informed that the new version of PotP that will support PS scripts with mVR hasn't been planned for release yet and that we shouldn't hold our breath for it.....sometimes they release new versions on a daily basis, but when it really matters it might take them forever.....c'est la vie I guess =/

Well, you can press the key and hold it.
I never keep a keyboard within hands reach, so that wouldn't help...I guess I'll try to make a few PS scripts presets for levels conversions then.

Also, the OSD doesn't seem to tell about the custom levels current state so playing around with levels blindly doesn't sound too good to me :o

I find having keyboard shortcuts to directly adjust saturation quite useful.
Good point, and if I keep the .ini file of PotP read-only I can play around with its saturation setting....too bad increments are 1% at a time.

[pie1394]

Yeah, that might be a possibility. It's a bit sad, though, to let DXVA do all the heavy lifting to create those nicely deinterlaced frames, just to throw them away again... :scared:


If I don't turn on frame-rate-doubling deinterlace, the 1440x1080i25/i30 & 1920x1080i25/i30 video presented by madVR + 1920x1080i25/i30 output signal obviously has something wrong. One field is always presented with the wrong contents. Anybody who has a native 1080i CRT / PDP HDTV can tell it.

Turn it on and still makes the GPU to send out 1920x1080i25/i30, this does not hurt the PQ (especially vertical resolution to me). For each frame, the deinterlaced field is actually never sent to TV.

About this I remembered long time ago when my HTPC was XP + 8800GTS, it worked fine. These MPEG2 HDTV contents can be sent to VMR9 with weaving option (no deinterlace) at 100% zooming case when the output signal is 1920x1080i25/i30. Of course the field-mode-scaling on Chroma components must be used to make a YUV/RGB 4:4:4 field image.

Just remembered such kinds of analysis were actually implemented on a product's deinterlacing engine designed by me long time ago. At that time, it needs to handle various NTSC / PAL / SDTV / HDTV input signal devices for interlaced contents. So a source interlaced video frame may not be actually deinterlaced on interlaced CRT/PDP. If video frame is deinterlaced and progressive signal is sent to such TV, the PQ is actually worse. But there are many combinations which need to be considered including source field order, output mode, scaling factor, pausing state, trick play, etc...



And colors are alright? FWIW, this way you only get 8bit YCbCr to RGB conversion with the current Intel drivers, unfortunately. I hope this will be fixed with a future Intel driver version. And yes, chroma upsampling is done by Intel/DXVA2 in this configuration, too.


At least it looks much closer if compared to the one produced by version 0.85.1 on ION chipset. :)

madVR 0.85.2 Luma - Bilinear

http://i.imgur.com/jVSxk.jpg (http://imgur.com/jVSxk)


madVR 0.85.2 Luma - DXVA

http://i.imgur.com/58juk.png (http://imgur.com/58juk)


madVR 0.85.1 Luma - DXVA

http://i.imgur.com/rIfpk.jpg (http://imgur.com/rIfpk)

[huhn]

I really hoped that going from Lanczos 4 (original default) to Lanczos 3 would allow me to activate AR by default, but maybe you're right and it's too taxing. However, from HD 4000 reports it seems that Lanczos 3 AR is not really a problem. So the big quesion is which hardware to use as reference.

my hd 4000 handle 720x480 -> 1920x1080 luma jinc 3 ar chroma mitchell-netravali ar with 34 ms so lanczos 3 ar is no problem at all.

but i think the hd 4000 is a bad reference most people who get a cpu with that card get an extra gpu too. at least thous who watch videos on it the rest will use the cpu for cpu heavy programs.

a hd 2000/hd 3000 or a4 apu gpu is maybe a better reference.

and how about an audio renderer which works hand in hand with madvr to get rig of the frame drop repeat problem by resampling the audio

by upsampling the audio to the max the audiocard supports

like 48032 to 96000

so madvr runs 100% smooth without reclock and out of the box.

[leeperry]

how about an audio renderer which works hand in hand with madvr to get rig of the frame drop
It took years to get Reclock and mVR where they are, and Reclock "works". Of course it doesn't if you enable framerate pulldown in mVR, but that's the only limitation AFAIK.

[DragonQ]

You could add a very small wizard that simply asks what the user's GPU is and then set recommended scalars based on that. Might be easier to auto-detect though.

[huhn]

It took years to get Reclock and mVR where they are, and Reclock "works". Of course it doesn't if you enable framerate pulldown in mVR, but that's the only limitation AFAIK.

if is that hard i'm sorry then it's better to skip that topic completely

[sneaker_ger]

I can't see anything wrong in the log, except that the rendering of the first two frames takes 113ms and 56ms. All remaining frames are rendered in < 5ms. Not sure why this happens.

0.85.1 seems to suffer from the same problem. Also had the problem where the playback does not start with LAV Video come back. MPC-HC's decoder still seems to work fine, but I have great trouble making it 100% reproducable. I have a feeling both problems are connected. It's like a frame is requested from the dxva2 decoder and it either takes very long for it to come or it doesn't come at all.
I will revert to the stable Catalyst later, since I can't remember having this problem with 0.85.1 before, and report back. (I should've done this from the beginning. Updating driver and madVR at the same time is obviously a bad idea for testing.)

Maybe I will also create a seeking sample to better test seeking in the future, unless something like this already exists.

[leeperry]

BTW going back to the BenQ W1070, these two youtube videos look pretty outstanding and rather enticing:

http://www.youtube.com/watch?v=99uhuBXTWmU

http://www.youtube.com/watch?v=NOWE4j0W9JU

Resistance is futile :p

[ajp_anton]

but i think the hd 4000 is a bad reference most people who get a cpu with that card get an extra gpu too. at least thous who watch videos on it the rest will use the cpu for cpu heavy programs.

a hd 2000/hd 3000 or a4 apu gpu is maybe a better reference.Every Ivy Bridge laptop has at least a HD4000. Every Sandy Bridge laptop has at least a HD3000.
HD2000 is a useless reference, because it only exists on desktops without an external GPU. Not sure if HD2500 is more popular in HTPCs.

[truexfan81]

I'm interested to know what kind of hardware can't handle proper deinterlacing to 50p/60p (besides broken Arrandale of course :p). A low-end nVidia GT 430 can handle it perfectly well. That'd have to be some ancient Radeon....either that or he's chosen algorithms too demanding for his GPU, in which case it'd surely be better to choose a less demanding algorithm than lose half of the temporal resolution of the image.

weird, with my gt430, if i activate the madvr deinterlacing on either setting, it becomes a slideshow. However the cuvid deinterlace to 60p works perfectly. :-/

i have tried this with dvds, xvid, and h264, same result.

i'm curious what the issue is there, but the videos are getting deinterlaced using cuvid, so not a huge issue.

[manma]

No, this is not normal at all. Maybe you have some other applications which use the GPU? E.g. some newer browsers do. Or maybe some software like SETI running in the background?

I guess it could be Firefox. I'll see if I can track it down.

[mindbomb]

And colors are alright? FWIW, this way you only get 8bit YCbCr to RGB conversion with the current Intel drivers, unfortunately. I hope this will be fixed with a future Intel driver version. And yes, chroma upsampling is done by Intel/DXVA2 in this configuration, too.


what specifically causes the 8 bit conversion in his case?
the use of the microsoft decoder, dxva in general, or dxva scaling?

[nevcairiel]

DXVA scaling on Intel results in 8-bit RGB, AMD and NVIDIA output high bitdepth RGB.

[mindbomb]

the chroma upsampling being done by intel/dxva2 is also a result of dxva scaling on intel?