madVR - high quality video renderer (GPU assisted)

[tahaa7]

Its a D3D9 issue, it doesn't offer a way to do a 1:1 conversion from a DXVA video surface to a normal D3D9 Texture, which madVR would need for further processing.
Some more "tricky" ways to perform this conversion have different levels of success on different GPUs. It can result in a slightly blurred chroma channel.

Software decoding or DXVA-CopyBack don't have this issue, because madVR doesn't have to perform such a conversion then and can instead feed the texture from the memory buffer instead.

Sorry, I'm not quite sure I understand. Could you please explain in a bit more detail? I'm relatively new to this, so I don't know all the inner workings of how madVR (or DXVA) works. And why is Nvidia specific in that regard?

[madshi]

But what would be the reason for moving subs up and down? You either want them in the video frame or you don't, do you?

I'm asking because I don't know if something could be done for ASS/SSA subs but the "moving subs up and down depending on videos" seems like a less likely scenario than just wanting subs to be at the right size for reading them at any given distance... I don't think I'm that peculiar in my use case, am I?
For me position is more important than size, but size should be alright, too, of course. cyberbeing already had a patch prepared to optimize size calculations, I'll ask him, maybe he can do a test build to move this forward.

How about the mem leak? Was it pointed and fixed?
No, not yet, not sure yet if it's madVR's fault, I have my doubts, but we'll see...

Does SystemCompute fairly accurately reflect MadVR's overall performance (ED, NNEDI3, etc.)?
I don't know.

If its not too time consuming, is it possible to implement nested if/else profile logic? It would make them a bit easier to manage and test.
I'll add it to my to do list, but no ETA. Not sure how time consuming it would be to implement.

Sorry, I'm not quite sure I understand. Could you please explain in a bit more detail? I'm relatively new to this, so I don't know all the inner workings of how madVR (or DXVA) works. And why is Nvidia specific in that regard?
Can't you just trust in what we said? Namely that native DXVA decoding comes with a small quality loss on some GPUs? That's a fact. *Why* that is the case is highly technical and shouldn't really be very important to you as a user, or am I wrong? It's just the way it is. Use native DXVA decoding if you want lowest power consumption. Use copyback DXVA or software decoding if you want highest quality. My best guess is that CUVID will sooner or later disappear from LAV Video Decoder. Of course only nevcairiel knows for sure... :)

[madshi]

Those of you with memory leak problems (sneaker_ger and nijiko?), can you please try the following test builds?

http://madshi.net/madVR89leakTest.rar

@nijiko, if you have total PC freezes with v0.89.11, I'd recommend to start with test build 5 and work your way up to build 1, because build 5 is nearest to v0.89.9. So if you have no problems with v0.89.9, test build 5 is the most likely to still work ok, and the risk of getting problems is getting higher, as you get nearer to test build 1.

[tahaa7]

Can't you just trust in what we said? Namely that native DXVA decoding comes with a small quality loss on some GPUs? That's a fact. *Why* that is the case is highly technical and shouldn't really be very important to you as a user, or am I wrong?

I believe you got me wrong, I trust what you guys said, I never said I didn't trust you. I am just curious as to why what you guys have said is true, I want to learn why it is so. Sure, if I was just a regular user, all of that wouldn't be important to me, and I wouldn't care one bit about it. (in fact, if I was an average consumer/user, I probably wouldn't even know about madVR and LAV filters anyway). But I do care. And I highly appreciate the work you guys have done and continue to do. Sorry if I came across any other way.

[aufkrawall]

I think it wouldn't make sense for madshi or nevcairiel to invest quite some time in explanations that only 1 or 2% of the users would understand.
It would probably end up quickly in code examples etc and I think that's not the purpose of this platform.

[rack04]

I'm struggling to understand the "automatically detect hard coded black bars" option. If I select this option with none of the other options selected my 720x480 (16:9) movie is changed to 720x480 (21:9). If I select "crop black bars" it changes the 720x480 (16:9) movie to 719x360 (21:9). Is that intended?

[nevcairiel]

I'm struggling to understand the "automatically detect hard coded black bars" option. If I select this option with none of the other options selected my 720x480 (16:9) movie is changed to 720x480 (21:9). If I select "crop black bars" it changes the 720x480 (16:9) movie to 719x360 (21:9). Is that intended?

Sounds normal to me, as long as the active image remains the same aspect ratio in all 3 cases.

[ashlar42]

For me position is more important than size, but size should be alright, too, of course. cyberbeing already had a patch prepared to optimize size calculations, I'll ask him, maybe he can do a test build to move this forward.Thanks a lot. I might have misunderstood the "moving" part. I thought people wanted to see some movies with subs in a certain position and some others with subs in a different position. If that was not the case, then sure, position is important too (although... too big can be handled, too small... you don't read it making subs useless :) ).

[KoD]

Its a D3D9 issue, it doesn't offer a way to do a 1:1 conversion from a DXVA video surface to a normal D3D9 Texture, which madVR would need for further processing.
Some more "tricky" ways to perform this conversion have different levels of success on different GPUs. It can result in a slightly blurred chroma channel.

Software decoding or DXVA-CopyBack don't have this issue, because madVR doesn't have to perform such a conversion then and can instead feed the texture from the memory buffer instead.
Trying to do the same for DXVA-Native would end up being practically the same as a CopyBack operation, so madshi decided to just let the user use LAV's copyback instead, since thats rather optimized.
This is surprising to me too, I was not aware DXVA native was in any way different from the CB option, except that it involved an additional memory transfer.

How about the case when DXVA deinterlacing is enabled in madVR (and any form of deinterlacing is disabled in LAV filters)? Would the same issue with chroma loss happen in this case too, irrespective of where the video decoding happened (by the CPU in software, by QS, or by the GPU in copy-back mode)?

[Asmodian]

I believe you got me wrong, I trust what you guys said, I never said I didn't trust you. I am just curious as to why what you guys have said is true, I want to learn why it is so. Sure, if I was just a regular user, all of that wouldn't be important to me, and I wouldn't care one bit about it. (in fact, if I was an average consumer/user, I probably wouldn't even know about madVR and LAV filters anyway). But I do care. And I highly appreciate the work you guys have done and continue to do. Sorry if I came across any other way.

If I remember past hints correctly; DXVA decoding leaves the video data in a format different from what madVR operates on. madshi has a tricky way to access the data correctly but while on Intel and AMD GPUs this method does not cause any loss something about how it works on Nvidia GPUs damages the chroma planes a little bit. Not really a technical answer but enough for what I feel the need to know. ;)

[DragonQ]

My best guess is that CUVID will sooner or later disappear from LAV Video Decoder. Of course only nevcairiel knows for sure... :)

I hope not. :(

I suppose by the time that happens MediaPortal 2 will be viable and that supposedly includes decent scaling algorithms, unlike the awful bilinear used in MediaPortal 1.

[aufkrawall]

on Nvidia GPUs damages the chroma planes a little bit.
It's really not just "a little bit": The blur is very ugly with cartoons and makes it totally absurd to select a HQ chroma scaling algorithm like Jinc, since it will hardly look better than just bilinear scaling.

[markanini]

I have a PAL DVD that madvr finds a cadence 2:2 on. Disabling deinterlacing looks identical though. Is it okay to add deint=off to the file name?

[DragonQ]

I have a PAL DVD that madvr finds a cadence 2:2 on. Disabling deinterlacing looks identical though. Is it okay to add deint=off to the file name?

2:2 cadence means it's 25 PsF. As long as the field order is set correctly in the container and/or stream, disabling interlacing has the same effect as (correctly) applying weave deinterlacing. So yes, you can add that.

[sneaker_ger]

Those of you with memory leak problems (sneaker_ger and nijiko?), can you please try the following test builds?

http://madshi.net/madVR89leakTest.rar
build 1: climbs to 330k, then to 370k but stays there
build 2: climbs to 327k, then to 333k but stays there
build 3: climbs to 326k, then to 335k but stays there
builds 4 + 5:
http://abload.de/img/build45_shader_error_e8sds.png

So, basically none of the builds has the extreme problem I have with the release builds. Build 1 is worst but still well below 400k, release builds just grow and grow extremely fast...

[madshi]

I am just curious as to why what you guys have said is true, I want to learn why it is so. Sure, if I was just a regular user, all of that wouldn't be important to me, and I wouldn't care one bit about it. (in fact, if I was an average consumer/user, I probably wouldn't even know about madVR and LAV filters anyway). But I do care.
Alright. DXVA outputs decoding results as "IDirect3DSurface9". madVR uses pixel shaders to do video processing, but pixel shaders can't access "IDirect3DSurface9". So madVR has to do lossy conversions to make the "IDirect3DSurface9" accessible for pixel shaders. This problem does not occur when using copyback or software decoding, because madVR has the pixels in CPU RAM then and can upload them to the GPU in a format pixel shaders can work with. Now don't ask me why Microsoft had the glorious idea to have DXVA output data in a format the pixel shaders can't process. You'd have to ask them, I can't really tell you that.

How about the case when DXVA deinterlacing is enabled in madVR (and any form of deinterlacing is disabled in LAV filters)? Would the same issue with chroma loss happen in this case too, irrespective of where the video decoding happened?
Yes.

build 1: climbs to 330k, then to 370k but stays there
build 2: climbs to 327k, then to 333k but stays there
build 3: climbs to 326k, then to 335k but stays there

So, basically none of the builds has the extreme problem I have with the release builds. Build 1 is worst but still well below 400k, release builds just grow and grow extremely fast...
Ok, try this build, based on my latest sources. Does it fix the problem?

http://madshi.net/madVR8911sneaker.rar

I'm struggling to understand the "automatically detect hard coded black bars" option. If I select this option with none of the other options selected my 720x480 (16:9) movie is changed to 720x480 (21:9). If I select "crop black bars" it changes the 720x480 (16:9) movie to 719x360 (21:9). Is that intended?
You're not listing the whole OSD output, though, or you're using a rather old madVR build. The latest build should show:

with "crop black bars" disabled:
movie 720x480 (21:9)

with "crop black bars" enabled:
720x480 -> 719x360 (21:9)

I don't think I can make it any clearer than that in the limited space the OSD has available.

[sneaker_ger]

Ok, try this build, based on my latest sources. Does it fix the problem?

http://madshi.net/madVR8911sneaker.rar
Yes, it seems to behave like prior test build 1. (Never exceeds 370k)

[nevcairiel]

Now don't ask me why Microsoft had the glorious idea to have DXVA output data in a format the pixel shaders can't process. You'd have to ask them, I can't really tell you that.

Because in their world you are also using DXVA video processing and converting the video to RGB with that. :)

[tahaa7]

Alright. DXVA outputs decoding results as "IDirect3DSurface9". madVR uses pixel shaders to do video processing, but pixel shaders can't access "IDirect3DSurface9". So madVR has to do lossy conversions to make the "IDirect3DSurface9" accessible for pixel shaders. This problem does not occur when using copyback or software decoding, because madVR has the pixels in CPU RAM then and can upload them to the GPU in a format pixel shaders can work with. Now don't ask me why Microsoft had the glorious idea to have DXVA output data in a format the pixel shaders can't process. You'd have to ask them, I can't really tell you that.

Thank you, madshi.

[KoD]

How about the case when DXVA deinterlacing is enabled in madVR (and any form of deinterlacing is disabled in LAV filters)? Would the same issue with chroma loss happen in this case too, irrespective of where the video decoding happened?
Yes.
Ok, that's unfortunate.
My final question is: if DXVA deinterlacing is enabled in madVR, but the OSD reports during playback that deinterlacing is off (because the current file does not need it), is this lossy process still taking place?

[rack04]

You're not listing the whole OSD output, though, or you're using a rather old madVR build. The latest build should show:

with "crop black bars" disabled:
movie 720x480 (21:9)

with "crop black bars" enabled:
720x480 -> 719x360 (21:9)

I don't think I can make it any clearer than that in the limited space the OSD has available.

Here are a couple screenshots with various settings. I'm just wondering why the DAR is changing from 16:9 to 21:9.

http://i11.photobucket.com/albums/a199/rack04/Enabled%20Detect%20Hard%20Coded%20No%20Crop_zpshfzs0h4q.jpg (http://s11.photobucket.com/user/rack04/media/Enabled%20Detect%20Hard%20Coded%20No%20Crop_zpshfzs0h4q.jpg.html)

http://i11.photobucket.com/albums/a199/rack04/Enabled%20Detect%20Hard%20Coded%20Crop_zpsjplt0hke.jpg (http://s11.photobucket.com/user/rack04/media/Enabled%20Detect%20Hard%20Coded%20Crop_zpsjplt0hke.jpg.html)

http://i11.photobucket.com/albums/a199/rack04/Disabled%20Detect%20Hard%20Coded_zpseasw2ola.jpg (http://s11.photobucket.com/user/rack04/media/Disabled%20Detect%20Hard%20Coded_zpseasw2ola.jpg.html)

[madshi]

Yes, it seems to behave like prior test build 1. (Never exceeds 370k)
Good to hear!

Because in their world you are also using DXVA video processing and converting the video to RGB with that. :)
Haha, yes, good point... :)

My final question is: if DXVA deinterlacing is enabled in madVR, but the OSD reports during playback that deinterlacing is off (because the current file does not need it), is this lossy process still taking place?
No.

Here are a couple screenshots with various settings. I'm just wondering why the DAR is changing from 16:9 to 21:9.
Please use "Aspect Ratio -> Fit to Video" and not "Fit to Window". Using "Fit to Window" often destroys the correct aspect ratio. The black bar detection stuff makes much more sense if you use "Fit to Video", as you're supposed to.

[rack04]

Please use "Aspect Ratio -> Fit to Video" and not "Fit to Window". Using "Fit to Window" often destroys the correct aspect ratio. The black bar detection stuff makes much more sense if you use "Fit to Video", as you're supposed to.

I couldn't find this setting using MPC-BE.

[madshi]

I couldn't find this setting using MPC-BE.
Ah sorry, my fault. In that case use "Video Frame -> Touch Window From Inside". Do *not* use "Stretch To Window". Same thing as in my previous post, just other names.

[rack04]

Ah sorry, my fault. In that case use "Video Frame -> Touch Window From Inside". Do *not* use "Stretch To Window". Same thing as in my previous post, just other names.

I have that option enabled.

http://i11.photobucket.com/albums/a199/rack04/Untitled_zps1x4uvts2.jpg (http://s11.photobucket.com/user/rack04/media/Untitled_zps1x4uvts2.jpg.html)

[madshi]

Oh, that's surprising. And that is with madVR v0.89.11? Which MPC-BE version are you using? Can you create a debug log for me, and maybe upload a small sample of that video file?

[rack04]

Oh, that's surprising. And that is with madVR v0.89.11? Which MPC-BE version are you using? Can you create a debug log for me, and maybe upload a small sample of that video file?

I am using madVR v0.89.11 and MPC-BE v1.4.6.892. I'm not sure how to cut a small sample but it happens with all of my DVDs. Here is a debug log.

http://www.megafileupload.com/qjnU/madVR_-_log.txt

[Knight77]

I've seen from your posts and your (very good) guide that when there's not image upscaling (ex. 720p>1080p) you prefer to do not activate Superres in Chroma Upscaling but you prefer Finesharp in Image Enhancement, is because you do not think that SR in that case is visible/useful?

Another thing that really interest me is to understand the "real" difference between xbr-100 and 150, I could not find any comparison but just people preferring one or the other but without a real explanation of the reason.

Guys any comments on this?

[Magik Mark]

Madshi,

Do you have any idea on how madvr would fair with Nvidia Quadro M6000?

[6233638]

I have that option enabled.
http://s11.photobucket.com/user/rack04/media/Untitled_zps1x4uvts2.jpg.htmlDo you have any form of aspect ratio correction enabled?
I found that enabling it in JRiver Media Center really messes things up when videos contain multiple aspect ratios.

For example, I have a video which is supposed to be displayed as 16:9, but it is horizontally compressed.
This video contains three different aspect ratios:
16:9 full-screen
4:3 pillarboxed (12:9)
16:9 windowboxed (16:9 letterboxed in a 4:3 frame)

Because it is horizontally compressed, it actually displays as approximately:
15:9 full-screen
11:9 pillarboxed
15:9 windowboxed (15:9 letterboxed in an 11:9 frame)

If I enable aspect ratio correction in JRMC what happens is that you get:

15:9 full-screen → 16:9 full-screen (correct)
11:9 pillarboxed → stretched to 16:9 full-screen (very wrong!)
15:9 windowboxed → 16:9 full-screen (correct)


The current best solution is to forgo the aspect ratio correction and have Zoom Control handle the windowboxed image:
15:9 full-screen → 15:9 full-screen
11:9 pillarboxed → 11:9 pillarboxed
15:9 windowboxed → 15:9 full-screen
This is wrong, but not disastrously wrong.

[baii]

Madshi,

Do you have any idea on how madvr would fair with Nvidia Quadro M6000?
It will just work like it's GeForce counter part, madvr don't get any benefit from huge Vram or pro card features.

Sent from my SM-T700 using Tapatalk

[AngelGraves13]

Does SuperRes do any deblocking? Trying to figure out what it does exactly.

The only thing missing from madVR at this point is a deblocking filter. MPEG-2 DVDs look horrible when upscaled.

[blueray101]

Can someone please tell the best setting for watching anime in 720p and 1080p for a high-end PC. I never watch anything below that.

[nijiko]

Those of you with memory leak problems (sneaker_ger and nijiko?), can you please try the following test builds?

http://madshi.net/madVR89leakTest.rar

@nijiko, if you have total PC freezes with v0.89.11, I'd recommend to start with test build 5 and work your way up to build 1, because build 5 is nearest to v0.89.9. So if you have no problems with v0.89.9, test build 5 is the most likely to still work ok, and the risk of getting problems is getting higher, as you get nearer to test build 1.

OK, when I have time, I'll test it immed. THX

[mindz]

Alright. DXVA outputs decoding results as "IDirect3DSurface9". madVR uses pixel shaders to do video processing, but pixel shaders can't access "IDirect3DSurface9". So madVR has to do lossy conversions to make the "IDirect3DSurface9" accessible for pixel shaders. This problem does not occur when using copyback or software decoding, because madVR has the pixels in CPU RAM then and can upload them to the GPU in a format pixel shaders can work with. Now don't ask me why Microsoft had the glorious idea to have DXVA output data in a format the pixel shaders can't process. You'd have to ask them, I can't really tell you that.

Is this also true for Intel QuickSync decoding?

[tahaa7]

Is this also true for Intel QuickSync decoding?

And is this the case with all Nvidia GPUs, and with ATI/AMD as well?

[huhn]

quicksync is copyback only.

but the case where quicksync is a better choice than DXVA copyback is pretty rare.


and there is a simple solution to all theoretical DXVA native issue. it is called DXVA copyback.

[chros]

...when there's not image upscaling (ex. 720p>1080p)...
Guys any comments on this?
But there IS image upscaling in this case, right? :)

[Knight77]

But there IS image upscaling in this case, right? :)

Yes I got it, I meant there's not resolution upscaling... you got what I meant :-P

Any further comment on what I posted?

Anyway I've got another little doubt: when I play videos using MadVr I noticed that the CPU is not much involved, like 20% usage, is it normal? I know that lot of work is done by my GTX960 but the common idea is that MadVr needs good CPU...why if my old i3 is used only at 20%?

[huhn]

madVR doesn't really use the CPU.

[dimitrik]

I'm getting about 10-20 frame drops (reported) per min on my HTPC (specs below) despite low render times (10-20ms depending on scaling factor).
Queues are all full and OSD does not predict any frame drops (it just says something like "1 frame repeat every 16 hours etc).

This occurs on both nnedi3 and super-xbr, as well as with just jinc upscaling.
I tested both 10-bit and 8-bit output and the problem is there in both cases.

My settings are:

D3D11, FSE
All "trade quality for performance" options off
Debanding: low/medium
Ordered Dithering
Chroma upscaling: Jinc
Image doubling: s-xbr or nnedi3/32
Downscaling:Catmul Rom/AR/LL
Upscaling refinement: off
LAV set to software decoding
TV (Sony Bravia W9) running in native 24p (MadVR set to change Refresh rate to video fps)
Catalyst Omega 14.12 drivers
Native RGB colorspace everywhere
MadVR 0.89.6

The problem exists with most files I tested, including 1080p, 720p and SD content. All the affected files play fine on my desktop (specs also below).

Any ideas what I could do to fix this?
:confused:

[aufkrawall]

Don't disable deband fade-in-out performance trade-off option, it requires very long queues to prevent frame drops.

[mcn]

When I pause a video I can see that the image goes back a few frames.

I noticed this while presenting 8 frames in advance.
Setting it down to 1 helps tremendously but sometimes I can still see this glitch.

If I completely disable the presentation of frames in advance the problem is persists and is unmitigated.
In this case changing the number of backbuffers doesn't seem to do anything.

I'm avoiding additional details about my setup on purpose, to keep down the noise. If you need more info ask away.

[dimitrik]

Don't disable deband fade-in-out performance trade-off option, it requires very long queues to prevent frame drops.

Thanks! Will give that a try...

Or since I can output 10 bit, perhaps I could also disable debanding as a worst case...

[huhn]

outputting 10 bit doesn't remove banding from a source.

[markanini]

I get some visible tearing when using a custom 71.928 Hz refresh rate in fullscreen exclude and windowed mode. HD7700 Windows 10.

[KoD]

madshi, thanks for the answer.

So, this means that at least when watching progressive material, there is no lossy conversion process affecting chroma. Too bad that as soon as DXVA deinterlacing gets activated, one still gets the lossy conversion, even when using DXVA copyback. DXVA copyback is not the hardware accelerated solution that gives the best quality in all cases like suggested in the posts above then.

Software deinterlacing using Yadif is not up to par to DXVA deinterlacing so this is a no go, and hardware deinterlacing with QS is broken in some cases. From all these options, I guess QS has the best chances of ending up as a working solution. I'll bother nevcariel in his thread with samples where QS deinterlacing breaks then, maybe something can be done about it.

[nevcairiel]

I'll bother nevcariel in his thread with samples where QS deinterlacing breaks then, maybe something can be done about it.

Don't bother, QS is an external component and I have no interest in fixing code that I didn't even write.

[dimitrik]

outputting 10 bit doesn't remove banding from a source.

Noted, thank you. I was aware in retrospect, but somehow got confused. I think because of native 10-bit content not suffering from banding as much as 8-bit...

Don't disable deband fade-in-out performance trade-off option, it requires very long queues to prevent frame drops.

That completely solved the problem, many thanks!:thanks:

[Asmodian]

That completely solved the problem, many thanks!:thanks:

Another option is to set both debanding settings to the same level; this disables fade detection entirely which also improves debanding performance slightly.