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, 01:03   #33701  |  Link
ashlar42
Registered User
 
Join Date: Jun 2007
Posts: 427
I was asking because I don't fully understand what were the reasons that led to the previous 3 versions being deemed not ideal, in case those solved this problem.

If the problem was with people wanting to move subs up and down, I simply state that it seems less likely than people wanting to choose one subs size and forget about it.

The way it is now, they're either too small on 2.35 material or too large on 1.78 material (covering more picture than necessary, by the way, considering the length we go to get that same picture at its best possible quality...).

If it's not solvable... I'll go back hoping somebody will start to take more care of XySubsFilter in the future. I get it that madshi is already going above and beyond what one could reasonably expect.

Actually, thanks again madshi for trying.
ashlar42 is offline   Reply With Quote
Old 18th October 2015, 03:27   #33702  |  Link
nijiko
Hi-Fi Fans
 
Join Date: Dec 2008
Posts: 222
How about the mem leak? Was it pointed and fixed?
nijiko is offline   Reply With Quote
Old 18th October 2015, 04:02   #33703  |  Link
seiyafan
Registered User
 
Join Date: Feb 2014
Posts: 161
Does SystemCompute fairly accurately reflect MadVR's overall performance (ED, NNEDI3, etc.)?
seiyafan is offline   Reply With Quote
Old 18th October 2015, 08:24   #33704  |  Link
dansrfe
Registered User
 
Join Date: Jan 2009
Posts: 1,212
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.
dansrfe is offline   Reply With Quote
Old 18th October 2015, 11:51   #33705  |  Link
tahaa7
Registered User
 
Join Date: Nov 2012
Posts: 36
Quote:
Originally Posted by madshi View Post
Native DXVA saves the copyback, so it lowers CPU usage. However, DXVA decodes to a format that it hard to work with for madVR. This results in a certain loss in chroma quality. In most situations you probably won't see the difference, but it's there.
OK, but aren't decoded frames the same with both native and copyback? The only difference is where they are located after decoding (GPU memory vs main memory). So madvr receives the same decoded frame, whether from GPU memory or main memory, no?

So, when you say "DXVA decodes to a format that it hard to work with for madVR", that would mean that it's a general DXVA issue, not a native vs copyback issue.

Last edited by tahaa7; 18th October 2015 at 11:54.
tahaa7 is offline   Reply With Quote
Old 18th October 2015, 11:52   #33706  |  Link
Knight77
Registered User
 
Join Date: Feb 2012
Posts: 54
Quote:
Originally Posted by Warner306 View Post
Image Enhancements will do the same thing as Upscaling Refinement when applied to an image already resized. It sharpens the luma to add detail to the image. Upscaling Refinement does the same but waits for resizing to take place. So, both could be considered post-resize sharpening.
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.
Knight77 is offline   Reply With Quote
Old 18th October 2015, 11:58   #33707  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 6,224
Quote:
Originally Posted by tahaa7 View Post
OK, but aren't decoded frames the same with both native and copyback? The only difference is where they are located after decoding (GPU memory vs main memory). So madvr receives the same decoded frame, whether from GPU memory or main memory, no?

So, when you say "DXVA decodes to a format that it hard to work with for madVR", that would mean that it's a general DXVA issue, not a native vs copyback issue.
that's an issue with nvidia and madVR.

DXVA copy back is not effected and AMD/INTEL DXVA native is not known for this issue.
huhn is offline   Reply With Quote
Old 18th October 2015, 12:35   #33708  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,899
Quote:
Originally Posted by tahaa7 View Post
OK, but aren't decoded frames the same with both native and copyback? The only difference is where they are located after decoding (GPU memory vs main memory). So madvr receives the same decoded frame, whether from GPU memory or main memory, no?
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 18th October 2015 at 12:41.
nevcairiel is offline   Reply With Quote
Old 18th October 2015, 14:15   #33709  |  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 14:25.
tahaa7 is offline   Reply With Quote
Old 18th October 2015, 14:33   #33710  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
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, 14:57   #33711  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
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, 15:10   #33712  |  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, 15:36   #33713  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,734
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, 15:46   #33714  |  Link
rack04
Registered User
 
Join Date: Mar 2006
Posts: 1,528
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, 16:02   #33715  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,899
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, 16:10   #33716  |  Link
ashlar42
Registered User
 
Join Date: Jun 2007
Posts: 427
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, 16:36   #33717  |  Link
KoD
Registered User
 
Join Date: Mar 2006
Posts: 552
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, 16:40   #33718  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,796
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, 17:09   #33719  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 930
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.
__________________
HTPC Hardware: Intel Celeron G530; nVidia GT 430
HTPC Software: Windows 7; MediaPortal 1.19.0; Kodi DSPlayer 17.6; LAV Filters (DXVA2); MadVR
TV Setup: LG OLED55B7V; Onkyo TX-NR515; Minix U9-H
DragonQ is offline   Reply With Quote
Old 18th October 2015, 17:18   #33720  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,734
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
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 13:12.


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