madVR - high quality video renderer (GPU assisted)

[TheShadowRunner]

This is a bug in the VP7 decoder. But I've found a workaround which I'll implement in the next madVR build.

Thank you!

It sounds more like a ZP bug to me, but of course I can't be sure. Why are you disabling the option "Display OSD through madVR's OSD API"? Does it have any disadvantages?

Yes, the control bar displayed via madVR's OSD API is much less reactive/ laggy. Scrolling it is also kind of a pain.
Since I have no issues with madVR going windowed <> FSE, I disabled "Display OSD through madVR's OSD API" completely.

Why do you switch the display refresh rate *while* the movie is playing? That's not a good idea, generally, IMHO. madVR generally doesn't like it much if you modify the refresh rate behind its back.

Yes, I know that, but the bug occurs also when madVR's internal frequency switcher is used, before the movie begins.
As I was reporting, it doesn't make any difference when it comes to this bug if madVR does it internally, or if ReClock or I do it manually.

From the log I enclosed, do you see any issue on the madVR side?

[6233638]

Uniformity issues are usually per panel (red, green, blue) and totally separate from the other panels. So using three 1dluts would be a much more efficient way for such a feature. That is, if I understand correctly what you're talking about. You do mean brightness variations of a panel, right?Higher end monitors such as Eizo (PC) or Sony/Barco (Broadcast) use LUTs for uniformity correction, my guess is that's what he's looking for.

Seems like it could be a pretty good feature—my LCD has 70 zones and while uniformity is pretty good for an LCD as a result, there doesn't seem to be any uniformity correction available via the service menu, so doing it through the HTPC would be interesting to see just how much better things could get.

BTB and WTW are not supposed to be visible on a properly calibrated display.I agree, BTB should not be visible on a calibrated display—the only reason to make BTB visible, is to make it easier to set up black level on a CRT. It really isn't necessary on flat panel displays where there is a very obvious jump in brightness across the whole screen if you just display a full black image and adjust the brightness control.

WTW visibility is debatable. Reference-class displays are still required to show 16–255, though in reality most content does not have anything above 235 and it can improve the contrast on many current displays. The option to preserve WTW would be nice though.


- probably necessary for 3D presentation (in a future version)
- necessary for 10bit output (in a future version)This is very exciting! I don't care if it's months away, you always deliver and I'm happy to wait.

I'm not accepting donations yet. Please wait for madVR v1.0. Once I get there, I'll accept donations, or maybe make a "pro" version with added features for a small price.As soon as you start accepting donations, or offering a "pro" version, you have my money.

Not sure what you mean. There should be no noticeable drop in quality when using 3DLUTs.While madVR does a great job working in 16-bit and dithering down to 8-bit for output, 8-bit just isn't enough precision to avoid discolouration and/or banding in the image.

Here are a couple of crops from Tron Legacy, at 200%

My current 3DLUT with data from 20–100% in 10% steps:
http://img16.imageshack.us/img16/6356/76925277.png (http://img16.imageshack.us/img16/6356/76925277.png)
Shows some discolouration/banding but tolerable for the improvements using a 3DLUT brings.

3DLUT with data from 10–100%:
http://img6.imageshack.us/img6/4394/91607264.png (http://img6.imageshack.us/img6/4394/91607264.png)

As you can hopefully see, there is a noticeable increase in banding and reddish discolouration in the darker areas. (might be easiest to open them in separate tabs in your browser and switch between the two)

This is with modified data too—I only used the Y value from my display at 10%, xy are set to D65, as that seemed to reduce the errors.

I'm hoping that 10-bit out to the display will help in reducing those errors.

Of course, this all depends on what kind of display you're using. With CRT, any kind of reduction in bit-depth is immediately obvious. On LCDs and LCoS/SXRD it's fairly noticeable, on Plasmas it probably isn't noticeable at all, as they add colour errors like this on their own. It's the main reason I couldn't stand to keep any of the Kuros.


This is partly why I would like the ability to tweak the output RGB values being sent to the display from a LUT, rather than giving it input values. I have had success in reducing this kind of error by manually tweaking the LUT with external devices. (but ultimately, none of them have been worth the additional expense over madVR & yCMS)

[mr.duck]

madVR is screwing with keyboard shortcuts in other programs. Specifically Ctrl+Shift+R

Is this a shortcut used by madVR? Can I have an option to disable all shortcuts plox? :)


Feature request: Settings >> rendering >> windowed mode settings >> new option: show seek bar


Thx. madVR rocks :)

[pdanpdan]

Yes, and try to use a linux console and search something with CTRL+R :)

[madshi]

Higher end monitors such as Eizo (PC) or Sony/Barco (Broadcast) use LUTs for uniformity correction, my guess is that's what he's looking for.
I highly doubt they use 3dluts, though, which was the point I was trying to make. They most probably use 3 separate 1dluts.

While madVR does a great job working in 16-bit and dithering down to 8-bit for output, 8-bit just isn't enough precision to avoid discolouration and/or banding in the image.
I strongly disagree. Dithering down to 8bit output does not cause any problems with discoloration or banding at all. The problems you're seeing are caused by either bad measurements or by yCMS processing problems, can't say for sure. Going to 10bit output will not change discoloration or banding at all, you will see exactly the same thing there. The only thing 10bit output will help with is reducing the strength of the dithering noise.

madVR is screwing with keyboard shortcuts in other programs. Specifically Ctrl+Shift+R
In a future version you'll be able to choose custom keyboard shortcuts to avoid such conflicts.

Feature request: Settings >> rendering >> windowed mode settings >> new option: show seek bar
Has been posted before. On my to do list, under "low priority".

[madshi]

I recently decided to give madVR another go, last time I had issues in fullscreen. After many tries it's apparent that in my own system MadVR is incapable to produce a smooth video image. Even when the renderer itself reports zero glitches the motion is glitchy, I can see microstutters in every panning scene. I've tried all the flush options, the DX11 option, the anti-glitch options, nothing gets rid of the glitches. It is sad, because the image quality is top, but I cannot tolerate glitches when I watch videos.
Which movie frame rate and display refresh rate are we talking about? What does the madVR OSD say about the various queues (are they all full or nearly full?) and about dropped and delayed frames? Does the problem occur in both windowed and exclusive mode? If it occurs in windowed mode, too, does turning Aero on/off make any difference? What happens if you disable Reclock, does the problem go away then?

Make sure VSync correction is disabled in Reclock. You reported that you used a profile to fix the clocks. Have you verified whether the profile actually works as intended?

[madshi]

Yes, I know that, but the bug occurs also when madVR's internal frequency switcher is used, before the movie begins.
As I was reporting, it doesn't make any difference when it comes to this bug if madVR does it internally, or if ReClock or I do it manually.

From the log I enclosed, do you see any issue on the madVR side?
Hmmmm... According to the log, a seek was performed after about 5 seconds of playback. During/after that seek playback was paused, but never resumed. So basically madVR doesn't seem to be frozen at all. It's just that playback is paused. You just pressing play/pause once or twice should unfreeze the player - unless the media player itself is really frozen. If that's the case the log doesn't indicate why that would have happened.

[TheShadowRunner]

Hmmmm... According to the log, a seek was performed after about 5 seconds of playback. During/after that seek playback was paused, but never resumed. So basically madVR doesn't seem to be frozen at all. It's just that playback is paused. You just pressing play/pause once or twice should unfreeze the player - unless the media player itself is really frozen. If that's the case the log doesn't indicate why that would have happened.

Damn, I feared so. For that log, I never paused once (and madVR's own internal frequency switcher was used btw).
Zoom Player is really frozen, and hangs there. In this state, its own guarddog kills it (after 20 seconds, it's a feature), or if the guarddog is disabled the only option is to kill the zplayer.exe process manually (what I did for that log, in order to keep it small).
I'll try to come up with a method to always recreate the issue...

A maybe related question: when frequency switching is involved, exemple 720p@60 to 1080p24, sometimes the switch is instantanous (exactly when the media starts) and sometimes [for the same media!] it takes up to 6-7 seconds before the switch occurs, during which a couple seconds of the media are looped (5-6 times).
What is this difference due to ? (I'm asking for madVR's internal frequency switcher specifically)

[madshi]

Damn, I feared so. For that log, I never paused once (and madVR's own internal frequency switcher was used btw).
Zoom Player is really frozen, and hangs there. In this state, its own guarddog kills it (after 20 seconds, it's a feature), or if the guarddog is disabled the only option is to kill the zplayer.exe process manually (what I did for that log, in order to keep it small).
I'll try to come up with a method to always recreate the issue...
In any case you may want to contact the ZP developer. From the log it doesn't look to me like madVR was at fault.

A maybe related question: when frequency switching is involved, exemple 720p@60 to 1080p24, sometimes the switch is instantanous (exactly when the media starts) and sometimes [for the same media!] it takes up to 6-7 seconds before the switch occurs, during which a couple seconds of the media are looped (5-6 times).
What is this difference due to ? (I'm asking for madVR's internal frequency switcher specifically)
I don't know. I just tell the OS to change the display mode.

[Dogway]

Is it the dither error diffusion or ordered dither? I say because I encode my rips in ordered dither (to save bitrate), I have tested ordered dithering over ordered dither and results are horrible so by the moment I have dithering disabled just in case.

I would also like to suggest a profile load option. Or some way where you can switch fast exclusive mode with windowed mode with its preconfigured settings. That is because I normally use mpc-hc to play small files, preview my encodes, watch clips downloaded from youtube, etc, and windowed mode is more convenient as I can pause, do a few things aside, resize window, I mean, more manageable. Other times I would just plug my laptop to the TV use exlusive mode, and Im good to go.

I also envy how you managed to port the resizers to be processed by the GPU, it would be great to see spline36 running on GPU for avisynth as well.
Welcome back!

[madshi]

Is it the dither error diffusion or ordered dither?
Neither nor. I'm currently using TPDF (random) dithering. I would love to implement some kind of error diffusion, but the basic principle of error diffusion is to spread the error to neighboring pixels. And that contradicts the basic principle of how GPUs work. Maybe I'll find a way to make error diffusion work by using CUDA/OpenCL some time in the future, but it would probably be quite slow, due to the algorithm contradiction I mentioned.

I have tested ordered dithering over ordered dither
I don't think madVR's dither should collide with ordered dither. Of course it's always better to not dither at all, but to use a higher bitdepth instead. But if you can't use a higher bitdepth, then it's usually better to use dither than to not use it. Maybe applying ordered dither twice is bad, that's quite possible. I have no personal experience with ordered dither. Anyway, that doesn't apply to TPDF dithering (used by madVR). TPDF dithering can be applied multiple times without any negative side effects, other than that applying it multiple times of course raises the noise floor. In audio processing TPDF dithering is used all the time.

I would also like to suggest a profile load option.
Maybe in some future version. Not anytime soon, though. Too many crucial things missing to spend my time on things like that right now.

[G_M_C]

Madshi, welcome back after a well-earned break.

First: I've been using madVR for a short period now, coming from JanWillems test-builds. Must say i'm satisfied with madVR's stable output and quality.

JanWillems builds however had a possibility to convert 8-bpc video to 10-bpc, and output that. It uses EVR-CP, i know, but somehow it was possible to force 10-bit output. I have the luck that i have equipment that accepts this 10-bit video. So 'bit-wise' that seems to be the better option.

But JanWillems builds aren't always stable (thats logical, they aren't labeled experimental for nothing), and also AVR-CP isn't always stable. Thats why i choose to work with madVR.

Some posts in this thread before there was some talk about 10-bpc maybe coming to madVR. Can you comment about this, do you think it is possible, and/or are you working on this subject ?

Also some posts before there was some talk about MPC-HT with madVR not exiting full-screen correctly. I want to report that i have also noticed this. I run full-screen on my secondary display. When exiting full screen, and coming back to my primary display the MPC-HT's window doesn't have the window-controls in the top bar anymore (dont know what they are called, but i mean the 3 small buttons in the right top for minimizing/maximizing/closing the window). These controls are 'simply not there anymore'

[TheShadowRunner]

In any case you may want to contact the ZP developer. From the log it doesn't look to me like madVR was at fault.

I sure did, and Blight and I came to the conclusion it's a madVR issue since it doesn't happen with EVR/VMR9.
I can reproduce the bug at will here.. only with madVR.

Maybe these logs can help.
I do _exactly_ the same for both tries, and close ZP in between of course.

I launch ZP, play a SD PAL video and then close the player. (madVR's internal frequency switcher is used: 720p60 to 720p50)

http://videoff7.free.fr/madVR_ZP_OK.zip (fast ZP control bar, all OK)
http://videoff7.free.fr/madVR_ZP_buggy.zip (slow ZP control bar, freeze if seek)


I don't know. I just tell the OS to change the display mode.

Ok, I found out that this delay that sometimes occur before frequency switching is due to ReClock, never happens when ReClock isn't in the graph. All OK on the madVR side regarding this.

[TheProfosist]

Unfortunately crash reports like this are hard for me to fix at this point in time. If there was a way for me to reproduce the crash, that would help greatly. Unfortunately these crashes don't seem to occur on my PC.
I posted more information later on in the thread (http://tinyurl.com/6f8twj2). And the problem on the laptop I believe is because of Nvidia Optimus.

[6233638]

I highly doubt they use 3dluts, though, which was the point I was trying to make. They most probably use 3 separate 1dluts.You're right, they do use 1D LUTs, I misunderstood the point you were trying to make.

I strongly disagree. Dithering down to 8bit output does not cause any problems with discoloration or banding at all. The problems you're seeing are caused by either bad measurements or by yCMS processing problems, can't say for sure.Editing the LUT so that xy values for all points are D65 (0.312713, 0.329016) still introduces that discolouration/banding in the image, so it's not a measurement/greyscale issue.

It is a combination of both what is being done with the LUT, and how those values end up being displayed on the screen. Using higher precision does have benefits in this area beyond reducing dithering. This is why high end displays use much higher precision LUTs for internal calibration. High-end Eizo monitors use 16-bit LUTs to drive the display panel for example:
http://img545.imageshack.us/img545/1834/1016bit.jpg
(of course the panels themselves are not 16-bit native, but they aren't 8-bit either)

When you are only sending 8-bit to a display, changing the RGB values being sent to it by even a single digit can have considerable effects on greyscale at the lower end of the scale. With 10-bit, you have four times the precision and it really does make a difference in reducing visible errors. (another reason why I want to manually tweak the LUT output values)

I have spent a considerable amount of time hand-tuning LUTs with dedicated devices, and this is a definite limitation caused by a lack of precision when only outputting 8-bit.

[madshi]

JanWillems builds however had a possibility to convert 8-bpc video to 10-bpc, and output that.
And does it look "better" in that mode compared to madVR?

Some posts in this thread before there was some talk about 10-bpc maybe coming to madVR. Can you comment about this, do you think it is possible, and/or are you working on this subject ?
I may look into this in a future version. But to be honest, I don't find it very important, because the only benefit 10bit output would bring is a lower dithering noise floor. Other than that, 10bit output will have no advantage.

Also some posts before there was some talk about MPC-HT with madVR not exiting full-screen correctly. I want to report that i have also noticed this. I run full-screen on my secondary display. When exiting full screen, and coming back to my primary display the MPC-HT's window doesn't have the window-controls in the top bar anymore (dont know what they are called, but i mean the 3 small buttons in the right top for minimizing/maximizing/closing the window). These controls are 'simply not there anymore'
This was reported with some older madVR versions when using the madVR D3D11 presentation mode. Are you using that mode? And are you sure you're using the latest madVR version? Try without D3D11 presentation mode. Does the problem still occur?

I sure did, and Blight and I came to the conclusion it's a madVR issue since it doesn't happen with EVR/VMR9.
I can reproduce the bug at will here.. only with madVR.
Haha, two can play that game: The issue only occurs with ZP, but not with any other media player, so it must be ZP? :D

Fact is, the problem only occurs with the combination of ZP + madVR. Use a different renderer and/or media player and the problem is gone. So we have no proof. It could be either ZP or madVR or it could be how those two interact. The log you uploaded earlier does not indicate a madVR problem.

Maybe these logs can help.
I do _exactly_ the same for both tries, and close ZP in between of course.

I launch ZP, play a SD PAL video and then close the player. (madVR's internal frequency switcher is used: 720p60 to 720p50)

http://videoff7.free.fr/madVR_ZP_OK.zip (fast ZP control bar, all OK)
http://videoff7.free.fr/madVR_ZP_buggy.zip (slow ZP control bar, freeze if seek)
Not sure what to look for in those logs. Both run about 6.8 seconds and then stop. Both look ok to me. The "buggy" log runs 6815 milliseconds and after 6813 milliseconds madVR claims to have successfully displayed a video frame. So I don't see anything wrong in that log. Or did the freeze start after those 6.8 seconds?

Ok, I found out that this delay that sometimes occur before frequency switching is due to ReClock, never happens when ReClock isn't in the graph. All OK on the madVR side regarding this.
Again, having someone else change display modes behind madVR's back is not a good idea. You sure this isn't the cause of the problem?

I posted more information later on in the thread (http://tinyurl.com/6f8twj2).
From your post it looks like most of the problems are D3D11 related? I'm aware of that the D3D11 presentation mode is not as stable as it should be atm. That's on my list of things to look at. The D3D11 presentation mode is only meant as a last resort if you run into glitch problems. So if you don't urgently need the D3D11 mode, I'd suggest to turn it off (for now).

[madshi]

Editing the LUT so that xy values for all points are D65 (0.312713, 0.329016) still introduces that discolouration/banding in the image, so it's not a measurement/greyscale issue.
I've checked test patterns with an "empty" 3dlut and found pretty much zero changes, when turning the 3dlut on/off. If you have a reproducible test case with an "empty" 3dlut (meaning a 3dlut which doesn't actually change anything), causing discoloration/banding, please let me know and help me reproduce the problem.

It is a combination of both what is being done with the LUT, and how those values end up being displayed on the screen. Using higher precision does have benefits in this area beyond reducing dithering. This is why high end displays use much higher precision LUTs for internal calibration. High-end Eizo monitors use 16-bit LUTs to drive the display panel for example
I'm not sure what you're talking about. The 3dluts used by madVR are 8bit input and 16bit output. Are you saying that Eizo monitors are using 16bit *input* 3dluts? That's technically impossible. Such a 3dlut would consume 1536 Terrabytes of memory. The 3dluts used by displays are to my best knowledge usually 17x17x17 with 16bit output bitdepth. The 3dluts used by madVR are 256x256x256 with 16bit output bitdepth. I'm pretty sure that there's not a single display out there which uses a 3dlut anywhere near the precision that madVR uses.

When you are only sending 8-bit to a display, changing the RGB values being sent to it by even a single digit can have considerable effects on greyscale at the lower end of the scale. With 10-bit, you have four times the precision and it really does make a difference in reducing visible errors.
No, it does not. Please look up "dithering" and how it works.

I have spent a considerable amount of time hand-tuning LUTs with dedicated devices, and this is a definite limitation caused by a lack of precision when only outputting 8-bit.
Can you please clarify which exact bitdepth you're talking about? E.g. there is the bitdepth you feed into the 3dlut, then there is the 3dlut input bitdepth, then there is the 3dlut output bitdepth, and then there is the HDMI transport bitdepth. You can't just talk about 8bit without specifying which exact bitdepth you mean. In the madVR processing chain there are 3 different bitdepths which could be described as "output" bitdepth.

Those hand-tuned LUTs with dedicated devices, do they do trilinear interpolation? Which input/output bitdepth does the LUT have? Which bitdepth does the display accept and is the LUT output dithered down to the native display bitdepth?

[G_M_C]

And does it look "better" in that mode compared to madVR?

Cant say for sure, cause looking better is kind of an subjective argument/feeling. But i have the feeling it did. Simply because i could turn of dithering in JanWillems build (or set it the lowest random setting), and outputting the 10-bit video to my receiver, wich in turn does 'its thing' using a Reon-VX video processor. Image seemed to be clearer, having more 'color-fidelity'. But as i said: This is subjective to be sure, i have to do some comparison between the two.

But then again: Another important argument for madVR is that using madVR with a trunk build of mpc-ht is more stable then Jan's experimental builds.


I may look into this in a future version. But to be honest, I don't find it very important, because the only benefit 10bit output would bring is a lower dithering noise floor. Other than that, 10bit output will have no advantage.

Thanx for your reply on this. 10-bit would be interesting i guess. But if benefit is small, and my subjective feeling towards it is wrong, than the effort might not be worth it.


This was reported with some older madVR versions when using the madVR D3D11 presentation mode. Are you using that mode? And are you sure you're using the latest madVR version? Try without D3D11 presentation mode. Does the problem still occur?

I'm using 0.74, which is latest afaik. And your right, not using D3D11 mode fixes the problem. I'll keep using the D3D9 path. I set it to D3D11, simply without thinking (like: I have D3D11, so might as well use it).

[TheShadowRunner]

Haha, two can play that game: The issue only occurs with ZP, but not with any other media player, so it must be ZP? :D
Fact is, the problem only occurs with the combination of ZP + madVR. Use a different renderer and/or media player and the problem is gone. So we have no proof. It could be either ZP or madVR or it could be how those two interact. The log you uploaded earlier does not indicate a madVR problem.
Thanks, good to know. It could very well be a ZP bug, I'm not saying otherwise, just trying to rule out one of the 2.

Not sure what to look for in those logs. Both run about 6.8 seconds and then stop. Both look ok to me. The "buggy" log runs 6815 milliseconds and after 6813 milliseconds madVR claims to have successfully displayed a video frame. So I don't see anything wrong in that log. Or did the freeze start after those 6.8 seconds?
No I didn't seek the control bar to trigger the freeze this time, but on the "buggy" log, ZP was in that weird slow state that eventually freezes after seeking. I was hoping the logs would show something different after (madVR's internal) frequency switch.

Again, having someone else change display modes behind madVR's back is not a good idea. You sure this isn't the cause of the problem?
Yes, I'm absolutely certain, I very much understood you don't like frequency switching behind madVR's back, so for all my testing I exclusively use madVR's internal switcher! ^^;

[pacemaker1000]

sorry to repeat myself but i am looking to pull the trigger today on a new GPU
contenters are the nvidia gt 430 or AMD 5xxx
initila research looks like the 430 was blighted on launch by bad drivers but i cant find if this is sorted
as i use MadVr and i know you lot are critical about picture quality like me can anyone suggest which is best? and if amd which model within the 5xxx series ar is a basic 6xxx better

thanks in advance

[noee]

"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.

[ajp_anton]

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 =).

[toniash]

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?

[XRyche]

madshi, do you have any plans on adding colour controls(contrast, brightness, saturation, hue) to madVR?

[nand chan]

madshi, do you have any plans on adding colour controls(contrast, brightness, saturation, hue) to madVR?

You can use a .3dlut for this

[TheShadowRunner]

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) :D
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 (http://videoff7.free.fr/madVR_OSDfilename_disabled_crash.zip). Could you check if anything strange is going on on madVR side that explains the crash?

[6233638]

I've checked test patterns with an "empty" 3dlut and found pretty much zero changes, when turning the 3dlut on/off. If you have a reproducible test case with an "empty" 3dlut (meaning a 3dlut which doesn't actually change anything), causing discoloration/banding, please let me know and help me reproduce the problem.Right, there are no problems with an "empty" LUT, it's once you start making changes—particularly at the lower end of the greyscale—that problems arise.

No, it does not. Please look up "dithering" and how it works.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.

Can you please clarify which exact bitdepth you're talking about? E.g. there is the bitdepth you feed into the 3dlut, then there is the 3dlut input bitdepth, then there is the 3dlut output bitdepth, and then there is the HDMI transport bitdepth. You can't just talk about 8bit without specifying which exact bitdepth you mean. In the madVR processing chain there are 3 different bitdepths which could be described as "output" bitdepth.I mean that what the video card is sending to the display is 8-bit, which is a lossy process.

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.

[madshi]

Cant say for sure, cause looking better is kind of an subjective argument/feeling. But i have the feeling it did. Simply because i could turn of dithering in JanWillems build (or set it the lowest random setting), and outputting the 10-bit video to my receiver, wich in turn does 'its thing' using a Reon-VX video processor. Image seemed to be clearer, having more 'color-fidelity'. But as i said: This is subjective to be sure, i have to do some comparison between the two.
If you do compare again, please compare madVR to both the 8bit and 10bit output of JanWillems build. Would be curious to here your impressions.

"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.
If deinterlacing is the only reason to go NVidia, then I would suggest to wait a bit. Deinterlacing is quite on the top of my to do list. Maybe I'll find a good solution for ATI. Or maybe not. At least I'm going to try...

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?
I guess I could add this information to ctrl+J.

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.
True. Couldn't think of an intuitive way to disable gamma processing again via the existing shortcuts.

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?
You could try writing "1080p50, 1080p59" into the madVR display mode edit box. Or maybe "1080p50, 1080p60". That should probably do the trick. Ehm, of course only if your display is 1080p. If it has a different resolution, you have to adjust the mode list accordingly, of course.

madshi, do you have any plans on adding colour controls(contrast, brightness, saturation, hue) to madVR?
Yes, but it's not high priority.

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) :D
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 (http://videoff7.free.fr/madVR_OSDfilename_disabled_crash.zip). Could you check if anything strange is going on on madVR side that explains the crash?
Unfortunately logs don't really help with madVR crashes. Is there a simple way I can reproduce the crash?

Right, there are no problems with an "empty" LUT, it's once you start making changes—particularly at the lower end of the greyscale—that problems arise.

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.

I mean that what the video card is sending to the display is 8-bit, which is a lossy process.

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'm a bit confused now, though. Which is the exact reason for the banding and discoloration in your opinion? Originally you said "There is a very noticeable drop in quality when using 3DLUTs". So you were saying that the 3dluts are at fault. Now you're saying that the dithered down madVR 8bit output is at fault. These are 2 very different things which have *nothing* to do with each other. madVR always dithers down to 8bit output, regardless of whether you use a 3dlut or not. So if the dithered down 8bit output is the problem, what does the 3dlut have to do with anything? And the other way round: If you say that the problem does not occur with an empty 3dlut, then obviously the dithered down 8bit output cannot be the problem, because even with an empty (or even with disabled 3dlut) madVR still outputs dithered down 8bit. You gotta make up your mind where the discoloring and banding problems are coming from. Is it the 3dlut? Or is it the dithered 8bit output? Two totally different and separate things, which have nothing to do with each other.

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.
Dithering is even used for 1bit images, where the only two available shades are black and white. And still dithering works. (Of course the noise levels are extremely high with 1bit images.)

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.
So the LUTs themselves were 8bit or 10bit? That's a *totally* different situation. No dithering is used in that case. Of course the difference between 8bit and 10bit is dramatic in that case. I would say that even a 10bit LUT is not precise enough. madVR uses 16bit LUTs and dithers the output down to 8bit.

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.

And with 8-bit LUTs
Who's using 8bit LUTs? madVR is using 16bit LUTs!

[jmone]

Hi Madshi, any comments on these two observations? http://forum.doom9.org/showthread.php?p=1531792#post1531792
1st Issue: madVR Windowed mode = Lip Sync issues on 23.776/24hz
2nd Issue: "Exclusive Mode Failed"

Thanks
Nathan

[madshi]

1st Issue: madVR Windowed mode = Lip Sync issues on 23.776/24hz (the video is delayed so the sound come first)

There is no issue with:
- EVR
- madVR Exclusive mode
- madVR Windowed mode at 50hz or 60hz

I've tried different combinations and the following make no difference to the lipsync issues:
- Decoding Vs Bitstreaming
- Video Clock on or off
- Normalize vol on or off
- HW Accell on or off (eg CUVID vs FFDSHOW)
- madVR Settings of "delay playback start until render queue is full" on or off
- madVR Settings of "use a separate device for presentation"
- Pause/Play or a Seek makes no difference - it is consistently out
- Disabling auto refresh rate changes
- Manually pre changing refresh rates

My only conclusion at this stage is that it is madVR Windowed mode that delays the video when the refresh rate is at 23.976/24hz ...unless there is other suggestions on what to try.
Can you cross check this with a different media player? What happens if you turn Aero on/off? Currently I don't see how madVR could be reponsible for this. madVR does not have any special code in it for 23.976/24.000Hz handling. It doesn't really matter to madVR whether the refresh rate is 24Hz or 240Hz. So I don't see how there could be a lipsync problem with 24Hz when there is none with higher refresh rates.

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.

[madshi]

Play this clip (http://www.mediafire.com/?k5cxvct47z5t19y) for example, got more if you want them. ffdshow configured as: YUV spec auto, input levels auto (or standard, it's the same), output levels PC. LAV Video is wrong with any sample. When playing fraps recorded files "AVI Decompressor (FPS1)" outputs RGB32 and connects with madVR, but the screen is black.
This will be fixed in the next build. Furthermore, RGB input with unknown range will now be treated as full range by default.

[6233638]

I'm a bit confused now, though. Which is the exact reason for the banding and discoloration in your opinion?Perhaps I'm making things too complicated.

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)

[madshi]

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 my best knowledge the VideoEQ Pro is not able to dither. So you're working with *rounded* 8bit or 10bit values. If you work with rounded (or truncated) data, of course every bit more makes a dramatic difference. 10bit really is *much* better than 8bit, when no dithering is used.

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.
The problem is that you don't have an 256x256x256 3dlut with the VideoEQ box, AFAIK. How many control points do you have? Probably *much* less than 256x256x256. So if you change one value, you don't affect a specific brightness step. You change much more, due to the necessary input interpolation. Add to that that no dithering is used (AFAIK). You cannot compare that to madVR. That's a whole different situation.

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.
Hand tuning a 3dlut can only work if you have a limited number of data points. How many data points do you have with the VideoEQ box? With madVR, if you wanted to hand tune the 3dlut, you'd have to play with 256x256x256 data points! You'd need decades to wade through such many data points. The number of data points is simply too big for you to edit them one by one. You could play with the measurement data you feed into yCMS, though.

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.
Did any of those boxes meet madVR's specs, which are:

- 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.

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
It's not lossless, the dithering raises the noise floor. But there should be no added banding and no discoloration.

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.

[madshi]

madVR v0.75 released

http://madshi.net/madVR.zip

* 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
I'm not sure whether I should recommend to activate the linear light scaling option or not. Please check it out and let me know what you think. It should be somewhat slower. From what I could see, if looks a bit better when downscaling by a large factor, but for upscaling I couldn't see much of a difference. Furthermore, with linear light scaling activated, I could see more halos, when using Lanczos. So make up your own mind. I'd be interested in your opinion about how it looks. And also how big of a performance drop you're seeing.

@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.

[G_M_C]

If you do compare again, please compare madVR to both the 8bit and 10bit output of JanWillems build. Would be curious to here your impressions.
[...]


I'll try to set it up so that i can switch between the two renderers and its possibillities. I'll let my GF comment/choose which looks best, ehhh ... sorry let my GF TRY to choose between them.

[Guybrushtx]

I have a problem with madvr 0.75:
Every time I close MPC HC (1.5.2.3456), program crashes.
With 0.74 everything goes well.
Could you please verify?

[kerimcem]

I have a problem with madvr 0.75:
Every time I close MPC HC (1.5.2.3456), program crashes.
With 0.74 everything goes well.
Could you please verify?

and exul. seek bar not see:(

[fastplayer]

Thanks for 0.75, madshi! :)
Unfortunately, MPC-HC (rev 3785) crashes when closing it. No such issue with 0.74.

[RyaNJ]

I have a problem with madvr 0.75:
Every time I close MPC HC (1.5.2.3456), program crashes.
With 0.74 everything goes well.
Could you please verify?

I can confirm this.

[Nevilne]

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.

[JaylumX]

I can confirm this.

Same here. Also some of my videos do not have the seek bar

[Fadeout]

Yes, two problems: crashes on exist and no seek bar. The second in particular needs fixing.

I also have another problem carrying over from previous versions: when I exit exclusive mode the player window misses the close button and I have to close through the menu.

[naoan]

Also crash if you drag another video while mpc-hc still playing.

[nand chan]

madVR v0.75 released

* subtitles run through the 3dlut now, too
* 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

Awesome, now all we need is a 64-bit build and 10-bit output and we are good to go again!

[TheShadowRunner]

Thanks for the new build!
Report:
On ZP, 0.75 doesn't crash on exit but madVR's own OSD has become gigantic in fullscreen mode and minuscule in windowed mode. (when it indicates windowed/exclusive)
Also ZP's "Display OSD through madVR's API" is now broken = ZP's control bar / OSD don't show up at all anymore in fullscreen when displayed via madVR's API.

As for the (ZP) bug which makes ZP slow/freeze on seek when "Display OSD through madVR's API" is disabled and a frequency switch occurs, it is still there. The madVR crash when "show OSD filename when opening a new file" is disabled is still there too, but the address has changed.
With 0.74, crash in madVR.ax module at address 0x00004770
With 0.75, crash in madVR.ax module at address 0x000047b0

Hope it helps, somehow ^^;;

[Boltron]

Crash for me also when I exit. On Win7 x64, MPC-HC>LAV Filters>madVR.

[THX-UltraII]

i can tell ya that madvr with lav decoder is deffo a good combination and im using an ati 5670 graphics card, very smooth indeed no frames been dropped

I don t think it will make any difference when using a 4550, 5670 or even a higher end ATI card because the GPU of the ATI is not beeing used because madVR and LAV video decoder both do not support ATI hardware decoding. That s why I got the 5450.

atm I m thinking about switching to a NVIDIA card. This way I can use CUVID in LAV Video Decoder and reduce my CPU usage (because I want to use SVP with high settings http://www.svp-team.com/wiki/Main_Page)

[6233638]

To my best knowledge the VideoEQ Pro is not able to dither. So you're working with *rounded* 8bit or 10bit values. If you work with rounded (or truncated) data, of course every bit more makes a dramatic difference. 10bit really is *much* better than 8bit, when no dithering is used.Correct, and I agree, the dithering improves the results considerably... but I would still like to be able to tweak the pre-dither (or no-dither) results to perfection, and look forward to when I can get 10-bit sent to the display.

This is one of the reasons I got rid of the VideoEQ though—that and the completely broken CMS.

I've also had a Lumagen Radiance XE (overpriced junk) and iScan Duo, neither of which has stayed in my system too long either. I think the iScan lasted the longest, as it had some unique features that were quite useful back when I was still using stand-alone devices for media playback.

The problem is that you don't have an 256x256x256 3dlut with the VideoEQ box, AFAIK. How many control points do you have?You had 10-bit control for greyscale/gamma (three 1024-point 1D LUTs) and matrix controls for the CMS from what I remember.

I'm not trying to compare it to what madVR is doing though, just explain why it was much easier to get the results I wanted with it, and why I look forward to 10-bit output.

Hand tuning a 3dlut can only work if you have a limited number of data points. How many data points do you have with the VideoEQ box? With madVR, if you wanted to hand tune the 3dlut, you'd have to play with 256x256x256 data points!I'd probably work with 10, 20 or 100 points, time permitting, or possibly 10 points plus touch-ups where necessary. (fix any obvious errors) I realise it sounds like this goes against "hand-tuning" the LUT if you are letting the rest of the points be interpolated, but I'd prefer some sort of control rather than tell madVR what my display currently measures and hope it all turns out OK in the end.

It's not just greyscale though, I'd love to be able to hand-tune 25/50/75/100% saturation for RGBCMY to make sure that the response is linear—I'm not sure that my display is when put into the "wide gamut" mode. (necessary to cover BT.709 gamut as it's a white LED display) Haven't had a chance to actually measure it and check for linearity yet.

You could play with the measurement data you feed into yCMS, though.Right, but then I feel like I'm basically guessing—yCMS only accepts XYZ or xyY data, right?

I suppose the simplest way to put it, is I just want to give it:
100%: 254,234,245
90%: 230,225,240
etc. and have it fill in the rest. (ideally this would be 10-bit though...)


Did any of those boxes meet madVR's specs, which are:

- 256x256x256 data points
- 16bit output
- ditherNo, this is the reason they didn't stay, and why madVR has replaced all stand-alone devices connected to my TV.

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.The main part of the problem isn't even madVR itself. (though I'm still not entirely convinced about 8>16>8 avoiding possible colour shifts near black when making gamma changes)

The problem is that you cannot disable a modern display's own internal LUTs/Processing, and have it display exactly what you send it. To get the best results, you're basically fighting against the display.

I feel that if you had used one of these external LUT boxes, you would immediately understand the problem, and I'm really not doing a good job of explaining it.

When tweaking with the VideoEQ, it was not uncommon to see things such as this:Pass|Output Value|Relative R| G | B
1 | 64, 64, 64 | 105% | 100% | 98%
2 | 62, 64, 66 | 104% | 100% | 99%
3 | 60, 64, 67 | 103% | 100% | 99.2%
4 | 58, 64, 68 | 103% | 100% | 99.4%
5 | 56, 64, 70 | 101% | 100% | 102%
6 | 55, 64, 69 | 099% | 100% | 101%10-bit precision helped dial in the results better, and the reason you have things jumping several steps at once sometimes is because you're essentially fighting against the display's internal processing to get the result you want from it.

Sometimes changing one of the output values from the LUT box would not make a change on the display, and sometimes making a single digit change would have it jump 2-3%.

This is why I don't believe that you can get the best results from a calculated LUT compared to one where you are telling it at least a portion of what things need to be to help get the best out of your display and tweaking the results where problems occur the most. (you might do 20-100% in 10% steps, 5-20% in 5% steps and manually tweak 1-5% individually for example)

added option to scale Luma in linear light:D Is there a reason why this is only for Luma? I look forward to trying it out.

This will hopefully be seeing a lot of use from me shortly, as I'll soon be downsampling everything to 720p once Sony launches the HMZ-T1.

I can confirm the MPC-HC crashes other people are reporting.

[Gaius]

I don't have a crash on exit, but I do have exclusive mode turned off, and I don't use a separate device and I have all the "trade quality for performance options" checked.

[Boltron]

Crash happens with and without exclusive mode for me.

Problem signature:
Problem Event Name: APPCRASH
Application Name: mpc-hc.exe
Application Version: 1.5.3.3757
Application Timestamp: 4e94a9c2
Fault Module Name: StackHash_6c74
Fault Module Version: 6.1.7601.17514
Fault Module Timestamp: 4ce7ba58
Exception Code: c0000374
Exception Offset: 000ce653
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 6c74
Additional Information 2: 6c74644f2a776d4eebd8a21e66ac538c
Additional Information 3: a883
Additional Information 4: a883ebc5ad391b943d97848a87e3b702