madVR - high quality video renderer (GPU assisted)

[Warner306]

Originally Posted by svengun

Is Florian the same person as Soulnight / Flo ? (From AVS thread: improving-madvr-hdr-sdr-mapping-projector)

No, not the same person.

[hannes69]

Originally Posted by hannes69

Do you refer to the ntoskrnl latency spikes in 1903 or something else?
I have these spikes higher than everything I´ve seen in the net, once up to 60 ms (yes, ms not µs) and since 1903 I have often repeated frames (let´s say 5-10 during one movie) when I had zero all the time in 1809. Sometimes no drops or repeats, sometimes repeats and the audio clock goes wacky, sometimes a repeat followed by a drop in a short time and so both numbers rising slowly, sometimes 50 drops and/or repeats at once, sometimes presentation glitches. Absolutely none of these symptoms in 1809.
[...]
Sometimes the audio clock ('clock deviation' in madVR OSD) jumps to a different value during playback and stays there, sometimes this repeats multiple times during playback. Normally I have a value in the region of -0.00220%. Then a repeat is shown and the clock jumps to a different value, let´s say -0.00310%. And this is not only shown, it is really the case: The drop/repeat time is adapted and to the predicted time a repeat occurs (shown in OSD and really the case).

UPDATE regarding this topic:
Windows update KB4505903 (build 18362.267) eliminated ALL of the described problems. In the meantime I´ve watched 4 full length movies, 0 drops, 0 repeats, 0 presentation glitches (after the initial ones at movie start), stable audio clock. At the same time DPC latency for ntoskrnl.exe dropped from up to 60ms down to <1ms.
Everything is working now as expected and like Windows 10 1809.
In the future I will postpone the major functional Windows updates and wait for feedback from others.

[el Filou]

Originally Posted by Asmodian

madVR does not report a drop when it presents a video frame for 4 screen updates instead of 5. At 120Hz with 24fps video you never need to actually drop or repeat an entire frame so you never see a drop/repeat due to timing inconsistencies. This is even true when watching on a 60Hz display

That's interesting, I never thought about that. So it means you could possibly have stutter when watching, say, 30p content on 60 Hz or 25p content on 50 Hz and not see it confirmed by the OSD? If that's the case, would it be possible (@madshi) to add a 'late presented frames' stat to the OSD?

[brazen1]

Originally Posted by fourbigkids

Hi all.

I am running MPC-BE v.1.5.3 with madvr 127.0.0.1 on a Windows 10 HTPC with an Nvidia RTX 2060. The video is fed via HDMI to a pre-pro and then to a Sony TV XBR85X850F. It can also be fed directly to the TV. I have madvr setup to open full screen and to change the refresh rate of the TV to match the video file. This works fine about 50% of the time. For the other 50% the video opens and plays as expected, full screen and with the adjusted refresh rate, but the menu bar is not available when placing the cursor at the bottom of the screen and right clicking does not open the context menu. There is no way to control playback when this occurs. However, if I double click on the video on screen to 'restore down', taking the application out of fullscreen mode, the menu bar and context menus return. Once the fault occurs it then keeps happening on each successive file until I reboot the computer. It then plays as expected for a random period of time and/or playback of a random number of files.

There does not seem to be any common characteristics in the files that this fault occurs. Could be anything, an .avi, .mp4, or mkv etc. But next time they could play faultlessly.

Has anyone encountered this sort of behaviour before and managed to resolve it?

Appreciate your advice.

Cheers,

Allan.

ps. Could you please let me know if this is better dealt with in another thread. a

You could also check madVR setting Rendering/Exclusive mode/Show seek bar.

[Asmodian]

Originally Posted by Manni

Their implentation has been set in stone for a few years and getting any bug fix/change/improvement from either is like pulling teeth.

DisplayCAL is a great option but Calman did update their madVR support recently, it is much better now and supports creating a 3DLUT for all SD content options.

HDR support is better too, but Calman still does not support creating a HDR 3DLUT for madVR, unlike DisplayCAL/Argyllcms.

[Manni]

Originally Posted by Asmodian

DisplayCAL is a great option but Calman did update their madVR support recently, it is much better now and supports creating a 3DLUT for all SD content options.

HDR support is better too, but Calman still does not support creating a HDR 3DLUT for madVR, unlike DisplayCAL/Argyllcms.

AFAIK there hasn't been any update to Calman re madVR recently, except the fixed .dll in madVR to correct the bug in madTPG that caused a corrupted DCI-P3 LUT and it took me MONTHs to get them to do it (and it was a simple file swap in the installation package). Calman has always been able to recalculate from a single profile and upload a different LUT for all SD content options (P3, BT2020, NTSC, PAL and Rec-709) since the first implementation of madVR in Calman years ago so I'm not sure what you're refering to. I've never done it but I think you can create an HDR 3DLUT if you use their BT2390 implementation, though it's not as flexible as in DisplayCAL or Lightspace. Of course it's not relevant if you use dynamic tonemapping.

[Asmodian]

I suppose it depends on how recent is "recently". I thought it was Calman 2019 that had an update that improved the integration? The first version I used could only assign a 3DLUT to BT.709, you could create any 3DLUT but I needed to rename the 3DLUT and manually assign it in madVR or it would just overwrite the same 3DLUT everytime. Maybe it was an update sometime in 2018 and I am misremembering it.

DisplayCAL and madVR really do work well together though, Argyllcms keeps getting better and better too so that is a very good workflow now.

Thanks for getting Calman to fix that dll!

[Manni]

Originally Posted by Asmodian

I suppose it depends on how recent is "recently". I thought it was Calman 2019 that had an update that improved the integration? The first version I used could only assign a 3DLUT to BT.709, you could create any 3DLUT but I needed to rename the 3DLUT and manually assign it in madVR or it would just overwrite the same 3DLUT everytime. Maybe it was an update sometime in 2018 and I am misremembering it.

DisplayCAL and madVR really do work well together though, Argyllcms keeps getting better and better too so that is a very good workflow now.

Thanks for getting Calman to fix that dll!

You might have missed it before but the ability to select the calibration slot in which to upload a 3D LUT was there from the beginning. I know because I was the one who pushed Spectracal to support madVR and I worked with madshi, Joel and Stacey to help test the initial implementation. It really hasn’t been updated since in any significant way, certainly not since Joel and Stacey have left.

[fourbigkids]

Thanks brazen1 and Warner306. Will check and report back. Cheers, Allan

[chros]

Originally Posted by Manni

I know because I was the one who pushed Spectracal to support madVR and I worked with madshi, Joel and Stacey to help test the initial implementation. It really hasn’t been updated since in any significant way, certainly not since Joel and Stacey have left.

Well done, Manni, and thanks for the insight!

[Gary.M]

Originally Posted by svengun

Hi Asmodian,



as I understood it , there a several software programs to achieve creating a 3D LUT . (my intent is to use this 100% just for MadVR)



My question was, which program achieves the best result for that. Calman studio (with or without using MadVR TPG) , or another program like LightSpace. If there isn't much difference in regards to quality , then maybe there is in terms of friendly to use (not a huge learning curve)

I understand that displaycal and lightspace are the best, Calman less so. There is a comparison out there somewhere. Maybe Ted of display calibrations has it on his site.

Sent from my MI 8 using Tapatalk

[Manni]

Originally Posted by Gary.M

I understand that displaycal and lightspace are the best, Calman less so. There is a comparison out there somewhere. Maybe Ted of display calibrations has it on his site.

Sent from my MI 8 using Tapatalk

Ted is very knowledgeable and a real asset to the calibration community, but he sells Lightspace for a profit, so unfortunately his comparisons are not always unbiased. Plus he doesn’t use or know much about madVR. Neither does Steve (Lightspace). Florian (DisplayCAL) knows madVR inside out, and that really helps when there is an issue that needs correcting.

Regarding specifically madVR support, Lightspace is the worst of the three, by far.

LS has many bugs that Steve refuses to correct, for example it happily uses the wrong levels for a 3D LUT (madVR requires video levels LUTs, LS will happily generate PC levels LUTs for madVR which are simply invalid). Neither Calman nor displayCAL allow this because unlike LS they follow the madVR specs. Worse, because of this bug, you have to manually apply one of four video filters (it depends on your setup which one is the correct one) every single time after generating each LUT because Steve refuses to correct this, or at least allow the user to select which filter to apply automatically, given that it will always be the same filter if you don't change the video chain/levels. Even after I reported the issue, and madshi confirmed the issue to Steve, this has not been corrected, and it was a year ago!

LS also has a poor interface with madVR, forcing you to manually enable/disable the LUT in madTPG (after manually disconnecting the link between LS and madTPG, and re-enabling it afterwards!). You never know if a LUT is enabled or not in the software itself, etc. Sure, you can reset a LUT, but if you want to check an existing calibration, it’s just really cumbersome and error-prone, vs the simple enable/disable LUT checkbox in Calman. LS doesn’t remember the madTPG IP address either, so you have to specify it every single time, eventhough it’s the same one (Calman not only saves it but, like DisplayCAL, it detects it automatically on the network if not saved).

LS also has the steepest learning curve, in general and regarding madVR specifically due to all these bugs/issues/quirks/poor interface. It’s extremely easy to get a poor madVR calibration with LS if you’re not aware of all the steps you have to perform manually to get good results. I hope it will change, but as many madVR users seem happy to use invalid LUTs generated by Lightspace or go through an incredibly convoluted process to generate valid ones, it’s unlikely to happen.

Everytime I report an issue with madVR to Steve, I’m told I’m the only one with that issue, and it’s not corrected. It also took me months to get Steve to replace the fixed madVR .dll in the Lightspace installation package, because “no one complained about corrupted DCI-P3 LUTs before”. Unbelievable! I don’t know how many madVR users use Lighspace, and who beta tests for Lighspace re madVR use, but the least I can say is that I’m not impressed. Again, there has been zero improvement in madVR support in Lightspace since the initial implementation years ago, so I have given up on seeing any progress in this area.

Finally pre-cal and post-cal reporting in LS is abysmal, especially compared to Calman which is miles ahead of it in this area. Even if I used LS to generate a LUT, I would still use Calman (or any other software) to do pre and postcal measurements, as would most other users. This is especially the case if I want to share the measurements with non-Lightspace users.

As long as it stays as it is, I won’t recommend LS for madVR use when DisplayCAL and Calman do as well or better results-wise are so much easier to use with madVR. LS is a very good 3D LUT generation tool, and if you know all the quirks re madVR use you can get excellent results with it, but it’s definitely the last software I’d recommend at this stage for madVR use due to all these issues, especially given the price.

[svengun]

Originally Posted by Manni

Regarding specifically madVR support, Lightspace is the worst of the three, by far.

You've convinced me, I will go for DisplayCAL

Many thanks for your detailed advice

[svengun]

Quote: Nvidia has reported on Siggraph that it is now bringing support of 10-bit per color channel under OpenGL with the new Studio Driver 431.70 WHQL to its Geforce and Titan series graphics cards.

just read it on hardware.info

[nevcairiel]

Originally Posted by svengun

Quote: Nvidia has reported on Siggraph that it is now bringing support of 10-bit per color channel under OpenGL with the new Studio Driver 431.70 WHQL to its Geforce and Titan series graphics cards.

just read it on hardware.info

And noone here cares, because Direct3D has had 10-bit support for years, and madVR does not use OpenGL at all.

[svengun]

Originally Posted by nevcairiel

And noone here cares, because Direct3D has had 10-bit support for years, and madVR does not use OpenGL at all.

Oh ..my bad

[huhn]

madVR is directx which even supports 16 bit rendering.

BTW. about 3d LUTs there are still bugs no one want to fix about it forcing me to use a custom shader to do it myself.

argyllCMS 3d LUT can'T deal with out of gamut values but they don'T clip them but madVR creates a lot of out of gamut values when chroma scaling that's totally fine BTW. but neither madshi nor displaycal wanted to fix that issues.

if you want to read about it: http://bugs.madshi.net/view.php?id=424

BTW: the last time i check it was stated that a 3d LUT shouldn't get out of gamut values and madshi thinks a 3d LUT should be able to handle them.

[Alexkral]

It seems to me that it's a madVR issue, and it should not be very difficult to fix. As you say, it has been stated that this is how 3D LUTs work, and you have already seen that it is solved simply by clamping the values.

[chros]

Originally Posted by svengun

as I understood it , there a several software programs to achieve creating a 3D LUT . (my intent is to use this 100% just for MadVR)

It will be a bit complicated than that (I wanted to find my previous post about this but I couldn't):
- basically, since both of your Philips 65OLED803 and LG OLED EG920V TV are HDR capable, you want to passthrough the HDR content to them
- meaning you can't use external 3dlut with hdr content!
- you can only use external 3dlut with SDR content

I'm not sure whether recent Calman (autocal) supports Philips TVs for creating 3dlut (I'm sure it won't support the older LG), so that means you can go for DisplayCal straight away, the process is easy.

PS: and I'll send you a PM.

[el Filou]

Originally Posted by chros

Basically, since both of your TVs are HDR capable, you want to passthrough the HDR content to them
- meaning you can't use external 3dlut with hdr content!
- you can only use external 3dlut with SDR content

What's the use case for the "tone map HDR using external 3DLUT" madVR option, then?