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

[mark0077]

mpc is acting stranger and stranger with every new build for the past few weeks for me. With newish builds I can't open a video in mpc while anotehr is playing, mpc either crashes or it just flickers and keeps playing what its already playing. Today I was playing a blu-ray, and decided to go and change my audio renderer to the null audio renderer to test something. I right clicked on mpc in the taskbar to get the recently played list, and picked the same bdmv file. To my amazement I currently have two instances of the same blu-ray playing right now, theres two instances of ffdshow video, two of ffdshow audio.... both playing away in the same evr-cp renderer... :) Looks so strange.

Any ideas whats been happening lately? Its something to do with this arcsoft audio decoder I recently started using for dts-hd. I guess the hack of replacing the two hex values in mpc-hc isn't going to be a robust way going forward? Is there a better way to allow this decoder to work in mpc-hc as the current hack of hex editing allows it to be used but causes me really strange behaviour..

I still would assume mpc-hc should give an error when trying to close down the first playing clip, and not attempt to open further clips if it runs into errors. It seems to just keep on going rebuilding the graph for the second clip, regardless of the fact that the first hasn't shut down.... therefore giving two clips playing in the same window..

[clsid]

The time required to play a file is really irrelevant. Those optimizations don't usually affect the GUI, they affect the processing of the media. And in the player, its always the same speed. You just might have lower CPU usage.
You are right. I forgot to mention that MPC should also adjust the playback rate to decode at max speed. Like Haali's timecodec tool does. If that doesn't b0rk anything though with rendering, otherwise NULL renderers could be used.

[STaRGaZeR]

What are the benefits of SSE2 vs SSE in MPC-HC? I haven't seen any comparisons or tests.

[kieranrk]

What are the benefits of SSE2 vs SSE in MPC-HC? I haven't seen any comparisons or tests.

Placebo if anything.

[skingery]

Primary Video Player: HP Mini 311 (W7, 2GB, Atom N270, ION); 1080p @ 60Hz, 0-255, 10-bit in, CoreAVC, Matroska Splitter
@Hera, You and I have similar systems. Mine is an Atom 330, ION. Really curious what MPC-HC version you are using and what some of the settings are. Are you using EVR Custom Presentation? Are you using 10-bit output too? Any of Jan's custom chroma settings?

Thanks in advance for your help,
Scott

[janos666]

Here is a new custom test build
***Link removed, see new posts...

Changed:
- revised 3DLUT generation algorithm (32-bit floating point texture instead of the old 16-bit float texture which was converted from 16-bit integer input)

Added:
- new CMS controls (Black Point Compensation ; a new Tone Response Curve Type ; White Point Adaptation State and 3DLUT quality presets)

What to test:
- Crash or black screen (only *new black screen*, I didn't try to solve the *old black screen* issues...)
- Subjective opinions if the overall CMS quality improved or not and if you like the new options or not.


Note that some of the new functions only work in combination with other settings (for example: BPC with Relative c. and Percept. only ; WPAdapt with Absolute c. only) and some functions depend on the ICC profile type too.

A little description about the new TRCs: The "Inverse Encode" with "Bright (gamma 2.2)" Ambient setting will do (ot at least try to do...) a fully inverse Rec709 encode. The other two Abbient Light settings use custom guess values as a first attempt to create "scaled inverse rec709 encode" curves.

I think they will never work because they simply should be never used. But here are the chance to test it...

But you should consider that the new "Inverse Encode" curves are not ONLY FOR TESTING but these are only the FIRST GUESS values. I can change them according to the feedbacks as I can add almost any math functions if you give me the formula...

---> Thanks for bobdynlan for creating the new GUI options for me.


And a question:

Would you like to have a "Use Device TRC" option as a new "Ambient Light" setting?

It would be a hard and messy thing to do it (may be more work than all of the above, and it won't be too precise while it would significantly increase the startup time when used...) but I can try if more than one people would experiment with it.

EDIT: The settings will be saved now (patch by bobdynlan).

[tetsuo55]

What are the benefits of SSE2 vs SSE in MPC-HC? I haven't seen any comparisons or tests.Placebo if anything.A noticable/reproducable improvement in GUI responsiveness and seeking time. I suspect a small improvement in the subtitle rendering performance but i cannot confirm that.

It should not have any noticable effects on the codecs as those are already hand optimized.

[Mercury_22]

Since is my understanding that is intended for LAVSplitter (&LavAudio) to replace the current splitters wouldn't be a good idea to create a mpc-hc branch now since LAVFilters 0.14 is stable enough for such testing?
I think it will benefit for both LAVFilters and MPC-HC.

[QQ]

hi,

sorry if these are stupid questions, but I could not find an answer without reading through hundreds of pages..

1. why are Sync options "sync video to display" and "sync display to video" disabled in MPC-HC for me, and sync to vsync checked by default?

2. Why doesn't MPC-HC change resolutions when going to fullscreen mode, even if I setup him to?

[STaRGaZeR]

A noticable/reproducable improvement in GUI responsiveness and seeking time. I suspect a small improvement in the subtitle rendering performance but i cannot confirm that.

It should not have any noticable effects on the codecs as those are already hand optimized.

I don't notice any of those improvements. Can you be more specific? "Feels better" isn't a good argument IMHO.

[Ger]

1. why are Sync options "sync video to display" and "sync display to video" disabled in MPC-HC for me, and sync to vsync checked by default?

These settings are only for the EVR Sync renderer. You need to select EVR Sync in the "Output" page and close any running file. Then the options become available.

[QQ]

These settings are only for the EVR Sync renderer. You need to select EVR Sync in the "Output" page and close any running file. Then the options become available.

Closing file was what I have been missing!

Any idea why MPC-HC won't switch refresh rate for me?

[janos666]

A new CMS tester custom test build: MPC-HC 2922 MSVC2010 x86 (http://www.mediafire.com/?5rndeh4scjnmtzq)

- The new settings will be saved now.
- The Inverse Encode curves are better now (a curve parameter was incorrect) but still very experimental.
- The HQ lookup should work now (SLOW startup ; and may be works only after a restart)

[Dstruct]

A new CMS tester custom test build: MPC-HC 2922 MSVC2010 x86 (http://www.mediafire.com/?5rndeh4scjnmtzq)

- The new settings will be saved now.
- The Inverse Encode curves are better now (a curve parameter was incorrect) but still very experimental.
- The HQ lookup should work now (SLOW startup ; and may be works only after a restart)

Color Management not working at all here (XP SP3, Nvidia 7600GS, VMR-9 renderless). Options in context menu also grayed out on playback.

Final 1.5.0.2827 is working fine.

[janos666]

I didn't try to fix a bug which is already fixed by somebody else. But I used the official SVN files to start with and they aren't fixed yet.

[Dstruct]

Ok .

[mark0077]

Any developers recognize this. first time I saw this problem.

An error popped up in mpc a few mins ago while watching a blu-ray.

"Media Player Classic"
GetDIB failed, hr = 80004005

About 10 minutes later mpc-hc just crashed.

[janos666]

I think this is the last CMS test build for now: MPC-HC 2922 MSVC2010 x86 CMS Test v4 (http://www.mediafire.com/?6d6kdkn553m6m85)

@darkbasic4 -> I think the new BPC option fixes your problem: ticket # 881 (https://sourceforge.net/apps/trac/mpc-hc/ticket/881) You should try it.

@ cyberbeing

The "Inverse Encode" with the "Bright (gamma 2.2)" produces an exact Inverse-Rec709-Encode curve now.
You can try it with different movies and as see how obnoxious it is.
It replaces the detailed dark tones with noisy gray shadows. And it not only destroys the shadow details but the overall contrast feeling is very bad too. Everything is washed out, even the bright scenes looks bad.

You can say that it should be "scaled". But what the hell would be the point in that?

The only significant difference between the studios and homes for this matter is the different ambient light level.

Now, you have your simulated studio display (if you believe that it should have an Inverse-Rec709 response). And it's relatively easy to simulate the studio light conditions at home (more or less) if you wish.
You won't need any scaling in this case and you can see that it's VERY WRONG. And you can believe me that this tone response curve should be never used. (At least on the end-user side.)

///
Just for the record: I already did this test with PhotoShop and madVR+yCMS, so this is the third evidence for me. And it also sounds more logical anyway.

*for everybody*
Otherwise, I am still open for your advices if you think you know the magical parameters for a wonderfully scaled Rec709 curve.

And yes, it's possible to get close to a pure-power ~2.35 curve while you keep a small linear segment but what would be the point in that?
There is no any logical explanation why do you want to do that except that you search for a good subjective result (which would be a pure-power curve) and your stop when you think it's fine enough and you can have the placebo that it's better while it's a little bit worse (but still good).

[Shakey_Jake33]

Don't know if this is a known issue, but there's is a small problem with Blu-Ray subtitles, where it will not display more than one 'subtitle' on-screen at a time. There are some Blu-Rays (in this case, Tsubasa Chronicle) where in certain scenes it displays song lyrics on the top of the screen, and subtitles for the episode itself on the bottom. Right now, it erratically changes between the two, making both somewhat impossible to follow.

[makakam]

I have some other problem with mpc-hc and blu ray subtitles. When I watch a blu ray that consists of a couple of m2ts files subtitles are displayed only until the next chapter. Btw mpc-hc looses chapters when I rewind and ffwd. These issues don't occur when the whole film is in one m2ts file. Is there any fix to this?

[cyberbeing]

The "Inverse Encode" with the "Bright (gamma 2.2)" produces an exact Inverse-Rec709-Encode curve now.
You can try it with different movies and as see how obnoxious it is.
It replaces the detailed dark tones with noisy gray shadows. And it not only destroys the shadow details but the overall contrast feeling is very bad too. Everything is washed out, even the bright scenes looks bad.
Of course it looks bad, it has an average gamma of ~1.94 and a near-black gamma of who knows what, probably 1.4 or something. Are you telling me you expected something different from such low gamma values?

You can say that it should be "scaled". But what the hell would be the point in that?
It looks considerably better with a near-black gamma of ~1.9, an average gamma of ~2.35, and a max gamma of ~2.6.
It does make the image appear more linear, but it looks more natural that way. If you personally like it is just a matter of taste.

Your preference of using a 2.35 gamma power-curve makes the darks and brights more exaggerated and punchy then real life on displays with insanely high contrast ratios. Some people prefer that larger-than-life look, nothing wrong with that.

Yet I'm using a CRT, which has a well behaved natural gamma that these curves were originally designed around, so maybe it wouldn't look as good on LCDs and such.

[janos666]

Are you telling me you expected something different from such low gamma values?
I didn't. I just wanted to show another example why it is completely useless.
It looks considerably better with a near-black gamma of ~1.9, an average gamma of ~2.35, and a max gamma of ~2.
Where does it huge scaling comes from? What standard or any kind of official document describes it?


The encode curve is well defined but hard to scale. Why would somebody standardize a curve which is absolutely useless in it's original form (at least for decoding) but otherwise very hard to scale? Moreover... do it without officially recommending a way how to do this scaling.

Why would a studio mastering engineer calibrate his display to a curve which isn't defined in any existing standards or doesn't even mentioned in any official papers?
-> You won't find any official documents which tells you how to scale this inverse curve. (Or one which even mentions the inverse encode curve...)

The only number you can find in official papers is "1.1". That's why the encode gamma is ~2.2 (1/0.45) and the decode gamma is ~2.4. (would be 1.1/4.5 but 1.1 is only a guess value anyway).
It comes from the differences between the ambient light conditions in studios and usual home environment where you watch your TV.


Does it sound logical or completely insane if every engineer take the standardized Rec709 curve parameters as an initial curve and... let's say... he increases them with his credit card's PIN number, divides them with his own age and multiplies them with the number of his children and ...why not... tune the display TRC manually until it "feels good" for him (absolutely subjectively, because he has no idea how to use the otherwise unusable inverse-encode curve, as there is no any official statement about it...)?

Isn't it more believable if he calibrates with a pure-power curve to match with an "average legacy CRT gamma"?


Let's see so how would I see this problem as an engineer (I am an engineer by the way, but from another kind...) if I were there when this whole TeleVision broadcast thing started:

Problems:
+ The sensor has it's own characteristics which is not the exact inverse of the display characteristics, nor linear. (And, for example, produces noise on dark areas...)
+ There is a difference between the Studio and Home ambient light conditions. (Smaller but existing problem if you really care about the quality.)

Hypothesis:
It would be the best solution if the image manipulation on the end-user side is minimized (zero if possible -> less error factor, cheaper end-user devices -> note that there are much more end-user displays than studio displays...) and the image manipulation in the studios is:
-> exact (described by standards as much as possible)
-> optimized = relatively easy and "cheap" while the final result is fine enough (because we don't want small studios to develop their own "cheaper" ways as their own standards or the less educated and/or lazy engineers to miss something in the jungle... or the manufacturers to use additional custom post-processing anyway to correct the missing parts...)

Let's see an idea:
- Keep both studio displays and end-user displays with their native TRC = ~gamma 2.4 (or as close as possible ... without the defects of the lower quality parts on the end-user side...)
- Construct a single transformation which takes care about every problems at one step (sensor characteristics, different ambient light conditions, etc).


If I were there you could be sure that it would work like this: Sensor data -> Rec709 encode -> display with native CRT TRC. ; No less, no more, but nice and optimal.
-> Except that I would drop the backward compatibility more often. -> No more old [legacy CRT] and [color/gray] or [NTSC] compatibility and many other BS in new HD standards-> Analog SDTVs require additional processing for watching downsampled digital HD streams anyway...)


But, of course, if somebody would give me a huge "reward" if I screw up everything with this standard (Somebody, who could make big money with an electronic part which corrects the mistakes because he would be the first who knows the "tricks" which I placed...) and/or I wouldn't be alone but with stupid co-workers who resist to screw it (because thye are simply stupid). You would never know... That's why I am still open to play with the invers-encode curve. But I can't figure out the magic values alone.
-> Yes, the only problem is that I have zero children, so the above mentioned formula won't work for me. :p:p:p

///
I think I already wrote it down many times but I know that my English is bad, so I tried to say it again (may be it will be understandable this time).


It looks considerably better with a near-black gamma of ~1.9, an average gamma of ~2.35, and a max gamma of ~2.6.
It does make the image appear more linear, but it looks more natural that way. If you personally like it is just a matter of taste.

This kind of reasoning has nothing to do with CMS. This is something like the eye-candy in the AMD drivers (CCC/Video -> A lot a expensively developed BS if you ask me.)

[cyberbeing]

Where does it huge scaling comes from? What standard or any kind of official document describes it?

Argyll CMS uses some form of CIECAM02 (http://en.wikipedia.org/wiki/CIECAM02) for Ambient Light scaling.
CIECAM02 Ambient Light scaling is standardized by the CIE Technical Committee (http://en.wikipedia.org/wiki/International_Commission_on_Illumination). The same which created CIE 1931 XYZ color space and CIE 1976 LAB color space used in all ICC profiles...
It is recommended that all gamma curves and colors should be scaled to ambient light for optimal viewing in a color managed environment.

When Argyll CMS scales REC.709 to ambient light with CIECAM02, then that adjustment is standardized for a color managed workflow. It's really as simple as that.

By specifying or measuring the ambient lighting for your display, a viewing conditions adjustment based on the CIECAM02 color appearance model will be made for the brightness of your display and the contrast it makes with your ambient light levels.

I suggested you ask the Argyll CMS dev since Argyll CMS is open source and has implemented this. He should be able to answer any questions you have. No reason to get so hostile...

[Sina™]

feature request:
color correction.
auto control: noise reduction, sharpness, etc...
shader -> deinterlace -> bob

[vBm]

feature request:
color correction.
auto control: noise reduction, sharpness, etc...
shader -> deinterlace -> bob

Feature requests should be added to TRAC (http://sourceforge.net/apps/trac/mpc-hc/newticket), otherwise they'll end up buried in this thread.
You'll need SF account thou.

[janos666]

Argyll CMS uses some form of CIECAM02 (http://en.wikipedia.org/wiki/CIECAM02) for Ambient Light scaling.
CIECAM02 Ambient Light scaling is standardized by the CIE Technical Committee (http://en.wikipedia.org/wiki/International_Commission_on_Illumination).

When Argyll CMS scales REC.709 to ambient light with CIECAM02, then that adjustment is standardized for a color managed workflow. It's really as simple as that.


Almost there, but:

- The ICommission Internationale de l´Eclairage and the International Telecommunication Union are different organizations.

- Rec 709 was published in 1990
- CIECAM02 was published in 2002

-> ITU could and did use CIE standards to describe the color space in their own standards but the CIE standards (mostly those which comes AFTER the corresponding ITU standard) are not strictly applies to ITU standards.

-> CIECAM02 has nothing to do with Rec709 until it mentions it. And it does not.

-> Was ITU optimistic about the possibility that CIE will come up with something which solves the "problem" with their new standard? :p
I don't know... Why would ITU develop something which has to be "fixed" later by somebody else? :confused:
(If they could simply develop something which already works.)


Even if you think it can work like this (but no, it can't...). There were 12 years gap when the Rec709 adopters didn't have any official suggestions about how to scale that miserable Inverse-Encode curve.
I think they would simply ignore it and use a pure-power curve instead. And keep it after CIECAM02 to ensure the consistency.



But I sad: "almost there", because even if I can't believe it's a nice thing to do, I can try to use CIECAM02.

[QQ]

Closing file was what I have been missing!

Any idea why MPC-HC won't switch refresh rate for me?

I have set 24 for 24, 50 for 25, 60 for 30, 60 as default, 23 for 23.976, and 59 for ntsc in MPC.

Content is 23.976

If tv is running at 60, no switch happens at all.

If tv is running at 23, it tries to switch to some over mode when LEAVING full screen (nothing on entering though)!

[cyberbeing]

janos666, you like being difficult don't you.

CIECAM02 is a color appearance model, it's standardized, and it has been adopted for use with ICC profiles and CMS. That is what Argyll CMS uses, and that if how I got the results I posted.

ITU never standardized how REC.709 should be viewed. All we have are recommendations.



Broadcast monitors seem to have a native response of around 2.35 from the measurements I've seen.

The EBU specifies 2.35 with a tolerance of ±0.15 if I remember correctly.

I believe THX only requires a minimum of 2.22, rather than specifically 2.22.

System gamma should not be "linear." That is, you should not be using the inverse camera gamma as the display gamma, it should be offset. For people that believe the camera gamma (Rec.709 curve) is 2.2, that would mean using a gamma greater than 2.2 at the display.

System gamma depends on the viewing environment, and I have heard numbers ranging from around 1.1 to 1.3. The EBU recommends 1.2 for viewing in a dark room, and it is just about the only system gamma recommendation I've seen in a technical paper.

You should be using the inverse of the camera gamma with a system gamma offset, rather than an oversimplified power function. There is a pretty big difference between the inverse Rec.709 curve compared to the equivalent power function. There is more midtone contrast, and it is brighter towards black.

Here is a system gamma of 1.2 vs the equivalent 2.35 power curve:
http://i42.tinypic.com/2pq8aom_th.png (http://i42.tinypic.com/2pq8aom.png)

Below 25% brightness is higher than even a 2.2 power curve, and as a result, shadow detail is more visible and the display's contrast requirements are significantly lowered.

This way you gain greater midtone contrast, and yet you retain good shadow detail as the curve is within the capabilities of modern displays.
REC.709 without any offset is approximatly centered on a 1.96 power-curve
REC.709 offset to 1.125 is approximately centered on a 2.22 power-curve. (Bright Room)
REC.709 offset to 1.2 is approximately centered on a 2.35 power-curve. (Dim Room)
With a CIECAM02 offset of ~1.25 (32 lux Dim Room)
REC.709 offset to 1.225 is approximately centered on a 2.4 power-curve. (Dark Room)
With a CIECAM02 offset of ~1.27, you have an average gamma of 2.35 and median gamma of 2.4. (0.1 lux Pitch Black Room)
REC.709 offset to 1.275 is approximately centered on a 2.5 power-curve. (Pitch Black Room)

I assume CIECAM02 has some sort of standardized method for calculating the offsets for particular ambient light conditions. From what I remember, Argyll reported offsets of ~1.25 for 32 lux ambient and ~1.27 for 0 lux ambient. While this is just a guess, CIECAM02 appears to be matching the average or median gamma of a curve to what it believes is the correct power-curve for the viewing conditions, rather than centering it on the closest power-curve. While I would like at least a CIECAM02 0.01 or 0.1 lux setting to match Argyll CMS, I see nothing wrong with you using a centered curve for some of the other presets if you prefer. You'll need to figure out on your own how to offset the curves though.

[janos666]

Ok.
1: You start to convince me.
2: I won't rush to set up a CIECAM02 transformation then.
-> But I am still not sure about how to find the correct parameters.
May be I could plot the curves and play with the numbers manually but that's something I would avoid. (I usually let other people to do these kind of things and I expect them to lie me that they did a professional job. :D)

I won't have time to play with the code for 3 days anyway. May be we will figure out something until then.

[chros]

Feature request:
- keyboard shortcuts for After Playback entries (at least "stand by" and "do nothing") in Options -> Keys
- it would be nice that these option can trigger an OSD message

These enhancements are very useful with remote controller application.

Thanks

(Posted on the trac, too)

[Dstruct]

1.5.0.2827

-> close MPC
-> doubleclick movie in Explorer (maybe one with external subtitles - to force slower loading time)
-> now when MPC pops up immediately click the mute button

Result: Sound
Expected: Muted


(Windows XP SP3 + RME HDSP 9632, DirectSound output)


https://sourceforge.net/apps/trac/mpc-hc/ticket/1157


FIXED (1.5.2.3114)

[JanWillem32]

The last few days I've been ill, so I haven't been able to do much. I intend to pick development up again.

For the case with the weird mixer response with EVR reported by Stephen R. Savage:
It's indeed the Intel GPU. Some time ago, I've asked if a friend could make render/mixer mode report of his Core 2 Duo generation Intel IGP.
The GPU is incapable of using any 4:2:0 chroma format. The GPU also can't handle a simple shader chain to up-sample chroma.
Solution: set RGB32 as preferred format for GPU's that report that they can't properly deal with the Y'CbCr formats. It's not an ideal situation to have this kind of processing of video data by the CPU, and it only somewhat works on 8-bit processing chains. It's quite a burden on the CPU in general and the memory controllers of both the CPU and the GPU to use software mode conversions to reasonable quality RGB32. Processing in 16-bit is too heavy on the IGP, 10- and 32-bit surfaces are not available.
This also means that the all the codecs used must be natively capable of deinterlacing, as the EVR mixer won't deinterlace RGB input formats. The internal convertors must be strictly bound to using 4:2:0 formats with 4:2:0 video, or completely convert to RGB32. Handling of native 4:2:2 and 4:4:4 video input still has to be tested later on.

I'm still very interested in the mixer handling of various other old or low-power GPU's that have problems with the EVR mixer. Maybe those can use a different solution.

Things I plan to do, but will probably need a bit of help with (in no particular order):
-complain about the default 7.1 channel ordering in the audio mixer (personal problem that I could correct by swapping the surround channels in the channel mapping)
-add two extra capability checks for a 10-bit backbuffer and a 10-bit display format in the renderer to solve error messages for GPU's that can't set them
-test my fix for switching rendering from one screen to another screen in certain multi-monitor setups
-fix screenspace shader option for VMR9 (it's always grayed out)
-add EVR renderer option "prefer NV12 as mixer format"
-add VMR9+EVR renderer option "try to set 3D load GPU speeds"
-rework my shader thread OP
-release a new shader pack
-write my signature, add link to the folder that contains the nightly builds, the shader pack, and other development stuff
-help with the modifications to the color management janos666 is proposing
-finally get the the EVR mixer working universally, or try to get C++ programmers to help with writing a new one
-add the scaling shaders that I've made ages ago to the standard menu
-try to implement the scaling shaders to also scale the bitmap-based subtitles
-trash the ancient vector-based subtitle renderer and font renderer and write one that uses DirectX instructions and can use optional anti-aliasing or even ClearType
-add an experimental refresh rate fix for the D3D full screen rendering that allows changing it to a correct value, just like in the windowed mode

@thuan I've heard that nVidia hard-coded the chroma conversion in the drivers. It's unfortunately the pure bilinear form of stretching chroma to the native resolution. The only solution to this, is to either use a pre-processing shader to undo the driver's filtering (inefficient) or write a new mixer.

By the way: does anyone have comments on my set of pictures? I'm planning to add modes to scale chroma and full screen video with some shaders. I would like to know what/which I should implement on a quality to performance to effort base rating.

[alexins]

Media Player Classic HomeCinema (x86/x64), 1.5.1.2931 (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-1-2931.html)

Changes (2929-2931): (http://www.xvidvideo.ru/changelog-media-player-classic-home-cinema.html)

"Volume" and "Balance" sliders:
mouse scroll up or button up = move to right
mouse scroll down or button down = move to left
This commit fixes ticket #989;
fix "Boost" slider in "Audio Switcher" dialog box;
fix sliders in "Subtitles->Default Style" dialog box;
fix sliders in "Miscellaneous" dialog box. (see details in comit 2929).

[namaiki]

janos666 and janwillem, any idea about trac 998?

"BT.601 -> BT.709" shader actually does the reverse transform" reported by thewebchat [Status: new Bug ]
http://sourceforge.net/apps/trac/mpc-hc/ticket/998

[18:31] tetsuo--: namaiki|asleep 998, janos666 and janwillem will have to look at it
[18:31] tetsuo--: maybe you can post on doom9 and ask them to comment on it

:)

[DMD]

How to apply the toolbar?

http://sourceforge.net/apps/trac/mpc-hc/wiki/Toolbar_images

THANKS

[JanWillem32]

@namaiki: Ticket 998 can be kept idle until the shader pack has been integrated, both "correct video colorspace BT.601 [SD] to BT.709 [HD] for HD video input" and "correct video colorspace BT.709 [HD] to BT.601 [SD] for SD video input" have correct and complete color matrices. It's really not the only shader with errors. In my shader pack, I've corrected all of them to more useful code.

@DMD: For automatic loading, "mpc-hc64.exe" or "mpc-hc.exe" has to be inside the same folder as "toolbar.bmp".

I've added binaries and source code deviated from build 2933 to the folder in my signature. I optimized the pixel shader constants initialization code, and changed the options for dithering levels on request. No real fixes are included yet.

[DMD]

....
@DMD: For automatic loading, "mpc-hc64.exe" or "mpc-hc.exe" has to be inside the same folder as "toolbar.bmp".....
Thanks for good information, I hope we can change other parts of the skin.

[thuan]

@Jan: Good to hear you have recovered. About my issue, thanks for your investigation, I'm going to keep this GFX card in case you manage a fix, so I can test it out for everyone.

[Mercury_22]

Revision 2935 - Directory Listing
Modified Wed Feb 16 03:53:15 2011 UTC (15 hours ago) by Aleksoid

Add : Fast seek(on keyframe) options - default ON (Page "Tweaks");
Change : swap default hotkey for Framestep/Framestep back and Jump Forward (medium)/Jump Backward (medium)

It's crashing when trying to play the previous file in the folder with the default option for "Fast seek(on keyframe)" = on!
When trying to play the next file in the folder with "Fast seek(on keyframe)" on there is no problem!

[oddball]

I sometimes get hard lockups of Windows 7 64 Ultimate (I have to press reset) when playing back stuff with MPC-HC (any recent build). Usually it's if I jump to some point in the video but sometimes happens when I start a file. I tried a few things including different video decoders (CoreAVC, ffdshow and internal). The only other two things I can think of is ReClock and D3D Fullscreen playback (Or possibly EVR-Sync). I am using Nvidia's latest drivers on a G210.

Which is the most likely candidate here?

[JanWillem32]

What are your temperatures and voltages when you write a continuous log session during playback? Does the standard system error log say anything?
Some of the higher quality settings have been reported to be too much of a burden on overheating systems. Dust and other causes of insufficient cooling is often the main cause of this type of problems.
If you need assistance, I'm available on the IRC channel, but make sure you've checked the basics, and have the logs ready before asking for help.

[oddball]

I assume you are replying to me. I have 2 GPU's one is reading 59C and the other is 80C. Both are passively cooled. They only lockup Win7 during skipping through a video or sometimes on startup. Never had it happen during normal playback. How do I enable continuous logging?

EDIT: BTW I recall there being a known bug with skipping through videos that would crash MPC. But it only used to crash the player. Not the entire OS.

[JanWillem32]

Rivatuner has a proper logging feature. It's been a while since I've used it, so I don't exactly know how to set it up. Don't forget that logging voltages, CPU, HDD and chipset temperatures can also be important. Seeing that you already have one GPU at 80ºC (processing a 3D load, I hope), pushing it a bit further, will really overheat it.

Edit:
@thuan & others that have errors with 10-bit display output: I'm testing an extra initialization check before setting the back buffer to 10-bit. Program testers are available in the folder added to my signature. Could anyone report if it's working?

[hdboy]

when I try to play a .ratdvd file, I get "failed to query needed interface to provide dvd playback."

I did "regsvr32 qdvd.dll" successfully. still same result. I added "DVD navigator" directshow filter. no go. also tried different renderers.

I AM able to play DVD from a video_ts\ folder by dragging the video_ts.ifo file into mpc, so dvd does seem to work. what is the problem here, does anyone knows? thanks.

[betaking]

can not compiled last mpc-hc svn 2936
mpegsplitter.lib(MpegSplitter.obj) : error LNK2019: 无法解析的外部符号 "public: __thiscall CMpegSplitterSettingsWnd::CMpegSplitterSettingsWnd(void)" (??0CMpegSplitterSettingsWnd@@QAE@XZ)，该符号在函数 "private: virtual class CInternalPropertyPageWnd * __thiscall CInternalPropertyPageTempl::GetWindow(void)" (?GetWindow@?$CInternalPropertyPageTempl@VCMpegSplitterSettingsWnd@@@@EAEPAVCInternalPropertyPageWnd@@XZ) 中被引用
C:\mpc-hc\bin\mpc-hc_x86\\mpc-hc.exe : fatal error LNK1120: 1 个无法解析的外部命令
结果 生成日志保存在“file://C:\mpc-hc\bin\obj\Release_Win32\mpc-hc\BuildLog.htm”

[Aleksoid1978]

can not compiled last mpc-hc svn 2936
mpegsplitter.lib(MpegSplitter.obj) : error LNK2019: 无法解析的外部符号 "public: __thiscall CMpegSplitterSettingsWnd::CMpegSplitterSettingsWnd(void)" (??0CMpegSplitterSettingsWnd@@QAE@XZ),该符号在函数 "private: virtual class CInternalPropertyPageWnd * __thiscall CInternalPropertyPageTempl::GetWindow(void)" (?GetWindow@?$CInternalPropertyPageTempl@VCMpegSplitterSettingsWnd@@@@EAEPAVCInternalPropertyPageWnd@@XZ) 中被引用
C:\mpc-hc\bin\mpc-hc_x86\\mpc-hc.exe : fatal error LNK1120: 1 个无法解析的外部命令
结果 生成日志保存在“file://C:\mpc-hc\bin\obj\Release_Win32\mpc-hc\BuildLog.htm”

If you use VS2008 - add this 3 files in MpegSplitter project:
IMpegSplitter.h
MpegSplitterSettingsWnd.cpp
MpegSplitterSettingsWnd.h

Sorry - but i don't have VS2008 installed.

Can anybody make this and commit MpegSplitter.vcproj to the SVN ???

[Aleksoid1978]

can not compiled last mpc-hc svn 2936
mpegsplitter.lib(MpegSplitter.obj) : error LNK2019: 无法解析的外部符号 "public: __thiscall CMpegSplitterSettingsWnd::CMpegSplitterSettingsWnd(void)" (??0CMpegSplitterSettingsWnd@@QAE@XZ),该符号在函数 "private: virtual class CInternalPropertyPageWnd * __thiscall CInternalPropertyPageTempl::GetWindow(void)" (?GetWindow@?$CInternalPropertyPageTempl@VCMpegSplitterSettingsWnd@@@@EAEPAVCInternalPropertyPageWnd@@XZ) 中被引用
C:\mpc-hc\bin\mpc-hc_x86\\mpc-hc.exe : fatal error LNK1120: 1 个无法解析的外部命令
结果 生成日志保存在“file://C:\mpc-hc\bin\obj\Release_Win32\mpc-hc\BuildLog.htm”

If you use VS2008 - add this 3 files in MpegSplitter project:
IMpegSplitter.h
MpegSplitterSettingsWnd.cpp
MpegSplitterSettingsWnd.h

Sorry - but i don't have VS2008 installed.

Can anybody make this and commit MpegSplitter.vcproj to the SVN ???

[betaking]

Thanks, i try again!:)
TEST OK!

[thuan]

@Jan: I still have the same error when I have both D3D Fullscreen mode and 10bit output enabled. Tested with mpc-hc tester dfr2935.7z

[JanWillem32]

That's too bad, I tried to fix the detection of the 10-bit output mode. It's only possible to detect 10-bit capability for the backbuffer, not for the display format. For some reason, the driver allows a 10-bit backbuffer, but not a 10-bit display mode. I guess this is another DirectX 9 limitation. (The initialization of the last frontbuffer, backbuffer and display format happen in the same step for DirectX 10/11.)
I'll see if I can add a manual option soon, to disable the 10-bit display format, while allowing the 10-bit backbuffer format in D3DFS mode.

I just added the chroma comparison pictures to the folder. A single package is easier to download than to save the pictures individually.
Program testers are available in my folder (the link to them is in my signature). These are deviated from build 2937.
This is mostly to test the new language RC files with some Unicode updates.
I optimized the ditherers to run a bit faster and handle near-black areas better. It really doesn't work well on source banding, so it still needs a debanding filter inserted into the mixer or renderer chain to properly work on the current quality of consumer-grade video. I removed some of the previous requirements for the ditherers, but they still need floating-point surface capability to be enabled. The floating-point options don't have to be enabled to use the ditherers. However, I don't recommend to enable dithering on 8-bit surfaces.