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 24th February 2019, 16:57   #54981  |  Link
tp4tissue
Registered User
 
tp4tissue's Avatar
 
Join Date: May 2013
Posts: 263
Quote:
Originally Posted by huhn View Post
i don't have a test file i don't know and i clearly don't know what madshi things about this or what supposed to happen in this case.

if our don't use an x2 scaling leaving the boarders is just pointless.
Well, I'm sure some people are OK with vertical bars because they're usually small on wide screen movies.

Because if we're to assume NGU already produces the best image, Why would we want Another Scaling layer Lanczos ontop of that JUST to get rid of a 2 pixel vertical bar ?


That is to say, the bestest bacon of the madvr system is NGU, so we're moving all our eggs to optimize performance for this feature. The lanczos cutting 2pixel vertical bar is good, but it's like kale, yea it's healthy, but we showed up at the picnic for bacon. ?
__________________
Ghetto | 2500k 5Ghz

Last edited by tp4tissue; 24th February 2019 at 17:09.
tp4tissue is offline   Reply With Quote
Old 24th February 2019, 18:27   #54982  |  Link
brazen1
Registered User
 
Join Date: Oct 2017
Posts: 208
Quote:
Originally Posted by tp4tissue View Post
No, you still get your money's worth , it will just look slightly more blurry because interframes are blended.

It smooths out judder for people who are very bothered by judder.

I personally don't mind judder, because heck 24fps itself is almost a slideshow, why bother with judder removal.
Judder is the worst motion I can imagine. I had it before modern 120Hz, 144Hz, 240Hz displays. 24fps isn't a slideshow. 60Hz displays are - resulting in pulldown. I tried madVR SM once. It appeared to still have judder just at a faster rate but I might have not optimized everything for it perfectly. I prefer 240Hz with modern interpolation algo. Smooth as butter including slow pans and no visible wrong guesses. Motion handling as good as gets for the time being...
__________________
HOW TO-Kodi 2D-3D-UHD (4k) HDR Guide Internal & External Players
W10v1809 X5690 9604GB RGB 4:4:4 8bit Desktop @60Hz 8,10,12bit @Matched Refresh Rates
KODI MPC-HC/BE PDVD DVDFab
65JS8500 UHD HDR 3D
brazen1 is offline   Reply With Quote
Old 24th February 2019, 19:02   #54983  |  Link
tp4tissue
Registered User
 
tp4tissue's Avatar
 
Join Date: May 2013
Posts: 263
Just tested some more movies. Surprisingly QUITE MANY will cause the blackbar detection to crop 1920 down to 1919 or 1918 which causes the subsequent 2nd phase upscaling to kick in.. After NGU already upscales..

Darn tootn'

NGU (High) -> Lanczos AR

the disable scaling option doesn't work.
__________________
Ghetto | 2500k 5Ghz

Last edited by tp4tissue; 24th February 2019 at 19:20.
tp4tissue is offline   Reply With Quote
Old 25th February 2019, 18:31   #54984  |  Link
Moksu
Registered User
 
Join Date: Oct 2009
Posts: 7
Hey,

Has anyone else experienced problems with MPC-HC crashing when moving it to another screen? (using madvr to playback output)
Moksu is offline   Reply With Quote
Old 25th February 2019, 19:37   #54985  |  Link
el Filou
Registered User
 
el Filou's Avatar
 
Join Date: Oct 2016
Posts: 393
Quote:
Originally Posted by tp4tissue View Post
Just tested some more movies. Surprisingly QUITE MANY will cause the blackbar detection to crop 1920 down to 1919 or 1918
the disable scaling option doesn't work.
Yes, a configurable option like "crop black bars of at least <x> lines" would be useful for 1920-wide sources, ideally with different settings for vertical and horizontal.
I'd even say the setting would be best if it could be specified as a Čage of the picture dimensions instead of number of lines, that way you could just get rid of the "disable scaling if image changes by <x> lines only" (although I doubt UHD sources still have small vertical black bars, but you never know).
__________________
HTPC: W10 1803, E7400, 1050 Ti, DVB-C, Denon 2310, Panasonic GT60 | Desktop: W10 1809, 4690K, HD 7870, Dell U2713HM | MediaPortal 1/MPC-HC, LAV Filters, ReClock, madVR
el Filou is offline   Reply With Quote
Old 25th February 2019, 21:58   #54986  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,362
I think pixel lines would still be best for the option, I would even like it if was the same "disable scaling if image size changes by only" option but applied to post doubling scaling as well. It could also be relative to the screen itself, the number of extra black lines allowed on the display before scaling activates, and do the check at each instance of image scaling (e.g. before lanczos scaling after doubling). Anamorphic is a little more complicated but I would prefer to not check this until after fixing the aspect ratio.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 26th February 2019, 02:37   #54987  |  Link
tp4tissue
Registered User
 
tp4tissue's Avatar
 
Join Date: May 2013
Posts: 263
Quote:
Originally Posted by Asmodian View Post
I think pixel lines would still be best for the option, I would even like it if was the same "disable scaling if image size changes by only" option but applied to post doubling scaling as well. It could also be relative to the screen itself, the number of extra black lines allowed on the display before scaling activates, and do the check at each instance of image scaling (e.g. before lanczos scaling after doubling). Anamorphic is a little more complicated but I would prefer to not check this until after fixing the aspect ratio.
Checking too many times is bad, because it doesn't seem to be a 100% reliable process. It may crop by an extra pixel or 2.

So, I think disabling Vertical check is best, because with horizontal we almost always have room to safely crop, whereas with vertical it could be risky.

I tried another file today, the detection cropped 3840x2160 to 3878, but because it was not doing NGU double, the Ignore scaling function did work in this case.

It's the 1920x1080 crops which cause issues when ngu to 3840.
__________________
Ghetto | 2500k 5Ghz
tp4tissue is offline   Reply With Quote
Old 26th February 2019, 04:06   #54988  |  Link
el Filou
Registered User
 
el Filou's Avatar
 
Join Date: Oct 2016
Posts: 393
It's not "because it was not doing NGU double", it's simply because it didn't have to scale at all as instructed by the setting in question. It compared 3838 or 3828 or whatever (3878 was a typo, right?) to 3840 and sees it's less than the max number of lines under which it can avoid scaling and doesn't scale.
When it compares 1918 after crop to 3840, it concludes "well this image needs to change more than 50 lines after cropping so let's scale"
Using a doubler in your upscaling then just makes the problem worse, but NGU is not the root cause.
__________________
HTPC: W10 1803, E7400, 1050 Ti, DVB-C, Denon 2310, Panasonic GT60 | Desktop: W10 1809, 4690K, HD 7870, Dell U2713HM | MediaPortal 1/MPC-HC, LAV Filters, ReClock, madVR
el Filou is offline   Reply With Quote
Old 26th February 2019, 05:09   #54989  |  Link
tp4tissue
Registered User
 
tp4tissue's Avatar
 
Join Date: May 2013
Posts: 263
Quote:
Originally Posted by el Filou View Post
It's not "because it was not doing NGU double", it's simply because it didn't have to scale at all as instructed by the setting in question. It compared 3838 or 3828 or whatever (3878 was a typo, right?) to 3840 and sees it's less than the max number of lines under which it can avoid scaling and doesn't scale.
When it compares 1918 after crop to 3840, it concludes "well this image needs to change more than 50 lines after cropping so let's scale"
Using a doubler in your upscaling then just makes the problem worse, but NGU is not the root cause.

I'm not actually sure if it's just ngu, i haven't tested that.

But I think it's prolly just coming up short after cropping to 1918 or 1919, after doubling, short of 3840.

But with 3840x2160, I have a file, it'd crop to 3839, detection works here, even though chroma is also NGU.

So I guess it all comes down to whether there is a second round of scaling. the first round is detected properly
__________________
Ghetto | 2500k 5Ghz
tp4tissue is offline   Reply With Quote
Old 26th February 2019, 08:49   #54990  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,026
Anyone compared a Geforce 2060 to a 1080 with madVR?
ryrynz is offline   Reply With Quote
Old 26th February 2019, 11:41   #54991  |  Link
Manni
Registered User
 
Join Date: Jul 2014
Posts: 647
Just to update regarding the 8bits/12bits difference with madTPG on the new JVCs. It looks like you need to enable the BT2020 flag in 12bits to get the native gamut. Problem is, you also need to do this with a rec-709 calibration. In 8bits, this isn't necessary. The gamut is linear whether you enable the BT2020 flag in the calibration tab or not.

So I highly recommend to calibrate in 8bits. In fact, I have resolved my banding issue in 8bits, it was due to the "auto" setting in madVR not detecting that the driver is set to 8bits. I discussed this with madshi and currently, the "auto" setting is based on the display EDID, not the driver settings to 8bits or 12bits. Madshi might fix this at some point. In the meantime, if you set the driver to 8bits, you have to force the bit depth to 8bits in madVR.

With 8bits dithering, there is no visible banding compared to 12bits, even with HDR 10bits content. So given all the issues with 12bits with post-385.28 drivers at least with the JVCs (no custom refresh rate, can't select 12bits, calibration issues, borked video levels), I'm using 8bits now, both for playback and calibration. That way, madVR can generate a custom refresh mode that stick,s I only have to enable it in the nVidia CP as it's disabled by default.

I couldn't use 8bits with the rs500 due to the magenta bug, but it's gone with the rs2000.

Thanks to Huhn for his help resolving this.
__________________
Win10 Pro x64 b1806 MCE
i7 3770K@4.0Ghz 32Gb@2.18Ghz EVGA GTX 1080 Ti SC2 11Gb@2GHz 385.28 RGB Full 8bits
MPC-BE/LAV/MadVR/jRiver/MyMovies V5.24
Denon X8500H>HD Fury Maestro>JVC RS2000

Last edited by Manni; 26th February 2019 at 11:45.
Manni is offline   Reply With Quote
Old 26th February 2019, 13:36   #54992  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,005
Quote:
Originally Posted by ryrynz View Post
Anyone compared a Geforce 2060 to a 1080 with madVR?
The RTX 2060 is about equivalent to a GTX 1070 Ti in performance, so it is still below a GTX 1080.
Warner306 is offline   Reply With Quote
Old 26th February 2019, 14:51   #54993  |  Link
el Filou
Registered User
 
el Filou's Avatar
 
Join Date: Oct 2016
Posts: 393
Quote:
Originally Posted by tp4tissue View Post
But I think it's prolly just coming up short after cropping to 1918 or 1919, after doubling, short of 3840.
Exactly, and this is the issue: the condition is only evaluated after cropping and before upscaling, but not after individual scaling steps.
Quote:
Originally Posted by tp4tissue View Post
But with 3840x2160, I have a file, it'd crop to 3839, detection works here, even though chroma is also NGU.
So I guess it all comes down to whether there is a second round of scaling. the first round is detected properly
I'll say it another way: it has nothing to do with how many rounds of scaling there is or if NGU is enabled somewhere, but with the difference in definition between the cropped image and the final definition the image needs to be displayed in.
Let's say your screen is 3840-wide, you set the setting to "disable scaling if image size changes by only 2 lines or less" and you have 2 black lines to crop in each of those two examples:
- 1920-wide source on 3840-wide display ==> madVR evaluates "my source is now 1918-wide, that's more than 2 lines difference with 3840, so I'll scale", then NGU gets you to 3836 and then has to use another scaler to get to 3840. The condition is only evaluated once before any scaling, so it doesn't even check after using NGU that it's now at less than 2 lines from the display def. In effect, it behaves as if it was playing back a native 1918-wide source!
- 3840-wide source on 3840-wide display ==> "my source is now 3838, that's 2 lines or less difference from 3840, I won't scale."
The setting is evaluated after cropping and before any upscaling operation, and only once. It has nothing to do with how many rounds of scaling are needed, or if NGU is enabled for chroma, or anything else.
Which is why it would be nice if madshi could change the behaviour of this setting to be checked after any scaling step, as Asmodian suggested. You could set it to 5 lines or less and it would handle 5 lines on a 3840 source or 2 lines on a 1920 source.
1920-wide sources is probably the only case where you'll encounter this specific issue as 960x540 video isn't a standard consumer def, but you could in theory also encounter it if you played that source def on a 1920x1080 screen, and also on 640x360 video with a 1280x720 screen.
__________________
HTPC: W10 1803, E7400, 1050 Ti, DVB-C, Denon 2310, Panasonic GT60 | Desktop: W10 1809, 4690K, HD 7870, Dell U2713HM | MediaPortal 1/MPC-HC, LAV Filters, ReClock, madVR

Last edited by el Filou; 26th February 2019 at 15:17. Reason: bad idea
el Filou is offline   Reply With Quote
Old 26th February 2019, 14:57   #54994  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,359
just use mpc-hc video frame double size for now.

Quote:
EDIT: or better, madVR should avoid cropping black bars in the source definition if their size is less than the configured setting for this option, that way it wouldn't need to do checks after each scaling step.
1920-wide sources is probably the only case where you'll encounter this specific issue as 960x540 video isn't a standard consumer def, but you could in theory also encounter it if you played that source def on a 1920x1080 screen, and also on 640x360 video with a 1280x720 screen.
black bar detection is also run on the CPU so it's not that easy.
huhn is offline   Reply With Quote
Old 26th February 2019, 15:15   #54995  |  Link
el Filou
Registered User
 
el Filou's Avatar
 
Join Date: Oct 2016
Posts: 393
Yes, thought about that afterwards.
I think re-evaluating that zoom control setting after each scaling step would be best and also not that hard to implement, IMHO.
__________________
HTPC: W10 1803, E7400, 1050 Ti, DVB-C, Denon 2310, Panasonic GT60 | Desktop: W10 1809, 4690K, HD 7870, Dell U2713HM | MediaPortal 1/MPC-HC, LAV Filters, ReClock, madVR
el Filou is offline   Reply With Quote
Old 26th February 2019, 17:13   #54996  |  Link
tp4tissue
Registered User
 
tp4tissue's Avatar
 
Join Date: May 2013
Posts: 263
Quote:
Originally Posted by el Filou View Post
Yes, thought about that afterwards.
I think re-evaluating that zoom control setting after each scaling step would be best and also not that hard to implement, IMHO.
Or u know, disable vertical bar cropping, solves 90% of the cases of this issue, not perfect, but i mean, it's a good sweep
__________________
Ghetto | 2500k 5Ghz
tp4tissue is offline   Reply With Quote
Old 26th February 2019, 19:33   #54997  |  Link
el Filou
Registered User
 
el Filou's Avatar
 
Join Date: Oct 2016
Posts: 393
sometimes there is 4:3 or 14:9 hardcoded in 16:9 source
__________________
HTPC: W10 1803, E7400, 1050 Ti, DVB-C, Denon 2310, Panasonic GT60 | Desktop: W10 1809, 4690K, HD 7870, Dell U2713HM | MediaPortal 1/MPC-HC, LAV Filters, ReClock, madVR
el Filou is offline   Reply With Quote
Old 27th February 2019, 01:38   #54998  |  Link
tp4tissue
Registered User
 
tp4tissue's Avatar
 
Join Date: May 2013
Posts: 263
Quote:
Originally Posted by el Filou View Post
sometimes there is 4:3 or 14:9 hardcoded in 16:9 source
I'm not saying a better solution isn't possible.

Only that as a quick and dirty fix that would resolve most of the issue is also very straight forward by disabling vertical bar detection

Moving ahead, we're mostly dealing with widescreen.
__________________
Ghetto | 2500k 5Ghz
tp4tissue is offline   Reply With Quote
Old 27th February 2019, 08:38   #54999  |  Link
FlashGordon
Registered User
 
Join Date: Oct 2010
Posts: 42
Possible bug:

in madVR 0.92.17

In keyboard shortcuts, if I set a key for 'chroma upscaling algorithm - Bicubic' the keybinding will do nothing. If I set keys specifically for the other chroma upscalers such as Lanczos, Spline, and Jinc they will work. This might have to do with the different options Bicubic gives you (75,100,150, etc.). If I set a key for 'chroma upscaling - toggle' it does select the last Bicubic I used once I toggle over to it.
FlashGordon is offline   Reply With Quote
Old 27th February 2019, 09:18   #55000  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,026
Pop it up on bugs.madshi.net
ryrynz 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 17:48.


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