madVR - high quality video renderer (GPU assisted)

[Plutotype]

I noticed that when playing 1080p24 (mkv, m2ts, ts .. full screen exclusive mode, default settings) my screen goes to 23hz. Because of this, there is a drop frames every 30-40 sec.

If I uncheck 'Present Several frames in advance "(old path), my screen stays in 24hz.

Is it related to Windows 8, Desktop Window Manager (DWM)?

Hi
Can you please post up your display modes settings from MadVR?

Mine are as follows. I have never experienced wrong display refresh rate switching ( assuming your screen supports them ):
1080p23, 1080p24, 1080p30, 1080p60, 1080p59, 1080p50

Thanks

[6233638]

I noticed that when playing 1080p24 (mkv, m2ts, ts .. full screen exclusive mode, default settings) my screen goes to 23hz. Because of this, there is a drop frames every 30-40 sec.

https://lh4.googleusercontent.com/-WCZJVHwvo0E/UXzRP6TYSLI/AAAAAAAABXE/lpPBshci9ac/s400/fse_newpath.jpg

If I uncheck 'Present Several frames in advance "(old path), my screen stays in 24hz.

https://lh5.googleusercontent.com/-oCUIT5D2MC4/UXzRUg5udOI/AAAAAAAABXM/jnfJUQWz_o8/s400/fse_oldpath.jpg

Is it related to Windows 8, Desktop Window Manager (DWM)?Just tested this here, and you are correct. If my display is already at 24Hz, the madVR refresh rate switcher changes to 23Hz in windowed mode or the new exclusive mode. But if I use the old exclusive mode and tell it to only switch when going fullscreen, it stays at 24Hz.

Unfortunately this doesn't affect it switching from another refresh rate to 24Hz - that still switches to 23Hz. So it's still broken on Windows 8 even if you use the old FSE mode.
And I actually had to stop using FSE mode because it conflicts with JRiver Media Center's OSD.


I have noticed similar behavior with JRiver's refresh rate switcher too: http://yabb.jriver.com/interact/index.php?topic=80014.msg545365#msg545365
JRiver's switcher works better for me than madVR's, because it can at least restore to 60Hz correctly, rather than restoring to 59Hz.

But it doesn't seem to get IVTC information from madVR so interlaced content is played at 50/60Hz rather than 24Hz.

Can you please post up your display modes settings from MadVR?

Mine are as follows. I have never experienced wrong display refresh rate switching ( assuming your screen supports them ):
1080p23, 1080p24, 1080p30, 1080p60, 1080p59, 1080p50Switching works correctly on Windows 7, it's broken on Windows 8.

I have madVR set up so that it only has:
1080p24, 1080p50, 1080p60 but it switches to:
1080p23, 1080p50, 1080p59

The composition rate is set correctly, but not the refresh rate.

[cvrkuth]

Mine display modes settings from MadVR are same as yours: 1080p23, 1080p24, 1080p30, 1080p50, 1080p59, 1080p60

I suspect the OS, I use Windows 8 Pro.

[6233638]

Mine display modes settings from MadVR are same as yours: 1080p23, 1080p24, 1080p30, 1080p50, 1080p59, 1080p60

I suspect the OS, I use Windows 8 Pro.The Nvidia control panel is able to switch to 24/60Hz correctly though, so it's not that the OS can't do 24/60Hz. Something must have changed with how refresh rate switching works though.

The "good" thing about this, is that your post finally confirms what I had been unable to get an answer for - the problem is not specific to Nvidia cards, and affects AMD (and likely Intel) too. Previously it had been suggested that this was a driver bug, but I find unlikely that both Nvidia and AMD have the same bug.

A "fix" for this is to run ReClock or JRiver's VideoClock which will eliminate the stuttering caused by the framerate/refreshrate mismatch.

But I wish someone could figure out why the refresh rate switcher isn't working correctly so that we can get 24/60 back.

23Hz on my card outputs 23.970.. but 24Hz is 24.0000.

[cvrkuth]

The Nvidia control panel is able to switch to 24/60Hz correctly though, so it's not that the OS can't do 24/60Hz. Something must have changed with how refresh rate switching works though.

Same as Catalyst Control Center... no problem with that..

Currently, I experiment with JRiver's VideoClock, looks like it could be a solution for now.

[pbreak]

Hi

have you guys seen anything like this?

http://i.imgur.com/cAGFT5w.jpg


It's like invisible little frames, box, i don't know...


I'm using Potplayer, ffdshow, madvr.

[namaiki]

Can the issue be reproduced with a different video renderer or in a different program that isn't using madVR?

[pbreak]

Can the issue be reproduced with a different video renderer or in a different program that isn't using madVR?


No matter what renderer i choose, overlay, evr, madvr, haali.... this 'thing' is always there.

Maybe a directx problem? i don't know, i need help :D

[namaiki]

Does it occur in all videos or just this one? I'm guessing it's probably just an artifact in that video.

[v0lt]

Spoils window caption in the MPC-BE and MPC-HC.

EVR-CP (norm)
http://i.imgur.com/pOYjSXEs.jpg (http://i.imgur.com/pOYjSXE.jpg)

madVR (bad caption)
http://i.imgur.com/e97GBsms.jpg (http://i.imgur.com/e97GBsm.jpg)

Sample: davichi cut.zip (http://pan.baidu.com/share/link?shareid=454759&uk=3558042035)

[iSunrise]

No matter what renderer i choose, overlay, evr, madvr, haali.... this 'thing' is always there.

Maybe a directx problem? i don't know, i need help :D
Not sure what kind of help you´re expecting if you have the same artifacts with every combination (if you actually did test all of these already) of renderers. I would blindly have guessed some hardware decoding issues related to DXVA, so you need to try software decoding first. If there´s no problems with software decoding, there´s something about that file that isn´t compatible. Otherwise (if that issue is still there with software decoding) you either have a corrupted file (corrupted frames) altogether or some issues with your graphics card`s hardware decoder (if you´re actually using DXVA).

You can also try LAV filters instead of ffdshow.

Also, try it out for yourself or give us a sample so we can double-check.

PS: That screenshot has a resolution of 1.425px × 671px. Is that a resize? Looks quite horrible.

[alamagar]

Hi all:

I use MPC-HC with madVR and I have 2 different displays: a plasma TV and a projector. I have an AVR between HTPC and the displays.

I defined the 2 different displays in madVR connected to the AVR but I need to indicate different settings in calibration options because each of them has been calibrated with a specific 3dlut file.

Is there a way for madVR to automatically switch for each display recognizing wich one is attached at a given moment?

Now I switch to the target display manually but it is a nuisance and time wasting.

[dansrfe]

Is there a way for madVR to automatically switch for each display recognizing wich one is attached at a given moment?

madVR tray -> Edit madVR Settings... -> devices

[alamagar]

madVR tray -> Edit madVR Settings... -> devices

You mean go to tray icon and change it manually?

AFAIK this is the same than entering madVR settings from inside MPC-HC, therefore still manual...

Or perhaps I misunderstood something.

[karamancho]

If you have older drivers installed, maybe try disable "present frames in advance". In the same case of having older drivers installed, you can also try enabling smooth motion which technically is not the same thing at all, but helped me when I did not want to update my drivers. You could try either one of the options for testing, but based on my own configuration, I don't think enabling both is a good idea. In the case of the 'present frames in advance' option, you will need to close and reopen the video for any changes to take effect.

updating the driver significantly reduced the number of presentation glitches, disabling the 'present frames in advance' in the settings removed presentation glitches from the OSD (so I'm not sure if they are non-existent or just hidden from the OSD). smooth motion just made everything worse so it's off for now.

You can get a volume indicator in madVR if you are using MPC-HC by enabling the OSD. (View-> Options-> Player-> tick Show OSD)
edit: If you mean a way to change the volume by using the mouse only while in exclusive mode, you can also try use your scroll wheel or two finger scroll if you have a touchpad.

OSD in MPC-HC already displays the volume when you change it. I was asking for an indicator (somewhere on the seek bar) that would show the current volume level, thats all

[Budtz]

Every once in a while when i close mpc-hc - madvr, reclock and ffdshow dosnt close with it. this means that i cant start another video and have to reboot. can an1 help here?

[seriouser]

Every once in a while when i close mpc-hc - madvr, reclock and ffdshow dosnt close with it. this means that i cant start another video and have to reboot. can an1 help here?

Ctrl+Alt+Delete, Start Task Manager, go to Processes and shut down MPC-HC.exe manually.

[6233638]

Every once in a while when i close mpc-hc - madvr, reclock and ffdshow dosnt close with it. this means that i cant start another video and have to reboot. can an1 help here?This used to happen quite often, but hasn't happened to me for a long time now. Make sure that you have everything up to date, and you might want to switch from ffdshow to LAV Filters.

Ctrl+Alt+Delete, Start Task Manager, go to Processes and shut down MPC-HC.exe manually.Ctrl+Shift+Esc will take you directly to the task manager.

[seriouser]

First of all huge thanks to madshi for coming up with Smooth Motion. I bought a Panasonic plasma that has horrendous false contouring in both 24hz and 50hz modes that I unfortunately can't return.

Using Smooth Motion has resolved almost all possible problems I had with the 24hz and 50hz modes @ 60Hz. Only thing that could be improved upon is a bit of ghosting or double images that occurs when objects move quickly across the scene or end end credits that roll down quickly.

The settings I'm using now are:

-exclusive mode
-separate devices for presentation and dxva
-cpu queu 32
-gpu queue 24
-present several frames in advance
-16 frames presented in advance

I've got an i7 950 @ 4GHz and a GTX 670 4GB so performance shouldn't be a problem. Also I'm using LAV filters with CUVID, Reclock and the latest 320.00 drivers.

I've been using Jinc3 AR for chroma upscaling and Bilinear for image upscaling but they don't seem to make much of a difference on the ghosting.

Are there any more settings that could possibly have an effect on the ghosting? I've read madshi's posts where he says that there shouldn't be any ghosting if madvr is working correctly so I'm wondering if I'm doing something wrong somewhere.

[river1]

Hi, madshi. I'm wondering what will madVR do with 24p content when the refresh rate is 60Hz. 2:3 pulldown?
I recently got a TV that can detect pulldown patterns and do IVTC quite correctly when refresh rate is not 24Hz. And I tried 24p video with 60Hz refresh rate using EVR, it's as smooth as playing 24p video with 24Hz refresh rate. But when I use madVR, the video keeps shaking. I think EVR is using 2:3 pulldown and TV can detect correctly, and madVR is using some kind of pulldown pattern that cannot be detected by TV.
BTW, I only play vfr videos with 60Hz refresh rate.

[ryrynz]

I've been using Jinc3 AR for chroma upscaling and Bilinear for image upscaling


I sure hope you meant that the other way around.

[Graeme Gill]

Hi, I'm trying to create some .3dlut files to accurately manage the color output of MadVR V 0.861, and am a bit in the dark as to how it is interpreting the media colorspaces. As an example, for a SD PAL encoded source, if I create and then select a NOOP.3dlut and send a 128/255 = 50.2% grey through the system (using MPC_HC, no gamma & color processing) I end up with a pixel value of 130.36/255 = 51.12% on average. If I assume that the color values being fed into the 3dLut are encoded with a gamma of 2.2 (as indicated in this post http://forum.doom9.org/showpost.php?p=1510363&postcount=637), this implies that the PAL material is assumed to have a gamma of 2.13 (.5112 ^ 2.2 = 0.2285, log(.2285)/log(.5) = 2.13).

PAL has a very poorly specified encoding transfer function :- Poynton recommends using the Rec709 transfer function (see Digital Video and HDTV Ch. 23, pp 269). A Rec709 encoding of 50.2% input would be 25.99%, or an equivalent gamma of 1.945. So interpreting it as gamma 2.13 is adding nearly 1.1, noticeably increasing the image contrast.

Is there a document that details what transfer functions MadVR is assuming for each type of meda (SD PAL, SD NTSC, HD), so that I can properly formulate the color handling in the 3dLut ?
Thanks.

[leeperry]

Ouh, Graeme Gill's in the house :)

If there were a way to create a mVR-compatible 3DLUT from within ArgyllCMS without the usually associated potential source of headaches, this would be pretty darn sweet :cool:

[madshi]

@Graeme,

madVR itself creates 3dlut files via yCMS with the following script:

Input_Primaries %redx% %redy% %greenx% %greeny% %bluex% %bluey% 0.31272661468101209 0.32902313032606195
Output_Primaries %redx% %redy% %greenx% %greeny% %bluex% %bluey% %whitex% %whitey%
Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0
Input_Range 16 235
Output_Range 16 235
Input_Bit_Depth %settings%
Output_Bit_Depth 16

Unfortunately, when defining the 3dlut file format we failed to properly store the input/output primaries in the header. So currently madVR requires these to be written in clear text to the "parametersData" field. madVR then reads the "input primaries" values from there and converts any sources to these primaries before running them through the 3dlut. It is recommended to choose input primaries which are near to the measured display primaries because after some experiments this seemed to produce the best results.

In terms of transfer function madVR expects the 3dlut to use a pure power curve of 0.45454545454545454545454545454545 for both input and output. If you can't seem to get correct results then maybe you have some sort of gamma processing active in the madVR settings?

If you have any more questions/problems, you can also email me directly at madshi (at) gmail (dot) com.

P.S: Unless you activate "enable gamma processing" in the "color & gamma" tab of the madVR settings, madVR does not modify the gamma of the source, when using an external 3dlut file. That means that decoded video is converted to RGB, then fed to the 3dlut with the unmodified gamma. FWIW, the 3dlut input/output is supposed to be gamma corrected light, not linear light.

[n3w813]

YES! Graeme and Madshi working together to enable generation of 3dluts from ArgyllCMS that can be used in MadVR!!! :D I think I just creamed my pants a little bit....

[Plutotype]

First of all huge thanks to madshi for coming up with Smooth Motion. I bought a Panasonic plasma that has horrendous false contouring in both 24hz and 50hz modes that I unfortunately can't return.

Using Smooth Motion has resolved almost all possible problems I had with the 24hz and 50hz modes @ 60Hz. Only thing that could be improved upon is a bit of ghosting or double images that occurs when objects move quickly across the scene or end end credits that roll down quickly.

The settings I'm using now are:

-exclusive mode
-separate devices for presentation and dxva
-cpu queu 32
-gpu queue 24
-present several frames in advance
-16 frames presented in advance

I've got an i7 950 @ 4GHz and a GTX 670 4GB so performance shouldn't be a problem. Also I'm using LAV filters with CUVID, Reclock and the latest 320.00 drivers.

I've been using Jinc3 AR for chroma upscaling and Bilinear for image upscaling but they don't seem to make much of a difference on the ghosting.

Are there any more settings that could possibly have an effect on the ghosting? I've read madshi's posts where he says that there shouldn't be any ghosting if madvr is working correctly so I'm wondering if I'm doing something wrong somewhere.

Thanks for your feedback regarding the DFC issue, this is something I was mentioning over the hdtvtest forum as benefit of the smooth motion feature in madVR.

1. Can you please post your Panasonic plasma model?
2. Double imaging you mean something like below? Im sorry, but Im afraid you cant solve this by any setting in madVR.
http://i1281.photobucket.com/albums/a509/Plutotype/DSC01006_zpsf508d708.jpg

[Aleksoid1978]

Spoils window caption in the MPC-BE and MPC-HC.

EVR-CP (norm)
http://i.imgur.com/pOYjSXEs.jpg (http://i.imgur.com/pOYjSXE.jpg)

madVR (bad caption)
http://i.imgur.com/e97GBsms.jpg (http://i.imgur.com/e97GBsm.jpg)

Sample: davichi cut.zip (http://pan.baidu.com/share/link?shareid=454759&uk=3558042035)

using madVR broken call SetWindowText() in MainWindow

[Graeme Gill]

@Graeme,

Unfortunately, when defining the 3dlut file format we failed to properly store the input/output primaries in the header. So currently madVR requires these to be written in clear text to the "parametersData" field. madVR then reads the "input primaries" values from there and converts any sources to these primaries before running them through the 3dlut. It is recommended to choose input primaries which are near to the measured display primaries because after some experiments this seemed to produce the best results.


Hi,
I understand, but this then means that if the input primaries are different to the source media primaries, MadVR will (presumably) clip the gamut. By setting the input primaries to the source medias primaries instead, I can handle the gamut mapping in other ways in the 3dLut.

One of the problems with MadVR V0.861 is that there is only one entry for the .3dLut, whereas ideally there should be one for each source media type, so that the user doesn't have to manually switch source optimized 3dluts when they play different types of media.

One of the things that is unclear is what primaries MadVR is using for each source type. Can you confirm that it is using Rec709 YCbCr + Rec709 primaries for HD ? Is it using Rec601 YCbCr + SMPTE RP 145 primaries for SD NTSC ? Is it using Rec601 YCbCr + EBU 3213 primaries for SD PAL ?


In terms of transfer function madVR expects the 3dlut to use a pure power curve of 0.45454545454545454545454545454545 for both input and output. If you can't seem to get correct results then maybe you have some sort of gamma processing active in the madVR settings?

P.S: Unless you activate "enable gamma processing" in the "color & gamma" tab of the madVR settings, madVR does not modify the gamma of the source, when using an external 3dlut file. That means that decoded video is converted to RGB, then fed to the 3dlut with the unmodified gamma. FWIW, the 3dlut input/output is supposed to be gamma corrected light, not linear light.


OK - this is what I was finding confusing - saying that the input of the 3dLut is a pure power curve of 1/2.2 is in direct contradiction to saying that the input values to the 3dLut are straight from the media source (presumably after doing Rec601 YCbCr to RGB conversion for SD, and Rec709 YCbCr for HD). But that comes close to what I'm measuring, so I'll assume the latter.

I think I figured out the discrepancy - I was using Sony Vegas to create the DVD, and its color values turn out to be Video level (16-235), even though it's showing them as-is on the computer display (very weird thing to do, but it makes it straightforward to check exact values). So my 50.2% value of 128 is actually a 51.14% test value. It's messing with the color values too (ie. clipping the yellow, etc.), so I'm not sure if it is suitable for creating color test patterns that exercise the full YCbCr colorspace.

[sydlexius]

Hi Madshi,

Are you familiar with the Lightpack (http://www.kickstarter.com/projects/woodenshark/lightpack-ambient-backlight-for-your-displays)Kickstarter project? If so, what are your thoughts?

[cyberbeing]

ideally there should be one for each source media type, so that the user doesn't have to manually switch source optimized 3dluts when they play different types of media.
This is similar to how old versions of madVR functioned. The 3DLUTs back then were doing YCbCr input -> RGB output, TV->PC levels, white point, gamut, and gamma correction. For some reason madshi decided to move from that and push gamut & gamma correction, YCbCr->RGB, and TV->PC levels conversion onto GPU shaders, and now we've had reduced functionality 3DLUTs for the past couple years. In-between the old & new 3DLUT support in madVR, there was a failed idea of using 3DLUTs which did gamut correction to a large gamut (yRGB) which contained all common video gamuts, and then using madVR shaders to do adaption for out-of-gamut colors from yRGB to the actual video gamut (this method failed because madshi was having problems correctly handling out-of-gamut colors via shaders in madVR).

madVR:
(1) input = 8bit Y'CbCr, 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(2) convert -> 32bit float R'G'B', 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(3) convert -> 32bit float RGB, 709 primaries/gamut, linear light, WTW/BTB, D65 White Point
(4) convert -> 32bit float RGB, Display primaries/gamut, linear light, WTW/BTB, D65 White Point
(5) convert -> 32bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma, WTW/BTB, D65 White Point
3dlut:
(6) input = 8bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma (with trilinear interpolation), WTW/BTB, D65 White Point
(7) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, D65 White Point
(8) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, Display White Point
(9) convert -> 16bit int R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point
madVR:
(10) input = 16bit int R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point
(11) dither down to 8bit R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point

Essentially it's now something like above, when using a yCMS created 3DLUT with a 16-235 BT.709 video.


By setting the input primaries to the source medias primaries instead, I can handle the gamut mapping in other ways in the 3dLut.
I'd personally like to see 3DLUT support in madVR go back to this (at least optional), if Graeme Gill is really willing to support creation of specialized 3DLUTs like this from Argyll CMS.

The only downside is how it would once again require a 3DLUT for each source gamut/levels -> destination gamut/levels combination. Very trivial if using a 6bit+trilinear interpolation->16bit 3DLUT (good enough IMHO) as they are less then 2MB each, but 8bit->16bit 3DLUT are 96MB each. I believe that madshi not liking the need to keep multiple 96MB 3DLUTs around to do gamut and levels correction, and the fact that yCMS was not capable of full CMS gamut correction in 3DLUTs, were the main reasons why he ultimately moved away from this in 2011.

[alamagar]

Hi all:

I use MPC-HC with madVR and I have 2 different displays: a plasma TV and a projector. I have an AVR between HTPC and the displays.

I defined the 2 different displays in madVR connected to the AVR but I need to indicate different settings in calibration options because each of them has been calibrated with a specific 3dlut file.

Is there a way for madVR to automatically switch for each display recognizing wich one is attached at a given moment?

Now I switch to the target display manually but it is a nuisance and time wasting.

Hi, again.
Any idea regarding this question other than using madVR tray icon?

[madshi]

I understand, but this then means that if the input primaries are different to the source media primaries, MadVR will (presumably) clip the gamut.
If the source primaries are "wider" then the measured display primaries (= recommended input primaries) then yes, madVR might clip the gamut. However, madVR is feeding black as 16 and white as 235 into the 3dlut, so there is some room (0-15, 236-255) for out of gamut colors, so it's not a straight clip.

By setting the input primaries to the source medias primaries instead, I can handle the gamut mapping in other ways in the 3dLut.
I see. But isn't the BTB/WTW range (madVR sends black as 16, but your 3dlut may contain mappings for 0-15, too) good enough to allow you to do your own mapping? Or is that range not large enough?

One of the problems with MadVR V0.861 is that there is only one entry for the .3dLut, whereas ideally there should be one for each source media type, so that the user doesn't have to manually switch source optimized 3dluts when they play different types of media.
The general idea was for madVR to convert all sources to one specific gamut, so that we only need one 3dlut for all source formats. If you strongly feel that separate 3dluts for separate source gamuts would produce noticeably better results I might consider allowing one external 3dlut file per source gamut.

One of the things that is unclear is what primaries MadVR is using for each source type. Can you confirm that it is using Rec709 YCbCr + Rec709 primaries for HD ? Is it using Rec601 YCbCr + SMPTE RP 145 primaries for SD NTSC ? Is it using Rec601 YCbCr + EBU 3213 primaries for SD PAL ?
madVR has a multi-stage auto-detection. First of all madVR checks if the video bitstream properly identifies the source gamut (this only works for MPEG2, h264 and VC-1). If not, madVR checks if the DirectShow decoder filter reports which gamut the source has. If that also fails, madVR guesses the gamut (EBU, SMPTE-C or Rec709) based on the source resolution and framerate.

The same logic is used for decoding matrix and transfer function.

The above logic is used to find out which gamut the source likely has. This gamut is then converted by madVR to the "input primaries" specified in the 3dlut header.

You can check the madVR OSD (Ctrl+J) to see which primaries and decoding matrix are used. And you can use keyboard shortcuts (e.g. Ctrl+Alt+Shift+P) to toggle the source primaries, in case the auto-detection failed to find the correct gamut.

OK - this is what I was finding confusing - saying that the input of the 3dLut is a pure power curve of 1/2.2 is in direct contradiction to saying that the input values to the 3dLut are straight from the media source (presumably after doing Rec601 YCbCr to RGB conversion for SD, and Rec709 YCbCr for HD). But that comes close to what I'm measuring, so I'll assume the latter.
Sorry, maybe I should be more clear. madVR expects the 3dlut to not modify the transfer function because madVR wants to do such modifications itself in realtime (otherwise you'd have to switch 3dluts everytime the user increases/decreases the gamma value, for example). madVR does not touch the source transfer function when using an external 3dlut file and when madVR's gamma processing is disabled. From what I remember, we found that using a pure power curve inside of the 3dlut processing chain with a gamma value of 2.2 for both de-gamma and en-gamma stages worked quite nicely for all source formats, so that's what madVR usually expects the 3dlut to use. However, you could in theory use any transfer function you like as long as you use the same function for de-gamma and en-gamma, so that the 3dlut doesn't change the overall transfer function.

Not sure, does that clarify things or does it make it even more confusing? :scared:

I think I figured out the discrepancy - I was using Sony Vegas to create the DVD, and its color values turn out to be Video level (16-235), even though it's showing them as-is on the computer display (very weird thing to do, but it makes it straightforward to check exact values). So my 50.2% value of 128 is actually a 51.14% test value. It's messing with the color values too (ie. clipping the yellow, etc.), so I'm not sure if it is suitable for creating color test patterns that exercise the full YCbCr colorspace.
Ah, that makes sense.

[seriouser]

Thanks for your feedback regarding the DFC issue, this is something I was mentioning over the hdtvtest forum as benefit of the smooth motion feature in madVR.

1. Can you please post your Panasonic plasma model?
2. Double imaging you mean something like below? Im sorry, but Im afraid you cant solve this by any setting in madVR.
http://i1281.photobucket.com/albums/a509/Plutotype/DSC01006_zpsf508d708.jpg

It's an European VT50, specifically TX-P50VT50Y and yes it looks a bit like that, not as bad though. Maybe I spend too much looking for possible errors than enjoying the content. :rolleyes:

[DragonQ]

That's weird, I read a lot of reviews of the xT50 series and didn't see any of them that mention bad contouring (which I assume is the same as banding/posterisation).

The "50 Hz bug" is, as I understand it, a symptom of the way plasmas refresh the screen, which requires a minimum of 60 Hz to eliminate flicker. So any 24 Hz or 50 Hz material requires frame doubling (or tripling/quadrupling), thus sometimes artefacts can be seen (kinda like ghost edges). Newer models suffer less but I doubt it's possible for it to be eliminated completely.

This post on the subject (http://www.avforums.com/forums/plasma-tvs/1622359-50-hz-bug-recorded.html) is very informative.

[dansrfe]

I'm buying this screen when it comes to the US: http://www.latimes.com/business/technology/la-fi-tn-lg-curved-oled-tv-20130429,0,6958382.story

[digitech]

I'm buying this screen when it comes to the US: http://www.latimes.com/business/technology/la-fi-tn-lg-curved-oled-tv-20130429,0,6958382.story

I Hope u have $13,500 dls? under your bed.

[dansrfe]

I Hope u have $13,500 dls? under your bed.

By the time it comes to the US it'll probably be around $10K which isn't too bad for an early adopter. They sell it because there are people that are willing to cough up that much money...

[Graeme Gill]

This is similar to how old versions of madVR functioned. The 3DLUTs back then were doing YCbCr input -> RGB output, TV->PC levels, white point, gamut, and gamma correction. For some reason madshi decided to move from that and push gamut & gamma correction, YCbCr->RGB, and TV->PC levels conversion onto GPU shaders, and now we've had reduced functionality 3DLUTs for the past couple years. In-between the old & new 3DLUT support in madVR, there was a failed idea of using 3DLUTs which did gamut correction to a large gamut (yRGB) which contained all common video gamuts, and then using madVR shaders to do adaption for out-of-gamut colors from yRGB to the actual video gamut (this method failed because madshi was having problems correctly handling out-of-gamut colors via shaders in madVR).

Doing sophisticated gamut mapping can't really be reduced to simple equations that could be directly implemented in a shader. That's why it's typically pre-computed and the result stored in a cLUT (Color Lookup Table/N-Dimensional LUT/3DLut).

[SIZE="1"]madVR:
(1) input = 8bit Y'CbCr, 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point

That's true for HD. SD needs EBU-PAL or SMPTE-NTSC primaries.

(2) convert -> 32bit float R'G'B', 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(3) convert -> 32bit float RGB, 709 primaries/gamut, linear light, WTW/BTB, D65 White Point
(4) convert -> 32bit float RGB, Display primaries/gamut, linear light, WTW/BTB, D65 White Point
(5) convert -> 32bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma, WTW/BTB, D65 White Point
3dlut:

I'm not measuring a Rec709 gamma to power 2.2 conversion. It seems like the levels are being passed directly through, but that does leave the puzzle of how the colors are being translated from the media colorspace to the 3dLut input space, since this should be done in linear light. Perhaps power 2.2 is assumed for this conversion ? If so, this is even more reason for using the media primaries as the input of the 3DLut, since it will prevent any slight inaccuracies due to different media gamma encoding assumptions.

I'd personally like to see 3DLUT support in madVR go back to this (at least optional), if Graeme Gill is really willing to support creation of specialized 3DLUTs like this from Argyll CMS.

It's a matter of whether I can make it mesh with what MadVR is presenting the 3DLut. At the moment I'm second guessing, although the results look quite promising.

The only downside is how it would once again require a 3DLUT for each source gamut/levels -> destination gamut/levels combination. Very trivial if using a 6bit+trilinear interpolation->16bit 3DLUT (good enough IMHO) as they are less then 2MB each, but 8bit->16bit 3DLUT are 96MB each. I believe that madshi not liking the need to keep multiple 96MB 3DLUTs around to do gamut and levels correction, and the fact that yCMS was not capable of full CMS gamut correction in 3DLUTs, were the main reasons why he ultimately moved away from this in 2011.

MadVR is unusual in using 256 resolution cLUTs. It is something that is only conceivable in recent years with the advent of very large memories and high processing bandwidth. Most other systems that were originally developed on more limited hardware use much lower resolution - 33 being typical in the graphic arts which also use per channel curves as well, to reduce the demands on the cLUT. For video work, 65 is a nice number, because the grid point match well with the 16-235 video encoding range points. That's what I'm defaulting to for the eeColor and MadVR ICC device links (==cLUT/3DLut), and then upsampling the device link to the MadVR 256 resolution 3dLUT using the standard tetrahedral interpolation provided by icclib (littleCMS has similar capabilities).

[Graeme Gill]

If the source primaries are "wider" then the measured display primaries (= recommended input primaries) then yes, madVR might clip the gamut. However, madVR is feeding black as 16 and white as 235 into the 3dlut, so there is some room (0-15, 236-255) for out of gamut colors, so it's not a straight clip.
But isn't the BTB/WTW range (madVR sends black as 16, but your 3dlut may contain mappings for 0-15, too) good enough to allow you to do your own mapping? Or is that range not large enough?

Hi,
I'm not sure how that could be used. 16-235 is a device space encoding :- the logical device ranges remain unchanged at 0.0 - 1.0. To put it another way, the encoding is invisible to the color management, it just sees (and is only capable of handling) device values in the range 0.0 - 1.0, which is all the device is physically capable of handling. To do more sophisticated gamut mapping, the source and destination gamuts need to be known. For output referred colorspaces such as standard Video, where the media has been rendered to fit within the gamut, this is assumed to be the colorspace surface.

To fit within the color management framework, an extended range would have to be normalised to a standard logical range, and what range would that be ? - it couldn't be represented as an expanded per channel RGB range, it is actually the media gamut shape in 3D that pokes outside the 16-235 values. And to know what that shape and its values are, the media colorspace would have to be known by the 3dLut. So it's much simpler to get the 3dLut to handle the whole thing.

The general idea was for madVR to convert all sources to one specific gamut, so that we only need one 3dlut for all source formats. If you strongly feel that separate 3dluts for separate source gamuts would produce noticeably better results I might consider allowing one external 3dlut file per source gamut.

I think I understand your motivation, and I think that a no compromise solution is possible by separating out the concerns into two configuration modes, with a common underlying implementation:

Normal mode (works "out of the box") :- create a 3DLut on demand. You just have to have models for the input space (ie. media primaries + gamma encoding, ie. Rec709) + black point & viewing transform = BT.1886 + display gamma + display profile = system display ICC profile or user selected ICC display profile. Create a 65 resolution 3DLut and implement using shader texture mapping to interpolate up to the video resolution. You've already got most of that code in MadVR, all that's missing is a call to littleCMS. You can apportion the work between the shader and the 3dLut as you wish, although it is probably simpler to do it all in the 3dLut.

Advanced mode :- the user specifies an ICC device link for each input media type. This takes the place of input space + blackpoint & viewing + output space loookup. Use it to create a 65 resolution 3DLut and implement using shader texture mapping to interpolate up to the video resolution. For backwards compatibility accept a .3dlut instead of an ICC device link.

madVR has a multi-stage auto-detection. First of all madVR checks if the video bitstream properly identifies the source gamut (this only works for MPEG2, h264 and VC-1). If not, madVR checks if the DirectShow decoder filter reports which gamut the source has. If that also fails, madVR guesses the gamut (EBU, SMPTE-C or Rec709) based on the source resolution and framerate.

The same logic is used for decoding matrix and transfer function.

Hmm. The OSD doesn't seem to indicate any transfer function, nor have I been able to measure one. This is consistent with your statement below...

Sorry, maybe I should be more clear. madVR expects the 3dlut to not modify the transfer function because madVR wants to do such modifications itself in realtime (otherwise you'd have to switch 3dluts everytime the user increases/decreases the gamma value, for example). madVR does not touch the source transfer function when using an external 3dlut file and when madVR's gamma processing is disabled. From what I remember, we found that using a pure power curve inside of the 3dlut processing chain with a gamma value of 2.2 for both de-gamma and en-gamma stages worked quite nicely for all source formats, so that's what madVR usually expects the 3dlut to use. However, you could in theory use any transfer function you like as long as you use the same function for de-gamma and en-gamma, so that the 3dlut doesn't change the overall transfer function.

Not sure, does that clarify things or does it make it even more confusing?

It's still a bit unclear, nor do I understand how you would expect the 3dlut would adjust for the display device characteristic without modifying the transfer curve along with everything else - after all, that's the point of it, to render the source media into an actual display device space so as to best preserve the intended appearance.

[ Turns out Sony Vegas is encoding things fine - I had created my Noop.3dlut using sRGB->sRGB, and MadVR was converting from EBU 3213-PAL to sRGB and messing up the colors. Making my Noop.3dlut out of EBU3213.icm->EBU3213.icm fixed the problem. A Noop out of Rec709.icm->Rec709.icm worked as expected for HD testing too.]

[madshi]

MadVR is unusual in using 256 resolution cLUTs. It is something that is only conceivable in recent years with the advent of very large memories and high processing bandwidth. Most other systems that were originally developed on more limited hardware use much lower resolution - 33 being typical in the graphic arts which also use per channel curves as well, to reduce the demands on the cLUT. For video work, 65 is a nice number, because the grid point match well with the 16-235 video encoding range points. That's what I'm defaulting to for the eeColor and MadVR ICC device links (==cLUT/3DLut), and then upsampling the device link to the MadVR 256 resolution 3dLUT using the standard tetrahedral interpolation provided by icclib (littleCMS has similar capabilities).
FWIW, madVR also accepts 7bit (128x128x128) and 6bit (64x64x64) 3dluts. I could add even lower resolution 3dlut support, if needed. Having 3dluts be a 2^x size makes things easier for Direct3D and my shader code. Also it allows me to feed BTB and WTW into the 3dlut, which may or may not be useful, depending on the software which creates the 3dlut.

To do more sophisticated gamut mapping, the source and destination gamuts need to be known.
And the known source gamut may not be a gamut converted to by madVR from another (unknown) gamut?

How about the following workaround: Instead of allowing users to specify only one external 3dlut I could allow them to specify one external 3dlut per each input media type. Wouldn't that do the trick for now, without me having to totally change the way madVR calibration works right now?

I think I understand your motivation, and I think that a no compromise solution is possible by separating out the concerns into two configuration modes, with a common underlying implementation:

Normal mode (works "out of the box") :- create a 3DLut on demand. You just have to have models for the input space (ie. media primaries + gamma encoding, ie. Rec709) + black point & viewing transform = BT.1886 + display gamma + display profile = system display ICC profile or user selected ICC display profile. Create a 65 resolution 3DLut and implement using shader texture mapping to interpolate up to the video resolution. You've already got most of that code in MadVR, all that's missing is a call to littleCMS. You can apportion the work between the shader and the 3dLut as you wish, although it is probably simpler to do it all in the 3dLut.

Advanced mode :- the user specifies an ICC device link for each input media type. This takes the place of input space + blackpoint & viewing + output space loookup. Use it to create a 65 resolution 3DLut and implement using shader texture mapping to interpolate up to the video resolution. For backwards compatibility accept a .3dlut instead of an ICC device link.
I'd prefer offering only one solution instead of two. That would make my life easier: Less code to maintain.

I have zero knowledge about how ICC works. Currently madVR is pretty "stupid" in that it simply feeds data into the 3dlut and that's it. Ok, I'm doing some gamut and gamma processing, but that's just relatively simple math. I think good quality calibration is probably much more complicated. So basically I don't know how to convert an ICC device link into a proper 3dlut.

I also don't know the extent of what ICC supports. I've been told that photo editors measure their displays at e.g. a 5x5x5 raster and then calculate a full 3dlut based on those measurements to make the display response perfect at all IRE levels. AFAIK this is also what the latest Lumagen Radiance 5x5x5 calibration does. "Conventional" calibration usually only corrects everything at one IRE, and then you have to hope that your display behaves linearly, so that the other IREs may look more or less right, too. Does ICC support such 5x5x5 measurements and the corresponding complex corrections to make a display virtually perfect?

From my naive point of view, for ideal results I'd imagine to measure maybe 5x5x5 and in addition to that the gray scale in maybe 32 or 64 steps. Throwing all those measurements together and turning it into a monstruous 3dlut should allow to get a perfect color and gamma response, I'd imagine. Does ICC support that concept?

Hmm. The OSD doesn't seem to indicate any transfer function
Just double checked my code. You're right. The OSD doesn't show the source transfer function, nor do I even care what it is. The reason for that is that BT.601 and BT.709 use the same transfer function and for PAL (AFAIK) it is usually recommend to use the same once again. Furthermore it is my understanding that the proper way to treat all that stuff is to convert to linear light by using a pure power curve of 2.2 because that is what CRTs used to do, too, when BT.601 and BT.709 were defined. At least so I understand Poynton. But it's a looooong time since I looked into this, so maybe my mind is playing tricks on me right now...

I'm not measuring a Rec709 gamma to power 2.2 conversion. It seems like the levels are being passed directly through, but that does leave the puzzle of how the colors are being translated from the media colorspace to the 3dLut input space, since this should be done in linear light.
madVR is using a pure power 2.2 conversion to get to linear light, then it performs gamut, contrast, saturation and hue changes (if necessary), then it converts back to gamma corrected light by using a pure power 2.2 conversion again. So the transfer function stays untouched by madVR. Unless you activate gamma processing in the madVR settings. Then madVR might actually modify the transfer function, depending on the settings...

It's still a bit unclear, nor do I understand how you would expect the 3dlut would adjust for the display device characteristic without modifying the transfer curve along with everything else - after all, that's the point of it, to render the source media into an actual display device space so as to best preserve the intended appearance.
What I meant is that the 3dlut *should* make the gamma response of the display perfect, but the 3dlut should not be used to convert to different gamma curves. E.g. there should not be one 3dlut for a end-to-end display gamma response of a pure power 2.2 curve, and another 3dlut for a pure power 2.4 curve. Instead basically the 3dlut should tune the display to have a perfect 2.2 curve. If the user wants 2.4, the necessary modifications would be done via madVR shader math outside of the 3dlut. The purpose of this approach is to avoid needing one 3dlut per desired display gamma value...

[cyberbeing]

madVR is using a pure power 2.2 conversion to get to linear light, then it performs gamut, contrast, saturation and hue changes (if necessary), then it converts back to gamma corrected light by using a pure power 2.2 conversion again. So the transfer function stays untouched by madVR. Unless you activate gamma processing in the madVR settings. Then madVR might actually modify the transfer function, depending on the settings...
That said, the following correction below is probably more accurate in general case than my previous post.

madVR:
(1) input = 8bit Y'CbCr, Video primaries/gamut, Video transfer function, WTW/BTB, D65 White Point
(2) convert -> 32bit float R'G'B', Video primaries/gamut, Video transfer function, WTW/BTB, D65 White Point
(3) convert -> 32bit float RGB, Video primaries/gamut, assumed pure power 2.2 gamma -> linear light , WTW/BTB, D65 White Point
(4) convert -> 32bit float RGB, Display primaries/gamut, linear light, WTW/BTB, D65 White Point
(5) convert -> 32bit float R'G'B', Display primaries/gamut, linear light -> pure power 2.2 gamma (result = same Video transfer function as input), WTW/BTB, D65 White Point
3dlut:
...

You can think of it as current versions of madVR treating the input transfer function of all videos is a 2.2 power curve for the purpose of converting to and from linear light.

What I meant is that the 3dlut *should* make the gamma response of the display perfect, but the 3dlut should not be used to convert to different gamma curves...
I've always found this rather confusing in the current madVR implementation.

My preferred way to handle this is to only correct the display's gamma to the values the 3DLUT takes as input, and not change the source's Video transfer function to any other gamma. To correct my display's gamma to my intended target, I use the Argyll ICC profile calibrated 16-bit curve via my GPU's gamma ramp. 3DLUT Gamma in -> 3DLUT Gamma out (gamut changed, gamma unchanged). GPU gamma ramp from ICC profile (gamma changed to intended target after 3DLUT gamut correction).

Alternative 1: madshi's current implementation of optional shader-based gamma correction implementation expects that you have the 3DLUT change Display's response curve to output an actual 2.2 power-curve. This allow expected results, if for example, you enable gamma processing in madVR, and change the gamma to a 2.4 power-curve, the display response should actually end up as a 2.4 power-curve when measured. 3DLUT Gamma in -> 3DLUT 2.2 Power Curve out (gamut changed, gamma changed).

Alternative 2: You can ignore madshi's intentions, and use a 3DLUT to change the display's gamma from the video's input transfer function to anything you want. Gamma in -> Custom Gamma out (gamut changed, gamma changed). nand-chan made ti3 parser (http://forum.doom9.org/showthread.php?t=162285) which allows merging a ICC profile gamma ramp into a 3DLUT, but the results were always somewhat poor, occasionally resulting in low-light banding and clipping. If this a flaw how ti3 parser modifies 3DLUT files, or a limitation of doing gamma correction in a 3DLUT, I don't know.


The purpose of this approach is to avoid needing one 3dlut per desired display gamma value...

Well you only really need one 3DLUT for the "default" target display response gamma you want to use. At that point madVR can still scale the gamma via shaders, it just will contradict with your GUI and act as more of a quirky brightness adjustment, since you use 2.2 power-curve as the expected base value instead of a scaling offset.

[leeperry]

Maybe I spend too much looking for possible errors than enjoying the content. :rolleyes:
Oh wait, I thought that was the whole point of this hobby? But now that you mention it, I did notice movies playing in the background while nitpicking for judder, chroma alignment and what-not :p

This post on the subject (http://www.avforums.com/forums/plasma-tvs/1622359-50-hz-bug-recorded.html) is very informative.
Nice link! Apparently this 24p judder test (http://www.avforums.com/forums/16827589-post16.html) would work brilliantly on my rig, good times :cool:

And I'm currently playing slow motion-ish 25p content with smooth-motion(in linear light mode) in 100Hz on my CRT and I can't see any ghosting, very impressive! Maybe fast motion is the problem(as it often is with FI) and could be polished somehow?

Slomo would always appear to look amazing with smooth-motion in mVR:
Here are two samples I´ve found that look perfect with smooth motion:
http://www.mediafire.com/?5xccccrs7109mjn
http://www.mediafire.com/?1zos93buokb981r

[dukestravels07]

Been using madvr for about a week now and it is superb. Only issue I have is with ripped dvd files.

It just doesn't like them on my system. I can encode the vob to mp4 or mkv and they play flawlessly without any choppiness, but playing the vob directly, results in constant dropped frames and choppiness. I really dont want to re encode all my dvds to mp4, but I will if it means I can use madvr...

I'm using mpchc x86 with lav codecs. I use dxva and it works well for every other file. The vobs play when removing madvr from the equation, but the quality drops dramatically, so I obviously want it on.

Ive noticed that during vob (mpeg2) playback, the cpu uses up to 80% of its resources. DXVA is definitley being used though, as it shows on CTRL J

CPU power is usually around 30% with other video files.

Any ideas? Thanks!

[noee]

Try turning off DXVA2 for MPEG2 in LAV (use CPU) and if your source is film, tell madVR with Ctrl_Alt_Shift_T.

[dukestravels07]

noee
Thanks for that. Not much change.
My CPU is VERY old actually. I cant upgrade the CPU on the motherboard, so bought a GPU accelerated video card to get DXVA, so I would really rather have the card take the load than the CPU.

[noee]

What CPU/what GPU then? MPEG2 requires very little "effort", even for older CPUs. What are you scaling up to? Try a lesser scaling algo.

[DragonQ]

To be honest, the quality loss when re-encoding a DVD to AVC will be more noticeable than the improvement you get with MadVR over EVR (unless of course you're using it for reasons other than image quality). Have you tried using EVR to play your MPEG2 DVDs with DXVA2? What about MadVR with DXVA2 scaling?

Even if EVR works, it's a pain switching between the two all the time. What you could do is install the 64-bit version of MPC-HC and set it up to use EVR-CP. Then you'll have one version of MPC-HC (32-bit) using LAV & MadVR for all of your AVC stuff, and one version of MPC-HC (64-bit) using LAV & EVR-CP for your MPEG2 stuff.

[leeperry]

and talking about slomo, forcing half-frame rate in Reclock with smooth-motion(in linear light mode) in 100Hz is really something on non-motion blurry content http://forum-images.hardware.fr/images/perso/sealbirman.gif

for some reason 100Hz seems to work better than 90 or 110 on my CRT, whatever the original frame rate.

[dukestravels07]

To be honest, the quality loss when re-encoding a DVD to AVC will be more noticeable than the improvement you get with MadVR over EVR (unless of course you're using it for reasons other than image quality). Have you tried using EVR to play your MPEG2 DVDs with DXVA2? What about MadVR with DXVA2 scaling?

Even if EVR works, it's a pain switching between the two all the time. What you could do is install the 64-bit version of MPC-HC and set it up to use EVR-CP. Then you'll have one version of MPC-HC (32-bit) using LAV & MadVR for all of your AVC stuff, and one version of MPC-HC (64-bit) using LAV & EVR-CP for your MPEG2 stuff.

Yep, Im all about quality with these rips. I dont even care if the output file is bigger than the input if I can upscale the videos to look better than DVD. I would rather not have to encode though.

So after playing around with things I checked off the "USE HALF FRAME RATE FOR DXVA DEINTERLACING" option in the trade quality for performance area of madvr and things are working perfectly. No frame drops at all, no stutter. The image looks good to my eyes, but are there any trade offs with this setting? My knowledge of this stuff is limited.

[DragonQ]

The down side is that you lose half the frames for interlaced content and thus half the motion resolution (25i will get deinterlaced to 25p instead of 50p, for example). If the content is progressive (24p/25p/30p) then that setting should make no difference but since you said enabling "film mode" didn't help, it sounds like it's interlaced.