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. |
19th October 2011, 14:26 | #10221 | Link |
Registered User
Join Date: Jan 2007
Posts: 530
|
"Best" is tough to define and in this case, subjective. If you care about h/w deinterlacing and madVR is your renderer of choice, then it seems nV might get the nod. If you can live with software deinterlacing, IMO, ATI 6xxx series is the way to go. Value of the 65xx series is hard to beat.
|
19th October 2011, 15:24 | #10222 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
Feature request:
Add information about the matrix used and levels into ctrl+J, so I don't have to go around checking ctrl+shift+alt+M/I. Also, when scrolling through ctrl+shift+alt+M/I, the "default" setting always says "(auto detect)". Is it possible to differentiate between for example BT.709 that is guessed based on the resolution, and streams that actually have the BT.709 flag? And if I "accidentally" activate gamma processing by pressing ctrl+shift+alt+F/G, there doesn't seem to be a way to disable it without unchecking the box in the settings. edit: I also have a video where ctrl+shift+alt+M doesn't do anything but change the text that says BT.709 or BT.601. Image stays at 709. If you don't know why, I'll try to cut out a small piece of it. It's 10-bit, 709 at PC levels. edit2: nevermind the previous edit, I'm an idiot =). Last edited by ajp_anton; 19th October 2011 at 17:07. |
19th October 2011, 16:03 | #10223 | Link |
Registered User
Join Date: Oct 2010
Posts: 131
|
frequency change
I own a Sony Tv that can work at 50 or 60 hz.
Until now I'm using Reclock to do 24fps -> 25fps and change the Tv set accordingly 24/25 fps -> 50Hz 29.97/30 fps -> 60 Hz Is it possible to let Reclock change 24 fps to 25 fps and Madvr change the frequency? |
19th October 2011, 17:07 | #10226 | Link |
Registered User
Join Date: Feb 2004
Posts: 399
|
madshi, I'm closing-in on figuring out the slow ZP / control bar seek freeze bug.
You were right, it seems to be a ZP bug.. After much testing, I found out that when I disable ZP's Interface > OSD > Action > "Show OSD filename when opening a new file", the issue _never_ happens (control bar always fast, never freezes) However with this feature disabled, more often than not I get a beautiful crash in madVR.ax as soon as playback starts. I enclose a debug log. Could you check if anything strange is going on on madVR side that explains the crash?
__________________
XP SP3 / Geforce 8500 / Zoom Player Last edited by TheShadowRunner; 19th October 2011 at 17:16. |
20th October 2011, 01:44 | #10227 | Link | ||
Registered User
Join Date: Apr 2009
Posts: 1,019
|
Quote:
I know how dithering works. But once you are in the lower-end of the greyscale (say 20% and under, particularly at higher gammas) single RGB value changes can make considerable differences on the display. With CRTs, this was significantly less of an issue, as +/- 1 RGB resulted in very small changes on the display, as being analogue, they were true 8-bit devices and (most) did not apply any digital processing that would reduce the precision of the display. If you send an 8-bit gradient to a CRT there is very little if any visible banding. With digital displays, particularly near black, +/- 1 RGB can result in changes of greater than 1-2 dE with an 8-bit input. Because of additional Greyscale, Gamma, CMS etc. processing, and limitations of the technology, most "digital" displays are not capable of displaying an 8-bit gradient that is perfectly smooth, especially compared with a CRT. With a 10-bit input, and a capable display, you have four times the precision for adjustments and can get much better results when tuning the lower-end of the greyscale/gamma. With madVR, outputting 8-bit or 10-bit may not make much of a difference to anything but the amount of dithering used, but when you're sending it to an actual display that is doing its own Greyscale/Gamma/CMS adjustments on top of what the 3DLUT has done, there can be a big difference between an 8-bit input and a 10-bit one. The LUT-processed image itself might be perfect and free of discolouration, but when you send that dithered 8-bit image to a digital display, which is rather imprecise, the end results can be poor. Dithering works because the shades used in dithering are supposed to be so close that they effectively blend together. With modern displays, however, each digital step (when near black) can be very noticeably different from the last, and so the differences between shades are too great for dithering to be effective. Quote:
If madVR's 8-bit output was going direct to a display which could show it without modification, I'm sure the results would be fine, but modern displays all do their own image processing to signals after the fact that cannot be disabled, and so sending them 10-bit data rather than 8-bit can definitely make a difference. I think this is probably a case of application vs theory. In theory, an 8-bit output from madVR may be enough, but from hand-tuning LUTs—by which I mean looking at individual greyscale patches and adjusting the RGB values for each one digit at a time with either 8-bit (0–255) or 10-bit (0–1024) precision and measuring the results, there are definite benefits from sending 10-bit data to a display that can make use of it. And with 8-bit LUTs, sometimes plus or minus a single digit at a specific point can be the difference between a visible error in the greyscale and it blending in smoothly. This is why I would prefer to be able to manually set 3DLUT output RGB values for points, rather than give it measurements from my display and calculate what it thinks is best. (which may be best on a perfect display) I'm not saying you're doing anything wrong, but sometimes manual controls are necessary, and I really do think that there will be good improvements once you have a 10-bit output working in exclusive mode. Last edited by 6233638; 20th October 2011 at 01:46. |
||
20th October 2011, 08:29 | #10228 | Link | ||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Two situations: (1) 16bit LUT, dithered down to 8bit, sent to display in 8bit. (2) 10bit LUT, sent to display in 10bit. I dare say that (1) will have a higher quality and precision. Who's using 8bit LUTs? madVR is using 16bit LUTs! |
||||||||||
20th October 2011, 09:42 | #10229 | Link |
Registered User
Join Date: Dec 2007
Posts: 652
|
Hi Madshi, any comments on these two observations? http://forum.doom9.org/showthread.ph...92#post1531792
1st Issue: madVR Windowed mode = Lip Sync issues on 23.776/24hz 2nd Issue: "Exclusive Mode Failed" Thanks Nathan |
20th October 2011, 09:49 | #10230 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
About the exclusive mode problem: I'd need a way to reproduce this, without having to wait hours or even days for the problem to appear. |
|
20th October 2011, 10:40 | #10231 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
|
|
20th October 2011, 12:24 | #10232 | Link | |
Registered User
Join Date: Apr 2009
Posts: 1,019
|
Quote:
I'm a calibration guy. I care about the end results, and try to do my best to understand how things work in the video chain to get the best results possible. The most recent LUT box I used was a VideoEQ Pro, which had 16-bit internal processing and the option of either an 8-bit or 10-bit output. To calibrate with the device, you set RGB output values for each point. (e.g. 10, 20, 30...% grey) So you either have 10-bit or 8-bit control over what is being sent to the display at any one point, so you could set 50% grey to 126,125,128 or 502,501,510 for example. At the lower end of the greyscale, if you were working in 8-bit, I saw the same kind of discolouration that I am seeing in madVR. With 10-bit controls, you could tweak the values slightly and end up with a much better result on the display. What I would see with many displays is that moving the control either up or down a notch would sometimes result in no visual change on the display - at some points it would take two or three notches before the display actually changed at all (this is not uncommon) however taking the time to find the best values definitely improved things. I don't know that the problem is necessarily with the 3DLUTs in madVR itself, but that sending 8-bit data to the display isnt a good enough input for its own internal LUTs/Processing to work with, as illustrated above. Sometimes it's more about manipulating the data being sent to the display to get the result you want rather than sending the "correct" data and hoping the display behaves itself. (unless it's a CRT, it won't) I would consider most displays' internal processing to be "lossy" so you really want to give them as much data to work with as possible. It may not have much of an effect on madVR's side of things whether it outputs 8-bit or 10-bit, but there can be consequences further along the display chain as a result. When you're limited to 8-bit out, +/- 1 RGB can make a big difference, which is why I'm so frustrated at the lack of control with 3DLUTs, because I know I can get better results than I am now, even with 8-bit out of the PC. I know that the output is dithered and so +/- 1 shouldn't matter, but from working with various external calibration/LUT boxes over the years, I'm not convinced this is getting the best results from the display. I'm still not entirely convinced that you can manipulate an 8-bit source in 16-bit, dither it back down to 8-bit for output and have a lossless result either, but that's another matter. Comparing like-for-like, with the 3DLUT calibration disabled, madVR certainly has the best 8-bit output I've seen from any Blu-ray source, so you're obviously doing the best job possible there. (not that I had any doubts) |
|
20th October 2011, 12:48 | #10233 | Link | |||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
- 256x256x256 data points - 16bit output - dither Your experience with those LUT boxes doesn't say much, if they didn't use dithering, or/and if they had much less input data points than madVR has. Especially if they don't use dithering *and* have less input data points, you can't really compare that to madVR's solution at all. Quote:
You said it yourself: With an "empty" 3dlut, you see no banding and no discoloration. But still, with an empty 3dlut, madVR runs the full processing with the final dithering down to 8bit output. If either the 3dlut or the downdithering to 8bit is a problem in itself, why do you not see any problems with an empty 3dlut? That makes no sense. So the problem is neither the 3dlut processing in itself, nor the dithering down to 8bit. The problem you're seeing with madVR is probably caused by either bad measurements and by yCMS doing something wrong. At least that's my current understanding. |
|||||
20th October 2011, 13:19 | #10234 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
madVR v0.75 released
http://madshi.net/madVR.zip Code:
* fixed: v0.74 stopped decoder DirectShow filter from being released properly * fixed: PotPlayer sometimes crashed when switching video files * fixed: internal decoders made problems with cropped MKVs & Haali Splitter * fixed: OSD sometimes didn't appear in ZoomPlayer in exclusive mode * fixed: VP70 decoder showed video upside down * fixed: RGB24 input sometimes crashed madVR * fixed: ffdshow RGB input level detection sometimes failed * subtitles run through the 3dlut now, too * internal decoders are now auto disabled if required decoder dlls are missing * added option to scale Luma in linear light, disabled by default * RGB input with unknown range is now treated by default as full range * added detailed information about matrix, primaries and levels to debug OSD * updated libav/ffmpeg dlls @STaRGaZeR, please check whether you can find a situation where the auto detection still fails. I hope you won't find any such situations, anymore. If you do, please let me know. And maybe you can then upload a sample, that would be helpful. Thanks. |
20th October 2011, 14:13 | #10240 | Link |
Registered User
Join Date: Aug 2010
Posts: 134
|
Downscaling in linear light seems to look just slightly better, but upscaling has bit too much aliasing, and what looks to be chroma bleeding as well? Just tried both with spline3.
Potplayer bug: all madvr and potplayer osd and subtitles have blackness instead of transparency. |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|