madVR - high quality video renderer (GPU assisted)

[daglax]

If you designate your projector as such, you get "Screen Config" options. I believe this should do what you want in conjunction with profiles and the "Crop Black Borders" option in Zoom Control.

And how does this work? Couldn't find any information about that feature at all.

Here is a quick explanation of what i wanna do:
My masking reduces the screen size to the most common aspect ratio these days: 2.4:1. Only the upper side of the screen is masked, so i need to movethe image to the bottom of the screen, which is no problem for madvr. The problem is, that there are movies with an asprect ratio of 2.35:1 an i want to crop the extra pixels to perfectly match my masked screen.

I don't know, if madvr has an option for this.

[jmonier]

And how does this work? Couldn't find any information about that feature at all.


In settings, go to devices and select your projector. Then make sure "Digital Projector" is selected. Once this is done you should have a 6th selection under your projector that says "screen config" that has "define visible screen area by cropping masked borders".

Frankly, I think the only tricky part about it is making sure that your projector is defined as such so that the 'screen option' appears. After that, everything else seems quite obvious.

[Asmodian]

I don't have a settings.bin either. I don't think this file exists.

I have always had a settings.bin file even when installing to program files with Win10. I am using an administrator account but UAC is set to default. I have backed it up and restored madVR's settings with it too.

It's been suggested to me to turn off the DVI Dithering on my AMD card. Should i or shouldn't i? Does the dithering restrict the color gamut?

Only turn off dithering for testing, never for normal use. Dithering does not restrict the color gamut. What does dithering have to do with the color gamut?

[daglax]

Is there an option in the madvr script language to activate profiles based on the active display?
For example:
if (device = Samsung XY) "profile1" else "profile2"


@jomnier
Thanks that did help! I needed to adjust a video playback option in MPC-HC and then it worked!

[feisty2]

@madshi
http://forum.doom9.org/showthread.php?t=173005
could this be implemented real time in madvr so I don't have to go re-encode all my videos to 4:4:4?

[GameGod]

Forgive me if this has been asked and answered before. I did a search, but couldn't really find an answer.

The issue I'm having is that the mouse cursor always shows up in the center of the screen for a few seconds when play back starts up, which is kind of annoying.

I tried moving the cursor off screen before starting play back but that doesn't seem to help.

Is this a known issue? Is there anything I can do to avoid this from happening?

Spec:
MadVR 0.89.17 on Win 7 x32.
Nvidia GTX 950, with 358.87 drivers.
Zoom Player Pro 10.

Thanks.

[TobiMan]

The issue I'm having is that the mouse cursor always shows up in the center of the screen for a few seconds when play back starts up, which is kind of annoying.


That's odd, as ZoomPlayer hides the cursor more reliable than other software, at least for me. There's an option in ZoomPlayer ->Interface ->Mouse -> Hide the mouse cursor (at the top)... maybe you can adjust the seconds?

[huhn]

@madshi
http://forum.doom9.org/showthread.php?t=173005
could this be implemented real time in madvr so I don't have to go re-encode all my videos to 4:4:4?

if I see this right this is not a shader.
and bilateral and superres(not sure of the current version) try to do the same.

[StinDaWg]

Is there anything I can do to improve the awful clock deviation on my AMD 7850? It seems no matter what settings I change (and I've tried them all), I always get at least 1 dropped or repeated frame during a 2 hour movie and it's really jarring. Video micro-stutters and the audio makes a loud glitching noise. It will fluctuate between 1 frame repeat every couple hours or sometimes days, but then will sometimes drop into the minutes for no rhyme or reason.

I'm about to throw this card out the window because I don't remember having these problems when I had a GTX 960.

[huhn]

the issue could be the audio renderer too. I mean you get audio glitches.

and if you want to get an 960 for a better video clock than i have to say you without a custom resolution you are more than lost.

[feisty2]

if I see this right this is not a shader.
and bilateral and superres(not sure of the current version) try to do the same.

It's different from super res, kind of similar to bilateral but not the exact same thing, bilateral could constantly produce both magic and garbage, that filter almost never produces garbage (because of super sampling and low frequency protection)

[StinDaWg]

the issue could be the audio renderer too. I mean you get audio glitches.

and if you want to get an 960 for a better video clock than i have to say you without a custom resolution you are more than lost.
I'm using the default windows directsound renderer. It only glitches at the same point that the video drops/stutters. I've also tried Reclock and the same thing happens.

I used to have a 960. Used custom resolution and never had any of these issues.

I see AMD released 15.12 drivers with custom timing option so I will play around with that.

[Asmodian]

Is there anything I can do to improve the awful clock deviation on my AMD 7850? It seems no matter what settings I change (and I've tried them all), I always get at least 1 dropped or repeated frame during a 2 hour movie and it's really jarring. Video micro-stutters and the audio makes a loud glitching noise. It will fluctuate between 1 frame repeat every couple hours or sometimes days, but then will sometimes drop into the minutes for no rhyme or reason.

I'm about to throw this card out the window because I don't remember having these problems when I had a GTX 960.

I would use Smooth motion.

[XMonarchY]

Will FilmGrain effect ever be added to madVR? From what I understand, it partially acts as semi-dithering, but mostly enhances perception of image detail. It could be a useful effect!

[GameGod]

That's odd, as ZoomPlayer hides the cursor more reliable than other software, at least for me. There's an option in ZoomPlayer ->Interface ->Mouse -> Hide the mouse cursor (at the top)... maybe you can adjust the seconds?

I tried this, and a few other settings but the cursor still shows up and then disappears. The only option that works is ZoomPlayer -> Interface -> Mouse -> Settings -> Always disable mouse cursor, but then the cursor is never shown when invoking the context menu, etc.

You don't see this issue at all? The cursor never appears in the middle of the screen for you? Do you use the display mode switching feature?

Thanks.

[ryrynz]

Will FilmGrain effect ever be added to madVR?

I think this has a particularly high chance of happening before 1.0.

[MS-DOS]

I'm using the default windows directsound renderer. It only glitches at the same point that the video drops/stutters. I've also tried Reclock and the same thing happens.

I used to have a 960. Used custom resolution and never had any of these issues.

I see AMD released 15.12 drivers with custom timing option so I will play around with that.

Does your GPU clock go up and down while you're watching ? If so, then you may want to try this (http://forums.guru3d.com/showthread.php?t=404465) utility.

[Kranium]

You don't see this issue at all? The cursor never appears in the middle of the screen for you? Do you use the display mode switching feature?

Thanks.

I paid attention while watching last night and mine also leaves the pointer visable for a few seconds when loading a file in MPC-HC/madVR so maybe it's not the player. I wouldn't be surprised if this was Windows fault in the hand off for exclusive mode, but I'm no expert. Just confirming you aren't alone ;)

[GameGod]

I paid attention while watching last night and mine also leaves the pointer visable for a few seconds when loading a file in MPC-HC/madVR so maybe it's not the player. I wouldn't be surprised if this was Windows fault in the hand off for exclusive mode, but I'm no expert. Just confirming you aren't alone ;)

Thanks. On another forum, the thinking was that it was somehow related to Logitech products and display rate switching. I have a Logitech K400 Plus and use MadVR to switch the refresh rate.

Does that apply to you as well?

[Kranium]

Thanks. On another forum, the thinking was that it was somehow related to Logitech products and display rate switching. I have a Logitech K400 Plus and use MadVR to switch the refresh rate.

Does that apply to you as well?

I do have a logitech TK820 and if I watch a 24p Bluray there would be switching since my desktop is at 60hz. I can try turning off the setting in madVR to switch the rate to match the source (in "Display Modes" section). I can also close the logitech systray application that controls things like pointer speed and gesture support.

[GameGod]

I do have a logitech TK820 and if I watch a 24p Bluray there would be switching since my desktop is at 60hz. I can try turning off the setting in madVR to switch the rate to match the source (in "Display Modes" section). I can also close the logitech systray application that controls things like pointer speed and gesture support.

I don't have any of the Logitech software installed, so would be curious to see if the problem goes away if the refresh rate switching is disabled.

I'll try it and report here as well.

[Manni]

Hi Madshi,

I have done some tests with the new HDR feature in MadVR, and it seems to be working very well, emulating HDR playback on a non HDR display (a JVC X500 in my case). It worked equally well on an X7000 which is HDR compatible, in fact the difference between the two units once brightness matched and both calibrated to P3 was minimal, even though the X500 only reaches about 90% of P3 while the X7000 with its P3 filter covers about 98% of it.

While the peak white my JVC X500 is able to produce is only around 110nits in high lamp iris fully open with a P3 / D65 / BT1886 calibration, I found that selecting 120nits in MadVR or even 180nits led to a too bright result for mid-tones and raised black levels for low APL scenes. It looks like the most believable results are obtained using 265 or even 400nits.

Following our ongoing discussion in the Spectracal forums regarding HDR calibration, I have a few MadVR specific questions you asked me to re-post here, so here we go:

1) Do you plan to let the user specify which native gamut is active for each type of content? For example, for Rec-709, we would run a profile on a rec709 native gamut (so as not to waste brightness unnecessarily due to a P3 filter), and apply a MadVR 3D LUT for rec-709, which will be reprofiled into SMPTE-C and PAL slots. But for P3 or Rec-2020 calibration, we would select a different user mode, for which either no 3D LUT is necessary, or a different 3D LUT made from a different profile. At the moment, if we select no 3D LUT for P3, my understanding is that MadVR assumes the display is only rec-709 compatible, therefore converts P3 to rec-709, losing on the wider gamut. It looks to me that we need to be able to specify, along with the 3D LUT we want to use, to which native gamut this correction applies, especially if we have on the display a P3 mode that doesn't need a further correction (or that would need a very large LUT to improve on the native ability). It would also be needed to specify that we want to use a P3 calibration for true rec2020 content, so that the conversion is in that case made as you suggest (but not when we want to display P3 to P3).

2) Do you plan to add the ability to specify which user mode we want to select for each calibration, for the displays MadVR supports like the JVCs, so that we can assign for each calibration a specific user mode with the best gamut (and an optional 3D LUT to make it more accurate if necessary). So for example, we would have a rec709 gamut for rec-709, SMPTE-C and PAL in one user mode with 3 different 3D LUTs, and a P3 gamut for P3 and rec2020 in a different user mode, with a 4th 3D LUT (from a different profile, possibly using a filter) to improve the native gamut accuracy in P3 (or rec2020, when the discussion about which mode is best is settled).

3) Beyond the ability to specify a value for peak white, would you consider adding a variable for reference white as well, which could give us more flexibility to achieve the best results. For example, depending on the amount of brightness and contrast we have in reserve, we might want a reference white closer to peak white with a projector barely able to hit 120nits in high lamp in a dedicated bat cave with full light control, while we might want more specular highlights with a flat panel able to reach 1000nits for peak white in a living room with ambient light. If you want to simplify, we could have a projector mode similar to what dolby vision does in cinema, where reference white remains at 48nits but peak white is set to twice that (100nits), while UHD Bluray will likely offer content mastered to 700-1200nits with flat panels in living rooms in mind.

I'm of course talking here of situations where MadVR is doing the HDR to SDR conversion. From my understanding it looks like we are going to have to wait until Arctic Islands and HDMI 2.0a support to be able to use MadTPG for HDR10 calibration. For HDR compatible displays like the new JVCs, it might be good to have the option to use MadVR in pass-through mode and let the display do all the conversions (once we have HDMI 2.0a support in GPU drivers)?

However, if we are talking about using MadVR to display HDR content to a non HDR display, we should be able to use SDR patterns to calibrate to P3 (or Rec2020) and BT1886, and let MadVR do the rest, provided some changes are made in the software according to the above notes.

Happy New Year everyone, and especially Madshi who's worked hard on MadVR in 2015!

[markanini]

Anyone else experiencing slowdowns at seek with the new AMD drivers?

[DigitalLF]

Happy new year MadShi we thank you for all the great work in 2015. hope it has been a great one for you!

[Manni]

Just added a 3rd point to my post above regarding the HDR feature.

[Kranium]

I don't have any of the Logitech software installed, so would be curious to see if the problem goes away if the refresh rate switching is disabled.

I'll try it and report here as well.

I tried both things I had mentioned with no changes. If it doesn't change refresh rate I think the pointer went away a second faster but its still hanging around at video start like always.

[a8213711]

I had a crash and didn't have internet at that time to send it, so I'll upload it now here since I don't know where else I should! Sorry if it's not on topic nor a useful thing to do.
http://pastebin.com/ksvh4qEC
I remember I used NNEDI with way more neurons my system could handle (just for testing), but it was for just 1 second.
And happy new year!

[Ashaira]

Can someone help me understand some things regarding what madvr needs to work at higher settings.

Currently i'm using the madvr that comes bundled with the new SVP 4.0 and as far as i can tell it is a 32bit version along with the 32 bit version of media player classic.

I seem to have A LOT of frame drops as soon as i enable any of the slightly more demanding algorithms.

My specs are 3930k 3.8GHz (can push it to 5GHz but nothing has taxed it enough to warrant that), gpu 1 R9 280x toxic edition, gpu 2 7970 GHz edition, 16 gigs of 1866MHz ram, 3 4k screens.

Trying to play a 1080p video on a 4k screen. The settings for processing are default as those for rendering. For scaling i have nnedi3 32 for chroma upscaling, spline 3taps for downscaling, jinc for image upscaling, and for image doubling i have tried several but the best i could get was nnedi3 32 on quadruple luma with nothing on chroma.

as soon as i tried anything with double or quadruple chroma i start dropping frames even though my gpu utilization stays around 85% and cpu barely reaches 30% on rare occasions. I tried disabling svp to see if that was the cause but no effect as cpu still had a lot of room left and the gpu acceleration for svp is done on a different gpu.

I'm trying to figure out what the culprit is. Is the problem the madvr version that comes bundled with svp4.0? am i expecting too much from the software to push quadruple chroma on a 4k screen? is the gpu not enough despite it reporting only 85% utilization at most? Are my 3 screens to blame? maybe interfering with the resolution it's trying to render the movie at? Would it help if i moved my movies to my SSDs?

Any help would be greatly appreciated.

[Warner306]

Can someone help me understand some things regarding what madvr needs to work at higher settings.

Currently i'm using the madvr that comes bundled with the new SVP 4.0 and as far as i can tell it is a 32bit version along with the 32 bit version of media player classic.

I seem to have A LOT of frame drops as soon as i enable any of the slightly more demanding algorithms.

My specs are 3930k 3.8GHz (can push it to 5GHz but nothing has taxed it enough to warrant that), gpu 1 R9 280x toxic edition, gpu 2 7970 GHz edition, 16 gigs of 1866MHz ram, 3 4k screens.

Trying to play a 1080p video on a 4k screen. The settings for processing are default as those for rendering. For scaling i have nnedi3 32 for chroma upscaling, spline 3taps for downscaling, jinc for image upscaling, and for image doubling i have tried several but the best i could get was nnedi3 32 on quadruple luma with nothing on chroma.

as soon as i tried anything with double or quadruple chroma i start dropping frames even though my gpu utilization stays around 85% and cpu barely reaches 30% on rare occasions. I tried disabling svp to see if that was the cause but no effect as cpu still had a lot of room left and the gpu acceleration for svp is done on a different gpu.

I'm trying to figure out what the culprit is. Is the problem the madvr version that comes bundled with svp4.0? am i expecting too much from the software to push quadruple chroma on a 4k screen? is the gpu not enough despite it reporting only 85% utilization at most? Are my 3 screens to blame? maybe interfering with the resolution it's trying to render the movie at? Would it help if i moved my movies to my SSDs?

Any help would be greatly appreciated.

The culprit is most likely NNEDI3 image doubling, which requires a very powerful GPU for upscaling to 4K. Also, you would not want to quadruple the image from 1080p -> 4K because the scaling factor is only 2x not 4x. Try super-xbr100 as a performance comparison.

For more settings assistance, try one of the links in my signature.

[Asmodian]

Nothing is wrong, that is all a 280x is going to be able to do. You might try not using NNEDI3 for chroma upscaling to free up performance for doubling. 85% Utilization is pretty high, madVR starts dropping frame before it hits 100% utilization in my experience.

If you have crossfire enabled that would hurt madVR performance so disable it if you can.

[seiyafan]

Two years ago I tested with 290x and found that it would drop frames above 64 neurons, I also tested a 280x, unfortunately the fan noise just killed movie watching experience. Eventually I settled with a MSI 270x, performance may not be that great but it's quieter than a library.

Hopefully nvidia pascal can bring more power to the table.

[madshi]

the issue is that madVR isn't switching to 23p if possible and madVR isn't using smoothmotion at 60 hz with these sources.
Okay, so why does madVR not change the refresh rate to 24/1.001Hz or engage smooth motion (on a 60Hz display)? Forcing deinterlacing & film mode where it detects a 3:2 pattern on the clip seems to be the only way to get it to actually treat it like p23.976 content.
That is with forced film mode disabled, right? If the decoder says it's 30fps then madVR treats it as such, if forced film mode is disabled. I cannot possibly know whether it's a reliable soft telecine video file or not. It might be. Then I could switch to 23p and enable smooth motion. But it could also be true 30p, or 60i, or the video could switch back and forth between 23p, 30p and 60i all the time in the middle of the movie.

Files like this is what the "if in doubt activate deinterlacing" setting is meant for. Usually that setting activates deinterlacing for files like this, which is probably the right solution.

OSD upscaling works great, however the text is hard to read when height is less then ~630px or within the smallest OSD size range.
With small window/video sizes it's hard to choose a "good" OSD font. Either it's becoming very small and hardly readable. Or I pick a larger font, then parts of the OSD are cut off. Whatever I do, some problem is there.

Improving the anti-ringing of sharpen edges would be welcome. At 1080p -> 1080P, I like to use a small amount of sharpening to keep the appearance of the image consistent across all resolution profiles. I find sharpen edges looks the best when used alone because it doesn't alter image brightness, but it shimmers during panning scenes due to its ringing. It is really my last request after a year and a half of using madVR. Super sampling or another sharpening algorithm that resembles SuperRes would also be welcome.
Can you show a screenshot where the ringing is visible? Ideally a short video sample with which I could reproduce it? Improving the sharpening anti-ringing filter is on my to do list, but it's not too easy. We want to supress the ringing, but we want to allow sharpening, too. If I make the anti-ringing filter too strict, I might also remove some valid sharpening.

I agreed, supersampling is the best for sharpening.
This is why I still use avisynth at the moment.

@ madshi
I think it could be interesting to use upscaling refinement even without upscaling or add a similar option for post sharpening.
Maybe at some point in the future. For now just zoom into the image ever so slightly.

After that I turned back in madvr >> "color & gamma"

and I set brightness to +50.

When I set +50 I've madvr displaying a near black flashing bar test pattern.
The +50 have an evident effect on the flashing bars ...

I turned back in madTPG and with Calman I performed another grey scale read ...

the result is identical like before!!

Maybe I found a bug?

or it is normal that a brightness setting do not effect the patches reproduced in madTPG ???
madTPG currently ignores the brightness/contrast/saturation/hue settings. My personal opinion is that calibration should be done without the help of those options, and those brightness/contrast options can then be used to e.g. adjust playback behaviour if you turn ambient light on/off. But that's just my personal opinion. If the majority of users would prefer to have madTPG apply brightness/contrast adjustments, too, it wouldn't be hard for me to change that. The tricky part is getting feedback from all the calibration users to ask what they want, and then get a clear vote. You're the first one even asking for this, so my impression is that most other users don't need (or even don't want) madTPG to apply brightness/contrast. But I'm not 100% sure.

Also seems like setting an audio delay in MPC-HC doesn't help :(
Then the only option seems to be to maybe try your luck with a different source filter. Or if that fails, use a different renderer for now... :(

Thanks for sparing me to search all forum posts :-) and I'll keep my fingers crossed that madshi will have pity on us sooner or later.

Now that I've tried ffdshow's nice, but slow version I'm really hooked to non-linear scale 4:3 or widescreen content to my 16:9 display ... but anything above sd resolution is a no go with my 2ghz dual-core. Esp. watching an old 4:3 tv series in widescreen is amazing.
Personally, I hate NLS, in any configuration. Try a movie with a horizontal camera pan. It looks totally aweful IMHO. Which is why this feature has very low priority for me. I might still add it some day, but not any time soon, sorry. Too many other things on my to do list, which I find far more beneficial/useful.

Speaking of, I wonder if this is a viable setup and the resolution switcher can actually deal with it.... Switching between 60Hz 8-bit and 24Hz 10-bit automatically.
The key problem for me is that I can ask the GPU to display anything in 10bit and it usually reports success, but whether or not the GPU actually outputs 10bit+ to the display or not is not something I can check. The GPU might do it, or it might output 8bit and apply dithering internally (or rounding, if dithering is turned off).

At some point in the future, I'm going to redesign the whole display mode switching options in madVR, and then I might make it possible to select specific bitdepths for specific resolutions.

Apparently, amongst other things like dynamic metatdata support in HDMI 2.1, the future spec will support 10 Bpc 60Hz RGB in UHD res.
Really? Do you have a link with this information? They'd have to increase the bandwidth once more to make that possible, I believe.

Thanks, but i fixed it. The problem was because yesterday i installed nvidia 3d play tv, after i unistalled it the mpc worked again with madvr
FWIW, the next madVR build will fix this crash. The end result will be that NVidia will try to artificially convert 2d movies to get 3d depth. Whether you like that or not will be your decision. Disabling 3d play might end up being the best option, anyway, even though the crash will hopefully be gone with the next build.

Also, why are madVR use RGB as output? I thought YCbCr444 was a requirement to run 4K material at 60hz?
YCbCr444 has the same bandwidth as RGB. If your HDMI output/input is limited to 10.8Gbps, then for 60Hz you need YCbCr420. The GPU driver should do the conversion automatically, if needed.

Hi, feature request idea please. Now that Im using madVR I am missing features I used to use allot from the MPC-BE stats renderer that I found useful. These are:

* CPU utilisation
* GPU utilisation
* Description of the codec used in decoding and what it is - e.g. DXVA 2 H.264 or software MPEG4PT2ASP etc
The OSD already shows whether native DXVA is used or not. Whether copyback or software decoding is used isn't shown, though, but that's not of much interest to madVR, anyway. I could add CPU & GPU utilization, but to be honest, at this point I'd rather spend my available development time on adding or improving algorithms, instead of adding information to the OSD which only some users will find helpful. I simply have too many things that still need to be done, so I have to put priority on what I personally find most important. And showing CPU/GPU utilization, while interesting, is not very important at the moment, IMHO, compared to some other things on my to do list.

1) Madshi, do you know any way to force vector adaptive deinterlacing using new AMD driver?
madVR asks for the highest quality algo available. So if the new AMD driver isn't using it, it's probably a bug in the drivers.

2) Please, have a look at this sample.
https://drive.google.com/file/d/0B7a6LffuxvKUblU4NmpHYWthdjQ/view?usp=sharing
Image is not centered if black bars are automatically detected.
Thanks, will have a look. Might take some time, though. Busy with other stuff atm.

[madshi]

would it be possible to change things so if smooth motion is needed, it will pick your highest refresh rate rather than the highest 'normal' one? specifically, i run my 60hz monitors at 66hz, which never gets picked for non 15/30/60 fps content
Hmmmm... Sounds like a good idea. Not sure how hard it would be to implement, though. Will have a look.

It's been suggested to me to turn off the DVI Dithering on my AMD card. Should i or shouldn't i? Does the dithering restrict the color gamut?
It should only become active if you ask madVR to output 10bit while your display doesn't accept 10bit. So in most cases enabling/disabling DVI Dithering for your AMD card shouldn't make a difference. If you want to check whether outputting 10bit looks better than 8bit, then it might make sense to disable DVI dithering, so that you can judge whether 10bit output actually works at all.

Is there an option in the madvr script language to activate profiles based on the active display?
For example:
if (device = Samsung XY) "profile1" else "profile2"
Oh, seems I forgot to update the profile help post. Yes, there's a new string variable called "display" you can use for this. However, I've been told it doesn't work correctly yet, so it might need some fixing on my side.

The issue I'm having is that the mouse cursor always shows up in the center of the screen for a few seconds when play back starts up, which is kind of annoying.
This is not something madVR usually has an influence on. It's usually the job of the media player to handle this. However, I suppose when switching display modes or refresh rates, or when entering/leaving fullscreen exclusive mode, maybe Direct3D or Windows itself might make the mouse cursor visible again. Not sure if that is something the video player can detect/handle.

Is there anything I can do to improve the awful clock deviation on my AMD 7850? It seems no matter what settings I change (and I've tried them all), I always get at least 1 dropped or repeated frame during a 2 hour movie and it's really jarring. Video micro-stutters and the audio makes a loud glitching noise. It will fluctuate between 1 frame repeat every couple hours or sometimes days, but then will sometimes drop into the minutes for no rhyme or reason.
Don't put too much weight into the repeat/drop estimates madVR is reporting. The *actual* number of frame drops/repeats is the key thing. Do you actually get drops/repeats during movie playback? If so, is it drops or repeats or sometimes this and sometimes that?

Will FilmGrain effect ever be added to madVR? From what I understand, it partially acts as semi-dithering, but mostly enhances perception of image detail. It could be a useful effect!
You can decrease the display bitdepth in the display properties. That will increase the amount of dithering madVR adds, which is probably similar to adding some film grain.

I had a crash and didn't have internet at that time to send it, so I'll upload it now here since I don't know where else I should! Sorry if it's not on topic nor a useful thing to do.
Was this a one-time-only crash? Or does it happen from time to time? If it's a one-time-only crash which only occurred due to overload then I wouldn't worry about it much.

I have done some tests with the new HDR feature in MadVR, and it seems to be working very well, emulating HDR playback on a non HDR display (a JVC X500 in my case). It worked equally well on an X7000 which is HDR compatible, in fact the difference between the two units once brightness matched and both calibrated to P3 was minimal, even though the X500 only reaches about 90% of P3 while the X7000 with its P3 filter covers about 98% of it.
Have you tried to compare: 1) Letting madVR convert HDR -> SDR. And 2) Using an old madVR build to send HDR untouched to the X7000, so that the X7000 will internally do the HDR interpretation? How did 1) and 2) compare, quality wise?

While the peak white my JVC X500 is able to produce is only around 110nits in high lamp iris fully open with a P3 / D65 / BT1886 calibration, I found that selecting 120nits in MadVR or even 180nits led to a too bright result for mid-tones and raised black levels for low APL scenes. It looks like the most believable results are obtained using 265 or even 400nits.
Agreed. The thing is that ambient light level needs to be taken into account, too. Originally 400nits was the lowest setting available in madVR because I thought it should already be plenty bright enough, and using lower settings didn't look too great, even for front projection. But then users asked for lower nits settings, so I added them. I wouldn't go lower than 265, though.

Do you plan to let the user specify which native gamut is active for each type of content? For example, for Rec-709, we would run a profile on a rec709 native gamut (so as not to waste brightness unnecessarily due to a P3 filter), and apply a MadVR 3D LUT for rec-709, which will be reprofiled into SMPTE-C and PAL slots. But for P3 or Rec-2020 calibration, we would select a different user mode, for which either no 3D LUT is necessary, or a different 3D LUT made from a different profile. At the moment, if we select no 3D LUT for P3, my understanding is that MadVR assumes the display is only rec-709 compatible, therefore converts P3 to rec-709, losing on the wider gamut.
As I already wrote in the SpectraCal thread, if you tell madVR to "calibrate this display using external 3dlut files" then madVR currently always applies a 3dlut, no matter what. Which one is chosen depends on how your 3dlut slots are filled. If the slot matching the source's gamut is empty, madVR defaults to the BT.709 slot. That might not be the best solution. I should probably default for e.g. the P3 slot (if it's filled) if the 2020 slot is empty and you're playing 2020 content. In any case, currently you cannot choose to use 3dluts for some content and not use 3dluts for other content. The settings dialog simply doesn't have the capability to do things like that. So if you want to use external 3dlut files, please provide a 3dlut for P3 and/or 2020, too. In that case all your worries should be solved.

However, if you insist that you absolutely have to be able to use 3dlut files for some gamuts and no 3dlut files for other gamuts, then I suppose the proper solution for that would be to use profiles. The "calibration" settings page is already profilable right now. So you could easily setup one calibration for HDR content (without using 3dluts) and another one for SDR content (using 3dluts) by using "if (hdr) ..." as profile rule.

2) Do you plan to add the ability to specify which user mode we want to select for each calibration, for the displays MadVR supports like the JVCs, so that we can assign for each calibration a specific user mode with the best gamut (and an optional 3D LUT to make it more accurate if necessary). So for example, we would have a rec709 gamut for rec-709, SMPTE-C and PAL in one user mode with 3 different 3D LUTs, and a P3 gamut for P3 and rec2020 in a different user mode, with a 4th 3D LUT (from a different profile, possibly using a filter) to improve the native gamut accuracy in P3 (or rec2020, when the discussion about which mode is best is settled).
I'm not sure what you mean with "user mode"?

3) Beyond the ability to specify a value for peak white, would you consider adding a variable for reference white as well, which could give us more flexibility to achieve the best results. For example, depending on the amount of brightness and contrast we have in reserve, we might want a reference white closer to peak white with a projector barely able to hit 120nits in high lamp in a dedicated bat cave with full light control, while we might want more specular highlights with a flat panel able to reach 1000nits for peak white in a living room with ambient light. If you want to simplify, we could have a projector mode similar to what dolby vision does in cinema, where reference white remains at 48nits but peak white is set to twice that (100nits), while UHD Bluray will likely offer content mastered to 700-1200nits with flat panels in living rooms in mind.
The "nits" setting in the settings dialog is not as scientific as it may appear to be. You shouldn't measure your peak luminance nits and then pick the matching value in madVR. Instead simply try different nits settings in madVR and pick the one which looks best to your eyes. I think this is all the adjustability that is needed for now.

Yes, it would be possible to add one more configuration option, to give you more control about which areas are compressed stronger or weaker, but to be honest, at this stage I don't want to add it, because HDR specs are still "changing". E.g. SMPTE 2094 is in the works, and I don't want to spend countless hours on fine tuning HDR algorithms now, when they might need adjusting after e.g. SMPTE 2094 is released, anyway.

For HDR compatible displays like the new JVCs, it might be good to have the option to use MadVR in pass-through mode and let the display do all the conversions (once we have HDMI 2.0a support in GPU drivers)?
I won't do passthrough until AMD/NVidia/Intel have APIs available that allow me to pass the metadata through, as well. I don't think it makes sense to passthrough just the data, but without metadata, because the display won't have all the necessary information this way.

-------

There will probably not be a new build this week end. Maybe next week, or the week after that. Don't know yet.

[madshi]

http://forum.doom9.org/showthread.php?t=173005
could this be implemented real time in madvr so I don't have to go re-encode all my videos to 4:4:4?
It does look quite interesting!

Big problem, though: KNLMeansCL seems to be GPL. Since madVR is closed source, I cannot use GPL projects. We could ask the KNLMeansCL dev whether he'd be willing to dual license as LGPL (or MIT/BSD). Or maybe there's another KNLMeans implemention available with a different license? I guess I could do the OpenCL part myself, if C++ code is avilable. But I don't have the time to investigate and develop some KNLMeans algorithm from the ground up myself.

[Manni]

Hi Madshi,

Thanks for your detailed reply, much appreciated. Here are some answers to your questions and a few comments/suggestions


Have you tried to compare: 1) Letting madVR convert HDR -> SDR. And 2) Using an old madVR build to send HDR untouched to the X7000, so that the X7000 will internally do the HDR interpretation? How did 1) and 2) compare, quality wise?


This wouldn't be a fair or meaningful test as the HDR implementation in the new JVCs is a work in progress. They should issue some f/w update once things firm up a bit. However, with gamma adjustments to get the best possible results with the current f/w, MadVR produced a more convincing picture (compared to playing the same content from the NVidia shield using the HD Fury Integral to switch the X7000 to HDR and making sure the best mode for HDR was selected, ie using P3 and PQ gamma with the necessary gamma adjustments).

I also compared the X500 (calibrated to P3 without a filter, reaching about 90% of P3) and the X7000 playing HDR content with its P3 filter allowing it to reach around 98% of P3), both playing the same HDR content converted to SDR with MadVR through a splitter for instant comparison, both brightness matched (the P3 filter in the X7000 drops the brightness by around 15-20%) and there was very little between the two, except of course that the X7000 is a much brighter projector so in some setups with a large screen can produce better results in HDR or 3D.


Agreed. The thing is that ambient light level needs to be taken into account, too. Originally 400nits was the lowest setting available in madVR because I thought it should already be plenty bright enough, and using lower settings didn't look too great, even for front projection. But then users asked for lower nits settings, so I added them. I wouldn't go lower than 265, though.


Thanks, seems to confirm my visual observation.


As I already wrote in the SpectraCal thread, if you tell madVR to "calibrate this display using external 3dlut files" then madVR currently always applies a 3dlut, no matter what. Which one is chosen depends on how your 3dlut slots are filled. If the slot matching the source's gamut is empty, madVR defaults to the BT.709 slot. That might not be the best solution. I should probably default for e.g. the P3 slot (if it's filled) if the 2020 slot is empty and you're playing 2020 content. In any case, currently you cannot choose to use 3dluts for some content and not use 3dluts for other content. The settings dialog simply doesn't have the capability to do things like that. So if you want to use external 3dlut files, please provide a 3dlut for P3 and/or 2020, too. In that case all your worries should be solved.


Thanks for the confirmation of the behaviour in MadVR. I agree that the P3 slot would be a better default for rec2020 if a 3D LUT is loaded for P3 and the rec2020 slot is empty.


However, if you insist that you absolutely have to be able to use 3dlut files for some gamuts and no 3dlut files for other gamuts, then I suppose the proper solution for that would be to use profiles. The "calibration" settings page is already profilable right now. So you could easily setup one calibration for HDR content (without using 3dluts) and another one for SDR content (using 3dluts) by using "if (hdr) ..." as profile rule.


Thanks for this suggestion, it might be useful in the future.

In the meantime, I found a simpler solution to avoid the conversion to rec-709 when the P3 and/or rec2020 slot is empty: to simply upload a unity LUT to the calibration slot when I don't want to spend 2-3 hours to get a marginally better calibration than what I get without a 3D LUT for that content. You might want to consider adding a "unity LUT" option for each slot to make it easier on the user, but that's solved for me.


I'm not sure what you mean with "user mode"?


I mean the user mode in the display. For example, in a JVC projector, I would set up "user1" for a rec-709 calibration, using a rec-709 colour profile and a specific lamp mode, iris opening, color temp and gamma curve. This would be the user mode used for the rec-709 calibration and I would use Calman to profile the display and generate a 3D LUT for the rec-709 MadVR slot. Then I would reprofile from this to generate the SMPTE-C and PAL 3D LUTs, which will be uploaded into the respective MadVR slots for SMPTE-C and PAL. All three 3D LUT calibrations are applied to the same rec-709 user mode and baseline calibration.

Then I would select another user mode in the display, and select a DCI-P3 colour profile (either a self-made one using the JVC Autocal software in the X500 which has no P3 filter, or the existing cinema2 preset in the X7000 which has a P3 filter). I would select a different lamp mode and iris setting, possiblty even color temp and gamma curve, then profile this baseline calibration in Calman and generate a DCI-P3 3D LUT for MadVR uploaded to the corresponding slot.

Therefore, if we could associate user1 to the rec-709, SMPTE-C and PAL calibration LUTs, and user2 to the DCI-P3(with an actual calibration), this would make it possible for MadVR to select the correct user mode / baseline for each calibration according to content.

For rec2020, it's more complicated so I might have to use profiles depending on how we resolve the rec2020 vs P3 calibration question going on in the Spectracal thread. For now, given the way MadVR behaves, I'll just leave the rec2020 slot empty, as rec2020 seems to be always converted to P3, even when there is a 3D LUT in the rec2020 slot and no 3D LUT in the P3 slot.


The "nits" setting in the settings dialog is not as scientific as it may appear to be. You shouldn't measure your peak luminance nits and then pick the matching value in madVR. Instead simply try different nits settings in madVR and pick the one which looks best to your eyes. I think this is all the adjustability that is needed for now.


Agreed, although if we could specify a value instead of limited choices, it might give more granularity. Not sure it's needed though, and you might have a good reason for the fixed values.


Yes, it would be possible to add one more configuration option, to give you more control about which areas are compressed stronger or weaker, but to be honest, at this stage I don't want to add it, because HDR specs are still "changing". E.g. SMPTE 2094 is in the works, and I don't want to spend countless hours on fine tuning HDR algorithms now, when they might need adjusting after e.g. SMPTE 2094 is released, anyway.


Agreed. Hopefully we'll have some more info on Monday when the HDR Alliance announces the HDR levels/specs at CES.


I won't do passthrough until AMD/NVidia/Intel have APIs available that allow me to pass the metadata through, as well. I don't think it makes sense to passthrough just the data, but without metadata, because the display won't have all the necessary information this way.


Agreed, that's what I meant with HDMI 2.0a profile support in the driver. HDMI 2.0a support means HDR metadata support. It's not connected to the HDMI 2.0 level A bandwidth and can be implemented on HDMI 1.4 chipsets, as Sony proved it with the VW520ES/665ES.

[feisty2]

actually just remove the distance weighting of Bilateral, and you get KNLMeansCL(s=0), which is the algorithm used in chromareconstructor :)

[Nullack]

I could add CPU & GPU utilization, but to be honest, at this point I'd rather spend my available development time on adding or improving algorithms, instead of adding information to the OSD which only some users will find helpful. I simply have too many things that still need to be done

Gday Madshi. I totally understand about priorities and I can capture the telemetry in the background to review at a later time after playback as a workaround. Its more just a feature suggestion for anytime where it might be possible :)

As for the HDMI 2.1 comment, well yes I was verbally told that by a colleague so I don't have an internet link but I have no doubt to mistrust what he said. In the past hes been very spot on about these sorts of things he has allot of contacts in the Asia Pacific region especially in Singapore and Taiwan; I get to hear about it when he comes to back Australia with these things.

[madshi]

As for the HDMI 2.1 comment, well yes I was verbally told that by a colleague so I don't have an internet link but I have no doubt to mistrust what he said. In the past hes been very spot on about these sorts of things he has allot of contacts in the Asia Pacific region especially in Singapore and Taiwan; I get to hear about it when he comes to back Australia with these things.
Well, I wouldn't mind having higher HDMI bandwidth, for sure.

In the meantime, I found a simpler solution to avoid the conversion to rec-709: to simply upload a unity LUT to the calibration slot
I suppose you're importing an eeColor unity table? That should work, yes.

I mean the user mode in the display. For example, in a JVC projector, I would set up "user1" for a rec-709 calibration, using a rec-709 colour profile and a specific lamp mode, iris opening, color temp and gamma curve. This would be the user mode used for the rec-709 calibration and I would use Calman to profile the display and generate a 3D LUT for the rec-709 MadVR slot. Then I would reprofile from this to generate the SMPTE-C and PAL 3D LUTs, which will be uploaded into the respective MadVR slots for SMPTE-C and PAL. All three 3D LUT calibrations are applied to the same rec-709 user mode and baseline calibration.

Then I would select another user mode in the display, and select a DCI-P3 colour profile (either a self-made one using the JVC Autocal software in the X500 which has no P3 filter, or the existing cinema2 preset in the X7000 which has a P3 filter). I would select a different lamp mode and iris setting, possiblty even color temp and gamma curve, then profile this baseline calibration in Calman and generate a DCI-P3 3D LUT for MadVR uploaded to the corresponding slot.

Therefore, if we could associate user1 to the rec-709, SMPTE-C and PAL calibration LUTs, and user2 to the DCI-P3(with an actual calibration), this would make it possible for MadVR to select the correct user mode / baseline for each calibration according to content.

For rec2020, it's more complicated so I might have to use profiles depending on how we resolve the rec2020 vs P3 calibration question going on in the Spectracal thread. For now, given the way MadVR behaves, I'll just leave the rec2020 slot empty, as rec2020 seems to be always converted to P3, even when there is a 3D LUT in the rec2020 slot and no 3D LUT in the P3 slot.
So if I understand correctly, you'd like to select a user mode "number" for each source gamut and then madVR would auto-select that specific user mode by using IP control?

actually just remove the distance weighting of Bilateral, and you get KNLMeansCL(s=0), which is the algorithm used in chromareconstructor :)
Remove the distance weighting of which Bilateral algorithm? The one in madVR/MPDN? Or do you mean some Bilateral algo in AviSynth/VapourSynth? Thanks...

[Manni]

madTPG currently ignores the brightness/contrast/saturation/hue settings. My personal opinion is that calibration should be done without the help of those options, and those brightness/contrast options can then be used to e.g. adjust playback behaviour if you turn ambient light on/off. But that's just my personal opinion. If the majority of users would prefer to have madTPG apply brightness/contrast adjustments, too, it wouldn't be hard for me to change that. The tricky part is getting feedback from all the calibration users to ask what they want, and then get a clear vote. You're the first one even asking for this, so my impression is that most other users don't need (or even don't want) madTPG to apply brightness/contrast. But I'm not 100% sure.


For what it's worth I agree that these settings should be ignored during calibration. I don't use them, but if I was, I wouldn't want them to be taken into account, otherwise the right way to calibrate would be to reset these before a calibration and set them again after. Ignoring them makes it possible to leave the settings in place, and possibly adjust them after the calibration.


The key problem for me is that I can ask the GPU to display anything in 10bit and it usually reports success, but whether or not the GPU actually outputs 10bit+ to the display or not is not something I can check. The GPU might do it, or it might output 8bit and apply dithering internally (or rounding, if dithering is turned off).


I can confirm that when playing UHD 10bits content in FSE when the GPU is switched to UHD RGB 8bits, MadVR reports 10bits when the GPU is dithering the 10bits content to 8bits. In that case setting MadVR to 8bits to prevent the GPU from dithering behind its back is probably a better solution.


At some point in the future, I'm going to redesign the whole display mode switching options in madVR, and then I might make it possible to select specific bitdepths for specific resolutions.


That would be great.

[Manni]

I suppose you're importing an eeColor unity table?


Yes, that's what I do, although with Lighspace MadVR is selected when I upload the null LUT in case it makes a difference. Haven't tried with Calman yet, but I assume it works with MadVR selected as well.


So if I understand correctly, you'd like to select a user mode "number" for each source gamut and then madVR would auto-select that specific user mode by using IP control?


Exactly, although I wouldn't necessarily restrict it to a user mode, it could be a factory preset as well (maybe that's what you meant, not sure how MadVR refers to user modes, if it's by number or by name).

For example, the correct mode for HDR playback in the X7000 is cinema2, which calls up a P3 calibration with the P3 filter and PQ gamma. This of course doesn't apply when MadVR is doing the conversion to SDR, but it would apply in the future if/when we have the option to passthrough the HDR data/metadata untouched to the display.

The idea would be that selecting "cinema2" or "user1" or "standard" with IP control would allow the user to bring in the correct baseline with all the relevant settings (lamp mode, iris setting, filter or not, gamma curve etc and baseline calibration on which the corresponding 3D LUT should be applied) automatically, instead of having to select the user mode manually.

So in my example, and with the current implementation, it would look like this:

rec-709 3D LUT -> select user1 (rec-709 baseline) in the PJ with IP Control
smpte-c 3D LUT -> select user1 (rec-709 baseline)
PAL 3D LUT -> select user1 (rec-709 baseline)
P3 3D LUT -> select user2 (P3 baseline)
rec2020 3D LUT -> select user3 (rec2020 baseline)

Also if there is a rec2020 3D LUT, would you consider not converting rec2020 content to P3?

That way we can try without a rec2020 3D LUT (MadVR converts rec2020 to P3, assuming there is a P3 3D LUT loaded) and with a rec2020 3D LUT (MadVR doesn't) and see what looks best on each display? An option (convert rec2020 content to P3) would be even better during tests, as it would allow us to try the two options while leaving the LUTs in place.

[feisty2]

Remove the distance weighting of which Bilateral algorithm? The one in madVR/MPDN? Or do you mean some Bilateral algo in AviSynth/VapourSynth? Thanks...

well... not sure, as long as the weighting function is the same and it should just work theoretically...
according to the doc of KNLMeansCL, the function (wmode=1) is called "Leclerc weighting function", the one also used in TNLMeans

[madshi]

Exactly, although I wouldn't necessarily restrict it to a user mode, it could be a factory preset as well (maybe that's what you meant, not sure how MadVR refers to user modes, if it's by number or by name).

For example, the correct mode for HDR playback in the X7000 is cinema2, which calls up a P3 calibration with the P3 filter and PQ gamma. This of course doesn't apply when MadVR is doing the conversion to SDR, but it would apply in the future if/when we have the option to passthrough the HDR data/metadata untouched to the display.

The idea would be that selecting "cinema2" or "user1" or "standard" with IP control would allow the user to bring in the correct baseline with all the relevant settings (lamp mode, iris setting, filter or not, gamma curve etc and baseline calibration on which the corresponding 3D LUT should be applied) automatically, instead of having to select the user mode manually.

So in my example, and with the current implementation, it would look like this:

rec-709 3D LUT -> select user1 (rec-709 baseline) in the PJ with IP Control
smpte-c 3D LUT -> select user1 (rec-709 baseline)
PAL 3D LUT -> select user1 (rec-709 baseline)
P3 3D LUT -> select user2 (P3 baseline)
rec2020 3D LUT -> select user3 (rec2020 baseline)
Ok. Well, maybe something to look at in some future version, but probably not any time soon.

Also if there is a rec2020 3D LUT, would you consider not converting rec2020 content to P3?
Simply configure madVR to "this display is already calibrated to BT.2020".

well... not sure, as long as the weighting function is the same and it should just work theoretically...
according to the doc of KNLMeansCL, the function (wmode=1) is called "Leclerc weighting function", the one also used in TNLMeans
Ok, but which KNLMeans/Bilateral code should I use as the base for my implementation then? I don't have the time/resources to implement one myself from ground up atm, so I need some C++ (or other) code to look at. And legally, it can't be GPL... :( Oh well, I guess if I look at some code just to understand the algorithm, and then totally write it new from scratch in HLSL/OpenCL/whatever, legally that should probably be alright, I suppose.

[feisty2]

https://github.com/VFR-maniac/VapourSynth-TNLMeans
okay, this one is LGPL

[madshi]

Sounds good, thanks. So that one would produce exactly the same output/quality?

[Manni]

Ok. Well, maybe something to look at in some future version, but probably not any time soon.


No problem, I agree it's not a priority at this stage, thanks for considering it.


Simply configure madVR to "this display is already calibrated to BT.2020".


Thanks.

1) Where is this option? I've probably missed it, but I've never seen it.

2) Will this allow to use a rec-709 calibration for rec-709, PAL and SMPTE-C, a P3 calibration for P3 and a rec2020 calibration for rec2020? Or will it force us to use the same baseline for all calibrations?

[feisty2]

Sounds good, thanks. So that one would produce exactly the same output/quality?

KNLMeansCL was initially an OpenCL version of TNLMeans, so I guess yeah,
parameters used in chromareconstructor:
ax=ay= radius
az=0
sx=sy=bx=by=0
a=1.0
h=str
ssd=1
"rclip" (external clip as the weighting reference) wasn't implemented in TNLMeans, guess you have to do that by yourself, but it should be pretty easy..

[huhn]

That is with forced film mode disabled, right? If the decoder says it's 30fps then madVR treats it as such, if forced film mode is disabled. I cannot possibly know whether it's a reliable soft telecine video file or not. It might be. Then I could switch to 23p and enable smooth motion. But it could also be true 30p, or 60i, or the video could switch back and forth between 23p, 30p and 60i all the time in the middle of the movie.

Files like this is what the "if in doubt activate deinterlacing" setting is meant for. Usually that setting activates deinterlacing for files like this, which is probably the right solution.

wouldn't IVTC fail in this case too?

ok it could kind of survive 30p. are the informations from media info unreliable or unaccessible?

can madVR always read the repeat flag and act different when they are found? like enabling smoothmotion.

so every case that is not interlaced is not harmed by this.

[nevcairiel]

2) Will this allow to use a rec-709 calibration for rec-709, PAL and SMPTE-C, a P3 calibration for P3 and a rec2020 calibration for rec2020? Or will it force us to use the same baseline for all calibrations?

Profiles! :)

[mark0077]

Hi all, maybe this is already well known, but I thought I would mention it. I was noticing ~3ms rendering times when the mpc-be window was at any size but not maximised. After maximised (non exclusive mode), the rendering times were around 16ms. Exclusive mode fixed this and brought it back to ~3ms but without exclusive mode, using the "use Direct3D 11 for presentation" option also brings rendering times down to 3ms in non exclusive mode. I can't remember seeing this checkbox having such a big impact on rendering times when I tested before but now I'm using Windows 10 so maybe that made the difference.

Just thought it was worth mentioning anyways for those not using fullscreen exclusive mode. I'm using GTX 980 in Windows 10.

[huhn]

have you checked the GPU powerstate?

rendertiems aren't reliable without GPU powerstate.