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 2nd June 2015, 14:38   #30681  |  Link
Aleksoid1978
Registered User
 
Aleksoid1978's Avatar
 
Join Date: Apr 2008
Location: Russia, Vladivostok
Posts: 2,262
Hi madshi.
I have question for you. How you(what API function use) change resolution/refresh rate ?? In MPC-BE/MPC-HC use ChangeDisplaySettingsEx(). But - after buy new GTX 960 i have some trouble with 24fps mode - after use ChangeDisplaySettingsEx() my TV info that use 24p, but in MPC-BE EVR Custom i see that fps ~23.976(and it's true). If i try use madVR with auto-refresh - i give "true" 24p mode. You do not know what could be wrong ??
__________________
I7 2600K@4.2 /Asrock P67 Extreme4 Gen 3 /Kingston HyperX 8Gb 1866 (4x2) Kit /OCZ Vertex 3 256Gb /Gigabyte GTX 960 /BenQ EW2430 /LG 47LM620T /Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215
Aleksoid1978 is offline   Reply With Quote
Old 2nd June 2015, 14:59   #30682  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,834
Quote:
Originally Posted by Aleksoid1978 View Post
Hi madshi.
I have question for you. How you(what API function use) change resolution/refresh rate ?? In MPC-BE/MPC-HC use ChangeDisplaySettingsEx(). But - after buy new GTX 960 i have some trouble with 24fps mode - after use ChangeDisplaySettingsEx() my TV info that use 24p, but in MPC-BE EVR Custom i see that fps ~23.976(and it's true). If i try use madVR with auto-refresh - i give "true" 24p mode. You do not know what could be wrong ??
Its the same API, but you have to cheat it.
Call ChangeDisplaySettingsEx with the new mode and CDS_UPDATEREGISTRY | CDS_NORESET once, and then a second time without a new mode and without the flags (it'll use the new mode you set in the previous call then)
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 2nd June 2015, 15:11   #30683  |  Link
Aleksoid1978
Registered User
 
Aleksoid1978's Avatar
 
Join Date: Apr 2008
Location: Russia, Vladivostok
Posts: 2,262
Quote:
Originally Posted by nevcairiel View Post
Its the same API, but you have to cheat it.
Call ChangeDisplaySettingsEx with the new mode and CDS_UPDATEREGISTRY | CDS_NORESET once, and then a second time without a new mode and without the flags (it'll use the new mode you set in the previous call then)
It's not necessary. Even call ChangeDisplaySettingsEx() only with CDS_UPDATEREGISTRY or CDS_FULLSCREEN or 0 - it's work. But something wrong with new mode - TV info that 24p, but in fact - 23.976. All other mode working as it should.
__________________
I7 2600K@4.2 /Asrock P67 Extreme4 Gen 3 /Kingston HyperX 8Gb 1866 (4x2) Kit /OCZ Vertex 3 256Gb /Gigabyte GTX 960 /BenQ EW2430 /LG 47LM620T /Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215
Aleksoid1978 is offline   Reply With Quote
Old 2nd June 2015, 16:21   #30684  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by Shiandow View Post
Jensen's inequality doesn't really care about which one is "correct" or "linear". It just uses the fact that the function used to go from gamma light to linear light is convex. If you go the other way around then the function you use is concave, so the inequality will be the other way around. You can really only use it to show that the values will (always) be higher when you use linear light, you can't use it to show whether this is better or not.
Ah, I see. The basic question that was discussed earlier in this thread was whether linear or gamma light was "correct". I had thought that you had tried to answer that question. Now I see that your reply didn't mean to judge about which is right (or even better).

Quote:
Originally Posted by Aleksoid1978 View Post
It's not necessary. Even call ChangeDisplaySettingsEx() only with CDS_UPDATEREGISTRY or CDS_FULLSCREEN or 0 - it's work. But something wrong with new mode - TV info that 24p, but in fact - 23.976. All other mode working as it should.
nevcairiel has it right. If you use ChangeDisplaySettingsEx() the normal way, it will switch to 23.976, even if you specify 24.000. You have to call ChangeDisplaySettingsEx() twice, in a very specific way (see nevcairiel's post), to get true 24.000.
madshi is offline   Reply With Quote
Old 2nd June 2015, 17:18   #30685  |  Link
Vegeak
Registered User
 
Join Date: May 2015
Posts: 2
Since the last 2 versions (0.88.9/0.88.10) if I set debanding as high it drops a lot of frames, I'm using 0.88.8 and it plays fine, my graphic card isn't good at all (GT 610), but I can play 720p files fine. This seems to happen since high debanding was modified, can I get a version with all the new changes but without this change specifically?
Vegeak is offline   Reply With Quote
Old 2nd June 2015, 17:21   #30686  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,494
New versions enabled gradient analyzing for "high" debanding. Go "rendering"->"trade quality for performance" and tick "don't analyze gradient angles for debanding". Then test again. (I don't know if it really needs much performance. Maybe it's just a coincidence and real problem is something else?)

That said, debanding might change again in the very near future according to the user reports here so this might only be a temporary option.

Last edited by sneaker_ger; 2nd June 2015 at 17:24.
sneaker_ger is offline   Reply With Quote
Old 2nd June 2015, 19:01   #30687  |  Link
Vegeak
Registered User
 
Join Date: May 2015
Posts: 2
Thank you! This fixed my problem.
Vegeak is offline   Reply With Quote
Old 2nd June 2015, 19:20   #30688  |  Link
XMonarchY
Registered User
 
Join Date: Jan 2014
Posts: 489
Whoever advised that using the High Speed HDMI cable would allow me to get 12bit not only @ 23Hz, but also at 60Hz was dead on right! I just got one of these cables and I can select 60Hz + 12bit in nVidia CP with no artifacts! I hope games will look better now!


BTW, is it a placebo effect that my games (Withcer 3) look better in 12bit mode than in 8bit mode? I know transitions are better, especially since I use a 1D LUT, but colors also seem richer! I tested my calibration done in 8bit with 12bit mode and there was no difference anywhere, and yet 12bit seems to produce richer colors...
__________________
8700K @ 5Ghz | ASUS Z370 Hero X | Corsair 16GB @ 3200Mhz | RTX 2080 Ti @ 2100Mhz | Samsung 970 NVMe 250GB | WD Black 2TB | Corsair AX 850W | LG 32GK850G-B @ 165Hz | Xonar DGX | Windows 10 LTSC 1809

Last edited by XMonarchY; 2nd June 2015 at 20:23.
XMonarchY is offline   Reply With Quote
Old 2nd June 2015, 20:29   #30689  |  Link
XMonarchY
Registered User
 
Join Date: Jan 2014
Posts: 489
Also, I noticed an odd problem. I am getting an occasional stutter during my SMPTE 170M content playback that I have not had before... I can't seem to narrow down which setting causes it. There are no frame drops or glitches or delayed frames for 25-30 minutes and suddenly there is this stutter where the screen shakes for a second and then all is fine for the next 30 minutes. GPU is fine, all is stable. I did update MPC-HC to the latest nightly build, do you think that may be reason?
__________________
8700K @ 5Ghz | ASUS Z370 Hero X | Corsair 16GB @ 3200Mhz | RTX 2080 Ti @ 2100Mhz | Samsung 970 NVMe 250GB | WD Black 2TB | Corsair AX 850W | LG 32GK850G-B @ 165Hz | Xonar DGX | Windows 10 LTSC 1809
XMonarchY is offline   Reply With Quote
Old 2nd June 2015, 22:29   #30690  |  Link
Sunset1982
Registered User
 
Join Date: Sep 2014
Posts: 277
Quote:
Originally Posted by XMonarchY View Post
Also, I noticed an odd problem. I am getting an occasional stutter during my SMPTE 170M content playback that I have not had before... I can't seem to narrow down which setting causes it. There are no frame drops or glitches or delayed frames for 25-30 minutes and suddenly there is this stutter where the screen shakes for a second and then all is fine for the next 30 minutes. GPU is fine, all is stable. I did update MPC-HC to the latest nightly build, do you think that may be reason?
Had this too yesterday...
Sunset1982 is offline   Reply With Quote
Old 2nd June 2015, 23:13   #30691  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,965
here is my opinion on debanding.
i used a BD with a on of banding encoded with VC-1 with about 14 mbit combined with bad mastering.

untouched: http://abload.de/img/untouchednwsn8.png
madVR high: http://abload.de/img/madvrhighqesn8.png
shiandow 1.0 0.0: http://abload.de/img/madvrnew1.00.036sp3.png
shiandow 1.0 1.0: http://abload.de/img/madvrnew1.01.0wds61.png

madVR high is stronger in debanding than shiandow 1.0 with margin 0.0 but a little bit more harmful too.
margin 1.0 has a very bad effect on moving scene this effect is still visible with 0.0 margin but not visible with madVR high.

so i give madVR high a clear edge in moving scenes.

here a screen with the problem i call it clouding on the blue car it is way worse in moving.

untouched: http://abload.de/img/untouched2xpuk6.png
shiandow 1.0 1.0: http://abload.de/img/clouding61ucd.png
shiandow 1.0 0.2: http://abload.de/img/clouding1.00.274ukn.png
shiandow 1.0 0.0: http://abload.de/img/clouding1.00.0neuas.png
madVR high: http://abload.de/img/cloudingmadvr5nux5.png

a deblock filter before debanding may help shiandow's algorithm a lot.
huhn is online now   Reply With Quote
Old 2nd June 2015, 23:25   #30692  |  Link
cyberscott
Registered User
 
Join Date: Oct 2007
Posts: 81
Quote:
Originally Posted by madshi View Post
Ok, thanks. One more try, if you don't mind:

http://madshi.net/madVR8810test5.rar

Please activate debug mode first (by double clicking "activate debug mode.bat"), then afterwards drop in the new madVR.ax. If you do it the other way round, but you're replacing the "wrong" madVR.ax file and you're testing with the official v0.88.10 again. I know, it's a bit confusing. Basically, after you dropped the replacement madVR.ax file into the madVR folder, don't double click any batch files, until you've completed testing. Thanks!
Ok, still change in the queues in this test. Hopefully I got the log correctly generated. Here it is...:
http://s000.tinyupload.com/?file_id=...04695651332179
cyberscott is offline   Reply With Quote
Old 2nd June 2015, 23:49   #30693  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by XMonarchY View Post
Also, I noticed an odd problem. I am getting an occasional stutter during my SMPTE 170M content playback that I have not had before... I can't seem to narrow down which setting causes it. There are no frame drops or glitches or delayed frames for 25-30 minutes and suddenly there is this stutter where the screen shakes for a second and then all is fine for the next 30 minutes. GPU is fine, all is stable. I did update MPC-HC to the latest nightly build, do you think that may be reason?
I've no idea. When this stutter occurs, do you have frame drops or glitches or delayed frames then?

Quote:
Originally Posted by huhn View Post
here is my opinion on debanding.
i used a BD with a on of banding encoded with VC-1 with about 14 mbit combined with bad mastering.

untouched: http://abload.de/img/untouchednwsn8.png
madVR high: http://abload.de/img/madvrhighqesn8.png
shiandow 1.0 0.0: http://abload.de/img/madvrnew1.00.036sp3.png
shiandow 1.0 1.0: http://abload.de/img/madvrnew1.01.0wds61.png

madVR high is stronger in debanding than shiandow 1.0 with margin 0.0 but a little bit more harmful too.
margin 1.0 has a very bad effect on moving scene this effect is still visible with 0.0 margin but not visible with madVR high.

so i give madVR high a clear edge in moving scenes.

here a screen with the problem i call it clouding on the blue car it is way worse in moving.

untouched: http://abload.de/img/untouched2xpuk6.png
shiandow 1.0 1.0: http://abload.de/img/clouding61ucd.png
shiandow 1.0 0.2: http://abload.de/img/clouding1.00.274ukn.png
shiandow 1.0 0.0: http://abload.de/img/clouding1.00.0neuas.png
madVR high: http://abload.de/img/cloudingmadvr5nux5.png

a deblock filter before debanding may help shiandow's algorithm a lot.
Good feedback - thank you!

Quote:
Originally Posted by cyberscott View Post
Ok, still change in the queues in this test. Hopefully I got the log correctly generated. Here it is...:
http://s000.tinyupload.com/?file_id=...04695651332179
Ok, I've finally found what causes the queues to not fill:

When madVR tries to copy the rendered frame to the backbuffer, exactly one out of four times it takes ca. 150-200ms. Every other time it takes 0ms (meaning no measurable time).

I've no idea why copying to the backbuffer sometimes is so slow and sometimes so fast, and why it seems to have a certain rhythm. It could either be a bug in the GPU drivers, or it could be a misconfiguration of some sort. You already tried lowering the number of pre-presented frames without success, right? And you already double checked the NVidia GPU control panel to make sure that the number of pre-rendered frames is set to application control, correct? Have you changed the madVR flush settings at some point? Have you tried restoring the madVR default settings at some point, just in case? Are you running some background process which might access the GPU (e.g. GPU-Z, or similar)? Try closing all processes which are not strictly needed, including the browser.

There's one more thing: In the original log I could see that madVR had to reset the VSync Direct3D device sometimes, because Direct3D reported it was "occluded". Which suggests that maybe some window might have covered the media player, at least for a short time. Does that make any sense to you? The test build you've tested with now doesn't reset the VSync device, anymore. I had hoped this would make a difference, but seemingly it doesn't.
madshi is offline   Reply With Quote
Old 3rd June 2015, 02:05   #30694  |  Link
Aleksoid1978
Registered User
 
Aleksoid1978's Avatar
 
Join Date: Apr 2008
Location: Russia, Vladivostok
Posts: 2,262
Quote:
Originally Posted by madshi View Post
nevcairiel has it right. If you use ChangeDisplaySettingsEx() the normal way, it will switch to 23.976, even if you specify 24.000. You have to call ChangeDisplaySettingsEx() twice, in a very specific way (see nevcairiel's post), to get true 24.000.
Thanks - i try
__________________
I7 2600K@4.2 /Asrock P67 Extreme4 Gen 3 /Kingston HyperX 8Gb 1866 (4x2) Kit /OCZ Vertex 3 256Gb /Gigabyte GTX 960 /BenQ EW2430 /LG 47LM620T /Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215
Aleksoid1978 is offline   Reply With Quote
Old 3rd June 2015, 02:33   #30695  |  Link
cyberscott
Registered User
 
Join Date: Oct 2007
Posts: 81
Quote:
Originally Posted by madshi View Post

Ok, I've finally found what causes the queues to not fill:

When madVR tries to copy the rendered frame to the backbuffer, exactly one out of four times it takes ca. 150-200ms. Every other time it takes 0ms (meaning no measurable time).

I've no idea why copying to the backbuffer sometimes is so slow and sometimes so fast, and why it seems to have a certain rhythm. It could either be a bug in the GPU drivers, or it could be a misconfiguration of some sort. You already tried lowering the number of pre-presented frames without success, right? And you already double checked the NVidia GPU control panel to make sure that the number of pre-rendered frames is set to application control, correct? Have you changed the madVR flush settings at some point? Have you tried restoring the madVR default settings at some point, just in case? Are you running some background process which might access the GPU (e.g. GPU-Z, or similar)? Try closing all processes which are not strictly needed, including the browser.

There's one more thing: In the original log I could see that madVR had to reset the VSync Direct3D device sometimes, because Direct3D reported it was "occluded". Which suggests that maybe some window might have covered the media player, at least for a short time. Does that make any sense to you? The test build you've tested with now doesn't reset the VSync device, anymore. I had hoped this would make a difference, but seemingly it doesn't.
Glad you were able to isolate the cause, that is a good thing. As far as .88.10, I always started testing at madVR's default settings, only changing the up-scaling to bilinear.
All the flush settings are at default, I never had need to touch them, and If I had, it would be corrected when I reset to default settings.

nVidia's control panel is set globally for "application control" for frames. I had hoped nVidia's new 353.06 drivers might have an effect but it appears to have made no difference.

I don't have gpu-z running nor any type of gpu overclocking/monitoring software running. I have tried closing processes to bare minimum with no changes.

I messed around a little more with the new .ax tonight
One thing I noticed that on the untouched, original .88.10 .ax, changing the exclusive mode present frames in advance didn't change the behavior of the queue, it would stay at 1-4/X until I set it below that. Even then, it would stay 1-4, 1-3, 1-2, etc. The latest madVRtest5.ax, the presented frames will completely fill if set to 4. (4-4/4).

With some more queue adjustments, I currently have all the queues filling up, using .88.10 and MadVRtest5.ax

Decoder queue: 14-15/15
Upload queue: 8-9/9
Render queue: 8-9/9
Present queue: 4/4-4 (lower than I like but the highest setting that works)


Also, remember me mentioning that the Decoder queue (in exclusive mode) would always show one more than it should, such as 14-16/15? When I set the exclusive mode to 4 frames or below, it will show correctly, 14-15/15. Not sure if that has anything to do with this issue, though.

The "occluded" D3D you saw was most like me tinkering with things at one point with the log running and I unintentionally sent you a log with my messing around. Sorry about that.

I always can use .88.8 if I want use 10 bit output with higher " presented frames in advance" settings in 10 bit DSD11 mode but of course I couldn't play with the added /changed features in .88.10.

I do appreciate you taking extra time troubleshooting this issue with me even though I'm the only one to have reported it up to now.

Here is the log for the full queues if you want to take a look.
http://s000.tinyupload.com/?file_id=...78447616236926

Last edited by cyberscott; 3rd June 2015 at 02:47. Reason: added link
cyberscott is offline   Reply With Quote
Old 3rd June 2015, 04:49   #30696  |  Link
Della
Registered User
 
Join Date: Dec 2011
Posts: 32
I replied earlier, I too have seen the unfilled queues when using 10 bit exclusive. You're not alone & thanks much for all your investigative work.
Della is offline   Reply With Quote
Old 3rd June 2015, 05:15   #30697  |  Link
har3inger
Registered User
 
Join Date: Feb 2014
Posts: 139
The newest MPC-HC official release for June 1st causes my render and present queues to bounce around zero despite having render times of around 28-30ms for 24p content. Dropped frame count is surprisingly fine, with only a couple frames per minute, but clearly something isn't working as it was before.

Anyone have a link to a copy of 1.7.6.156 I could revert to? That was the tweaked 64 bit build to support 64 bit madvr. The old one on dropbox from weeks/months back is dead.

Hmm, with further testing to isolate the problem, it went away without me doing anything. Go figure.

Last edited by har3inger; 3rd June 2015 at 05:25.
har3inger is offline   Reply With Quote
Old 3rd June 2015, 07:01   #30698  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
Hey I have a very simple suggestion that would make the usage much simpler.

Why are downscaling algorithms like Catmul in the upscaling pages, and why are upscaling algorithms like Lanczos in the downscaling page?

You could remove downscaling algorithms from the upscaling page and upscaling algorithms from the downscaling page. That would make the interface simpler and make it easier for new users.

Also, someone mentioned that Scale in Linear Light shouldn't be used when downscaling except for Catmul when also using Anti-Ringing. If it's a bad choice for others, it could be removed for other algotirhts.

Last edited by MysteryX; 24th June 2015 at 07:07.
MysteryX is offline   Reply With Quote
Old 3rd June 2015, 08:21   #30699  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,228
Quote:
Originally Posted by MysteryX View Post
Why are downscaling algorithms like Catmul in the upscaling pages, and why are upscaling algorithms like Lanczos in the downscaling page?

You could remove downscaling algorithms from the upscaling page and upscaling algorithms from the downscaling page. That would make the interface simpler and make it easier for new users.

Also, someone mentioned that Scale in Linear Light shouldn't be used when downscaling except for Catmul when also using Anti-Ringing. If it's a bad choice for others, it could be removed for other algotirhts.
They're algorithms for upscaling and downscaling, nothing needs to be removed. There are common preferences for upscaling and downscaling and sometimes different from each other, that's fine.

With regards to scaling in linear light it's a case of only enabling it if you you need it. Some options may move to advanced section but I suspect this rejigging if it occurs will happen closer to 1.0.
ryrynz is offline   Reply With Quote
Old 3rd June 2015, 09:13   #30700  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by cyberscott View Post
Glad you were able to isolate the cause, that is a good thing. As far as .88.10, I always started testing at madVR's default settings, only changing the up-scaling to bilinear.
All the flush settings are at default, I never had need to touch them, and If I had, it would be corrected when I reset to default settings.

nVidia's control panel is set globally for "application control" for frames. I had hoped nVidia's new 353.06 drivers might have an effect but it appears to have made no difference.

I don't have gpu-z running nor any type of gpu overclocking/monitoring software running. I have tried closing processes to bare minimum with no changes.

I messed around a little more with the new .ax tonight
One thing I noticed that on the untouched, original .88.10 .ax, changing the exclusive mode present frames in advance didn't change the behavior of the queue, it would stay at 1-4/X until I set it below that. Even then, it would stay 1-4, 1-3, 1-2, etc. The latest madVRtest5.ax, the presented frames will completely fill if set to 4. (4-4/4).

With some more queue adjustments, I currently have all the queues filling up, using .88.10 and MadVRtest5.ax

Decoder queue: 14-15/15
Upload queue: 8-9/9
Render queue: 8-9/9
Present queue: 4/4-4 (lower than I like but the highest setting that works)


Also, remember me mentioning that the Decoder queue (in exclusive mode) would always show one more than it should, such as 14-16/15? When I set the exclusive mode to 4 frames or below, it will show correctly, 14-15/15. Not sure if that has anything to do with this issue, though.

The "occluded" D3D you saw was most like me tinkering with things at one point with the log running and I unintentionally sent you a log with my messing around. Sorry about that.

I always can use .88.8 if I want use 10 bit output with higher " presented frames in advance" settings in 10 bit DSD11 mode but of course I couldn't play with the added /changed features in .88.10.

I do appreciate you taking extra time troubleshooting this issue with me even though I'm the only one to have reported it up to now.

Here is the log for the full queues if you want to take a look.
http://s000.tinyupload.com/?file_id=...78447616236926
The VSync reset stuff might have had a part in this, as well. Here's a new test build:

http://madshi.net/madVR8810test6.rar

This time it's a release mode build. So please double click "activate release mode.bat" first, then replace the madVR.ax file. Then please just double check if this test build still fills the queues with your current settings (4 frames pre-presented). If it does, as is well. If it doesn't, the VSync reset stuff is still a problem. I don't need a log this time. Just the information whether this build still fills the queues for you, or not. Thanks.
madshi 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 10:31.


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