madVR - high quality video renderer (GPU assisted)

[chuuey]

Well I think my Vsync issues on XP are a problem related to the Nvidia drivers. Even with latest WHQL drivers, the refresh rate reported by madVR is all over the place, sometimes falling to 57Hz on a 60Hz screen and sometimes jumping into 62 range, and frame drops occur everywhere. I just tested madVR on another machine with Intel HD4000 Ivy Bridge graphics, exact same software setup as my PC and it works flawless, no Vsync issues and I just watched a film with 0 frame drops on it. I guess Nvidia messed something up on XP and 600 series drivers. Interesting fact is that all games, for example have perfect Vsync applied.

[Niyawa]

Do you really expect him to work continuously, without break, on madVR? He has other priorities you know.
What?! A developer has a life?! Heresy!

Jokes aside, don't recklessly assume that I was criticizing his behavior of taking breaks silly. That was a simply a comment based on ryrynz guess.

[MokrySedeS]

so does that 91% load stutter?No, it does not. Playback is smooth with no dropping frames.
It starts to drop ~3 frames per second though when I have a brwoser with hardware acceleration enabled in the background, which by itself causes 2-4% load.
Slight overclock would probably take care of that, but afterburner crapped out on me yesterday when I tried to update it so I can't test it right now.

I'm a little surprised as a 660 also gave 30% on 720p@1080p when Xaurus tried it (http://forum.doom9.org/showpost.php?p=1598453&postcount=15165)(and 48% on interlaced PAL DVD (http://forum.doom9.org/showpost.php?p=1598462&postcount=15168)).Display calibration maybe? My display is not calibrated. Just guessing...

Hopefully you both tested a 16/9 720p movie and not 2.40I know I did ;) A 720p file with 2.35 aspect ratio gives me 24%.

And you were using CUVID decoding in LAV, right?Nope... dxva2cb. Why should I use CUVID?

Anyway if your 91% load on that 1440*1080@29.97fps "worst case scenario" sample doesn't stutter then I guess I might just snag one of those <100€ 650Ti's after all :pBear in mind that I have a power edition card from msi, which is slightly overclocked by default.

EDIT: 92-93% with CUVID but still plays smoothly.

[truexfan81]

OK, thanks again for the testing! so does that 91% load stutter?

I'm a little surprised as a 660 also gave 30% on 720p@1080p when Xaurus tried it (http://forum.doom9.org/showpost.php?p=1598453&postcount=15165)(and 48% on interlaced PAL DVD (http://forum.doom9.org/showpost.php?p=1598462&postcount=15168)).

Hopefully you both tested a 16/9 720p movie and not 2.40, and I know madshi also added optimized code for fixed ratios...

And you were using CUVID decoding in LAV, right?

Anyway if your 91% load on that 1440*1080@29.97fps "worst case scenario" sample doesn't stutter then I guess I might just snag one of those <100€ 650Ti's after all :p

non-Ti 650? Yes, I guess this board must really suffer on J3AR :o

I'm getting tired of constantly switching scalers, I just wanna leave them both on J3AR permanently.

i hear ya, for most things i use jinc3ar luma and softcubic chroma (i noticed some weird artifacts when using jinc3 chroma) only thing i have in 60fps is nascar races, so i just change it to lanczos3ar when i watch those.

[truexfan81]

Does anyone have any idea how a Intel i5-4570R, i5-4670R or a i7-4770R with the new Haswell HD 5200 (GT3e) will perform with MadVR? Might consider a Mini-ITX Media Center running Media Browser + MPC-HC if the performance is good enough.

when using madvr the gpu is more important than anything

[6233638]

i noticed some weird artifacts when using jinc3 chromaDo you have any samples for that? I would be very interested in seeing them.

[truexfan81]

Do you have any samples for that? I would be very interested in seeing them.

i'll have to see if i can reproduce it, will post later if i don't forget

[Dodgexander]

Does anyone have any idea how a Intel i5-4570R, i5-4670R or a i7-4770R with the new Haswell HD 5200 (GT3e) will perform with MadVR? Might consider a Mini-ITX Media Center running Media Browser + MPC-HC if the performance is good enough.

I should think so, madshi said himself it works great on his current Intel HD 4000 graphics.

What's interesting though is that it seems only mobile cpus are being shipped with the flagship integrated gpu. Not that the desktop one won't be an improvement on what's currently on offer..but still..

Sent from my Blade S using Tapatalk 2

[jmelan]

Hi madshi, I am a long time user of madVR - thanks for all of your efforts!

I have a GTX 650 Ti and noticed that the included madNvLevelsTweaker.exe utility has the added benefit of fixing the Nvidia HDMI audio "not plugged in" problem after resume from sleep/TV turned off and back on (normally requires a restart).

Not knowing how the madNvLevelsTweaker.exe utility is working, is it safe to run multiple times (eg every time I resume from sleep)? If not, is there any chance that whatever function you are using to reset the graphics driver could be used separately?

Thanks!

- other dedicated programs such as HDMIOn and HDMIYo fail to correct the issue. Also, the Gefen HDMI detective plus does not work properly with the current Nvidia drivers (HDCP error).

[dbcooper]

Hi guys, have a quick question about DVD playback.

Many PAL DVD's are 25fps progressive but flagged as 50i, where the frames are progressive (at 25fps) but are played twice to give 50fps.

Can I simply deselect "automatically activate deinterlacing when needed" and safely have the video played as 25p?

[Dodgexander]

Hi guys, have a quick question about DVD playback.

Many PAL DVD's are 25fps progressive but flagged as 50i, where the frames are progressive (at 25fps) but are played twice to give 50fps.

Can I simply deselect "automatically activate deinterlacing when needed" and safely have the video played as 25p?

Or you can toggle between modes during playback. See the shortcut section.

You should also use the osd to see if it's detecting anything wrongly.

Sent from my Blade S using Tapatalk 2

[dbcooper]

Thanks for the shortcut tip. What's happening (according to the OSD) is that (with "automatically activate deinterlacing when needed" on) MadVR spends a lot of time deinterlacing, which puts stress on my old GPU. I assume that if I turn off that option then MadVR will simply drop half of the 50 fps, leaving a perfect, progressive 25fps?

[6233638]

Many PAL DVD's are 25fps progressive but flagged as 50i, where the frames are progressive (at 25fps) but are played twice to give 50fps.

Can I simply deselect "automatically activate deinterlacing when needed" and safely have the video played as 25p?There is a half framerate option in the "trade quality for performance" settings. But if the disc is actually progressive, deinterlacing probably won't be activated.

I have a GTX 650 Ti and noticed that the included madNvLevelsTweaker.exe utility has the added benefit of fixing the Nvidia HDMI audio "not plugged in" problem after resume from sleep/TV turned off and back on (normally requires a restart).I can't speak for using madNvLevelsTweaker, but have you disabled the Nvidia Display Driver Service? I know that some people like to disable "unnecessary" services, and I have found it to cause problems with HDMI audio in the past when it was disabled.

[dbcooper]

There is a half framerate option in the "trade quality for performance" settings. But if the disc is actually progressive, deinterlacing probably won't be activated.

I can't speak for using madNvLevelsTweaker, but have you disabled the Nvidia Display Driver Service? I know that some people like to disable "unnecessary" services, and I have found it to cause problems with HDMI audio in the past when it was disabled.

It seems to depend on the title menu - if this is flagged as progressive then the movie will be played as progressive, if it is interlaced then the movie will be played interlaced.

[adhara]

when using madvr the gpu is more important than anything

What a pity.
I noted (MadVR + Lav (Jriver)) the following distribution in terms of use of machine resources (in average and with Bicubic/Lanczos).

GPU (hd4000) : 60%-80%
CPU (i7 3370): 5%-10%

Many people are moving towards a fanless configuration (w/o any graphic card).
It would be nice that developers balance their codes load between CPU and GPU.
Currently, most of codes are GPU oriented. Not sure this is the better choice.

[DragonQ]

Hi guys, have a quick question about DVD playback.

Many PAL DVD's are 25fps progressive but flagged as 50i, where the frames are progressive (at 25fps) but are played twice to give 50fps.

Can I simply deselect "automatically activate deinterlacing when needed" and safely have the video played as 25p?
Yes. CTRL + SHIFT + D will toggle deinterlacing on/off as needed.

If performance isn't a problem then you can usually leave deinterlacing on for progressive content. To check that nothing funky is happening to the video, simply step through the frames (after playing a few seconds). If every other frame is identical to the previous one, then everything is fine. If they are similar but not the same, then your GPU isn't handling the cadence properly and is incorrectly applying deinterlacing, resulting in resolution loss.

[jmelan]

...I can't speak for using madNvLevelsTweaker, but have you disabled the Nvidia Display Driver Service? I know that some people like to disable "unnecessary" services, and I have found it to cause problems with HDMI audio in the past when it was disabled.

Nothing disabled, clean install. Nvidia's current drivers have a problem with HDMI hotplug detection. Since I use my HTPC for cablecard recording (HD homerun prime), the TV is often off. When I turn it back on, HDMI audio does not work until a restart.

I realize that this is off topic. I will probably try to just keep using madNvLevelsTweaker, but that method does not have a high WAF. Apparently both AMD and intel video drivers are handling HDMI hotplug detection properly right now, but I would prefer to stick to Nvidia and CUVID for LAV/madVR.

[yok833]

Is there a big difference in picture quality between Cuvid and hardware decoding? Is DVXA copy back the worst solution?

[6233638]

Is there a big difference in picture quality between Cuvid and hardware decoding? Is DVXA copy back the worst solution?CUVID forces the graphics card into its highest power state when running, and I have found that using CUVID with a lot of files will activate deinterlacing when there's no need for it. (if I use software decoding or DXVA2 copy-back, it's detected as being a progressive video)

DXVA2 Native decoding performs slightly worse than LAV's Copy-Back implementation for me, and it does not allow you to force Film-type deinterlacing, which makes it useless for me.

DXVA2 Copy-Back performs best out of the three. Files are correctly detected as being progressive/interlaced, and you are able to force Film-type deinterlacing when using it if you need to. (I actually have madVR set up to force Film-type by default, and manually override it in the rare case that video-type is required)

Both DXVA2 decoding options also allow the graphics card to drop down to the medium power state as well if it's not needed. Because I have a GTX570, it never needs to be in the high power state during video playback, so this reduces my power consumption.


It is rare, but I have one or two videos (Blu-ray discs, even) that show artefacts when decoded via the hardware decoders, that play back perfectly with software decoding. Otherwise, image quality should be the same between CUVID and DXVA2 Copy-Back.

But it's so rare that I stick with DXVA2 Copy-Back for the power savings.

I can't say what the situation is like for AMD/Intel.

[DragonQ]

Yeah I would recommend both types of DXVA2 over CUVID for nVidia cards, unless you have a specific reason to use the latter (like I do right now).

[iSunrise]

In other words, for maximum compliance with current specifications, madVR should default "the display is calibrated to the following transfer function / gamma" to "pure power curve 2.20" (IIRC it already does), because sRGB, and more importantly, it should default "enable gamma processing" to "enabled, pure power curve 2.40", because BT.1884.

The source is always encoded to the specification (e.g. BT.709) so it should be left alone.
BT.709 does not specify a display gamma however. CRT broadcast monitors have a native gamma of approximately 2.40, but some LCD broadcast monitors were set to 2.20 gamma. We now have a spec for display gamma (BT.1886) which uses 2.40 as the reference gamma. (but it also includes compensation for lower contrast displays)
...
This is all fine so far. But video content is typically designed to be viewed at (or around) 2.40 gamma - based on what a broadcast CRT measures, and the BT.1886 specification.

So with my display calibrated to 2.20 gamma, and madVR set up accordingly, I then need to use gamma correction to achieve the correct 2.40 gamma for watching film content:
...
The BT.1886 specification would beg to differ. 2.40 gamma is the reference that all displays should be targeting - in a controlled environment. In an uncontrolled environment, anything goes - what's the point of 2.4 gamma if you can't see anything because the room is too bright? Though you could probably measure the in-room contrast and apply the BT.1886 curve to arrive at the "correct" gamma value for those viewing conditions. (below 10,000:1 contrast, it deviates from 2.40 gamma)
Thanks to e-t172´s and 6233638´s detailed descriptions of the whole gamma situation, LCD displays and the "new" BT.1886 specification (which I also didn´t know of before), I have taken the time to not only measure, but calibrate everything again.

I have a pretty controlled environment with an Eizo CG243W LCD at my desk and I am astounded with the final results. The room I have resembles a pretty common room setup with one light on my desk (near the LCD) and one light that is moderately lighting up the room (not overly bright). I have to mention though that these lights I have at home really don´t make any difference regarding my final settings, because even when I turn off all the lights or am using a brighter low-energy light bulp near the LCD the results are not much different (the only difference is that the eyes only recognize one light source, which is the LCD itself, instead of an additional one at the desk and therefore they are then overly sensitive to it, which gives the impression of reduced contrast, but that´s negligible).

Before that discussion I always wondered why some seemed to be satisfied with 2.40 gamma while watching films with madVR, while it always looked to dark on my LCD before. That is, using a target with BT.709 specifications, going with a pure power curve along with 2.20 gamma and gamma processing with 2.40, which looks terrible (black crush). Therefore I just went without gamma processing in the past.

I wrongly assumed this is only because of the relatively low contrast levels for LCDs (I had a CRT before) and quickly forgot about it, because I thought this is not something I could fix. However, because of that mention of the BT.1886 specification I was again questioning that. Therefore I created some calibration targets and compared between them, with and without madVR´s calibration settings active as well as with and without madVR´s gamma adjustments or/and any combination of them. At first, I only did this by blindly judging the definition/detail in the dark areas and the look (flat/overexposed, etc.) Then I used the test patterns from AVS HD and double-checked.

I also found this (http://en.wikipedia.org/wiki/Rec._709):

Rec. 709 is written as if it specifies the capture and transfer characteristics of HDTV encoding - that is, as if it were scene-referred. However, in practice it is output (display) referred with the convention of a 2.4-power function display [2.35 power function in EBU recommendations]


What I found out is that the perfect calibration target to let madVR work with is to calibrate to/emulate a REC.709 target according to the factory adjusted 3DLUT, without ANY manual changes whatsoever from my side. Going with the REC.709 target the final result on my monitor is so precise that it not only shows me every shade of grey from 0-255 (distinguishable with the naked eye), but also uses the BT.709 curve as defined in the profile. Along with that, I have then set madVR to "this monitor is already calibrated" and the "BT.601/BT.709 curve" option with gamma "2.20".

Now, since BT.1886 was mentioned and e-t172´s and 6233638´s posts about the correct display gamma, I enabled "enable gamma processing" with a "pure power curve" and gamma "2.40". After I did this step I played back some samples, films and test patterns and I couldn´t believe my eyes.

I have never before seen such depth on this LCD, ever!

As an example, I watched like 30 minutes of the new Aliens Blu-Ray and completely forgot about time, because it looked almost three-dimensional in some scenes (the scene where they woke up on the starship approaching LV426 and are having their mission briefing where Ripley is standing in front on the right with the ship and the sergeant in the back). I also watched some BBC recorded broadcasts (with madVR´s deinterlacing enabled, which works very well IMHO) with 60fps (59.940) and they also look stunning. I also have some older TV shows (like Baywatch) that seem to have been mastered on SMPTE-C with 2.35-2.5 monitors and that also looks better than before.

madVR is even more valuable as I imagined before, since I am not sure how I can emulate this behaviour with everything else now. A huge plus is madVR´s high internal precision doing all these calculations before the final down-dithering to 8-bit. I also am pretty sure that even if I could replicate that somehow, madVR still has the advantage of being a lot more flexible in every aspect (very smart guessing logic, overrides and tagging).

I would recommend everyone who still has doubts about BT.1886 to try it for themselves.

[dansrfe]

Why isn't there a professional calibration guide written in simple terminology for reference anywhere? :(

[iSunrise]

Why isn't there a professional calibration guide written in simple terminology for reference anywhere? :(
Have you tried the AVS HD 709 (http://www.avsforum.com/t/948496/avs-hd-709-blu-ray-mp4-calibration) guide, yet? Look especially at the RELATED LINKS section that has very detailed instructions with pictures and examples. Also, the various test pattern ISOs are extremely helpful to check your results.

Since madshi hinted that he´s going to commit a bit more time to calibration (because he wasn´t happy with yCMS if I remember correctly) this will only get better in the future.

[6233638]

Before that discussion I always wondered why some seemed to be satisfied with 2.40 gamma while watching films with madVR, while it always looked to dark on my LCD before.It will look too dark on an LCD because you need at least 10,000:1 native contrast before you can use 2.40 gamma without significantly crushing shadow detail.
It tends to look bad on CRT because most CRTs don't behave properly when the brightness control is turned down that low. (so they don't measure 2.40 at every point and are crushing shadow detail)
Most people only look at the "average gamma" which is almost meaningless.What I found out is that the perfect calibration target to let madVR work with is to calibrate to/emulate a REC.709 target according to the factory adjusted 3DLUT, without ANY manual changes whatsoever from my side.What do you mean by "emulating a Rec.709 target"? BT.709 only specifies primaries, it does not specify any EOTF. (gamma) Typically you would want a monitor like that to be calibrated to a 2.2 power curve.Going with the REC.709 target the final result on my monitor is so precise that it not only shows me every shade of grey from 0-255 (distinguishable with the naked eye), but also uses the BT.709 curve as defined in the profile. Along with that, I have then set madVR to "this monitor is already calibrated" and the "BT.601/BT.709 curve" option with gamma "2.20".I'm not sure why you would calibrate your display to the BT.709 curve (which is not to be used on displays) if you are going to be cancelling it out anyway. (by telling madVR that the display is calibrated to it, and then setting the target to 2.40 power)Now, since BT.1886 was mentioned and e-t172´s and 6233638´s posts about the correct display gamma, I enabled "enable gamma processing" with a "pure power curve" and gamma "2.40". After I did this step I played back some samples, films and test patterns and I couldn´t believe my eyes.I'm not sure that you have interpreted the BT.1886 spec correctly - you shouldn't be anywhere near a 2.40 gamma when your display only has 850:1 contrast.
I would suggest using this calculator (http://www.avsforum.com/t/1409045/how-power-law-gamma-calibration-can-lead-to-crushed-blacks/0_100#post_22208270) to get the right values for your display. (you need to set white and black level in the top left - don't touch anything else)If you are able to write to the monitor LUT directly, I would use that for calibration rather than any of the options inside madVR. (just tell madVR that the display is already calibrated to BT.709/2.2 power, so that it only performs colorspace transformations)
Otherwise you will need to use yCMS and disable gamma correction. (because it only allows for "simple" adjustments, and not custom target curves)

Why isn't there a professional calibration guide written in simple terminology for reference anywhere? :(I'm happy to help, but I don't think this is the place for it.

[totalz]

I'm using LAV video decoder + MadVR, and am wondering which hardware decoding setting to choose in LAV.

With MadVR, which hw-decoding is recommended? DxVA2 native or copy-back?

[hdboy]

For some reason, I am getting huge number of frame drops playing some trailers with smooth motion on (24fps->60). For example, this one

http://videos.hd-trailers.net/20130409_elysium_trailer1_4000.mp4

mediainfo tab


General
Complete name : S:\20130409_elysium_trailer1_4000(2).mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 63.0 MiB
Duration : 2mn 12s
Overall bit rate mode : Variable
Overall bit rate : 4 000 Kbps
Encoded date : UTC 2013-04-09 15:15:49
Tagged date : UTC 2013-04-09 15:15:49

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2mn 12s
Bit rate mode : Constant
Bit rate : 3 936 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.079
Stream size : 62.0 MiB (98%)
Language : English
Encoded date : UTC 2013-04-09 15:15:49
Tagged date : UTC 2013-04-09 15:15:49

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 2mn 12s
Bit rate mode : Variable
Bit rate : 61.6 Kbps
Maximum bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 994 KiB (2%)
Language : English
Encoded date : UTC 2013-04-09 15:15:49
Tagged date : UTC 2013-04-09 15:15:49
mdhd_Duration : 132168


Odd because my system can play much more demanding material, like bluray m2ts files, just fine with smooth motion on. I am using mpc-hc and lav splitter and lav decoder. Any idea? thanks

[leeperry]

BTW, could the MPEG1 chroma be properly aligned with a simple PS script? :o

92-93% with CUVID but still plays smoothly.
OK, sounds good! The thing is that the 2GB 650Ti-Boost is currently selling for 119€ shipped so I see little point in getting a regular 650Ti, except if its price melts down.

And I'm mapping gamuts via a PS script so I guess this would increase the load as well.

Well I think my Vsync issues on XP are a problem related to the Nvidia drivers. Even with latest WHQL drivers, the refresh rate reported by madVR is all over the place, sometimes falling to 57Hz on a 60Hz screen and sometimes jumping into 62 range, and frame drops occur everywhere. [..] Interesting fact is that all games, for example have perfect Vsync applied.
Oh, did you try using the old rendering path? If mVR with a 600 board is a no-go on XP then I can kiss J3AR goodbye and stick to my "bang for bucks" 8800GS(paid 60€ 5 years ago) that has always worked flawlessly.

[dbcooper]

For some reason, I am getting huge number of frame drops playing some trailers with smooth motion on (24fps->60). For example, this one

http://videos.hd-trailers.net/20130409_elysium_trailer1_4000.mp4

Hmm, just tried the file and I see a target window size of 1920x1140, so it was resized/distorted on my system. (I have a 1920x1200 display.)

[cyberbeing]

I would suggest using this calculator (http://www.avsforum.com/t/1409045/how-power-law-gamma-calibration-can-lead-to-crushed-blacks/0_100#post_22208270) to get the right values for your display.

If that calculator is correct, BT1886 is identical to an sRGB curve if you have a White Level of 120 cd/m2 (35fL) and Black Level of 0.1 cd/m2, with an effective gamma of ~2.22 @ 50% stimulus. Essentially it will never reach an effective gamma of 2.4, unless as 6233638 mentioned, your Black Level is effectively 0 cd/m2 with an insane contrast ratio. Overall this seems to suggest that the BT1886 specification was designed with "Average/Typical" room lighting in mind, with a focus on optimizing for the natural capabilities of the display. Using BT1886 is likely not particularity suitable if you do most of your viewing in "Dim" or "Dark" viewing conditions.

Compared to 32 lux ambient light scaled BT.709 curve in Argyll CMS, it appears BT1886 from that calculator always results in a lower/brighter effective gamma. I'd expect the same if you applied ambient light scaling to the supposed BT1886 settings in Argyll CMS. Argyll CMS uses CIECAM02 math which adapts to your 0% & 100% cd/m2 luminance measurements when scaling to ambient light. This type of ambient light scaling is not something you can mimic with madVR's current implementation of gamma control, so something to keep in mind if you don't do the majority of your watching in a well lighted room.

[6233638]

If that calculator is correct, BT1886 is identical to an sRGB curve if you have a White Level of 120 cd/m2 (35fL) and Black Level of 0.1 cd/m2, with an effective gamma of ~2.22 @ 50% stimulus. Essentially it will never reach an effective gamma of 2.4, unless as 6233638 mentioned, your Black Level is effectively 0 cd/m2 with an insane contrast ratio. Overall this seems to suggest that the BT1886 specification was designed with "Average/Typical" room lighting in mind, with a focus on optimizing for the natural capabilities of the display. Using BT1886 is likely not particularity suitable if you do most of your viewing in "Dim" or "Dark" viewing conditions. It is designed around Just-Noticeable Difference. If your display has X contrast, then it does not support a higher gamma than the BT.1886 curve suggests without compressing levels. (i.e. making the difference between two values indistinguishable)
It's a much better solution than other compensated gamma functions, and is also intended to be used on broadcast monitors, which are typically used in dark conditions, so ambient light is not a factor. (though high levels of ambient light will reduce your display's contrast and change the target curve accordingly)
This type of ambient light scaling is not something you can mimic with madVR's current implementation of gamma controlYou can calibrate to a custom curve via yCMS.

[cyberbeing]

You can calibrate to a custom curve via yCMS.

Not sure what you mean by this. yCMS grayscale measurements + madVR gamma processing will completely ruin the characteristics of anything which is not a pure power-curve.

[6233638]

Not sure what you mean by this. yCMS grayscale measurements + madVR gamma processing will completely ruin the characteristics of anything which is not a pure power-curve.While yCMS targets a 2.20 power curve, if you use Yxy data you can manipulate the Y values to achieve any curve you want. (but you should not use madVR's gamma processing with this)

[cyberbeing]

And that curve will not match the curve produced by Argyll CMS, as I stated above.

yCMS doesn't leave a calibrated custom gamma curve untouched if you use grayscale measurements.
madVR gamma processing scales BT.709 curves in different way compared to Argyll CMS.

[6233638]

And that curve will not match the curve produced by Argyll CMS, as I stated above.

yCMS doesn't leave a calibrated custom gamma curve untouched if you use grayscale measurements.
madVR gamma processing scales BT.709 curves in different way compared to Argyll CMS.If you have a target curve, you can match it with yCMS by using Yxy data and adjusting the Y points until they measure the same as your target.

But you should not use madVR's gamma processing on top of this, because it expects the input to be a 2.2 power curve, and your custom curve is not.

And I would not use anything other than BT.1886 calculated values on my display, as that is now the agreed upon standard for how content is supposed to be viewed.

[Nui]

you can manipulate the Y values to achieve any curve you want. the key word is manipulate. E.g. enter Y, measure what ycms does with it, enter new Y to make ycms (unknowingly) correct gamma to the curve you want.

[cyberbeing]

If you have a target curve, you can match it with yCMS by using Yxy data and adjusting the Y points until they measure the same as your target.

Ah that's what you meant. I've never tried that before since it seemed a bit tedious to do each time you calibrate, but that does sound like it would work.

I just knew that if I used Argyll CMS measurements as yCMS grayscale measurements, and re-measure my display with madVR gamma processing disabled, the curve will no longer match the curve I calibrated to. The only time use of yCMS grayscale measurements will match, is if I calibrate to a pure power-curve in Argyll CMS. From what I recall, the problem is that yCMS is unable to accurately linearize and recreate custom gamma curves specified though grayscale measurements. This is why I've always used yCMS with gamut measurements only and gamma processing disabled, as it was the simplest way to maintain a custom gamma curve untouched.

[6233638]

Ah that's what you meant. I've never tried that before since it seemed a bit tedious to do each time you calibrate, but that does sound like it would work.Well that's basically how you calibrate a display anyway. Measure the value, make a change, measure the change, until it's as close to your target as possible.

There are automated processes for calibrating some devices (or profile-based calibration on a PC) but I have yet to find a package that does as well as calibrating by hand.

In most cases you don't need more than 10 point control (unless something is seriously wrong with your display) so it's not that time consuming anyway.

This is why I've always used yCMS with gamut measurements only and gamma processing disabled, as it was the simplest way to maintain a custom gamma curve untouched.And I do the opposite - I avoid using gamut correction because yCMS is only useful when there are large errors. yCMS itself often introduces errors when using gamut correction, so I only use it when absolutely necessary.

I only use yCMS for gamma correction, and leave grayscale and gamut alone. (I use the display controls for that)

I have tried ArgyllCMS several times over the years with a number of different meters and displays, and I have never found it to produce good looking profiles. They might measure well, but they look bad. (they don't give smooth results and often posterize)

[e-t172]

It will look too dark on an LCD because you need at least 10,000:1 native contrast before you can use 2.40 gamma without significantly crushing shadow detail.
I'm not sure that you have interpreted the BT.1886 spec correctly - you shouldn't be anywhere near a 2.40 gamma when your display only has 850:1 contrast.
I would suggest using this calculator (http://www.avsforum.com/t/1409045/how-power-law-gamma-calibration-can-lead-to-crushed-blacks/0_100#post_22208270) to get the right values for your display. (you need to set white and black level in the top left - don't touch anything else)If you are able to write to the monitor LUT directly, I would use that for calibration rather than any of the options inside madVR. (just tell madVR that the display is already calibrated to BT.709/2.2 power, so that it only performs colorspace transformations)

That might be my fault, actually. Earlier in this thread I said that BT.1886 is in fact nothing less than Power law + BLC (Black Level Compensation). I said that intuitively by looking at the formula without bothering to check my math. I was terribly wrong, as the calculator clearly shows.

As a matter of fact, the calculator indicates that for a typical H-IPS monitor (1000:1 contrast ratio), the BT.1886 curve is actually much closer to 2.2 pure power law than 2.4… in that regard 6233638 is completely right. If you have a limited-contrast monitor and want to be as close as BT.1886 but can only set a pure power curve, then your best bet is on 2.2, not 2.4. The only situation where 2.4 is to be used is when you have infinite contrast (i.e. CRT, maybe plasmas, OLED).

So for most people with LCD, disregard what I said, 2.2 is what you want. Or even better, use the actual BT.1886 curve, with appropriate parameters from the black and white levels of your display. Unfortunately, madVR doesn't have support for the BT.1886 curve (yet).

Something to keep in mind: just so that we're clear, from a luminance standpoint, when you're setting a target gamma in madVR, what you end up targetting is a black compensated power law, not a pure power law - so you should be looking a the BLC curve in the calculator that 6233638 linked. The rationale is that madVR cannot target a pure power law because it doesn't know your display's black level. But even if it did, trying to target a pure power law on a display with a non-zero black level would obviously result in black clipping, which is bad. According to the thread 6233638 linked, black compensation avoids that, but crushes dynamic range instead. BT.1886 would then be an attempt at defining a curve that brings the best of both worlds. Note, however, than a black compensated curve is actually closer to BT.1886 than a pure power curve.

[6233638]

Something to keep in mind: just so that we're clear, from a luminance standpoint, when you're setting a target gamma in madVR, what you end up targetting is a black compensated power law, not a pure power law - so you should be looking a the BLC curve in the calculator that 6233638 linked. The rationale is that madVR cannot target a pure power law because it doesn't know your display's black level.I think you have it the other way around - without knowing the black level, you cannot use a black level compensated gamma value.BT.1886 would then be an attempt at defining a curve that brings the best of both worlds. Note, however, than a black compensated curve is actually closer to BT.1886 than a pure power curve.This post (http://www.avsforum.com/t/1409045/how-power-law-gamma-calibration-can-lead-to-crushed-blacks/100_100#post_22253013) is a pretty good indicator of why BT.1886 is better than a black level compensated power curve though. Now that BT.1886 exists, I don't see a reason to calibrate to anything else (for HT purposes at least) if you have the ability to.

[therock003]

Will there ever be an x64 build for madVR so i can use it with mpc x64? Also i have a notebook with IntelHD graphics, and upscaling sd with jinc 3-passes gives seriously low performance. Do i need strong hardware in order to be able to get decent upscale performance?

[ryrynz]

Will there ever be an x64 build for madVR so i can use it with mpc x64?

Quite likely yes, but not anytime soon (probably a couple of years) you'll just have to use MPC x86 instead.


Also i have a notebook with IntelHD graphics, and upscaling sd with jinc 3-passes gives seriously low performance. Do i need strong hardware in order to be able to get decent upscale performance?

Yes you do, especially with Anti-Ringing enabled. Use Lanczos 3 taps instead and look to change your Chroma to Bicubic 75 both settings without Anti-Ringing enabled if need be.

[therock003]

Yes you do, especially with Anti-Ringing enabled. Use Lanczos 3 taps instead and look to change your Chroma to Bicubic 75 both settings without Anti-Ringing enabled if need be.

Well Playback on these settings was smooth and i even had antiringing on with lanczos. But i didnt notice any difference between this and EVR. I had one process of x86 with madVR and the x64 with eVR at the same time, and freezed the same frame and alternate the windows on fullscreen, but i couldnt notice any difference :(

[e-t172]

I think you have it the other way around - without knowing the black level, you cannot use a black level compensated gamma value.

No, actually, I stand by what I said. The calculator results are expressed in terms of absolute luminance, as well as BT.1886. However, madVR is unable to target some absolute luminance because it doesn't know what the luminance of 0% and 100% is. When you specify a pure power curve in madVR, it is applied in terms of pixel values, not luminance. So in the end, the output of madVR, after the pure power curve has been applied, is offset by the monitor's black level (madVR pixel value 0 = monitor black level). And when you offset a pure power curve with the monitor's black level, you get… a black-compensated power curve. QED.

The important thing here is that when configured in madVR a pure power law is applied to pixel values, but luminance ≠ pixel value. Instead, luminance = a*(pixel value)+b. The resulting luminance follows a black-compensated curve, even though the pixel values follow a pure power curve.


This post (http://www.avsforum.com/t/1409045/how-power-law-gamma-calibration-can-lead-to-crushed-blacks/100_100#post_22253013) is a pretty good indicator of why BT.1886 is better than a black level compensated power curve though. Now that BT.1886 exists, I don't see a reason to calibrate to anything else (for HT purposes at least) if you have the ability to.

I totally agree, but considering very few calibration solutions support BT.1886 right now, most people won't have this ability. A good first step would be to have BT.1886 support in madVR, so that BT.1886 can be used even with a monitor using a different curve (e.g. black-compensated pure power law, sRGB function).

[ryrynz]

i didnt notice any difference between this and EVR.

If you take a screenshot of each one and enlarge a portion of it you'll be able to more easily see the difference, it may be hard to notice the differences on a "small" screen especially to an untrained eye.

[therock003]

If you take a screenshot of each one and enlarge a portion of it you'll be able to more easily see the difference, it may be hard to notice the differences on a "small" screen especially to an untrained eye.

Well the point is that the difference in quality should be significant so that you can notice it live as youre watching the video, and note examine a frame in detail to see the better results. Anyway how can a capture a full screen so i can post it, and analyze the differences. I'm using mpc but i think saving an image, it saves it at native resolution and not the upscaled fullscreen image.

[Niyawa]

Well the point is that the difference in quality should be significant so that you can notice it live as youre watching the video, and note examine a frame in detail to see the better results. Anyway how can a capture a full screen so i can post it, and analyze the differences. I'm using mpc but i think saving an image, it saves it at native resolution and not the upscaled fullscreen image.
This is true. But as some said, you need a trained eye for that. Some people will see the difference (they claim it's around 6-10%) others will just say it's not worth it. In any case, I've been using madVR for more than a year and a half now. Whenever I see EVR-CP I can somewhat see a blurry or distorted red, it seems like the colors are not vibrant as they should. Maybe this is my own self-inserted placebo effect, but it happens. The real thing really changes when we make upscaled screenshots comparison though.

You can use Print Screen and paste the copied image in a image editor, Paint will do. Save in .png of course.

[madshi]

Thanks for the explanation.
But wouldn't it possible to "talk" with LAV Filters ?
For what exact purpose?

It's always unchecked, doesn't change anything. Also whenever I switch to fullscreen exclusive mode, my GPU(ATI HD6850) load skyrocket to 80%.
I think I messed up somewhere, not sure what it is though.
That sounds weird. Maybe you could try uninstalling/reinstalling the GPU driver, or maybe there's a way to reset the GPU driver to default settings?

allow me to ask whether the AR filename tag is on your current todo list ?
Yes.

With extended displays EVR has the same problem and it uses the primary displays composition rate. Disabling composition fixes this, is there a way to ignore composition in this type of situation with madvr?
If composition is enabled (and it can't be disabled in win8) and if you're not using overlay or FSE, then there's no way to "ignore" composition. Direct3D is redirected to composition internally in the OS in that situation. No way around it, except by disabling composition, using overlay or FSE.

However switching from one display to another with different refresh rates, evr handles fine, madvr doesn't and it uses the first displays composition rate.
If EVR can handle this then it might be considered a madVR bug. So please create an entry in the bug tracker, with an attached log file and a detailed description how to reproduce it (how to setup dual monitor so that the issue occurs etc). I can't promise I'll look at this soon, though, because multi-monitor issues are really hard for me to debug cause my development PC doesn't have a dual monitor setup. Please also write into the bug tracker description whether the problem does not occur if you directly start a new media player instance on the target monitor. (Probably it will work fine then?)

Here's a log (http://www.sendspace.com/file/x8no4e) for display changer not working after using cru. nvidia CP and nircmd works fine.
According to the log your monitor has no display modes listed to switch to. My best guess would be that the cru utility results in madVR detecting a new display. Check the device stuff in the madVR settings.

edit2: OTOH if aero peek worked with overlay I'd use it most of the time. Is this possible?
You'd have to ask Microsoft about that.

Does anyone have any idea how a Intel i5-4570R, i5-4670R or a i7-4770R with the new Haswell HD 5200 (GT3e) will perform with MadVR? Might consider a Mini-ITX Media Center running Media Browser + MPC-HC if the performance is good enough.
madVR already works pretty well with Intel HD4000 GPU. Of course there are limits, e.g. it definitely won't do 60p Jinc3 resizing etc. But if you're willing to make a few compromises with the scaling algorithms, it should work very well. The Haswell graphics will likely be a bit faster than HD4000, but not worlds faster, so I believe you'd still have to accept some compromises with Haswell, as well. Haha! With "[H][as][well] as well". If you don't want to make any compromises you'll likely have to go with a NVidia 660 or something with similar power from AMD. And even that is only with the current madVR algorithms. I don't know whether maybe in the future there'll be new algorithms which consume even more power.

If I have the option to choose an extremely close approx. refresh with very small deviations on my monitor to the native frame rates like 23.976fps, 25fps or 29.970fps AND also a multiple for all of them, what would I go for?
What looks best to your eyes. There's no general answer to your question, it all depends on the exact hardware (GPU and display) you're using. Simply try both and trust your eyes.

Well I think my Vsync issues on XP are a problem related to the Nvidia drivers. Even with latest WHQL drivers, the refresh rate reported by madVR is all over the place, sometimes falling to 57Hz on a 60Hz screen and sometimes jumping into 62 range, and frame drops occur everywhere. I just tested madVR on another machine with Intel HD4000 Ivy Bridge graphics, exact same software setup as my PC and it works flawless, no Vsync issues and I just watched a film with 0 frame drops on it. I guess Nvidia messed something up on XP and 600 series drivers. Interesting fact is that all games, for example have perfect Vsync applied.
Ah, XP. I don't really know what's going on, nobody else except you seems to have this specific problem. It could be a driver problem, but then why does nobody else suffer from it? I believe there are still several people on XP (although the number is decreasing). It's quite possible that your hardware has a problem. You could try getting a comparable GPU from a different manufacturer, or even the same GPU from the same manufacturer, and then sell your current GPU on ebay. It could also be a problem related to XP. Maybe reinstalling XP would solve the problem, but doing that is no fun, of course.

Anyway, there's really not much I can do. It's pretty clear that the vsync scanline information your GPU/driver reports are very unreliable. Games are not using that information, but madVR needs it.

I have a GTX 650 Ti and noticed that the included madNvLevelsTweaker.exe utility has the added benefit of fixing the Nvidia HDMI audio "not plugged in" problem after resume from sleep/TV turned off and back on (normally requires a restart).
Really?? I'm surprised...

Not knowing how the madNvLevelsTweaker.exe utility is working, is it safe to run multiple times (eg every time I resume from sleep)?
Yes, it should be safe.

Hi guys, have a quick question about DVD playback.

Many PAL DVD's are 25fps progressive but flagged as 50i, where the frames are progressive (at 25fps) but are played twice to give 50fps.

Can I simply deselect "automatically activate deinterlacing when needed" and safely have the video played as 25p?
For most PAL DVDs deactivating deinterlacing should result in perfect 25p. However, there are a few odd DVDs where parts of the movie, or even the full movie would be full of weaving (interlacing) artifacts this way. The best solution would be to force madVR into film mode deinterlacing. That should always result in perfect 25p output - as long as the movie is true film content. There is some content out there (especially anime) which is field blended, though. For such content you can't use madVR's film mode, nor can you deactivate deinterlacing, for such content you need to use full video mode DXVA deinterlacing.

What a pity.
I noted (MadVR + Lav (Jriver)) the following distribution in terms of use of machine resources (in average and with Bicubic/Lanczos).

GPU (hd4000) : 60%-80%
CPU (i7 3370): 5%-10%

Many people are moving towards a fanless configuration (w/o any graphic card).
You can't have a PC without any GPU. Such a PC would not be able to drive any monitor. What you probably mean is that many people are moving towards a PC with a built in GPU (e.g. Intel's HD4000 GPU).

It would be nice that developers balance their codes load between CPU and GPU.
Currently, most of codes are GPU oriented. Not sure this is the better choice.
CPU and GPU are very very different designs. The CPU is ideal for some algorithms, but not so good for other algorithms. Same with the GPU. All algorithms where every pixel runs through the same calculations are perfect for the GPU and would run rather slowly on the CPU. E.g. Jinc3 scaling would never run in full speed on a GPU, I believe, not even on the fastest (consumer) CPU available.

My personal opinion is that video decoding should ideally be done via CPU and then all video image algorithms should run on the GPU. And that's a solution which is absolutely possible with madVR to achieve. The current integrated GPUs are still relatively slow. But their performance is increasing much faster compared to the increase in CPU performance. So a few years from now GPU performance will probably be multiple times that of today. So in the long run the design chosen for madVR will play out to be the right one.

Maybe someday I'll offer to run some parts of madVR on the CPU instead of the GPU, but in order to do that I'd have to rewrite every algorithm for the CPU. So it would be a LOT of work. So if it ever comes it will be a long time from now.

I'm using LAV video decoder + MadVR, and am wondering which hardware decoding setting to choose in LAV.

With MadVR, which hw-decoding is recommended? DxVA2 native or copy-back?
Personally I recommend software decoding, if your GPU is fast enough. If you want to use hw decoding, "native" should probably perform faster than "copy-back".

BTW, could the MPEG1 chroma be properly aligned with a simple PS script? :o
That should be possible, although it might be ever so slightly lower quality then if done right in the first place.

Well the point is that the difference in quality should be significant so that you can notice it live as youre watching the video, and note examine a frame in detail to see the better results.
madVR does have a number of advantages over EVR, but not all of them are obvious. Some image quality advantages only show in certain kinds of scenes. E.g. differences in chroma upsampling show well with scenes where there's lots of contrasty red and black stuff. E.g. red fonts on black background. Or advantages in color processing bitdepth and dithering only show if you have content with very smoothly blended gradiants. Or advantages in scaling algorithm only show if you actually use scaling, and hopefully more than just by a small amount. The higher the scaling factor, the bigger the differences. Or the madVR anti-ringing filter can only show its benefits if you scale videos which have high contrast edges.

Maybe some day I'll provide a collection of test samples which demonstrate where madVR beats EVR noticeably. It's a bit difficult, though, because if I use Hollywood movie samples for that, I could run into legal trouble.

madVR also has some other advantages over EVR. E.g. if your display can only do 60Hz, but doesn't support 24Hz, then only madVR allows smooth playback (without 3:2 pulldown judder) of Blu-Ray movies on your display. EVR can't do that. Or madVR has a better seeking behaviour. Or madVR has a built in refresh rate switcher. Or madVR has the best IVTC algorithm built in that is available in the HTPC world (as far as I know).

For some reason, I am getting huge number of frame drops playing some trailers with smooth motion on (24fps->60).
Don't see frame drops here with my Intel HD4000 GPU. Which queues are near empty when those frame drops occur? Have you tried in fullscreen exclusive mode?

[DragonQ]

Or madVR has the best IVTC algorithm built in that is available in the HTPC world (as far as I know).
Well there's surely room for improvement, considering almost all of my 25p-inside-25i streams cause MadVR to activate deinterlacing - it's fortunate that my GPU handles this properly. I don't think I've ever seen MadVR activate IVTC automatically, unless I'm just misunderstanding the OSD.

[nevcairiel]

Better than those found in GPUs though? ;)

The ones in GPUs are rather limted, you can be lucky if it handles 3:2 properly, any other cadence will most like just not work - and not to mention that it doesn't decimate after the IVTC, so you can't get 24p out of a telecined 29.97 fps movie.
So yes, much better.

The only thing missing is auto-detection, so i don't need to manually force it. :)

[DragonQ]

Quicker than a flash...