Log in

View Full Version : Media Player Classic Home Cinema (MPC-HC) - DXVA!


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 [318] 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410

mariner
20th January 2011, 02:05
Do you want to try the latest svn builds see it's fixed for you? Since xvidvideo.ru & XhmikosR didn't build it for now, I've uploaded the vanilla r2870 builds here, x86/x64 both included, only .exe.

http://www.mediafire.com/?xx5wdpt9k393tzb

MSVS2010 SP1Beta + Cross-mingw GCC 4.5.2 stable from xvidvideo.ru

I will answer also if I may, waiting for mariner: no, nothing changed with this build, still a nice black screen for all videos.

Compared to Casshern's summary, diffs are I'm using MPC-HC x64 and ATI 4780.

Nothing that can be set in Renderer Settings menu has any effect. Only solution is not using EVR Custom Pres. Other renderers are working (EVR, VMR-9, Haali etc...)

Greetings sansnom05. Thanks for the new build. Same result as draden's.

mariner
20th January 2011, 02:27
@everyone with the black screen in EVR-CP problems:

* Please only test with Catalyst 10.12, we know it doesnt work in older versions because ati fixed a bug with mixing that makes all the changes we added possible in 10.12 (older versions before ati regressed might work too, not sure how far back one would need to go)
...

I strongly disagree. Users should not be forced to update their drivers to fix a problem that did not occur before. That is a very bad attitude to take as a project leader. Many people don't even know what a driver is, let alone how to update one. MPC should at least provide a workaround option to get the old behavior, which might be wrong but at least works.

(talking about the black picture regression here)

Mercury_22,
in the latest Catalyst versions (since 10.8 if I remember correctly) there is a bug with many cards that Full RGB is not working over HDMI - it's the same as Limited RGB.
If your card is affected you can try using the DVI output

clsid has a point here. New cat version introduces "features" such as those reported by pankov that may not be so desirable.

mindbomb
20th January 2011, 04:26
What about ReClock (or other) with 24-bit and 32-bit output?

with reclock i have to use the 24 bit padded to 32 bit option

with the foobar plugin, the 24 bit output option works fine.

terminaldawn
20th January 2011, 05:18
I am going to be rebuilding my HTPC, is there anyway I can backup all of my MPC-HC settings (especially the key mappings)?

Thanks!

namaiki
20th January 2011, 05:25
Open regedit and export [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic], and/or in MPC-HC, View> Options, Tick Store settings to .ini file, close MPC-HC and copy out the MPC-HC.ini file generally located in the same directory as MPC-HC.exe is located.

terminaldawn
20th January 2011, 05:35
Open regedit and export [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic], and/or in MPC-HC, View> Options, Tick Store settings to .ini file, close MPC-HC and copy out the MPC-HC.ini file generally located in the same directory as MPC-HC.exe is located.

THANKYOU!!!

I am on win 7 and tried the store settings to INI before asking here, and an ini file was never created. I even tried launching MPC in Admin mode. ??? o Well

Anyways... Will I have any issues exporting these settings and then importing them to my PC after I re-install Win 7 and codecs?

--Thanks!!

namaiki
20th January 2011, 05:43
The MPC-HC.ini file might have have appeared in a sub-folder of :
C:\Users\<user; e.g. namaiki>\AppData
or
C:\ProgramData

It should be fine if you are installing the same or similar build of MPC-HC and other codecs.

JanWillem32
20th January 2011, 05:49
@mariner: http://www.mediafire.com/?e6ix43wpyndo8sm ATi CCC is indeed a bit limited by default, but you can expose quite a few functions. The download is a profile to use with DXVAchecker. I'm still trying to tweak all functions, but I can most certainly use 10-bit full-range RGB and audio over HDMI. This download is also quite useful for anyone else that wants to expose some extra features. I do have to use the "Use Extended Display Identification Data (EDID)" setting in the "Monitor Properties" tab, else I get discoloration.

@terminaldawn: Run regedit, navigate to the key "HKEY_CURRENT_USER\Software\Gabest\", right click the key and choose export. You can also make .REG profiles with individual settings with this method. The .REG files contain text that can easily be edited with notepad.

Last, but not least: I might help out a bit with the design for the main website, but styling is of course quite difficult. Is this tasteful enough for the main website after cropping and switching the background?
http://www.mediafire.com/?49ms0ysvq1a8cgu
(For the technical part: the pictures were downsized to 50% with bicubic a=1.00.)

MokrySedeS
20th January 2011, 10:47
When playing "very wide" movies, encoded in 16:9 with black bars, played back on a 16:10 monitor, the encoded black bars are gray compared to the ones further out. Yes, I'm using the correct levels, the wrong levels look even worse. I'm using EVR-CP.
When switching to madVR with the exact same decoding settings, the black bars are completely black.

What can I do to fix this?
Win 7 x64, HD4850.

Disable dynamic contrast in CCC --> Video --> All Settings.
Disabling other "features" like edge-enhancment or de-noising is probably a good idea too.

cca
20th January 2011, 14:14
Disable dynamic contrast in CCC --> Video --> All Settings.
Disabling other "features" like edge-enhancment or de-noising is probably a good idea too.

Dynamic contrast is evil :devil: One of the first things I disable when I do fresh driver installs are the above mentioned options, they do more harm than good.

tetsuo55
20th January 2011, 16:20
Another update on the black-video-with-EVR-CP.

Details on the changes:

* JanWillems patches removed some restrictions from the mixer, that made all input colorspaces possible.

* It is clear that the mixer is incapable of handling some formats, so the patches where updated to only allow those that EVR-CP understands (but still many more than before the first patch)

* We then found out that ATI catalyst drivers between 10.6 and 10.11 not only broke 10bit but also mixing of almost all colorspaces. (this is why some people are still seeing black video)

Using any driver on ATI older than 10.6 or newer than 10.11 will fix any black screen video issues.

Now on to the why:
These changes give us the room required to reduce the rounding errors on filters applied and gives us a good way to implement better chroma upscaling, etc....

clsid
20th January 2011, 18:09
Since it is known which range of drivers have the problem, could we disable the 'broken' 10bit functionality for those drivers, and also restrict the mixer to formats that work for those drivers?

The driver version can easily be detected and used to conditionally do things. See for example the DXVA compatibility check code.

This way the black screen bug will be fixed for users with old drivers, and users with new drivers will get the full functionality of the current code.

I would like to emphasize the fact that we can't expect users to update their drivers. They are generally n00bs and MPC should simply be made as idiot-proof as possible. Certainly in cases like this where MPC suddenly stops working properly from one version to another.

SamuriHL
20th January 2011, 18:28
I'm in favor of that approach, as well, clsid. That shouldn't be a ridiculously hard thing to implement, either, and should be fairly easy to maintain I would think.

Mercury_22
20th January 2011, 18:46
@ aleksoid
Revision 2874 -2875 make MPC-HC crash when trying to play any Interlaced m2ts file !

Revision 2875 - Directory Listing
Modified Thu Jan 20 13:06:51 2011 UTC (4 hours, 34 minutes ago) by aleksoid

Fix : rev. 2857, language ordering for select Subtitle stream incorrect sometimes;

Revision 2874 - Directory Listing
Modified Thu Jan 20 11:00:54 2011 UTC (6 hours, 40 minutes ago) by aleksoid

Change : rewrite code for rev. 2867;



P.S. Also the black screen when using internal H264 decoder it's still there ! When using an external decoder e.g. M$ DTV-DVD Video Decoder there's no more black screen for the same file with the same settings

Polcius
20th January 2011, 19:49
Weird stuff...

My problem was because of my new Nvidia card, a Gt 430. I put back my old card (ATI HD4350) and the mkv's work flawlessly; no signs of the problem.

I'm lost. I don't think the Nvidia is faulty, since DVDs and avis worked nice.

WTF

namaiki
20th January 2011, 19:52
Which nVidia drivers? (mostly just curious since I can't really do any testing)

Aleksoid1978
20th January 2011, 22:46
@ aleksoid
Revision 2874 -2875 make MPC-HC crash when trying to play any Interlaced m2ts file !

Fix - rev. 2877

janos666
20th January 2011, 23:22
The only reason why I don't convert back with the video gamma function is the ghastly bad black values it produces,
usually including banding.


I never advised to do that! Moreover, I suggested to completely forget about the Rec709 encode curve. You should never use that for any purposes (unless you work with your own RAW material). You should take it as it never existed.

You should work with pure-power curves instead. You can pick up an exponent between 2.2 and 2.4 (may be 2.35 is a good choice for general usage).

But you should use the same curve for both the "original, gamma wighted RGB -> linear RGB for processing" and "processed linear RGB -> gamma weighted RGB for presentation or optional later processing".


With the use of the Rec709 encode curve, you try to restore the original, linear data before the Rec709 encoding. But this is 1: impossible without errors (heavy noise and banding) ; 2: bad idea because the encoding was done like this for good reasons (to hide the noise and fit the data for the assumed "perfect end-user display and view environment"). If you apply the post-processing on this false linear data, you can exaggerate the problems. (You try to de-noise and de-band the heavily noisy and banded false data and re-encode it with the noise-hider curve again which produces banding again. Shh.... :confused:)

With the use of different curves for the two steps you change the relative contrast of the source material.
It can work if you know the exact TRC of your display. But it produces false results with the lcms processing (unless you also change the source profile for lcms).


Calibrated CRT and 3LCD projector, both the same result. I will calibrate from 2.2 to 2.6 gamma, depending on what I'm working on.


That's good. I currently restored my old settings: I calibrated my display to gamma 2.35 and D65 white with ArgyllCMS/dispcal and I do the gamut conversion with yCMS (without any other software corrections).
I still like the effectively 10-bit VGA LUT correction better than the currently useless 10-bit output with MPC-HC (ok, it's 10-bit output, but effectively comes from slightly damaged 8-bit...).
And I also prefer the ArgyllCMS/dispcal result instead of yCMS's white balance correction through the dithered 8-bit output of madVR. (It's strange and causes too much noise for me.)

***But I also learned that the absolute colorimetric intent corrects the white POINT only. It doesn't take care about the fluctuating gray axis. So a 1D VGA LUT calibration is inevitable with ICC color correction methods. But my goal was to use the 10-bit output to make every necessary corrections at one step and in one place. But it simply can't be done with lcms. (May be with yCMS if it evolves and madVR will support 10-bit output. But until then... the VGA LUT works with 10-bit already and yCMS doed a great job with gamut correction on a calibrated display...)


I know that many videos don't actually use the specified gamma transfer function to begin with, but it's the best assumption I can make when processing DVD and blu-ray media.


It's not a bug, it's a feature! :rolleyes:
You don't have to believe me, but I already explained it here: The original data is encoded with the Rec709 encode curve but it's intended to be decoded with a pure-power curve. That's how it works (hides the noise and corrects the view environment differences between the studio and home atmosphere...).


I do switch the output gamma setting of the final pass color management a lot. The color management uses a single-power gamma function of 2.2, 2.35 or 2.4 to build the LUT, it doesn't receive a gamma transfer function.


Ok. You can do what feels good for you. But the end-users can't do that and you showed an example when you used lcms too, after the mid-processing gamma transformation was involved. It is very misleading... (And you didn't even explained it. I only guessed that you know what you are doing. -> Even if you do erroneous things intentionally. But that's your business... may be I am wrong with the pure-power curve theory and you are right here. There is no official standard for this. :mad:)


But I still don't understand...
Why does it feel better for you to apply a gamma transformation somewhere at the middle of the processing chain if you use lcms too?
Why don't you let the original TRC untouched and do the processing at the final step with lcms? :rolleyes:
It's easier, more error-free to explain for end-users and probably works better. I simply can't see the point in this to involve the Wide Gamut RGB TRC in the middle of the processing when you don't even have a display with that color space. It made no sense for me... :stupid:

-> But OK, I can see now... You didn't use the same function because you resisted to use the Rec709 encode curve which caused errors.
Why don't you try to use the same pure-power curve before "wild" things ("developed" as a "workaround" for the self-made, otherwise non-existing problems) like this?


/// Sorry, I wrote a lot so I didn't check for grammar errors. (I am Hungarian...)

Mercury_22
20th January 2011, 23:56
Fix - rev. 2877
No more crash but VC-1 i it's starting very slow (after ~ 10sec) and the playback it's very very "choppy"/slow/broken (Tested with WMVideo Decoder DMO & Nero since internal can't play VC-1 i )


Also since Revision 2876 - Directory Listing
Modified Thu Jan 20 20:55:33 2011 UTC (102 minutes, 41 seconds ago) by sansnom05

updated SoundTouch to svn 103 can't compile the x64 version
3>c:\mpc-hc\src\filters\renderer\mpcaudiorenderer\soundtouch\include\STTypes.h(90): fatal error C1017: invalid integer constant expression

EDIT:The x64 compilation have been fixed in Revision 2879 - Directory Listing
Modified Thu Jan 20 22:38:17 2011 UTC (22 minutes, 40 seconds ago) by XhmikosR

follow up to r2876 Thanks XhmikosR

Mixer73
21st January 2011, 00:22
Since it is known which range of drivers have the problem, could we disable the 'broken' 10bit functionality for those drivers, and also restrict the mixer to formats that work for those drivers?

On the flip side if everybody keeps catering for their ridiculously broken drivers, AMD will never pull their finger out and fix anything, or establish a QA program that can put out drivers where more than 50% of stuff works.

I'd be quite happy to see stuff not work and for AMD to cop the slating they deserve for the state of their drivers with regard to media playback. Maybe then they will wake up to themselves.

janos666
21st January 2011, 01:06
@clsid

I think it is the manufacturer's responsibility to provide bug-free drivers. (And this is a more solid statement with proprietary drivers and "secret" source codes.)

If an old driver causes problems with a software, the user may want to find the problem and eventually update the driver and learn how to deal with basic problems or ask for "professional"* help (*anybody who knows what should be done...).
If you automatically restrict those functions then she/he may think that it's simply an unsupported feature on her/his PC and yes, as Mixer73 told: the driver bug may never be fixed and/or the feature will never be used by more than a few people.
If you also give instructions to the user about a necessary driver update... well... Why don't you become her/his personal janitor for free? If she/he isn't experienced with these things, she/he can cause serious troubles and fear about drivers for a life. :)

Polcius
21st January 2011, 01:31
Which nVidia drivers? (mostly just curious since I can't really do any testing)

260 and 266 (the two last ones).

BTW, who said that altering the Contrast, Brightness and Saturation values in ATI CCC video tab would worsen the video quality?

I don't understand why.

clsid
21st January 2011, 02:23
On the flip side if everybody keeps catering for their ridiculously broken drivers, AMD will never pull their finger out and fix anything, or establish a QA program that can put out drivers where more than 50% of stuff works.

I'd be quite happy to see stuff not work and for AMD to cop the slating they deserve for the state of their drivers with regard to media playback. Maybe then they will wake up to themselves.
@clsid

I think it is the manufacturer's responsibility to provide bug-free drivers. (And this is a more solid statement with proprietary drivers and "secret" source codes.)

If an old driver causes problems with a software, the user may want to find the problem and eventually update the driver and learn how to deal with basic problems or ask for "professional"* help (*anybody who knows what should be done...).
If you automatically restrict those functions then she/he may think that it's simply an unsupported feature on her/his PC and yes, as Mixer73 told: the driver bug may never be fixed and/or the feature will never be used by more than a few people.
If you also give instructions to the user about a necessary driver update... well... Why don't you become her/his personal janitor for free? If she/he isn't experienced with these things, she/he can cause serious troubles and fear about drivers for a life. :)
These are very narrow minded opinions and just shows how little most people care about the usability of MPC unless it directly affects themselves.

Of course it is the task of the hardware makers to provide proper drivers, but in reality things just don't work that way.

You guys didn't even know the previous driver version were buggy until things got broken in MPC and the issue was discussed here. Exactly because it used the work fine, people will tend to blame MPC for the problem. A driver is not even considered a possible cause because they didn't change that.

The black screen issue is a regression and can easily be fixed with the proposed workaround. Anyone who things that this is a bad idea is just an egoistic moron.

Disabling functionality that was already broken to begin with is absolutely no problem at all. Certainly not since it is something that the average user does not use or even knows about.

Sigh.

janos666
21st January 2011, 02:26
260 and 266 (the two last ones).

BTW, who said that altering the Contrast, Brightness and Saturation values in ATI CCC video tab would worsen the video quality?

I don't understand why.

1: Because it's digital processing where the final output bit depth is often equal with the bit depth of the source (8 bit/color = 256 possible values per channels), so without tricks like dithering (which has other drawbacks: the dithering noise) every processing happens for a cost of lost image information (it causes artifacts like banding or miss-colorization).

2: If you don't have a colorimeter/spectrophotometer or at least a reference display to compare the results, you can't be sure if it makes the things better or worse. (The "feels better" can be misleading and you can adapt to bad settings. And may be you will find the proper things faulty when you change your hardwares or drivers, etc).
And usual displays usually requires non-linear corrections in white balance and gamma, so these "almost linear" corrections (not perfectly linear because they works with errors...) can't help too much. (May be a little with the overall result.)
A simple "Saturation" control is another bad idea because you can't really achieve more saturated colors (wider gamut which requires a wider light spectrum) and usual display usually has differently saturated primaries. For example, Red is very over-saturated (most disturbing with human skin tones) but blue is slightly under-saturated. What do you achieve with the Saturation slider? Very under-saturated blue and may be better red. But don't forget that there is a green too. -> This can be handled by real color management solutions very well.


@clsid
I didn't said it's a bad idea to make workarounds. I only listed some arguments why it can be treated like that.
I think it's actually good to have workarounds from any sides for every possible problems. But I think it should be handled with low priority. (If somebody doesn't have any better things to do, because it's basically redundant.)
The driver update is a workaround too because every driver should be perfect and usable (you should be able to live with the one on the CD). :)

And just ro the record: When I saw black screen first with the 10-bit option I went to the AMD forum first where a stupid moderator closed my topic after some hours. And we had some arguments about the capabilities of my hardwares later. He resisted that I am a poor stupid idiot (he didn't bother himself to take a single looks at Dell's hardware specifications which I linked: "No, you can't have a 10-bit display. Those are very expensive, you idiot! Can't you understand?"). And other funny thing was that people (on a different forum where he can't ban me) believed in his words. :D
He refused to answer me again after these bugs got fixed. What a strange accident. :D

mindbomb
21st January 2011, 02:47
Does bicubic -1.00 is the best resizer for high quality?

this brings up a good question, what the heck does the a value refer to in the bicubic resizing choices?

Popular opinion appears to be that the more negative it is, the sharper the image, but idk if that is right.

I wish mpc hc had a little description of each choice, ala ffdshow or madvr

namaiki
21st January 2011, 03:27
this brings up a good question, what the heck does the a value refer to in the bicubic resizing choices?

Popular opinion appears to be that the more negative it is, the sharper the image, but idk if that is right.

From what I can see, closer to zero than -0.60 and there is aliasing, higher than that, depending on how much you are resizing the video, and there is also a bit of aliasing, but only on edges.

As far as I can tell, it's the same value used in Haali's Renderer.

Aleksoid1978
21st January 2011, 03:33
No more crash but VC-1 i it's starting very slow (after ~ 10sec) and the playback it's very very "choppy"/slow/broken (Tested with WMVideo Decoder DMO & Nero since internal can't play VC-1 i )

upload a sample.
I test on .m2ts/.ts + H264 and .m2ts + VC-1 - all play fine.
But i use Cyberlink PDVD10 Video Decoder for VC-1 playback.

mindbomb
21st January 2011, 04:05
No more crash but VC-1 i it's starting very slow (after ~ 10sec) and the playback it's very very "choppy"/slow/broken (Tested with WMVideo Decoder DMO & Nero since internal can't play VC-1 i )

are you trying with frame time correction on?

tetsuo55
21st January 2011, 09:45
These are very narrow minded opinions and just shows how little most people care about the usability of MPC unless it directly affects themselves.

Of course it is the task of the hardware makers to provide proper drivers, but in reality things just don't work that way.

You guys didn't even know the previous driver version were buggy until things got broken in MPC and the issue was discussed here. Exactly because it used the work fine, people will tend to blame MPC for the problem. A driver is not even considered a possible cause because they didn't change that.

The black screen issue is a regression and can easily be fixed with the proposed workaround. Anyone who things that this is a bad idea is just an egoistic moron.

Disabling functionality that was already broken to begin with is absolutely no problem at all. Certainly not since it is something that the average user does not use or even knows about.

Sigh.
Although i agree that we should not support broken driver revisions your idea to use a detection system like we use with DXVA is a good one.

I don't think i've explained clear enough what the black-video bug is exactly

Why did it work before?: A combination of bugs, that negatively affect video quality tricked the renderer into using a different surface, thus not revealing the black-video bug when cat 10.6 came out.

Why can't we simply use the old code: Once the combination of bugs was fixed the "trick" no longer works and the renderer always takes the surface with the highest quality.

What now?: JanWillem is experimenting to see if we can force the renderer into that "trick" mode when the drivers between 1.6 and 10.11 are detected. So far though, when it works image quality is even worse than before.

So with the version of the code image quality is starting to near perfection
With the old code image quality was so-so
With the old-emulation code image quality is just plain bad

But i guess its better than a black screen?

WonderCsabo
21st January 2011, 09:54
Guys, i have a noob question: can MPC-HC decode the lossless TrueHD, or just the lossy embedded AC3 stream?

nevcairiel
21st January 2011, 10:05
It can decode TrueHD.

Edit:
To clear up some misconceptions: TrueHD does not contain a "core" AC3 itself, not like DTS-HD contains a core DTS track. However on BluRays, TrueHD tracks are muxed in a way that includes an AC3 track for players not capable of TrueHD - but only there, its not a format thing like it is with DTS.

WonderCsabo
21st January 2011, 11:14
I know that, that's why i called it "embedded stream". But for now, i only found TrueHD tracks which contain embedded AC3 within. Thanks!

How can i be sure that MPC-HC decodes the lossless MLP stream instead of the embedded AC3?

Mercury_22
21st January 2011, 11:50
upload a sample.
I test on .m2ts/.ts + H264 and .m2ts + VC-1 - all play fine.
But i use Cyberlink PDVD10 Video Decoder for VC-1 playback.
Here is the sample (http://sharebee.com/b4d0ac0f) Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : AP@L3
Codec ID : 234
Duration : 1mn 42s
Bit rate : 20.6 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.398


are you trying with frame time correction on?
Tested with both off and on ! but you should know that FTC it's useful only when using WMVideo Decoder DMO

SamuriHL
21st January 2011, 14:43
How can i be sure that MPC-HC decodes the lossless MLP stream instead of the embedded AC3?

Find one that's 7.1. :)

Polcius
21st January 2011, 14:50
1: Because it's digital processing where the final output bit depth is often equal with the bit depth of the source (8 bit/color = 256 possible values per channels), so without tricks like dithering (which has other drawbacks: the dithering noise) every processing happens for a cost of lost image information (it causes artifacts like banding or miss-colorization).

2: If you don't have a colorimeter/spectrophotometer or at least a reference display to compare the results, you can't be sure if it makes the things better or worse. (The "feels better" can be misleading and you can adapt to bad settings. And may be you will find the proper things faulty when you change your hardwares or drivers, etc).
And usual displays usually requires non-linear corrections in white balance and gamma, so these "almost linear" corrections (not perfectly linear because they works with errors...) can't help too much. (May be a little with the overall result.)
A simple "Saturation" control is another bad idea because you can't really achieve more saturated colors (wider gamut which requires a wider light spectrum) and usual display usually has differently saturated primaries. For example, Red is very over-saturated (most disturbing with human skin tones) but blue is slightly under-saturated. What do you achieve with the Saturation slider? Very under-saturated blue and may be better red. But don't forget that there is a green too. -> This can be handled by real color management solutions very well.



Ok. But, for example, let's assume that I don't have a colorimeter. The only thing I have is the DVE Pro Calibration DVDs. These contain a blue filter to adjust saturation. The problem is that when I connect my PC to my TV the "Color" (saturation) control is greyed out. What I could do, and did before, is adjust the saturation slider in the ATI CCC, to a position where the saturation test in DVE was correct.

This is bad? From what you're saying, adjustments in the ATI CCC will mess up things. Right?

janos666
21st January 2011, 15:36
This is bad? From what you're saying, adjustments in the ATI CCC will mess up things. Right?

Not for sure but most likely yes.

Ask somebody with a proper instrument (wide gamut displays most likely require spectrophotometers instead of colorimeters with Lab filters!) to measure some color patches on your display (primary colors + at least 10 grays at different levels ; or much more, it's up to you...) in CIE XYZ format and:
- Use ArgyllCMS/colprof to generate an ICC profile to use it with MPC-HC's EVR-CP
- Use yCMS to generate a 3DLUT for madVR. (-> my current recommendation)

Polcius
21st January 2011, 15:48
Not for sure but most likely yes.

Ask somebody with a proper instrument (wide gamut displays most likely require spectrophotometers instead of colorimeters with Lab filters!) to measure some color patches on your display (primary colors + at least 10 grays at different levels ; or much more, it's up to you...) in CIE XYZ format and:
- Use ArgyllCMS/colprof to generate an ICC profile to use it with MPC-HC's EVR-CP
- Use yCMS to generate a 3DLUT for madVR. (-> my current recommendation)

Ok, since I have access to a spectrophotometer I will try this.

But last I checked, madVR didn't support subtitles or DVD menus, and I need those features.

janos666
21st January 2011, 16:11
But last I checked, madVR didn't support subtitles or DVD menus, and I need those features.

Choose the first alternative then.
If you plan to create an ICC profile then I suggest you to use DispcalGUI (http://hoech.net/dispcalGUI/) for ArgyllCMS (http://www.argyllcms.com/).
DispcalGUI comes with some preset test charts but it also has a nice GUI which helps you to set up any custom test charts for your taste.

Since none of the ICC methods take care about the white balance, you should run the calibration too (calibrate and profile). Choose the Adaptive HiRes mode and High quality settings if you have time (slower than HiRes but better for displays with relatively high contrast ratio ; same for the quality settings: takes more time but probably produce better results).

And don't forget to enable CMS in MPC-HC after you disabled those CCC "features". :)

Mercury_22
21st January 2011, 16:22
I think I have a better solution for Revision 2866 - Directory Listing
Modified Wed Jan 19 04:56:35 2011 UTC (2 days, 10 hours ago) by sansnom05

-changed: single click will pause/resume playback for compact mode(in fact, any mode with any bars visible)
-fixed simplified chinese resource file errors in r2865


Just comment line 2774 and 2776 //if(!m_fFullScreen && (IsCaptionMenuHidden() || fLeftMouseBtnUnassigned))
{
PostMessage(WM_NCLBUTTONDOWN, HTCAPTION, MAKELPARAM(point.x, point.y));
} //else
and this way we can keep left click drag and gain the left down Play / Pause function in compact mode !
With the current fix we are losing left click drag

Polcius
21st January 2011, 17:12
Choose the first alternative then.
If you plan to create an ICC profile then I suggest you to use DispcalGUI (http://hoech.net/dispcalGUI/) for ArgyllCMS (http://www.argyllcms.com/).
DispcalGUI comes with some preset test charts but it also has a nice GUI which helps you to set up any custom test charts for your taste.

Since none of the ICC methods take care about the white balance, you should run the calibration too (calibrate and profile). Choose the Adaptive HiRes mode and High quality settings if you have time (slower than HiRes but better for displays with relatively high contrast ratio ; same for the quality settings: takes more time but probably produce better results).

And don't forget to enable CMS in MPC-HC after you disabled those CCC "features". :)

Ok, I will try it ASAP, thanks!

cyberbeing
21st January 2011, 20:40
Since none of the ICC methods take care about the white balance, you should run the calibration too (calibrate and profile). Choose the Adaptive HiRes mode and High quality settings if you have time (slower than HiRes but better for displays with relatively high contrast ratio ; same for the quality settings: takes more time but probably produce better results).


I'll just throw out there that the HiRes and Adaptive HiRes settings are specific to the EyeOne Pro (and possibly ColorMunki?).

In general, the Adaptive HiRes setting usually results in more consistent measurements of low luminance near-black patches (for example below the EyeOne Pro rated spec of 0.20 cd/m2). If you have a display with a very low black point or in particular a CRT, it can be useful when calibrating. Just keep in mind that it is a bit of a hack that was originally intended for reflective (printer) measurements, not emisive (display) measurements. It was only enabled in dispcal by request, and can be viewed as an experimental feature, not suited for general-use.

DO NOT use Adaptive HiRes when profiling the display. While using Adaptive mode can be useful for calibrating your Gfx Video LUT, it is unsuited for ICC profile generation. Because of its 'adaptive' integration time it will likely produce measurements which skew the relationship between colored patches and in-turn result in a lower-quality ICC profile. Using HiRes without Adaptive is the recommended way to profile your display with Argyll. Of course, nothing is stopping you from experimenting with Adaptive mode, and what really matters is if you are happy with the resulting ICC profile or not.

mindbomb
21st January 2011, 20:41
Tested with both off and on ! but you should know that FTC it's useful only when using WMVideo Decoder DMO

I actually found that it benefits the cyberlink decoder as well, with vc-1 in an mkv container.


From what I can see, closer to zero than -0.60 and there is aliasing, higher than that, depending on how much you are resizing the video, and there is also a bit of aliasing, but only on edges.

As far as I can tell, it's the same value used in Haali's Renderer.

I did a little digging, I found out the same resizing options were in virtualdub. Apparently the creator of virtualdub thought bicubic A=-0.75 was the best because bicubic A=-1.00 oversharpened, and he ended up making it the default value. So, I'm actually gonna go with bicubic A=-0.75 from now on.

Polcius
21st January 2011, 20:57
I'll just throw out there that the HiRes and Adaptive HiRes settings are specific to the EyeOne Pro (and possibly ColorMunki?).

In general, the Adaptive HiRes setting usually results in more consistent measurements of low luminance near-black patches (for example below the EyeOne Pro rated spec of 0.20 cd/m2). If you have a display with a very low black point or in particular a CRT, it can be useful when calibrating. Just keep in mind that it is a bit of a hack that was originally intended for reflective (printer) measurements, not emisive (display) measurements. It was only enabled in dispcal by request, and can be viewed as an experimental feature, not suited for general-use.

DO NOT use Adaptive HiRes when profiling the display. While using Adaptive mode can be useful for calibrating your Gfx Video LUT, it is unsuited for ICC profile generation. Because of its 'adaptive' integration time it will likely produce measurements which skew the relationship between colored patches and in-turn result in a lower-quality ICC profile. Using HiRes without Adaptive is the recommended way to profile your display with Argyll. Of course, nothing is stopping you from experimenting with Adaptive mode, and what really matters is if you are happy with the resulting ICC profile or not.

Ok.

What general settings should I use?

I selected "Video" in the upmost tab; and in profiling it says "single curve + matrix".

cyberbeing
21st January 2011, 21:31
Chromaticity Coordinates: 0.312713x 0.329016y
White Level: Native
Black Level: Native

Tone Curve Option #1: Gamma 2.222222 Relative
OR
Tone Curve Option #2: Rec.709 + Ambient Light Level Measurements
(If your unable to measure Ambient, take an educated guess. 0-32 lux is considered a dim/darkened room, 32-64 lux is an average room, 64-128 lux is a bright room, 200-700 lux is your standard electronics store showroom lol)
(2.222222 Gamma is more general-purpose, while the Rec.709 curve is the same which HD Video is encoded with)

Black Point Output Offset: 100%
Black Point Correction: Default is 0% for LCD and 100% for CRT. This setting could raise your black level in order to correct the color temperature. Set to your personal preference.

Calibration Quality: High

First do the above with Calibrate Only. When finished your display will have a calibrated gfx video lut.

In dispcalGUI go to Tools -> Verify Calibration to make sure the post-calibration DeltaE readings are acceptable. (DeltaE <1 is good, 1-2 is so-so, 2-3 is bad, >3 is unacceptable)

__________

Now it's time to make some ICC profiles with Profile Quality: High.

For a basic matrix profile use Curves + Matrix with the Large Testchart for Curves + Matrix.

For a higher quality LUT profile use XYZ LUT + Matrix with the Large Testchart for LUT.

After creating a profile in dispcalGUI and installing it, go to Tools -> Verify Profile (use the Extended Verify ti1) in order to make sure the ICC profile color corrections are producing acceptable DeltaE readings. (DeltaE <1 is good, 1-2 is so-so, 2-3 is bad, >3 is unacceptable)
__________

If you want to save time and make multiple profiles, just go directly with XYZ LUT + Matrix and the Large Testchart for LUT with Calibrate and Profile, and then afterwords use Options -> 'Create Profile from Measurments Data' to make a Curves + Matrix and L*A*B* LUT ICC profile as well with your single ti3 file.

Polcius
21st January 2011, 22:19
Ok, thanks!

So, once finish it says to "install the profile". I did it. Do I need to change/check any additional Windows' settings?

janos666
21st January 2011, 23:20
@cyberbeing

This is not the best place to discuss this and I don't even want to argue with that. But,
1: he already mentioned that he will use a spectrophotometer
2: The only supported spectrophotometers with displays measurement capabilities are i1Pro and CM and they both support the Adaptive HiRes mode.
3: Both the i1Pro and CM (in normal mode) are uncertain under 0.2 cd/m^2 while many LCD TVs have significantly lower black (not to mention high-end plasma TVs but a c-PVA is more than enough).
According to my experiences, you need to use the Adaptive mode for any displays with a contrast ratio of ~800:1 or higher, or the black point will be lifted and the near-black scale won't be smooth.
And another good advise is to use the same instrument settings for calibration and profiling because the profile-aware software will try to compensate for the measured display, so the final result mostly depends on the profile and a different calibration is only another error factor.

Polcius
22nd January 2011, 00:12
Well, my TV is not that good and I don't need perfect accuracy: I'm just an enthusiast who loves movies and wants to see them as good as possible... so I don't think it matters that much, I did it in HiRes mode.

I attached the verifications. I think its acceptable.

Now, how can I be sure that the ICC profile is installed and active?
Do I have to change something in the windows color management section?

Thanks to all for your help, these color management solutions are tricky.

cyberbeing
22nd January 2011, 03:08
the black point will be lifted and the near-black scale won't be smooth.
We seem to be basically on the same page. I'll just mention that behavior such as the above are caused by a low black level, not contrast ratio. Even though the two are interrelated, you can't blindly assume every high contrast display has a low black level.

And another good advise is to use the same instrument settings for calibration and profiling because the profile-aware software will try to compensate for the measured display, so the final result mostly depends on the profile and a different calibration is only another error factor.
This is generally true, but it gets a bit tricky since Adaptive mode isn't well suited for profiling, and is an error factor just by itself. Getting creative and combining Adaptive with non-Adaptive measurements for profile generation may result in the smallest error. Maybe something like:

Adaptive: White Point, Black Point, Grayscale
Non-Adaptive: Color Patches

I do agree this isn't a discussion to really take up in this thread. Someplace like the Argyll CMS mailing list would be better suited. I'm sure dev Graeme Gill has some opinions on the matter, as he is the one who originally frowned upon the idea of using of Adaptive mode for profiling.

Now, how can I be sure that the ICC profile is installed and active?
Do I have to change something in the windows color management section?
As far as I know, dispcalGUI installs profiles correctly in Windows Color Management so you shouldn't need to do anything further.

An easy test would be downloading this (http://www.xrite.com/product_overview.aspx?ID=757&Action=support&SoftwareID=546) to check that your calibrated lut is being loaded when you reboot your PC.

janos666
22nd January 2011, 04:04
Now, how can I be sure that the ICC profile is installed and active?


Your got the first half of the answer from cyberbeing, now here is the other half:
Don't forget to enable CMS in MPC-HC: Right click on the player windows, renderer settings, color management ->> enable ; and optionally set the desired gamma value (ambient light).

wOxxOm
22nd January 2011, 07:27
#2866 -changed: single click will pause/resume playback for compact mode(in fact, any mode with any bars visible)
Modified Wed Jan 19 04:56:35 2011 UTC (3 days, 1 hour ago) by sansnom05this obscene change should have a configuration option to turn it off!
without easy mouse dragging MPCHC is ****.