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

[a_afra]

As it currently stands, MPC-HC color management forcibly adapts my custom Rec.709 gamma to 2.2, 2.35, or 2.4 which completely defeats the purpose of calibrating to a specialized gamma curve.

The whole purpose of color management is to display the same image regardless of the calibrated gamma or other settings. This is exactly what every other ICC color managed application (like Photoshop) does.

[JanWillem32]

@Dstruct: http://zp.lo3.wroc.pl/cdragan/d3dcaps.html The Japanese site for this stuff is more up-to-date but translations of technical terms is a bit difficult for most automatic translators. http://m.amatukami.com/~fport/cgi-bin/thmj/file/1257855049.html
@cyberbeing: Compiled a version with more relaxed detection settings, maybe this helps.

[Dstruct]

@Dstruct: http://zp.lo3.wroc.pl/cdragan/d3dcaps.html The Japanese site for this stuff is more up-to-date but translations of technical terms is a bit difficult for most automatic translators. http://m.amatukami.com/~fport/cgi-bin/thmj/file/1257855049.html

Alright, thanks!


Btw: Would it be possible to implement fast(er) Bilinear and Bicubic resizing algorithms in software? Especially with high resolution videos it seems that my GeForce 7600GS is too slow with the the Bilinear and Bicubic Pixel Shader algorithms. Dropped frames all the time :(


Currently only "Nearest Neighbour" mode is working fine here. Even the software "Bilinear" algorithm is too slow. CPU is a Intel Core 2 Duo E6700 (2x 2.66 GHz) and my display is running at 1920x1200px at 32bit.

[JanWillem32]

That's a common thing with older video cards: they have 2D clocks that are relative to their age. Use a tool to run your video card at 3D speeds or higher, and you can often double your processing capacity. My HD4890 has a 2D GPU clock of 500 MHz. Because of my shader stack, I run it at 640 MHz (with idle standard voltages). For me there's plenty of headroom left, too. My video card almost reaches a GHz with higher voltages on the core.
Many tools are available to set video card clocks and make a "gaming" profile, linked to a program (in this case MPC-HC).

[cyberbeing]

The whole purpose of color management is to display the same image regardless of the calibrated gamma or other settings. This is exactly what every other ICC color managed application (like Photoshop) does.
MPC-HC isn't a video editor, it's a video player. While it's nice to have an option to target gammas of 2.2, 2.35, and 2.4 these wouldn't match any BT.709 video mastering setup. Since it won't be the same as any image or video editor with a proper ICC managed BT.709 working space, what value do you see in it matching only itself?

As video playback is concerned, all lcms needs to do is gamut adaptions, correct the color temperature to D65, produce low deltaE values for all colors. With a native gamma setting, you would still produce the same image for anybody who calibrated to the same gamma target. The ideal solution would be the ability specify this target gamma in MPC-HC, but since doing so is somewhat impractical with non-powercurve gammas like BT.709, a native gamma option would be a good compromise.


@cyberbeing: Compiled a version with more relaxed detection settings, maybe this helps. http://www.mediafire.com/?7hb2utn68yii6i7

VMR9 FullFP now works again.
EVR-CP FullFP once gain produces corrupted output, hangs the graphics driver, and eventually BSOD.

Unless you find a way to fix EVR-CP FullFP, it seems you need different checks between VMR9 and EVR.

[Dstruct]

That's a common thing with older video cards: they have 2D clocks that are relative to their age. Use a tool to run your video card at 3D speeds or higher, and you can often double your processing capacity. My HD4890 has a 2D GPU clock of 500 MHz. Because of my shader stack, I run it at 640 MHz (with idle standard voltages). For me there's plenty of headroom left, too. My video card almost reaches a GHz with higher voltages on the core.
Many tools are available to set video card clocks and make a "gaming" profile, linked to a program (in this case MPC-HC).

I think I'll get a passive Nvidia GT 430 next month. Hopefuly it will have enough power for it. The only shaders I'm running are the resizing algorithms.


Now I just watched a movie (1280x570, 23.98fps) with "Nearest Neighbour" and enabled color management and enabled "HalfFP" at 1920x1200. Worked fine for about half a hour and then suddenly all gets slowed down and many many frames got dropped. Stop+Playback again didn't fix it immediately. Waited some minutes (writing this anser here) -> playback => fine again.

Weird :(

[Dstruct]

While it's nice to have an option to target gammas of 2.2, 2.35, and 2.4

Aren't the options in MPC "source" gammas? Target = display/profile. Wrong?

[JanWillem32]

Aren't the options in MPC "source" gammas? Target = display/profile. Wrong?
They are the reception gamma values for the incoming images. The color management is handled in the final pass, just before dithering.

It sounds like you have an overheating problem, can you clean your case and then check temperatures?

[a_afra]

MPC-HC isn't a video editor, it's a video player. While it's nice to have an option to target gammas of 2.2, 2.35, and 2.4 these wouldn't match any BT.709 video mastering setup. Since it won't be the same as any image or video editor with a BT.709 destination profile, what value do you see in it matching only itself?


Studio monitors are calibrated to 2.2-2.4 gamma, so that's the way to display videos in MPC-HC, or any other video player/editor.

[Dstruct]

It sounds like you have an overheating problem, can you clean your case and then check temperatures?

Good hint. GPU is at 104°C (sounds too hot right?) and CPU at 58°C.

[JanWillem32]

That's very much too hot, those temperatures can expand and damage the little metal parts inside and beneath the chip. My GPU keeps stable on air at maximum fan speed at 76 °C.

[hoborg]

Hi.
I am not sure if somebody already reported this:

Start any video - press CTRL+ALT+DEL and lock the computer then unlock. MPC-HC will freeze.
This doesn't happend if i play video directly in Graphstudio - this pointing that problem is in MPC-HC.exe.

[Virtual_ManPL]

Are someone working on fixing system hanging and video stutter bugs when playing HD movies on Win 7 + EVR CP ?

It's big pain in the ass for user like me, who migrate from XP to 7 and see this... :p

NVM, the cause was Full Floating Point Precision settings set to default in optimal set
Also the same hanging and stuttering produces 2 10-bit options and Half Floating Point Precision as I see

[cyberbeing]

Studio monitors are calibrated to 2.2-2.4 gamma, so that's the way to display videos in MPC-HC, or any other video player/editor.

That is incorrect.

Studio monitors are calibrated to a scaled Rec.709 gamma averaging around 2.4-2.6, so that would be considered the 'correct' way to display videos in MPC-HC, or any other video player/editor in a darkened environment.

HD Video Mastering: Rec.709 Gamma
Blu-ray Disc: Rec.709 Gamma
HDTV Broadcasts: Rec.709 Gamma

Windows OS Native Gamma: 2.2 or 2.4 Gamma power-curve
Mac OS Native Gamma: 1.8 or 2.4 Gamma power-curve
Pictures: sRGB Gamma curve or 2.2 (AdobeRGB1998) Gamma power-curve

If you have a sRGB picture, you want to display it with a sRGB Gamma curve.

If you have a AdobeRGB1998 picture, you want to display it with a 2.2 Gamma power-curve.

If you have a Rec.709 video, you want to display it with a Rec.709 Gamma curve... not a power-curve.

If you don't already realize, a Gamma power-curve is very different from the Rec.709 Gamma. While a Gamma power-curve has the same gamma for all values light to dark, a Rec.709 Gamma changes it's gamma as it goes from light to dark. It should be common sense to view Rec.709 video with a Rec.709 Gamma.

[Dstruct]

That's very much too hot, those temperatures can expand and damage the little metal parts inside and beneath the chip. My GPU keeps stable on air at maximum fan speed at 76 °C.

Yeah, just cleaned my case (was really dusty). But the GPU temperatre deosn't got down (still climbs up to ~110°C). CPU got down to ~42°C ...


Let's see how the new GT 430 (also passive) will work ...

[cyberbeing]

VMR9 FullFP now works again.
EVR-CP FullFP once gain produces corrupted output, hangs the graphics driver, and eventually BSOD.

Unless you find a way to fix EVR-CP FullFP, it seems you need different checks between VMR9 and EVR.

@JanWillem32

Since you didn't comment on the above, what is your plan of action? Is another test build incoming?

Since I'll be going to bed soon (2:45AM now), it would be nice to get some closure while you are still around.

Edit: Oh well, sleep time.

[Dstruct]

@cyberbeing: Compiled a version with more relaxed detection settings, maybe this helps. http://www.mediafire.com/?7hb2utn68yii6i7

With this build I no longer can move the MPC window via click+drag on the video picture. Hand cursor is displayed but I can't drag the window anymore ....

FIXED (1.4.1.2891)

[a_afra]

If you have a Rec.709 video, you want to display it with a Rec.709 Gamma curve... not a power-curve.

If you don't already realize, a Gamma power-curve is very different from the Rec.709 Gamma. While a Gamma power-curve has the same gamma for all values light to dark, a Rec.709 Gamma changes it's gamma as it goes from light to dark. It should be common sense to view Rec.709 video with a Rec.709 Gamma.


If you don't already realize, the Rec. 709 curve is the encoding curve (which we can safely ignore), and not the decoding/viewing curve. You don't have to believe me: http://www.poynton.com/notes/PU-PR-IS/Poynton-PU-PR-IS.pdf

Anyway, decoding video with the Rec. 709 curve is obviously too bright and noisy. But this was already explained on this thread a few days ago.

It seems that many people think that my color management implementation is completely incorrect and confusing. The solution is simple: I suggest considering to throw it out.

[djsolidsnake86]

with latests builds can't move the video windows with the mouse :(
solutions please?

[Mercury_22]

with latests builds can't move the video windows with the mouse :(
solutions please?

If you want you can use my builds (http://d01.megashares.com/dl/933a3fc/MPC-HC_2887.zip) : reverted Revision 2866 and changed the default Play/Pause mouse key to Middle Down from Left Down

[janos666]

If you have a Rec.709 video, you want to display it with a Rec.709 Gamma curve... not a power-curve.

It should be common sense to view Rec.709 video with a Rec.709 Gamma.

Did you actually test it subjectively?
A pure-power viewing gamma gives me much better subjective results than an inverse-Rec709-Encode TRC. It looks much cleaner because that's how it works: the encoding curve filters the sensor noise when decoded with pure-power curves.

But show me a high-end HDTV with a scaled inverse-Rec709-Encode curve and I will believe your. You won't find any, I guess...
The THX certified HDTVs produce a pure-power TRC in THX modes. (And they usually have a gamma value of 2.2 by default, mostly because 2.35 or 2.4 is very hard to achieve with some LCDs.)

But it's enough to think about the fact that it's nothing else but a legacy CRT compatibility thing. -> Do you think that old analog CRTs without any additional post-processing produced a scaled inverse-Rec709-Encode TRC? :p

[bobdynlan]

Are someone working on fixing system hanging and video stutter bugs when playing HD movies on Win 7 + EVR CP ?

It's big pain in the ass for user like me, who migrate from XP to 7 and see this... :pNVM, the cause was Full Floating Point Precision settings set to default in optimal set
Also the same hanging and stuttering produces 2 10-bit options and Half Floating Point Precision as I see
Not letting this one slide because of the "for user like me" - not plural but with 75% effect of that, you should become a politician :devil:
PC details for bug reporting: E6550 2,33GHz@3,5GHz (on default VCore) + 4GB DDR2 + GF8600GT@GTS on 7 (64bit)
The real issue might be your (unstable) overclock, why have you blamed MPC-HC first? How's 3dmark 06's Deep Freeze test on your system? If heat is not an issue, try increasing your GPU voltage (hardware mod required - like the simple pencil mod). Also note that 7 drivers, especially 64-bit ones, are more strict than the XP ones, and also put a heavier load. Think about MPC-HC as any other 3D app, anything you check in the gui can have a performance impact.
People with onboard gpus or old cards like 7600GS, 8600GT (@GTS or not), should not activate these advanced functions in the first place.

So MPC-HC, go on with exposing lots of features in the gui and gray them out for known hw/drivers that do not work, maybe that will be enough push for users to upgrade, or scream at the manufacturers. I really can't understand how they can get away with these bugs. What if CPU manufacturers were doing this as-well?

[cca]

I'm testing mixer settings to try to solve the black screens problem on opening. I've disabled the "16-235" setting, because it harms quality and it uses the wrong levels for chroma. Also not working: D3D Fullscreen GUI Support and Force 10-bit RGB Input.
Currently the mixer can only do 8-bit, full range RGB. I'm trying hard to solve that. In the mean time, DXVA and many external codecs will correctly output 4:2:0 chroma, and some software codecs, like the internal ones are force-mixed to 4:2:2 (with the ugliest form of chroma blurring ever). Those who care to up-sample chroma, might sometimes have to switch between up-sampling from 4:2:0 in one occasion and from 4:2:2 in the other. Only the three EVR types are affected, the other renderers don't up-sample chroma by default.
The other thing is my attempt at temporal dithering. Later on dithering will probably need to become user-selectable, including the allowed noise levels. These builds use use a medium level of 8/256 or 8/1024.

This is getting confusing, the last recommendation was to use 16-235, now that turns out defective? And like most users, I don't plan on switching shaders per video, so everything is forced to NV12 in my case so the upsampling shader chain is constant. I do not use any internal software decode because I cannot select output color space etc, I use only the H264 DXVA decoder.

Quality is nice, but let me remind you, the average user just wants it to work!

[JanWillem32]

@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

[Virtual_ManPL]

Not letting this one slide because of the "for user like me" - not plural but with 75% effect of that, you should become a politician :devil:
PC details for bug reporting: E6550 2,33GHz@3,5GHz (on default VCore) + 4GB DDR2 + GF8600GT@GTS on 7 (64bit)
The real issue might be your (unstable) overclock, why have you blamed MPC-HC first? How's 3dmark 06's Deep Freeze test on your system? If heat is not an issue, try increasing your GPU voltage (hardware mod required - like the simple pencil mod). Also note that 7 drivers, especially 64-bit ones, are more strict than the XP ones, and also put a heavier load. Think about MPC-HC as any other 3D app, anything you check in the gui can have a performance impact.
People with onboard gpus or old cards like 7600GS, 8600GT (@GTS or not), should not activate these advanced functions in the first place.

So MPC-HC, go on with exposing lots of features in the gui and gray them out for known hw/drivers that do not work, maybe that will be enough push for users to upgrade, or scream at the manufacturers. I really can't understand how they can get away with these bugs. What if CPU manufacturers were doing this as-well?
:p

Overclock have nothing to do with it.
I have stable system. CPU tested with IntelBurnTest 2.5 for 2 day. GPU now isn't overclocked, because I don't use SMarks or play games anymore.
Even if I run on default CPU clock, hangs and stutters still occur.

I only don't know why this option is default in optimal mode, when it have serious issues like this.

[cca]

@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 not saved yet to a .INI file or the registry.
MSVS 2010 versions only, based on v1.4.1.2891
x86: http://www.mediafire.com/?br8ask6l37977wo
x64: http://www.mediafire.com/?0nqu8gy9exnq375
Damn, is anything working right on that mixer? Needs a lot of work obviously, for now I'll just try to find an acceptable setup for my regular playback.

[cca]

Tried the test build with Dithering build in. My ATi 4850 seems to have no problems with it, not sure what benefit the higher levels produce, if any. Level 32 produces artifacts like artificial noise.

[Hera]

Is there any reason to have half-borked SWF support in MPC? Does anyone even use that?

Is there any way to have the most compact view still have the glass border, like in WMP?

NVM, the cause was Full Floating Point Precision settings set to default in optimal set
Also the same hanging and stuttering produces 2 10-bit options and Half Floating Point Precision as I see

I was informed that this is due to weak hardware.

[Virtual_ManPL]

Can be true, GF8600 is not high-end or now even mid-end GPU,
but still works fine with DxVA or CUDA

[Dstruct]

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


"28" as default? Much too noisy for me. "8" is ok. What's the meaning of those numbers?


In previous builds there was an "EVR color range" menu in the Renderer Settings. It was always set to "0-255" but was grayed out. What was it for and why got it removed? At the same place I now have "Dithering levels". My Nvidia driver settings are set to "0-255".

[G_M_C]

Isnt it a good idea to hold of on posting these test-builds for now ?
They raise more questions than they solve, and also features added in one version are lost on the next.

My wish would be that a sound working alpha / beta is worked on, and posted. From there an inventory of of all the missing pieces can be made and addressed. The current way makes everything more unclear, for users and developers alike.

Also i get the feeling that all work that is done now, seems to stem from,- or flow out of the fact that the mixer seems to function insufficiently. Am i right in this conclusion ?

[JanWillem32]

We don't have the luxury of having any alpha- or betatesters, so I went ahead and posted modified builds before submitting major code changes to the SVN. I'm mostly involved with core rendering stuff that can break a lot of functionality. I really don't mind the comments and questions, I only want to submit decently working code in the end.
The mixer is indeed a big problem. Everything has to pass trough 8-bit, full range RGB. From there, it's then modified to suit the first surface of the renderer. This method is very bad for maintaining as much precision as possible in the transfer from file to the renderer.
Secondly, for some reason, EVR renderers with the internal software codecs convert all 4:2:0 chroma sub-sampled media to 4:2:2. It wastes resources on older machines and the conversion quality is rather bad. Other renderers don't modify chroma.

@Dstruct For renderer settings: http://sourceforge.net/apps/trac/mpc-hc/wiki/New_Renderer_Settings
I posted about the level selection item earlier. The level selection item "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.
The default dithering level is non-defined, so 0 is assumed. You can test this by deleting the registry DWORD value "VMRDitheringLevels" in "HKEY_CURRENT_USER\Software\Gabest\Media Player Classic\Settings".
http://en.wikipedia.org/wiki/Dither Dithering is a noise method to hide banding. I adapted "semi-random colored surface noise" to a form relative to the 8-bit or 10-bit display output. The levels are the maximum allowed color differences in x/256 (8-bit display output) or x/1024 (10-bit display output).

[Dstruct]

@Dstruct For renderer settings: http://sourceforge.net/apps/trac/mpc-hc/wiki/New_Renderer_Settings
I posted about the level selection item earlier. The level selection item "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.

Ok, but why are these options not there anymore in the latest build? Because I'm on XP (without EVR renderer) and the latest build has a check for this?


Btw: With my Nvidia card it seems "Wait for flushes" needs to be enabled too (otherwise the image becomes "skewed" vertically). Not sure if this should be changed by default?


The default dithering level is non-defined, so 0 is assumed.

Weird because I've just installed your latest build and it was set to "28".

[JanWillem32]

-I got rid of the dysfunctional setting.
-It seems you have a tearing problem. Try some VSync settings to see if they work for you. "Wait for flushes" is expensive on GPU cycles, compared to regular VSync settings. You can also try the D3DFS mode, that often helps to control VSync as well. There's also "alternative VSync" that allows VSync offsets, but many systems really don't need it enabled at all. Good luck with testing a few settings.
-I used the same internal number range as the EVR levels items used before. That might influence some settings once, when the registry key is generated.

[Dstruct]

-I got rid of the dysfunctional setting.

Alright.


It seems you have a tearing problem. Try some VSync settings to see if they work for you. "Wait for flushes" is expensive on GPU cycles, compared to regular VSync settings. You can also try the D3DFS mode, that often helps to control VSync as well. There's also "alternative VSync" that allows VSync offsets, but many systems really don't need it enabled at all. Good luck with testing a few settings.

Don't like D3DFS mode (as I often need the normal non-maximized window). Can't we have both modes combined so that only when entering fullscreen the D3DFS mode is activated?


I have all VSync and GPU Control settings enabled. Seems to give me the best motion of the video. Already noticed that the "Wait for flushes" option is heavy on the GPU. But with it disabled the picture becomes like devided into two parts (vertically) and the lower part of the image is displayed a bit ahead of the upper part. The ratio of the size of the upper part vs lower part also is "moving" in this case. Can be seen very good with the red Tearing test lines. Only with "Wait for flushes" enabled I'm getting straight vertical lines.


-I used the same internal number range as the EVR levels items used before. That might influence some settings once, when the registry key is generated.

Ok, that might explain it. Thanks for your time!

[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


FIXED (1.4.1.2892)

[a_afra]

The higher dithering levels can be a bit noisy, just try out some banding samples and use whatever settings you like.

I don't see why would this heavy noise "dithering" be any better than my implementation of the high quality void-and-cluster dithering algorithm (it's comparable to Floyd-Steinberg but much faster and can be trivially parallelized). The noise added through dithering should not be greater than 1 level!

[a_afra]

The mixer is indeed a big problem. Everything has to pass trough 8-bit, full range RGB. From there, it's then modified to suit the first surface of the renderer. This method is very bad for maintaining as much precision as possible in the transfer from file to the renderer.


Yeah, you can't have maximum precision with EVR, but I don't think it's that bad. I don't really like the direction the EVR-CP renderer is going. I love high quality video, but EVR is simply not the best way to achieve that, no matter how many hacks you use. If you want to achieve the best results, you should use madVR or write a new renderer from scratch which is not based on EVR/VMR. Yes, you need more processing power in that case, but if you want the highest quality, it's inevitable, even if you stick with EVR and DXVA.

I don't think it's a good idea to sacrifice the stability, performance, hardware support, and elegance of the "original" EVR-CP for a slight increase in quality. Most users don't care about minor banding, suboptimal chrome upsampling, and tons of dithering algorithm settings. They just want to enjoy the movie. Anyway, those artifacts are not that easy to observe if you're watching a film, instead of staring at test patterns from 2 inches.

Obviously I do care about top-notch quality, but IMHO EVR is not the proper way to get there. It's not worth the trouble.

[Vincent Vega]

this is a small sample file made by my TV viewing application:
http://www.mediafire.com/?x294obqj404fs8j

i have a problem playing such files: mediainfo says video stream is interlaced, however most media players (mpc-hc included) don't recognize this fact, and seem to output video from splitter as progressive, hense there is no proper deinterlacing happening downstream in the graph. with mpc-hc internal splitter and ffdshow+yadif i can only get deinterlacing to start working by checking "Process frames flagged as progressive".

pls help me understand whose fault it is with such files: muxer's in my TV app possibly forgetting to put some additional flag in mp4, or mpc-hc splitter's?

[nevcairiel]

Splitters don't usually mark the stream as interlaced, its the video decoders job to do that.

[Vincent Vega]

ok thanks, than lets add third candidate to be blamed: video decoder.

anyways question still remains.. TMT3, and of course the TV app's own built-in player were the only two players that knew this video requires deinterlacing. others just showed jaggies

[JanWillem32]

@a_afra: Your ditherer is still the set with "optimal". For "default" no dithering is used. The temporal noisy type uses quantized, colored noise to mask banding. It's by no means a default setting, just an added feature by request to use a different type of end-stage handling.
Later on, I'm also planning to add the option to convert to correct limited Y'CbCr ranges, available with both VMR-9 and EVR-CP, and maybe some other common end-stage processing items.
The DirectX 9 renderer and allocator-presenter is shared between VMR-9 and EVR-CP. So in fact, I'm actually trying to add features to both.

To tell an inside "secret", I've requested the complete removal of all DirectX 7 items. Those items lack maintenance, have some evident errors, and nobody wants to work on it. I'm waiting on the acceptance for that, before starting modernization of DirectX 9 items. In line for modernization are: the subtitle renderer that shares 90% of the same code with the DirectX 7 type, the OSD renderer that has a font and rasterizing capacity from the last millennium (it can't even do anti-aliasing), the mixer is handled in software mode with ancient non-DirectX methods, and most of all, the ugly chroma blur that's currently forced on all EVR renderers. All those things influence both quality and performance.
I'm quite okay with moving away from EVR. The only thing used for presentation is the alpha-blending capacity, that's easy to replace by just doing alpha blending in the rendering process and export the single-layer surface to the front buffer. Apart from that, only the EVR mixer is used. If the development team can gather enough people to help with coding, alpha- and betatesting on the development of a mixer, I'll happily help with the coding of it.
The aim is to still keep all items in the legacy DirectX 9 type for now, but if things go well, I can help out with DirectX 11 migration.

You are right about the ease of use of the program. I think there should be a guide to tell people what the additional features are for. The "default", "optimal" and maybe a few "advanced" presets should be good enough for most people that just want proper playback.

@Dstruct: D3DFS mode requires re-initialization of rendering on the video card and in software, that takes a few seconds. It's one of the reasons why it's not the default fullscreen mode. The first main advantage of this mode is that it disables the rendering of the Windows desktop interface, so that the CPU and GPU can spend more processing on other tasks.

[clsid]

Wouldn't it be a better/safer idea to implement a completely new renderer? That could then be marked as experimental and get all the fancy new features.

The current renderers can then be kept as they are, of course with the recently added (broken) new features being removed or fixed. That way we at least have "stable" renderers available during the development of a new one. Plus we continue to have renderers that work on older versions of Windows. Remember that XP still has over 50% market share and that is expected to still be around 30-40% a few years from now.

[tetsuo55]

Hi Clsid,

Apart from any potential work on a directx11 renderer, the stuff janwillem intends to work on will work on XP and up.

And remember, as a_afra pointed out, its all about balancing bugs here.
The renderers are broken in many ways, its just the question of how noticable is the bug, to me it looks like janwillems's work (which is all beta) is trading many old bugs for few new ones.

[JanWillem32]

@clsid Very much indeed. If versions with a custom mixer, integrated EVR sync or entirely separate renderers are developed, they should be added as a separate renderer in the options list.
As long as items are nothing more than add-on modules that can be switched on and off (most of them even during playback), no new enumeration is required. The "default" preset should still be the most useful setting for older hardware (most extra's disabled). The "optimal" preset should use a lot more functions, maybe some variants of this preset can be added, too. Advanced users will like to set custom settings, and I think it's a good idea to centralize the rendering, shader and mixer settings. Saving custom presets for advanced users is a welcome feature to manage different settings.
I'm indeed trading off things, but at least I'm willing to help remove items that don't work properly in the first place. I do intend to make the complete rendering process lighter for all renderers on default settngs. The most evident fixes of that were the over-filtering bug (still present in VMR-7), and the .5 pixel offset problem that didn't allow 1:1 pixel mapping for the subtitles and OSD.

[lukanz]

hy
i just wonder if its possible to use the BASS from www.un4seen.com with Media Player Classic just like some other player do .

thx

[janos666]

What about a DirectX 11 renderer? :rolleyes:

The only limitation is that it requires Vista+ but other than that:
- It supports almost every cards (starting from Gefoce FX and such)
- Very flexible (both very modern and very old cards can automatically work with their full capabilities)
- It will be up-to-date for a long time if it's not the last DirectX version ever (before software rendering comes back)

It would be very exciting to see what a DX11 renderer is capable to do with DX11 cards.

[JanWillem32]

If I would start on a DirectX 11 renderer, I would keep the minimum functions at the PS/VS 4.0 base profile levels of DirectX 10. That way people with DirectX 10 hardware can still use it. That doesn't require any compatibility mode. It's not possible to make it work with DirectX 9 hardware, unless you add specific compatibility modes for that.
I'm wondering how a DirectX 11 2D renderer would perform, as well.
PS version 4.0 (DirectX 10.0) is what I build my first pixel shader on. I used it to color a 3D teapot model. Of course, I advanced my skills a lot since then. I learned quite a few tricks and functions available in DirectX 10 and 11 rendering.
DirectX 10 and 11 modes also eliminate the problem of having to do the annoying .5 pixel vertex adaptations of DirectX 9 in 2D mode.
It does require expanding the development team, because we are really short on people to even help out with basic alpha- and betatesting. It would be very hard to create it all by our current development team.

You are talking about software rendering. It might surprise you, but except for the final output that's always done by hardware, every DirectX hardware audio/video function has a duplicate software emulation mode. Within MPC-HC, most of the video functions rely on hardware rendering on the video card. There might be some software modes that could be used in the renderer, but currently I don't see any renderer functions that would be logical to render in software mode. If a video card is unable to handle some advanced function, the entire system is generally too weak to handle it in software mode, as well.

[cyberbeing]

Anyway, decoding video with the Rec. 709 curve is obviously too bright and noisy. But this was already explained on this thread a few days ago.

The native Rec.709 curve is way to bright (with a gamma that averages ~1.94). This is why you scale the curve with a power function of around ~1.2 to meet viewing conditions like Argyll CMS does. In this way you maintain the same properties of Rec.709 curve but with a much more acceptable average gamma like 2.4. The technical data in the pdf document you linked supports this, but the author favors the idea of instead approximating the Rec.709 curve with a gamma power-curve, under the assumption that a power-curve is close enough to Rec.709 to be acceptable.

Scaling a Rec.709 curve with a power function is the optimal solution, but is not widely supported.

Using a ~2.4 power-curve is the compromise solution which works well enough for most people, and much easier to support if trying to standardize something (the purpose of the paper you linked).

Did you actually test it subjectively?
A pure-power viewing gamma gives me much better subjective results than an inverse-Rec709-Encode TRC. It looks much cleaner because that's how it works: the encoding curve filters the sensor noise when decoded with pure-power curves.
Yes, I have tested it subjectivly. A scaled Rec.709 curve gives more pleasing results then a power-curve to my eyes. Because of the nature of the Rec.709 curve it brings out more detail in shadows (where it has a lower-gamma then avg) and highlights (where it has a higher-gamma then avg).

But show me a high-end HDTV with a scaled inverse-Rec709-Encode curve and I will believe your. You won't find any, I guess...

For high-end HDTVs which have a full-cms system, an ISF tech should be capable of approximating a scaled Rec.709 curve and some do (from what I've read on avsfourm in the past). It's my understanding that most HDTVs use a 2.2 gamma.

But it's enough to think about the fact that it's nothing else but a legacy CRT compatibility thing. -> Do you think that old analog CRTs without any additional post-processing produced a scaled inverse-Rec709-Encode TRC?

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.

__________

That said, I'm a bit unsure how this turned into a gamma discussion. Please let's go back to the issue at hand. If I use my 2.2, 2.35, or 2.4 ICC profile, all is well since MPC-HC has presets for those. If you use any gamma other then 2.2, 2.35, 2.4 and want to keep that gamma at display, MPC-HC doesn't support this and will adapt the gamma to one you don't want.

Is there some problem with implementing support of scaled Rec.709 gamma or just using the display gamma specified in the ICC profiles? Just take a look at the Argyll CMS source code and match how it deals with Rec.709 scaling with ambient light measurements. You could add presets like Rec.709 (1 lux ambient), Rec. 709 (32 lux ambient), Rec. 709 (64 lux ambient), and Rec. 709 (128 lux ambient) to the already existing power-curve presets.
__________

MSVS 2010 versions only, based on v1.4.1.2891
x86: http://www.mediafire.com/?aiemgnfoc3seemr
x64: http://www.mediafire.com/?lbbyod3gjvb637r
EVR FullFP still semi-hangs the graphics driver with that build.
VMR9 FullFP still works.

If EVR FullFP can't be easily fixed, we need a workaround so people don't BSOD their PCs by mistake.

[Dstruct]

@a_afra: Your ditherer is still the set with "optimal". For "default" no dithering is used. The temporal noisy type uses quantized, colored noise to mask banding. It's by no means a default setting, just an added feature by request to use a different type of end-stage handling.

Shouldn't a_afra's ditherer also be listed under "Dithering Levels" then? At the moment it's a "hidden" setting :(