madVR - high quality video renderer (GPU assisted)

[Nachbar]

Does madvr support 36-bit deep color output or does it cap out at 30-bit?

I ask this because I believe my receiver is taking 30-bit output and down converting it to 24-bit. It is a Pioneer VSX 1021-K which the specs say it supports 36-bit deep color and no mention of anything else.

If I connect my computer directly to my TV it is fine and the test picture I am viewing shows no banding but if I go through the receiver it shows banding.

I have made sure the display properties in madvr is set to 10-bit and higher and made sure in catalyst control center that the display is set to 12-bit.

The manual doesn't mention if only certain HDMI ports accept this or not. I could try moving it around and testing a bit more. I am using the same input on the TV that works and made sure it is set to PC and UHD color.

[6ari8]

Originally Posted by Anime Viewer

Yes, I have an HDMI port that I connect my TV to, but both the TV and the laptop screen are shown to go through the Intel GPU like the second image you posted. Here is the PhysX display diagram on my system:

Mine's like the second one. Yours seems to be like the third image.

Unfortunately, that means that all your output ports are connected to the Intel GPU.

I don't know what gaming laptop makers were thinking by choosing to connect output ports to the iGPU. I think anyone using their laptop to drive monitors with those ports would be using a power supply so connecting them to the discreet GPU would've been a much better choice.

With your setup, I think you should use exclusive mode with either D3D9 or D3D11 because that brings down the present stats to around 1-3ms for me when I'm using my HDMI port. Windowed mode gives me 8-9ms present.

[trip_let]

I was checking through a variety of content to find bad samples for s-xbr and just ran across a case where s-xbr doubling at any sharpness gets confused. I'm sure there are others, but in case someone's never seen what weirdness can happen sometimes, here it is.

s-xbr 50 vs. nnedi3 16
http://screenshotcomparison.com/comparison/134926

Original image


Doesn't really matter which s-xbr setting; it gets confused and erases some of the lines in the background grid in the box with the 32275GP with all of them. And there's nothing special about nnedi3, which was used for comparison. It could have been anything else. I think SuperRes may be on for both, but that's besides the point and not consequential.

[iSunrise]

@trip_let:
Your example perfectly shows, why super-xbr in it's current state is not a contender to NNEDI3 at all. Personally, I found the loss of picture details disturbing and also the strange alterations in various samples. Your example (and other tests I've done yesterday) only show that:

1) super-xbr seems to completely erase/destroy very visible picture details and also fine detail (look at the various 1s at the bottom, it almost modifies the 1 to an I, unacceptable)
2) NNEDI3 is a lot sharper than super-xbr (which is a result of the loss of fine detail)
3) super-xbr "rounds everything" and acts as some kind of anti-aliasing filter, adding picture information where there was none before

People that want an accurate representation of the original should stay away from it, even though it might be a lot faster.

Personally, I found that the new bilateral chroma scaler is extremely promising, at least on the samples I've watched closely, it's also extremely fast, looks great and is a perfect combination with NNEDI3 doubling and Bicubic50/75 for luma upscaling. Very good results if you can take the NNEDI3 performance hit.

[nevcairiel]

Pixel Art is a special kind of content, and resizers/doublers designed for generic content will just not always handle it properly. Its not a very convincing example of anything other than the fact that it doesn't work nicely for Pixel Art.

[madshi]

Originally Posted by leeperry

I would also be cool with creating a folder in mVR's folder such as "SuperRes HQ OFF" or something if that's not too much trouble please.

Ok, I could live with that. Will add it to a future build.

Originally Posted by kasper93

@madshi: Something weird is going on. If I make MPC-HC window size equal to screen size madVR will go into exclusive mode and position window in center even though it weren't before. If I open context menu to disable exclusive mode it window go back to its original place. Also seekbar doesn't work in this "exclusive mode" probably it is not reported correctly.

To reproduce open any file in MPC-HC. And stretch the window to display size (not work area size). Basically this means to Make MPC-HC max size. To do that you need manual grab window borders and stretch it.

I will look into details tommorow. But it looks like madVR have "if (windowSize == displaySize) GoToRetardedExclusiveMode();" logic

That sounds quite weird! I'm having trouble reproducing it, though. I suppose the MPC-HC window is not centered on the screen in this situation, is it? Could you create a debug log that shows this situation?

Originally Posted by Warner306

Today, I attempted to embrace image sharpening as tool to improve an image rather than enhance its artifacts. I found the following settings beneficial in improving the quality of high-definition video:

1080p -> 1080p
Image Enhancements - FineSharp (strength 0.6)

720p -> 1080p
Upscaling Refinement - SuperRes (medium: strength=1.0; passes=1)

SuperRes is my favourite of the two. Its ringing is not obvious or bothersome compared to other sharpeners. I'm curious if the luma and chroma are doubled together or just the luma like the other shaders?

An AR filter for FineSharp would be great.

I had tried to add an AR filter for FineSharp, but my first try didn't work very well. Will have to try again later...

Originally Posted by Nachbar

Does madvr support 36-bit deep color output or does it cap out at 30-bit?

Direct3D11 supports either 8bit, 10bit or 16bit, but not 12bit. The GPU drivers make of that whatever they want. If I output 10bit, some GPU drivers output 10bit, others 12bit, others 8bit or 16bit. So in other words I don't have exact control over what the GPU outputs, unfortunately.

Originally Posted by trip_let

I was checking through a variety of content to find bad samples for s-xbr and just ran across a case where s-xbr doubling at any sharpness gets confused. I'm sure there are others, but in case someone's never seen what weirdness can happen sometimes, here it is.

s-xbr 50 vs. nnedi3 16
http://screenshotcomparison.com/comparison/134926

Original image


Doesn't really matter which s-xbr setting; it gets confused and erases some of the lines in the background grid in the box with the 32275GP with all of them. And there's nothing special about nnedi3, which was used for comparison. It could have been anything else. I think SuperRes may be on for both, but that's besides the point and not consequential.

Interesting!

Originally Posted by iSunrise

@trip_let:
Your example perfectly shows, why super-xbr in it's current state is not a contender to NNEDI3 at all. Personally, I found the loss of picture details disturbing and also the strange alterations in various samples. Your example (and other tests I've done yesterday) only show that:

1) super-xbr seems to completely erase/destroy very visible picture details and also fine detail (look at the various 1s at the bottom, it almost modifies the 1 to an I, unacceptable)
2) NNEDI3 is a lot sharper than super-xbr (which is a result of the loss of fine detail)
3) super-xbr "rounds everything" and acts as some kind of anti-aliasing filter, adding picture information where there was none before

People that want an accurate representation of the original should stay away from it, even though it might be a lot faster.

Originally Posted by nevcairiel

Pixel Art is a special kind of content, and resizers/doublers designed for generic content will just not always handle it properly. Its not a very convincing example of anything other than the fact that it doesn't work nicely for Pixel Art.

^

Agree with nevcairiel. Although super-xbr was originally made for pixel art! Which means that maybe Hyllian may want to look into this issue? Not sure if it's easily fixable, though.

In any case, yes, NNEDI3 is superior to super-xbr in quality - but at a multiple of the performance cost. It's your decision which algo to use, of course.

Originally Posted by iSunrise

Personally, I found that the new bilateral chroma scaler is extremely promising, at least on the samples I've watched closely, it's also extremely fast, looks great and is a perfect combination with NNEDI3 doubling and Bicubic50/75 for luma upscaling. Very good results if you can take the NNEDI3 performance hit.

There are some samples which show significant problems with the bilateral chroma upscaler, though. So once we concentrate on that, we'll have to collect such samples and try to fix them. For now I'm still concentrated on SuperRes.

[madshi]

madVR v0.88.17 released

http://madshi.net/madVR.zip

* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic
* added SuperRes anti-ringing filter
* fixed little SuperRes quality detoriation introduced in v0.88.16
* fixed: high GPU consumption in paused mode (PotPlayer, Kodi DSPlayer)
* all (useful) IVideoWindow APIs now work even when no pins are connected

For users, this build is probably not much different to Saturday's test build. Well, at least I hope so. However, for some media player developers there's a big (positive) change. I've been asked to do rendering in paused and stopped modes for a long time, and now finally it's implemented. This required some deeper changes, though, so there's a certain danger of new bugs showing up.

Notes for media player developers:

1) Please set the owner/parent *before* you connect the pins.
2) All the various OSD interfaces in madVR now also work in paused and stopped mode. Maybe you can make use of it in some way?
3) If you're using IOsdRenderCallback, *PLEASE* make sure that your ClearBackground() and RenderOsd() callbacks return "ERROR_EMPTY" if there is no active OSD on screen. This is very important because if you don't return ERROR_EMPTY, madVR will switch into low latency mode to speed up your OSD reaction times. This is good for OSD latency, but not good for video playback reliability.
4) If you're using IMadVROsdServices::OsdSetBitmap, there's a new flag (see header files) that tells madVR whether your OSD bitmap needs low latency or not. Low latency makes sense for OSD elements the user can use to control something, but probably not for purely informational OSD elements.
5) You can see whether madVR is in low latency mode by checking the size of the "present queue". In low latency mode this queue is limited to 2 frames.

[ryrynz]

Originally Posted by madshi

You can see whether madVR is in low latency mode by checking the size of the "present queue". In low latency mode this queue is limited to 2 frames.

Any particular reason for this feature?

[madshi]

Faster OSD reaction times, of course. Not so important for simple informational texts like "exclusive" or "windowed". But things like the FSE seekbar or even more complex OSD elements do benefit. Some media players draw complex OSDs through the madVR OSD interfaces.

[Prinz]

I have here a video file that results in black video screen (windowed mode) with all current version. 0.88.8 is the last that works, 0.88.9 and 0.88.10 crash right away, all newer versions have black video screen in windowed mode.

[madshi]

Sample?

[6ari8]

In 0.88.17, both MPC-HC and MPC-BE stutter when I bring up the OSD (CTRL+j) during playback.
No frame drops/repeats but it acts as if it's dropping frames.

[leeperry]

Originally Posted by madshi

* fixed: high GPU consumption in paused mode (PotPlayer

Oh wow, too good!

Originally Posted by madshi

Ok, I could live with that. Will add it to a future build.

Awesomtastic, thank you! I still don't understand why I would be the only one seeing that nasty veil among the few mVR users who currently aren't on vacation huh......maybe it somehow synergizes with dynamic dithering, I could imagine it making the dancing noise patterns less obvious or maybe the latter completely hide the veil.

I had a really good look at what HQ does and I must admit that I see the exact same veil in the HDTV tuner of my Sammy TV, I only see it in mVR when HQ is on....maybe it's display dependent then huh, not sure but either way I can't wait to try the new SR AR coz sxbr50 does kinda look like the rings of Saturn on bad sources ^^

Please allow me to +1 the request of a few other SR users to please allow us specifying the number of passes and strength along with the new presets. I do realize that less is more when it comes to sharpening and that I'm currently going way overboard on sharpness in SR so I would happily try presets but a good bunch of us would also very much fancy the ability to specify our own parameters.

[mogli]

With the new release all queues display as empty while playing and only fill when paused, though everything seems to work fine nevertheless.

[iSunrise]

Originally Posted by madshi

Agree with nevcairiel. Although super-xbr was originally made for pixel art! Which means that maybe Hyllian may want to look into this issue? Not sure if it's easily fixable, though.

It would certainly be great if he can reduce the rounding that seems to occur, which also eats into some details. Maybe he can optimize that to be a little less aggressive.

Originally Posted by madshi

There are some samples which show significant problems with the bilateral chroma upscaler, though. So once we concentrate on that, we'll have to collect such samples and try to fix them. For now I'm still concentrated on SuperRes.

OK. I would be very interested in some samples that show artefacts, because when I used them on mine, I was pleasently surprised by it's sharpness and detail retention.

[James Freeman]

Originally Posted by madshi

* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic

What are the benefits/purpose of these?

[Ver Greeneyes]

Originally Posted by mogli

With the new release all queues display as empty while playing and only fill when paused, though everything seems to work fine nevertheless.

I'm seeing the same thing. Happens both with D3D9 and D3D11. No frames seem to actually drop, so it must be a visual issue.

[rack04]

Originally Posted by mogli

With the new release all queues display as empty while playing and only fill when paused, though everything seems to work fine nevertheless.

I was just about to report the same problem.

[Anime Viewer]

Originally Posted by madshi

madVR v0.88.17 released

http://madshi.net/madVR.zip

* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic
* added SuperRes anti-ringing filter
* fixed little SuperRes quality detoriation introduced in v0.88.16
* fixed: high GPU consumption in paused mode (PotPlayer, Kodi DSPlayer)
* all (useful) IVideoWindow APIs now work even when no pins are connected

For users, this build is probably not much different to Saturday's test build. Well, at least I hope so. However, for some media player developers there's a big (positive) change. I've been asked to do rendering in paused and stopped modes for a long time, and now finally it's implemented. This required some deeper changes, though, so there's a certain danger of new bugs showing up.

Notes for media player developers:

1) Please set the owner/parent *before* you connect the pins.
2) All the various OSD interfaces in madVR now also work in paused and stopped mode. Maybe you can make use of it in some way?
3) If you're using IOsdRenderCallback, *PLEASE* make sure that your ClearBackground() and RenderOsd() callbacks return "ERROR_EMPTY" if there is no active OSD on screen. This is very important because if you don't return ERROR_EMPTY, madVR will switch into low latency mode to speed up your OSD reaction times. This is good for OSD latency, but not good for video playback reliability.
4) If you're using IMadVROsdServices::OsdSetBitmap, there's a new flag (see header files) that tells madVR whether your OSD bitmap needs low latency or not. Low latency makes sense for OSD elements the user can use to control something, but probably not for purely informational OSD elements.
5) You can see whether madVR is in low latency mode by checking the size of the "present queue". In low latency mode this queue is limited to 2 frames.

I'm not sure which change its from, but my OSD no longer seems to be reporting accurate information:

Even though it says 0s for target rectangle, and all of the queues I'm not seeing any problems with the video playing. (Therefore the dropped frames, delayed frames, and presentation glitches 0s may be correct. I can change my settings to something my system can't handle like 256 neurons, and see if it still reports no problems with drops and glitches to see they are being misreported too). This screen capture of the OSD was taken with the video playing, so it wasn't during a pause or stop.
Edit: When I changed to 256 neurons my render times shot up to 96ms, and I did get dropped frames and presentation glitches so the 0's reported in those areas were accurate.

[michkrol]

@madshi, a small tweak for some (later) build: could we get keyboard shortcuts for the new chroma upscaling algos (Bilateral, NEDI, s-xbr) as well as ability to switch to/from them with the "chroma upscaling algorithm - toggle" key?

Originally Posted by mogli

With the new release all queues display as empty while playing and only fill when paused, though everything seems to work fine nevertheless.

Similar thing happens here on MPC-HC (x64) V1.7.9.54 (nightly).
For me the queues show as 0-x/x while playing and x-x/x while paused.
No frame drops, playback is stable.
Screenshots below.



EDIT: Looks like I'm the n-th person to report this (I'm a slow writer). Sorry for the duplicate info/unintended spam.