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

[LigH]

The only limitation is that it requires Vista+ ...

Believe it or not ... but I know many people who are still quite satisfied with XP. :o

So ... go ahead, implement one. But please, don't make it the only one. :scared:

The removal of DirectX 7, though, is probably inevitable. Or does anyone related to modern media still use Windows 9x which is already limited regarding multi-channel audio, not to mention file sizes? I believe many installers of modern media software already require XP as minimum.

[tetsuo55]

Believe it or not ... but I know many people who are still quite satisfied with XP. :o

So ... go ahead, implement one. But please, don't make it the only one. :scared:

The removal of DirectX 7, though, is probably inevitable. Or does anyone related to modern media still use Windows 9x which is already limited regarding multi-channel audio, not to mention file sizes? I believe many installers of modern media software already require XP as minimum.The official MPC-HC binary won't run on any OS older than XP sp2, nor on any hardware that lacks SSE2 instructions.

So on the officially supported OS's only overlay, VMR9(dx9) and EVR (dx9) work natively, those os's supporting Dx11 are also the ones with native support for EVR

[JanWillem32]

@cyberbeing: The only only major difference in the rendering pathway for the GPU of VMR-9 and EVR are the mixers. It could be that the GPU chokes on doing conversions for the mixer but is perfectly capable of rendering with a A32R32G32B32F surface. I will need assisting from people with this specific hardware problem to see if making changes to the mixer instructions or the surface support detection will work.
Are there any volunteers for this? I don't mind doing some remote desktop work, building even up to 10 altered versions or even analyzing system errors. This all does over-extend what is possible on a forum, so we normally handle these things by chat on our IRC channel.

@Dstruct: level 1 (static) is a_afra's ditherer, no dithering is level 0 (rounding).

@LigH There are no plans other than removing DirectX 7 types and modernizing the the DirectX9 types at the moment. I would not recommend removal of the DirectX 9 types until the extended support lifecycle of the last DirectX 9-only consumer OS (XP) has ended on 4/8/2014. http://support.microsoft.com/lifecycle/?p1=3223

[janos666]

Native CRT gamma, no it wouldn't match Rec.709. The point is you would be using additional post-processing when mastering to approximate a Rec.709 scaled-inverse on a CRT. Of course nothing is well standardized, so what every studio does is probably different.


According to my own knowledge, the Rec709-Encode transfer function (keep in mind that it's a copy from the previous standards, it's not a new HD thing at all) was design to prepare the original linear data (the RAW sensor data isn't gamma weighted) to be watched on analog CRT displays without any additional post-processing on the user side.
That's how they constructed the encode curve: Linear data -> Encoding with Rec709 curve -> broadcast -> analog decoding (no additional image manipulation) for analog CRT -> proper end-use experience

Ok, may be there was some kind of basic "CMS" in some CRT TVs. (Something like contrast, or even saturation control, etc.) But the original idea (in the beginning of this whole game) was to support the legacy analog CRT (and you can see where we are now, but every new standard is based on the previous and they all tried to keep the compatibility with the legacy standards...)
And that legacy CRT may be averages around a pure-power curve, not an inverse-Rec709-encode curve. (But I never measured any old analog CRTs myself.)

And there is another misleading factor: Sometimes they did (or still do?) use the Inverse-Rec709-Encode curve: When they edited the linear data before the Rec709 encoding. They needed a display with LUT processing to see how it will look after they apply the Rec709 Encode curve.
*I tried to simulate it once: I calibrated my display with unscaled Rec709 curve and watched a linearized output (I used yCMS to do it) though this calibration: The result reminded me to the state when I watch an unmolested data with a pure-power curve calibration (except the inevitable detail loss).

But, of course, it's only my opinion (based on my own little "research" in this topic).

Next time I want to recalibrate my display, I will try to use a scaled invers-Rec709-Encode curve. I currently use: Input_Transfer_Function 1.0 0.0 0.425531914893617 0.0 (with the same numbers for the output_ and yes, the display is calibrated to gamma 2.35)
The gamut emulation is based on the TRC curve (curve + matrix style), so I will need to ignore the output_transfer_function and use the IRE measurement data to specify the uncalibrated display response.
But what coefficients and exponent do you recommend to achieve a properly scaled curve (for the input_ function)?

[clsid]

The official MPC-HC binary won't run on any OS older than XP sp2, nor on any hardware that lacks SSE2 instructions.

So on the officially supported OS's only overlay, VMR9(dx9) and EVR (dx9) work natively, those os's supporting Dx11 are also the ones with native support for EVRDoesn't the official build only require SSE1? Anyhow, I don't see how that is relevant to DirectX. Besides, the SSE requirement can easily be removed in personal builds with a 2-line patch. The performance difference is very small.

The default renderer on Windows XP is actually VMR-7 (windowed). Since that isn't even a custom renderer in MPC, it would be pretty pointless to remove it. So I assume you guys are only considering removing VMR-7 (renderless) and the DX7 QT/Real renderer?

What is the current status of the EVR CP black screen issue? Has it been confirmed that r2863 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2863) has fixed it?

[Taurus]

Doesn't the official build only require SSE1?
Yes, SSE(1).
I have two Athlon XP's with only running SSE(1) instructions on WinXp 32bit.
No problems until now with MPC-HC.:devil::p

[mr.duck]

What is the current status of the EVR CP black screen issue? Has it been confirmed that r2863 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2863) has fixed it?

I wanted to test but this page has not been updating for a week and a 1/2 http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/

[Superb]

AMD/ATI Catalyst 11.1 is out.
http://support.amd.com/us/gpudownload/Pages/index.aspx

[cyberbeing]

@cyberbeing: The only only major difference in the rendering pathway for the GPU of VMR-9 and EVR are the mixers. It could be that the GPU chokes on doing conversions for the mixer but is perfectly capable of rendering with a A32R32G32B32F surface. I will need assisting from people with this specific hardware problem to see if making changes to the mixer instructions or the surface support detection will work.
I suspect this is more of a WinXP problem or possibly a NVIDIA/WinXP problem rather then a specific hardware problem. Have you tried loading up WinXP SP3 yourself to see if you can reproduce?

Next time I want to recalibrate my display, I will try to use a scaled invers-Rec709-Encode curve. I currently use: Input_Transfer_Function 1.0 0.0 0.425531914893617 0.0 (with the same numbers for the output_ and yes, the display is calibrated to gamma 2.35)
The gamut emulation is based on the TRC curve (curve + matrix style), so I will need to ignore the output_transfer_function and use the IRE measurement data to specify the uncalibrated display response.
But what coefficients and exponent do you recommend to achieve a properly scaled curve (for the input_ function)
I'm unsure exactly what you are asking. You seem to be talking about madVR and yCMS.

During yCMS 3dlut creation, if you specify both an Input_Transfer_Function and an Output_Transfer_Function, Grayscale_Measurements is ignored. By the same measure, there is no need to specify an Input_Transfer_Function and Output_Transfer_Function unless they are different from each other. Also, unless you have some special source, Input_Transfer_Function should never be touched in the first place. It sounds like you are messing with settings in yCMS which you don't understand properly. If you have questions, post in the yCMS thread.

[janos666]

The Input_Transfer_Function sets the decode curve. It has to be the same function which you think you want to see as a final result on your screen (otherwise gamut emulation won't work properly).
I use the Output_Transfer_Function when I calibrate my display with ArgyllCMS/dispcal and I know the TRC of my display. But I can't describe the ambient-scale Rec709 curve with this, so I would use the Grayscale_Measurements instead.
So, I would use the Grayscale_Measurements to describe my uncalibrated display response and the Input_Transfer_Function to describe my decode curve (which is the desired TRC after the gamma correction made according to the Grayscale_Measurements).
I asked for proper parameters for the Input_Transfer_Function which describes an scaled Rec709 curve (for a dark room). I want to see an exponent and a slope value. That's all.

[JanWillem32]

@cyberbeing I don't own a license of Windows XP. On top of that, my hardware is totally different and I don't have any experience with the combination of XP and EVR. I have been told though, that the binary's from .NET 4.0 Framework work generally better than the older ones. Maybe that's a good start, along with updating drivers, checking temperatures, and more of those things.
Your problem seems to be quite specific, you are currently the only one reporting this. There's not much I can do about it without on in-depth analysis. I suggest we take your computer for a test run. I'll be available after about 7 hours of sleep. irc://irc.freenode.net/MPC-HC

[Dstruct]

@Dstruct: level 1 (static) is a_afra's ditherer, no dithering is level 0 (rounding).

Ok, thanks!

[cyberbeing]

The Input_Transfer_Function sets the decode curve. It has to be the same function which you think you want to see as a final result on your screen (otherwise gamut emulation won't work properly).
Incorrect. Input_Transfer_Function is basically the source gamma from which gamma correction is performed (the 'before'). Output_Transfer_Function (the 'after') is what the target gamma which the Input_Transfer_Function is adapted to.

Input_Transfer_Function doesn't represent what you want to see as final result when also using Output_Transfer_Function and/or Output_Format.

I use the Output_Transfer_Function when I calibrate my display with ArgyllCMS/dispcal and I know the TRC of my display. But I can't describe the ambient-scale Rec709 curve with this, so I would use the Grayscale_Measurements instead.
When you calibrate your display to a gamma of 2.35, as you are currently doing, you shouldn't be touching the Input_Transfer_Function and Output_Transfer_Function settings. All you should be using is Input_Format, Output_Format, and Gamut_Measurements. Optionally you could also use Grayscale_Measurements and Gamma_Curve 0.0 2.35 as well.

So, I would use the Grayscale_Measurements to describe my uncalibrated display response and the Input_Transfer_Function to describe my decode curve (which is the desired TRC after the gamma correction made according to the Grayscale_Measurements).
I asked for proper parameters for the Input_Transfer_Function which describes an scaled Rec709 curve (for a dark room). I want to see an exponent and a slope value. That's all.

Now this is correct. Only when Grayscale_Measurements is used does Input_Transfer_Function change roles and instead represent the target gamma you want to see on your display.

I'm unsure exactly how Argyll CMS calculates its Rec.709 curves using ambient light measurements. Asking on the Argyll CMS mailing list is probably your best bet to getting an answer.

I also think you should post your yCMS config in the yCMS thread (http://forum.doom9.org/showthread.php?t=154719) along with what you intend the 3DLUT to do, since it still sounds like you are not configuring yCMS properly. The yCMS advanced settings are not particularly intuitive to use. More importantly they aren't even needed unless you are doing something non-standard. That big warning in the manual is there for just that reason.WARNING: The following commands are meant for advanced users only, people who perfectly understand the purpose of these commands. If you do not fully understand what is following there is a big chance that you will not need any of it.
__________

@cyberbeing I don't own a license of Windows XP. On top of that, my hardware is totally different and I don't have any experience with the combination of XP and EVR. I have been told though, that the binary's from .NET 4.0 Framework work generally better than the older ones. Maybe that's a good start, along with updating drivers, checking temperatures, and more of those things.
Your problem seems to be quite specific, you are currently the only one reporting this. There's not much I can do about it without on in-depth analysis. I suggest we take your computer for a test run. I'll be available after about 7 hours of sleep. irc://irc.freenode.net/MPC-HC
No need for a WinXP license for this purpose, just use it as a trial for 30 days.

Temperatures are fine, and my GPU drivers are up-to-date as I just installed 266.45 back on January 12th. I could try rolling back to something older if you'd like though.

Also, which binaries are you referring to?

I currently use EVR.dll 6.0.6002.18084 (vistasp2_gdr.090806-2338). Older revisions of EVR have the same issue. The newer Win7 EVR doesn't work with XP, since it can't be registered with regsrv32.
I have .NET 1.1, .NET 2.0, .NET 3.0, .NET 3.5 installed, as well as the .NET 4.0 'Client Profile' and .NET 4.0 'Extended'.

For reference, this is the type of distortion I'm seeing (the patterns, shapes, and locations change depending on the video, but in general that's how it looks, black screen with colorful geometric shapes):
http://img213.imageshack.us/img213/6038/evrfullfp.png

If I'm still awake in 7 hours I'll try to get on IRC.

[v0lt]

Revision 2863
...
-changed OSD color scheme to make sharp text look better, by bobdynlan
EVR Custom Pres. - normal
EVR Sync - bug is not fixed

[hissatsu]

Has anyone else noticed the ability to take screenshots being broken with builds past r2825? With r2840 and every build after that, I get a red/gray/black garbled mess when I take a screenshot. I've tested it with DVDs and Blu-rays, tried saving as PNG, JPG, BMP, same thing.

[pdanpdan]

What is the current status of the EVR CP black screen issue? Has it been confirmed that r2863 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2863) has fixed it?
For me it's not fixed (Win7 64, mpc-hc 32/64, ATI HD2400PRO, Cat 11.1) for anything except DXVA.

[JanWillem32]

The problem of cyberbeing is in the "experimental" lab on IRC at the moment.

@v0lt: Thanks! I added a few fixes to that rendering path. I will see to it that it's committed soon.

@hissatsu The screenshot function is hard-coded to 8-bit. Disable the surface changes, and it will work again. I'm already designing a surface exporter that can save images in all four surface types to a file, and can use the render stages (pixel shaders and scalers).

@pdanpdan My mixer fixes are not in the trunk build yet, try one of my beta builds. If that solves things, I might get those committed soon.

[pdanpdan]

I tried these:Originally Posted by JanWillem32 View Post, MSVS 2010 versions only, based on v1.4.1.2891

It's not fixed, but what I saw is that now, in D3D fullscreen it always disables aero

[janos666]

@cyberbeing
I shouldn't argue with you anymore because we have the exact opposite approaches for this problem. But I can't stand to react: CLICK (http://forum.doom9.org/showpost.php?p=1474597&postcount=76)

[Polcius]

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.

I have a few questions:

1- Do DVD's also use the Rec.709 gamma? Or only HD material uses it?

2- Why do you use these coordinates 0.312713x 0.329016y instead of the default ones? Or why not use the default 6500k daylight setting?

3- When measuring ambient light, do I have to do this with the TV on or off? Because I assume that the light emitted from the TV will have an effect on the measurement.

BTW: I measured the ambient light. My room is "dim", I only have a small bulb behind the TV. The measurement says 1 lux. Is this possible?

Thanks

[hissatsu]

@hissatsu The screenshot function is hard-coded to 8-bit. Disable the surface changes, and it will work again. I'm already designing a surface exporter that can save images in all four surface types to a file, and can use the render stages (pixel shaders and scalers).


Forgive me if I'm a bit clueless, but I really don't know what you're saying about surface changes. If it has to do with having 10-bit or shaders enabled, they aren't. Builds r2825 and earlier can take screenshots normally, builds r2840 and later screenshots are a mess, same settings.

[JanWillem32]

@hissatsu: Really sorry, because of byte-ordering problems (BGR<->RGB), only the PNG and JPEG type are working. 8-bit surfaces means that the functions 10-bit RGB Output, Full Floating Point Processing and Half Floating Point Processing have to be disabled.

[Dstruct]

Any idea why http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log isn't reachable?

[Casshern]

I hope the versions in the quote below are the "latest beta" builds regarding the mixer options. Unfortunately they do not work and give black screen:

With the internal dxva decoder the ctrl-j stats (which still overlay over the black screen) show this:
Mixer: RGB32 Type: X8R8G8B8
Under formats: surface is A8R8G8B8 and the rest is X8R8g8b8
Pin Info on the EVR CP shows that NV12 is used. Aero is on.

YUY2 tested with ffdshow software decoding also produced a black screen with the same stats as above. This used to work with an earlier test version, so we kind of move in the wrong direction. Just hope that gets sorted out soon - so everybody can enjoy the good stuff that comes from these rewrites in the near future.

@cca: Once the bug of forced blurring the chroma from 4:2:0 to 4:2:2 is solved with EVR, the behavior will be the same as with all other renderers (no chroma changes).
"16-235" unfortunately sets Y'CbCr to the ranges <16,235>, <16,235>, <16,235>, instead of the correct ranges <16,240>, <16,240>, <16,240>. This is just another defect of the mixer. Anyone who absolutely needs limited ranges can use my shader in screenspace.

Still available, DXVAChecker preset, mostly to expose some ATi CCC functions: http://www.mediafire.com/?e6ix43wpyndo8sm

Ditherer fully integrated, levels are selectable. The temporal dithering shader requires a bit of processing power. (It's still not even close to my regular heavy shaders.) The ditherer settings are now properly saved to a .INI file or the registry. The higher dithering levels can be a bit noisy, just try out some banding samples and use whatever settings you like. Results between 10-bit and 8-bit output are different.
MSVS 2010 versions only, based on v1.4.1.2891
x86: http://www.mediafire.com/?aiemgnfoc3seemr
x64: http://www.mediafire.com/?lbbyod3gjvb637r

[JanWillem32]

Well, I have a prototype that has the ugly conversion ripped out.
This must be one of the most user un-friendly builds ever, but I do feel that I have to explain things.
The default EVR mixer will in most cases reject IYUV/I420 and YV12 format input. The current, but wrong solution when those types are sent to the mixer, is to provide the mixer with an ugly and lossy conversion to the YUY2 format.
This build will still render in EVR, but with some limitations. If rendering fails, it reverts to VMR. That often includes using the internal software codecs on 8-bit 4:2:0 video.
With external codecs rendering will usually fail if the input is given in a IYUV/I420 or YV12 format. NV12 input is advised for software codecs that play 8-bit 4:2:0 video.
DXVA commonly uses NV12 already, so that should work fine.
Lastly, if anything else but NV12, IYUV/I420 or YV12 is used in EVR with this build when playing 8-bit 4:2:0 video, such as mixing with the YUY2 or RGB formats, you get lossy conversions and often the chroma bug, as well.
At the moment, I'm trying to find people to help us write and test the conversion code from IYUV/I420 or YV12 to NV12 to solve this problem.

[Mangix]

Any idea why http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log isn't reachable?sourceforge was DDoSed

[Brazil2]

The default renderer on Windows XP is actually VMR-7 (windowed). Since that isn't even a custom renderer in MPC, it would be pretty pointless to remove it. So I assume you guys are only considering removing VMR-7 (renderless) and the DX7 QT/Real renderer?
That would be a pity to remove VMR7 renderless now because there is still a majority of people using XP and many many of them are running it on quite slow machines -compared to 'modern ones'-, so VMR7 renderless is the only way to get a smooth playback AND with subtitles.

[Carpo]

anyone know where else i could get svn builds of mpc-hc - as xvidvideo.ru hasn't updated since 17th jan

[goldie]

anyone know where else i could get svn builds of mpc-hc - as xvidvideo.ru hasn't updated since 17th jan
XhmikosR (http://forum.doom9.org/member.php?u=125152) did

[Carpo]

Thanks

[betaking]

what change by last mpc-hc 2893 svn?

[Dstruct]

When changing the Accurate and Alternate VSync options with an opened video (paused or while playback), MPC-HC (1.4.1.2891) crashes:


Microsoft (R) DrWtsn32
Copyright (C) 1985-2001 Microsoft Corp. Alle Rechte vorbehalten.



Anwendungsausnahme aufgetreten:
Anwendung: C:\Programme\Media Player Classic\mpc-hc.exe (pid=1940)
Wann: 25.01.2011 @ 11:13:21.093
Ausnahmenummer: c0000005 (Zugriffsverletzung)

*----> Systeminformationen <----*
Terminalsitzungskennung: 0
Prozessoranzahl: 2
Prozessortyp: x86 Family 6 Model 15 Stepping 6
Windows-Version: 5.1
Aktuelles Build: 2600
Service Pack: 3
Aktueller Typ: Multiprocessor Free

*----> Taskliste <----*
0 System Process
4 System
332 smss.exe
388 csrss.exe
412 winlogon.exe
456 services.exe
468 lsass.exe
632 svchost.exe
684 svchost.exe
740 svchost.exe
792 spoolsv.exe
1108 Explorer.EXE
1260 hdsp32.exe
1296 hdspmix.exe
516 TOTALCMD.EXE
1120 svchost.exe
304 firefox.exe
1712 plugin-container.exe
1764 thunderbird.exe
1940 mpc-hc.exe
1904 drwtsn32.exe

*----> Modulliste <----*
(0000000000340000 - 0000000000349000: C:\WINDOWS\system32\Normaliz.dll
(0000000000400000 - 000000000111b000: C:\Programme\Media Player Classic\mpc-hc.exe
(0000000001b80000 - 0000000001e59000: C:\WINDOWS\system32\xpsp2res.dll
(0000000002910000 - 0000000002b0f000: C:\WINDOWS\system32\d3dx9_43.dll
(0000000010000000 - 0000000010446000: C:\Programme\Ffdshow\ffdshow.ax
(00000000408b0000 - 0000000040996000: C:\WINDOWS\system32\WININET.dll
(0000000040f50000 - 0000000041139000: C:\WINDOWS\system32\iertutil.dll
(00000000452e0000 - 0000000045413000: C:\WINDOWS\system32\urlmon.dll
(000000004fd50000 - 000000004fef6000: C:\WINDOWS\system32\d3d9.dll
(000000005b0f0000 - 000000005b128000: C:\WINDOWS\system32\uxtheme.dll
(0000000061880000 - 00000000618ba000: C:\WINDOWS\system32\OLEACC.dll
(000000006de80000 - 000000006de86000: C:\WINDOWS\system32\d3d8thk.dll
(0000000071a00000 - 0000000071a08000: C:\WINDOWS\system32\WS2HELP.dll
(0000000071a10000 - 0000000071a27000: C:\WINDOWS\system32\WS2_32.dll
(0000000072210000 - 000000007223b000: C:\WINDOWS\system32\DINPUT.dll
(0000000072c80000 - 0000000072c88000: C:\WINDOWS\system32\msacm32.drv
(0000000072c90000 - 0000000072c99000: C:\WINDOWS\system32\wdmaud.drv
(0000000072f70000 - 0000000072f96000: C:\WINDOWS\system32\WINSPOOL.DRV
(00000000735f0000 - 00000000735f8000: C:\WINDOWS\system32\msyuv.dll
(0000000073620000 - 0000000073627000: C:\WINDOWS\system32\msdmo.dll
(0000000073aa0000 - 0000000073ab5000: C:\WINDOWS\system32\mscms.dll
(0000000073e40000 - 0000000073e44000: C:\WINDOWS\system32\KsUser.dll
(0000000073e70000 - 0000000073ecc000: C:\WINDOWS\system32\DSOUND.dll
(0000000074790000 - 00000000748ff000: C:\WINDOWS\system32\quartz.dll
(0000000074cb0000 - 0000000074cd3000: C:\WINDOWS\system32\oledlg.dll
(0000000075250000 - 000000007527e000: C:\WINDOWS\system32\msctfime.ime
(0000000075790000 - 00000000757fb000: C:\WINDOWS\system32\usp10.dll
(0000000075ec0000 - 0000000075ee1000: C:\WINDOWS\system32\MSVFW32.dll
(0000000076320000 - 0000000076325000: C:\WINDOWS\system32\MSIMG32.dll
(0000000076330000 - 000000007634d000: C:\WINDOWS\system32\IMM32.dll
(0000000076350000 - 000000007639a000: C:\WINDOWS\system32\COMDLG32.dll
(00000000765f0000 - 0000000076601000: C:\WINDOWS\system32\devenum.dll
(0000000076af0000 - 0000000076b1e000: C:\WINDOWS\system32\WINMM.dll
(0000000076bb0000 - 0000000076bbb000: C:\WINDOWS\system32\PSAPI.DLL
(0000000076bf0000 - 0000000076c1e000: C:\WINDOWS\system32\WINTRUST.dll
(0000000076c50000 - 0000000076c78000: C:\WINDOWS\system32\IMAGEHLP.dll
(0000000076f90000 - 000000007700f000: C:\WINDOWS\system32\CLBCATQ.DLL
(0000000077010000 - 00000000770e3000: C:\WINDOWS\system32\COMRes.dll
(00000000770f0000 - 000000007717b000: C:\WINDOWS\system32\OLEAUT32.dll
(00000000773a0000 - 00000000774a3000: C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\COMCTL32.dll
(00000000774b0000 - 00000000775ee000: C:\WINDOWS\system32\ole32.dll
(00000000778f0000 - 00000000779e4000: C:\WINDOWS\system32\setupapi.dll
(0000000077a50000 - 0000000077ae6000: C:\WINDOWS\system32\CRYPT32.dll
(0000000077af0000 - 0000000077b02000: C:\WINDOWS\system32\MSASN1.dll
(0000000077b10000 - 0000000077b32000: C:\WINDOWS\system32\Apphelp.dll
(0000000077ba0000 - 0000000077ba7000: C:\WINDOWS\system32\midimap.dll
(0000000077bb0000 - 0000000077bc5000: C:\WINDOWS\system32\MSACM32.dll
(0000000077bd0000 - 0000000077bd8000: C:\WINDOWS\system32\VERSION.dll
(0000000077be0000 - 0000000077c38000: C:\WINDOWS\system32\msvcrt.dll
(0000000077da0000 - 0000000077e4a000: C:\WINDOWS\system32\ADVAPI32.dll
(0000000077e50000 - 0000000077ee3000: C:\WINDOWS\system32\RPCRT4.dll
(0000000077ef0000 - 0000000077f39000: C:\WINDOWS\system32\GDI32.dll
(0000000077f40000 - 0000000077fb6000: C:\WINDOWS\system32\SHLWAPI.dll
(0000000077fc0000 - 0000000077fd1000: C:\WINDOWS\system32\Secur32.dll
(000000007c800000 - 000000007c908000: C:\WINDOWS\system32\kernel32.dll
(000000007c910000 - 000000007c9c9000: C:\WINDOWS\system32\ntdll.dll
(000000007e360000 - 000000007e3f1000: C:\WINDOWS\system32\USER32.dll
(000000007e670000 - 000000007ee91000: C:\WINDOWS\system32\SHELL32.dll

*----> Statusabbild für Threadkennung 0x46c <----*

eax=00000000 ebx=00000001 ecx=00000068 edx=00000002 esi=03be2410 edi=0356d000
eip=00aa637f esp=03a3fae0 ebp=03a3faec iopl=0 nv up ei pl nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000203

*** ERROR: Module load completed but symbols could not be loaded for C:\Programme\Media Player Classic\mpc-hc.exe
Funktion: mpc-hc
00aa635a 8bd1 mov edx,ecx
00aa635c 83e17f and ecx,0x7f
00aa635f c1ea07 shr edx,0x7
00aa6362 7465 jz mpc-hc+0x6a63c9 (00aa63c9)
00aa6364 eb06 jmp mpc-hc+0x6a636c (00aa636c)
00aa6366 8d9b00000000 lea ebx,[ebx]
00aa636c 660f6f06 movdqa xmm0,oword ptr [esi]
00aa6370 660f6f4e10 movdqa xmm1,oword ptr [esi+0x10]
00aa6375 660f6f5620 movdqa xmm2,oword ptr [esi+0x20]
00aa637a 660f6f5e30 movdqa xmm3,oword ptr [esi+0x30]
FEHLER ->00aa637f 660f7f07 movdqa oword ptr [edi],xmm0 ds:0023:0356d000=????????????????????????????????
00aa6383 660f7f4f10 movdqa oword ptr [edi+0x10],xmm1
00aa6388 660f7f5720 movdqa oword ptr [edi+0x20],xmm2
00aa638d 660f7f5f30 movdqa oword ptr [edi+0x30],xmm3
00aa6392 660f6f6640 movdqa xmm4,oword ptr [esi+0x40]
00aa6397 660f6f6e50 movdqa xmm5,oword ptr [esi+0x50]
00aa639c 660f6f7660 movdqa xmm6,oword ptr [esi+0x60]
00aa63a1 660f6f7e70 movdqa xmm7,oword ptr [esi+0x70]
00aa63a6 660f7f6740 movdqa oword ptr [edi+0x40],xmm4
00aa63ab 660f7f6f50 movdqa oword ptr [edi+0x50],xmm5
00aa63b0 660f7f7760 movdqa oword ptr [edi+0x60],xmm6

*----> Stack Back Trace <----*
WARNING: Stack unwind information not available. Following frames may be wrong.
ChildEBP RetAddr Args to Child
03a3faec 00520468 0356d000 03be2410 00000168 mpc-hc+0x6a637f
03a3fb94 00000178 00000178 00000400 00000200 mpc-hc+0x120468

*----> Raw Stack Dump <----*
0000000003a3fae0 00 d0 56 03 00 d0 56 03 - 10 24 be 03 94 fb a3 03 ..V...V..$......
0000000003a3faf0 68 04 52 00 00 d0 56 03 - 10 24 be 03 68 01 00 00 h.R...V..$..h...
0000000003a3fb00 98 fb ff ff e0 05 00 00 - 20 fa ff ff 99 00 00 00 ........ .......
0000000003a3fb10 38 ad 35 00 c3 00 00 00 - 30 fb a3 03 a0 fb a3 03 8.5.....0.......
0000000003a3fb20 68 01 00 00 c0 1b 6f 04 - 94 fb a3 03 00 00 00 00 h.....o.........
0000000003a3fb30 7a fe ff ff 2a 43 68 00 - 38 ad 35 00 80 fc a3 03 z...*Ch.8.5.....
0000000003a3fb40 86 01 00 00 00 00 00 00 - 00 02 00 00 80 57 97 01 .............W..
0000000003a3fb50 21 a5 53 00 c0 1b 6f 04 - 80 57 97 01 94 fb a3 03 !.S...o..W......
0000000003a3fb60 00 00 00 00 86 01 00 00 - 5c fc a3 03 a0 fb a3 03 ........\.......
0000000003a3fb70 e0 d4 49 cf 15 11 ce 11 - b0 3a 00 20 af 0b a7 70 ..I......:. ...p
0000000003a3fb80 00 00 00 00 01 00 00 00 - 70 61 97 01 03 00 00 00 ........pa......
0000000003a3fb90 b0 fb a3 03 f0 02 00 00 - 78 01 00 00 78 01 00 00 ........x...x...
0000000003a3fba0 00 04 00 00 00 02 00 00 - 00 02 00 00 38 4d 51 00 ............8MQ.
0000000003a3fbb0 70 61 97 01 80 57 97 01 - 6c fc a3 03 10 fc a3 03 pa...W..l.......
0000000003a3fbc0 6a d0 91 7c e4 fc a3 03 - 7a 16 00 00 e0 d4 49 cf j..|....z.....I.
0000000003a3fbd0 00 9e 55 03 5c fc a3 03 - 58 59 97 01 b8 fc a3 03 ..U.\...XY......
0000000003a3fbe0 9e 61 4f 00 c0 1b 6f 04 - 80 57 97 01 88 fc a3 03 .aO...o..W......
0000000003a3fbf0 00 00 00 00 86 01 00 00 - 5c fc a3 03 98 fc a3 03 ........\.......
0000000003a3fc00 cb a8 34 72 70 ec 9a 01 - 58 59 97 01 7a 16 00 00 ..4rp...XY..z...
0000000003a3fc10 00 00 00 00 00 00 00 80 - 00 00 00 00 00 00 00 80 ................

*----> Symboltabelle <----*
C:\Programme\Media Player Classic\mpc-hc.exe

This crash seems to be fixed in 1.4.1.2892!


But sometimes MPC-HC freezes when changing those VSync options during playback! Sound goes on but picture is frozen and I have to kill MPC-HC ...

[Dstruct]

-I got rid of the dysfunctional setting.

In 1.4.1.2892 it's (Renderer Settings/Output Range) back here!? It's set to 0-255 but always grayed out.



What happened to the Dither options in 1.4.1.2892? They are gone!?

[JanWillem32]

I can try to integrate a few of my changes. It's just that failing to get the YV12/IYUV/I420 to NV12 convertor working, is really stalling my progress. (This isn't my field of expertise, either.)

[Dstruct]

Ok. Didn't know your changes weren't official yet.

Will I get the crash http://forum.doom9.org/showthread.php?p=1474133#post1474133 back when your changes get build in?

[v0lt]

I see many posts about the problem with color on ATI.
If you turn on "Sharpen Complex 2" shader, then the bug becomes more noticeable.
1. norm1 (http://img405.imageshack.us/img405/1586/142824.png), bad1 (http://img405.imageshack.us/img405/7236/1412892.png)
2. norm2 (http://img291.imageshack.us/img291/6714/2833.png), bad2 (http://img171.imageshack.us/img171/5439/2840.png)
3. norm3 (http://img291.imageshack.us/img291/9247/oldi.png), bad3 (http://img291.imageshack.us/img291/2296/newwv.png)
Version 2833 is not a problem, in 2840 version of the problem is.

[tetsuo55]

That would be a pity to remove VMR7 renderless now because there is still a majority of people using XP and many many of them are running it on quite slow machines -compared to 'modern ones'-, so VMR7 renderless is the only way to get a smooth playback AND with subtitles.With janwillem's changes VMR9 should be lighter on resources than VMR7. there really is no reason to keep it.

Can you confirm?

[JanWillem32]

@v0lt: That's the regular chroma bug. http://forum.doom9.org/showthread.php?p=1463132#post1463132
I've also made a few pictures for the OP of that thread. I've discussed this problem a lot of times and it's a difficult thing to solve. I'm trying to get a few pixel shaders integrated into EVR-CP/Sync and VMR-9, to get chroma up-sampled properly for those that can spare the GPU cycles.
Those two renderers are the only two that even can up-sample chroma, the others simply don't do it.
For now, you can activate chroma up-sampling manually with my shaders. I wouldn't recommend using the default "YV12 Chroma Upsampling" shader at all.

[cca]

A question, mostly out of curiosity: Why the chroma upsampling bug doesn't happen with the regular EVR? Something different on Microsoft's default presenter?

[v0lt]

@JanWillem32
I have no problems (nvidia). But your words were heard. Solution is not great.

For now, you can activate chroma up-sampling manually with my shaders.
I downloaded shaders from here (http://forum.doom9.org/showthread.php?p=1474027#post1474027). Which shader you recommend?

[JanWillem32]

@cca: regular EVR is blurry, and does have the chroma bug from 4:2:2 to 4:4:4 on my hardware with regular builds.

@v0lt: Assuming for 4:2:0 input video (mixer output YV12, I420/IYUV or NV12):
very low end: 4÷2÷0 chroma blur for SD&HD video input on old and slow PS 2.0 hardware
low end: 4÷2÷0 to 4÷2÷2 intermediate Catmull-Rom spline4 chroma up-sampling for SD&HD video input on old PS 2.0 hardware + 4÷2÷2 Catmull-Rom spline4 chroma up-sampling for SD&HD video input on old PS 2.0 hardware
normal: 4÷2÷0 to 4÷2÷2 intermediate Catmull-Rom spline5 chroma up-sampling for SD&HD video input + 4÷2÷2 Catmull-Rom spline5 chroma up-sampling for SD&HD video input

I really have to re-design that naming scheme. More shaders are in the experimental phase, and it's already hard to keep them apart right now. The integrated ones will have to be split into HD and SD versions again, too.

[cca]

Finally the forums are back!

[SamuriHL]

Most excellent! We were getting a bit worried!!! :)

[Superb]

Btw, if you guys want to see the svn changes while SF.net's ViewVC is offline (due to the attacks), you can surf here:
http://sourceforge.net/apps/trac/mpc-hc/log/trunk

[cca]

Btw, if you guys want to see the svn changes while SF.net's ViewVC is offline (due to the attacks), you can surf here:
http://sourceforge.net/apps/trac/mpc-hc/log/trunk

many :thanks: for that link!

[MrHipp]

Could someone please help a newbei. What is the deal with 10-bit input (A2R10G10B10). Which decoder supports that output for MPEG2? Or it depending on the
hardware? I have an ATI Radeon 5450. Could someone please advice what is needed to get 10-bit input to work. BTW 10-bit output appears to work.

Thanks in advance.

[JanWillem32]

10-bit input will be removed, along with other broken features of the mixer.

[anuswara]

hello.
I just have installed mpc home cinema for the first time.
every time i open the player and load enyone kind of file the mpc tell me that directx (9???) end user runtime is
outdated.

on vista32 i have directx10.
I dont know if i can "update back" to dx9... I'm worry.
and sometime the mpc crashes.

what to do?

thanks a lot in advance.

[namaiki]

hello.
I just have installed mpc home cinema for the first time.
every time i open the player and load enyone kind of file the mpc tell me that directx (9???) end user runtime is
outdated.

on vista32 i have directx10.
I dont know if i can "update back" to dx9... I'm worry.
and sometime the mpc crashes.

what to do?

thanks a lot in advance.
Make sure to install the latest DirectX Runtimes (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en). (don't accidentally install the bundled Bing bar!!) Long story.

By the way, seeing as you have misunderstood the message that tells you to update the directx end user runtime, do you have any suggestions to make the error easier to understand for others?

[Midzuki]

http://www.google.com/search?num=20&hl=en&safe=off&q=%22index+of%22+d3dx9_41.dll&btnG=Search

then copy the damn DLL to the system32 folder.