Media Player Classic Home Cinema (MPC-HC) - DXVA!

[nevcairiel]

I put the test build directly onto the MP board
http://forum.team-mediaportal.com/719905-post89.html

[mariner]

Hi,

Aleksoid make a patch for it, i have started it too but his approach is better.

Now we have a setting in registry : VC1_Decoder_Output in
HKEY_CURRENT_USER\Software\Gabest\Filters\MPEG Splitter for standalone Filter
HKEY_CURRENT_USER\Software\Gabest\Media Player Classic\Filters\MPEG Splitter for MPC-HC soft.

1- Standard Connection (Microsoft DMO) "{31435657-0000-0010-8000-00AA00389B71}"
2- Cyberlink PDVD Codec "{D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53}"
3- Arcsoft Codec "{629B40AD-AD74-4EF4-A985-F0C8D92E5ECA}"

A dialog menu will be add soon :)

Standalone Filter, MPC-HC and reg file can be downloaded here :
MPC_vc1_Filter_Reg (http://www.mediafire.com/?jne6w47060dw7rc)

Thank you Aleksoid :)
Sebastiii.

Greetings Sebastiii.

This is brilliant.

Many thanks and best regards.

[nevcairiel]

I put the test build directly onto the MP board
http://forum.team-mediaportal.com/719905-post89.html

I posted another test built over in the MP thread
http://forum.team-mediaportal.com/codecs-external-players-55/vc-1-issues-vc1-91402/index10.html#93

I have hope for this one!

[Sebastiii]

I posted another test built over in the MP thread
http://forum.team-mediaportal.com/codecs-external-players-55/vc-1-issues-vc1-91402/index10.html#93

I have hope for this one!

I hope too :)
Thanks m8,
Seb.

[JanWillem32]

I've been developing a bit, and had a very hard time with getting switching between video files working again in EVR CP D3DFS mode. I've changed the stats screens a bit, for some code cleanup and better indication of functions. I also started to optimize the pixel shader initialization. With some luck, I might be able to add vertex shader support and two-pass scalers in a while.
I hope I can add a set of warning messages soon, for when functions or renderers get switched because of hardware incompatibility. I noticed that a lot of the reported problems are due to silent switching from EVR to the fallback VMR7 renderer.

[sshd]

The default keyboard shortcuts are fine, except for the stretching, move and rotate of the movie, which require numpad keys.

The numpad is not present on a lot of modern keyboards and laptops.

Using the numpad keys are the most obvious for default values. But how about a function that remaps these functions to the normal number keys for those of us without numpad?

[cca]

@JanWillem32 no notable changes for me with the latest build, then again our hardware setup is similar, I wouldn't expect any.

[JanWillem32]

@sshd: Remapping in View -> Options-> Player -> Keys menu doesn't work for you? We do have to be careful about mapping keys, as many are in use by Windows by default, along with some common hotkeys and there are missing keys on some international layouts. Many laptop keyboards feature FN (alternative shift) keys that are completely handled in hardware, and are therefore undetectable in software. As long as the keyboard layout loaded in Windows includes the Numpad, any program can simply assume that it's present. Patches are welcome, but I really don't know how to correctly solve this problem.

@cca: That's a good thing, I guess? Major improvements will require implementation of new scalers, adding vertex shader support or re-writing the font and subtitle renderers. All current scalers are single pass, two-pass scalers are better for performance of all scalers, except bilinear. Vertex shaders could lessen the load on the CPU when performing rotation and surface initialization. The font and subtitle renderers are are old and too CPU resource intensive, but I hope the development team can assemble a work force to re-write those. But that's really a lot of work. Other than that, I'd really like to fix the screenshot function and add EVR CP and VMR9 functions to EVR Sync.

For those that are interested in why I disabled Aero for D3DFS in my tester builds, I've included two variant tester builds in my folder that allow Aero to stay enabled in D3DFS. I get sync problems with either 8- or 10-bit mode and 10-bit output often initializes wrong, so I get a rainbow of colors on my screen. I wish it was possible to disable Aero on only the screen in use, that would solve this problem nicely.

[done75]

MPC-HC on xvidvideo.ru??? :confused:

[janos666]

New CMS test build (modified from JanWillem32 2961 source): x86 MSVC2010 SSE2 (http://www.mediafire.com/?m7m2dbp15rdp5zr) ; source (http://www.mediafire.com/?lx77prqy1ylb67b) ; patch against vanilla 2961 (http://www.mediafire.com/?p1s6148qti8jj3e)

New:
- "Pre-linearized input" ambient light option (use ONLY with custom pixel shaders which work in linear RGB spaces and don't apply the last gamma wighting step with them).

Changed:
- Improved static dithering for the Full floating point precision mode. (Don't worry if your eyes can't notice it. ; It's Attila's work too, by the way.)
- Fully reconstructed (still CIECAM02 based) Inverse-Encode curve handling. (It should be much faster now and it won't mess with the gamut emulation anymore.)
- Some small changes to improve speed and decrease the memory consumption during the 3DLUT creation.


Let me know if this speed and quality is reasonable for you.
-> The quality won't be improved further any time soon. (This is the best what lcms2.2b can do with standard ICM profiles.)
-> The speed could be improved with decreasing the LUT sizes. So, let me know if you can't see any small difference between Medium and High quality (and may be I will decrease the LUT sizes then).

If there is no negative response, I will finalize and send in this patch as it stands now.

EDIT: I updated the links:
- I slightly decreased the LUT size for the High Quality option because it was unstable with D3DFS + Full float modes together. (It should always work now while it's a little faster too but still should be enough...)

EDIT2: Another small (but dirty) hotfix.

[mark0077]

Guys, regarding using arcsoft audio decoder with mpc-hc, is it possible for a dev to allow it to be used without having to do the hex edit workaround in the mpc exe file?

[pdanpdan]

@JanWillem32
I tested both x64 and x86 builds with aero enabled and they work like a charm :). No problem for now.
Thank you.

[cyberbeing]

New CMS test build (modified from JanWillem32 2961 source): x86 MSVC2010 SSE2 (http://www.mediafire.com/?q5hsooqr42bzjpw) ; source (http://www.mediafire.com/?nabbrx4r3u06jr9) ; patch against vanilla 2961 (http://www.mediafire.com/?hoaa49paakn8wa1)
That build is borked. The RED and BLUE color channels are swapped when LCMS is enabled.

[janos666]

That build is borked. The RED and BLUE color channels are swapped when LCMS is enabled.

Download the files again. Sorry. (I have series of bad lucks today. :()

[cyberbeing]

Speed is improved. Old = ~42 seconds | New = ~6 seconds

The CIECAM02 inverse encode presets could use some more tweaking.
I'm still unable to get a good gamma match to my 0.0001 LUX Ambient Argyll CMS Rec.709 curve, which has an average gamma of 2.36.

It currently falls between the Office and the Dim setting. The Dark setting seems to be the equivalent of having a black-hole as ambient... If anything they need to be redefined. The current Inverse Encode (Dark) setting is useless and should be scrapped. The Inverse Encode (Dim) should be the limit for how dark things get, since it is already beyond the ~2.35 avg gamma that Argyll uses for a pitch black ambient.

Could you make a test build with fine increments between the current Inverse Encode Office and Dim settings? That would at least allow me to identify the closest match CIECAM02 setting by trial and error. Still a mystery as to why you can't get Argyll CIECAM02 to match lcms2 CIECAM02. Were you never able to figure the exact Argyll parameters for CIECAM02?

It's also worth mentioning that BPC enabled is a must, or near-black tones get crushed with Inverse Encode in that build.

[janos666]

Speed is improved. Old = ~42 seconds | New = ~6 seconds

Is it acceptable for you?
(It's only 3 seconds with my hardware and there are faster CPUs than mine and the pure-power is faster...)

The Dark setting seems to be the equivalent of having a black-hole as ambient...
The current Inverse Encode (Dark) setting is useless and should be scrapped.

Why shouldn't I set the ambient light to dark for the "Dark" preset (I mean really dark like now) if you can watch movies in a fully darkened room? (Relatively small and low-luminance scree in a room with low reflectance...)

The CIECAM02 inverse encode presets could use some more tweaking.
I'm still unable to get a good gamma match to my 0.0001 LUX Ambient Argyll CMS Rec.709 curve, which has an average gamma of 2.36.

Still a mystery as to why you can't get Argyll CIECAM02 to match lcms2 CIECAM02. Were you never able to figure the exact Argyll parameters for CIECAM02?

I gave up the studying of the ArgyllCMS source code really soon (may be too soon...) because:
- It's huge (thousands of lines per files) and the style is strange for me.
- I assume that the outputs will never really match (may be the average gamma will match but the curve itself won't ; I think you should not blindly trust in HCRF's assumption functions...).
(+ ArgyllCMS is a nice piece of software and Graeme is talented and smart but hey... those are only his random guess values just like these are mine... at least try to judge about the guess values subjectively before you take one of them as an absolute etalon...)
So I am not sore if I want to push this thing too hard.

But I can try to clear it for you why...

Fisrt of all: lcms uses less user definable CIECAM02 parameters than CIECAM02 itself uses and ArgyllCMS sets.

Insignificant things: I set the ambient light temperature to D50 (only because the XYZ profile is based on the D50 illuminant, so it doesn't mess with the user definable intent ; but both conditions has D50 values and the adaptation state is "Fully adapted" too, so there is no any correction.)

I set the studio ambient light conditions like this:
vc1.Yb = 20; vc1.La = 200/3.1415; vc1.surround = 1;

And I set the ambient light presets (bright..dark) as follows:

vc2.surround = 2; vc2.Yb = 20; vc2.La = 96/3.1415;
vc2.surround = 2; vc2.Yb = 20; vc2.La = 64/3.1415;
vc2.surround = 3; vc2.Yb = 20; vc2.La = 32/3.1415;
vc2.surround = 4; vc2.Yb = 20; vc2.La = 6/3.1415;

Let's start with the easy parts:

- The 3.1415 number is there because the values should be defined in cd/m^2 instead of LUX. (I could swallow it somehow that I should guess round LUX values to set up cd/m^2 parameters. It's absolutely ridiculous but fine...)
- I grabbed the 200 LUX studio luminance and the 20% thing from ArgyllCMS. (That's OK, I had no idea...)
- The other values are guess values (dispcal usually measures them in real-time with the sensor ; or reads them in from the command line parameters --- but after that... I didn't investigated it yet).

Now, let's clear the bigger problems...
- There is nothing like the vc[any].surround in ArgyllCMS (at least I couldn't find it yet - not if I spent too much time with studying it -> may be I will later) but there are many other parameters which are not controllable in lcms but set up in ArgyllCMS. (And I didn't even figured out yet that what they are. CIECAM02 is relatively young, so I can't find too much thing about it on the web...)
- May be you noticed that this surround parameter can only be set to 1,2,3,4 and that's all (1 means bright, 4 means "pitch black" but there is no "supernova").
- The lcms documentation is very close-mouthed about CIECAM02.

After all, I decided to include those guess values and wait for you to tell if you like them or not.

I would gladly change those presets if you give me new numbers. (I already said that I hate to make guesses when it seems I do science...)

I wouldn't be surprised if I miss something or I do something wrong with the CIECAM02 parameters.

It's also worth mentioning that BPC enabled is a must, or near-black tones get crushed with Inverse Encode in that build.
Not always. I usually have black-crush with anything else than [calibrate with pure-power curve + black offset (High Quality and Adaptive HiRes modes) ; construct a matrix + single gamma profile].
I basically do the same thing with yCMS too (but the reason is the lack of the white balance correction there).


The highest possible cLUT size with the ultra quality is ("only") 45x45x45 with float16 numbers. I can't feel that it's enough for characterizing uncalibrated displays or responses like Rec709.
Of course, there shaper curves in there too but I wish to disable them because they are not better than they are in matrix+shaper style profiles (may be worse).

I am not sure what's the problem with matrix + shaper|or|curve(s) style profiles but I think they are not enough to fully describe the uncalibrated or Rec709 responses. (I think it's because colprof likes to "smooth" aout the curves. May be too hard, but distinctly too hard for uncalibrated responses.)

I am not sure how lcms works internally but may be this is the tight cross section with curve based profiles (those "fast transforms"...). But PhotoShop usually behaves like lcms, so I guess it's may be a profile limitation, not a calculation error.


I would like to try a cLUT profile without the shaper curves but with 128x128x128 size. But it's too hard to compile ArgyllCMS on windows without programming experiences.

[cyberbeing]

Is it acceptable for you?
6 seconds isn't bad for High, but I'd probably stick with Medium (2 seconds) for casual viewing. Obviously, a night and day difference to 42 seconds.

Why shouldn't I set the ambient light to dark for the "Dark" preset (I mean really dark like now) if you can watch movies in a fully darkened room? (Relatively small and low-luminance scree in a room with low reflectance...)
Because that setting results in an average gamma near 3.0, which is a bit excessive. The Dim setting already results in a average gamma of ~2.6.

I assume that the outputs will never really match (may be the average gamma will match but the curve itself won't ; I think you should not blindly trust in HCRF's assumption functions...).
Well HCFR agrees with DispcalGUI's calculation of avg gamma from profile verification. There are only so many ways to calculate where measurement points fall on a power-curve. There is no assumption going on, only math.

First of all: lcms uses less user definable CIECAM02 parameters than CIECAM02 itself uses and ArgyllCMS sets.

Now, let's clear the bigger problems...
- There is nothing like the vc[any].surround in ArgyllCMS (at least I couldn't find it yet - not if I spent too much time with studying it -> may be I will later) but there are many other parameters which are not controllable in lcms but set up in ArgyllCMS. (And I didn't even figured out yet that what they are. CIECAM02 is relatively young, so I can't find too much thing about it on the web...)
- May be you noticed that this surround parameter can only be set to 1,2,3,4 and that's all (1 means bright, 4 means "pitch black" but there is no "supernova").
- The lcms documentation is very close-mouthed about CIECAM02.

If lcms2 isn't flexible enough with CIECAM02 parameters, then we're indeed stuck if Argyll CMS specifically defines them.

I set the studio ambient light conditions like this:
vc1.Yb = 20; vc1.La = 200/3.1415; vc1.surround = 1;
- I grabbed the 200 LUX studio luminance and the 20% thing from ArgyllCMS. (That's OK, I had no idea...)

Are you sure that's correct? On the mailing list, Graeme clearly said he used 1000 LUX as the studio luminance for REC.709. Wouldn't your current use of 200 LUX throw off scaling by a lot?

After all, I decided to include those guess values and wait for you to tell if you like them or not.
Inverse Encode Bright = Very Bad
Inverse Encode Office = Close to Acceptable for a Bright Room
Inverse Encode Dim = Close to Acceptable for a Dark Room
Inverse Encode Dark = Very Bad

I would gladly change those presets if you give me new numbers. (I already said that I hate to make guesses when it seems I do science...)
I wouldn't be surprised if I miss something or I do something wrong with the CIECAM02 parameters.
At this point, you know more about CIECAM02 than I do, and that doesn't say much...

Try making a build using 1000 LUX as the studio gamma for REC.709 and let's see if anything improves...

Not always. I usually have black-crush with anything else than [calibrate with pure-power curve + black offset ; construct a matrix + single gamma profile]. I basically do the same thing with yCMS too (but the reason is the lack of the white balance correction there).
I was saying that lcms was darkening near-black tones rather significantly to the point that they were no distinguishable on my monitor when viewing a test pattern. Enabling BPC kept those tones visible and closer the original video tones, and honestly where they should be. This is only an issue when using Inverse Encode. But overall a non-issue since BPC resolves it.

[Tsukihime]

what happens to xvidvideo.ru?
It doesn't have mpc-hc svn build any more...

[Aleksoid1978]

xvidvideo.ru - will no longer be MPC-HC on this site.
Author - Alexins - declined further assembly.

[Carpo]

any reason why? and any idea where we can get svn builds now

[betaking]

any reason why? and any idea where we can get svn builds now
build by xhmikosr!
http://xhmikosr.1f0.de/ :)

[Virtual_ManPL]

Seems like there won't be any updates to Black Edition...
Too bad, I liked it...

http://img833.imageshack.us/img833/4899/mpchcbe.png



Now, how about finally officially releasing SVN builds on https://code.google.com/p/mpc-hc/ (https://code.google.com/p/mpc-hc/) ?

[Carpo]

build by xhmikosr!
http://xhmikosr.1f0.de/ :)

Thanks :-)

[tetsuo55]

Now, how about finally officially releasing SVN builds on https://code.google.com/p/mpc-hc/ (https://code.google.com/p/mpc-hc/) ?That's the plan.

[hoborg]

Hi,

Aleksoid make a patch for it, i have started it too but his approach is better.

Now we have a setting in registry : VC1_Decoder_Output in
HKEY_CURRENT_USER\Software\Gabest\Filters\MPEG Splitter for standalone Filter
HKEY_CURRENT_USER\Software\Gabest\Media Player Classic\Filters\MPEG Splitter for MPC-HC soft.

1- Standard Connection (Microsoft DMO) "{31435657-0000-0010-8000-00AA00389B71}"
2- Cyberlink PDVD Codec "{D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53}"
3- Arcsoft Codec "{629B40AD-AD74-4EF4-A985-F0C8D92E5ECA}"

A dialog menu will be add soon :)

Standalone Filter, MPC-HC and reg file can be downloaded here :
MPC_vc1_Filter_Reg (http://www.mediafire.com/?jne6w47060dw7rc)

Thank you Aleksoid :)
Sebastiii.

Thanks, it is working great!
I am happy with "D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53" becouse FFDshow accept it and PDVD too :)

[Superb]

Which site is the official project page? GoogleCode or SF.net?
Which SVN repository the official one? GoogleCode or SF.net?
What is the latest official version? 1.5.0.2827 (on GoogleCode) or v1.5.1.2903 (on SF.net)?
Can you guys make all these question clear and use a central project location?

[vBm]

Which site is the official project page? GoogleCode or SF.net?
Which SVN repository the official one? GoogleCode or SF.net?
What is the latest official version? 1.5.0.2827 (on GoogleCode) or v1.5.1.2903 (on SF.net)?
Can you guys make all these question clear and use a central project location?
Both are official.
There are preps in order to move to GoogleCode to be the main repository.

[janos666]

Well HCFR agrees with DispcalGUI's calculation of avg gamma from profile verification. There are only so many ways to calculate where measurement points fall on a power-curve. There is no assumption going on, only math.

Is it not an assumption to describe the response of an individually scaled Rec709 curve with a single "average gamma" value?
It never was a pure-power curve and it's not a simple "power curve with a streigt segment" anymore. It's a mutated freak which couldn't be described by <20 parameters.
So, a matching avg gamma doesn't necessarily means that you have the same curves. May be the avg gamma has to be different to achieve the overall closest match (CIECAM is CIECAM but lcms is not Argy...)


If lcms2 isn't flexible enough with CIECAM02 parameters, then we're indeed stuck if Argyll CMS specifically defines them.

There is a backup solution: borrow the entire CICAM02 code from ArgyllCMS with all of it's parameters. (I am not sure if I want to do that or if I can do that.)


Are you sure that's correct? On the mailing list, Graeme clearly said he used 1000 LUX as the studio luminance for REC.709. Wouldn't your current use of 200 LUX throw off scaling by a lot?

I found these in dispcal.c (about line 3755):

case gt_Rec709:
case gt_SMPTE240M: /* Television studio conditions */
x.svc->set_view(x.svc, vc_none,
x.nwh, /* Display normalised white point */
0.2 * 1000.0/3.1415, /* Adapting luminence, 20% of 1000 lux in cd/m^2 */
0.2, /* Background relative to reference white */
1000.0/3.1415, /* Luminance of white in the Image field (cd/m^2) */
0.01, x.nwh, /* 1% flare same white point */
0, 0);

x.dvc->set_view(x.dvc, vc_none,
x.nwh, /* Display normalised white point */
0.2 * ambient, /* Adapting luminence, 20% of ambient in cd/m^2 */
0.2, /* Background relative to reference white */
x.twh[1], /* Target white level (cd/m^2) */
0.01, x.nwh, /* 1% flare same white point */
0, 0);

Display normalised white point
- I set both white points to D50 which is the white point of the XYZ space I use for this transform and I set the adaptation state to "Fully Adapted".
- My speed trick was that I use monochrome gray input values and then copy the resulted curve for all (RGB) channels.
So there should be zero white point correction during the curve scaling and it couldn't affect the white balance of the RGB values. It's a simple luminance scaling now.

Background relative to reference white
I have no idea how to determine it but I accepted the 20%.

Adapting luminence, 20% of...
Here comes the 200 LUX (0.2*1000) for the studio. The ambient preset values are guess values between 0 and 200...

1% flare same white point
I have no idea what this is but there is no lcms parameter like this. (And I suspect that lcms either ignores this correction which is not a problem if you would set both ambient parameters to the same value, or the hard-coded default value is matching with ArgyllCMS by default.)

Luminance of white in the Image field |and| Target white level
I am not sure.
May be I mixed up the parameters and this one should be the "La" value for lcms and the LUX based values are controlled by the surround preset...?

Inverse Encode Bright = Very Bad
Inverse Encode Office = Close to Acceptable for a Bright Room
Inverse Encode Dim = Close to Acceptable for a Dark Room
Inverse Encode Dark = Very Bad

Very bad for what purpose? Did you try the Bright preset in really bright room (like a TV studio) and the Dark preset in pitch black?


I was saying that lcms was darkening near-black tones rather significantly to the point that they were no distinguishable on my monitor when viewing a test pattern.

I know. That's why I added the BPC function. But I still have better results with matrix + single gamma profiles.

This is a very strange thing because I calibrated and/or profiled a plasma TV and some c-PVA panels too. They all had significantly higher contrast ratios (but smaller gamuts) than my IPS display but there were less problems with near-black shades. May be because my display has a factory calibrated lut and they tried to do some kind of BPC too (but different than Argy). Or it's the "Advanced-FRC" dithering in the panel. I don't know.

-----------------------------------

I just read the cmscam02.c (lcms):

The surround parameter of lcms controls the F, c, Nc CIECAM02 parameters:
F -- factor determining degree of adaptation
c -- impact of surrounding
Nc - chromatic induction factor[/CODE]
Now that I identified these parameters, I know what remained:
Sr = Yb - reference white luminance / surround luminance

For some reason ArgyllCMS uses fixed Sr=0.2 while the wikipedia article suggests that it should be set together with the F, c, Nc parameters. -> linear interpolation between the tree very scientifically described presets, like "projector in dark room".
You know... If you have only a half projector in an almost but not perfectly dark coliseum, then you should use linear interpolation... (or buy a new projector to replace the broken one and use the veils...) HAHHH :p
So, I don't care about the surround parameter anymore. I just leave it as is.

I am only more confused now because I would change the Yb parameter but that will lead us further from ArgyllCMS. :confused:


May be I will try another set of parameters and post a test build later.

And I will ask Marti about it. May be he has an idea how to match with ArgyllCMS.

[ramicio]

I wish there was options to put whatever information one wanted in the black area at the bottom. Like single statistics at a time, without needing to take up half of one's screen to view them all mandatory.

[cyberbeing]

@janos666
Well I took some time to look at some source code and your patch.


ViewingCondition Ev, /* Enumerated Viewing Condition */
double Wxyz[3], /* Reference/Adapted White XYZ (Y range 0.0 .. 1.0) */
double La, /* Adapting/Surround Luminance cd/m^2 */
double Yb, /* Relative Luminance of Background to reference white (range 0.0 .. 1.0) */
double Lv, /* Luminance of white in the Viewing/Scene/Image field (cd/m^2) */
/* Ignored if Ev is set to other than vc_none */
double Yf, /* Flare as a fraction of the reference white (Y range 0.0 .. 1.0) */
double Fxyz[3], /* The Flare white coordinates (typically the Ambient color) */
double C; /* Surround Impact */
double Nc; /* Chromatic Induction */
double F; /* Adaptation Degree */
Is dispcal doing vc_none? If so, how do we use Lv, which is not a CIECAM02 parameter? That would be a question for Graeme.

*svc; /* Source viewing conditions */
*dvc; /* Destination viewing conditions */


/* Television studio conditions */
x.svc->set_view(x.svc, vc_none,
x.nwh, /* Display normalised white point */
0.2 * 1000.0/3.1415, /* Adapting luminence, 20% of 1000 lux in cd/m^2 */
0.2, /* Background relative to reference white */
1000.0/3.1415, /* Luminance of white in the Image field (cd/m^2) */
0.01, x.nwh, /* 1% flare same white point */
0, 0);
Television studio conditions
Wxyz = Display normalized white point <- REC.709 D65
La = 0.2 * 1000.0/3.1415
Yb = 0.2
Lv = 1000.0/3.1415
Yf = 0.01
Fxyz = Display normalized white point <- REC.709 D65

/* The display we're calibratings situation */
x.dvc->set_view(x.dvc, vc_none,
x.nwh, /* Display normalised white point */
0.2 * ambient, /* Adapting luminence, 20% of ambient in cd/m^2 */
0.2, /* Background relative to reference white */
x.twh[1] /* Target white level (cd/m^2) */
0.01, x.nwh, /* 1% flare same white point */
0, 0);
Wxyz = Display normalized white point <-Read from the ICC profile wtpt tag
La = 0.2 * ambient (cd/m^2) <- Ambient Bright/Office/Dim/Dark presets
Yb = 0.2
Lv = Target white level (cd/m^2) <-Read from the ICC profile lumi tag
Yf = 0.01
Fxyz = Display normalized white point <-Read from the ICC profile wtpt tag


The source color temperature should be set to D65 for REC.709, not D50. The destination color temperature should be read from the ICC profile wtpt tag.
Change vc1 to svc = source viewing condition. Change vc2 to dvc = destination viewing condition. That will make things clearer about what they represent.
(I've put changes in bold)
// Set up initial CIECAM02 parameters
cmsViewingConditions svc, dvc;

svc.whitePoint.X = 0.95047; svc.whitePoint.Y = 1.0; svc.whitePoint.Z = 1.08883; dvc.whitePoint = cmsReadTag(hProfile, cmsSigMediaWhitePointTag) ;
svc.D_value = dvc.D_value = 1.0;
// You may need to create a parsing function for "cmsReadTag(hProfile, cmsSigMediaWhitePointTag)" to get values in the correct format

const double luxtocdm = 3.1415; // Assumptions about the studio view conditions
svc.Yb = 0.2; svc.La = 200/luxtocdm; svc.surround = 1; // CAUTION: these are only guess values!
//Since lcms2 defines Yb as a 'cmsFloat64Number', it should likely be a decimal (0.2 vs 20 for 20%)


switch(Ev) {
case vc_dark:
s->C = 0.525;
s->Nc = 0.8;
s->F = 0.8;
break;
case vc_dim:
s->C = 0.59;
s->Nc = 0.95;
s->F = 0.9;
break;
case vc_cut_sheet:
s->C = 0.41;
s->Nc = 0.8;
s->F = 0.8;
break;
default: /* average */
s->C = 0.69;
s->Nc = 1.0;
s->F = 1.0;
break;
/* La/Lv <10%, dark */
/* La/Lv 10 - <20%, dim */
/* La/Lv >=20%, average */
/* special, cut sheet */#define AVG_SURROUND 1
#define DIM_SURROUND 2
#define DARK_SURROUND 3
#define CUTSHEET_SURROUND 4case CUTSHEET_SURROUND:
lpMod->F = 0.8;
lpMod->c = 0.41;
lpMod->Nc = 0.8;
break;

case DARK_SURROUND:
lpMod -> F = 0.8;
lpMod -> c = 0.525;
lpMod -> Nc = 0.8;
break;

case DIM_SURROUND:
lpMod -> F = 0.9;
lpMod -> c = 0.59;
lpMod -> Nc = 0.95;
break;

default:
// Average surround
lpMod -> F = 1.0;
lpMod -> c = 0.69;
lpMod -> Nc = 1.0;

Argyll CMS uses a fixed 'Average' surround (or not, SEE BELOW EDIT) in dispcal when scaling the gamma curve with CIECAM02. In other words, all of the below should be set to 1 in LCMS (no wonder your Dark preset has such a high gamma, you were using CUTSHEET...). You could ask Graeme the logic behind this, but I believe it's because 'Average' is the default and non-default CIECAM02 'surround' would need a specially created ICC profile. In other words, the surround parameter should be kept at the default unless a specially created CIECAM02 source and destination ICC profile define something different.
(I've put changes in bold)
// Get the ambient view condition parameters
// For more information about the recommended TRC, see the paper at http://www.poynton.com/notes/PU-PR-IS/Poynton-PU-PR-IS.pdf
// I decided to include these strange "CIECAM02-Scaled-Inverse-Encode" curves anyway.
// The manually determined exponents are used for the Pure-Power TRCs and I set the CIECAM02 view condition parameters for the Inverse Encode TRC scaling here.
switch (m_AmbientLight) {
case AMBIENT_LIGHT_BRIGHT: dvc.surround = 1; dvc.Yb = 0.2; dvc.La = 96/luxtocdm; // CAUTION: these are only random guess values.
exponent = 2.2; break;
case AMBIENT_LIGHT_OFFICE: dvc.surround = 1; dvc.Yb = 0.2; dvc.La = 64/luxtocdm; // It requires further testing and fine-tuning (if they will ever work).
exponent = 2.3; break;
case AMBIENT_LIGHT_DIM: dvc.surround = 1; dvc.Yb = 0.2; dvc.La = 32/luxtocdm;
exponent = 2.35; break;
case AMBIENT_LIGHT_DARK: dvc.surround = 1; dvc.Yb = 0.2; dvc.La = 1/luxtocdm;
exponent = 2.4; break;
case AMBIENT_LIGHT_BYPASSLINEAR: exponent = 1.0; break; // Linear input TRC to process prelinearized data (custom pixel shaders).

Could you try making a build with the changes I listed here and above?
If it doesn't work, post your patch to the Argyll mailing list and see if anybody can offer some guidance about what's wrong. The changes I listed appear to match Argyll's dispcal CIECAM02 setting. If it doesn't work correctly in lcms, either Argyll or lcms isn't implementing CIECAM02 correctly...

_______
Edit: Just realized something. The following is probably why it hasn't been match Argyll CMS dispcal.
/* La/Lv <10%, dark */
/* La/Lv 10 - <20%, dim */
/* La/Lv >=20%, average */

Rather then Argyll using 'Average' Surround for the Destination Viewing Condition, Surround value is based on your monitor's luminance. (This can be read from the ICC lumi tag).

Let's say your display luminance (lv) is 80 cd/m^2.
Ambient = 32 lux (~10 cd/m^2 * 0.2 = 2 cd/m^2) = 2(La)/80(Lv) = Dark Surround
Ambient = 64 lux (~20 cd/m^2 * 0.2 = 4 cd/m^2) = 4(La)/80(Lv) = Dark Surround
Ambient = 96 lux (~30 cd/m^2 * 0.2 = 6 cd/m^2) = 6(La)/80(Lv) = Dark Surround

Let's say your display luminance (lv) is 300 cd/m^2.
Ambient = 32 lux (~10 cd/m^2 * 0.2 = 2 cd/m^2) = 2(La)/300(Lv) = Dark Surround
Ambient = 64 lux (~20 cd/m^2 * 0.2 = 4 cd/m^2) = 4(La)/300(Lv) = Dark Surround
Ambient = 96 lux (~30 cd/m^2 * 0.2 = 6 cd/m^2) = 6(La)/300(Lv) = Dark Surround

In other words, you would always be using the Dark Surround preset.
// Get the ambient view condition parameters
// For more information about the recommended TRC, see the paper at http://www.poynton.com/notes/PU-PR-IS/Poynton-PU-PR-IS.pdf
// I decided to include these strange "CIECAM02-Scaled-Inverse-Encode" curves anyway.
// The manually determined exponents are used for the Pure-Power TRCs and I set the CIECAM02 view condition parameters for the Inverse Encode TRC scaling here.
switch (m_AmbientLight) {
case AMBIENT_LIGHT_BRIGHT: dvc.surround = 3; dvc.Yb = 0.2; dvc.La = 96/luxtocdm; // CAUTION: these are only random guess values.
exponent = 2.2; break;
case AMBIENT_LIGHT_OFFICE: dvc.surround = 3; dvc.Yb = 0.2; dvc.La = 64/luxtocdm; // It requires further testing and fine-tuning (if they will ever work).
exponent = 2.3; break;
case AMBIENT_LIGHT_DIM: dvc.surround = 3; dvc.Yb = 0.2; dvc.La = 32/luxtocdm;
exponent = 2.35; break;
case AMBIENT_LIGHT_DARK: dvc.surround = 3; dvc.Yb = 0.2; dvc.La = 1/luxtocdm;
exponent = 2.4; break;
case AMBIENT_LIGHT_BYPASSLINEAR: exponent = 1.0; break; // Linear input TRC to process prelinearized data (custom pixel shaders).


If you don't multiply by 0.2, then you would have something as follows:
Let's say your display luminance (lv) is 80 cd/m^2.
Ambient = 1 lux (~0.3 cd/m^2) = 0.3(La)/80(Lv) = Dark Surround
Ambient = 32 lux (~10 cd/m^2) = 10(La)/80(Lv) = Dim Surround
Ambient = 64 lux (~20 cd/m^2) = 20(La)/80(Lv) = Average Surround
Ambient = 96 lux (~30 cd/m^2) = 30(La)/80(Lv) = Average Surround

Let's say your display luminance (lv) is 300 cd/m^2.
Ambient = 32 lux (~10 cd/m^2) = 10(La)/300(Lv) = Dark Surround
Ambient = 64 lux (~20 cd/m^2) = 20(La)/300(Lv) = Dark Surround
Ambient = 96 lux (~30 cd/m^2) = 30(La)/300(Lv) = Dark Surround

In this case, by skipping the 20% deal, you get a variable result depending on how bright your display is. Below would be for 80 cd^m2, but it would really need to read the ICC lumi tag and set surround dynamically.
// Get the ambient view condition parameters
// For more information about the recommended TRC, see the paper at http://www.poynton.com/notes/PU-PR-IS/Poynton-PU-PR-IS.pdf
// I decided to include these strange "CIECAM02-Scaled-Inverse-Encode" curves anyway.
// The manually determined exponents are used for the Pure-Power TRCs and I set the CIECAM02 view condition parameters for the Inverse Encode TRC scaling here.
switch (m_AmbientLight) {
case AMBIENT_LIGHT_BRIGHT: dvc.surround = 1; dvc.Yb = 0.2; dvc.La = 96/luxtocdm; // CAUTION: these are only random guess values.
exponent = 2.2; break;
case AMBIENT_LIGHT_OFFICE: dvc.surround = 1; dvc.Yb = 0.2; dvc.La = 64/luxtocdm; // It requires further testing and fine-tuning (if they will ever work).
exponent = 2.3; break;
case AMBIENT_LIGHT_DIM: dvc.surround = 2; dvc.Yb = 0.2; dvc.La = 32/luxtocdm;
exponent = 2.35; break;
case AMBIENT_LIGHT_DARK: dvc.surround = 3; dvc.Yb = 0.2; dvc.La = 1/luxtocdm;
exponent = 2.4; break;
case AMBIENT_LIGHT_BYPASSLINEAR: exponent = 1.0; break; // Linear input TRC to process prelinearized data (custom pixel shaders).

So try making three builds.

The first with Surround Dark (dvc.surround = 3) set for all presets <- I now believe this is dispcal behavior

The second Surround Average (dvc.surround = 1) set for all presets. <- I originally thought this was what dispcal was doing, but now I'm not so sure. Build it anyway, just to confirm.

The third with Dark Preset = Dark Surround (dvc.surround = 3), Dim Preset = Dim Surround (dvc.surround = 2), Office preset = Average Surround (dvc.surround = 1), and Bright preset = Average Surround (dvc.surround = 1). <- This would be different than Argyll CMS, but it would result in a much larger adjustment. No clue if ignoring the 20% thing Argyll does for the La parameter would be considered 'correct' or not. If doing this, REC.709 should also be changed from 200 to 1000 lux to stay consistent.

I suspect that Argyll is indeed using Average Surround for REC.709 CIECAM02 source and Dark Surround for CIECAM02 destination when doing all ambient light gamma scaling. That would explain why there is hardly any change (< 0.05 avg gamma) in Argyll's viewing condition adjustment between 0 lux and 64 lux.

[janos666]

The source color temperature should be set to D65 for REC.709, not D50. The destination color temperature should be read from the ICC profile wtpt tag.
I already explained that it doesn't matter because I work with gray colors.

The input is G = 1..256
G->XYZ (from Rec709 to linear)
XYZ->Jab
CIECAM02 corrections
Jab->XYZ
XYZ->G (from linear to linear)
And then r=G, g=G, b=G, and these are the new RGB curves. Theay are identical, so it can't affect the final white point or white balance.

But the D50 is a standard illuminant (the built in XYZ profile is based on this illuminant), so I guess it's the best choice to avoid any possible clipping (which could lead to another errors). And it is more convenient to use (becaouse of various reasons).

The color temperature correction is another transform which affects every colors. So, don't worry about it. This is the only thing which we shouldn't really care about...


Now, I can see that you are almost as concerned about how to mix the lcms parameters with ArgyllCMS parameters as I am. (You are constantly editing your post and changing your mind...)
I have only one advantage over you: I did more "trial and error" with the lcms parameters.

Surround value is based on your monitor's luminance. (This can be read from the ICC lumi tag).

Yes, I thought about that but I can't see the point in this. How they are correlated (surround and display luminance)?

-----------
I am struggling with something else now and I should go to sleep soon. But I will read the rest of your post and make new builds tomorrow.

[cyberbeing]

I already explained that it doesn't matter because I work with gray colors.
I also realized that after I posted. Since we aren't using CIECAM02 for color correction any longer, the specified color temperature likely makes no difference there. I left it as-is, since I don't know enough about CIECAM02. It's color temperature locus could change how it deals with luminance. Unless someone knowledgeable says otherwise, I agree that it is likely better, left as-is.

Now, I can see that you are almost as concerned about how to mix the lcms parameters with ArgyllCMS parameters as I am. (You are constantly editing your post and changing your mind...)
I have only one advantage over you: I did more "trial and error" with the lcms parameters.
Sorry about the constant edits. :p
I posted one thing, but did change my mind after reading a bit more. Instead of deleting it and starting over, I just tacked on things to the end.

Yes, I thought about that but I can't see the point in this. How they are correlated (surround and display luminance)?
Rec.709 Source Display
La = 0.2 * 1000.0/3.1415
Lv = 1000.0/3.1415
Your Destination Display
La = 0.2 * ambient (cd/m^2)
Lv = Target white level (cd/m^2)
How Argyll determines the CIECAM02 surround value to use.
/* La/Lv <10%, dark */
/* La/Lv 10 - <20%, dim */
/* La/Lv >=20%, average */
Lv = Luminance of white in the Viewing/Scene/Image (aka Monitor luminance)
La = Adapting/Surround Luminance (aka 20% Ambient Light)

For your REC.709 Source Display conditions you have, 200 (La) / 1000 (Lv) = 20% = CIECAM02 Average Surround.
Argyll assumes the REC.709 source reference to be a bright image in an equally bright ambient light. When Ambient Light is equal to or greater than Display Luminance, this is considered a CIECAM02 Average Surround.

For your Destination Display with 251 lux luminance (80 cd/m^2 aka dispcal's Target White Level) and 32 lux Ambient Light you have, have 6.4 (La) / 251 (Lv) = 2.5% = CIECAM02 Dark
In this case we have a dim 251 lux monitor in a much darker 32 lux ambient light. Since there is a large difference between the monitor luminance and ambient luminance, this is considered CIECAM02 Dark Surround.

This makes me realize I may have made another mistake in my previous post. 'La' doesn't equal Ambient Light, it's actually 20% of ambient light according to Argyll CMS.
The resulting code changes would then be as follows for what I assume is Argyll CMS behavior, using only 20% values for La and Dark Surround CIECAM02.

// Get the ambient view condition parameters
// For more information about the recommended TRC, see the paper at http://www.poynton.com/notes/PU-PR-IS/Poynton-PU-PR-IS.pdf
// I decided to include these strange "CIECAM02-Scaled-Inverse-Encode" curves anyway.
// The manually determined exponents are used for the Pure-Power TRCs and I set the CIECAM02 view condition parameters for the Inverse Encode TRC scaling here.
switch (m_AmbientLight) {
case AMBIENT_LIGHT_BRIGHT: dvc.surround = 3; dvc.Yb = 0.2; dvc.La = 19.2/luxtocdm; // CAUTION: these are only random guess values.
exponent = 2.2; break;
case AMBIENT_LIGHT_OFFICE: dvc.surround = 3; dvc.Yb = 0.2; dvc.La = 12.8/luxtocdm; // It requires further testing and fine-tuning (if they will ever work).
exponent = 2.3; break;
case AMBIENT_LIGHT_DIM: dvc.surround = 3; dvc.Yb = 0.2; dvc.La = 6.4/luxtocdm;
exponent = 2.35; break;
case AMBIENT_LIGHT_DARK: dvc.surround = 3; dvc.Yb = 0.2; dvc.La = 0.2/luxtocdm;
exponent = 2.4; break;
case AMBIENT_LIGHT_BYPASSLINEAR: exponent = 1.0; break; // Linear input TRC to process prelinearized data (custom pixel shaders).

I guess you could make that a 4th build :scared:

I would encourage you to post the current state of your patch to the Argyll CMS mailing list with the questions/changes I brought up. Asking for help is better then making guesses totally in the dark. I think I have a pretty good idea of what Argyll is doing now, but it could use some confirmation and guidance from Graeme.

[73ChargerFan]

Open Source Humor: http://who-t.blogspot.com/2011/03/how-to-dos-developer.html
It explains how to submit evil bug reports.

[G_M_C]

I also realized that after I posted. Since we aren't using CIECAM02 for color correction any longer, the specified color temperature likely makes no difference there. I left it as-is, since I don't know enough about CIECAM02. It's color temperature locus could change how it deals with luminance. Unless someone knowledgeable says otherwise, I agree that it is likely better, left as-is.


[...]

But i do agree that the target display white point should be assumed @ D65. This is what is says on the calibration report I got when my display was ISF-calibrated.

[Brazil2]

Which site is the official project page? GoogleCode or SF.net?
Which SVN repository the official one? GoogleCode or SF.net?
What is the latest official version? 1.5.0.2827 (on GoogleCode) or v1.5.1.2903 (on SF.net)?
Can you guys make all these question clear and use a central project location?

Both are official.
There are preps in order to move to GoogleCode to be the main repository.

Can anyone else confirm that v1.5.1.2903 at SF.net is an official release ?
And if so why there are no individual filters available ? Why the main site (http://mpc-hc.sourceforge.net) hasn't been updated accordingly ?
This is very confusing.

[JanWillem32]

I've merged the source code of this build with the one posted earlier by janos666. Quite a nice new set of features were added to the dithering and color management section.
Only the test mode for dithering and the new random ordered single-level ditherer are mine this time, but I'm quite satisfied with those for now.
Tester versions and modified source code downloads are available in my folder. These are built by Visual Studio 2010, are available in x86 and x64 types and were deviated from build 2962.

[janos666]

But i do agree that the target display white point should be assumed @ D65. This is what is says on the calibration report I got when my display was ISF-calibrated.

This is nothing like that. The white point is corrected elsewhere (but do corrected according to your settings, like relative or absolute intent, WP adapt state, etc).
The CIECAM02 part works with gray values only. How do you change the color of Gray = 256? (Not R=G=B=256)
Setting it to D50 just ensures that lcms or CIECAM02 won't try to correct the white point in the Jab or XYZ spaces where the gray values go through during the process (where they are real 3D colors, but still D50 grays and should remain D50 grays --> and the the reference is D50 so I think this is the safest setting).

@cyberbeing - The same thing applies to your first code lines. Leave the WP settings alone! They makes no different with D=1.0 anyway. And they have NO business here. The WP and WB correction is another transform (later).

I used Yb=20 for 20% because Marti used this number for a code example in the lcms documentation. (May be he was wrong but I believe that it should be 20. The other float64 numbers work like this too - they don't need to be normalized.)
Lcms was made to be very user friendly (may be too dumb user friendly). Even the exponent is inverted. You have to input gamma values instead of the real exponent values for the math functions. (I didn't follow this with my Rec709 curve definition. I used the standard functions and standard values.)

but it would really need to read the ICC lumi tag and set surround dynamically

I can do that. But I am not sure if I want to.
The only sanity in this that somebody will probably set lower display luminance for a dark room and higher display luminance for a bright room.
But there is no any real correlation between the display luminance and surround luminance. It's only a guess.
Otherwise... We are using Abmient Light presets here. So, it's easy to say that you probably set a Dark preset in MPC-HC if you sit in a dark room, and so on...

But Ok, this will be the next thing in the line if other attempts fail.

I would encourage you to post the current state of your patch to the Argyll CMS mailing list

I have asked Graeme and he helped as much as he wanted ("read the code"). But I already sent a mail to the lcms list, so Marti may clear up these things.

I just downloaded Jan's latest source and I will post some test builds with modified CIECAM02 parameters later.

-------------------------

Meanwhile, I suggest you (or anybody who is interested in HQ CMS with MPC-HC) to do the following with ArgyllCMS (easier and faster with DispcalGUI):
- Reset your VGA LUT and temporary disable CMS in the software you will use now
- Restore any display settings to their default values (except the brightness) and/or find the settings which preserves the most color tones (-> subjective test with a 8-bit gray gradient is fine - without CMS while you do this...).
- Run a test on your uncalibrated display to figure out the current average gamma value
- Set your calibration targets to native white point, native white luminance, native black luminance, and the same gamma value you figured out earlier (keep the Relative scaling and the 100% black offset options)
- Create a minimal test chart (5 neutral and 2 single channel patches with targen will result in 8 patches at total)
- Run a high quality calibration (and choose adaptive hires mode for spectros if available)
- Construct a "matrix + single gamma" style profile with measuring your minimal test chart.
- Apply the resulted ICM for Windows CMS
- Set the rendering intent to Absolute Colorimetric in MPC-HC and the WP Adapt state to None.

If you validate this profile, you will probably have low dE values everywhere except some very dark colors. That's because black offset is not a standard thing and dispcal won't try to correct the huye of these colors by default on LCDs.

If you do this with Half or Full floating point precision modes (and a reasonable display) and apply dithering, then you will probably end up with the best possible result. (Unless you have a display with hardware calibration capabilities and 12+ bit internal 3DLUTs...)

Another (faster and smarter) alternative would be to skip the entire calibration and construct a high quality profile from a big test chart ("matrix + curves" style profile from 64 single channel + 1 white patches). But lcms doesn't support black point compensation with the absolute intent and it's not so good with the relative intent either. (May be I will try to make a custom absolute intent and fine-tune the BPC later if we finished with the CIECAM02 parameters. ; May be you are fine without BPC if you have a Kuro, so you can try it now if you wish.)

[QQ]

Hello,

using internal MKV source filter, I cannot select a different audio track, menu is disabled. Using Haali, I can navigate to filters, haali, then change it there.

Is this by design?

[janos666]

test mode for dithering and the new random ordered single-level ditherer are mine this time

The test mode was a good idea, just like the "random ordered" dithering. (I thought about this one too but eventually found it redundant next to the random noise methods).

I found a small mistake in the merged code but there will be a small (mostly CIECAM02) update anyway...

-------------

@cyberbeing - So, here are the test builds (based on Jan's code above): http://www.mediafire.com/?389phs0m5p9mj1h
I kept the D50 WP and made different builds with different settings as follows (the first line is the studio preset, and Bright..Dark):

01
vc1.Yb = 20; vc1.La = 0.2*1000/luxtocdm; vc1.surround = 1;

vc2.surround = 3; vc2.Yb = 20; vc2.La = 96/luxtocdm;
vc2.surround = 3; vc2.Yb = 20; vc2.La = 64/luxtocdm;
vc2.surround = 3; vc2.Yb = 20; vc2.La = 32/luxtocdm;
vc2.surround = 3; vc2.Yb = 20; vc2.La = 6/luxtocdm;


02
vc1.Yb = 20; vc1.La = 0.2*1000/luxtocdm; vc1.surround = 1;

vc2.surround = 3; vc2.Yb = 20; vc2.La = 0.2*96/luxtocdm;
vc2.surround = 3; vc2.Yb = 20; vc2.La = 0.2*64/luxtocdm;
vc2.surround = 3; vc2.Yb = 20; vc2.La = 0.2*32/luxtocdm;
vc2.surround = 3; vc2.Yb = 20; vc2.La = 0.2*6/luxtocdm;


03
vc1.Yb = 0.2; vc1.La = 0.2*1000/luxtocdm; vc1.surround = 1;

vc2.surround = 3; vc2.Yb = 0.2; vc2.La = 96/luxtocdm;
vc2.surround = 3; vc2.Yb = 0.2; vc2.La = 64/luxtocdm;
vc2.surround = 3; vc2.Yb = 0.2; vc2.La = 32/luxtocdm;
vc2.surround = 3; vc2.Yb = 0.2; vc2.La = 6/luxtocdm;

04
vc1.Yb = 0.2; vc1.La = 0.2*1000/luxtocdm; vc1.surround = 1;

vc2.surround = 3; vc2.Yb = 0.2; vc2.La = 0.2*96/luxtocdm;
vc2.surround = 3; vc2.Yb = 0.2; vc2.La = 0.2*64/luxtocdm;
vc2.surround = 3; vc2.Yb = 0.2; vc2.La = 0.2*32/luxtocdm;
vc2.surround = 3; vc2.Yb = 0.2; vc2.La = 0.2*6/luxtocdm;

Now, you can see that some of them are absolutely redundant. For a quick look it seems like those settings are simply ignored and only the surround = 1,2,3,4 makes significant difference (but I didn't measure anything).

[vBm]

Can anyone else confirm that v1.5.1.2903 at SF.net is an official release ?
And if so why there are no individual filters available ? Why the main site (http://mpc-hc.sourceforge.net) hasn't been updated accordingly ?
This is very confusing.

It is official release, filters are not available cause casimir didn't build 'em. Site is not updated cause dude who made site is working on new one and he's MIA atm.

[fastplayer]

Hello,

using internal MKV source filter, I cannot select a different audio track, menu is disabled. Using Haali, I can navigate to filters, haali, then change it there.

Is this by design?
Is the Audio Switcher enabled? If not, you can't switch tracks.

[QQ]

Is the Audio Switcher enabled? If not, you can't switch tracks.

that was it, thanks!

one more question - it still instantiates an instance of decoder for each of the tracks (filters menu lists a decoder for each of the track), is this normal? isnt it trying to decode them all simultaneously?

[fastplayer]

that was it, thanks!

one more question - it still instantiates an instance of decoder for each of the tracks (filters menu lists a decoder for each of the track), is this normal? isnt it trying to decode them all simultaneously?
Only the selected track is decoded, nothing else.

[QQ]

why are multiple instances of decoder loaded then? (just trying to understand the mechanism..)

[fastplayer]

why are multiple instances of decoder loaded then? (just trying to understand the mechanism..)
AFAIK, this only happens with the worthless internal splitters. Please use Haali or LAV.

[moonrak]

Hi,
xvidvideo.ru is hosting again MPC-HC.
Is this permanent?
moonrak

[boyumeow]

Just treat it as one place where U can get beta of mpc-hc.
Likewise, U can get from XhmikosR http://xhmikosr.1f0.de/
Later, it might be from googlecode https://code.google.com/p/mpc-hc/
Thanks.

[QQ]

AFAIK, this only happens with the worthless internal splitters. Please use Haali or LAV.

I see.

Does the rule apply to all the internal filters?

[fastplayer]

I see.

Does the rule apply to all the internal filters?
It's not a rule but my personal preference. For formats that matter to me the most like MKV, MOV/MP4, I use Haali/LAV. Saying that the internal filters are "worthless" was a bit too harsh but if you follow the discussions in various threads on this forum, you'll notice that other people prefer the alternatives, too.

[QQ]

Understood.

I'm a bit OCD when it comes to understanding what I use.. If I use haali, then "Audio" right click menu does not allow me to choose audio track, but menu on Navigate does. Why is this functionality duplicated in mpc-hc? :|