Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th October 2015, 13:15   #33701  |  Link
tahaa7
Registered User
 
Join Date: Nov 2012
Posts: 36
Quote:
Originally Posted by nevcairiel View Post
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?

Last edited by tahaa7; 18th October 2015 at 13:25.
tahaa7 is offline   Reply With Quote
Old 18th October 2015, 13:33   #33702  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by ashlar42 View Post
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.

Quote:
Originally Posted by nijiko View Post
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...

Quote:
Originally Posted by seiyafan View Post
Does SystemCompute fairly accurately reflect MadVR's overall performance (ED, NNEDI3, etc.)?
I don't know.

Quote:
Originally Posted by dansrfe View Post
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.

Quote:
Originally Posted by tahaa7 View Post
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 is offline   Reply With Quote
Old 18th October 2015, 13:57   #33703  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
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.
madshi is offline   Reply With Quote
Old 18th October 2015, 14:10   #33704  |  Link
tahaa7
Registered User
 
Join Date: Nov 2012
Posts: 36
Quote:
Originally Posted by madshi View Post
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.
tahaa7 is offline   Reply With Quote
Old 18th October 2015, 14:36   #33705  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
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.
aufkrawall is offline   Reply With Quote
Old 18th October 2015, 14:46   #33706  |  Link
rack04
Registered User
 
Join Date: Mar 2006
Posts: 1,538
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?
rack04 is offline   Reply With Quote
Old 18th October 2015, 15:02   #33707  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by rack04 View Post
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 18th October 2015, 15:10   #33708  |  Link
ashlar42
Registered User
 
Join Date: Jun 2007
Posts: 652
Quote:
Originally Posted by madshi View Post
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 ).
ashlar42 is offline   Reply With Quote
Old 18th October 2015, 15:36   #33709  |  Link
KoD
Registered User
 
Join Date: Mar 2006
Posts: 567
Quote:
Originally Posted by nevcairiel View Post
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)?
KoD is offline   Reply With Quote
Old 18th October 2015, 15:40   #33710  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
Quote:
Originally Posted by tahaa7 View Post
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.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 18th October 2015, 16:09   #33711  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 934
Quote:
Originally Posted by madshi View Post
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.
__________________
TV Setup: LG OLED55B7V; Onkyo TX-NR515; ODroid N2+; CoreElec 9.2.7
DragonQ is offline   Reply With Quote
Old 18th October 2015, 16:18   #33712  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Quote:
Originally Posted by Asmodian View Post
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.
aufkrawall is offline   Reply With Quote
Old 18th October 2015, 17:21   #33713  |  Link
markanini
Registered User
 
Join Date: Apr 2006
Posts: 299
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?
markanini is offline   Reply With Quote
Old 18th October 2015, 17:38   #33714  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 934
Quote:
Originally Posted by markanini View Post
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.
__________________
TV Setup: LG OLED55B7V; Onkyo TX-NR515; ODroid N2+; CoreElec 9.2.7
DragonQ is offline   Reply With Quote
Old 18th October 2015, 18:25   #33715  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by madshi View Post
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:


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...
sneaker_ger is offline   Reply With Quote
Old 18th October 2015, 19:20   #33716  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by tahaa7 View Post
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.

Quote:
Originally Posted by KoD View Post
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.

Quote:
Originally Posted by sneaker_ger View Post
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

Quote:
Originally Posted by rack04 View Post
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.
madshi is offline   Reply With Quote
Old 18th October 2015, 19:24   #33717  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by madshi View Post
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)
sneaker_ger is offline   Reply With Quote
Old 18th October 2015, 19:33   #33718  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by madshi View Post
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 18th October 2015, 19:35   #33719  |  Link
tahaa7
Registered User
 
Join Date: Nov 2012
Posts: 36
Quote:
Originally Posted by madshi View Post
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.
tahaa7 is offline   Reply With Quote
Old 18th October 2015, 20:35   #33720  |  Link
KoD
Registered User
 
Join Date: Mar 2006
Posts: 567
Quote:
Originally Posted by madshi View Post
Quote:
Originally Posted by 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?
KoD is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 15:01.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.