madVR - high quality video renderer (GPU assisted)

[flossy_cake]

Originally Posted by NeonPhoenix

So is there nothing I can do for better quality?

What quality issues are you having?

[Sunspark]

flossy, is the both bad avoided by using the D3D11 automatic decoder w/ D3D11 presentation path?

I remember there was discussion when it first came out that the advantage of this pairing was that it would fix the chroma problem that nvidia has with dxva2-native.

neon, if you have an overpowered system, you also have the option of doing as huhn does and use "none" for decoding (software, look at task manager to see how much cpu usage increases on the performance tab). But generally, if you're already using copy-back, then all the rest will just come down to your algorithm choices for scaling, dithering, etc. Don't get too carried away, more cpu/gpu usage does not always present a better image.

[flossy_cake]

Originally Posted by Sunspark

flossy, is the both bad avoided by using the D3D11 automatic decoder w/ D3D11 presentation path?

I can't recall, there were some reports a few years ago about D3D11 decoding being broken but that may no longer be relevant.

Regardless, I'm not sure D3D11 decoding is as "tried and tested" as DXVA2-copyback which I've been using for years without issue.

But I recently stopped using it for everything except 4k60/HEVC cause even a i3-12100 can easily decode everything below that without breaking a sweat.

[huhn]

for the like 20 times to the same people madVR doesn't have a d3d11 path it is always d3d9 always.

so the presentation of d3d11 and the decode have nothing todo with each other.

with d3d11 native decode the first thing madVR does is copy that back to d3d9.
with d3d11 presentation it just copies from d3d9 to d3d11 these operation are not free but also not expensive well on a iGPU they kinda are. only presentation is done using d3d11.

this is totally different with proper d3d11 renderer like mpcVR which fully supports d3d11. scaling deint super rez you name it it supports it while madVR can only accept a frame from it and copy that back to d3d9 that's it.

[Sunspark]

I was playing around earlier with monitoring power consumption using hwinfo64. Usually we look at load %s on the CPU and GPU, but total power consumption is I think possibly a better measure. You can right click and have it show graph for total on the cpu package, or individual graphs like IA, GT and DRAM.

madVR is the most power-hungry renderer, even when using DXVA.

[flossy_cake]

Originally Posted by huhn

the presentation of d3d11 and the decode have nothing todo with each other.

but the chroma issue occurs with LAV's DXVA-native so by changing the decoder in LAV to D3D11 is the chroma issue resolved?

[Sunspark]

That's what nevcariel and madshi said back then. That it was a damage-free method of doing native decoding. The presentation path is not very relevant imo because I have observed it is entirely possible to use D3D11 native decoding with a D3D9 presentation path.

I didn't see any test images and I can't test because I don't have nvidia.

Two pairs would have to be looked at in this context:
d3d11n decode-d3d11 pres (even if it's interopped)
d3d11n decode-d3d9 pres

If both the same, and since you already know what it looks like with dxva2n you will have the answer fast.

[Asmodian]

Originally Posted by Sunspark

Two pairs would have to be looked at in this context:
d3d11n decode-d3d11 pres (even if it's interopped)
d3d11n decode-d3d9 pres

The purpose is testing for the chroma bug in native decoding, right? If so, you do not need to test different present methods. They have no connection and no one has ever suggested there was an issue with presentation in either D3D9 or D3D11. There is no "native" or "copy back" for presentation and presentation is done in RGB; a chroma bug similar to the one with DXVA2 native is not even possible.

Worrying about presentation in this case simply over complicates testing.

[huhn]

Originally Posted by flossy_cake

but the chroma issue occurs with LAV's DXVA-native so by changing the decoder in LAV to D3D11 is the chroma issue resolved?

DXVA2 can not handle a YCbCr image over.
so madVR actually gets a DXVA2 scaled RGB image and just uses some math to undo it.

it doing
splitNv12stretchrect
RGBtoYCbCr
YCbCr to CbCr
chroma scaler

d3d11 can hand over a image without touching it in any way.

[Sunspark]

Is the answer for everyone who is able to do D3D11-native decoding, to stop using copy-back as unnecessarily loading on the system when this method exists?

Using copy-back with my settings on total CPU package power (which includes iGPU) I was averaging 12.5 watts on a video's intro. Changing it to D3D11-native increased the power consumption by 1 watt to 13.5. Changing presentation mode to D3D11 down from D3D9 overlay increased the power consumption a further 3 watts to 16.5. Using "None" back on D3D presentation was about 11.5 watts.

I suppose it would change on codec/resolution/scaling, etc. Interesting that "none" for this h.264 piece was 1 watt less than a copy-back operation and that D3D11n was more (implies drivers aren't optimized), which would be fine if it was nvidia and avoided the chroma issue.

Everyone's setup will be different.

[huhn]

because d3d11 native decode isn't properly implemented in madVR.

deint is blocked for example. and there is much more madVR is crippled with it.

hardware decoding isn't cheaper then software too it depends especially with madVR.

the d3d11 to d3d9 interop can cost more then doing software decoding and uploading a huge data stream.
this will not happen with UHD but with a DVD totally possible. for some reason just calling a shader to do something cost quite a big even through the shader is doing close to nothing.

and you can not test this with madVR because of the stuff it does.
setting madVR to film and using dxva2 copyback will show very high CPU usage compared to d3d11 native.

d3d11 presentation is just adding another interop so it should always be slower.

comparing DXVA2 native to D3D11 native is not fair because madVR can't use D3D11 scaling and has to do an interop giving DXVA2 native a huge edge. if you now go and don't use DXVA2 scaling DXVA2 native decode will look slow because it now runs a bunch of additional shaders compared to D3D11 native.

[flossy_cake]

LAV only has one option for d3d11 decoding and its just called "d3d11" - is it native or copyback to RAM?

[huhn]

if you select an adapter it is copyback.
d3d11 can be used headless d3d9 doesn't like that so you can use an iGPU for decode that has no connected display.

d3d11 is in general superior to DXVA2 it can do so much more. madVR implementation is the issue and GPU driver obviously but you can not blame d3d11 for that.

[longiloquence]

Is there a newer build than the one in the OP?

[huhn]

https://www.videohelp.com/software/madVR

beta version are time bombed they only work for a couple of months.
206b was not released by madshi or atleast not in a thread i know about but is from his server.

[NeonPhoenix]

Originally Posted by flossy_cake

What quality issues are you having?

I don't know, just asking about trade for quality settings that I should keep checked for better quality because i've heard some of them are making the image worse if you uncheck it.

[Sunspark]

None of them make the image worse if you uncheck them.

[Asmodian]

The only one that could be argued to at least not harm quality (some say it is better quality) is scale chroma separately, if it saves performance.

Also, don't rerender frames when fade in/out is detected only has an impact when using reduce banding artifacts with a different strength during fade in/out. I always leave it checked because rerendering can cause dropped or delayed frames even on strong hardware, but I don't use reduce banding artifacts either so it is irrelevant.

[clsid]

Anyone who is a novice Madvr user should leave those settings at their defaults.

The quality impact is tiny and performance impact can be significant.

[tp4tissue]

I still use the copyback for black bar removal. My s90c is motorized with 1 meter of travel, on 2:1 movies, sometimes I use the bottom of the screen, sometimes top, just to even the wear out on the oled panel.

It's pretty conveniant the mount saves 4 settings. So you just press 1 button and it gets into position.

Madvr is really the only system that can do this, haha. No tv lets you do what madvr lets you do.