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 4th December 2013, 19:31   #21041  |  Link
cvrkuth
Registered User
 
Join Date: Apr 2011
Posts: 54
I update my OS (Windows 8.1 Pro), I have same problem again.
I noticed that when playing 1080p24 (mkv, m2ts, ts .. full screen exclusive mode, default settings) my screen goes to 23hz. Because of this, there is a drop frames every 30-40 sec.

If I uncheck 'Present Several frames in advance "(old path), my screen stays in 24hz.

Quote:
Originally Posted by madshi View Post
Your log file indicates that the display mode is reported as 1080p24 when madVR starts rendering. And madVR knows that 24Hz is what you need, so it doesn't touch the display mode. Then madVR goes into fullscreen exclusive mode, telling Direct3D9 to use 24Hz. It seems that in your case Direct3D9 ignores madVR's wish and switches to 23.976Hz instead. That would be a bug in Windows/Direct3D9. I've already implemented some hacks to fix this problem with Intel GPUs, but it's possible that this fix doesn't work with AMD/NVidia GPUs, I'm not sure. Feel free to add a bug report to the madVR bug tracker about this problem, if there isn't one already. Maybe if I find some time I'll see if I can workaround the problem with AMD/NVidia GPUs, too. It's not a madVR bug, though, but a bug in Windows or Direct3D9 or in the GPU drivers. madVR clearly requests 24.000Hz, according to the log.

I found this... In my display settings, I have checked 'Let me choose one scaling level for all my displays'.. I uncheck this and trouble is gone!

Regards!
__________________
Intel Core i7-4790 CPU @ 3.60GHz, RAM 32 GB Dual-Channel DDR3 @ 665MHz (9-9-9-24),
Panasonic TX-P42G20E, NVIDIA GeForce GTX 970, Win 10 Pro x64,
PotPlayer 1.7.16291 64-bit, madVR v0.92.17

Last edited by cvrkuth; 4th December 2013 at 19:34.
cvrkuth is offline   Reply With Quote
Old 5th December 2013, 00:35   #21042  |  Link
Niyawa
Registered User
 
Niyawa's Avatar
 
Join Date: Dec 2012
Location: Neverland, Brazil
Posts: 169
Quote:
Originally Posted by madshi View Post
Yes, sorry, forgot to add that to the interface.
We appreciate it.

Quote:
Originally Posted by madshi View Post
If it works with your specific OS/GPU/driver setup then it's usually beneficial to enable it. At least it rarely harms. There have been some reports about problems with this option, though. E.g. some AMD/NVidia laptop users with a shared AMD/NVidia <-> Intel GPU had problems. Also the latest Intel drivers don't play nice with this option. These are all GPU driver problems, though, and not madVR's fault.
Hm, so it's more or less as I thought. Thanks for the help.

Quote:
Originally Posted by madshi View Post
I've heard about this only if there's a display mode change and the display needs 5 seconds to resync.
Strange. When I change my display mode it takes about 1-2 seconds most, I guess this goes from display to display.

Oh yeah, there's one more thing I'd like everyone to give their thoughts about. This user has been having issues with madVR output to TV with HDMI. We're not particularly sure what is causing that so any input here would be welcome.
__________________
madVR scaling algorithms chart - based on performance x quality | KCP - A (cute) quality-oriented codec pack
Niyawa is offline   Reply With Quote
Old 5th December 2013, 02:26   #21043  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Never mind have to look into this one..
ryrynz is offline   Reply With Quote
Old 5th December 2013, 20:52   #21044  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by madshi View Post
The disabling of dithering for pixels which don't need it is has 3 potential benefits:

(1) With full black or white video areas, dithering ever so slightly increased the black level and decreased peak white brightness. This also meant that some displays didn't "recognize" full black video areas, due to dithering, and thus they didn't turn off the local dimming LEDs etc. With the new test build, hopefully this problem should be solved.
Thank you for the fix. If calibration is disabled, or I tell madVR that my display is calibrated to BT.709, things work as expected. But if I enable yCMS calibration (lowest value is a 5% measurement) I'm still seeing an elevated black level.
6233638 is offline   Reply With Quote
Old 6th December 2013, 03:53   #21045  |  Link
Megalith
Registered User
 
Join Date: Mar 2011
Posts: 131
Quick question. The decoding options (decode MPEG2/VC-1/h264) under the "processing" tree only need to be checked if you aren't using any other kind of video decoder, correct? So with the latest release of MPC-HC, which includes the LAV Video Filter, these may be left off?

EDIT: I've answered my own question. Now I'd like to know if the madVR decoder is better than the LAV one, or if they produce identical output.

Last edited by Megalith; 6th December 2013 at 04:09.
Megalith is offline   Reply With Quote
Old 6th December 2013, 05:02   #21046  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by Megalith View Post
EDIT: I've answered my own question. Now I'd like to know if the madVR decoder is better than the LAV one, or if they produce identical output.
In theory, any decoder is supposed to give identical output for an identical input bitstream.

Differences in the output can only be the result of decoder bugs or additional post-processing, but the latter isn't really part of the actual decoder anymore.

Biggest difference between different decoders is the performance and whether they are implemented in software or use "hardware" acceleration.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 6th December 2013 at 14:00.
LoRd_MuldeR is offline   Reply With Quote
Old 6th December 2013, 09:04   #21047  |  Link
THX-UltraII
Registered User
 
Join Date: Aug 2008
Location: the Netherlands
Posts: 851
Quote:
Originally Posted by annovif View Post
Hi , i know that with an HTPC i've got to output in RGB (4:4:4) 0-255 for the best quality , and in the catalyst control panel i've setted it (RGB full). About the level I've got coreavc that can set the input level and the output level separately 0-255 or 16-235 . Now , i know that the Blu ray level is 16-235 , so i have setted the coreavc input level in 16-235 . About the output level i want coreavc untouch the signal level and i've setted it to 16-235 too .
In the final In madvr i've setted 0-255 . Is this all ok for the best quality? Or have i to set 0-255 madvr and coreavc too ?

Thank you, Fabio
Now that (I think) that I know how all things works I ll try to summarize the BTB/WTW discussion. You basically have 3 options:

1.
Set madvr to pc levels, set gpu to pc levels, set TV to pc levels (0-255). This means, that BTB and WTW will be clipped, it also means that there is expansion involved, which might lead to banding. madvr dithering does a good job of eliminating that.

2.
Set madvr to TV levels, set GPU to pc levels, set TV to TV levels. This means there will be neither clipping nor expanding.

3.
If your TV doesn't have settings to change black levels and is fixed to TV levels: Set madvr to PC, GPU to TV. BTB and WTW will be clipped, and there is double processions going on (expansion by madvr -> reduction by gpu).

The second option is the best quality wise, because there is no processing of the levels involved, and therefore no banding introduced. The problem is that if you use your PC for anything but viewing through madvr, your levels will be messed up.

There is also a 4th option if you want both limited(video) and full-range(pc applications) to display properly. If you can adjust input mapping on your display (usually low or limited vs. normal or full) then use option 2 and switch display input to normal when displaying desktop applications.
THX-UltraII is offline   Reply With Quote
Old 6th December 2013, 23:58   #21048  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
Quote:
Originally Posted by 6233638 View Post
Thank you for the fix. If calibration is disabled, or I tell madVR that my display is calibrated to BT.709, things work as expected. But if I enable yCMS calibration (lowest value is a 5% measurement) I'm still seeing an elevated black level.
I hope this issue will be fixed by the new Argyll 1.6.2 but I haven't tested it yet. The new Argyll might also address (some of) the issues you have had with it in the past?
Asmodian is offline   Reply With Quote
Old 7th December 2013, 11:01   #21049  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by Asmodian View Post
I hope this issue will be fixed by the new Argyll 1.6.2 but I haven't tested it yet. The new Argyll might also address (some of) the issues you have had with it in the past?
I think that issue is unrelated, as I'm still using the yCMS options in madVR rather than loading an external 3DLUT.
6233638 is offline   Reply With Quote
Old 7th December 2013, 12:23   #21050  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by v0lt View Post
@madshi
I have problems with YV16 in madVR. But it is not clear reason in decoder or renderer.
Hmmmm... Is this your own decoder, respectively the MPC-HC decoder? Or LAV? Or something else? I can look into this, if you think it might be a renderer issue, but I'd need to be able to reproduce it somehow.

Quote:
Originally Posted by dansrfe View Post
Are there settings for changing the black/white levels in the settings dialog along with the keyboard shortcuts? Also, does changing them adjust the top and bottom of the gamma curve?
Which black/white levels are you talking about? The source black/white levels? Or the display black/white levels? There are settings for the display in the settings dialog - but not settings for the source, because by definition source black/white levels may differ from source to source, so it makes no real sense specifying them in the settings dialog.

Quote:
Originally Posted by Prot View Post
may i ask is there any x64 release of this VR?
No. There might be one some time in the future, but probably not any time soon.

Quote:
Originally Posted by cvrkuth View Post
I found this... In my display settings, I have checked 'Let me choose one scaling level for all my displays'.. I uncheck this and trouble is gone!
Weird. I'm not sure why such a setting would affect the refresh rate switching!

Quote:
Originally Posted by Niyawa View Post
Oh yeah, there's one more thing I'd like everyone to give their thoughts about. This user has been having issues with madVR output to TV with HDMI. We're not particularly sure what is causing that so any input here would be welcome.
I don't know what that would be. First check would be to try windowed mode instead of fullscreen exclusive mode. In windowed mode at least the media player window should be visible. If it is, does madVR show video rendering? If not, try disabling Overlay mode, in case it's activated. Of course it's possible that the GPU doesn't support PS3.0 pixel shaders, then madVR can't render.

Quote:
Originally Posted by 6233638 View Post
Thank you for the fix. If calibration is disabled, or I tell madVR that my display is calibrated to BT.709, things work as expected. But if I enable yCMS calibration (lowest value is a 5% measurement) I'm still seeing an elevated black level.
The feature works by checking if the output pixel happens to be a straight cardinal 8bit value (or very near to that). If it is, dithering can be safely disabled for this pixel. If there's a fractional part (worth mentioning) then dithering is necessary to produce a correct color (averaged over a bigger image area).

If dithering is not disabled for a pure black screen with yCMS calibration then that means that the yCMS 3dlut probably produces a fractional black level value for some reason. I don't know why. It could be a problem with yCMS, or a result of your display needing black correction of some sort, or some sort of inaccuracy in madVR's 3dlut processing. In the first 2 cases there's probably not much I can do about it.

Quote:
Originally Posted by LoRd_MuldeR View Post
In theory, any decoder is supposed to give identical output for an identical input bitstream.

Differences in the output can only be the result of decoder bugs or additional post-processing, but the latter isn't really part of the actual decoder anymore.

Biggest difference between different decoders is the performance and whether they are implemented in software or use "hardware" acceleration.
Mostly agreed. Two minor additions/corrections:

(1) I've read that the decoder is only 100% strictly defined for h264. For MPEG2 I've read that there's a tiny room of interpretation. So h264 decoder output should be bit identical, but MPEG2 decoder output might not be. But it's probably a very minor difference.

(2) Different decoders can produce different timestamps, which can result in different levels of motion smoothness. E.g. with really bad MPEG2 broadcasts, depending on the decoder behaviour some sections might be smooth or not smooth.

From a technical point of view, if the splitter timecodes contain jitter, decoder A might decide to use the splitter's I frame timecodes and interpolate the other timecodes. Decoder B might decide to use some sort of timecode averaging/smoothing. Decoder C might pass the splitter timecodes through untouched.

Another difference is when the decoder restarts its timecode logic. Some decoders do that when DirectShow reports a discontinuity. Others do it with every I frame.

"Bad" timecodes can result in motion judder/stutter, but that also depends on the renderer. madVR is a bit less sensitive about jittery timecodes than some other renderers, but with really bad timecodes you can bring madVR into trouble, too.
madshi is offline   Reply With Quote
Old 7th December 2013, 13:16   #21051  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by madshi View Post
If dithering is not disabled for a pure black screen with yCMS calibration then that means that the yCMS 3dlut probably produces a fractional black level value for some reason. I don't know why. It could be a problem with yCMS, or a result of your display needing black correction of some sort, or some sort of inaccuracy in madVR's 3dlut processing. In the first 2 cases there's probably not much I can do about it.
It must not be getting disabled for black if I'm seeing an elevated black level. My display turns a zone completely off if it's sent zero, but the zones only turn down to a very low level if it's above zero - even something like 0, 0, 1.

The LUT I am using is relatively simple, and is only used to fine-tune the gamma response of my display; grayscale and gamut are actually worse if I try to use yCMS for that - at least via the controls in the madVR settings window.
I displayed test patterns in my media player, measured them in CalMAN, and adjusted the yCMS values until each point measured exactly 2.40 gamma.

Code:
red,   Yxy, 0.2126, 0.640, 0.330
green, Yxy, 0.7152, 0.300, 0.600
blue,  Yxy, 0.0722, 0.150, 0.060
white, Yxy, 1.0000, 0.312713, 0.329016

5,   Yxy, 0.00080, 0.312713, 0.329016
10,  Yxy, 0.00545, 0.312713, 0.329016
15,  Yxy, 0.01415, 0.312713, 0.329016
20,  Yxy, 0.02750, 0.312713, 0.329016
25,  Yxy, 0.04550, 0.312713, 0.329016
30,  Yxy, 0.06950, 0.312713, 0.329016
35,  Yxy, 0.09900, 0.312713, 0.329016
40,  Yxy, 0.13300, 0.312713, 0.329016
45,  Yxy, 0.17300, 0.312713, 0.329016
50,  Yxy, 0.21900, 0.312713, 0.329016
55,  Yxy, 0.27500, 0.312713, 0.329016
60,  Yxy, 0.33200, 0.312713, 0.329016
65,  Yxy, 0.40000, 0.312713, 0.329016
70,  Yxy, 0.48100, 0.312713, 0.329016
75,  Yxy, 0.55800, 0.312713, 0.329016
80,  Yxy, 0.64250, 0.312713, 0.329016
85,  Yxy, 0.73160, 0.312713, 0.329016
90,  Yxy, 0.82350, 0.312713, 0.329016
95,  Yxy, 0.91250, 0.312713, 0.329016
100, Yxy, 1.00000, 0.312713, 0.329016
I am not able to set a zero point in the yCMS dialog - the save button is disabled if I try to do that, so one would assume it is being set to zero. After all, who wants an elevated black level?

Back when I was using external hardware which let you write your own custom LUTs as a text file, no matter what the lowest measured value in the LUT was, I would always set black to 0, 0, 0.

If you are using interpolation/smoothing on the LUT, it also needs to follow the curve from the lowest point of data (typically 10%) down to the lowest value in the LUT rather than trying to converge on 0, 0, 0, otherwise you can end up with highly distorted values near black.
It should look something like this (video levels) rather than the values from 10% down converging at black.
In that example, all values would be considerably darker than they should be, and you would have red tinted shadows below 10% if that were the case. You would be surprised at how many calibration packages made that mistake - it's why I preferred to manually calculate the LUTs myself.


While values near black may need to be quite elevated for proper shadow detail to be visible, as in the example I posted above, I can't think of a reason you would not want black to be zero.
6233638 is offline   Reply With Quote
Old 7th December 2013, 17:07   #21052  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
http://www.avsforum.com/t/1477339/so...#post_23430408
NicolasRobidoux is offline   Reply With Quote
Old 7th December 2013, 20:44   #21053  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Quote:
Originally Posted by NicolasRobidoux View Post
I'm noticing Jinc in the Image upscaling of a diagonal pattern has some parts where the lines aren't completely straight.
The line which goes from bottom left to top right has X patterns which form a star and the other line has twelve smudgy strike out lines.
Is this effect something that could be improved?
ryrynz is offline   Reply With Quote
Old 8th December 2013, 00:04   #21054  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by 6233638 View Post
It must not be getting disabled for black if I'm seeing an elevated black level. My display turns a zone completely off if it's sent zero, but the zones only turn down to a very low level if it's above zero - even something like 0, 0, 1.

The LUT I am using is relatively simple, and is only used to fine-tune the gamma response of my display; grayscale and gamut are actually worse if I try to use yCMS for that - at least via the controls in the madVR settings window.
I displayed test patterns in my media player, measured them in CalMAN, and adjusted the yCMS values until each point measured exactly 2.40 gamma.

I am not able to set a zero point in the yCMS dialog - the save button is disabled if I try to do that, so one would assume it is being set to zero. After all, who wants an elevated black level?

Back when I was using external hardware which let you write your own custom LUTs as a text file, no matter what the lowest measured value in the LUT was, I would always set black to 0, 0, 0.
If you think this could be a bug in madVR then please feel free to create an entry in the bug tracker. Then I'll have a look when I find some time. If it's a bug in yCMS then there's nothing I can do. I don't even have the yCMS source code. And even if I had, I wouldn't know how to fix it.

Quote:
Originally Posted by NicolasRobidoux View Post
Yep, I know...

Quote:
Originally Posted by ryrynz View Post
I'm noticing Jinc in the Image upscaling of a diagonal pattern has some parts where the lines aren't completely straight.
The line which goes from bottom left to top right has X patterns which form a star and the other line has twelve smudgy strike out lines.
Is this effect something that could be improved?
I think this is probably an distorted/bad screenshot. Try downloading the test pattern video, I don't see these strike out lines here.
madshi is offline   Reply With Quote
Old 8th December 2013, 00:37   #21055  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by madshi View Post
If you think this could be a bug in madVR then please feel free to create an entry in the bug tracker. Then I'll have a look when I find some time. If it's a bug in yCMS then there's nothing I can do. I don't even have the yCMS source code. And even if I had, I wouldn't know how to fix it.
I'm guessing it'll be however yCMS is interpolating when creating the LUT.

There's no way to have madVR override this so that black is always completely black? (either in the LUT, or after it?)
E.g. have madVR run a known black reference through yCMS, and always set that value as zero.

It's only a very minor gamma correction I'm doing for the sake of correctness rather than being something my display needs, so I suppose I can stick to telling madVR my display is already calibrated.

It sounds like people are also having this problem when creating LUTs via other tools like ArgyllCMS, so I wonder if it's something worth investigating?

You shouldn't have to adjust the LUT at all, just set the lowest value that it outputs as zero, rather than being slightly elevated.



I wish the LUT process was a lot easier where you could just set RGB output values, rather than adjusting input values. It's less automated, but it makes it trivial to get good results. Create a patch of color in your image editor of choice, adjust the RGB values until it matches your target, and enter those values in the LUT.

I suppose that gets complicated once you're looking to do a lot of points for gamut calibration rather than just grayscale and gamma, but it's still so much simpler to say that 100% blue needs 16,32,250 to be accurate than anything else, for example. (though you would probably want to use at least 10-bit values)

Last edited by 6233638; 8th December 2013 at 00:43.
6233638 is offline   Reply With Quote
Old 8th December 2013, 10:11   #21056  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
As I said, if you think this is something I should fix in madVR, feel free to create an entry in the bug tracker. I don't have time to look at this *now*, and I will forget about it, if it's not in the bug tracker.
madshi is offline   Reply With Quote
Old 8th December 2013, 11:39   #21057  |  Link
v0lt
Registered User
 
Join Date: Dec 2008
Posts: 1,959
Quote:
Originally Posted by madshi View Post
Hmmmm... Is this your own decoder, respectively the MPC-HC decoder? Or LAV? Or something else? I can look into this, if you think it might be a renderer issue, but I'd need to be able to reproduce it somehow.
I use a modified MPC-BE.
mpc-be_3994_YV16.7z

Last edited by v0lt; 8th December 2013 at 18:48.
v0lt is offline   Reply With Quote
Old 8th December 2013, 12:57   #21058  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by v0lt View Post
I use a modified MPC-BE.
mpc-be_3994_YV16.7z
From looking at my source code and a test madVR log it seems to me that madVR is doing its part correctly. Then I've dumped out a frame coming from the MPC-BE test build, and the lower half of the chroma information is zeroed out - while it should be around 0x80 for a black screen. So this looks very much like it's MPC-BE's fault. The luma information looks correct, the size of the frame, too, but the chroma information is stored incorrectly. The 2nd half is zeroed out, the first half is not correct, either.

Unfortunately LAV doesn't seem to support YV16, so we can't use LAV to double check. But I'm pretty sure this is MPC-BE's fault.

Last edited by madshi; 8th December 2013 at 12:59.
madshi is offline   Reply With Quote
Old 8th December 2013, 14:12   #21059  |  Link
v0lt
Registered User
 
Join Date: Dec 2008
Posts: 1,959
Quote:
Originally Posted by madshi View Post
From looking at my source code and a test madVR log it seems to me that madVR is doing its part correctly. Then I've dumped out a frame coming from the MPC-BE test build, and the lower half of the chroma information is zeroed out - while it should be around 0x80 for a black screen. So this looks very much like it's MPC-BE's fault. The luma information looks correct, the size of the frame, too, but the chroma information is stored incorrectly. The 2nd half is zeroed out, the first half is not correct, either.
Thank you. Most likely you're right. If I take an uncompressed YV16 AVI file, the decoder is not used and the picture is normal.
twogradients_RAW.rar

Quote:
Unfortunately LAV doesn't seem to support YV16, so we can't use LAV to double check. But I'm pretty sure this is MPC-BE's fault.
LAV contains the same code as in the modified MPC-BE, but this code is disabled.
v0lt is offline   Reply With Quote
Old 8th December 2013, 14:26   #21060  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Then maybe nevcairiel could help out fixing that code?
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 16:20.


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