madVR - high quality video renderer (GPU assisted)

[leeperry]

BTW, I see that you added filename tags for fps overriding, would you also consider doing it for gamut/decoding matrix(and possibly AR as well) please? So I could tag my pesky REC709 gamut+matrix SD files and other ppl could tag their 25fps accelerated NTSC DVDRips and SMPTE-C/EBU for the HD conspiracy believers.

Maybe something like:
PAL = EBU gamut
HTDV = REC.709 gamut + decoding matrix
BT601 = 601 matrix
BT709 = 709 matrix
and of course EBU, SMPTE-C and REC709 for gamuts.

and something like 1.33 and 1.78 for AR overriding would cut us from remuxing with a proper DAR, which can be a PITA when you have a truckload of files and can't use ffdshow anymore(I cry a million tears ^^)

[madshi]

Originally Posted by NicolasRobidoux

At this point, I suspect that originals with haloing may not always be sigmoidization's friend.

May be true. As you said, different color spaces do different things to different types of lines. Some thin out light lines and make dark lines fatter. Others do the opposite. Depending on the content, one can look better with one test image, another one with a different test image. It could be true that light halos generally don't fit well with sigmoidization.

FWIW, I've also found other cases where sigmoidization wasn't working too well. I don't have time to double check right now, but I *think* this image also made problems with sigmoidization:

http://madshi.net/colorsrc.png

This one only really looks good with linear light upscaling, due to the extreme dithering patterns. But I don't think there's ever going to be video content looking like this, so this specific test image doesn't bother me too much.

Originally Posted by NicolasRobidoux

Mathias:
You knew that Sandy Bridge has a built-in algorithm which can roughly be described as an AntiRing system?

Yes, I'm aware of that, but I haven't had the chance to test the Sandy Bridge/Ivy Bridge algorithm yet. To be honest, from what I've read, my expectation is that it might reduce/remove ringing quite nicely, but it might come with more negative side effects to my own AR algorithm. But I'm just guessing here, I might be wrong.

Originally Posted by JarrettH

Now that LAV will do DVDs, I'm wondering whether the quality is the same? None (weave) in lav video (pass on to gpu) vs DXVA2 in madvr, or should they be identical?

I'm not sure what practical effect this LAV option has, so I can't say. You'd have to ask nevcairiel about this.

Originally Posted by jokerb47

what would be better for luma upscaling: Lancos 3 AR or Jinc 3 noAR?

Depends on what bothers you more: ringing or aliasing. If ringing is your main enemy, choose Lanczos3 AR. If aliasing is your biggest concern, choose Jinc3.

Originally Posted by dansrfe

Ok so apparently the last couple of madVR versions don't acknowledge the ICC profile set by Windows...

I haven't changed anything, other than offering the option to disable the GPU gamma ramps (see madVR settings dialog). Do you have this option activated? FWIW, I've been told that the ICC profile is ignored by the GPU when using Overlay. Maybe you're using Overlay?

Originally Posted by NicolasRobidoux

This is a good looking result. Sure, EWA QuadraticJinc 3 has less moire, but again this is a rather extreme test case. Actually, if anything is not quite right with a scheme, this test image and downsampling ratio will make it jump at you. Schemes considered "reasonable" will produce absolutely awful results.
It certainly illustrates how well AR works (Good job Mathias!) because the Catmull-Rom result manages a nudge less halo than EWA QuadraticJinc 3, and it is also a nudge sharper.
I'm impressed.
P.S. I'm VERY impressed. Squeezing this good a result out of Catmull-Rom filtering... This is a better result than with the overwhelming majority of schemes I've tested. And believe me, me and others have looked at a lot of flies.

I'm glad you like it. To be honest, I didn't spend much time on the downscaling AR algorithm, so I wasn't 100% sure how good it would work. I'm happy to hear it seems to work well.

Originally Posted by NicolasRobidoux

Again, this shows that Catmull-Rom + AR downsampling (through linear light: it has to) is really high quality. If it was not, it would be obvious. As it turns out, except for the better anti-aliasing of EWA QuadraticJinc, and the slightly better anti-haloing of Catmull-Rom AR, the two methods, amazingly, are quite close. Catmull-Rom + AR is also slightly sharper.
(Note: EWA QuadraticJinc is the "natural" downsampler of my arsenal. It's not as sharp as EWA LanczosSharp or EWA Lanczos Radius 3, which is almost as sharp as tensor Lanczos 3 (which is too sharp IMHO anyway, although lots of people like sharpness). It also has less halo.)
P.S. Moire drives DSLR folk nuts. So, I paid a lot of attention to it.
P.S.2 If you enlarge both, you can see the usual difference between a high quality tensor method and a high quality EWA method: The checkerboard mode is suppressed with EWA, and not with Catmull-Rom AR. Same with the fly.

Why are you using EWA QuadraticJinc instead of EWA LanczosSharp? Is the ringing the only reason? Unfortunately madVR doesn't do "Jinc" downscaling at the moment. I'm not sure if I'm going to add it. But I guess Jinc AR for downscaling might be the ultimate downscaling solution? It would be rather slow, though (for realtime video playback).

Originally Posted by jmone

I've got the GTX 660 installed with 306.97 drivers and it is working fine but I want to check if I've got the correct settings esp colour space:
Setup: HTPC --> HDMI --> AVR --> HDMI --> TV/PJ (note: the TV was prof calibrated a few years ago against the Cable Box that is on the same HDMI Input to the TV from the AVR so I'm guessing it is Limited Range)

Current Colour Space on the Dedicated HTPC (eg no desktop or game useage): Limited Range in Nvidia and Full Range in madVR - When using the AVSHD 709 test patters for Black, APL and White Clipping I see flashing just above 16 (Reference Black) and just below 235 (Reference White) which I think is "Correct". I also tried using the madNvLevelsTweaker to push full range in the driver and while this worked I did not notice a change in the test pattern behaviour. When I change madVR to limited range then I see all levels of the AVSHD 709 test pattern flash regardless of if the driver is in full or limited range mode

For best quality you should force NVidia to use full range and then you need to use the matching options (either full or limited) in both your display and madVR.

Originally Posted by FreeFall

I have come across a problem with Zoom Player when using MadVR.

Playback won't start on the first try when using the delay playback start until renderer queue is full option and Zoom Players automatic subtitle stream selection. It will start normally if you press play a second time or don't use the above option.

Subtitle Settings.
http://www.mediafire.com/view/?zww21g5ua3ebe1f

This only happens with video files that use PGS (Blu-ray) subtitles.

Test Video.
http://www.mediafire.com/?7ge5zvk6k99g22y

Zoom Player 8.5 Max
MadVR 0.84.3
LAV Splitter / Video (CUVID) / Audio 0.52
xy-VSFilter 3.0.0.65
GeForce GTX 580 (306.97)
Windows 7 Pro

Will have a look at this later.

Originally Posted by 6233638

So Windows 8 is officially out now today. Is anyone else experiencing issues with madVR's refresh rate changer?

1080p24 is outputting 1080p23, and 1080p60 is outputting 1080p59. I am able to select and use 1080p24/60 on the desktop without any problems outside of madVR.

If you create a debug log I might be able to tell you more about what went wrong. Or maybe not.

Originally Posted by Budtz

Is it correct that i dont have much use for all of this this when i use reclock and a 50hz setting? (using 50hz lets me whatch ether pal content or 24hz content without having to change settings + it seems more stable for some reason + films are a tad smother without having the so-called soap opera effect.)

Getting your GPU output modes as correct as possible certainly won't harm. If you use Reclock, it might not make a difference in terms of smoothness. But e.g. watching 24fps movies in 50Hz means that the audio is sped up, too, resulting in the Mickey Mouse effect (audio pitch goes up). Also video will play back faster than real life, which is questionable, too. Of course it's all your decision. If you like it that way, that's ok with me.

Originally Posted by leeperry

Also, maybe someone else already reported it but whatever page I close mVR's config on, each time I close it, the next time it will reopen on the main page of my active display under /devices/...it was pretty handy for rolling purposes when it was remembering the last active page

It should remember the active page, it does for me. However, if there's an undefined device in your settings (look for a question mark), madVR will automatically switch to that instead of the last used page. You can fix that by properly telling madVR what device type that question mark device is.

Originally Posted by mindbomb

Question:
Have you thought about adding a performance metric along with the sharpness, ringing, and aliasing, etc. to the scaling pages?

Yes.

Originally Posted by JarrettH

When you watch a b&w movie, is Chroma upscaling still happening?

Yes, unless we're talking about custom encodings with weird settings. That said, the chroma information for b&w movies should usually be almost flat, so there won't be any visible difference between any of the chroma upsampling algorithms.

[madshi]

Originally Posted by leeperry

BTW, I see that you added filename tags for fps overriding, would you also consider doing it for gamut/decoding matrix(and possibly AR as well) please? So I could tag my pesky REC709 gamut+matrix SD files and other ppl could tag their 25fps accelerated NTSC DVDRips and SMPTE-C/EBU for the HD conspiracy believers.

Maybe something like:
PAL = EBU gamut
HTDV = REC.709 gamut + decoding matrix
BT601 = 601 matrix
BT709 = 709 matrix
and of course EBU, SMPTE-C and REC709 for gamuts.

and something like 1.33 and 1.78 for AR overriding would cut us from remuxing with a proper DAR, which can be a PITA when you have a truckload of files and can't use ffdshow anymore(I cry a million tears ^^)

I would consider that, but the tags would have to be very clear. E.g. "PAL" could be a part of a movie title, so it's not clear enough. Same with "EBU". "BT709" doesn't have this problem, but it could stand for the matrix or for the gamut or for the transfer function, so again it's not clear. For AR e.g. "4:3" would be great, but filenames don't support ":", so that can't be used. Ok, maybe 1.33 would do. But which ARs would have to be supported? If I think about custom encodes with stripped black bars, there could be a multitude of possible ARs which can make things quite complicated again.

[6233638]

Originally Posted by madshi

If you create a debug log I might be able to tell you more about what went wrong. Or maybe not.

http://www.filedropper.com/madvr-log


Unrelated to that, it also seems that the "path hack" to use an alternate DVD Navigator without replacing system files (I believe the tool just changed some registry keys to point to the new file) no longer works in Windows 8 so I have yet to find a way to get DVD playback working without Macrovision errors.

[madshi]

Originally Posted by 6233638

http://www.filedropper.com/madvr-log

The log claims that originally, before starting video playback, the display was 1080p60. Then, you started movie playback. The optimal display mode refresh rate would have been 23 for that movie. But the list of allowed modes was only 1080p24, 1080p50 and 1080p60, so madVR switched to 1080p24. The resulting display mode was 1080p24.

That's what the log says. If you actually got 1080p23 then that's probably a driver problem, because according to the log madVR clearly requested 1080p24, and after switching madVR double checked the resulting mode and again it was reported by the OS/GPU drivers as 1080p24.

[6233638]

Originally Posted by madshi

The log claims that originally, before starting video playback, the display was 1080p60. Then, you started movie playback. The optimal display mode refresh rate would have been 23 for that movie. But the list of allowed modes was only 1080p24, 1080p50 and 1080p60, so madVR switched to 1080p24. The resulting display mode was 1080p24.

That's what the log says. If you actually got 1080p23 then that's probably a driver problem, because according to the log madVR clearly requested 1080p24, and after switching madVR double checked the resulting mode and again it was reported by the OS/GPU drivers as 1080p24.

OK, thanks. Very strange.

If I select 1080p24 on the desktop, madVR reports that as being 24.0x when running windowed, but when it switches to FSE, it changes to 23.9x (same thing for 1080p60)

[FlashGordon]

Originally Posted by FlashGordon

I have a silent film on Blu-ray @1080i that seems to have an odd cadence... madvr's IVTC won't identify the cadence at all, it'll just say "unknown". There is very slight combing without any IVTC or deinterlacing applied, but with IVTC the combing seems to go away. Playback @ 60Hz seems to be smooth, but I get frame drops when I try @ 24Hz.

madshi, I've reuploaded a sample here: http://www.mediafire.com/?f8s0cfd641l59sy as per your request.

[leeperry]

Originally Posted by madshi

It should remember the active page, it does for me. However, if there's an undefined device in your settings (look for a question mark), madVR will automatically switch to that instead of the last used page. You can fix that by properly telling madVR what device type that question mark device is.

Oh ok, thank you for the explanation. Maybe you could nag the user with a pop-up message box and tell him to define what his display is because that wasn't clear to me at all.

Originally Posted by madshi

I would consider that, but the tags would have to be very clear. E.g. "PAL" could be a part of a movie title, so it's not clear enough. Same with "EBU". "BT709" doesn't have this problem, but it could stand for the matrix or for the gamut or for the transfer function, so again it's not clear. For AR e.g. "4:3" would be great, but filenames don't support ":", so that can't be used. Ok, maybe 1.33 would do. But which ARs would have to be supported? If I think about custom encodes with stripped black bars, there could be a multitude of possible ARs which can make things quite complicated again.

Well, a persistent problem with AR is the 720x576 AVI 25fps PAL files for instance.....I used to have a rule in ffdshow forcing 4:3 but now I'm out of luck. Maybe something like [AR=xx] for instance, et voilà ))

You could accept any AR and simply round up 1.33 to 4:3 and 1.78 to 16/9? That would save my day actually

Well, any movie that has ".PAL." in its filename will require EBU primaries anyway and same goes for ".HDTV." that will require REC.709 gamut+primaries.

You could go with [matrix=601] and [matrix=709]?

And for the gamuts, same story: [primaries=xx], accepting the SMPTE-C / EBU / REC.709 keywords?

And while we're at it, levels conversions would be extremely convenient too! Something like [source-levels=xx] accepting the two "PC" and "TV" keywords?

And the icing on the cake would be custom levels, as we all have files with funky levels(eg. went through several sloppy conversions for instance), so it'd be too awesome to be able to make a 40-200 to 0-255 conversion for instance! Something like [source-levels=xx-xx]...this would allow us to ditch ffdshow for good, and once the file is properly tagged no need to input them manually ever again...OMG, that would be too good

PS script support will allow sharpening/mirroring/flipping/debanding/super-resolution upscaling and all the stuff you can already do in MPC and ffdshow, so together with levels conversion/gamut & primaries rolling via tags, this would become an entirely viable alternative to ffdshow and its nasty 8bit post-processing that is a bottleneck and a major disgrace to your 16bit pipeline

again for making our dreams come true!

[mzso]

Originally Posted by 6233638

24p shouldn't have any motion blur other than what is in the source.

I play games at 60p, and there's still a huge difference with backlight scanning on/off with my LCD. (not a response time issue - high speed photographs don't show any motion blur on the panel)
It's an issue of perception, and the same reason why when you use a strobe light, you are able to see things clearly that would otherwise have been a blur - it's the same thing happening here with LCD/OLED. (that doesn't use BFI/Backlight Scanning)

Ok, so its still an insufficient framerate issue.

Originally Posted by 6233638

Sony's OLED headset only has 10,000:1 contrast for example (5,000:1 when calibrated to reference levels) which is no better than a high end plasma.

As far as I know you don't need more than 10000:1. At any moment the human eye can't perceive more. The fact that the eye can adapt to low light conditions is irrelevant because it takes like a half hour.

[mzso]

If I understand correctly there is no "image scaling" when I play 1920*1080 content on my 1920*1200 monitor in fullscreen mode.
Then why do I get dropped frames when I change to Jinc 3, from Lancos 8 (bot with AR)?
I don't touch anything else.

[dansrfe]

@madshi,

Ah yeah I didn't fully understand the disable GPU ramp setting. I had it enabled. If I correctly understand now, disabling the GPU ramps is mainly for the purposes of disabling the application of the ICC profile and letting madVR perform the color correction via yCMS and 3DLUTs? Thanks.

[cyberbeing]

ICC profiles do not perform gamut correction with madVR, only gamma and whitepoint correction through the gamma ramp. Assuming you have a calibrated GPU gamma ramp, unless your yCMS 3DLUT was created from Primary + Whitepoint + IRE Grayscale measurements with the gamma ramp disabled/linear, you wouldn't want to use madVR Overlay mode or check 'disable GPU gamma ramps' for FSE.

[leeperry]

Originally Posted by mzso

If I understand correctly there is no "image scaling" when I play 1920*1080 content on my 1920*1200 monitor

Chroma is upscaled, because it's stored at half-resolution in YV12.

Originally Posted by dansrfe

If I correctly understand now, disabling the GPU ramps is mainly for the purposes of disabling the application of the ICC profile and letting madVR perform the color correction via yCMS and 3DLUTs?

I rechecked yesterday by creating a funky graphic card's CLUT in RivaTuner and the "disable GPU ramps" doesn't reset the graphic card's CLUT, it really only does what it says...so I don't really see the point of this option tbh.

[Yoshi8765]

Originally Posted by Yoshi8765

@HoP
By DXVA, I mean DXVA2. Does this make a difference?
If madVR doesn't support DXVA2, then the guide I used to set up MPC-HC makes no sense....

The guide I used is here (Image-intensive! and long!): http://wp.me/PrgSo-b1
Can anybody clear this up for me?

[NicolasRobidoux]

Originally Posted by madshi

Why are you using EWA QuadraticJinc instead of EWA LanczosSharp? Is the ringing the only reason?

Yes: EWA QuadraticJinc is my ImageMagick "high quality low ringing" (what I call "natural") linear scheme. (Although I must say that sigmoidization is quite good at suppressing ringing with sRGB images. I'm not including this nonlinear trick in this ranking.)
EWA LanczosSharp (without AR, which is a nonlinear tool, and which has no equivalent in ImageMagick) is great for downsampling and upsampling (so is EWA QuadraticJinc), but it creates too much halo for me to call it "natural looking".
That is: In a sense, EWA QuadraticJinc is my AR-like method without an AR-like limiter.

[starla]

Originally Posted by madshi

But e.g. watching 24fps movies in 50Hz means that the audio is sped up, too, resulting in the Mickey Mouse effect (audio pitch goes up).

Actually Reclock is able to keep the pitch at correct level.

[cyberbeing]

Originally Posted by leeperry

so I don't really see the point of this option tbh.

The point is for disabling the GPU gamma ramp which ICC profiles are loaded to, assuming you want yCMS 3DLUT + madVR shaders only to perform color corrections.

Rivatuner is likely either using a different method for adjusting the GPU CLUT, or preventing the CLUT from being reset. I know that NVIDIA GPUs contain something like 3 different gamma ramp mechanisms (standard Windows/ICC CLUT, driver-based CLUT, low-level ramdac CLUT), which are all unique and apply on top of each other.

[Keiyakusha]

Originally Posted by Yoshi8765

The guide I used is here (Image-intensive! and long!): http://wp.me/PrgSo-b1
Can anybody clear this up for me?

What exactly you want to hear? Here are some facts for you:
- madvr doesn't support native dxva
- dxva doesn't brings anything good (its not bad either, so lets call it useless waste of time).
- that guide you linked talks about different type of dxva. that one doesn't needs to be supported by renderer in any way. It is a feature of LAV video decoder.
- this guide maybe good in terms of providing results that do work, but its makes you do pretty complicated setup. and many things it suggests only needed to work around user's lack of knowledge and possible problems he can face. You supposed to read it and do exactly as it says. But don't try to understand it, because its like reading the book from end to beginning - at some point you'll figure out the story, but its not easy to follow.

[leeperry]

Originally Posted by cyberbeing

The point is for disabling the GPU gamma ramp which ICC profiles are loaded to, assuming you want yCMS 3DLUT + madVR shaders only to perform color corrections.

Rivatuner is likely either using a different method for adjusting the GPU CLUT, or preventing the CLUT from being reset. I know that NVIDIA GPUs contain something like 3 different gamma ramp mechanisms (standard Windows/ICC CLUT, driver-based CLUT, low-level ramdac CLUT), which are all unique and apply on top of each other.

I'm not too sure of how to check if a LUT loaded via ArgyllCMS gets through(I guess I could use pstrip, but this nasty hack gives black screens on unsupported nvidia's IME and I got better things to do than rebooting several times in a row.....or I could create a bogus .cal file), but what mVR would need is something like "dispwin -c" in ArgyllCMS that completely wipes the graphic card's CLUT(s), not just the gamma ramps...but I guess it would have to save it, erase it then restore it when the media player is closed....headaches ahead

[e-t172]

Originally Posted by leeperry

I'm not too sure of how to check if a LUT loaded via ArgyllCMS gets through(I guess I could use pstrip, but this nasty hack gives black screens on unsupported nvidia's IME and I got better things to do than rebooting several times in a row.....or I could create a bogus .cal file)

You can use the X-Rite LUT Tester to check the current state of your hardware LUTs.

Originally Posted by leeperry

but what mVR would need is something like "dispwin -c" in ArgyllCMS that completely wipes the graphic card's CLUT(s), not just the gamma ramps...but I guess it would have to save it, erase it then restore it when the media player is closed....headaches ahead

CLUT = gamma ramps. They're the same thing. "Gamma ramps" is the Windows (MSDN) term for the hardware LUTs.