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. |
4th December 2013, 19:31 | #21041 | Link | |
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:
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. |
|
5th December 2013, 00:35 | #21042 | Link | ||
Registered User
Join Date: Dec 2012
Location: Neverland, Brazil
Posts: 169
|
We appreciate it.
Quote:
Quote:
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 |
||
5th December 2013, 20:52 | #21044 | Link | |
Registered User
Join Date: Apr 2009
Posts: 1,019
|
Quote:
|
|
6th December 2013, 03:53 | #21045 | Link |
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. |
6th December 2013, 05:02 | #21046 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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. |
|
6th December 2013, 09:04 | #21047 | Link | |
Registered User
Join Date: Aug 2008
Location: the Netherlands
Posts: 851
|
Quote:
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. |
|
7th December 2013, 12:23 | #21050 | Link | ||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
No. There might be one some time in the future, but probably not any time soon. Quote:
Quote:
Quote:
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:
(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. |
||||||
7th December 2013, 13:16 | #21051 | Link | |
Registered User
Join Date: Apr 2009
Posts: 1,019
|
Quote:
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 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. |
|
7th December 2013, 20:44 | #21053 | Link | |
Registered User
Join Date: Mar 2009
Posts: 3,646
|
Quote:
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? |
|
8th December 2013, 00:04 | #21054 | Link | |||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
|
|||
8th December 2013, 00:37 | #21055 | Link | |
Registered User
Join Date: Apr 2009
Posts: 1,019
|
Quote:
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. |
|
8th December 2013, 10:11 | #21056 | Link |
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.
|
8th December 2013, 11:39 | #21057 | Link | |
Registered User
Join Date: Dec 2008
Posts: 1,959
|
Quote:
mpc-be_3994_YV16.7z Last edited by v0lt; 8th December 2013 at 18:48. |
|
8th December 2013, 12:57 | #21058 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
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. Last edited by madshi; 8th December 2013 at 12:59. |
|
8th December 2013, 14:12 | #21059 | Link | ||
Registered User
Join Date: Dec 2008
Posts: 1,959
|
Quote:
twogradients_RAW.rar Quote:
|
||
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|