madVR - high quality video renderer (GPU assisted) [Archive] - Page 404

e-t172

28th September 2013, 20:13

Is there any way to use ICC Color Profiles (like MPC-HC does natively) without converting to 3D LUT?

I tried to convert my profile using Argyll+DispcalGUI, and with TI3 Parser but with no success,
both of them show some crazy windows errors with red X in them.

No, but Argyll is now able to generate 3DLUTs directly with great flexibility. See the Argyll doc (http://www.argyllcms.com/doc/Scenarios.html#TV1) and this thread (http://www.avsforum.com/t/1471169/madvr-argyllcms) for instructions.

Anyone use the BT.709 Gamma profiles, and think they look like they got elevated blacks and too low gamma (1.95)?

That's because 709 gamma specs are for Encoding ONLY !!!
NOT for calibrating displays, period.

That's correct. ITU-R BT.709 (http://www.itu.int/rec/R-REC-BT.709/) only defines an opto-electronic transfer function, as opposed to an electro-optical transfer function.

Your Display calibration should be a Pure Power Curve of 2.2 to 2.4.

Not quite. Ideally it should follow the ITU-R BT.1886 (http://www.itu.int/rec/R-REC-BT.1886-0-201103-I/en) specification, which is the new standard for video displays. This specification does not specify a pure power curve (at least not for displays with imperfect black), it specifies a custom curve with a well-defined electro-optical transfer function.

Question: Why madshi included BT.709 Display Gamma into MadVR?

That's a good question. Display gamma suffered from much confusion until ITU-R BT.1886 cleared everything up for us. Ideally madshi should remove BT.709 from the gamma options (because it is confusing and doesn't actually make sense) and add BT.1886 support, but that's a feature request, and last time I checked madshi isn't accepting feature requests right now. In the mean time, it is possible to use BT.1886 by generating a 3DLUT with Argyll.

cvrkuth

28th September 2013, 20:40

I update my OS (Windows 8.1 Pro), I have same problem again.
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.

It works for me. Which GPU do you have? Are you using the latest madVR build? If so, create a debug log, zip it and upload it somewhere and I'll have a look.

Log file here (http://www.krstic.eu/madvr_log.zip).
I have Sapphire Radeon HD 5670 Ultimate 1GB,
Intel Core2 Duo E8400 3.00GHz, RAM 8 Gb
Panasonic TX-P42G20E, Catalyst™ 13.9
Win8.1 Pro x64, JRiver Media Center 18 Ver. 18.0.212, madVR v0.86.11

6233638

28th September 2013, 20:45

Your Display calibration should be a Pure Power Curve of 2.2 to 2.4.Your display should be calibrate to BT.1886, which adjusts the gamma curve based on the capabilities of your display.

If your display has 10,000:1 native contrast or greater, you should be using a straight 2.4 power curve.

Question: Why madshi included BT.709 Display Gamma into MadVR?Because people requested it. And it can work reasonably well if people are still using CRTs without external LUT correction. (the 3DLUT support doesn't allow for enough customization for CRTs)

ryrynz

29th September 2013, 05:59

Here's one new feature:

http://forum.doom9.org/showthread.php?p=1645630#post1645630

One less essential filter active in Avisynth, awesome.

Some questions:
Will it have values that can be adjusted?
Will the deband be done before or after resizing? And have you compared quality of deband before and after resizing?
What's the general performance impact?
Will there be a an HQ mode at all?

James Freeman

29th September 2013, 06:00

Not quite. Ideally it should follow the REC-BT.1886 specification,

Your display should be calibrate to BT.1886, which adjusts the gamma curve based on the capabilities of your display.

Thank you for clarifing this.

In the Rec. ITU-R BT.1886, Appendix 1,
Its called EOTF-CRT matching.

I calibrate with Argyll+DispCalGUI, I think Black output offset setting which is 100% offset correction for LCDs and 0% for CRT monitors.

EDIT: Apparently to calibrate to the BT.1886 standard, "Black output offset" should be set to 0 with Gamma of 2.4.
I'll try it tonight and report back.
End of Edit.

This corrects higher output black response (around 0.1 cd/m2) of an LCD in relation to the input to get a more accurate calibration.
Meaning: No crushed blacks, simmilar to an CRT curve, and maximum Contrast Ratio that an LCD capable of.

A BT.709 ecncoding curve is closer to 0.51 (1.96).

0.51 * 2.2 = 1.122 Its already darker than a linear representation.
0.51 * 2.4 = 1.224 Even darker.

According to Rec. ITU-R BT.1886,
The recommended gamma should be set around 2.4.
But I find the end-to-end gamma of 1.22 (2.4) is a little too dark.
When watching movies I sense 2.2 is just right (darkened room), sometimes around 2.0 is even better for shdow detail (with the lights On).

Thanks.

baii

29th September 2013, 06:43

Hi, I just tried the CRU recommend few pages ago, and my u2711 finally seem to able to do 23/24 hz

madvr report 23 and 24 as well, just curious, is it possible that the monitor scaler scale the 23/24 hz into 60hz? Or what is reported by madvr or reclock is definitely right?

Sorry for kind of OP.

e-t172

29th September 2013, 10:38

In the Rec. ITU-R BT.1886, Appendix 1,
Its called EOTF-CRT matching.

No. Appendix 1 is not a normative section. It's only for people who have special needs and want to precisely match a CRT response. What you should be following is the function in Annex 1, which is the normative section.

I calibrate with Argyll+DispCalGUI, I think Black output offset setting which is 100% offset correction for LCDs and 0% for CRT monitors.

EDIT: Apparently to calibrate to the BT.1886 standard, "Black output offset" should be set to 0 with Gamma of 2.4.
I'll try it tonight and report back.
End of Edit.

The BT.1886 function is not equivalent to simple black compensation. Argyll has dedicated options (http://www.argyllcms.com/doc/collink.html#Ib) for applying BT.1886.

According to Rec. ITU-R BT.1886,
The recommended gamma should be set around 2.4.
But I find the end-to-end gamma of 1.22 (2.4) is a little too dark.
When watching movies I sense 2.2 is just right (darkened room), sometimes around 2.0 is even better for shdow detail (with the lights On).

No. You're confusing technical gamma (i.e. the γ parameter in the BT.1886 specification) and effective gamma (that is, the pure power curve gamma that best approximates BT.1886). With typical LCD screens, the BT.1886 function with γ=2.4 is actually closer to a pure power curve with γ=2.2.

n2k3

29th September 2013, 12:15

Since early this month I've been having blue screens (3 total now) and I think it's related to madVR.
The blue screens happened when I dragged my video window downwards, so that some of the lower part of the window is below the taskbar (off screen),
within a second a blue screen happens with the following error: 0x00000050 PAGE_FAULT_IN_NONPAGED_AREA
The blue screens always have the same error (if you want I can upload the minidump(s) Windows made) but don't happen every time I drag my video window below the taskbar, only sometimes.

I'm using MPC-HC v1.7.0.7771 x86 in combination with madVR v0.86.10 (with Windowed Overlay enabled), and my OS is Windows 7 x64 - SP1
If you want more information on this matter, tell me what you need, and I'll be happy to provide.

James Freeman

29th September 2013, 13:05

No. Appendix 1 is not a normative section. It's only for people who have special needs and want to precisely match a CRT response. What you should be following is the function in Annex 1, which is the normative section..
Right, sorry for that.
Annex 1 is the standard.
Appendix 1 is the alternative.

The BT.1886 function is not equivalent to simple black compensation. Argyll has dedicated options (http://www.argyllcms.com/doc/collink.html#Ib) for applying BT.1886.

Setting a Gamme of 2.4 with "Absolute" option (instead of Relative).
Black Output Offset to 0.
WILL give an exact BT.1886 gamma curve.

I quote the text of argyll:

"Note that using all input offset (degree == 0.0) is equivalent to the use of the BT.1886 transfer function."
"Use "-G2.4 -f0" for BT.1886"

No. You're confusing technical gamma (i.e. the γ parameter in the BT.1886 specification) and effective gamma (that is, the pure power curve gamma that best approximates BT.1886). With typical LCD screens, the BT.1886 function with γ=2.4 is actually closer to a pure power curve with γ=2.2

Right, sorry again.
After reading the Argyll text,
This is what Absolute vs Relative gamma does in Argyll.
An Absolute gamma of 2.4 will NOT be 2.4 after taking the black offset of 0 into account, it will be lower as you've already stated.
Also I have tried the BT.1886 calculator offered at the AVSforum and with my display (U2410, Contrast of 850:1)
it practically does not matter what gamma I put into it, the result is almost always around 2.2.

James Freeman

29th September 2013, 19:55

OK, I have tested the BT.1886 standard against my regular 2.2 power curve calibration.

I don't like it.

Yes, the image has more discernible shadows.
But it destroys the depth of the image I am used to, and looks unnatural.
It also lowers my already low IPS panel contrast.

The default settings in Argyll (Gamma: Relative, Black Offset: 100%) give me the best results.
Because it works best with what a monitor can give natively, and not force it to conform to a standard.

Quote from the manual:
The default way of handling this (equivalent to 100% black output offset) is to allow for this at the output of the ideal response curve, by offsetting and scaling the output values.
This defined a curve that will match the responses that many other systems provide and may be a better match to the natural response of the display, but will give a less visually even response from black.

I don't care for "less visually even response from black"...
I care for deep contrasty popping image, which I don't get when calibrating to the BT.1886 standard.
Yes, 1886 gives a more even grey scale and close to CRT black response but at the expense of image depth.

I can see ALL the black steps either way (No black crush what so ever).
I don't think you can set any setting that resulting in a pure power curve below 10% that crushes the blacks, argyll always has some kind of offset to the blacks.
Only its selectable between Input & Output Offset (0% to 100%).

I think that if a display has less than 1000:1 contrast ratio, BT.1886 can do more harm than good.

A "Power Curve + BLC" gives me a nicer deeper picture.
At least with my setup.

Any thoughts?

6233638

29th September 2013, 22:48

OK, I have tested the BT.1886 standard against my regular 2.2 power curve calibration.A power curve will only have shadow detail down to around 5% black on a display with 1000:1 contrast.

Yes, the image has more discernible shadows.
But it destroys the depth of the image I am used to, and looks unnatural.
It also lowers my already low IPS panel contrast.The point is that you're no longer crushing or clipping shadow details when using BT.1886

I don't care for "less visually even response from black"...
I care for deep contrasty popping image, which I don't get when calibrating to the BT.1886 standard.
Yes, 1886 gives a more even grey scale and close to CRT black response but at the expense of image depth.Then you need a higher contrast display.

I can see ALL the black steps either way (No black crush what so ever).Black crush does not necessarily mean that all steps are indistinguishable, but that they are compressed and more difficult to distinguish in high contrast situations.
The old methods of black level compensation did not do a good job with this, and also had a tendency to reduce midtone contrast.

See this post for comparisons between 2.2, BT.1886 and 2.2 with black level compensation for a 2000:1 contrast display: http://www.avsforum.com/t/1409045/how-power-law-gamma-calibration-can-lead-to-crushed-blacks/100_100#post_22253013
You can see that 2.2 with black level compensation does not do well to distinguish gray levels near black. A 1000:1 display would be even worse.

James Freeman

30th September 2013, 05:20

6233638,

Yes, the blacks are more compressed with "Power law + BLC" but they are still visibly all there.
I don't think there are higher contrast displays in IPS type panels (above 1000:1) at least not in my budget.

Based on viewing few dark blu ray movies:
I think (in my opinion only) the movies are mastered with "Power law + BLC".
I can still see all the shadow details even in high contrast scenes (yes, even below 5%).
The blacks are compressed to a smaller range and that makes them visibly "smoother" and NOT even.
If the movie mastered that way, it's just fine.

I think BT.1886 is too aggressive with the black compensation (as stated before).

Do you think the movies are mastered on a CRT?
Or a BT.1886 calibrated LCD?

I think there is a problem with Argyll's calculations.
When calibrating with argyll to BT.1886 specs, the lowest black on my monitor (0.23 to 200 cm/m2 = 870:1 ) turns to 0.29 and as a result lowers the contrast ratio.
I don't know why but it should use the lowest black no matter what.

This partially made me look negatively up on BT.1886.

NewmanHD

30th September 2013, 15:16

Hey guys! Currently I use Niyawa description (MPC-HC, madVR, LAV, ReClock, xyVS). Thinking about buying a VGA card next to a G840/i3-2120 (Asus B75 MoBo/8GB RAM). The best picture settings will prove adequate for a HD7730? Later prove to be enough? I do not play games and I'm sorry for my English. Thanks.

6233638

30th September 2013, 15:42

I think (in my opinion only) the movies are mastered with "Power law + BLC".Films are typically mastered on high contrast displays which do not have a need for black level compensation. LCD monitors have not been widely adopted.

I can still see all the shadow details even in high contrast scenes (yes, even below 5%).
The blacks are compressed to a smaller range and that makes them visibly "smoother" and NOT even.
If the movie mastered that way, it's just fine.

I think BT.1886 is too aggressive with the black compensation (as stated before).

Do you think the movies are mastered on a CRT?
Or a BT.1886 calibrated LCD?BT.1886 is the new standard for mastering. To calibrate to anything else is wrong.
If you want a higher contrast image, you have to either compromise on shadow detail and go with a less accurate image, or replace it with a higher contrast display.

I think there is a problem with Argyll's calculations.
When calibrating with argyll to BT.1886 specs, the lowest black on my monitor (0.23 to 200 cm/m2 = 870:1 ) turns to 0.29 and as a result lowers the contrast ratio.
I don't know why but it should use the lowest black no matter what.That doesn't sound right, but I have never had good success with ArgyllCMS. I'm hoping that there will be CalMAN support eventually.

leeperry

30th September 2013, 16:26

Do you think the movies are mastered on a CRT?
Well, SONY Pictures promised that CRT monitors in their mastering houses would be replaced by OLED through the end of the year, but yes indeed CRT still rules there and here's a real world picture of a french TV show production control room in 2013 (http://s.tf1.fr/mmdia/i/33/5/plateau-speciale-10-ans-ci-26-10592335hxsqq.jpg), it's one of those (http://www.highwayav.com/Portals/0/Products/Production_Monitors/BVM_PVM_Monitors/BVM-A14F5M/1169568028-191.jpg).

That's the very reason why some/most/many HD movies look greenish and overly saturated in the REC.709 gamut as some mastering facilities would convert from SMPTE-C/EBU to REC-709 via a high precision 3DLUT but IRL some wouldn't. Once everyone goes OLED, hopefully the SMPTE-C orangey red will be history and the hero of Disney's Cars will finally be as deep red in the anime as it is on the poster (http://www.avsforum.com/t/1038602/) :devil:

I think there is a problem with Argyll's calculations.
Using Argyll's mail list is a bit of a pain, but Graeme Gill does read this thread (http://www.avsforum.com/t/1471169/) FWIW and he's the only one that can help/fix the issue you're encoutering.

Thinking about buying a VGA card next to a G840/i3-2120 (Asus B75 MoBo/8GB RAM). The best picture settings will prove adequate for a HD7730? Later prove to be enough?
madshi made clear that he might add more demanding algorithms as he sees fit, and for instance no performance figure has yet been announced regarding the forthcoming debanding filter.....so it wouldn't be too wise to buy a monster board in order to hopefully anticipate on what mVR might require later.

If you want Jinc AR scaling@1080p for both luma & chroma upscaling, possibly SmoothMotion on top of it and being able to process 1440x1080i@59.94, a GTX650Ti will barely have the muscles......not sure about AMD boards as I believe madshi said that their texture processing was (sometimes) faster, but I guess you would be looking at a HD7850+ (http://www.hardware.fr/articles/879-21/upgrade-face-x-anciennes-generations.html) in order to remain on the safe side for a (possibly little) while and their new GPU generation is about to be released so resellers will have to get rid of their 7850/7870's in a timely manner ;)

madshi

30th September 2013, 16:46

Is there any way to use ICC Color Profiles (like MPC-HC does natively) without converting to 3D LUT?
No, you need to create a 3dlut for madVR to do any calibration.

I'm not sure I know how to put the drain on madVR ?

This is what I'm doing for now :

[...]

The "videoFrame" is a WPF Control which hosts the WindowsFormsHost, this host does have a Window, this is this window handle that is exposed through videoFrame.VideoHwnd and forwarded to madVR (with put_Owner)

This window is created on the WPF UI thread (I have no other choices), while madVR is created on a dedicated thread (STA or MTA, with message pumping)
Well, looks alright to me. I'm not sure why you have the problems you have. I can only imagine that the WPF UI thread doesn't react to the messages as quickly as it should, but I don't really know... :(

Looks promising! I assume there will be a new tag so it can be selectively enabled/disabled?
Of course.

Ideally madshi should remove BT.709 from the gamma options (because it is confusing and doesn't actually make sense) and add BT.1886 support
Wouldn't I need to know the display's black level in order to do that? I don't know that, unless you provide madVR with measurements. And if you do that, you can just as well provide a full 3dlut which does the BT.1886 stuff internally, can't you? I'm just not sure if it makes any sense for madVR to offer BT.1886.

Will it have values that can be adjusted?
Will the deband be done before or after resizing? And have you compared quality of deband before and after resizing?
What's the general performance impact?
Will there be a an HQ mode at all?
There will be a "low" and a "high" setting. Debanding is done before resizing, but (currently) after chroma upsampling. On my HD4000 the "low" setting costs about 7ms per 1080p frame. The "high" setting costs about 14ms. The "high" setting removes more banding, and has a slightly more complicated algorithm to avoid too much detail loss. The "low" setting is comparable to f3kdb's default settings (in high bitdepth).

I haven't compared the quality before/after resizing, and I don't think it's necessary. If the source is banding free before the resizing, then it will still be banding free afterwards (except if you use DXVA scaling with a GPU which only supports 8bit). IMHO the right place to do debanding is before scaling.

madvr report 23 and 24 as well, just curious, is it possible that the monitor scaler scale the 23/24 hz into 60hz?
Yes, that is possible.

Since early this month I've been having blue screens (3 total now) and I think it's related to madVR.
Related to maybe. But there's no way a user mode software like madVR should be able to produce a blue screen. So the blame is most probably the GPU drivers. I'd suggest updating the drivers, maybe the BIOS.

Hey guys! Currently I use Niyawa description (MPC-HC, madVR, LAV, ReClock, xyVS). Thinking about buying a VGA card next to a G840/i3-2120 (Asus B75 MoBo/8GB RAM). The best picture settings will prove adequate for a HD7730? Later prove to be enough? I do not play games and I'm sorry for my English. Thanks.
I don't know if the 7730 is fast enough for highest settings at all framerates. You may want to check renethx' posts in the AVSForum. He's done some checks which GPU can do which framerates with which algorithms. The 7730 is probably not fast enough to do the highest settings for 60fps, but I don't know for sure...

StephaneM

30th September 2013, 17:07

Hi,
Well, looks alright to me. I'm not sure why you have the problems you have. I can only imagine that the WPF UI thread doesn't react to the messages as quickly as it should, but I don't really know... :(
I've found a workaround for this : when adding madVR to the graph, it has to be done on the main UI thread.

At this point I thought I would put back the whole graph on the UI thread, but while it works, it does requires many tricks to build the graph while having WPF animation (and keep them smooth). It's much easier to have the graph in a dedicated thread.

So you can have madVR added to the graph in the UI thread and have the graph in another thread (preferably with a message pump). Then the only thing you have to do is to place some madVR calls on the main UI thread (well I had to do it only for SetWindowPosition, so I guess that anything that will somehow change properties on the madVR window requires to be called on the UI thread)

NewmanHD

30th September 2013, 17:32

I don't know if the 7730 is fast enough for highest settings at all framerates. You may want to check renethx' posts in the AVSForum. He's done some checks which GPU can do which framerates with which algorithms. The 7730 is probably not fast enough to do the highest settings for 60fps, but I don't know for sure...

Thanks for your reply. Could you give me a link about the post? I can not find.

James Freeman

30th September 2013, 19:16

I want to quote a few short posts from AVSforum: How power law gamma calibration can lead to crushed blacks Thread.

However, I also see (mainly in outdoor scenes) a loss of... I don't know - "richness". It's like there is a very light haze, and the colors aren't as vibrant. Do you see this also?

Yes, at times. The trick is to avoid "A/B' comparisons with a pwr-law setup.

Ok, then do professional calibrators use the bt.1866 standard or do they use another standard when calibrating consumer panels?

I don't know what "pros" are actually doing, but at this point they really *should* be doing one setting with PowerLaw w/BLC and another with BT1886 (as opposed to "Day" and "Night" modes) ...
Subject to the customers' wishes, and the displays' capabilities, of course.

Straight power law (with no black level compensation) should be a non-starter in the flat panel age.

This is exactly what I've wanted to read.

As I like the Power Law + BLC better because I get a more Contrasty image without "Visually-Non-Satisfactory-Blacks".
Note that I did not use the term "Black Crush" because they are NOT (visually for me), they just live in a smaller space, yet all of them are perfectly visible. :D

Well... BT.1886 is a relatively new standard that tells "everyone" to conform to it, yet, not without a compromise.

Cheers.

6233638

30th September 2013, 19:41

Note that I did not use the term "Black Crush" because they are NOT (visually for me), they just live in a smaller space, yet all of them are perfectly visible. :DThat's still black crush. BT.1886 relies on a lot of research that has been done for just-noticeable difference in a number of scenarios.

No-one says you have to calibrate your display to follow the standards. Set it up however you like, if that's what you prefer. It does sound like something is going wrong with ArgyllCMS if it's raising your display's black level.
But further discussion on this probably belongs on AVS Forum rather than the madVR topic.

The real solution to your problem is to move away from a display with only 870:1 contrast, which is very low.

fairchild

30th September 2013, 20:15

Some people don't have the option to calibrate to BT.1886 I would need to use a 3dlut which would rely on my spectrometer which drifts with heat over time, and the process of creating the 3dlut would probably give me inaccurate results anyway.

Hence, i can only calibrate my display using it's controls to 2.22 gamma since my set also lacks a 10-pt gamma adjustment. There is NO standard for gamma adjustments anyway, different authoring houses calibrate with different displays and different values.

6233638

30th September 2013, 23:11

leeperry

1st October 2013, 00:31

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.
Problem lies in how the CPU and GPU handle threads in Windows XP.
If you guys are still around, my contact at nvidia just confirmed that these new beta drivers might fix the refresh rate detection problem in mVR on XP with the 660: GeForce 331.40 beta drivers (http://www.nvidia.com/object/winxp-331.40-beta-driver.html)

Too bad I sold my Asus 660 at no loss as I was under the impression that it would take forever to see a fix released and was starting looking at HD7850's.

fairchild

1st October 2013, 01:50

You may not be successful using ArgyllCMS with your Spectro, but you would be able to implement a custom gamma curve using the 3DLUT interface.

BT.1886 is the standard for gamma now. There was no standard.

Can you point me in the right direction as to how to actually create a 3dlut to use with MadVR to have a BT.1886 gamma curve? I'm leaving this in this post as I think it would be helpful to MadVR users who are in the same predicament as myself. (if madshi requests this be moved to PM's no problem doing that.) :thanks:

BTW I have read posts from calibrator's who are still calibrating displays to 2.22 even with the ability to calibrate to BT.1886 Either because the picture overall comes out too dark or just preference. (referring to both pro and DIY calibrators on the AVS forums.)

Asmodian

1st October 2013, 02:19

I started with this post (http://www.avsforum.com/t/1471169/madvr-argyllcms) from AVSforum but changed some options for BT.1886 output. This uses Argyllcms to do the calibrations. Rec709.icm can be found in the Argyll directory, the rest of the files are generated.

Open madTPG.exe from the MadVR install folder
Enable "use fullscreen"
Enable "disable VideoLuts"
Enable "disable 3dlut"

dispcal.exe -v -dmadvr -Yp -qu -m -G2.4 -f0 -w 0.3127,0.3290 "dispcal"
targen.exe -v -d3 -G -s40 -g128 -f2000 "MadVR"
dispread.exe -v -dmadvr -Yp -K dispcal.cal "MadVR"
colprof.exe -v -qh -bl -aX "MadVR"
collink.exe -v -3m -qh -et -Et -Ib:2.2 -G -a dispcal.cal -iaw Rec709.icm MadVR.icm 3DLUT.icm

For very dark viewing conditions I like this change to the collink line:
collink.exe -v -3m -qh -et -Et -Ib:2.4 -G -a dispcal.cal -iaw Rec709.icm MadVR.icm 3DLUT.icm

I also add the -ye option to both dispcal and dispread. This uses the meter correction file for my i1 Display 3 Pro and a white LED backlit LCD monitor but you need to install the correction files for Argyll to use them. You can do dispcal -help to see what options there are available for -y on your system.

Any suggestion or improvements very welcome. :thanks:

edit: I am currently happy with the results of the calibration on my 1000:1 contrast ratio, ~180 cd/m2 IPS monitor but nothing is ever perfect.

andybkma

1st October 2013, 11:32

Greets, can someone please confirm this madVR Full Screen Exclusive (FSE) behavior for me please? I need to find out if this is being caused by mVR or something on my system....

Win7 64-bit, with FSE On (using new path, Present Several Frames in Advance checked), HDMI or VGA out to an external monitor or projector, if I put the computer into Sleep (Standby) and then come out of Sleep, the first time (and only the first time) I go into FSE mode I seem to lose graphics output to the external monitor (the monitor goes into sleep mode) for about 3-4 seconds before finally going into FSE. If I use the old FSE path (Present Several Frames in Advance unchecked) then I have this problem when coming out of FSE mode instead of going into. Very odd. This happens only with Sleep, if I reboot the computer I don't have this problem.

I have tried checking & unchecking numerous mVR settings; I have tried using different media players Zoom Player and PotPlayer with both Nvidia graphics and Intel HD4000; and have tried various settings under Device > Display Mode (on/off). All did nothing, I still have the same problem so this is leading me to believe this is something possibly with mVR itself and not my laptop. Just odd that it happens only the very first time I flick from windowed to fullscreen FSE mode after coming out of Sleep. If FSE mode is unchecked then all is good so I know it's something with FSE.

Anybody else experience same? Cheers...

oddball

1st October 2013, 15:37

Bug report.

http://pdl.warnerbros.com/wbmovies/gravity/trailer2/GRAVITY_TRAILER_5-2k.mov

Plays as red and shades of black. If I switch to EVR it plays fine.

sneaker_ger

1st October 2013, 16:02

6233638

1st October 2013, 17:56

Bug report.
http://pdl.warnerbros.com/wbmovies/gravity/trailer2/GRAVITY_TRAILER_5-2k.mov
Plays as red and shades of black. If I switch to EVR it plays fine.Please report bugs to the bug tracker: http://bugs.madshi.net

But Madshi is aware of the problem: http://www.avsforum.com/t/1490573/gravity-2k-trailer/0_100#post_23762599

It works fine for me. It's ProRes 10 Bit 4:2:2 - do you have any intermediate filters between LAV and madVR? Do you have "P210" output ticked in LAV Video? ("v210" output seems broken for me, not sure if LAV or madVR fault)I'm guessing you don't have any display calibration options enabled.

sneaker_ger

1st October 2013, 18:22

I'm guessing you don't have any display calibration options enabled.

Indeed, I do not.
madVR reports BT.709 matrix, DCI-P3 primaries and limited range (all "best guess").

oddball

1st October 2013, 18:23

It works fine for me. It's ProRes 10 Bit 4:2:2 - do you have any intermediate filters between LAV and madVR? Do you have "P210" output ticked in LAV Video? ("v210" output seems broken for me, not sure if LAV or madVR fault)

Nope. P210 and v210 make no difference.

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

"But Madshi is aware of the problem: http://www.avsforum.com/t/1490573/gr...#post_23762599"

Will check it out.

oddball

1st October 2013, 18:25

Please report bugs to the bug tracker: http://bugs.madshi.net

But Madshi is aware of the problem: http://www.avsforum.com/t/1490573/gravity-2k-trailer/0_100#post_23762599

I'm guessing you don't have any display calibration options enabled.

OK disabling display calibration fixes it.

sneaker_ger

1st October 2013, 18:36

Does v210 work with disabled display calibration, too? Odd that it's just me.

6233638

1st October 2013, 20:19

OK disabling display calibration fixes it.You could also tag the video as BT.709 content by putting primaries=709 in the filename.

ryrynz

2nd October 2013, 08:30

Next madVR build is going to have some goodies for you guys. Will take a while until it will be released, though.

Would absolutely love to get a test build with the deband feature. Pretty excited for this one based on what I've read and seen over on the flash3kyuu thread.

SHaKOL

2nd October 2013, 10:32

Hi
i have a problem with .avi files when i choose madVR as the video renderer, like this:

http://im34.gulfup.com/4qaSe.png

but when i choose enhanced video rendere (custom presenter) works normally

Duffy Moon

2nd October 2013, 10:46

For the last few months, I've been having a problem with my reds. They look very blotchy and noisy. I'm not aware of having changed anything except for drivers (to the latest build). I'm using the latest MPC. All other colours are absolutely fine.

ryrynz

2nd October 2013, 11:02

If updating the drivers was something you've changed then it would make sense to revert that to see if it fixes the issue, besides that you could try restoring default settings via the batch file in MadVR's directory.
Resetting and reverting are the basics when it comes to troubleshooting, always do those first.

Duffy Moon

2nd October 2013, 11:12

Thanks. I'll try restoring default settings. Actually, I only updated the video driver about a week ago, so the phenomenon was the same with previous one.

ryrynz

2nd October 2013, 11:37

If the issue still occurs after resetting post all relevant details of your system (OS, graphics adapter, driver, madVR version etc) and we'll figure it out.

michkrol

2nd October 2013, 12:59

Hi
i have a problem with .avi files when i choose madVR as the video renderer

We'll need more info to help. Post your system specs (especially GPU), operating system, drivers version, player + version, codecs + version, madVR version.
If you're not using MPC-HC 1.7.0, try it (mpc-hc.org).

Try pressing (CTRL+J) if you get an OSD in top left corner of the video, post a screenshot, similar to this:
http://i.imgur.com/z8yA4mWs.png (http://imgur.com/z8yA4mW)
Post a list of filters used (in MPC-HC right click on video, select filters).
http://i.imgur.com/yEKbIpUs.png (http://imgur.com/yEKbIpU)
Apart from the files being *.avi, what codecs are used? Preferably post MediaInfo (in MPC-HC: File-> Properties, select MediInfo tab, copy whole text here as [code] block).

StephaneM

2nd October 2013, 17:53

Hi,

I need some help regarding external pixel shaders, no matter what I try I fail to apply a shader.

What I have done so far : created the playback graph and all is fine. Then upon user interaction I try to add a shader.

Here is my interface definition for C# Interop :

[ComImport, System.Security.SuppressUnmanagedCodeSecurity,
Guid("B6A6D5D4-9637-4C7D-AAAE-BC0B36F5E433"),
InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IMadVRExternalPixelShaders
{
[PreserveSig]
int ClearPixelShaders(bool postScale);

[PreserveSig]
int AddPixelShader([MarshalAs(UnmanagedType.LPStr), In] string sourceCode,
[MarshalAs(UnmanagedType.LPStr), In] string compileProfile,
int stage, IntPtr reserved);
};

And this is how I'm using it :

IMadVRExternalPixelShaders madvrShaders = playbackGraph["VideoRenderer"].GetInterface<IMadVRExternalPixelShaders>();
if (madvrShaders != null)
{
int result = madvrShaders.AddPixelShader(shaderCode, targetProfile,
(int)madVRProperties.ShaderStage.PreScaling, IntPtr.Zero);
}
Marshal.ReleaseComObject(madvrShaders);

No matter what I do I get 0x80004005 as result...

Regarding the arguments I'm passing here they are :

targetProfile = "ps_2_0"
shaderCode = "sampler s0 : register(s0);\nfloat4 p0 : register(c0);\n\n#define width (p0[0])\n....."

Am I missing something ?

Thanks,
--
Stéphane.

Nachbar

2nd October 2013, 18:09

I just had it crash while I was watching Commie's Monogatari series second season episode two

It crashed specifically while I was full screen around the 3:40 - 4:00 mark. I'm not using full screen exclusive mode. I believe the cause is xysubfilter (not to be confused with xyvsfilter) It will also sometime crash saying it was madvr.dll that caused it

I'm using LAV filters 0.58.2, madvr 0.86.11, reclock 1.8.8.0, mpc-hc 1.7.0, and xysubfilter 3.1.0.546

I've attached the crash report in a zip file.

huhn

2nd October 2013, 19:05

read the rules:
http://forum.doom9.org/forum-rules.htm

Nachbar

2nd October 2013, 19:16

Thanks Vivan for showing me the fix - it is xysubfilter's fault.
The fix is here: http://code.google.com/p/xy-vsfilter/issues/detail?id=153

SHaKOL

2nd October 2013, 20:56

We'll need more info to help. Post your system specs (especially GPU), operating system, drivers version, player + version, codecs + version, madVR version.
If you're not using MPC-HC 1.7.0, try it (mpc-hc.org).

Try pressing (CTRL+J) if you get an OSD in top left corner of the video, post a screenshot, similar to this:
http://i.imgur.com/z8yA4mWs.png (http://imgur.com/z8yA4mW)
Post a list of filters used (in MPC-HC right click on video, select filters).
http://i.imgur.com/yEKbIpUs.png (http://imgur.com/yEKbIpU)
Apart from the files being *.avi, what codecs are used? Preferably post MediaInfo (in MPC-HC: File-> Properties, select MediInfo tab, copy whole text here as [code] block).

specs: gtx 570, windows 7 ultimate 64-bit, 327.23 driver, mpc-hc 1.7.0.7680, cccp 2013-08-01, madVR 0.86.11

http://im32.gulfup.com/YqOCo.png

http://im32.gulfup.com/P5Wwg.png

General
Complete name : H:\1\Drift King\الدروس\مجلد جديد ‫‬\ألتنقية\1020.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 1.91 GiB
Duration : 30mn 17s
Overall bit rate : 9 026 Kbps

Video
ID : 0
Format : MS Video
Codec ID : CRAM
Codec ID/Info : Microsoft Video 1
Duration : 30mn 17s
Bit rate : 8 988 Kbps
Width : 1 152 pixels
Height : 796 pixels
Display aspect ratio : 1.447
Frame rate : 200.000 fps
Bits/(Pixel*Frame) : 0.049
Stream size : 1.90 GiB (100%)

noee

2nd October 2013, 22:46

@StephaneM:

Are you using DirectShowLib?

Would this be it?

// madVR Filter COM InterOp)
[ComImport, Guid("E1A8B82A-32CE-4B0D-BE0D-AA68C772E423")]
public class madVideoRenderer {}
.
.
.
// (instantiation)
m_madVR = (IBaseFilter)new madVideoRenderer();
m_PixelShader = (IMadVRExternalPixelShaders)m_madVR;
.
.
.

StephaneM

2nd October 2013, 22:57

Are you using DirectShowLib?
No, I'm using my own interop Library.

Would this be it?

// madVR Filter COM InterOp)
[ComImport, Guid("E1A8B82A-32CE-4B0D-BE0D-AA68C772E423")]
public class madVideoRenderer {}
.
.
.
// (instantiation)
m_madVR = (IBaseFilter)new madVideoRenderer();
m_PixelShader = (IMadVRExternalPixelShaders)m_madVR;
.
.
.
Not sure if this will change anything using DirectshowLib. Anyway, I'm able to use at least one madVR interface the way I do : IMadVRExclusiveModeControl for disabling exclusive full screen. So I know that I'm talking to the right COM object and that it expose the right interface.

The only thing I'm not sure of is if my interface definition is correct or not (for instance the interface documented by madshi for ClearPixelShaders state that this methode expect an int argument whereas it seems to be a bool...

Regards,
--
Stéphane.