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.

[anuswara]

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?

sorry. the error was easy to understand. but I wonder that i have to download dx9 on my pc bundled with dx10 and therefore I worried for my OS..conflict or so ;-)
now I have to pluck up the courage to do this install.

thanks.

[nevcairiel]

DX9, 10 and 11 can life happy on the same system. Alot of games also ship those DX installers because they need a feature that was not in the initial version of DX9, like MPC-HC does.

[anuswara]

thanks a lot nevcairiel

[hissatsu]

@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.

Ah, thanks. I had Full Floating Point enabled.

[JanWillem32]

I coded a bit and I played with the compiler settings. The builds are slightly faster and smaller, but unfortunately not sexier than my previous ones (we really need to do something about that GUI).
This should be working better in the case of NV12 output from software codecs in EVR. De-interlacing for NV12 input and conversion where needed has mostly been fixed.
I made complete packages this time. These are compiled with MSVS 2010, and deviated from build r2911.

[cca]

@JanWillem32

Got an error about missing "mfc100u.dll" , can you make a static compile?

EDIT: OK, will get the redistributable and try the x86 build.

[MrHipp]

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

Could it be due to the fact that the filters don't support
MEDIASUBTYPE_A2R10G10B10?

[mark0077]

Has anyone noticed lately or can anyone confirm that with mpc-hc open, and when another file is loaded that usually opens in mpc-hc, mpc-hc just gives a little flicker and continues on with the currently loaded file, rather than opening the newly selected one. If anyone can confirm I'll start going back through mpc-hc versions to find the cause.

Aswell as this, mpc-hc doesn't seem to send the stop / quit signal, well at least reclock isn't getting it. I use reclock (with madVR) to auto change refresh rate and I have sent output from the vbs script to a text file to see what messages are going accross. I had my TV at 50hz, opened a 23.976hz movie, see output below where reclock went to state yellow and set my screen to 23.976 hz. I double clicked the fullscreen window to get out, to close the player. I then see another yellow and a stop signal, two more yellows but no stop or quit at the end when I exit mpc-hc so my desktop gets left at 23.976 hz :) Not a big deal but isn't it upto mpc-hc to send these signals or is it the video renderer?

YELLOW 23
YELLOW 23
STOP 50
YELLOW 23
YELLOW 23

[JanWillem32]

@MrHipp: A2R10G10B10 can be connected, but only if the video decoder and mixer both support it (rare). The renderer can most certainly handle it. It's best not to do any kind of colorspace conversion, other than bit-reordering before the mixer. That's why I added the support for NV12. The mixer often refuses pure planar types like YV12 and I420/IYUV. The semi-planar NV12 is bit-compatible, easily converted from those types and usually accepted by the mixer as a format for 8-bit 4:2:0 Y"CbCr.
@mark0077: MPC-HC can add things to the playlist... Maybe that's what you mean with your first item?

[cca]

@JanWillem32: At first glance the only thing I noticed using your latest build was that the mixer is outputting NV12 when fed with NV12. Is there something specific I can test and expect a difference?

[mark0077]

@mark0077: MPC-HC can add things to the playlist... Maybe that's what you mean with your first item?

Yeah that never happened before though. I mean I have mpc-hc in the quick launch area in windows 7, so with one movie playing, I often go and right click the mpc-hc icon to see the list of recently played items, and click one. Clicking the already playing movie or any others just makes mpc-hc flicker. This never happened in the past.

Just now I had two instances where I clicked a movie in the recent list and mpc-hc flickered and just crashed... Maybe its unique to this windows 7 feature?

[JanWillem32]

@cca: You could experiment with the different output formats, interlacing flags, and priority settings from ffdshow tryouts. Not all output media types may be accepted by the EVR mixer. Don't forget, the settings in the video card control panel do matter, even when using software decoding. (So does the type, age and brand of your hardware.) This is especially true for the advanced deinterlacing settings.

@mark0077: I'm not familiar with this problem, or taskbar programming functions. The best we can do in such situation is file a report on trac, and set up a test. I can't replicate this problem myself, but I'm running with different soft- and hardware. Please go trough your settings, or even delete the entire settings regkey. If that doesn't help, we can try to trace and solve things from the program's side.

[mindbomb]

how does one use the audio switcher to downmix audio?

I am confused as to how to use the custom channel mapping feature. I just want a simple stereo downmix.

[JanWillem32]

For DTS and DD there's often the downmix options from the decoder, but else you will have to send the audio trough a mixer. You can try to use the internal channel mapper, but that doesn't set a lower volume. If you want that, you can use ASIO programs, or connect to the audio renderer of ffdshow tryouts to mix.

[janos666]

@Jan
May be it's only me but the custom pixel shaders don't seem to work with your latest test build (x86). I have your chroma upsample shaders in the "combine" box but Ctrl+P doesn't do anything (except the OSD indication ON/OFF).
Should I clear the shaders and readd them?

And may be it depends on the AMD driver version but I have the "black screen on exit" now with enabled Aero too. (I only had it with the "disable Aero" option in the past.) [This is the "10-bit output black-screen", not the "unsupported format" one.)

[JanWillem32]

Do you have one of the four " toggle"/"disable" options enabled in the pixel shader menu? That's the only thing I can think of. If the shader compiler says that a script compiles and you have a video card capable of that level, it should work. I've just used my regulars to watch a video, and everything worked fine. Also "invert" still activates on every hardware PS level for me.
The black screen is indeed annoying, but I haven't found anything but reloading the display driver to be working. I'm still looking for a function or call that can refresh the screen on exit. I like 10-bit video too, but a hotkey to reaload the driver isn't ideal for me either. This problem is really old, by the way. The very old types that had the former working 10-bit output working, did give me the same problem with the black screen on exit.

[Fadeout]

I confirm that going from 1.4.2833 to 1.5.1.2910 switched the default display from RGB32 to NV12 and breaks chroma upsampling.

This means that by default now the players produces worse video quality. What's the rationale behind this? Why breaking stuff that was working?

[hoborg]

Hi.
What happend with changelog (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log)?
Any alternative?

[MrHipp]

@MrHipp: A2R10G10B10 can be connected, but only if the video decoder and mixer both support it (rare). The renderer can most certainly handle it. It's best not to do any kind of colorspace conversion, other than bit-reordering before the mixer. That's why I added the support for NV12. The mixer often refuses pure planar types like YV12 and I420/IYUV. The semi-planar NV12 is bit-compatible, easily converted from those types and usually accepted by the mixer as a format for 8-bit 4:2:0 Y"CbCr.
@mark0077: MPC-HC can add things to the playlist... Maybe that's what you mean with your first item?

If NV12 is offered as input to the mixer, wouldn't the offered output format be one of D3DFMT_X8R8G8B8/ D3DFMT_A8R8G8B8? Making 10 bit input impossible?

[JanWillem32]

@Fadeout: It was only chroma blurring from 4:2:0 to 4:2:2, anyway. The quality was bad, and the colorspace conversions were done with 8-bit integer software mode. It's too taxing on low-end CPU's to do this kind of thing, or any other real-time video modification for that matter. For mainstream and high-end PC's, better conversion quality can be reached when using the complete surfaces of 10-, 16-, or 32-bit RGB and using the shadercore of the GPU.
This is just one of the steps necessary to lower the minimum requirements of video playback on EVR. On the other hand, I want to line the renderer up for integrating shaders, to do a few mixer tasks.

@MrHipp: After modifying the mixer settings and debugging, it seems that the mixer will now take the surface type that it's assigned to. However, I'm not very satisfied with the level of bit-precision errors. As far as I can see from crude surface exports, the level of error is more than a perfect Y'CbCr to RGB conversion matrix in 32-bit floating-point should produce. (I made a reference for conversions in the shader pack, for both the calculus and the algebra: "standard Y'CbCr and RGB conversion codes".)
It's probably not limited to only 8-bit integer RGB, anymore.

[adam777]

Hi.
What happend with changelog (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log)?
Any alternative?

I believe it's closed by sourceforge, due to recent attacks.
You can use http://sourceforge.net/apps/trac/mpc-hc/timeline?changeset=on&update=Update while it's down.

[hoborg]

I believe it's closed by sourceforge, due to recent attacks.
You can use http://sourceforge.net/apps/trac/mpc-hc/timeline?changeset=on&update=Update while it's down.

:thanks:

[nevcairiel]

I prefer this view here, its more concise

https://sourceforge.net/apps/trac/mpc-hc/log/trunk

[hoborg]

I prefer this view here, its more concise

https://sourceforge.net/apps/trac/mpc-hc/log/trunk

:thanks:

BTW, FFDshow doesn't have trac, right?

[Casshern]

@Fadeout: It was only chroma blurring from 4:2:0 to 4:2:2, anyway. The quality was bad, and the colorspace conversions were done with 8-bit integer software mode. It's too taxing on low-end CPU's to do this kind of thing, or any other real-time video modification for that matter. For mainstream and high-end PC's, better conversion quality can be reached when using the complete surfaces of 10-, 16-, or 32-bit RGB and using the shadercore of the GPU.
This is just one of the steps necessary to lower the minimum requirements of video playback on EVR. On the other hand, I want to line the renderer up for integrating shaders, to do a few mixer tasks.

@MrHipp: After modifying the mixer settings and debugging, it seems that the mixer will now take the surface type that it's assigned to. However, I'm not very satisfied with the level of bit-precision errors. As far as I can see from crude surface exports, the level of error is more than a perfect Y'CbCr to RGB conversion matrix in 32-bit floating-point should produce. (I made a reference for conversions in the shader pack, for both the calculus and the algebra: "standard Y'CbCr and RGB conversion codes".)
It's probably not limited to only 8-bit integer RGB, anymore.

Tried the new 2910 and still get the dreaded black screen on my system. This is getting annoying. What can I do to help solving this problem? What info do you need? I can also run a logging version if you like?

Also if the new behavior (connecting NV12 without chroma blurring) looks worse than the old, why not just make a switch, so people can choose what they want until the new shader code is ready? Chroma blurring is better than no chroma upsampling at all!

[janos666]

I just saw this in the changlog:
r2863 r2912
1229 1229 cmsCIExyY whitePoint;
1230 1230
1231 whitePoint.x = 0.31271;
1232 whitePoint.y = 0.32902;
1231 whitePoint.x = 0.312713;
1232 whitePoint.y = 0.329016;
1233 1233 whitePoint.Y = 1.0;

Very nice, but there is a little problems with this. These are the CIE D65 coordinates but the Rec709 standard defined it's own white point: a rounded D65. So, it should be:
r2912 r2913
1229 1229 cmsCIExyY whitePoint;
1230 1230
1231 whitePoint.x = 0.312713;
1232 whitePoint.y = 0.329016;
1231 whitePoint.x = 0.3127;
1232 whitePoint.y = 0.3290;
1233 1233 whitePoint.Y = 1.0;

I think I will play a bit with this CMS stuff if I manage to get a working compiler environment. (Note that I am not a programmer. :D)

[adam777]

I prefer this view here, its more concise

https://sourceforge.net/apps/trac/mpc-hc/log/trunk

:thanks:

[tetsuo55]

Tried the new 2910 and still get the dreaded black screen on my system. This is getting annoying. What can I do to help solving this problem? What info do you need? I can also run a logging version if you like? Is that the build janwillem posted? or from another source?.

Also if the new behavior (connecting NV12 without chroma blurring) looks worse than the old, why not just make a switch, so people can choose what they want until the new shader code is ready? Chroma blurring is better than no chroma upsampling at all!Ofcourse it looks worse, you need to enable chroma upsampling with the shaders for now. Or use the stable which does not contain any of the renderer changes.

[cca]

The funny thing is, it actually looks better if you use the proper chroma upsampling shaders, the video is sharper. The downside is, those shaders won't play well in low end hardware (like netbooks with intel VGAs).

[Fadeout]

Ofcourse it looks worse, you need to enable chroma upsampling with the shaders for now. Or use the stable which does not contain any of the renderer changes.

Explain this better. The old method is too taxing for CPU or GPU?

And doing this through shaders means that you're lowering the load on CPU but increasing it on GPU, I guess?

What if one uses DXVA and so already does most work on the GPU?

What is exactly that I should do to obtain optimal quality under the new version? Consider that I need DXVA and subtitles.

[vBm]

:thanks:

BTW, FFDshow doesn't have trac, right?No, but you can use CIA.vc (http://cia.vc/stats/project/ffdshow%20tryouts) logs to see last 20 revs :)

[JanWillem32]

Explain this better. The old method is too taxing for CPU or GPU?The old method was an incomplete fix, introduced to fix a black screen problem. This method is lossy, and done pure software mode with rounding to 8-bit. On top of that, the convertor to YUY2 is very heavy compared to the bit re-ordering required for NV12.
https://sourceforge.net/apps/trac/mpc-hc/changeset/1589
Also note that VMR9 (renderless), EVR-CP and EVR Sync output the same chroma sub-sampling form after my patch.
And doing this through shaders means that you're lowering the load on CPU but increasing it on GPU, I guess?Even the weakest DirectX 9 GPU types can do colorspace conversions and interpolation.
Ideally you want to dedicate the CPU and system memory for performing program and system tasks, and the video card to perform video tasks (or even a bit more than that). Swapping video data between the CPU and video card is generally bad for overall performance.
What if one uses DXVA and so already does most work on the GPU?DXVA implementations usually only use the shadercore to put decoded images on a surface to export to the mixer object. Most of the video decoding is done in dedicated parts of the GPU.
What is exactly that I should do to obtain optimal quality under the new version? Consider that I need DXVA and subtitles.DXVA will always export NV12, so up-sampling form 4:2:0 is required. Subtitles are currently generated almost completely in software mode.
Shader thread: http://forum.doom9.org/showthread.php?t=157634
Chroma up-samplers:
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'm planning to add a few other windowed function shaders to accompany the current scalers, but I must be careful, since my last try at using Lanczos scaling didn't go very well.
You can also try some other shaders and renderer settings to improve the picture quality. Some of those items are very demanding, and some processing just seems to come for free. It all depends on your hardware.

@Casshern: We can do a lot more on IRC: irc://irc.freenode.net/MPC-HC .
With the very scarce few alpha- and betatesters we have at the moment (we really need a lot more), I've done custom builds with experimental fixes and functions. To help with development we usually ask to run a list of tests and to try out relevant settings, and then wait for the response. For problems we usually try to replicate the problem and try to fix things. Sometimes we will even use a remote desktop session.

[Fadeout]

New version + shaders still looks to me worse than old version without shaders.

On the left the new one, on the right the old, the new one is more blocky.

And using the new shaders on the old version seems to deny the chroma upsampling.

[pdanpdan]

These are compiled with MSVS 2010, and deviated from build r2911
Hello, I tried both 32 and 64bit versions on Win764, Ati HD2400PRO, catalyst 11.1.
Now I no longer have black screens, and everything seems to work as it should (DXVA and software decoding). For my GPU maximum dithering level is 1. I tried Full floating point, half FP, 10bit output (it's not supported on my card, but the output is 8bit as it should).
If you need some more tests or infos please tell me.
Thank you.

PS: If I use D3D Fullscreen both on my 1th or the 2nd output (CRT TV):
- Aero is allways turned off (it's not checked in options)
- if 10bit output is checked, I have black screen on exit (it's just for info, I don't mind :) )

[vBm]

New version + shaders still looks to me worse than old version without shaders.

On the left the new one, on the right the old, the new one is more blocky.

And using the new shaders on the old version seems to deny the chroma upsampling.

In future please use imageshack.us or imgur.com instead of attaching screens (takes at least day or so to get it approved and by that time it's already buried in this thread ;x)

[JanWillem32]

@Fadeout: The etiquette for image comparison:
Use lossless image formats in a true lossless mode. That means using no bit per component per pixel reduction at all with an image format like PNG or JPEG2000. For advanced users: full exports of surfaces in a lossless raw DDS file can sometimes be very useful too.
Use video and image sources that are known to be properly mastered. Many unconverted DVD and blu-ray sources are fine. http://w6rz.net/ also has a few interesting test samples.
Include MediaInfo logs of the source image or video, also add relevant information on the renderer settings and the hardware used.
The next item is to disable all full image scaling. Anamorphic correction is disabled by unticking "Keep Aspect Ratio" under View, Video Frame. Normal scaling can be disabled by setting "Normal Size" under View, Video Frame.
At the moment, the internal screenshot item is broken. Please take a screenshot with the "Print Screen" button on your keyboard. After that, paste into an image editor, clip the edges off and save it properly.

In your case, there's special attention for chroma conversion comparison. You might want to use "chroma for SD&HD video input" on top of chroma up-sampling to highlight chroma contours.

@pdanpdan: Good to know that the problem is solved for some people.
To help out, just keep track of this thread. For live interaction, we use IRC. Some developers often ask visitors to test a few things on the MPC-HC channel. People usually respond quite quickly. If it takes too long, just send a message directly to a developer.

I found a website with one explanation why linear gamma transformation can be important for image quality (there are actually more reasons): http://www.all-in-one.ee/~dersch/gamma/gamma.html .
That's for all of the people wondering why I like to convert to linear RGB before processing RGB color data.

[pdanpdan]

Also in these 2 builds I cannot see the options for the internal filters (a required resource is unavailable).

[HoP]

Hello Guys
what happened to the subtitle quality???
i'm using JanWillem32 build (r2911)
http://upit.cc/images/15e04fca.jpg

[Fadeout]

@Fadeout: The etiquette for image comparison:

Nope. I'm not interested in technical tests. I'm interested on the practical use I do of the player and a sample of something I can actually watch.

In this case I'm simply saying that the old player version produces a smoother image, while the new version + new shaders produce a more blocky image. For whatever reason, but this is what I see.

I also would like to know why these new shaders, if applied to the old player, undo the default chroma upsampling, while the default shaders for chroma upsampling produce a identical image to the default (since the upsampling is already done).

http://img140.imageshack.us/img140/2619/samplegb.jpg

That's the sample. Simply trust me when I say it's indicative of what I see in the player even if it doesn't fit your submission criteria.

The one on the left is the new player + shaders, and as you can see it is more blocky, while the other on the right is more uniform and doesn't show the same big boxes.

[janos666]

I wonder if somebody can see any significant differences in the CMS quality with this dummy test build: mpchc2915cms.7z (http://www.mediafire.com/?zs5g8qaasqdih5y)
I didn't change much but I enabled the Black Point Compensation feature (it works with cLUT type display profiles only, I guess ; and should be used with the Relative or may be with Perceptual intents, it won't work with the absolute colorimetric intent) and I increased the 3DLUT size for testing purposes (slower lut generation, may be hangs for some seconds). And I also changed the WP from the CIE D65 values to ITU Rec 709 values.

@JanWillem32
The source code package which you gave me doesn't want to compile for me. It says that the version string is undeclared.

[thuan]

I see the same thing as Fadeout. Here are two images:
JanWillem32 with 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
http://thumbnails20.imagebam.com/11834/080f62118332774.jpg (http://www.imagebam.com/image/080f62118332774)
Normal build
http://thumbnails19.imagebam.com/11833/856724118326262.jpg (http://www.imagebam.com/image/856724118326262)
You can see the blocky red area near the central of the image.

I set up the two up-sample shaders as normal Combined Shaders with EVR-CP and Bicubic 0.75 resizer. GFX card is Geforce 9800GT.

[cyberbeing]

There appears to be a bug which prevents enabling Color Management in the recent builds on WinXP SP3 x86. Once a video is loaded, 'Enable' is grayed out.

Last tested working build was 2833. It was broken in 2840, so one of the commits between 2834 and 2840 broke it.

Is there a reason why JanWillem32's fix for this has not yet been committed to source?

[tetsuo55]

Fadeout, thuan,

Thuan's sample shows the problem very well and correctly (fadeout isn't using the same size on both images so its difficult to compare)

it looks like something is indeed going wrong with the chroma scaling, its almost like its being linearly scaled first and then anti-aliased.

[cca]

Hello Guys
what happened to the subtitle quality???
i'm using JanWillem32 build (r2911)
http://upit.cc/images/15e04fca.jpg

Noticed the same problem with that build, subtitle rendering seems a lot worse.

[tetsuo55]

Its the same problem as with the chroma.

We've removed the low quality scaling, but mpc-hc does not natively have high quality replacements yet.

[cca]

Its the same problem as with the chroma.

We've removed the low quality scaling, but mpc-hc does not natively have high quality replacements yet.

This needs a fix, I use subtitles extensively. For now I reverted to the normal builds compiled from the svn that have some scaling at least. It's horrid to see such subtitles when you have specified 1280x720 as the subtitle texture resolution.

[tetsuo55]

ofcourse, eventually all the missing features will be re-introduced, they are called nightly builds for a reason ;)

[cca]

ofcourse, eventually all the missing features will be re-introduced, they are called nightly builds for a reason ;)

:p yep I know, I like testing the new stuff though :cool:

[Betsy25]

Hi,

Is it possible to have the option "File / Save Thumbnails...." open to the current media's folder by default please ?

[HoP]

@cca:tnx for your comment...goodluck

[Hera]

Very general question, but, how will these changes affect performance?

[JanWillem32]

pdanpdan: I updated linking in these builds, does this solve it? It should also be independent from the Microsoft Visual C++ 2010 Redistributable Packages now.

HoP: That's purely my fault, I tried to add some scalers to the bitmap based subtitle rendering. It's in the early stages of development.

Fadeout: I can't work on things without some technical data about what to change. From a technical point of view, both of the images look really bad.
The specific chroma transformations look like this: http://forum.doom9.org/showthread.php?p=1463132#post1463132 .
For any kind of analysis, there's always the reference factor. The "ffdshow NV12" sample shows the unmodified state of 4:2:0 sub-sampled chroma. CiNcH also added information about what the mixer output was, and the system information.
I can't see what the actual chroma state is, what the mixer does or what the system configuation is from your picture. That's the reason for my previous post.

@janos666: Which SVN manager and compiler do you use? I altered src\apps\mplayerc\FileVersionInfo.h , referencing http://www.codeproject.com/KB/files/fileversioninfo.aspx?msg=396945#xx396945xx (from the original writer).

@thuan: This image is scaled. In my previous post, I explained how the chroma can be analyzed in an optimal way.
Please some samples of an older build, my build with shaders and my build without shaders to help me solve this problem. I can't really see if any shaders are enabled at all on these pictures. Is the mixer output a correct NV12, YV12 or IYUV/I420?

@cyberbeing: My patches are very experimental, and tend to break a lot of stuff. It's usually best to test a lot before committing anything. The very reason I post builds on this forum thread and on IRC, is to get usable error reports returned (and recruiting some extra programmers, alpha- and beta-testers).

@cca: Very glad to hear that you like to test stuff.

@Hera: I've had very consistent performance increases. The biggest performance increase for me came when the DirectX 9 renderers stopped over-filtering. I had quite a few performance and quality problems when I first reported that bug. http://forum.doom9.org/showthread.php?p=1463148#post1463148
I've always made sure that all quality options, will stay optional.
With quality options and a ton of shaders enabled, even I have to give my GPU a higher clockspeed than the regular 2D load setting. It's a lot better than what it was before, though.

These are compiled with MSVS 2010, and deviated from build r2916. I didn't add many changes, other than renderer optimization and setting the subtitles to the previous filter setting.

[Stephen R. Savage]

@JanWillem32: What's going on here?

http://img43.imageshack.us/img43/6159/mpchc.th.png (http://img43.imageshack.us/i/mpchc.png/)
Unpatched MPC-HC build.

http://img838.imageshack.us/img838/9025/mpchcold.th.png (http://img838.imageshack.us/i/mpchcold.png/)
Patched MPC-HC.

Why is my video being converted to YUY2? If anything, it looks worse now, with some sharp edges being blurred. Also, the dithering options don't seem to do anything at all.

[thuan]

@Jan: Here you go http://www.mediafire.com/?2elbm3xuezrkmv3
I'm using DXVA so that's NV12. As for shader settings I used 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 in normal Combined Shader with your r2916 build.

EDIT: Forgot the MediaInfo log:
General
Unique ID : 224811950960145443359033246477980259306 (0xA92134F239065372BD3A79CC8B27D3EA)
Complete name : D:\My Documents\Videos\[aether] Kalafina - oblivious ~ufotable edit~ [E9AD753B].mkv
Format : Matroska
File size : 101 MiB
Duration : 4mn 4s
Overall bit rate : 3 470 Kbps
Movie name : pv: oblivious ~ufotable edit~
Encoded date : UTC 2008-09-05 21:24:21
Writing application : mkvmerge v2.2.0 ('Turn It On Again') built on Mar 4 2008 12:58:26
Writing library : libebml v0.7.7 + libmatroska v0.8.1
Cover : Yes / Yes

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 4mn 4s
Width : 704 pixels
Height : 368 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 1.913
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Title : omfg anamorphic
Writing library : x264 core 61 r957M 7ce0f2c
Encoding settings : cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=7 / psy_rd=0.0:0.0 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=8 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=crf / crf=12.0 / qcomp=1.00 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=2:1.00
Language : Japanese

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 4mn 4s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Title : different from full version
Language : Japanese

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : lazy karafx - and ripped from #gg
Language : English

[Hera]

@Jan, build you just linked to,
Error when trying D3D fullscreen and 10-bit input: DX9AllocatorPreseter Failed
Worked just fine before. Specs in sig.
Works with ATi Radeon 4250 Mobile though.
Not video dependent.

[cyberbeing]

@cyberbeing: My patches are very experimental, and tend to break a lot of stuff. It's usually best to test a lot before committing anything. The very reason I post builds on this forum thread and on IRC, is to get usable error reports returned (and recruiting some extra programmers, alpha- and beta-testers).
It's just that CMS is still grayed-out in the latest svn MPC-HC builds on my PC. Your test builds last week fixed it, so I hope you can finalize a simple patch soon, so I'm not stuck with an old build of MPC-HC forever.

[cca]

@JanWillem32 not sure if you removed them, mediafire says "Invalid or Deleted File"

[HoP]

@JanWillem32:tnx for your effort...i'm wait for your new build...goodluck

[JanWillem32]

@Stephen R. Savage: Dithering requires 16-bit floating point processing support and one of the three surface options enabled. For 10-bit output in D3DFS it even requires one of the two floating point surface options to be enabled on top of the 10-bit output option.
http://sourceforge.net/apps/trac/mpc-hc/wiki/New_Renderer_Settings
The YUY2 output is odd. The mixer merit of YUY2 for 4:2:0 video is lower than YV12, I420/IYUV and NV12. Are you using any external filters? I would definitely like to look into this problem.

@thuan: The chroma problem when enabling shaders in your case is due to previous filtering, so it causes double filtering. This is the first time I've seen the mixer do both horizontal and vertical basic linear filtering on the chroma with any of my recent builds. It has some chroma bleeding, so it's not really full chroma up-sampling. I know someone with a video card of that generation and a similar system configuration that didn't get any filtering on the chroma. So, this is another thing I'd like to take a look at. Thank you for the pictures and information for comparison, they were fine for a proper first analysis.

@cyberbeing: I already made 6 patches. They are just waiting in line for testing and committing, editing or refusal. Development of functions is fast, but actual testing and debugging takes a bit more time.
http://sourceforge.net/apps/trac/mpc-hc/ticket/1120
http://sourceforge.net/apps/trac/mpc-hc/ticket/1121

I noticed errors, so I updated some renderer settings, these builds should work better during renderer initialization.

Thank you all for your continuing responses, the development team can really use some help with testing, analysis and advices to get things done right.

[thuan]

I'm using the old driver 258.96 BTW, because with newer Nvidia drivers, DXVA stutters a lot according to a lot of ppl, I'm not the only one. I wonder if my chroma issue was because of the old driver, but for now I think I keep using it as I haven't seen anything better worth updating.

[god_md5]

reported bug
over the ffdshow 2882 can show idx subtitle(inside ts) .
hdtv is ok .
but my area sdtv is not have video outout
other software can't spilte the subtitle,only hpc-hc can spilter ,but not video out ,like is the hpc-hc spilter bug?
can you help to fix this ,thank you

sample ts
http://www.mediafire.com/?b5wcwcf4klljewk
Sourceforge and doom9 have Attack??

[HoP]

is there any setting for "only one instance"?
http://upit.cc/images/beafe0fc.jpg

[namaiki]

is there any setting for "only one instance"?

Yes, but it only means a new instance will not be created for files opened from Windows Explorer.

[HoP]

@namaiki:tnx for your comment but i think we need to solve this problem :D

@JanWillem32:tnx for new build...in this build subtitle quality is great...tnx again

[6205]

Website with changelog of every single revision is not working anymore
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log

[namaiki]

I believe it's closed by sourceforge, due to recent attacks.
You can use http://sourceforge.net/apps/trac/mpc-hc/timeline?changeset=on&update=Update while it's down.

I prefer this view here, its more concise

https://sourceforge.net/apps/trac/mpc-hc/log/trunk

Website with changelog of every single revision is not working anymore
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log

cheers.

[Hera]

Recently this became an issue - might be the latest ATi Drivers,
HalfFP/FullFP (No difference) + W7 64 + 1080p video + Radeon 4250 Mobile = System almost not-responsive, mouse cursor getting stuck, laggy or very laggy video.
Behavior on NV ION did not get affected - still skips frames, sometimes audio stops.

[god_md5]

@JanWillem32

Got an error about missing "mfc100u.dll" , can you make a static compile?

EDIT: OK, will get the redistributable and try the x86 build.
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84

[Stephen R. Savage]

@Stephen R. Savage: Dithering requires 16-bit floating point processing support and one of the three surface options enabled. For 10-bit output in D3DFS it even requires one of the two floating point surface options to be enabled on top of the 10-bit output option.
http://sourceforge.net/apps/trac/mpc-hc/wiki/New_Renderer_Settings
The YUY2 output is odd. The mixer merit of YUY2 for 4:2:0 video is lower than YV12, I420/IYUV and NV12. Are you using any external filters? I would definitely like to look into this problem.

I am using ffdshow to decode H.264/MKV, configured to output YV12. In your patched builds, EVR-CP has switched from RGB32 to YUY2 for "mixer output", though as far as I can tell, the image is still RGB32 as this test image (http://img820.imageshack.us/img820/1119/yuvtest.png) is not degraded. I am using an Intel GMA X3100 on Windows 7 (64); could it be that my GPU doesn't support YV12 images?

Edit: EVR-Sync has always been using YUY2 "mixer output" since it was committed, though like EVR-CP, it appears to also be running in RGB32 actually...

[cca]

I am using ffdshow to decode H.264/MKV, configured to output YV12. In your patched builds, EVR-CP has switched from RGB32 to YUY2 for "mixer output", though as far as I can tell, the image is still RGB32 as this test image (http://img820.imageshack.us/img820/1119/yuvtest.png) is not degraded. I am using an Intel GMA X3100 on Windows 7 (64); could it be that my GPU doesn't support YV12 images?

Interesting. In my own configuration, at least in the past (didn't try this in recent builds) whenever I was forcing YV12 in ffdshow, it couldn't even connect to EVR-CP and the system was falling back to the default system renderer.

EDIT: Just tried it with JanWillem32's latest test build, falls back to video mixing renderer and produces horrible video in my case. NV12 is the way to go in ATI cards.

[JanWillem32]

@thuan: That could very well be the reason. Maybe others with similar hardware can confirm this? I currently can't reproduce this.

@god_md5: http://sourceforge.net/apps/trac/mpc-hc/ticket/523 It's known, but personally I don't know if there's any updates on DVB subtitle source filters. I'll ask others later.

@Hera: Indeed, for ATi I've noticed that during driver installation, almost all video filtering options in the control panel get enabled by default. Did you correct the settings on that tab? There's also a little bug with the display options tab. If the check for the setting "use EDID" isn't set, the color management acts weird.

@Stephen R. Savage & cca: When using ffdshow tryouts, it's usually best to let the mixer do a lot of the conversion work. In the output tab of the video decoder, use "Set pixel aspect ratio in output media type", "Set interlace flag in output media type" and "Allow output format changes during playback".
The next problem is the actual supported output types. I420/IYUV and YV12 are often refused by EVR, that leaves only NV12 as an option for 4:2:0 chroma sub-sampled video. Unfortunately, YUY2, YVYU and YUYV are selected by default instead. The only solution to that, is to disable those formats. Only enable YUY2, YVYU or YUYV if you want to play an actual 4:2:2 chroma sub-sampled video (not very common).
That should make a good NV12 connection without any chroma conversions before the mixer.

[cca]

Indeed, and this is what I have always done for some years now, ffdshow is forced to NV12. Because I also use ffdshow to play some interlaced DVDs, and ATI cards can only do Vector Adaptive deinterlacing when NV12 is used, that was another reason for me to force it as output format.

[pdanpdan]

@JanWillem32 - still the same problem with resources not available for internal filters properties in the latest builds, and still aero always disabled in d3d fullscreen (by the way, is this by design or a defect?).
Subtitles resizing seems to work as it should.

[Ger]

Indeed, and this is what I have always done for some years now, ffdshow is forced to NV12. Because I also use ffdshow to play some interlaced DVDs, and ATI cards can only do Vector Adaptive deinterlacing when NV12 is used, that was another reason for me to force it as output format.

I do the same thing, mostly for DVB sourced material though, since I rarely use DVD sources. One of the reasons I prefer ffdshow over the internal MPEG-2 decoder is that I can force NV12 output in ffdshow, while the internal MPEG-2 decoder always seem to prefer YUY2 (even when "Set interlace flag in output media type" is checked), which along with UYVY only supports some/simpler deinterlacing methods according to DXVAChecker.

I believe the situation is the same with Nvidia as well, with NV12 being the safe bet for getting all hardware deinterlacers working.

So the question is, shouldn't the internal software decoders also have NV12 as the top output priority, at least if "Set interlace flag in output media type" is checked?

Another problem with the internal MPEG-2 decoder is that 4:2:2 source material (DVB feeds etc.) is not supported, unlike ffdshow which handles it just fine.

[Dstruct]

Just got this crash in 1.5.0.2827 while closing MPC:

Anwendungsausnahme aufgetreten:
Anwendung: C:\Programme\Media Player Classic\mpc-hc.exe (pid=1888)
Wann: 07.02.2011 @ 18:56:53.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
628 svchost.exe
688 svchost.exe
744 svchost.exe
796 spoolsv.exe
1120 Explorer.EXE
1300 hdsp32.exe
1376 hdspmix.exe
1592 TOTALCMD.EXE
1888 mpc-hc.exe
1804 uTorrent.exe
1492 drwtsn32.exe

*----> Modulliste <----*
(0000000000340000 - 0000000000349000: C:\WINDOWS\system32\Normaliz.dll
(0000000000400000 - 0000000000f49000: C:\Programme\Media Player Classic\mpc-hc.exe
(00000000019b0000 - 0000000001c89000: C:\WINDOWS\system32\xpsp2res.dll
(0000000002520000 - 000000000271f000: C:\WINDOWS\system32\d3dx9_43.dll
(0000000002ef0000 - 0000000003336000: C:\Programme\Ffdshow\ffdshow.ax
(0000000010000000 - 000000001004c000: C:\Programme\Media Player Classic\mpcresources.de.dll
(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
(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
(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
(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 0x348 <----*

eax=04733040 ebx=7c911000 ecx=0175af80 edx=003f0608 esi=04733040 edi=0175aff4
eip=005a407e esp=01f8fd48 ebp=0175afdc iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202

*** ERROR: Module load completed but symbols could not be loaded for C:\Programme\Media Player Classic\mpc-hc.exe
Funktion: mpc-hc
005a405e ff83c41cc38d inc dword ptr [ebx+0x8dc31cc4]
005a4064 b600 mov dh,0x0
005a4066 0000 add [eax],al
005a4068 008dbc270000 add [ebp+0x27bc],cl
005a406e 0000 add [eax],al
005a4070 83ec0c sub esp,0xc
005a4073 8b442410 mov eax,[esp+0x10]
005a4077 85c0 test eax,eax
005a4079 7415 jz mpc-hc+0x1a4090 (005a4090)
005a407b 83e0fc and eax,0xfffffffc
FEHLER ->005a407e 8b40fc mov eax,[eax-0x4] ds:0023:0473303c=????????
005a4081 89442410 mov [esp+0x10],eax
005a4085 83c40c add esp,0xc
005a4088 e9dfab3900 jmp mpc-hc+0x53ec6c (0093ec6c)
005a408d 8d7600 lea esi,[esi]
005a4090 83c40c add esp,0xc
005a4093 c3 ret
005a4094 8db600000000 lea esi,[esi]
005a409a 8dbf00000000 lea edi,[edi]
005a40a0 83ec3c sub esp,0x3c
005a40a3 89742430 mov [esp+0x30],esi

*----> Stack Back Trace <----*
WARNING: Stack unwind information not available. Following frames may be wrong.
ChildEBP RetAddr Args to Child
0175afdc 00000000 00000001 00000348 00000000 mpc-hc+0x1a407e

*----> Raw Stack Dump <----*
0000000001f8fd48 d0 8a 69 04 50 74 75 01 - f8 00 64 04 b3 4f 83 00 ..i.Ptu...d..O..
0000000001f8fd58 40 30 73 04 80 af 75 01 - da 50 83 00 8c af 75 01 @0s...u..P....u.
0000000001f8fd68 1c ba 65 00 e4 b8 8c 46 - 80 bc 35 00 0c b5 35 00 ..e....F..5...5.
0000000001f8fd78 ac fd f8 01 70 b5 35 00 - f4 af 75 01 24 fe f8 01 ....p.5...u.$...
0000000001f8fd88 b0 67 9d 00 01 00 00 00 - 1d 79 7c 74 dc af 75 01 .g.......y|t..u.
0000000001f8fd98 0c b5 35 00 00 00 00 00 - 78 b6 35 00 54 b5 35 00 ..5.....x.5.T.5.
0000000001f8fda8 a4 b5 35 00 c0 fd f8 01 - 4b 89 7c 74 00 00 00 00 ..5.....K.|t....
0000000001f8fdb8 b8 b4 35 00 54 b5 35 00 - dc fd f8 01 f2 8f 7c 74 ..5.T.5.......|t
0000000001f8fdc8 00 b5 35 00 b8 b4 35 00 - 80 3a 73 01 d8 b4 35 00 ..5...5..:s...5.
0000000001f8fdd8 00 b5 35 00 e8 fd f8 01 - 3c 8f 7c 74 08 b5 35 00 ..5.....<.|t..5.
0000000001f8fde8 fc fd f8 01 b9 a3 7a 74 - 01 00 00 00 d8 43 71 01 ......zt.....Cq.
0000000001f8fdf8 38 44 71 01 00 00 00 00 - 3a 88 42 00 00 b5 35 00 8Dq.....:.B...5.
0000000001f8fe08 98 bb 8c 46 d8 43 71 01 - d8 43 71 01 ff ff ff ff ...F.Cq..Cq.....
0000000001f8fe18 00 00 00 00 d8 43 71 01 - ec 43 71 01 68 fe f8 01 .....Cq..Cq.h...
0000000001f8fe28 29 a7 9a 00 0a 00 00 00 - f8 fc 42 00 e0 43 71 01 ).........B..Cq.
0000000001f8fe38 41 b5 65 00 01 00 00 00 - 3d 9e 37 7e e0 44 72 01 A.e.....=.7~.Dr.
0000000001f8fe48 d3 41 46 00 d8 43 71 01 - c0 bb 8c 46 00 c0 00 00 .AF..Cq....F....
0000000001f8fe58 74 f6 9f 00 94 fe f8 01 - 00 00 00 00 e0 44 72 01 t............Dr.
0000000001f8fe68 64 ff f8 01 d8 28 9e 00 - ff ff ff ff 6c 44 46 00 d....(......lDF.
0000000001f8fe78 85 9b 91 00 00 00 00 00 - a4 f3 12 00 60 17 19 00 ............`...

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

[mark0077]

I am also seeing mpc crashing if u try to open a file while one is playing. Mpc also isn't closing gracefully as I can still see ffdshow and reclock icons in the taskbar after it's closed in recent versions.

[robpdotcom]

Mpc also isn't closing gracefully as I can still see ffdshow and reclock icons in the taskbar after it's closed in recent versions.

I've had that for quite some time - no idea which version it started with. Hovering the mouse over the icons makes them disappear though.

[mark0077]

I've had that for quite some time - no idea which version it started with. Hovering the mouse over the icons makes them disappear though.

Yeah I know but unfortunately if some settings are changed for example in various filters guis, like reclock, and if it doesn't shut down gracefully, then the settings changes can be lost. Good job ffdshow can save its settings using the apply button, and not on filter shut down...

[robpdotcom]

if some settings are changed for example in various filters guis, like reclock, and if it doesn't shut down gracefully, then the settings changes can be lost.

Ahhh, I wondered why Reclock settings didn't always stick. Thanks for that info.

[Stephen R. Savage]

@Stephen R. Savage & cca: When using ffdshow tryouts, it's usually best to let the mixer do a lot of the conversion work. In the output tab of the video decoder, use "Set pixel aspect ratio in output media type", "Set interlace flag in output media type" and "Allow output format changes during playback".
The next problem is the actual supported output types. I420/IYUV and YV12 are often refused by EVR, that leaves only NV12 as an option for 4:2:0 chroma sub-sampled video. Unfortunately, YUY2, YVYU and YUYV are selected by default instead. The only solution to that, is to disable those formats. Only enable YUY2, YVYU or YUYV if you want to play an actual 4:2:2 chroma sub-sampled video (not very common).
That should make a good NV12 connection without any chroma conversions before the mixer.

Even when all formats besides NV12 are disabled, I still get "Mixer Output: YUY2". The only difference is that I get very strange chroma artifacts (solid 8x8 red/blue blocks).

http://img547.imageshack.us/img547/4528/evrcpnv12.th.png (http://img547.imageshack.us/i/evrcpnv12.png/)
NV12

http://img29.imageshack.us/img29/7281/evrcpyv12.th.png (http://img29.imageshack.us/i/evrcpyv12.png/)
YV12

http://img822.imageshack.us/img822/5899/evrcprgb.th.png (http://img822.imageshack.us/i/evrcprgb.png/)
RGB32

In each of these cases, the OSD reports the mixer output to be YUY2.

[G_M_C]

Even when all formats besides NV12 are disabled, I still get "Mixer Output: YUY2". The only difference is that I get very strange chroma artifacts (solid 8x8 red/blue blocks).

http://img547.imageshack.us/img547/4528/evrcpnv12.th.png (http://img547.imageshack.us/i/evrcpnv12.png/)
NV12

http://img29.imageshack.us/img29/7281/evrcpyv12.th.png (http://img29.imageshack.us/i/evrcpyv12.png/)
YV12

http://img822.imageshack.us/img822/5899/evrcprgb.th.png (http://img822.imageshack.us/i/evrcprgb.png/)
RGB32

In each of these cases, the OSD reports the mixer output to be YUY2.

Is the connection to your monitor configured as YUY2 ?
My connection to my TV can be configured in CCC as 4:2:2 (limited or full) and 4:4:4 (limited or full), and afaik both as RGB or YUV. Might be the place to look ?

[thuan]

@Jan: I have tried the latest driver version and still the same chroma upsampling with your build and shaders problem happens on my setup, not to mention the stuttering DXVA (stupid nvidia, but ATI has chroma upsampling problem).

[Jong]

Sorry if this has been discussed before. I've been happy with the last stable build since it came out, so have not been updating regularly or reading this thread very often for a while.

I have just updated to the new "1.5.0.2827" stable build, which defaulted to using its own Matroska splitter instead of Haali that I was using previously. I very quickly spotted that it was always showing the first subtitle stream, if available.

Haali will only show forced streams, by default. Other subtitles default to "off" but are selectable as required. The inbuilt splitter seems to always show the first stream.

I know I could turn off all embedded subtitles, but that would not then be good for forced subtitle streams.

Am I missing something or is this a limitation of the current splitter?

[yetanotherid]

Anyone else having problems getting MPC-HC to open AVS scripts?

So far, on my XP SP3 machine, version 1.3.1249.0 is the last version capable of successfully opening one. The newer versions just sit there displaying "opening" while they slowly eat up RAM. Version 1.3.1249.0 also seems to be the last version which gives you a choice of more than three logos, so I assume newer versions aren't reading the mpciconlib.dll file?

Oh..... And as mentioned in a different thread, version 1.3.1249.0 also opens those problem vob files with the correct aspect ratio. By "those problem vob files" I'm referring to the occasional one which opens with a 2.35 aspect ratio using newer versions of MPC-HC. http://forum.doom9.org/showthread.php?t=159286

[JanWillem32]

@pdanpdan: Solved the resource problem. Aero gave problems in combination of the exclusive mode with clear video memory commands and enforcing settings on the video driver. Aero isn't rendered during D3DFS exclusive mode, anyway. Windowed mode can work with Aero enabled and re-initialization of Aero should only take a few seconds. (If not, I can try to solve it.)

@Ger: The internal MPEG-2 decoder is old. I don't know much about it, but it could very well be that it just doesn't have any routines for 4:2:2 chroma sub-sampled data. I use the default Microsoft decoder, as it seems to be able to use at least IDCT DXVA mode in my situation. My video card can't do the full VLD DXVA decoding mode for MPEG2. I don't know if that decoder can do 4:2:2 structures, either.

@Stephen R. Savage: I can't really see it very well because of the scaling artifacts, but it does look like 4:2:2 input indeed. I changed a few settings in the attached builds.
Can you also check that file with MediaInfo? If it reports that the file itself is 4:2:2 chroma sub-sampled, YUY2 would be a correct format for the mixer. Could you also check if the ffdshow tryouts video filter is loaded properly from the "Play", "Filters" menu?

@thuan: I'm starting to think that writing a custom mixer is the only way to get proper and uniform color conversion across all hardware brands, video cards and drivers. You really can't find any setting in the video card control panel for video playback, 2D/3D rendering, or whatever that will disable the chroma alteration?

@Jong: I couldn't really find an active ticket for this, so please report it on: http://sourceforge.net/apps/trac/mpc-hc/report . You could try a nightly build, I've seen an update on the source splitters a few days ago.

@yetanotherid: The graphics can get an update: http://forum.doom9.org/showthread.php?t=156694 . You are not the only one with aspect ratio problems. See if there's a report that fits your description in the bug tracker, else make a new one.

I removed the convertor to YUY2, and gave NV12 a higher merit than YV12 and I420/IYUV. If it's preferred, I can set different merits for interlaced and non-interlaced content in future builds. I also tried a bit of optimizing for start-up speed.

[yetanotherid]

An update to my previous post #16152.

Now I'm more confused regarding the inability to open AVS scripts.
Previously I had the latest version of the CCCP installed and the version of MPC-HC which comes with it (1.4.2677.0) had always successfully opened AVS scripts. (Was version 1.4.2677.0 a special CCCP version of MPC-HC? I can't find it anywhere else.)

Recently I uninstall the CCCP and installed the latest version of MPC-HC as well as the latest stable version of ffdshow. I just tried the version of MPC-HC which came with the CCCP (I'd saved it before uninstalling the CCCP) and it won't open AVS files any more either. However version 1.3.1249.0 will quite happily open and play them.

I'd have assumed if one version of MPC-HC will play AVS scripts then my PC's setup is okay and any other version should play them as well. As that's not the case though, is there something I'm missing? An ffdshow decoder which should be enabled for example, or an internal MPC-HC filter which I need to disable? AVS scripts still open in VirtualDub without a problem.

One other question.... I may be remembering incorrectly but I was sure AVS was listed as a supported file type in MPC-HC's "Open file" menu, but this doesn't seem to be the case any longer. Am I remembering incorrectly? I generally open AVS scripts via the Explorer SendTo menu so I could be imagining AVS scripts appearing as a supported file type, but I'm sure when I had the CCCP installed they did..

[Jong]

@Jong: I couldn't really find an active ticket for this, so please report it on: http://sourceforge.net/apps/trac/mpc-hc/report . You could try a nightly build, I've seen an update on the source splitters a few days ago.Thanks Jan. I'll leave it a day or so to see if anyone else has some comment/insight into this. If not, I'll raise a ticket.

[thuan]

@Jan: I tried every setting in the video section of my video card, nothing fixed the problem and some make the video looks worse. Still on latest driver.

[GrofLuigi]

@yetanotherid: Recently I had similar problems with MPC hanging on opening AVS scripts. I solved it by moving away ffavisynth.dll and ffavisynth.avsi from Avisynth/plugins directory.

I tried just now returning them and they give no problems, but it might have been some combination of script/version...

GL

[Taurus]

@yetanotherid
I never had problems opening avs scripts with MPC-HC.
Just tried the latest from xvidvideo.ru (1.5.1.2910.x86.msvc2010).
Everything o.k.

[yetanotherid]

@yetanotherid: Recently I had similar problems with MPC hanging on opening AVS scripts. I solved it by moving away ffavisynth.dll and ffavisynth.avsi from Avisynth/plugins directory.

I tried just now returning them and they give no problems, but it might have been some combination of script/version...

GL

GrofLuigi,
Thank you. If I had a first born, he/she'd be yours.
After spending hours messing around, not to mention the mess I've probably made of file associations and codecs in the process, removing the ffavisynth.avsi file has me opening avs scripts like there's no tomorrow, returning it stops me opening them, removing it...... etc. etc.

Why the newer versions of MPC-HC are effected while the older versions not? I guess it'd be nice to know, but I think I'll try to block this one out and pretend it never happened.....

[JanWillem32]

@thuan: What settings make video look worse, or any other setting that could hinder the picture looking like the reference output? (I'd like to know what to tell people what they have to disable or enable for video playback.) What about the 3D or display settings? I know that "quality" and "performance" settings can have an effect on full screen scaling scaling settings. Maybe these settings can influence mixer objects as well.

For reference, I'm trying to get chroma scaling completely disabled in the mixer, so the renderer can do it in a proper, user-selectable way. For that to work, the mixer has to deliver unmodified chroma data: http://forum.doom9.org/showthread.php?p=1463132#post1463132 . (In the mean time I've written better scalers than the one in the sample, by the way.) Many users with various hardware have reported that the chroma is properly unmodified from the mixer when testing these nightly builds. I need to be sure that if I add a chroma scaling option, people will not get distorted output when enabling it.
I'll try to make some sample screenshots of the different chroma up-sampling modes. It's been a while since I made some picture quality comparisons. (I also feel the need to show off that I can actually write a proper scaler. :D)

[Hera]

@JanW,
I have all the stuff disabled for Radeon 4250 Mobile. Still the same issue with FullFP.
1.5.0.2827 works fine.

[JanWillem32]

1.5.0.2827 is rather old, I didn't contribute to it. It doesn't have a real Full Floating Point Processing rendering path or Half, for that matter. Surfaces were created from three different places in the past, with many items hard-coded to 8-bit RGB/RGBA.
You can use the Hardware, Monitoring Graphs function of ATi Tray tools to log the GPU usage during rendering. If it's at 100% usage for longer than the buffer period, it's too much for the GPU to handle. It also helps a lot to set higher GPU clock speeds than the usual 2D settings. Even on low end video cards, many basic quality settings can be used with some overclocking.

[mark0077]

Figured out why my mpc-hc wasn't shutting down gracefully. Without arcsoft audio decoder in the external filter chain, it shuts down correctly. With it, reclock and ffdshow icons don't disappear from the taskbar nor does reclock exit and save its settings...

Anyone know why mpc-hc has a hard time shut down correctly when using arcsoft decoder? Could the fact that we have to modify the exe with hex changes to get the arcsoft decoder to work, have an impact?

[Dstruct]

It also helps a lot to set higher GPU clock speeds than the usual 2D settings.

Could you add an option to MPC to switch graphic cards to higher clock speed?

[JanWillem32]

@Dstruct: Unfortunately, no. It's very hard to send such settings to the video card at all. I've been trying to get all anti-aliasing and anisotropic filtering disabled from within the program, but it usually doesn't work at all (and it returns errors). Clock speeds are even harder. The rendering process is usually detected as a 2D item, so the GPU usually runs at 2D load settings during video playback. Setting custom adjusted clock speeds (as I do with an ATi Tray Tools profile), is near impossible to implement into the program. The best I could do, is loading some vertex data to fake 3D rendering and try to get full 3D clock speeds (with very loud fans as a consequence :p).

Chroma up-sampling comparison pictures: (I tried very hard not to post red-on-black items this time.)
Normally, I would post-process video like this with full image scaling, "sharpen complex v3 + deband + medium denoise" to get rid of some of the luma and chroma imperfections, color management and dithering on top of chroma scaling. These images are a bit "raw" for my taste, but optimal for pure chroma scaling quality comparison.

[Hera]

EDIT 2: JanW Test Builds + NV ION + 10-bit in = Error creating EVR Custom renderer CreateDevice failed DX9AllocatorPreseter failed D3DERR_NOTAVAILABLE
EDIT 3: FullFP doesn't stutter for some reason on NV ION EDIT 4: with *some* 1080p content and stutters with other... >.<
EDIT 5: The quality is horrible though, purely horrific.

1.5.0.2827 is rather old, I didn't contribute to it. It doesn't have a real Full Floating Point Processing rendering path or Half, for that matter. Surfaces were created from three different places in the past, with many items hard-coded to 8-bit RGB/RGBA.
You can use the Hardware, Monitoring Graphs function of ATi Tray tools to log the GPU usage during rendering. If it's at 100% usage for longer than the buffer period, it's too much for the GPU to handle. It also helps a lot to set higher GPU clock speeds than the usual 2D settings. Even on low end video cards, many basic quality settings can be used with some overclocking.

Interesting, same issue with 1.5.1.2910. 10-bit in works now though with Radeon 4250.

Shouldn't it automatically up the clock speeds if 2D clock speeds are inefficient? I assumed that was the default behavior on modern GPUs anyway.

Absolutely no changes in FullFP performance on NV ION though.

EDIT1: It would be nice if 10-bit input would work in windowed mode...

[thuan]

@Jan: So I tried to change 3d settings, but to no avail, it's not exhaustive, but I gave up half way, disappointed >_<. So what is your current GFX card, I might buy something soon, so at least I want something that works with your future features. As for what made video looks bad, basically for my current config keeps everything at defaults, both dynamic contrast enhancement and color enhancement did that for Japanese animation IMO, other features to change color and gamma should not be touched unless you were calibrating your display of course.

[pdanpdan]

@JanWillem32: The problem with resources is fixed now, thank you.
Ref. Aero: I have 2 displays (LCD+CRT TV), and I keep MPC interface on LCD, and the movie in D3D Fulscreen on TV. In the oficial builds this kept Aero on on my LCD. I agree that if there's only one display, Aero off is not a problem.

[Dstruct]

The best I could do, is loading some vertex data to fake 3D rendering and try to get full 3D clock speeds (with very loud fans as a consequence :p).

Yeah, something like this. Same way games do it. Of course this should be optional only.

[JanWillem32]

@Stephen R. Savage: http://sourceforge.net/apps/trac/mpc-hc/changeset/2827 The build 2827 is one month old, and was released as "stable", because it was long overdue. I didn't contribute to it. All of the work I've done, is exclusive to nightly builds.

@Hera: Unfortunately, I'd wish that clock speeds would be adapted to the actual load. Unfortunately, it can only be set to 2D load or 3D load settings with a trick.
The 10-bit output option requires locking an entire screen to exclusive mode, as the Windows desktop won't allow it. The only thing available for windowed mode is a 10-bit backbuffer, to use the video card's color LUT on.
The ION probably has problems with setting a 10-bit backbuffer. I'll try to add a detection option to see if I can disable enforcing a 10-bit backbuffer in that case.
The stuttering is probably the worst with animated subtitles on 1080i/(30000/1001) video. I can only think of the 100% load limit for the ION that would cause stuttering and frame drops.
Explain the quality thing please. With the "optimal" settings preset, without dithering and other post-processing, the picture should come out like the "base" pictures I posted.

@thuan: That's too bad. I still wonder why users with similar systems reported that unaltered chroma came out of the mixer, but it doesn't work in your case. From a developer point of view, it's annoying that it's forced with your system for some reason, and can't be enabled on most other systems. There's no way that the program can directly detect this, either. Please hold on to your system for some time, I'd really like to find a complete solution, instead of advising all users to buy new hardware. It might very well be that a new mixer is required to get this problem solved.

@pdanpdan: Microsoft should make it possible to disable Aero on only the active screen. I can allow Aero to stay enabled when not forcing 10-bit output (or an experimental function I'd still like to add), but then it would be nearly the same as the fullscreen windowless rendering mode, anyway.

@Dstruct I can add it as an optional item, once I fixed the vertex processing (it's done in software at the moment). Right now, it's a bit too risky.

[god_md5]

reported bug
over the ffdshow 2882 can show idx subtitle(inside ts) .
hdtv is ok .
but my area sdtv is not have video outout
other software can't spilte the subtitle,only hpc-hc can spilter ,but not video out ,like is the hpc-hc spilter bug?
can you help to fix this ,thank you

sample ts
http://www.mediafire.com/?b5wcwcf4klljewk
Sourceforge and doom9 have Attack??
sorry my eng,photo , i mean mpc-hc spilter is not video,but have subtilte
please test the sample ts.ver is 1.5.1.2917
http://img17.imageshack.us/img17/9711/screenhunter02feb091840.jpg

[JanWillem32]

That's the black screen bug. Try one of my nightly builds, I've solved most of the causes of it. http://forum.doom9.org/showthread.php?p=1476526#post1476526
It will take some time before the fixes are integrated into the source code. We need to solve other mixer problems first.

[cca]

@JanWillem32: are your sure that graphics card clocks are not dynamic? In my ATI 4850, if I leave the Catalyst Control Center in the Overdrive display which displays the clocks and open a (non-DXVA) video, I can clearly see the clocks changing to higher speed, even going to max speed at many occasions. Of course I can only speak for my hardware.

[Stephen R. Savage]

@Stephen R. Savage: http://sourceforge.net/apps/trac/mpc-hc/changeset/2827 The build 2827 is one month old, and was released as "stable", because it was long overdue. I didn't contribute to it. All of the work I've done, is exclusive to nightly builds.

Please take the time to read what I write. If you notice, the build in the screenshot is revision 2917, one of your (http://www.mediafire.com/?er833bzfj200p5m) builds (even though nothing has changed relative to even v1.3...)

Quite honestly, I had no problems with the way MPC-HC was performing before, and am therefore extremely concerned with these future "improvements" that appear to accomplish nothing at all.

[thuan]

@Jan: I want to make another shot. Can you post the registry dump (without personal info like file open history) of a working MPC-HC config for me to try? I might have set up something wrong, albeit I have tried set it up from scratch once by deleting the old settings in registry, it still didn't work.

[JanWillem32]

@cca: Overdrive isn't enabled by default. If it helps to fine-tune things, it's a good way to achieve a good power balance. I usually overclock manually, so I'll have to try this first. Can nVidia, Intel, IGP and mobile GPU users report something similar to enable to get a bit more performance in 2D mode?

@Stephen R. Savage: I'm sorry about the version thing, I looked at the wrong item. It's odd that you get YUY2 with all types of inputs. It has a lower merit than NV12, YV12 and I420/IYUV (+ some rare other formats). I assume the same thing happens with internal codecs?
You might not realize it, but if the file format is a Y'CbCr-4:2:0-type and the mixer format isn't, you do have a lossy conversion problem before even mixing. It's hard to guess where that conversion happens. Can you post MediaInfo logs, the filter information from the filters menu, system information, or anything else that could help solve this problem? I haven't seen refusal of NV12 by the mixer before, and I do intend to solve it.

@thuan: Most certainly, these are my own settings (slimmed down a bit). Don't forget to back-up the main registry key before applying the REG file, as it will delete the all current settings.
It's a long shot, but it might help to get the mixer to leave internal chroma unchanged.

My pictures have been viewed quite a few times now. What do people think about the chroma up-sampling? Those who can't see it: zoom in with point sampling/nearest neighbor and look at the color contrasts. There are only differences in chroma quality between the spline4 and spline5 up-sampling in very detailed areas.

[clsid]

A tip that might help for better debugging/testing:
Use TRACE at strategic points in the code. Instruct users to download DebugView to log the output.

http://technet.microsoft.com/en-us/sysinternals/bb896647

[thuan]

@Jan: I tried your settings and right off starting playback I have this:
http://thumbnails15.imagebam.com/11883/0fced0118824650.jpg (http://www.imagebam.com/image/0fced0118824650)
My system seems not to like D3D exclusive mode, clicking OK on the error the movie starts but its color is convert to TV range which is wrong as I'm using a LCD monitor. This has been going for a while, but as I don't use it I didn't report the issue. Set aside this issue, my GFX card chroma upsampler still kicks in after that. And when I go and disable D3D exclusive mode still the same thing happens. If you want me to do more test, please do tell.

[cca]

@JanWillem32: I don't actually use overdrive, I have the checkbox unchecked. I just go the overdrive tab of the ATI Catalysts and there I can see the GPU clocks. Similar effect can be observed with 3rd party utilities, like GPU Z for example. I first noticed this behaviour over a year ago, so it is nothing new from a driver version point.

I do not know what happens on other manufacturers' cards though, this is only for AMD cards (R.I.P. ATI logo!).

[JanWillem32]

@clsid: Thanks, I'll explore this tool. Right now it seems to just detect MPC-HC starting up the detours library. Maybe after changing a few settings I'll find something interesting. There's already trace EVR, so I'll test that for another build.

@thuan: That as well? Can your computer even start games or other programs that use the exclusive mode? Can you see if VMR-9 (renderless) does the same thing with the exclusive mode? While you're at it, does VMR-9 (renderless) blur the chroma in the same way as EVR-CP?
I wonder what renderer will use limited ranges. As far as I know, none of the renderers does that by default. I'll take a look at it.

@cca: With my video card (HD 4890), I can only see it switch to idle mode (240 MHz), 2D load mode (500 MHz, too low for my usage) and 3D load mode (850 MHz). I haven't seen any dynamic changes outside of those modes, even on constant 100% GPU usage on 2D load mode, it won't go to the 3D load mode. Did you find any trick to enable more dynamic changes?

[mariush]

Is there any reason why the latest MPC-HC (1.5.0.2827,from the website) would freeze when trying to play AVS files?

I had 1.3.1249.0 , moved the folder and got the zip file from the site and renamed the executable to mplayerc.exe - every video plays just fine with the previous configuration (evr custom presenter, haali splitter, coreavc, ac3filter on win2k3 32bit, radeon 4850), except avs scripts - mpc-hc freezes and keeps two cpu cores busy...

http://savedonthe.net/image/857/mpchcavsfreeze.png

[HoP]

@JanWillem32:
please put your latest builds(MPC & Shaders)in your sig...thanks in advance

[Ger]

@Ger: The internal MPEG-2 decoder is old. I don't know much about it, but it could very well be that it just doesn't have any routines for 4:2:2 chroma sub-sampled data. I use the default Microsoft decoder, as it seems to be able to use at least IDCT DXVA mode in my situation. My video card can't do the full VLD DXVA decoding mode for MPEG2. I don't know if that decoder can do 4:2:2 structures, either.
AFAIR, Microsoft (Win7), Arcsoft, Cyberlink and MPC-HC MPEG-2 decoders all fail with 4:2:2 sources.

Mainconcept/Elecard, Dscaler and ffdshow, in addition to VLC etc. should work, but there are probably others out there as well.

Since you seem to have a good understanding of this chroma stuff, maybe you'd be willing to look into adding 4:2:2 support to the internal MPEG-2 decoder?

Anyway, if anyone is interested, here is a MPEG-2 4:2:2 sample (http://www.multiupload.com/X9JQLLLCNW).

I removed the convertor to YUY2, and gave NV12 a higher merit than YV12 and I420/IYUV. If it's preferred, I can set different merits for interlaced and non-interlaced content in future builds.
I think that would be a good idea, to be able to take advantage of the best hardware deinterlacing methods.

[cca]

@JanWillem32:

My 4850 only has 2 modes, one 2D (idle) and one 3D (max clock). The 3D mode clockspeeds are also used for DXVA. Now, when I play a video in MPC-HC I notice the clock sometimes is in 2D and sometimes in 3D, changing every few seconds sometimes. I did nothing at all for this to happen.

Also, a few weeks ago I modded my card's BIOS to lower the idle speeds. This had an unexpected effect. Now the card seems to use 3 clock speeds! Only very low, one intermediate (the original idle clock speed) and one maximum. When playing videos it switches between the intermediate and the max dynamically.

Note that the original behavior I describe in the 1st paragraph was happening even before I touched the VGA Bios, so my mod has nothing to do with it in reality.

[tetsuo55]

Is there any reason why the latest MPC-HC (1.5.0.2827,from the website) would freeze when trying to play AVS files?

I had 1.3.1249.0 , moved the folder and got the zip file from the site and renamed the executable to mplayerc.exe - every video plays just fine with the previous configuration (evr custom presenter, haali splitter, coreavc, ac3filter on win2k3 32bit, radeon 4850), except avs scripts - mpc-hc freezes and keeps two cpu cores busy...
]thats a security leak in avisynth, you need to put all the dll files next the avisynth exe afaik.


@everyone testing Janwillems builds, this forum thing doesn't seem to be working well for debugging and fixing the problems you are reporting, could you guys come on irc? http://webchat.freenode.net/?channels=mpc-hc
Chatting there would go a lot faster.

[alexins]

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

Changes (2911-2920):

cosmetics in the batch files;
Enhanced the precision of the CIE D65 white point for the color management calculations. Patch by janwillem32;
clean up ffmpeg makefile;
update libpng to v1.5.1;
Fix : truncate OSD at file open;
merge makefile_c.inc with makefile;
resized "Playback" dialog box (no clipping in most translations).;
recalculated size of the sliders "Volume" and "Balance". more precise control with the keys.;
updated russian translation;
update lcms to the latest git.

[mariush]

thats a security leak in avisynth, you need to put all the dll files next the avisynth exe afaik.


I'm sorry tetsuo55, I don't understand what you're saying. If I start the old version of the player and drag an avs file on it, it plays just fine. Trying the same on the new version fails. Can you please explain it again?

I also found some other issue with this new version. I have a MKV file with 2 ac3 tracks and both play at the same time with Matroska selected in Source Filters. Play > Audio is grayed out.

After I unchecked Matroska in Source filters and restarted the player, Haali renderer was used and took care of the file and I can select again from the Haali properties which audio to play.

[GTPVHD]

H.264 software decoder is broken in 1.5.1.2920 build on Athlon XP, works fine on Core 2 CPU. Which is weird since it works fine on 2910 and there's no changes that I can think of between 2910 and 2920 that could have cause this.

http://img232.imageshack.us/img232/7917/2920broken.png

http://img710.imageshack.us/img710/6382/2910ok.png

This could be a GCC 4.5.3 compiler bug, 2910 was compiled with Cross-Mingw with GCC 4.5.3 (Pre-Release, svn rev. 169526, 2011.02.02) x86_32) while 2920 was compiled with Cross-Mingw with GCC 4.5.3 (Pre-Release, svn rev. 169972, 2011.02.09) x86_32).

[thuan]

@Jan: My replies are in bold.

@thuan: That as well?
Yes, when I have D3D exclusive mode enabled in conjunction with 10-bit output, if I disable either of them it works normally.
Can your computer even start games or other programs that use the exclusive mode?
Yes, finished Dead Space 2 recently. I got a SSD recently and reinstalled Windows then, but this error has been there before the reinstall and as I can play games fine before and I always leave my GFX card settings at default. It might be a problem with my configuration.
Can you see if VMR-9 (renderless) does the same thing with the exclusive mode?
Yes, it has the same behavior.
While you're at it, does VMR-9 (renderless) blur the chroma in the same way as EVR-CP?
Yes, it always kicks in.

I wonder what renderer will use limited ranges. As far as I know, none of the renderers does that by default. I'll take a look at it.

[alexins]

H.264 software decoder is broken in 1.5.1.2920 build on Athlon XP, works fine on Core 2 CPU. Which is weird since it works fine on 2910 and there's no changes that I can think of between 2910 and 2920 that could have cause this.

http://img232.imageshack.us/img232/7917/2920broken.png

http://img710.imageshack.us/img710/6382/2910ok.png

This could be a GCC 4.5.3 compiler bug, 2910 was compiled with Cross-Mingw with GCC 4.5.3 (Pre-Release, svn rev. 169526, 2011.02.02) x86_32) while 2920 was compiled with Cross-Mingw with GCC 4.5.3 (Pre-Release, svn rev. 169972, 2011.02.09) x86_32).
The problem was introduced in Rev. 2916:
OPTFLAGS += -O2 -march=pentium4 -msse -mfpmath=sse
Dear developers, be careful with keys optimization, particularly with key -march !!!

But remember, by using these flags, binaries from your system might not work on another one with a different CPU. So if you compiled with optimizations for a Pentium 4 (-march=pentium4), you can't share a hard disk or packages with a friend who only has a Pentium MMX (-march=pentium-mmx). Though the other way around should work, see below.
This is the case if you are using the -march flags. If you use -mtune instead without any -march option, your binaries are backward compatible down to i386, but the scheduling is optimized for your chosen architecture. CPUs are also backward compatible so if you update your system with a new CPU you can still use your old packages. There is one exception though; if your old CPU supports a feature, like AMD's 3dnow, that your new CPU doesn't. So if you have an athlon (-march=athlon) and upgrade to a pentium4 your old packages might not work. You can mix -march and -mtune if you, for example, would like to create binaries that would run on any i686 but are optimized for a pentium4. This would be accomplished by using -march=i686 and -mtune=pentium4.

3.17.15 Intel 386 and AMD x86-64 Options (http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options)

P.S.
The -mfpmath = sse, doesn't always work correctly, sometimes it leads to problems!!!

[skingery]

Hi Everyone, been watching for a while. Still trying to get a handle on all the technical details. Feeling pretty much like a noob so bear with me.

The first thing I want to understand is the resizer drop down under Playback - Output using EVR CP. Is it correct these are different methods of resizing? And that quality is best at Bicubic A=-1.00? And that nearest neighbor would be the least taxing on GPU and Bicubic A=-1 would be the most taxing? So, depending on your hardware would want to experiment with what it will handle the smoothest?

Thanks in advance for your help!
Scott

[Hera]

@JanW - Thuan provided a screenshot of the exact issue I am experiencing with your builds. Older versions work just fine. Fullscreen games like FO3 or Portal work fine. By reduced quality, I just meant just that which others reported it seems.
@tetsuo55 - If I see JanW there, I will.

[god_md5]

That's the black screen bug. Try one of my nightly builds, I've solved most of the causes of it. http://forum.doom9.org/showthread.php?p=1476526#post1476526
It will take some time before the fixes are integrated into the source code. We need to solve other mixer problems first.
my test ver is 2917 form xhmikosr (black screen bug)
you compile ver have other bug(JanWillem32 in post the comilpe x86 ver 2917)
xhmikosr and xvidvideo ver 2917 is ok
i use win7 x64,and ati xt2600 ,driver 11.1,cpu is q9400
http://img843.imageshack.us/img843/3402/screenhunter02feb101314.jpg

[Aleksoid1978]

The problem was introduced in Rev. 2916:
OPTFLAGS += -O2 -march=pentium4 -msse -mfpmath=sse
Dear developers, be careful with keys optimization, particularly with key -march !!!

But remember, by using these flags, binaries from your system might not work on another one with a different CPU. So if you compiled with optimizations for a Pentium 4 (-march=pentium4), you can't share a hard disk or packages with a friend who only has a Pentium MMX (-march=pentium-mmx). Though the other way around should work, see below.
This is the case if you are using the -march flags. If you use -mtune instead without any -march option, your binaries are backward compatible down to i386, but the scheduling is optimized for your chosen architecture. CPUs are also backward compatible so if you update your system with a new CPU you can still use your old packages. There is one exception though; if your old CPU supports a feature, like AMD's 3dnow, that your new CPU doesn't. So if you have an athlon (-march=athlon) and upgrade to a pentium4 your old packages might not work. You can mix -march and -mtune if you, for example, would like to create binaries that would run on any i686 but are optimized for a pentium4. This would be accomplished by using -march=i686 and -mtune=pentium4.

3.17.15 Intel 386 and AMD x86-64 Options (http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options)

P.S.
The -mfpmath = sse, doesn't always work correctly, sometimes it leads to problems!!!

Hi. what flag do you use for your build ???

[tetsuo55]

I'm sorry tetsuo55, I don't understand what you're saying. If I start the old version of the player and drag an avs file on it, it plays just fine. Trying the same on the new version fails. Can you please explain it again? a while ago we commited some security fixes for exploits. One of the exploits has to do with dll's loaded from a non standard directory. Many people have avisynth dll's and avsi files spread accross the computer. so you need to have all your files next to avisynth.exe (except for the .avs)

I also found some other issue with this new version. I have a MKV file with 2 ac3 tracks and both play at the same time with Matroska selected in Source Filters. Play > Audio is grayed out.

After I unchecked Matroska in Source filters and restarted the player, Haali renderer was used and took care of the file and I can select again from the Haali properties which audio to play.Sounds like the audio splitter is disabled, i suggest resettings you settings, click on the word "bugs" in my signature for instructions.

H.264 software decoder is broken in 1.5.1.2920 build on Athlon XP, works fine on Core 2 CPU. Which is weird since it works fine Minimum CPU requirement for official builds is a Pentium4 or Athlon64.
You can use what alexins said to create a custom build that does on athlonXP
@tetsuo55 - If I see JanW there, I will.He's there most of the time
my test ver is 2917 form xhmikosr
you compile ver have other bug
xhmikosr and xvidvideo ver is ok
i use win x64,you ver 2917 x86,and ati xt2600 ,driver 11.1
can you explain in a bit more detail which version causes what behaviour? for example from which build is that screenshot?

See "bugs" in my signature for more info.

[GTPVHD]

Tetsuo, I don't compile MPC-HC, I use alexins' builds for testing and this is short sighted. A lot of people still use MPC-HC 1.x, you shouldn't bump the requirements to SSE2 CPUs for very minimal gains. If you do that for the next major version like 2.0/3.0/whatever I can understand but 1.x should always be compatible with SSE CPUs.

[Dstruct]

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

Changes (2911-2920):

Enhanced the precision of the CIE D65 white point for the color management calculations. Patch by janwillem32;
update lcms to the latest git.


Cool. But Color Management isn't working anymore at all with this build. It gets grayed out on playback start and isn't becoming active (seen in Playback Stats). Same with (Half) Floating Point Processing option(s).

Was fixed by JanWillem32 here: http://forum.doom9.org/showthread.php?p=1473873#post1473873

[tetsuo55]

Tetsuo, I don't compile MPC-HC, I use alexins' builds for testing and this is short sighted. A lot of people still use MPC-HC 1.x, you shouldn't bump the requirements to SSE2 CPUs for very minimal gains. If you do that for the next major version like 2.0/3.0/whatever I can understand but 1.x should always be compatible with SSE CPUs.We removed SSE support a long time ago, its just only recently become noticable. higher performance is only one of many reasons.

I do see your point and i suggest the following:
The community works together to help make a wiki page that explains how to compile for legacy systems. that way some of the nightly builds can still be used on older hardware and os's.

I am aware of 3 required changes.
1. Remove forced SSE2 settings
2. Remove forced DEP settings
3. Comment out DVD related code that makes mpc-hc crash on win2k

We will not support builds created through this page!

[betaking]

We removed SSE support a long time ago, its just only recently become noticable. higher performance is only one of many reasons.

I do see your point and i suggest the following:
The community works together to help make a wiki page that explains how to compile for legacy systems. that way some of the nightly builds can still be used on older hardware and os's.

I am aware of 3 required changes.
1. Remove forced SSE2 settings
2. Remove forced DEP settings
3. Comment out DVD related code that makes mpc-hc crash on win2k

We will not support builds created through this page!

2. Remove forced DEP settings
+1! A lot of people don not like dep!

[GTPVHD]

I don't care about DEP changes, DEP should always be on for security reasons or the Win2k changes since MPC-HC hasn't been supported or worked on Win2k since 1.4.2499.0, but making MPC-HC 1.x incompatible with SSE CPUs just by using -march=pentium4 compiler option is really short sighted decision. You're just gonna alienate a lot of users. Also most people just pull down the code and compile it, they're not gonna change anything so your wiki guide page idea is unrealistic.

But since the MPC-HC team has decided to give up all those users to VLC, I'm not gonna comment anymore on this matter.

[tetsuo55]

But they do love virusses and trojans! haha:p

[tetsuo55]

I don't care about DEP changes, DEP should always be on for security reasons or the Win2k changes since MPC-HC hasn't been supported or worked on Win2k since 1.4.2499.0, but making MPC-HC 1.x incompatible with SSE CPUs just by using -march=pentium4 compiler option is really short sighted decision. You're just gonna alienate a lot of users. Also most people just pull down the code and compile it, they're not gonna change anything so your guide page idea is unrealistic.The SSE2 decision is based on many factors, the most important ones are that msvc2010 cannot compile for SSE1, SSE2 offers a considerable improvement in performance and we don't support hardware older than 5 years.
But anyone is free to join the team and be the legacy developer person! maybe we can decide on hosting an official x86 sse legacy build, as long as the main team members are not the one releasing it.

[GTPVHD]

MSVC2010 SP1 compiles SSE just fine, alexins' 2910/2920 builds all use SSE if you see the About screen. The compiler bug with MSVC2010 has been fixed in SP1, just so you know. That's my last comment on this.

[betaking]

But they do love virusses and trojans! haha:p

I think you mentioned that the DEP settings to remove just remove the MPC-HC in the relevant code, rather than a complete shutdown of the operating system in the DEP! This did not have any impact on the safety! And I found a problem. In XPSP2 OR XPSP3 both operating systems use the code open the DEP of the MPC-HC. (The two systems are enabled by default DEP's) does not appear random CRASH. On the contrary if it is in VISTA or WIN7 two operating systems, but will appear randomly CRASH! In addition, I have a suggestion if it is SVN daily updates DEP code without removing the relevant code. But if it is officially released version of the relevant code can be removed DEP!
PS: DEP does not provide much of the help system security. Anti-virus software and network firewalls is you need most!
:)

[Dstruct]

DEP should stay enabled. Users that don't want it still can disable it.



This way is the one to avoid:

Having DEP forced on on the system but the application not being DEP aware.

[tetsuo55]

Indeed if people have problems with DEP it will be because they have one or more DEP incompatible applications.
The crashes betaking mentiones are caused by non-DEP aware filters and/or dll's.

I'm not 100% sure but i think reclock is an often crasher that is not DEP aware.

@GTPVHD I've asked the team to think about the SSE vs SSE2

[GTPVHD]

Tetsuo, your legacy SSE build idea is an acceptable compromise. Also, you should communicate changes like this months in advance instead of letting people know only after release.

[tetsuo55]

We changed the support level almost a year ago, i didn't even know we still had SSE users :P

[nevcairiel]

There hasn't been a new CPU for nearly 8 years (P4 in 2001, Athlon64 in 2003) now that did not support SSE2. At some point, you should realize that your way outdated hardware won't be able to run the up-to-date software anymore. Your system is probably not fast enough to take advantage of the new enhancements anyway, so could as well stick with the last SSE release, imho.

How about we disable SSE as well, so you can run stuff on your Pentium2?
You have to draw the line somewhere. And 8 years is a long time in the PC industry, so imho requiring SSE2 is totally acceptable.

Same with OS support. Anything below XP SP3 is not officially supported anymore, as even MS gave up on those.

[GTPVHD]

Look, I have Core 2 machines, no need to attack me just because I tested the latest builds on an old Athlon XP which worked fine until 2916 changes.

Also Pentium 4 was released in 2000, 11 years ago and Athlon 64 was released in 2003, 8 years ago. Since you all don't support hardware older than 5 years old, aka stuff released in 2006 which would be Core 2 minimum, with your logic why not disable support for Pentium 4 and Athlon 64/X2 CPUs then?

[nevcairiel]

Attack? Right.

5 years is just a guideline, as you yourself said, its 8 years right now.
In any case, SSE3 does not offer a significant upgrade like SSE2 does.
The decoders are already able to use SSE3, as they have runtime checks and use custom written assembly.
Just the parts that are not hand optimized get optimized by the compiler, and that is told to use SSE2 if possible.

[GTPVHD]

The SSE2 decision is based on many factors, the most important ones are that msvc2010 cannot compile for SSE1, SSE2 offers a considerable improvement in performance and we don't support hardware older than 5 years.

I know tetsuo didn't really mean this but anyway. :p

Lets just drop this, it's not really important anyway.

[clsid]

There is very little C/C++ code in MPC that can benefit from forcing SSE(2) in the compiler. Most CPU an data intensive code already uses hand-written assembly code.

We have tested it several times in ffdshow and came to the conclusion that for general decoding forcing SSE(2) has no real benefits at all. It only helped for a select few data intensive processing algorithms, none of which are used by MPC. An example of the few filters was Deband, which is now even implemented using runtime cpu dectection, making it even less useful to force SSE in ffdshow.

I suggest adding a simple benchmark option to MPC:
mpc-hc.exe /benchmark some_test_file.mkv

This should do something like this:
1) open MPC
2) open file
3) start timer
4) play file
5) close file at end of playback
6) stop timer
7) write duration to STDOUT
8) close MPC

Perhaps even a /benchmark=X to play the file X times and output the duration X times. So repeating steps 3-7.

[bobdynlan]

I suggest adding a simple benchmark option to MPC:
mpc-hc.exe /benchmark some_test_file.mkv

This should do something like this:
1) open MPC
2) open file
3) start timer
4) play file
5) close file at end of playback
6) stop timer
7) write duration to STDOUT
8) close MPC

Perhaps even a /benchmark=X to play the file X times and output the duration X times. So repeating steps 3-7.
Download Batch Launcher - a cmd script (http://cid-d561cc7d122f3f32.skydrive.live.com/redir.aspx?resid=D561CC7D122F3F32!115)
1. copy bl.cmd to SendTo folder (%AppData%\Microsoft\Windows\SendTo in W7 or %USERPROFILE%\SendTo in XP)
2. right click the first mpc-hc.exe to test, and choose bl.cmd from the SentTo menu.
3. at the parameters prompt, add something like this:
C:\XFILES\SHARED\t3.vob /play /close
4. wait for the playback to finish - you should choose a short file like 30 seconds for benchmarking (can measure up to 24h).
5. check out the summary in the cmd window
6. repeat from step 2 with another mpc-hc.exe build. At 3, just press enter to use the saved parameters.

Sample output (file) from this batch file:
mpc-hc.exe C:\XFILES\SHARED\t3.vob /play /close RunAs:N
Started 17:29:47.13 Thu 02/10/2011
-------------------------------------------------


-------------------------------------------------
Finished in 0:00:25.87 ~ 25.87 seconds


Another usage would be to launch a file to a specific position and pause, for consistent screenshots
C:\XFILES\SHARED\t3.vob /open /start 182000

[nevcairiel]

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.

[bobdynlan]

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. Not true. The total time of playing a 30 second file will be 30 seconds + some overhead of less than a second. But if you use another decoder/splitter/option this might change drastically - stuff like stutters and frame drops also come into play. How about that Crowd run file :)

[Hera]

I use Athlon XP 3000+ for 360p - 720p content. XP SP3, NV 6600.

[Sina™]

when i add external filters (cyberlink) restart mpc, mpc doesn't save them. (drm?)
v1.5

[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.

[thuan]

@Jan: I took a look at your screenshots, the most noticeable changes are from none to blur then spline4 but I didn't notice much different between spline4 and spline5, the most noticeable set is the Dreamworks set and the less is the Panda set. My monitor is DELL U2311 IPS LCD, calibrated.

[JanWillem32]

The processing difference between spline4 and spline5 is really small, too. Both filters fit into the PS 2.0 level after separation of the HD and SD types. I can also make optimized, separated shaders for usage with Half and Full Floating Point Processing (the sign and exponent bits are quite useful when storing chroma data), if there's enough interest for it.
For what I know, only the windowed sync filers (Lanczos and other types of filters) can be sharper, but with over-saturation in ringing patterns as extra artifacts.
The picture from Kung-Fu Panda is actually the prime example of a picture that suffers heavily under chroma down-sampling. In the central part of the picture, there's massive color bleeding into the grayish frame from the red and green pattern inside of it. The fireworks on the teal sky produce saturation bleeding. If you look closely, many of the pieces of firework have a darker center, making it even more obvious.

[jeremy33]

JanWillem32 do you know when the black screen bug will be fixed ?

[JanWillem32]

The black screen on exit bug requires a moment of inspiration of how to perform a correct reinitialization when exiting the D3DFS 10-bit mode. I've already tried a few different methods to try to solve it, but it seems that none of the commands work at all. When returning to the desktop, only the commands that reload either the regular or the safe video driver work properly to reset the black screen. I'm wondering if the "reload display driver" function as available in both the nVidia and AMD contol panels could be called during the end rendering sequence. Note that this problem exists from the moment that the 10-bit output item was created.
The mixer black screen problem should be gone after my last change to prefer complete software conversion to RGB32 if NV12, YV12 and I420/IYUV are not available for mixing 4:2:0 chroma video. This is for internal codecs only, external codecs communicate directly to the mixer, so it's a bit harder for the program to do software conversions for that. This means that some external codecs will always fail with the EVR mixer with certain hardware.

[jeremy33]

My problem is the mixer black screen problem with the option Half Fp or Full Fp with ffdshow output set to rgb32.

With internal filters no problem. Without the option Half Fp or Full Fp with ffdshow output set to rgb32 no problem.

[JanWillem32]

Does the mixer enumerate R8G8B8, X8R8G8B8, A8R8G8B8, X8G8G8R8 or X8G8G8R8? You can force a single frame to render with a single left-click after activating the statistics screen.
I can imagine that the mixer would refuse to only do RGB to RGB conversion. I don't recommend any lossy conversions like this after decoding and before mixer input, unless the GPU really can't handle proper Y'CbCr format mixing.
I posted this before:
When using ffdshow tryouts, it's usually best to let the mixer do a lot of the conversion work. In the output tab of the video decoder, use "Set pixel aspect ratio in output media type", "Set interlace flag in output media type" and "Allow output format changes during playback".
The next problem is the actual supported output types. I420/IYUV and YV12 are often refused by EVR, that leaves only NV12 as an option for 4:2:0 chroma sub-sampled video. Unfortunately, YUY2, YVYU and YUYV are selected by default instead. The only solution to that, is to disable those formats. Only enable YUY2, YVYU or YUYV if you want to play an actual 4:2:2 chroma sub-sampled video (not very common).
That should make a good NV12 connection without any chroma conversions before the mixer.

[jeremy33]

This is what I get with the option Half Fp or Full Fp with ffdshow output set to rgb32 with mpchc 2937.
http://img204.imageshack.us/img204/4124/pressepapiers1q.th.jpg (http://img204.imageshack.us/i/pressepapiers1q.jpg/)

If I set ffdshow to NV12 it worked but the mixer output NV12, is it normal. It should output RGB32 no ?

http://img571.imageshack.us/img571/2324/pressepapiers2.th.jpg (http://img571.imageshack.us/i/pressepapiers2.jpg/)

[JanWillem32]

NV12 is perfectly fine to use, if your input is 8-bit, 4:2:0 chroma sub-sampled. It means that the decoder delivers a matching format to the mixer. You can check the properties of an input file with either File, Properties (internal MediaInfo data), or use MediaInfo externally. The download is available on http://mediainfo.sourceforge.net .
The internal codecs will often use NV12 for the EVR mixer as well.

[jeremy33]

Ok thank you I will use NV12 in ffdshow output.

[Virtual_ManPL]

Should this new MPEG splitter options
http://img808.imageshack.us/img808/5465/45766340.png

share setting with this ?
http://img15.imageshack.us/img15/3804/82803193.png

[Aleksoid1978]

Should this new MPEG splitter options
http://img808.imageshack.us/img808/5465/45766340.png

share setting with this ?
http://img15.imageshack.us/img15/3804/82803193.png

No - MPEG Splitter has own settings, different from player.

[Virtual_ManPL]

Odd... but it will be wise to keep this options in one tab

[clsid]

The black screen on exit bug requires a moment of inspiration of how to perform a correct reinitialization when exiting the D3DFS 10-bit mode. I've already tried a few different methods to try to solve it, but it seems that none of the commands work at all. When returning to the desktop, only the commands that reload either the regular or the safe video driver work properly to reset the black screen. I'm wondering if the "reload display driver" function as available in both the nVidia and AMD contol panels could be called during the end rendering sequence. Note that this problem exists from the moment that the 10-bit output item was created.
The mixer black screen problem should be gone after my last change to prefer complete software conversion to RGB32 if NV12, YV12 and I420/IYUV are not available for mixing 4:2:0 chroma video. This is for internal codecs only, external codecs communicate directly to the mixer, so it's a bit harder for the program to do software conversions for that. This means that some external codecs will always fail with the EVR mixer with certain hardware.
Are there still any known problems when 10bit and FP processing options are disabled?

When exactly is colorspace conversion used? I hope not during "simple" playback, because that used to work fine with for example YV12. My concern is that playback without the new fancy renderer settings should work at least as good as before your changes. I can understand that features like 10bit have stricter requirements for the mixer, but if so, those requirements should only be enforced when the 10bit option is enabled.

May I suggest labeling the experimental features as experimental, so that novice users do not accidentally enable them. For example, simply add " (experimental)" to the end of the option strings.

[JanWillem32]

The EVR mixer requires format-to-format support from the video card and its drivers. For example on my system, I can't use YV12 or I420/IYUV because it has always been refused by my hardware, even for "simple" playback. (The same goes for any other format that doesn't support interlacing probably.)
Since I made the convertor to NV12 and re-ordered the mixer format merit list, I haven't had black screen reports from people that use the internal codecs, even with advanced features enabled. I did get 3 reports about completely distorted output with floating point options enabled. With none of those cases I had the chance of in-depth analysis, and the hardware configurations, settings and distortion form were totally different.
For the internal codecs, conversion options have always been present. These currently are: YV12 to IYUV/I420, IYUV/I420 to YV12, YV12 to NV12, IYUV/I420 to NV12, YV12 to RGB32, IYUV/I420 to RGB32, YUY2 to RGB32 and some RGB to RGB conversions that are limited to 8-bit or less. Y'CbCr conversions to RGB before the mixer have a low merit, because those are lossy conversions and are in many cases incompatible with any surface format above 8-bit RGB.
External codecs will have the same kind of problem, if no suitable format is presented to the mixer, it will fail. The 8-bit RGB to higher bit depth RGB conversion problem described by jeremy33 is a known problem on some hardware, but easy to solve.
The "fancy" functions I added are not exactly new. I just removed all hard-coded 8-bit RGB problems. The main video renderer is now capable of 32-bit in the mixer up to the backbuffer. (Backbuffer and display format are limited to 10-bit maximum.) That's not the case for the main video rendering path of the build in the SVN. For other renderers, I still have to work on the font renderer that uses A4R4G4B4 and the subtitle and OSD renderers that use A8R8G8B8. (Also with a heavy impact on CPU resources.)
It's maybe a bit odd, but I like it when novice users try out, mess up settings and just ask what went wrong.

[chogster]

Guys,

I'm getting seriously high GPU usage (80%+) and unstable playback on a HD5450 with Full Float Processing Point enabled on the newer versions of MPC-HC. Is this a known issue?

Having reverted to version 2833, GPU usage remains between 35-45%.

Cheers

[JanWillem32]

How many filtering options do you enable? I must say that the "Full Float Point Processing" is really not the same thing as it used to be. It's not an issue, this item just enables more processing than it used to.
Try setting the video card to 3D GPU clock speeds, or near it and see if that helps. There's else the option to use Half Float Point Processing or only 10-bit RGB output instead.

[cca]

@JanWillem32: Anything you can do to improve the subtitle renderer's speed will be appreciated, one the reasons I switched to MPC-HC was the ability to render HQ subtitles regardless of the video resolution, since the subtitle texture has it's own resolution. Also, the fact that maintains compatibility with the visual result of DirectVobSub is a big plus, since that engine and MPC's was written by the same person initially. As it is apparent, that engine is outdatted and slow today, can't use more than one CPU core either.

I don't expect you to rewrite the entire engine, probably too big of a project, but any improvements in speed (and in quality, as long is won't become slower!) are welcome. My primary video kind are japanese anime, and most of them have ass styled subs, even soft-karaoke and the such, demanding a lot from the subtitle renderer, so you can understand why I wrote this message!

[v0lt]

Odd... but it will be wise to keep this options in one tab
No.

Mpeg-splitter has only one pin for audio. The player does not see all audio tracks.

Other splitters have a number of pins equal to the number of tracks. The player sees all audio tracks and can switch between them.

[thuan]

@cca: which kind of subtitle that caused slowdown on your computer? I also do watch a lot of Japanese animation with soft subs, karaoke or other effects and it still doesn't feel slow on my supposed weaker computer. It is nice to have more CPU cycles for other stuffs but for now I don't think the sub renderer needed to be changed right away, at least after all the new features Jan is doing have been completely mature.

[nevcairiel]

No.

Mpeg-splitter has only one pin for audio. The player does not see all audio tracks.

Other splitters have a number of pins equal to the number of tracks. The player sees all audio tracks and can switch between them.

Could still be the same settings. Having to configure it in 5 places is the worst design ever.

[Virtual_ManPL]

Exactly...
and searching for nearly the same option in different places is not a good idea

@ v0lt - Yes :devil:

[cca]

@cca: which kind of subtitle that caused slowdown on your computer? I also do watch a lot of Japanese animation with soft subs, karaoke or other effects and it still doesn't feel slow on my supposed weaker computer. It is nice to have more CPU cycles for other stuffs but for now I don't think the sub renderer needed to be changed right away, at least after all the new features Jan is doing have been completely mature.

Not every one I watch performs so slow, but there are some cases that clearly tax the CPU. Lately most subbers go easy on the effects because they know most systems can't handle it anyway.

[Virtual_ManPL]

I can post sample of high CPU hog subtitles
http://www.megaupload.com/?d=SB6Y47LD (try complex karaoke version)

[JanWillem32]

I'm already busy with the subtitle renderer. http://forum.doom9.org/showthread.php?p=1475856#post1475856
As a first step, I'm trying to get the bitmap-based subtitles to render with the internal scalers on a proper surface, instead of using the same rendering path of the vector-based subtitles.
Bitmap-based subtitles need a good scaler, like the normal video rendering path, but with alpha channel (transparency) support. Vector-based subtitles do not need full image scaling at all (it's forced on bilinear fitering right now), but could use anti-aliasing (such as ClearType). It's unfortunate that the subtitle renderer seems to break with every change I make. It might take a full re-write of two subtitle renderers and the font renderer to get it working properly.

[jeremy33]

JanWillem32, I have a problem with your solution (output of ffdshow in NV12) because I can't use Input/Output levels & YCbCr specification in ffdshow and the colors are wrong.

So what can I do ?

[JanWillem32]

First check the video card's control panel. A lot of video settings (even some that are set by default) mess up proper video playback.
On the "RGB conversion" tab of ffdshow, use the "reset" function. Those settings are correct.
As a last item: check for chroma up-sampling. http://forum.doom9.org/showthread.php?p=1463132#post1463132 If the chroma is blocky, you can up-sample chroma with one or two of my pixel shaders (not integrated yet).
There might be other things that are wrong in your case, just post descriptions of the specific problems and we'll see what we can do.

[Hera]

The same 10-bit error is there.

Out of curiosity, how does WMP manages sometimes less than 10% CPU when playing a 15FPS 720p MP4 on my netbook?
MPC:HC manages a minimum of 20% playing the same video.

[JanWillem32]

I can imagine that's because WMP uses the default EVR with DXVA.

[chros]

Can someone post a calibration file for my LCD TV and MPC?
(I'm watching HD content on it.)
My TV has the following options:
- brightness, contrast
- rgb colors adjustment

(In nvidia control panel I haven't any calibration wizard on my laptop ...)

Thanks!

[jeremy33]

There is only one thing that not work, it's the ffdshow tab "rgb conversion" with "yCbcr specification" because the output is NV12 so tab "rgb conversion" is simply bypassed.

[JanWillem32]

@chros: All display devices have unique characteristics and will wear out in time. Professionals calibrate monthly with calibration devices and calibration patterns. Those are a bit expensive. For a less expensive option, you can download a lot of things to help with manual calibration.
Some good samples: http://www.avsforum.com/avs-vb/showthread.php?t=948496 .
I do not recommend using .ICC or .ICM files made from other display devices other than your own, as they will never match.

@jeremy33: Y'CbCr to RGB in 8-, 10-, 16- or 32-bit conversion is a mixer task (along with some other functions). It's not something that should be done by anything before the mixer (such as the video decoder). That is unless the GPU can't use use YV12, I420/IYUV or NV12 at all.
Can you post descriptions of the specific problems? At the moment I don't know if it's defective drivers, hardware, software, source files or a calibration problem of your display device.

[jeremy33]

Here are all my old settings, before I switch to NV12, (with ffdshow and evr custom) -> HomeCinema-HD - HTPC Video playback with MPC-HC, ffdshow and Reclocks (http://www.homecinema-hd.com/intro_en.html)

Until the version 2833 of mpchc the quality was really good, everything worked perfectly.

But now with NV12 the color are not good because I used the "rgb conversion tab" to set the "yCbcr specification" with the different profil in ffdshow. I just send NV12 to the renderer but it don't find the right "yCbcr specification".

I hope it's clear ;)

[JanWillem32]

Good grief, they set even more filters in that guide than I set shaders. (I do that because I'm a developer and I really don't like digital image modification/filtering outside of the mixer and renderer.)
In general, ffdshow is perfectly well capable of detecting correct ranges, and HD or SD Y'CbCr settings. The same thing applies for both the VMR-9 and EVR mixers.
You can test for correct basic Y'CbCr ranges with the "Misc Patterns\A - Additional\4-Color Clipping.mp4" file from the MP4 package on http://www.avsforum.com/avs-vb/showthread.php?t=948496 . I think that's a good start to check. Ignore the numbers, those are only correct for the luma values in the grayscale. The final three color bars should be the ones left of the central strip and be barely visible (in line with 233). That is the most common error that affects Y'CbCr handling I can think of.
Now I see something else in that guide, too. Scaling is used, and if you scale to near or over HD resolutions, when no stream information is available, BT.709 is always selected. In that case, just disable the scaling. MPC-HC can scale with 6 different options, and a few more if you also count the scalers in my shader package.

[jeremy33]

This is my guide and as you can see in Before / After part the quality is really good.

This is my result with 1080p "Misc Patterns\A - Additional\4-Color Clipping.mp4" file. So no resize by ffdshow (just by mpchc because I'm on my pc screen 1440x900).

EVR custom (with Full Float Point Processing) + ffdshow NV12
http://img137.imageshack.us/img137/8901/nv12.th.jpg (http://img137.imageshack.us/i/nv12.jpg/)

EVR custom (without Full Float Point Processing) + ffdshow RGB32 with ffdshow yCbcr specification to BT.709
http://img835.imageshack.us/img835/534/rgb32.th.jpg (http://img835.imageshack.us/i/rgb32.jpg/)

EVR custom (with Full Float Point Processing) + Internal Filter
http://img405.imageshack.us/img405/3690/evrinternal.th.jpg (http://img405.imageshack.us/i/evrinternal.jpg/)

madVR + ffdshow YV12
http://img695.imageshack.us/img695/5025/madvrffdshow.th.jpg (http://img695.imageshack.us/i/madvrffdshow.jpg/)

madVR + Internal Filter
http://img210.imageshack.us/img210/9641/madvrinternal.th.jpg (http://img210.imageshack.us/i/madvrinternal.jpg/)

[JanWillem32]

That's the oddest luma/chroma clipping I've seen in a while. I can reproduce it only with simulating some inverted Y'CbCr ranges of <16-235> <0,255>, <0,255>.
In the Catalyst Control Center, under "Video settings" disable everything but "Use application settings", "Use automatic deinterlacing", "Pulldown detection" and "Apply current video quality settings for Internet video". That disables driver based color controls for video on AMD graphics.
Are you using one of my test builds or one from another source? I eliminated the setting for the broken "16 - 235" item of the "Renderer Settings", "Output Range" item. Only "0 - 255" works. Maybe that's an issue, too.

[SamuriHL]

That's the oddest luma/chroma clipping I've seen in a while. I can reproduce it only with simulating some inverted Y'CbCr ranges of <16-235> <0,255>, <0,255>.
In the Catalyst Control Center, under "Video settings" disable everything but "Use application settings", "Use automatic deinterlacing", "Pulldown detection" and "Apply current video quality settings for Internet video". That disables driver based color controls for video on AMD graphics.
Are you using one of my test builds or one from another source? I eliminated the setting for the broken "16 - 235" item of the "Renderer Settings", "Output Range" item. Only "0 - 255" works. Maybe that's an issue, too.

Personally I set a RGB 0-255 pixel format and set dynamic range to 0-255, as well. This has always given me the best color (except with 11.1...that driver was messed up). I do agree with disabling all those video settings, though. They tend to cause some issues. *ESPECIALLY* dynamic contrast. That one is evil. :)

[jeremy33]

The settings of catalyst are already exactly like you describe.

My build is from xvidvideo.ru (2937) and it's already 0-255 in renderer settings.

So if I understand, this is ok :

EVR custom (without Full Float Point Processing) + ffdshow RGB32 with ffdshow yCbcr specification to BT.709
http://img835.imageshack.us/img835/534/rgb32.th.jpg (http://img835.imageshack.us/i/rgb32.jpg/)

madVR + ffdshow YV12
http://img695.imageshack.us/img695/5025/madvrffdshow.th.jpg (http://img695.imageshack.us/i/madvrffdshow.jpg/)

madVR + Internal Filter
http://img210.imageshack.us/img210/9641/madvrinternal.th.jpg (http://img210.imageshack.us/i/madvrinternal.jpg/)

And this is not ok :

EVR custom (with Full Float Point Processing) + ffdshow NV12
http://img137.imageshack.us/img137/8901/nv12.th.jpg (http://img137.imageshack.us/i/nv12.jpg/)

EVR custom (with Full Float Point Processing) + Internal Filter
http://img405.imageshack.us/img405/3690/evrinternal.th.jpg (http://img405.imageshack.us/i/evrinternal.jpg/)

So the renderer does not work like it should ?

[jeremy33]

With the version 2833 it's ok ! The renderer convert NV12 to RGB32.

With the last version with EVR custom (without Full Float Point Processing) + ffdshow NV12 it's work !

[JanWillem32]

I've included a tester build deviated from r2941 in my folder. Maybe that one changes things for you?
I haven't seen such a big luma/chroma problem before, and I'm really wondering why it's happening on your system. If the tester build doesn't solve it, would you be able and willing to come to the #mpc-hc IRC channel?

[jeremy33]

I test your build and it doesn't work. How can I come to #mpc-hc IRC channel ?

[JanWillem32]

You can use http://webchat.freenode.net/?channels=mpc-hc , or install an IRC client and go to irc.freenode.net and open the #mpc-hc channel. Other visitors are of course always welcome, too.

[ikarad]

I test your build and it doesn't work. How can I come to #mpc-hc IRC channel ?

Good morning, could you give me the file of the example above to test on my computer?
Thanks.

[jeremy33]

ikarad read this message : http://forum.doom9.org/showpost.php?p=1479091&postcount=16304

[ikarad]

ikarad read this message : http://forum.doom9.org/showpost.php?p=1479091&postcount=16304

Thanks.

[ikarad]

It's maybe a bit odd, but I like it when novice users try out, mess up settings and just ask what went wrong.

Janwillem32, I have one question.

With evr custom, when I use mpc-hc under xp sp3 I have rgb32 under mixer output. With vista I have nv12. Why?

example under xp sp3
http://img696.imageshack.us/img696/7130/23927200.th.jpg (http://img696.imageshack.us/i/23927200.jpg/)

[janos666]

New CMS Test (v5): MPC-HC 2941 x86 (MSVC2010SP1 SSE2) (http://www.mediafire.com/?oo6ifpojxj8oi0c)

The Inverse Encode curve is now "scaled" according to the CIECAM02 color appearance model.

The additional calculation takes significantly longer time than the usual (may be you will think the playback would never start ; however the pure-power TRC presets aren't affected by these changes) but I recommend to use the Medium (or High) quality with the Inverse Encode TRC setting anyway (because this TRC is probably far from your current display TRC).

The CIECAM02 parameters are not "fine tuned" yet. But I would hear your opinions about the current state. (I think the Dark ambient light preset is the best now.)

I don't think I can speed up the CIECAM02 calculations myself (may be nobody could without touching the lcms engine itself ; or implement a different code for this step [other than the lcms function] ; or "break" the old state).


There were some compatibility problems between some CMS settings and the CIECAM02 features. I think I solved those problems but it is possible that some unlucky combination won't work as intended.
For example: Absolute rendering intent + Medium WP Adaptation State + Inverse Encode TRC. (Again, the Pure-Power curves aren't affected by these changes. ; And some feature will work with cLUT profiles only.)
---> Let me know if you feel something wrong with a given combination of the CMS settings.

[JanWillem32]

@ikarad: With normal 4:2:0 chroma down-sampled video, all 4:2:0 formats are tested (NV12, YV12 and IYUV/I420). If none of those is presented to the mixer, the compatibility mode RGB32 is used. With different hardware and different drivers mixers will all act differently in what formats they will allow. That seems to be so in you case, too.

@janos666: Good to see some progress on the color management.

[cyberbeing]

Janos666, I'm interested to see how it worked out, but CMS is still disabled for me in your test build.

Could you update your build with JanWillem32's patch that relaxed FullFP support detection? It still hasn't landed in SVN, and without it, CMS is grayed out on my system.

[ikarad]

@ikarad: With normal 4:2:0 chroma down-sampled video, all 4:2:0 formats are tested (NV12, YV12 and IYUV/I420). If none of those is presented to the mixer, the compatibility mode RGB32 is used. With different hardware and different drivers mixers will all act differently in what formats they will allow. That seems to be so in you case, too.


Why is there any difference between the two different os and atlthough I use the same drivers and the same computer?

Is it a problem because I use ffdshow in YUY2?

[JanWillem32]

The driver models of Vista and XP are really different. That always makes a big difference.
YUY2 is a 4:2:2 format, it will only get preference with the internal formats if the source is also 4:2:2. It will always distort if you let one component handle conversion from 4:2:0 to 4:2:2 and another from 4:2:2 to 4:4:4, that's why.
In the mixer, there's nothing in my build that will really block it, though (or any format at all). The normal nightly builds have a less advanced convertor to NV12, by the way.
For both the 4:2:0 and the 4:2:2 formats a compatibility option to convert to RGB32 is implemented. (That usually fails on anything but 8-bit surfaces.)

[ikarad]

The driver models of Vista and XP are really different. That always makes a big difference.
YUY2 is a 4:2:2 format, it will only get preference with the internal formats if the source is also 4:2:2. It will always distort if you let one component handle conversion from 4:2:0 to 4:2:2 and another from 4:2:2 to 4:4:4, that's why.
In the mixer, there's nothing in my build that will really block it, though (or any format at all). The normal nightly builds have a less advanced convertor to NV12, by the way.
For both the 4:2:0 and the 4:2:2 formats a compatibility option to convert to RGB32 is implemented. (That usually fails on anything but 8-bit surfaces.)

The best choice is to use xp or vista in my case (mixer output on rgb32 + ffdshow in yuy2 or nv12 + ffdshow in yuy2)?

[JanWillem32]

The mixer uses an ordered list of formats. The closest matching format that supports interlacing in a 4:2:0 fashion is NV12, for 4:2:2 formats YUY2 is usually used. It's too bad that NV12 has a low merit with ffdshow tryouts (lower than YUY2, YVYU and UYVY), so you have to switch manually. Luckily, 4:2:2 format video is still somewhat rare.
Using RGB conversion before the mixer is a compatibility option. I even advise people to avoid it by using VMR-9 instead of EVR.
If you can get ffdshow with an NV12 connection to the EVR mixer and get proper hardware deinterlacing, it's a good connection.

[ikarad]

The mixer uses an ordered list of formats. The closest matching format that supports interlacing in a 4:2:0 fashion is NV12, for 4:2:2 formats YUY2 is usually used. It's too bad that NV12 has a low merit with ffdshow tryouts (lower than YUY2, YVYU and UYVY), so you have to switch manually. Luckily, 4:2:2 format video is still somewhat rare.
Using RGB conversion before the mixer is a compatibility option. I even advise people to avoid it by using VMR-9 instead of EVR.
If you can get ffdshow with an NV12 connection to the EVR mixer and get proper hardware deinterlacing, it's a good connection.

I use software deinterlacing (I don't like hardware because I can't use filters) and YUY2 (YUY2 is better than YV12, doesn't it?) because when I see interlaced movies (japan anime at 30fps interlaced. Yes it still exist evens in bluray), I use decomb avisynth filter (It is not compatible with rgb mode) to realize inverse telecine and to have the original framerate of video.

[chros]

@chros: All display devices have unique characteristics and will wear out in time. Professionals calibrate monthly with calibration devices and calibration patterns. Those are a bit expensive. For a less expensive option, you can download a lot of things to help with manual calibration.
Some good samples: http://www.avsforum.com/avs-vb/showthread.php?t=948496 .
I do not recommend using .ICC or .ICM files made from other display devices other than your own, as they will never match.

Thanks, I'll check out the link ...

[janos666]

Could you update your build with JanWillem32's patch that relaxed FullFP support detection?

It wasn't too hard to merge the changes but it wasn't trivial either (This recommended Turtoise SVN Client looks completely crazy sometimes. It showed me it will clear some lines but I got many compiler errors because they left there ; and the new patch file is buggy too, so I think other lines left there too and those just didn't cause compiler errors to help me find and clear them...), so this build is very experimental (but worked for me): MPC-HC x86 2938@JanWillem32 + CMS Test v5 (http://www.mediafire.com/?tp57vj8tuw962k5)

[janos666]

YUY2 is better than YV12, doesn't it?

Only if your video is 4:2:2. If you have a video encoded with 4:2:0 then it involves a redundant, inefficient, lossy transformation.

[ikarad]

edit edit

[JanWillem32]

You can check the properties of an input file with either File, Properties (internal MediaInfo data), or use MediaInfo externally. The download is available on http://mediainfo.sourceforge.net .
To be buried in this very busy thread for the third time:
When using ffdshow tryouts, it's usually best to let the mixer do a lot of the conversion work. In the output tab of the video decoder, use "Set pixel aspect ratio in output media type", "Set interlace flag in output media type" and "Allow output format changes during playback".
The next problem is the actual supported output types. I420/IYUV and YV12 are often refused by EVR, that leaves only NV12 as an option for 4:2:0 chroma sub-sampled video. Unfortunately, YUY2, YVYU and YUYV are selected by default instead. The only solution to that, is to disable those formats. Only enable YUY2, YVYU or YUYV if you want to play an actual 4:2:2 chroma sub-sampled video (not very common).
That should make a good NV12 connection without any chroma conversions before the mixer.

[ikarad]

You can check the properties of an input file with either File, Properties (internal MediaInfo data), or use MediaInfo externally. The download is available on http://mediainfo.sourceforge.net .
To be buried in this very busy thread for the third time:
When using ffdshow tryouts, it's usually best to let the mixer do a lot of the conversion work. In the output tab of the video decoder, use "Set pixel aspect ratio in output media type", "Set interlace flag in output media type" and "Allow output format changes during playback".
The next problem is the actual supported output types. I420/IYUV and YV12 are often refused by EVR, that leaves only NV12 as an option for 4:2:0 chroma sub-sampled video. Unfortunately, YUY2, YVYU and YUYV are selected by default instead. The only solution to that, is to disable those formats. Only enable YUY2, YVYU or YUYV if you want to play an actual 4:2:2 chroma sub-sampled video (not very common).
That should make a good NV12 connection without any chroma conversions before the mixer.
Thanks.

Some months ago I had seen that YUY2 offers a better quality than YV12 and by consequently I have used YUY2

http://www.homecinema-fr.com/forum/viewtopic.php?f=1196&t=29900151

[Ger]

The next problem is the actual supported output types. I420/IYUV and YV12 are often refused by EVR, that leaves only NV12 as an option for 4:2:0 chroma sub-sampled video. Unfortunately, YUY2, YVYU and YUYV are selected by default instead. The only solution to that, is to disable those formats.

STaRGaZeR has pretty much said/suggested he will change that (http://forum.doom9.org/showthread.php?p=1478939#post1478939). No one has objected to the new priority yet, so I think it will happen.

[JanWillem32]

@ikarad: They probably mean that they prefer to obscure a chroma bug problem of the mixer (there are actually 2). I'm already adding options to the renderer to get at least spline5 working as an option to up-sample chroma with automatic 4:2:0 and 4:2:2 detection when enabled.
@Ger: Thank you. That seems to be a good discussion of how to improve that tab.

[cyberbeing]

MPC-HC x86 2938@JanWillem32 + CMS Test v5 (http://www.mediafire.com/?tp57vj8tuw962k5)

Some things I noticed:

First off, Inverse Curve + Dim (2.35 Gamma) results the closest match to Argyll CMS (dispcal -g709 -a0.1 -f1.0 -k1.0) with a Matrix + 3 Curve ICC profile. Noticeably different then madVR+yCMS, but the gamma appears reasonably close. (I'll need to do some measurements to confirm this).
Inverse Curve + Bight (2.2 Gamma) is very significantly brighter. Inverse Curve + Dark (2.4 Gamma) is very significantly darker.

Lookup Quality High is extremely slow as you noted. I counted 42 seconds... Is there no way to just cache this data on the HDD, since it will always be the same if the ICC profile doesn't change?
Unfortunately Lookup Quality High seems required. Using Medium results in moderate banding. Low results in heavy banding. Both are pretty much unusable quality wise.

Changing lcms settings while a video is playing or paused seems buggy. Sometime lmcs just disables itself and won't activate again until the video is re-opened.

Re-opening the video from the playlist results in an 'Out of Memory' error reported by MPC-HC.

I still get extremely poor looking results when using a XYZ LUT or LAB LUT ICC profile, but that is nothing new.

When I find time, I'll re-calibrate, create a fresh profile, and take some measurements with your patch.

[ikarad]

@ikarad: They probably mean that they prefer to obscure a chroma bug problem of the mixer (there are actually 2). I'm already adding options to the renderer to get at least spline5 working as an option to up-sample chroma with automatic 4:2:0 and 4:2:2 detection when enabled.


Thank you.

Your option is also available in builds from xvidvideo.ru or not?

Is it usefull to select YUY2 to correct chroma bug (if I use old version of mpc-hc) or to select NV12 (or YV12) without to make convertion?

[JanWillem32]

http://forum.doom9.org/showthread.php?p=1463132#post1463132 YUY2 can have "half" a chroma bug. The good news is that even old builds can compile and add pixel shaders. http://forum.doom9.org/showthread.php?p=1457640#post1457640 I should really organize my thread, I've had over 1000 downloads, but no proper guide and such things in the OP.
Some types of video cards (no exact data which brands and generations) have a blurry linear filter forced on the chroma data in the mixer. I don't have a solution for that problem yet, unfortunately.
If you want quality comparison on the chroma scalers, 7z packed 8-bit PNG screenshots are available in my folder.

[janos666]

Some things I noticed:

First off, Inverse Curve + Dim (2.35 Gamma) results the closest match to Argyll CMS (dispcal -g709 -a0.1 -f1.0 -k1.0) with a Matrix + 3 Curve ICC profile. Noticeably different then madVR+yCMS, but the gamma appears reasonably close. (I'll need to do some measurements to confirm this).
Inverse Curve + Bight (2.2 Gamma) is very significantly brighter. Inverse Curve + Dark (2.4 Gamma) is very significantly darker.

I will contact with Graeme Gill again to find better fitting CIECAM02 parameters.

Lookup Quality High is extremely slow as you noted. I counted 42 seconds... Is there no way to just cache this data on the HDD, since it will always be the same if the ICC profile doesn't change?

I though about that myself because the slowest part is the CIECAM02 transform (much slower than the basic color transformation).
But it would be a relatively big job for me. (MPC-HC should check if the ICC profile is changed or not and load the cached texture from the HDD or create a new one. I think it would require to declare a basic file format which holds the texture and a copy of the ICC profile.)

But it's only a couple of seconds with my CPU. And it's single threaded. I think it wouldn't be too hard to make it multi-threaded. (But yet again, I am not a real programmer, so I would leave it for others...)

Changing lcms settings while a video is playing or paused seems buggy. Sometime lmcs just disables itself and won't activate again until the video is re-opened.

Re-opening the video from the playlist results in an 'Out of Memory' error reported by MPC-HC.

These are caused by the same problem. I ran into it when I tried to use even bigger 3DLUTs. (Very High is "only" 227x227x227 now. I would hit 256x256x256.)
I planned to consult with some developers about this. (May be it's an internal limitation which could be mellowed.)

I still get extremely poor looking results when using a XYZ LUT or LAB LUT ICC profile, but that is nothing new.

Did you try the -qu option for ArgyllCMS/colprof? (And Graeme did some changes in the upcoming 1.3.3 which will may help.)

[Mangix]

off-topic but why not use pngout to compress the PNGs? I doubt 7z is any good at it...

[JanWillem32]

I used '"optipng 0.6.4.exe" -zc9 -zm9 -zs0-3 -f0-5 -preserve *.png' to compress them, and 7z in storage mode. It's a set of 12 images, 18.2 MB in size.

[matthew_eli]

@Namaiki

I've replayed to Ticket #878:

https://sourceforge.net/apps/trac/mpc-hc/ticket/878#comment:9

could you please look at this?

[namaiki]

@Namaiki

I've replayed to Ticket #878:

https://sourceforge.net/apps/trac/mpc-hc/ticket/878#comment:9

could you please look at this?

Please post a Ctrl+J graph of that H.264 video being played in MPC-HC.

[jeremy33]

The settings of catalyst are already exactly like you describe.

My build is from xvidvideo.ru (2937) and it's already 0-255 in renderer settings.

So if I understand, this is ok :

EVR custom (without Full Float Point Processing) + ffdshow RGB32 with ffdshow yCbcr specification to BT.709
http://img835.imageshack.us/img835/534/rgb32.th.jpg (http://img835.imageshack.us/i/rgb32.jpg/)

madVR + ffdshow YV12
http://img695.imageshack.us/img695/5025/madvrffdshow.th.jpg (http://img695.imageshack.us/i/madvrffdshow.jpg/)

madVR + Internal Filter
http://img210.imageshack.us/img210/9641/madvrinternal.th.jpg (http://img210.imageshack.us/i/madvrinternal.jpg/)

And this is not ok :

EVR custom (with Full Float Point Processing) + ffdshow NV12
http://img137.imageshack.us/img137/8901/nv12.th.jpg (http://img137.imageshack.us/i/nv12.jpg/)

EVR custom (with Full Float Point Processing) + Internal Filter
http://img405.imageshack.us/img405/3690/evrinternal.th.jpg (http://img405.imageshack.us/i/evrinternal.jpg/)

So the renderer does not work like it should ?

JanWillem32, I think my problem happen with ATI series below HD5xxx. Several people on a french forum are in the same case.

[cca]

But JanWillem32 has an ATI 4890 if I remember right, a card older than the 5xxx series!

jeremy33's result kinda alarmed me, so I tried the test too, no problems with JanWillem32's latest test build using EVR CP + Full Floating Processing + FFDshow NV12. Mixer appears to receive NV12 and outputs also NV12.

[Casshern]

I used '"optipng 0.6.4.exe" -zc9 -zm9 -zs0-3 -f0-5 -preserve *.png' to compress them, and 7z in storage mode. It's a set of 12 images, 18.2 MB in size.

Tried the last test build "dfr2947 large lut". Instead of a black screen i get white noise static with all formats (NV12, YUY2, RGB 32). For obvious reason it does not show on a screenshot, but I guess this could be called progress?!

[Matching_Mole]

I have a quick question about th EVR renderer and its action on color without the color management feature activated.
Currently I resize video and convert it into RGB32 in FFDshow. In MPC I use the EVR Sync renderer and set up the Video Frame option in "Normal Size" in order to avoid any re-resizing from the renderer. But, even if the data are already in RGB32 when they are sent to the EVR presenter, do it make additional conversion/operation on the data and if yes what are they?

NB: obviously I set up all the video options in Catalyst Center of my old ATI 2600 XT in "Use Application Setting".

[ikarad]

JanWillem32, I think my problem happen with ATI series below HD5xxx. Several people on a french forum are in the same case.

I have a nvidia card and I have the same problem.

[GTPVHD]

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c3202ce6-4056-4059-8a1b-3a9b77cdfdda

Microsoft has released Windows 7 Service Pack 1(SP1) RTM/Final.

[cca]

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c3202ce6-4056-4059-8a1b-3a9b77cdfdda

Microsoft has released Windows 7 Service Pack 1(SP1) RTM/Final.

Already installed, this service pack bring nothing new really, it's just a collection of previously released hotfixes plus some unreleased ones. Has no effect in video playback as far as I can tell.

[SamuriHL]

Already installed, this service pack bring nothing new really, it's just a collection of previously released hotfixes plus some unreleased ones. Has no effect in video playback as far as I can tell.

Actually, there's a few video related hotfixes that are included that were never on windows update. One of them is HDMI handshaking related if I remember right. So you may not notice any difference, but, there's definitely some stability fixes in there.

[Mixer73]

Already installed, this service pack bring nothing new really, it's just a collection of previously released hotfixes plus some unreleased ones. Has no effect in video playback as far as I can tell.

Personally when a service pack comes out its a nice time to slipstream the SP and do a clean install...

[bobdynlan]

http://support.microsoft.com/kb/2488113 This one will help with some rare Visual Studio 2010 BSODs. Please try it out. I don't know why it's listed as optional on WU.

[vood007]

Is there a way to reset the "Overwrite Aspect Ratio" to default on player start?

[mr.duck]

Is there a way to reset the "Overwrite Aspect Ratio" to default on player start?

Also is it possible to just have the options: Default, 4:3, 16:9?

[pdanpdan]

@JanWillem32
In the latest build, there is a strange bug - after a movie is over or on movie change, the last image in previous movie remains on screen. Sound from new movie works, and the progress bar moves, but no image from the new movie.
Win 7 x64, mpc-hc tester dfr2947 (32/64, large LUT's or not), EVR Custom, D3D Fullscreen on 2nd monitor.
It I don't use D3D Fullscreen it works. Also it was working in the previous version (dfr2941 I think).

[thymej]

http://blogs.msdn.com/b/windowssdk/archive/2010/04/07/coming-soon-win-sdk-for-windows-7-and-net-4.aspx
It's not Windows SDK 7.1 problem and only 1 XP SP2 user has reported experiencing BSoD, if it was serious every XP SP2 users will be reporting BSoDs, but this hasn't happen so it's only the single reporter's machine.

BTW, its not a single reported machine, I have the same issue and same BSoD, I have SP3 because I needed to use PowerShell 2.0 for XP on the system with with MPC-HC BSoD.

Edit: I will try the hotfix (943232) for the sfx.dll file soon

[LigH]

And on top of all: Why bold?

[G_M_C]

bold = critical

The fact that you write your comment in bold doesnt make it nessesarily true ofcourse, let alone that is makes it critical.

Problems are only critical when there are many more people that have the same opinion as you, and when the problem breaks functionality. And that doesnt include naming.

So since naming in itself can never be critical, just a matter of taste perhaps, why dont you just rename you copy or something like that ?

[nevcairiel]

MPC-HC will not be renamed because you don't like the name. Sorry.
In fact, i don't think anyone would rename any project because of you.

[Thunderbolt8]

for me it's critical.
hahaha :D , you're just kidding about renaming right?you were kidding with your post, right?

[leeperry]

for me it's critical.
http://www.pixelz.fr/6/d/7/bbf630ba877ba24e256ad5febfd6a.png
It's got your name on it http://forum-images.hardware.fr/images/perso/alphat.gif

[burfadel]

If anything, it could be 'MPC - Home Cinema', but still reference Media Player Classic elsewhere. I think of more important though is that gui change which has seemed to have gone quiet. There's already the option there for a basic skin change when you place in the image file, but I'd like something that reflect Windows 7 whilst still retaining the simplesness, NOT something that reflects Windows 95! Yes, the interface is circa Windows 95, at least 15 years old! I know the 'classic' refers to the pre WMP 7 inbuilt Windows media player, but since thats probably lost on people now there's really no point retaining it, keeping an interface which makes the player look more 'media player ancient' that 'media player classic'...!

[mr.duck]

Sina™, your suggestions are so bad I want to cringe.


MPC is already the best available. I mean just look at it...

http://img576.imageshack.us/img576/5948/mpc.png

A bit of TV I was just watching. The status and seekbar tuck behind the Windows 7 taskbar nicely.

[G_M_C]

for me it's critical.
hahaha :D , you're just kidding about renaming right?

No i wasnt. And there seem to be more people on this board that dont agree with you.

Renaming? The source code is available, so you can adapt your version to your need if you want, im sure changing the name can be changed also.

[yesgrey]

suggestion:
the name: media player classic home cinema, is too long, it's a sentence & it's a great feed for comedians: media player classic home cinema high definition extra plus. :D (1000 kilometer length of the name)
You got it wrong... All your suggested names are even bigger! except the last one, which has one less character.
"mpc-hc", that's how you should call it. ;)

[bobdynlan]

foobar2000 is a great player under the hood, like mpc-hc, but will also not win any design competitions, with all those gui elements floating around like crazy on resize, spartan playlist, limited search ...etc.
for me it's critical.
nircmdc (http://www.nirsoft.net/utils/nircmd.html)win settext class "MediaPlayerClassicW" "BOOH!"
Critical needs require critical tools :helpful:

[thuan]

foobar2000 is a great player under the hood, like mpc-hc, but will also not win any design competitions, with all those gui elements floating around like crazy on resize, spartan playlist, limited search ...etc.

I thought you were talking about a different player and not foobar2000. Albeit I do agree that there're audio players with initially easier to get used,too. I do not see the current version has such problems as you described, not to mention I see its search facilities are far advanced compared to other.

As for MPC-HC, I also don't see a point to rename the project, I and most others are fine with it. Also, as it has stuck as a brand name, not only something technical.

[adam777]

you're just playing with words.
it's just a free, incomplete project: (worst dvd features i ever saw, freezes a lot when i pause dvd movies, chapter switching freezes & lots of more).
after 1000 century of development, it's extremely buggy.

Centuries of development!
Millennia of development!

[janos666]

[B]suggestion:
the name: media player classic home cinema, is too long, it's a sentence & it's a great feed for comedians

I agree that the name is too long and yes, it's a little funny too: Media Player Classic - Home Cinema (supplement after the "classic" word). I think they should have dropped the "Classic" word when they added the "Home Cinema" (but it's only my opinion and it's not a real problem). But I think a renaming would be a very bad idea now! I hate when a software is renamed without any good reason (for example, last time it happened with a reason).
[B]suggestion:
suggestion names: minimaplay, winplay, lightplay.
unusual name: eknom,
Well, it must be a joke. At least I laughed.

The default skin is not very "top-modern-stylish" but it's fully functional and OK.
I think you are free to provide a patch with skin support and your custom skin (not if I personally like your concept but others may do...) :D

-----------

The only thing I would change is to make the "Jump (medium)" default instead of the "Framestep".
It's very annoying for anybody who switches from almost any other player and she/he don't know the way how to change that.
I think this is the main reason of the "uninstall after the first try" scenarios.
It doesn't require university degree to use the "Options" menu but she/he will decide to uninstall before she/he could find this option.

[janos666]

people are different... (you can laugh forever, who cares?)

i'm a designer & this terrible design is not tolerable.
it's 2011, not 2000.
did you ever heard of "design efficiency"? of course not.

Like I said: I think you are free to make a new (optionally selectable , or may be new default) skin.

I don't care about the player skin because I watch movies in full screen. :p

[cca]

@janos666 and everyone else: Why you bother feeding the trolls? MPC is opensource, anyone is free to use it, contribute in it, or not bother with it at all. Useless comments just make this thread pile up junk.

[Virtual_ManPL]

i don't work for free.

http://img132.imageshack.us/img132/6993/1267256959605.jpg

Saying this in open source program thread...

[v0lt]

I agree that "Media Player Classic Home Cinema" - a very long name.

several variants of names:
Media Player Classic (the same player, but another version.)
Classic Player
Classic Media Player (why not?)

[JanWillem32]

For those that have missed me, I lost my Internet connection due to issues with copyrights.
The pictures I've posted have been removed, and I hope to resume normal work within a few days.

[pirlouy]

Please don't answer to Sina. Report his posts to admins. It would be enough...

[cca]

For those that have missed me, I lost my Internet connection due to issues with copyrights.
The pictures I've posted have been removed, and I hope to resume normal work within a few days.

Welcome back, and be careful. You see how much influence the copyright lobbies have...

[vood007]

Please don't answer to Sina. Report his posts to admins. It would be enough...

Reported him too. What a clown...

[mr.duck]

i'm a designer & this terrible design is not tolerable.
WHAT THE HELL?!?! LOL!

There are plenty of options already if you want a bloated, modern interface. Just use Windows Media Centre or something. Arcsoft total media thing or some other feature laden apps.


MPC is so outdated now, we could just refer to MPC-HC as MPC from now on and people will know what we mean.

[tetsuo55]

This discussion is not leading us anywhere.

@Sina:
Changing the name is not something to be taken lightly. Our name is well known all over the world. Changing it would be confusing to most of our users.

If you have a problem with the name not fitting into certain menu sections nicely than we can talk about using the short name in those areas.

MPC-HC is an open-source volunteer project. This means nobody gets payed and the changes to the source are made by people who do this for fun in their spare time.
You say you are highly skilled in design, i would gladly accept patches that make the gui changeble, and if a vote shows that many people like your default skin we can consider making it the default (as long as performance is not impacted)

For more information about how open source works you can read this: http://producingoss.com/

----

@ All.
Let's stop this discussion for now, when someone makes a patch, or a sound business-case for a name change we can re-open the discussion.

[cyberbeing]

MPC-HC x86 2938@JanWillem32 + CMS Test v5 (http://www.mediafire.com/?tp57vj8tuw962k5)

I finally took some measurements with a freshly calibrated profile, and it seems my previous assumptions were incorrect.

madVR + 3DLUT (Gamut_Measurements Only) = 2.36 Avg Gamma, 0.76 Avg DeltaE 30-100 IRE

Ambient Bright + Inverse Encode = 2.26 Avg Gamma, 1.708 Avg DeltaE 30-100 IRE

Ambient Dim + Inverse Encode = 2.54 Avg Gamma, 1.427 Avg DeltaE 30-100 IRE

Primary and secondary DeltaE are much worse than madVR as well.

I will contact with Graeme Gill again to find better fitting CIECAM02 parameters.

Any progress using CIECAM02 to make a fast transform (instead of full correction) with Graeme Gill's improved parameters?

[janos666]

Here is a working copy: 2947@JanWillem32+CMSTestv6 (http://www.mediafire.com/?lwalxjpb182cdux)

Changes:
- 16-bit 3dlut texture for 16-bit surface mode (Half Floating Point option) and 32-bit texture for 32-bit surface mode (Full Floating Point option). -> CMS should work with Intel IGPs and old VGAs too (again).
- The 3dlut creation should consume less system memory now and should be slightly faster. -> Theoretically. Let me know your experience.

To be honest, I am not even sure about what did he meant with that "fast transform". But I think it covers my idea: use the CIECAM transform on some (like 256 gray or 256+256+256 R,G,B colors instead of all colors in the 3DLUT) and use the result to set up a new lut-based transfer function (precalculated numbers from an external software, zero real-time CIECAM02 calculations in MPC-HC).
It would greatly improve the speed but MAY BE decrease the quality a bit, so I don't want to change the current parametric curve (and real-time pixel processing) based transfer until we decide if we want to keep this Inverse Encode thing or not.
And it won't be necessary if we have to cache the 3dlut texture on the HDD anyway. (It depend on the user experiences with the "Lookup Quality" option. -> High Quality is slow anyway, even with pure-power curves.)
I would get it working first before I try to optimize the speed. But may be it will be the same thing. I am not yet sure how CIECAM02 works.

I am currently trying to make new (bigger and better) dither matrix (for the Full Float mode, and leave the old for the Half Float mode...)


How do you calculate those dE values? What is your reference? What is the dE number with pure-power curves?

[cyberbeing]

To be honest, I am not even sure about what did he meant with that "fast transform". But I think it covers my idea: use the CIECAM transform on some (like 256 gray or 256+256+256 R,G,B colors instead of all colors in the 3DLUT) and use the result to set up a new lut-based transfer function (precalculated numbers from an external software, zero real-time CIECAM02 calculations in MPC-HC).
It would greatly improve the speed but MAY BE decrease the quality a bit, so I don't want to change the current parametric curve (and real-time pixel processing) based transfer until we decide if we want to keep this Inverse Encode thing or not.
Real-time pixel processing I assume would apply the entire CIECAM02 visual appearance model to all colors. Do you actually want to be doing this? It goes way beyond just a gamma curve and will actually change the chromaticity of pixels based on their surrounding pixels in real-time. Generating this calculation still takes 42 seconds with high lookup quality. A couple times even ate up ~1GB of RAM, but other times there was no memory increase? Not sure the explanation for that. In any case, if it stays like this, it would never be practical to use.

Was anything with the CIECAM02 Inverse Encode calculation actually changed in this build? It appears about the same as your last build. I'll do some measurements later, but I wouldn't be surprised if the results were the same as my previous post.

How do you calculate those dE values? What is your reference? What is the dE number with pure-power curves?
They were calculated in ColorHCFR.

The Grayscale is referenced with D65.
The Primaries and Secondaries are referenced with the REC.709 Primaries and Secondaries.

Neither is referenced with gamma afaik.

[skampy]

Would anyone be able to tell me why I am not able to play the following video? MPC-HC simply crashes before it begins to play (Media Player Classic - Home Cinema has stopped working). Here are video details:

General
Unique ID : 225750044276386840738155841697198440217 (0xA9D5E084813EC941B45E34F397FCFF19)
Complete name : J:\Movies 3\Red Cliff - Part I (Blu-Ray DTS-MA).mkv
Format : Matroska
File size : 23.4 GiB
Duration : 2h 25mn
Overall bit rate : 23.1 Mbps
Encoded date : UTC 2011-02-26 10:02:38
Writing application : mkvmerge v4.4.0 ('Die Wiederkehr') built on Oct 31 2010 21:52:48
Writing library : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 25mn
Bit rate : 21.0 Mbps
Width : 1 920 pixels
Height : 816 pixels
Display aspect ratio : 2.35:1
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.559
Stream size : 21.3 GiB (91%)
Title : x264 2pass @ 21030 kb/s
Writing library : x264 core 114 r1913 5fd3dce
Encoding settings : cabac=1 / ref=5 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=6 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=21030 / ratetol=1.0 / qcomp=0.70 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language : English

Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Codec ID : A_DTS
Duration : 2h 25mn
Bit rate mode : Variable
Bit rate : 1 636 Kbps / 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossless / Lossy
Title : Mandarin DTSHD-MA 5.1
Language : Chinese


But I have countless others that I can play that are nearly exactly similar, including the following which has the same FPS:

General
Unique ID : 231596594054338785825904625798090131484 (0xAE3BE1AD4F16D81288E2A7ECF1B5081C)
Complete name : I:\Movies 2\The Descent (Blu-Ray DTS-MA).mkv
Format : Matroska
File size : 14.7 GiB
Duration : 1h 43mn
Overall bit rate : 20.4 Mbps
Encoded date : UTC 2011-01-11 06:29:20
Writing application : mkvmerge v4.4.0 ('Die Wiederkehr') built on Oct 31 2010 21:52:48
Writing library : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 43mn
Bit rate : 18.7 Mbps
Width : 1 920 pixels
Height : 818 pixels
Display aspect ratio : 2.35:1
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.497
Stream size : 13.2 GiB (89%)
Title : x264 2pass @ 18730 kb/s
Writing library : x264 core 112 r1834 a51816a
Encoding settings : cabac=1 / ref=5 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.05:0.15 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=18730 / ratetol=1.0 / qcomp=0.70 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language : English

Audio #1
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Codec ID : A_DTS
Duration : 1h 43mn
Bit rate mode : Variable
Bit rate : 1 561 Kbps / 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossless / Lossy
Title : English DTSHD-MA 5.1
Language : English

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 1h 43mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 142 MiB (1%)
Title : Commentary
Language : English


Any ideas? :(

[janos666]

apply the entire CIECAM02 visual appearance model to all colors.
Yes, that's what I did. It processes colored pixels (every pixel in the 3DLUT texture one-by-one).
It goes way beyond just a gamma curve and will actually change the chromaticity of pixels based on their surrounding pixels in real-time.
It was easier to do and sounded better for the first time.
Do you actually want to be doing this?
Now that it proved to be inefficient (on both performance and quality sides), I guess I will come up with something else.

A couple times even ate up ~1GB of RAM, but other times there was no memory increase? Not sure the explanation for that.

It was Jan's idea to change the compiler settings to static memory management. It won't remain like this.

Was anything with the CIECAM02 Inverse Encode calculation actually changed in this build? It appears about the same as your last build.

I tried to tweak the CIECAM02 view condition settings according to the ArgyllCMS settings.

But you shouldn't bother yourself with measuring the result. I will either change the whole CIECAM02 thing or rip it out.


But, if you have any time to spare with measuring and/or subjective comparing, I would ask you to compare the Pure Power results:
Vanilla build <--> My build with Low Quality LUT (basically the same with some small changes to improve quality without penalty).
My build with Low Quality LUT <--> My build with High Quality LUT. ("Brute force" improvement: higher LUT size - let me know if you find it inefficient)
(And keep your usual calibration LUT! I want a test with heavy image manipulation anyway...)

I have an old excel sheet for parsing the results: yCMS_Argyll_comp_v0.2.rar (http://www.mediafire.com/?2ulovtjb00d9hsb) but HCFR is as good as any (until you have a colorimeter)...

[G_M_C]

Here is a working copy: 2947@JanWillem32+CMSTestv6 (http://www.mediafire.com/?lwalxjpb182cdux)

[...]


I've tried this one. It just crashes on my machine. The process is simply killed, disappears from the desktop and Win7-64 makes an error report to MS. No error message whatsoever, it just terminates.
More precise info: The crash occurs after some/a few minutes into my video. So the video DOES start, plays ok for a few minutes, and then the above happens. Tested video's are all H264 (720p/1080p/1080i). MPC's video decoder (DXVA). Outputted on secondary screen through HDMI. Audio streamed.

Renderer settings (most of em anyway);
Full screen D3D
dithering level 9
10 bit output
full floating point precision
Ambient (dim) 2.35
trc type =pure power
wp adapt state = medium
lookup quality = high
No BPC (what is that anyway ?).

Shaders: the combined shaders Janwillem advises (4:2:0 up-sampling into the -> 4:2:2 up-sampling)

Graphics board: HD 5770. Cat 10:12.

PS: Tried setting to medium precision FP, medium precision lookup etc. That seems to work. But not finished testing yet.

[janos666]

The Full Floating Point Precision + High Lookup Quality options together produce a very large 3dlut texture (somebody may call it "insanely big").
The Half Floating Point Precision mode creates half precision textures which need less system and VRAM.
(Half Precision otherwise requires equal or slightly more CPU time because the lcms result is always full precision and only the texture is half precision, so it has to be converted into half precision first which is an extra step...)
The Lookup Quality controls the size of the 3dlut which greatly affects the system and VRAM consumption as well as the startup time.

BPC = Black Point Compensation -> Eliminates black crush on relatively low contrast displays. (It needs cLUT profiles, won't work with matrix profiles.)


@G_M_C
I think you should update your VGA driver to 11.02WHQL

UPDATE: I solved the CIECAM02 performance problem, so one less thing to worry about.

[mr.duck]

Can it be possible to use MPC-HC to watch a TV program that is being recorded (TS file, MPEG2)? The problem is that MPC can only play the first few mins and then it stops and you have to reopen the file to get the new length to play a bit more. The TS file is constantly being updated so I want to make MPC just keep playing as there is more video available.

Just make the seekbar greyed out and start playing 5 sec from the end of the file would be fine. Does that sound like a good idea?

[G_M_C]

The Full Floating Point Precision + High Lookup Quality options together produce a very large 3dlut texture (somebody may call it "insanely big").
The Half Floating Point Precision mode creates half precision textures which need less system and VRAM.
(Half Precision otherwise requires equal or slightly more CPU time because the lcms result is always full precision and only the texture is half precision, so it has to be converted into half precision first which is an extra step...)
The Lookup Quality controls the size of the 3dlut which greatly affects the system and VRAM consumption as well as the startup time.

BPC = Black Point Compensation -> Eliminates black crush on relatively low contrast displays. (It needs cLUT profiles, won't work with matrix profiles.)


@G_M_C
I think you should update your VGA driver to 11.02WHQL

UPDATE: I solved the CIECAM02 performance problem, so one less thing to worry about.

I dont know if updating drivers is the solution, but will do later.

Question for all;
Is there a objective visible difference on your TV or other device you actually watch the movie on between using 'Half Floating Point Precision + High Lookup Quality lookup' and 'Full Floating Point Precision + High Lookup Quality' ?

[CSMR]

I've made some changes to this click behavior...

Basically, if you have any bars(caption/seekbar/control/information/status/ etc), then you can click to pause/resume, but if you don't have any bars like preset->minimal mode, the mouse will be used to move window instead. So if you like Borderless/FrameOnly mode and also want to click pause/resume, turn on any bar from View menu will do that.
Current build 1.5.1.2953 works like this. I'm not sure this is ideal.

With some bars (e.g. status), you can move the window via status. So activating them and having mouse pause/resume is workable. Other bars (e.g. seek) you can't move the window with. With only seek, for example, there is no way to move the window, since mouse pauses/resumes.

A quick fix for this would be: if any bars are active that allow moving the window, mouse pause/resume is active, otherwise mouse moves the window.

However I don't think it's intuitive that this behavior changes when bars are removed or added. Whether you can move the window or pause or resume with mouse on the main area shouldn't depend on what information you choose to display. Instead can't there be a setting? Default is non-minimal mode, usual bars, and mouse pause/resume. Using minimal mode implies ability/desire to tweak, so an extra setting is not a problem.

[janos666]

I dont know if updating drivers is the solution, but will do later.

Is there a objective visible difference on your TV or other device you actually watch the movie on between using 'Half Floating Point Precision + High Lookup Quality lookup' and 'Full Floating Point Precision + High Lookup Quality' ?

The Full Floating Point option doesn't work properly with some old AMD drivers. I can't remember exactly but may be it was fixed somewhere around 10.12 (or earlier?). I test the debug builds with 11.02WHQL (HD5850 1Gb).

I would wait with that decision until the dithertexture gets updated with a bigger matrix and higher precision numbers, and the Inverse Encode curves are finalized.
(The High Quality setting is mainly for the Inverse Encode curves because they usually lay further from the usual display TRC.)

[Hera]

Where did subtitles go with Haali Renderer? I don't get that option with Athlon, NV6600, and XP. I do with Athlon II, 4250 Mobile, and 7.

[djesteban]

I am trying to play an .avs script in mpc-hc x64 after installing avisynth x64. I get an error saying Cannot render the file. Now, avisynth x64 seems to work fine since I can use it with dgdecnv x64, so is this a problem with mpc-hc x64 where avs script reading is disabled?
I found this feature request ticket number (http://sourceforge.net/apps/trac/mpc-hc/ticket/447) on the sourceforge for mpc-hc, any chance of getting this working in future release?

Thanks, cheers

[GrofLuigi]

I can't find the explanation for some recent changes in the changelog. In my .ini file some new things appeared.

1) FastSeek=1

What does it do? What does 0 do?

2) New lines of keymappings

Before:

CommandMod5=904 b 27 "" 5 0 0
CommandMod6=903 b 25 "" 5 0 0

After:

CommandMod5=902 3 27 "" 5 0 0
CommandMod6=901 3 25 "" 5 0 0
CommandMod7=904 b 27 "" 5 0 0
CommandMod8=903 b 25 "" 5 0 0

(the first two I had defined previously and forgotten what exactly they do, but I am sure I need them badly).

Are the new commands same/similar to before? Can they interfere?

GL

[G_M_C]

I dont know if updating drivers is the solution, but will do later.

Question for all;
Is there a objective visible difference on your TV or other device you actually watch the movie on between using 'Half Floating Point Precision + High Lookup Quality lookup' and 'Full Floating Point Precision + High Lookup Quality' ?

I quote my own post for janos; Can we agree that the difference between half en full (as per my question) is negligible? If so, i'll leave it to half floating point precision untill the reason for crashing is more clear. Cause Half Floating Point Precision + High Lookup Quality doesn't crash (watched two full movies without crash).

[janos666]

If so, i'll leave it to half floating point precision untill the reason for crashing is more clear.

It depends on many things, like: display characteristics, profile type and quality, color sensor accuracy, your profiler software and your profile creation settings (and your calibration practice), your personal taste (smoothness or accuracy), etc.

I think the Half Floating Point with Medium size is more than enough in most cases.
So, you don't have to worry with either Full precision + Medium LUT size, or Half precision + High LUT size.

I think I would prefer Full precision + Medium size because it takes less time to start the playback.


***
Remember, that the existence of an option itself doesn't mean that you have to use it. It only means that you are free to test it and it's available if you feel that you need it. So, don't push it!
***


You can check the results with these test videos: http://www.avsforum.com/avs-vb/showthread.php?t=948496.
I usually use the first 4 videos from the Additional directory and the black/white clipping from the Basic Settings folder.

[hoborg]

Hi.
Can somebody compile MPC mpeg splitter to output WVC1 as {D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53} instead of {31435657-0000-0010-8000-00AA00389B71} like LAVF do?
Just for test interlaced VC-1 with PDVD10 decoder.

Thanks.

[G_M_C]

It depends on many things, like: display characteristics, profile type and quality, color sensor accuracy, your profiler software and your profile creation settings (and your calibration practice), your personal taste (smoothness or accuracy), etc.

I think the Half Floating Point with Medium size is more than enough in most cases.
So, you don't have to worry with either Full precision + Medium LUT size, or Half precision + High LUT size.

I think I would prefer Full precision + Medium size because it takes less time to start the playback.


***
Remember, that the existence of an option itself doesn't mean that you have to use it. It only means that you are free to test it and it's available if you feel that you need it. So, don't push it!
***


You can check the results with these test videos: http://www.avsforum.com/avs-vb/showthread.php?t=948496.
I usually use the first 4 videos from the Additional directory and the black/white clipping from the Basic Settings folder.

The LUT; If someone doesnt use his own LUT, is the windows 'standard' used (in my case sRGB / 4:4:4 YUV) ? Cause my plasma has been ISF calibrated (sRGB for PC input, and 709 for HD video, D65 etc. if i remember correctly). So if my PC just outputs one of those, as close to the standard as possible, im good.

Hmmm, do i actually need the LUT in my case I wonder :confused:

[janos666]

The LUT; If someone doesnt use his own LUT, is the windows 'standard' used (in my case sRGB / 4:4:4 YUV) ? Cause my plasma has been ISF calibrated (sRGB for PC input, and 709 for HD video, D65 etc. if i remember correctly). So if my PC just outputs one of those, as close to the standard as possible, im good.

Hmmm, do i actually need the LUT in my case I wonder :confused:

It asks Windows for a profile first and creates a standard sRGB profile if there is no response.

If you don't have any ICM profiles for you display then I suggest to turn OFF the CMS in MPC-HC. (At least for HD videos, because you mentioned Rec709 but SD NTSC and SD PAL/SECAM are all different.)

Without having an ICM file, some kind of "calibration report" or post-calibration measurement data, I can't say more.

This is not a simple question. The IFS guy adjusted the hardware controls. But...
- What is the effective precision of the hardware processing?
- What controls does your hardware offer?
- What was his real target? (I doubt he aimed the real sRGB curve. And the gamma<-vs->scaled_inverse is another religious question for Rec709, etc.)
...and so on...


If you really care about quality and color accuracy, I suggest to buy an own sensor (be careful: a WCG display requires spectrophotometers and spectros requires extra care when you use them on high contrast displays...) and do the calibration and/or profiling for yourself.
The ISF guy may has an expensive instrument but your hardware will drift more in one month that this difference.
He may has routine but he doesn't know every single displays like you can know your own display.
His aim is probably the "good enough to get paid" and not the "as good as anybody could do it".


I personally prefer to skip the entire calibration if possible (or choose a target which is as close to the native characteristics as possible), construct a high quality profile and use high quality software processing.
It gives you the freedom to easily adapt to any source materials (starting from AdobeRGB to sRGB and Rec709 or PAL...) and the calibration+profiling process is also more convenient without the profiling step.
However, it doesn't mean that it's a good practice for every hardwares or that I don't change anything in the hardware menu...


And I could continue it for pages but this is not that froum topic.

[Matching_Mole]

I have a quick question about th EVR renderer and its action on color without the color management feature activated.
Currently I resize video and convert it into RGB32 in FFDshow. In MPC I use the EVR Sync renderer and set up the Video Frame option in "Normal Size" in order to avoid any re-resizing from the renderer. But, even if the data are already in RGB32 when they are sent to the EVR presenter, do it make additional conversion/operation on the data and if yes what are they?

NB: obviously I set up all the video options in Catalyst Center of my old ATI 2600 XT in "Use Application Setting".

With the last developments (and thanks to the developers for all their works!) I'm a little lost to know what actions are actually done by the renderers. And it seems that the CMS developments concern only VMR9 and EVR Custom, do you plan to add it to other renderer as EVR-Sync (from my understanding no).

[janos666]

Why do you use EVR-Sync on the first place?
Did you try EVR-CP with different V-sync options?

I could see some people who struggled with EVR-Sync. And the solution was (for their sync problems!) to use EVR-CP instead.

For me, it's the best to disable V-sync or use V-sync with the Accurate V-sync option (desktop Radeon). On my laptop (mobile Geforce), I use V-sync + Alternate V-sync.

And don't forget to try the Full Screen Exclusive mode and/or disable Aero.

I think the EVR-Sync renderer is outdated in many ways. If I were in the position to make this decision, I would rip it out, because it's abuser (you think you should use it for best sync but no, you would probably be better with the EVR-CP sync options while you give up the other benefits of EVR-CP...).

[Matching_Mole]

Why do you use EVR-Sync on the first place?
Did you try EVR-CP with different V-sync options?

I use EVR Sync since one year or more in my HTPC because it give me a perfect playback with almost no stuttering (99% of time) and absolutely no tearing. And have this result took a lot of time in order to find the exact correct timing in Powerstrip for each movie fps (so 23.976, 24, 25, 29.976 and 30fps) because I don't want to use reclock.

I chose EVR sync at this time because I didn't find the correct set up in EVR custom to have the same stability in the results. But maybe now the things are better and I can try again!

[Leslie Pierce]

howd to install codecs to windows media player

[ikarad]

I found a problem with ffdshow 3760 and mpc-hc
https://sourceforge.net/apps/trac/mpc-hc/ticket/1187
The back right channel (speaker) and the LFE crossover channel are swapped. I found a workaround for this problem by using the swap channel options to swap the LFE and Back right channels.

I try with ffdshow since 3361 and thre is the same problem. I try
with different version of mpc-hc (1.2.2972 until the last 1.5.1.2931) and
There is the same problem
(I haven't tried with older version of ffdshow and mpc-hc)

I use ffdshow with mpc-HC but this bug doesn't appeared with mpc-hc only

here http://forum.doom9.org/showpost.php?p=1481175&postcount=13095
Your logic is wrong. Imagine that MPC-HC has 2 bugs: wrong mapping in internal decoder and wrong mapping in internal mixer and these 2 bugs "neutralize" each other, ie the output is correct.
But when external decoder (ffdshow in your case) is connected to internal mixer then the output is wrong. Your description of the problem does not rule out this speculative situation.

BTW I tested ffdshow in 2 different players (not MPC-HC) and didn't noticed the problem.


Gleb Egorych has tested with other players as mpc-hc and there is not the bug. He said that the bug is due to mpc-hc.

I don't know if it's a bug of ffdshow or mpc-hc and I post bugreport here (bugtracker https://sourceforge.net/apps/trac/mpc-hc/ticket/1187) and in the topic of ffddhow (and bugtracker of ffdshow)

[oddball]

Sorry if this has already been bought up but if I enable D3D Fullscreen (My preferred playback method) it takes AGES to exit the player. Especially if I am playing video. Sometimes it takes as long as 10-15 seconds to exit. I ttired a clean install of various flavors from 2499 onwards but it's the same. I wonder if this is an issue with the latest Nvidia drivers.

EDIT: It's not just D3D mode. Even when the player is doing nothing (Just open it. Leave it for a little bit then try to exit) it takes ages to exit.

EDIT: I think I solved it. I followed the FAQ about disabling the 'Hide CD/DVD-ROMS' menu problem and it seems to have fixed it. It now exits correctly with no lag/not responding. I think it might have something to do with having VirtualCloneDrive installed (Recent addition to my setup).

[Aleksoid1978]

To all - what you think about different key in registry for x86 and x64 ???
Now we have - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic]

I propose to do so:
x86 - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic Home Cinema]
x64 - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic Home Cinema x64]

This is better for different x86 and x64 version - in this we can have different settings, speciality for External Filters.

Waiting for your opinion :)

[fastplayer]

To all - what you think about different key in registry for x86 and x64 ???
Now we have - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic]
Remove "Gabest" from the key and shorten it to "MPC-HC" resp. "MPC-HC64".

[nevcairiel]

Renaming the registry keys will cause everyone to lose their settings. I also don't think its required to seperate them. There is no real reason why anyone would run both x86 and x64 on the same system. You pick one that works best for you, and then stick to it. And even if they did, it would probably cause alot of confusion why the settings didn't stick when changing it in one version.

[fastplayer]

Renaming the registry keys will cause everyone to lose their settings.
I probably should've mentioned that I assumed this change was in preparation for a new official MPC-HC version which could transfer the old settings. :)

[Mercury_22]

To all - what you think about different key in registry for x86 and x64 ???
Now we have - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic]

I propose to do so:
x86 - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic Home Cinema]
x64 - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic Home Cinema x64]

This is better for different x86 and x64 version - in this we can have different settings, speciality for External Filters.

Waiting for your opinion :)
Remove "Gabest" from the key and shorten it to "MPC-HC" resp. "MPC-HC64".
Totally agree with both

And maybe solve this related bug too
There is a problem with the default player when there are both (x86 & x64) MPC-HC versions on a system :
If I set one version, let's say x86, as default player for all (any) formats if I open the other one (x64) and I just go to "Formats" (options --> Formats) without changing anything (nothing it's selected) and then close it (the x64 version) the first version (x86, which was set as default player for all formats) it's NOT anymore the default player for all formats

Can somebody do something about this ?

EDIT: I'm guessing that maybe there is a "64" missing in the x64 version format association

Yep, it would indeed probably be better to let the x64 build use "mplayerc64.extension" instead of "mplayerc.extension" for its file associations. Should be an easy change for the devs.

[boyumeow]

I agree with nevcairiel that we do not need to run both x86 and x64 on the same system especially there is x64 ffdshow, unless U are testing or trying to run with other programs that do not have 64bit support. Thanks.

[mark0077]

Because many filters / renderers don't support x64, wouldn't having both mpc versions sharing the same settings cause problems?

For example I use the 64bit version of mpc and ffdshow recently to get better avisynth script frame rate conversion performance, but of course in that config I can't use reclock or madVR. Its not a big deal for me but I don't know if sharing settings between the two is acceptible to everyone, maybe most but not all... especially if they intend to use both versions slightly differently as I do... using different renderers etc. If madVR and reclock had x64 versions it wouldn't be an issue for me :) to have them sharing the same settings which would make more sense but x64 hasn't and probably never will fully catch up? Would it be much work to make it optional, like when x86 mpc version is started, and then later an x64 version, couldn't the x64 version ask, do you want to use the same settings as x86 version or not with the warning that not all settings may work between the two because of lack of x64 versions of particular filters / renderers.

[Virtual_ManPL]

I support idea of using different keys for each version
x86 - [HKEY_CURRENT_USER\Software\MPC-HC]
x64 - [HKEY_CURRENT_USER\Software\MPC-HC64]

I use 64bit versions of MPC-HC, LAVFSplitter and Xvid.

ffdshow, CoreAVC, MainConcept, CyberLink & Haali splitter have also 64bit versions.
So it's quite large group to choose your favorite decoder or splitter.

[v0lt]

Why do you have two versions of the player with different settings? :confused:

[mark0077]

Why do you have two versions of the player with different settings? :confused:

Because some software like filters / renderers arn't x64 yet, hence the difference in settings. mpc 32 bit pointing to reclock and madVR isn't going to work with mpc 64 so identical settings isn't 100% possible for everyone. Even large pieces of software like photoshop has seperate settings for its 32 and 64 bit versions, I assume for similar reasons with some plugins not being 64bit yet etc..

[HoP]

i don't know its a bug or no but if subtitle started with quote( ' ) it cant be displayed
i haven't this problem with PotPlayer
http://www.pixelz.fr/2/9/7/e1d9727acff61213b4923dff4aefd.jpg

[pdanpdan]

@HoP - It's an error in the subtitle file - it should be 1, not '1

[HoP]

@HoP - It's an error in the subtitle file - it should be 1, not '1

yes..i know but mpc should display it like other players(ex.PotPlayer)

[fastplayer]

yes..i know but mpc should display it like other players(ex.PotPlayer)
No, it shouldn't. That SRT is not "valid":
http://en.wikipedia.org/wiki/SubRip#SubRip_text_file_format
http://www.matroska.org/technical/specs/subtitles/srt.html

[Sebastiii]

Hi.
Can somebody compile MPC mpeg splitter to output WVC1 as {D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53} instead of {31435657-0000-0010-8000-00AA00389B71} like LAVF do?
Just for test interlaced VC-1 with PDVD10 decoder.

Thanks.

Hi,

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

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

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

A dialog menu will be add soon :)

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

Thank you Aleksoid :)
Sebastiii.

[nevcairiel]

That would all not be needed if the MPEG Splitter just wouldn't be so dumb and support multiple media types.
These Hacks make everything just worse.

[Sebastiii]

Effectively, would be nice, i don't know how to do this :(
I hope that eventually can be made :)

But for sure like with this patch connection is working outside MPC-HC.

Seems Lavf has an issue (for now) : http://forum.team-mediaportal.com/719214-post68.html

Thanks,
Sebastiii.

[nevcairiel]

VC-1 will always have broken timestamps. The MPC-HC MPEG Splitter will actually be worse. LAV Splitter does not need Frame-Time correction when using EVR. MPC-HC Splitter does, at least when being used with Internal decoder, ffdshow or MS DMO Decoder.

There is still controversy where the VC-1 timestamps should be fixed. I decided to fix them in the splitter, but i didn't offer options to turn it off.

I think i will offer an option in LAV Splitter to disable the VC-1 timestamp fixing code, maybe the PDVD decoder requires the broken timestamps and fixes them itself (and double fixing results in breaking).

I'll create a test build later today with the fixing code turned off, so you guys can throw it at your VC-1 with the PDVD decoder and see what happens.

[Sebastiii]

Ok nice nevcairiel :)
Thank you m8,
Seb.

[nevcairiel]

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

[mariner]

Hi,

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

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

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

A dialog menu will be add soon :)

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

Thank you Aleksoid :)
Sebastiii.

Greetings Sebastiii.

This is brilliant.

Many thanks and best regards.

[nevcairiel]

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

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

I have hope for this one!

[Sebastiii]

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

I have hope for this one!

I hope too :)
Thanks m8,
Seb.

[JanWillem32]

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

[sshd]

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

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

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

[cca]

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

[JanWillem32]

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

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

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

[done75]

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

[janos666]

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

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

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


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

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

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

EDIT2: Another small (but dirty) hotfix.

[mark0077]

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

[pdanpdan]

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

[cyberbeing]

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

[janos666]

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

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

[cyberbeing]

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

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

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

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

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

[janos666]

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

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

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

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

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

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

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

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

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

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

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

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

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

Let's start with the easy parts:

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

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

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

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

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

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


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

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

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


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

[cyberbeing]

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

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

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

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

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

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

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

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

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

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

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

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

[Tsukihime]

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

[Aleksoid1978]

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

[Carpo]

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

[betaking]

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

[Virtual_ManPL]

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

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



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

[Carpo]

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

Thanks :-)

[tetsuo55]

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

[hoborg]

Hi,

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

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

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

A dialog menu will be add soon :)

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

Thank you Aleksoid :)
Sebastiii.

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

[Superb]

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

[vBm]

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

[janos666]

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

I just read the cmscam02.c (lcms):

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

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

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


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

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

[ramicio]

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

[cyberbeing]

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


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

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


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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

So try making three builds.

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

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

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

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

[janos666]

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

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

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

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


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

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

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

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

[cyberbeing]

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

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

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

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

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

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

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

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

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

[73ChargerFan]

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

[G_M_C]

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


[...]

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

[Brazil2]

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

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

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

[JanWillem32]

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

[janos666]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[QQ]

Hello,

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

Is this by design?

[janos666]

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

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

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

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

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

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

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


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

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


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

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

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

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

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

[vBm]

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

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

[fastplayer]

Hello,

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

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

[QQ]

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

that was it, thanks!

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

[fastplayer]

that was it, thanks!

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

[QQ]

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

[fastplayer]

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

[moonrak]

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

[boyumeow]

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

[QQ]

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

I see.

Does the rule apply to all the internal filters?

[fastplayer]

I see.

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

[QQ]

Understood.

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

[fastplayer]

Understood.

I'm a bit OCD when it comes to understanding what I use.. If I use haali, then "Audio" right click menu does not allow me to choose audio track, but menu on Navigate does. Why is this functionality duplicated in mpc-hc? :|
I guess the Audio menu is only active/useful, when you use the internal splitters which are slightly better integrated into the menu system. For external ones, you have to go through the Filters/Navigate menu or tray icon (--> Haali). For me this isn't a "problem" because I have the Audio Switcher disabled (which turns off the Audio menu). I prefer ffdshow to handle my audio decoding and mixing.

[nevcairiel]

The "Audio Switcher" is only useful when the splitter exports all audio streams, and does not offer track choosing capabilities of its own. The MPC-HC internal MKV splitter is like that, it exports all tracks. The MPC-HC internal mpeg-splitter on the other hand offers track choosing, same as Haali or my LAV Splitter.

[f@chance]

I have enjoyed MPC-HC for as long as I can remember and I used it with the DScaler IVTC mod, because that is the only MPEG decoder that allows hard coded telecine to be removed. Unfortunately the latest versions crash when opening the DScaler settings. I read through this thread and many commented on this problem and like them I was hoping that this could be patched.

I want to stay with MPC-HC because I am so used to its operation but if the 1080i broadcasts can no longer be played back at the frame rate that they were shot I might have to close the chapter on MPC-HC and find a replacement. That would be too sad as I have used this player for such a long time.

Just to quote madshi from http://forum.doom9.org/showpost.php?p=1427202&postcount=4235
DScaler IVTC mod: Very reliable IVTC (60i -> 24p) for all NTSC/ATSC broadcasts and DVDs. No other MPEG2 decoder can do that.
Looks like it is worthwhile to find a solution for this.

[Casshern]

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

Tried your latest 2962 test version. It's still completely broken on the 5970 card. Instead of black screen, it shows some sort of static noise with all connection types NV12 YUY2 and RGB32. Will this bug ever get fixed. And yes it's not the catalyst driver as all other players have no problem at all displaying everything correctly in all possible combination (DXVA, non DXVA, YUY2, NV12, YV12, RGB32 etc.). Please fix this!

[cca]

Tried your latest 2962 test version. It's still completely broken on the 5970 card. Instead of black screen, it shows some sort of static noise with all connection types NV12 YUY2 and RGB32. Will this bug ever get fixed. And yes it's not the catalyst driver as all other players have no problem at all displaying everything correctly in all possible combination (DXVA, non DXVA, YUY2, NV12, YV12, RGB32 etc.). Please fix this!

If you see noise, please check the "Dithering Levels" setting in the Renderer settings. If it is set too high you get this "noise".

[janos666]

And yes it's not the catalyst driver as all other players have no problem at all displaying everything correctly in all possible combination (DXVA, non DXVA, YUY2, NV12, YV12, RGB32 etc.)

Can I aks your driver version anyway? (This statement is funny. Wouldn't you blame AMD if their driver works with every games except the one you would play...?)

The new (CCC2) drivers usually requires a clean install. Many people had to uninstall the old (CCC) driver and run DriverSweeper in safe mode when they updated to the new CCC2 set. (Me too. AutoCAD failed to start and there were no OpenGL at all before I did a clean install.)

[Inspector.Gadget]

Unfortunately the latest versions crash when opening the DScaler settings. I read through this thread and many commented on this problem and like them I was hoping that this could be patched.

@ All: here's the crash data from my system in case it helps:

Problem Event Name: BEX
Application Name: mpc-hc.exe
Application Version: 1.5.1.2953
Application Timestamp: 4d684e3d
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 011c25d8
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


I've just started using DScaler 5 with the IVTC Mod with MPC-HC but it's a lot easier than using the bloated mess called PowerDVD, more stable than ffdshow+Avisynth+TIVTC, and can output 24p or 30p while MPC-HC internal MPEG2 is limited to 30p as far as I can tell. It would be nice if the two would continue to work well together.

[namaiki]

@ All: here's the crash data from my system in case it helps:


What's the last version (doesn't have to be exact) of MPC/MPC-HC that it does work with?


MPC-HC internal MPEG2 is limited to 30p as far as I can tell
What do you mean?

[Inspector.Gadget]

What do you mean?

Given either soft-telecined or hard-telecined content, the MPC-HC internal MPEG-2 decoder (non-DXVA) outputs only 30p content according to the renderer (unless I've been doing something REALLY wrong...) using weave, and lacks an"ignore soft telecine/IVTC hard telecine" option. DScaler with the IVTC mod can put out either 24p or 30p even given hard telecined content. I'm on a display that ony does 62 hz (lol) so it doesn't matter much to me but apparently it's really handy for some people who can set displays to a multiple of 24 hz.

As for the last version where it worked, I installed DScaler today so I wouldn't know where to look. But the guy I was replying to seems to have some rough idea, at least...

[namaiki]

I'm on a display that ony does 62 hz (lol)

Holy crap, so am I! What the heck's the model of your screen/graphics card combo? I get 62Hz outputting from the Intel card on this laptop with switchable graphics.

I tried ReClock for a while, it was pretty good for speeding up 30Hz-> 31Hz stuff where there is a noticeable pause in the video during each second of video when VSync is enabled. With ReClock, video was perfectly smooth but the ~5% speedup was quite noticable at times.

[bobdynlan]

janos666 & JanWillem32, your changes are killer! :thanks:
Quite literally, because with them enabled gpu ram usage goes to the roof. Lookup quality High does not even work without a 512MB GPU card - to be expected, as having everything else on with 1080p steals more than 300MB as reported by GPU-Z.
People tend to check any option they find in the gui thinking it will make it better. And while there is nothing wrong with going for perfection, nobody should jump on using an option without some hard comparative numbers. The result can be worse than a placebo effect - wasting precious energy.
Anyway, just wait and see the options I've added to the internal decoder, talking about wasting energy :)

[Casshern]

If you see noise, please check the "Dithering Levels" setting in the Renderer settings. If it is set too high you get this "noise".

Has nothing to do with dithering - i have that all turned off. Its still the same issue that produced a black screen a couple of versions back - now it produces pink noise, and just like with the black screen before the stats still work -> so its most likely that the refactoring which eliminated the mpc inbuild rgb32 conversion is the culprit. I am all for a menu option to bring the old behaviour back.

[Casshern]

Can I aks your driver version anyway? (This statement is funny. Wouldn't you blame AMD if their driver works with every games except the one you would play...?)

The new (CCC2) drivers usually requires a clean install. Many people had to uninstall the old (CCC) driver and run DriverSweeper in safe mode when they updated to the new CCC2 set. (Me too. AutoCAD failed to start and there were no OpenGL at all before I did a clean install.)

Well it's still the same configuration as before - see my detailed posts regarding the black screen issue. While their might be some interaction with the catalyst drivers on some cars -> we confirmed back then that the problem persists regardless of driver on the 5970 and some other cards (though not all, and we tested upto 10.12)

[Casshern]

I also use the IVTC modded dscaler, as it is still the best solution for wrongly flagged and/or telecined content. The last version of mpc where the property page of IVTC-dscaler works is 1356. I saved this version, just to change the settings for dscaler. Fortunately once the settings are changed, one can switch back to newer versions of MPC for viewing. But this is a long standing bug in all versions of mpc-hc since 1356.

@ All: here's the crash data from my system in case it helps:

Problem Event Name: BEX
Application Name: mpc-hc.exe
Application Version: 1.5.1.2953
Application Timestamp: 4d684e3d
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 011c25d8
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


I've just started using DScaler 5 with the IVTC Mod with MPC-HC but it's a lot easier than using the bloated mess called PowerDVD, more stable than ffdshow+Avisynth+TIVTC, and can output 24p or 30p while MPC-HC internal MPEG2 is limited to 30p as far as I can tell. It would be nice if the two would continue to work well together.

[betaking]

latest versions crash when opening the DScaler settings not a bug! see here http://forum.doom9.org/showpost.php?p=1451378&postcount=15063
if you can compiled mpc-hc open release.vsprops change DataExecutionPrevention="2" to DataExecutionPrevention="0" save it and recompiled!

[Casshern]

This would explain it! I only looked superficially at the changes after 1356 but didn't think about this. Good find! This points to a bug in dscaler....

latest versions crash when opening the DScaler settings not a bug! see here http://forum.doom9.org/showpost.php?p=1451378&postcount=15063
if you can compiled mpc-hc open release.vsprops change DataExecutionPrevention="2" to DataExecutionPrevention="0" save it and recompiled!

[nevcairiel]

DEP is recommended to be always on. If some filter crashes when its on, its definitely a bug in that filter, no question.

[tetsuo55]

Crashes with this code "Exception Code: c0000005" always mean that either DEP or a lack of SSE/MMX support is causing a crash.

If its not SSE/MMX then you can be sure that the filter being used has a bug that causes it to buffer overflow.
Running it with DEP disabled can have negative side effects on your windows session.

[Eliminateur]

since a few weeks ago (i can't remember when it started or on what upgrade) i can't take anymore screencaps, they all result in garbage:
http://img219.imageshack.us/img219/5573/strikewitches211tobemys.th.jpg (http://img219.imageshack.us/i/strikewitches211tobemys.jpg/)

that's using latest ffdshow x64 3771 (also happens with 3698), EVR CP, 10bit RGB, FullFP, Vsync renderer output, direct RGB fed.
mpc-hc x64 2962, it also happened with older version(just upgraded to see if it was solved, but no)

[ramicio]

The same thing happens to me, too, with EVR CP.

[JanWillem32]

I'm sorry, but the broken screenshot function is my doing.
I fixed up the pathways for 10-, 16- and 32-bit rendering and corrected byte ordering errors for the 8-bit rendering path.
The internal screenshot function can only handle the old type of 8-bit ordered input.
As a result, only the PNG and JPG writers work with 10-bit out, HFPP and FFPP disabled.
I find it easier to just use the standard print screen button on my keyboard and pasting that image into an image editor. (And use a bit of auto-cropping, of course.)
I've had some success with exporting a memory dump of the final screenspace surface, so it might work later on. The exported item is a headerless DIB bitmap of just the full 32, 64 or 128 bits per RGBA pixel. On a 1920×1080 screen with FFPP enabled, that's a 253.125 MB file for one screenshot.

[clsid]

If "save image" and "save thumbnails" do not work with certain settings, then an error message should be displayed that explains the situation. Just like is already done when a renderer is used that is incompatible with taking screenshots in MPC.

Otherwise similar bug reports will keep coming.

[Eliminateur]

i see, that's umfortunate, it's quite annoying to printscr and paste and save afterwards when it was done in a signle click.
i'll be disabling FFPP then as i haven't noticed any visual quality difference, i really want screencap functionality

and yes, an error or warning should be displayed, because a corrutp saved image is not very user friendly

[JanWillem32]

The main function of FFPP is to reduce rounding from one rendering stage to another. http://sourceforge.net/apps/trac/mpc-hc/wiki/New_Renderer_Settings
I counted 9 surface conversions from mixer output to backbuffer with the filters I put in my rendering path, so rounding to 8- or 10-bit in every stage would be rather bad in my case.
If you only enable scaling, the damage to the color dynamics is of course a lot less.

I was hoping to do something more useful or enjoyable than to code this fix during breakfast...
The code is still bad for the screenshot function, but it's at least capable of producing JPG and PNG files with 4×4 dithering. The BMP writer is broken.
I'm not going to put more effort into this item, until it's been re-written with normal, modern functions.
The method for saving a fully rendered screenspace picture isn't ready yet, so it's not included.

[Qaq]

For me PQ of JanWillem32's patches (+shaders) is noticable better. Thanks JanWillem32. I make screenshots not very often so I prefer to keep better PQ and lose usability. For now at least. I know how to use PrntScr&Paint and I can use unpatched MPC-HC version for screenshots/screenlists.

[JanWillem32]

I actually don't know if the EVR mixer will dither in 8-bit RGB mode. It could be that the function I fixed is actually more accurate with 32-, 16- or 10-bit surfaces enabled.
A 4×4 dither map is still not a lot, though. The the internal dithering maps of the renderer are 32×32 (regular) and 128×128 (with FFPP). That's one of the reasons I want a full rendered surface exporter. The more quality output before going into an image editor, the better.

[fastplayer]

Hi Jan,

when outputting RGB32/RGB32HQ with ffdshow, neither FFPP/HFPP nor 10-bit IN/OUT, seem to apply any sort of dithering. Only when using the internal decoders, dithering is applied. Is this by design or a bug?
Setup: MPC-HC 2962, ffdshow 3771, Win7 32-bit, HD4670, CAT 11.2.

[JanWillem32]

If the input is rounded to 8-bit at the input from the mixer, there's nothing left to dither indeed. The heavy random dither should still be visible when activated.
I've only seen that dithering and color management deactivates when I change the display resolution or change display devices during playback. It's otherwise quite reliable.
Do you have an incompatibility problem with the VMR-9 or EVR mixer that you require RGB mixer input?

[fastplayer]

Do you have an incompatibility problem with the VMR-9 or EVR mixer that you require RGB mixer input?
No problems that I know of. I was just wondering how MPC's dithering would look like compared to ffdshow's implementation.
I've just selected RGB32 resp. RGB32HQ as output colorspace in ffdshow. Dithering in ffdshow is disabled, of course.
Here's the sample I used for testing:
Banding_720p.rec709.mkv (http://www.mediafire.com/?to56a070x43dskn)
It's not a big deal. I wasn't sure whether this was a configuration problem on my side or just the way things work. :)

[Hera]

Non-Jan's builds (such as the latest stable release):

I still cannot figure out why MPC greys-out subtitles when using Haali renderer on XP on Athlon XP 3000+, but allows them for EVR/VMR output modes.

Additionally, all the GPU options are also greyed-out for both EVR and VMR on my XP rig - this also seems like a regression.

Considering that EVR/VMR are complete **** compared to Haali renderer in terms of performance for CPU-decoding, I need a fix for this!

[nevcairiel]

Haali Renderer does not support the MPC-HC internal subtitle renderer. The Haali Renderer is not part of MPC-HC, and you should ask Haali to support it - but good luck in that ever happening.

[madshi]

I thought the Haali renderer did support subtitles? I'm confused... (sorry, I've not really looked into the whole subtitle topic yet).

[sneaker_ger]

I thought the Haali renderer did support subtitles? I'm confused... (sorry, I've not really looked into the whole subtitle topic yet).

It does, nevcairiel is wrong.

[nevcairiel]

I suppose it does, i didn't really double check, and greying out the options sounds like it plain doesn't support it.

In any case, i wouldn't recommend the Haali Renderer to anyone, its pretty buggy these days.

[fastplayer]

In any case, i wouldn't recommend the Haali Renderer to anyone, its pretty buggy these days.
...and should be removed as a renderer from MPC-HC.

[Hera]

I suppose it does, i didn't really double check, and greying out the options sounds like it plain doesn't support it.

In any case, i wouldn't recommend the Haali Renderer to anyone, its pretty buggy these days.

Things that weren't greyed out before,
- VMR settings on XP, now they are
- Subtitles on XP w. Haali Renderer, now they are

Both of these settings work on W7 + 64-bit MPC.

You can remove Haali Renderer if you make EVR & VMR utilize its features, as it stands now Haali Renderer skips the least and offers the best performance while EVR/VMR drop frames and stutter on Athlon XP 3000+

[namaiki]

as it stands now Haali Renderer skips the least and offers the best performance while EVR/VMR drop frames and stutter on Athlon XP 3000+

What's the graphics card and which resizer is being used for EVR/VMR? Also, try disable MPC-HC's VSync for EVR/VMR.

(I don't have an XP rig to test)

Are you using MPC-HC 2903?

What do you mean by "VMR settings on XP" do you mean the options for the VMR renderless video renderers?
And what do you mean by subtitles are 'greyed out' for Haali Renderer?

[ForceX]

You can remove Haali Renderer if you make EVR & VMR utilize its features, as it stands now Haali Renderer skips the least and offers the best performance while EVR/VMR drop frames and stutter on Athlon XP 3000+

I can confirm this. Especially in the case of weak GPUs and notebooks with old OEM drivers (which do not seem to be ever updated -_-) Haali seems to just plain work, whereas VMR/EVR would stutter horribly and VSYNC settings do little to help, and it's the only other renderer which supports the internal subtitle engine And Haali's internal scaler is significantly better than whatever crap the default renderer in Win 7 uses, so I don't see any reason why you'd want to abolish Haali as an option.

@namaiki: I think he means the Subtitles option in the right-click menu is disabled.

[Ryo94]

I just noticed that in some avi files recorded with Camstudio when you drop common image files on MPC the colors are not displayed correctly, is this a bug or I'm missing some codec setting?

Here is a video sample (900KB)
http://www.multiupload.com/S9M8ET94GJ

See like the colors looks odd, like inverted.

[namaiki]

Ryo94, could you please post a screenshot of how the video looks to you and point out what colors are messed up? It looks fine to me as far as I can tell.

Also, which build number/version of MPC-HC are you using?

Is this screenshot (http://img823.imageshack.us/img823/2260/skdjfklsdjf.jpg) of your video looking fine, or messed up? I tested using MPC-HC 2903 32-bit.

[Ryo94]

Weel, that looks fine but this is how it looks here

http://img38.imageshack.us/img38/9517/picqs.jpg (http://img38.imageshack.us/i/picqs.jpg/)

I'm using MPC-HC 1.5.2827 on Win7 32 bits.

[namaiki]

When you have that video open in MPC-HC, what appears in the menu: Play-> Filters?

[Ryo94]

Enhanced video renderer (Custom Presenter)
ffdshow video decoder
Avi decompresor (CRAM)
d:\video.avi

[Hera]

What's the graphics card and which resizer is being used for EVR/VMR? Also, try disable MPC-HC's VSync for EVR/VMR.

(I don't have an XP rig to test)

Are you using MPC-HC 2903?

What do you mean by "VMR settings on XP" do you mean the options for the VMR renderless video renderers?
And what do you mean by subtitles are 'greyed out' for Haali Renderer?

GPU doesn't have h264 support, doesn't do much.
It is a simply issue of poor EVR/VMR CPU utilization compared to Haali. CPU with Haali is much higher than with EVR/VMR, the system is less responsive, and the video plays much much much better.
Hell if the video is too much no matter what - CPU will stay saturated at 100%. Quite impressive!
Confirmed better than VMR/EVR on Athom N270 and XP 3000+

Can't change V-Sync settings: as I said the settings are greyed out - can't change any renderer settings.

Right Click -> Subtitles. Both internal MKV splitter and the external.

I am inquiring to why this is so.... :confused:

Pretty much up-to-date Windows XP, new install with latest DX.

[namaiki]

Enhanced video renderer (Custom Presenter)
ffdshow video decoder
Avi decompresor (CRAM)
d:\video.avi

On my PC, in place of ffdshow video decoder there is 'Color Space Converter'. If I put ffdshow video decoder there instead, I can reproduce the same issue.

Can't change V-Sync settings: as I said the settings are greyed out - can't change any renderer settings.

There are a number of such settings. Could you please post a screenshot (in this way, there will be no confusion) so that I can investigate?
Also, what is listed in the menu: Play-> Filters, when you have the video open?


Right Click -> Subtitles. Both internal MKV splitter and the external.
In MPC-HC: is View-> Options-> Playback-> Auto-load subtitles ticked? Also, are the subtitles in the MKV file or external(for example, .ssa or .srt)

Finally, what build number of MPC-HC are you using? The model of video card matters as MPC-HC's internal subtitle renderer has certain requirements which I can't recall of right now.

[Ryo94]

On my PC, in place of ffdshow video decoder there is 'Color Space Converter'. If I put ffdshow video decoder there instead, I can reproduce the same issue.

How do I replace ffdshow for the Color Space Converter on that list?

[namaiki]

Go into ffdshow video configuration, go to the bottom of the Codecs/Decoder list and there is an item called Raw video. Try disable that for now and see if the other filter loads instead.

[Ryo94]

It works! but instead disabled I set it for YUV otherwise videos won't play in SubtitleWorkshop (I remember to enable this and set it for all supported because of SW)
Thanks a lot for your help namaiki!

[bobdynlan]

I have enjoyed MPC-HC for as long as I can remember and I used it with the DScaler IVTC mod, because that is the only MPEG decoder that allows hard coded telecine to be removed. Unfortunately the latest versions crash when opening the DScaler settings. I read through this thread and many commented on this problem and like them I was hoping that this could be patched.

I want to stay with MPC-HC because I am so used to its operation but if the 1080i broadcasts can no longer be played back at the frame rate that they were shot I might have to close the chapter on MPC-HC and find a replacement. That would be too sad as I have used this player for such a long time.

Just to quote madshi from http://forum.doom9.org/showpost.php?p=1427202&postcount=4235

Looks like it is worthwhile to find a solution for this.
It would be nice if the two would continue to work well together.
I also use the IVTC modded dscaler, as it is still the best solution for wrongly flagged and/or telecined content. The last version of mpc where the property page of IVTC-dscaler works is 1356. I saved this version, just to change the settings for dscaler. Fortunately once the settings are changed, one can switch back to newer versions of MPC for viewing. But this is a long standing bug in all versions of mpc-hc since 1356.If its not SSE/MMX then you can be sure that the filter being used has a bug that causes it to buffer overflow.
Running it with DEP disabled can have negative side effects on your windows session. It's a bug in DScaler, but it's not a very serious one - gui/registry stuff. Too bad sources of the extra options can't be found as I understood, it would have been better to fix the cause not go around it.

Those who can live with it can patch their own copies of mpc-hc. Either follow the tip about editbin, or use my batch file to toggle this DEP stuff on/off on the exe. The script will find mpc-hc if you have video files associated, but if not, place a copy in the same folder or pass the filename as a parameter to the script. Patched output is renamed with _ prefix.
Download from http://office.live.com/self.aspx/Shared/BATCH/NXTOGGLE.BAT (http://cid-d561cc7d122f3f32.office.live.com/self.aspx/Shared/BATCH/NXTOGGLE.BAT)
:: NXBIT TOGGLE FOR PE FILES
::
:: REQUIRED PARAMETER:
:: - PE file (exe, dll)
:: - this version is customized for mpc-hc, if no parameter is received it will search for mpc-hc.exe
::
:: ABOUT:
:: Programs having DEP enforced crash when loading external libraries that are not DEP compatible,
:: for example MPC-HC with the DScaler5 beta MPEG2 codec when going to the filter options. This is not a bug
:: in MPC-HC, but expected behaviour from linking with enhanced security support.
::
:: It is recommended to fix the external library, but if that's not possible, what do you do?
:: People suggested that the source code of MPC-HC should change back, or to disable DEP system-wide. I don't
:: see the point in lowering overall security for just a particular issue. Not when it's a rather trivial task
:: to patch the DEP enabled program on the client side. Microsoft provides an easy tool named EDITBIN in the
:: Windows SDK: EDITBIN /NXCOMPAT:NO or /NXCOMPAT filename to disable/enable DEP Compatibility check
:: Some may not want to install Windows SDK just for this. I've seen a patch for some program advertised as
:: very advanced and asking for donations for the hard work. It was using a bundled EDITBIN tool... Anyone can
:: pack that 1MB link.exe + mspdb100.dll and call it a "patch". I choosed the harder way.
::
:: This batch file will toggle the NX bit of the PE file you choose, and nothing more. It's output is very much
:: alike that of EDITBIN (if not identical), and it's doing this with api's available on a default Windows install.
:: I still recommend EDITBIN for all the options it has, but if you need just this function, you're set.

[gngn]

Non-Jan's builds (such as the latest stable release):

I still cannot figure out why MPC greys-out subtitles when using Haali renderer on XP on Athlon XP 3000+, but allows them for EVR/VMR output modes.

Additionally, all the GPU options are also greyed-out for both EVR and VMR on my XP rig - this also seems like a regression.

Considering that EVR/VMR are complete **** compared to Haali renderer in terms of performance for CPU-decoding, I need a fix for this!

i dont have on XP the problems you describe. i get subtitles with Haali Renderer, in any combination of the internal subt. engine/DirectVobSub + internal mkv splitter/Haali Splitter. only thing is that if you use DirectVobSub the "Subtitles" option from the right-menu is greyed out, as that option only works with the internal subt engine and not with the third-party DirectVobSub.

all GPU options are greyed out on any renderer with the exception of VMR9renderless+EVR Custom Pres as they were made specifically for only those 2 renderers.

[clsid]

It works! but instead disabled I set it for YUV otherwise videos won't play in SubtitleWorkshop (I remember to enable this and set it for all supported because of SW)
Thanks a lot for your help namaiki!The original problem with wrong colors was probably due to the buggy conversion of BGR24 to RGB24 in ffdshow. So you could also try unchecking RGB24 on the Output page in ffdshow settings. That will trigger conversion to RGB32 and hopefully give proper colors.

[boyumeow]

@Hera,
Have U try using directx web installer rather than standalone installer? Not sure this will work, just checking. Thanks.

[Hera]

I determined that MPC disallows subtitles if I enable CoreAVC, this worked just fine before,
http://img87.imageshack.us/i/coreavchaali.jpg/


EDIT: Renderer settings magically appeared after re-installing DX from standalone installer. Odd - I never had a limbo state where DirectX allowed some features to work but not others - it either worked or told me that I forgot to update DirectX...
Subtitles are still non-functioning.

And here is the VMR9 greyed out options
http://img199.imageshack.us/i/vmr9renderless.jpg/
The *only* settings that work: reset optimal - reset default - tearing test. Everything else greyed out.

Odd.

[namaiki]

subtitles

You seem to have missed the bottom part of my previous post:
Also, what is listed in the menu: Play-> Filters, when you have the video open? (with subtitles)


In MPC-HC: is View-> Options-> Playback-> Auto-load subtitles ticked? Also, are the subtitles in the MKV file or external(for example, .ssa or .srt)

Finally, what build number of MPC-HC are you using? The model of video card matters as MPC-HC's internal subtitle renderer has certain requirements which I can't recall of right now.

[Hera]

Build number is in the screenshots provided - 1.5.1.2959.
Same exact issue with latest stable build.
GPU: NV 6600 non-GT 256MB AGP8x - 2-hundred series drivers.

Issue is Haali Renderer + CoreAVC reproducible. Which I don't get at all.
Subtitle menu was not greyed out when CoreAVC was not set to preferred codec.
Which is odd, or just a coincidence or something... ?

I will do more testing tomorrow.

[ceb]

Hi, I started using MPC-HC a few years ago although only now I'm starting to 'tweak' the settings to have the best quality. I have some questions, I hope someone can answer them even though they come from a newbie. :p
My CPU is an Intel Core i5 2500 and my video card is an ATI 5770. I use Windows 7 64-bit with all the latest drivers, please note that I use the "Only Driver" version of the Catalyst since I don't need the CCC. I use the 64-bit version (with installer) of MPC-HC, currently I have version 1.5.2.2962.
Please don't suggest me using other software (FFDShow, Reclock, etc.) because I want to use onyl MPC-HC.
I mainly watch anime with subtitles, the formats are:
- .mkv - 720p with soft and hard subs
- .mp4 - 720p with hard subs
- .avi - 480p (640x480) (not sure if it is correct, probably DivX quality) with hard subs

1) This is what I do after installing the 64-bit version (with installer) of MPC-HC, correct me if I'm doing something wrong or if I can do anything else to increase video quality. I've only written the changes that affect the video, everything else is at default (except some UI settings).
- change the output resizer to "Bicubic A=-1.00 (PS 2.0)
- in the internal filters, disable the DXVA on MPEG-2, H264/AVC and VC1
- change the maimun texture resolution of subtitles to "Desktop"
- enable the "Sharpen Complex 2" shader - I noticed that this one makes the hard subs look a little bit uglier, but from a certain distance it's not noticable anymore

2) I use the 64-bit version, does it have any downside against the 32-bit one? I don't use any other sfotware (like FFDShow and such), only MPC-HC, so there isn't any problem in that way.

3) When the camera moves in a video, it seems to "stutter" a bit. The audio and subtitles do not go out of sync. Not a big deal, but I would prefer to resolve it.

4) As I've written in the first question, I disable the DXVA. I do this because with .mp4 videos, if the DXVA is enabled, I can only hear the audio with a black video. Maybe it's an incompatibility with the Sandy Bridge processors?
Anyway, since my CPU is powerful enough (I think), should I disable it always?

5) What does the "Round up to power of two" option in the subtitles do?

I know they are a lot of questions, I hope someone has the patience to help me.
Thanks. :)

[namaiki]

Issue is Haali Renderer + CoreAVC reproducible. Which I don't get at all.
Subtitle menu was not greyed out when CoreAVC was not set to preferred codec.


What is listed in the menu: Play-> Filters, when you have a video open with subtitles and CoreAVC is not being used?

In MPC-HC: is View-> Options-> Playback-> Auto-load subtitles ticked? Also, are the subtitles in the MKV file or external(for example, .ssa or .srt)

[Momber]

It has always bugged me that the subtitle renderer of MPC-HC causes dropped frames with DXVA (tried all XP, Vista and 7) so I upgraded to a more powerful computer and am using software decoding now.
Now the subtitle renderer causes tearing! (Using EVR-CP under XP SP3 at the moment).
Please advise how to resolve this, or alternatively, if it's a bug of MPC (which I believe it is because it has been reported by many people for at least two years), provide an ETA for a fix.
Thank you.

[namaiki]

What about: View-> Options-> Renderer-> Reset-> Optimal?
(good luck if you're on ATi)

Also, is this on the bug tracker?

[madshi]

Hey Momber, the best tearing fix is to use fullscreen exclusive mode. Of course that comes at the cost of not having the full GUI (with the stock renderers). EVR-Custom has some tearing/VSync related options, you can try playing with them to get rid of tearing even in non-exclusive mode. Maybe you will succeed. Of course you can also give madVR a try. It automatically switches between windowed and exclusive mode, so you get the best of both worlds... :) However, madVR doesn't support the MPC-HC subtitle renderer yet.

[JanWillem32]

I've patched an over-filtering bug of the subtitle renderer, but it's otherwise a badly maintained, single-threaded resource hog. It even renders on a A4R4G4B4 surface...
I tried setting up a transport of screen space overlay surfaces, just like with the OSD screen (similar renderer) on vanilla EVR. It's very difficult. The lack of developers to help develop the subtitle renderer is a problem, it should have been edited long ago to use some more recent rendering methods.

[cca]

I've patched an over-filtering bug of the subtitle renderer, but it's otherwise a badly maintained, single-threaded resource hog. It even renders on a A4R4G4B4 surface...
I tried setting up a transport of screen space overlay surfaces, just like with the OSD screen (similar renderer) on vanilla EVR. It's very difficult. The lack of developers to help develop the subtitle renderer is a problem, it should have been edited long ago to use some more recent rendering methods.
That's my experience with it too, depends a lot on how fast the CPU is per single core. Makes sense if you realize it was written years ago, before the multicore CPU era.

[JanWillem32]

I'm happy to report succes on replacing the trilinear interpolation for the LUT of the color management, without making it much heavier to process.
Because of a few optimizations, it's now a lot faster to switch the dithering test mode, dithering, and color management off and on again. The initialization of the main renderer should be slightly faster, too.
I'm definitely satisfied with the improvements I made today.

[madshi]

I'm happy to report succes on replacing the trilinear interpolation for the LUT of the color management
What did you replace it with? Isn't trilinear interpolation exactly what is needed? At least that's what I'm using in madVR for 3dlut math.

[janos666]

What did you replace it with? Isn't trilinear interpolation exactly what is needed? At least that's what I'm using in madVR for 3dlut math.

I think tri-linear is the safest method (and should be good enough) but it should be some kind of polynomial interpolation (in theory) because these RGB values are gamma weighted (or not... but mostly...).
And it applies for the dithering noise as well. That should be gamma corrected too (at least in theory...).

You can find his current method in final.psh (in his source code package).

@JanWillem32
Yes, it feels much faster now.

[madshi]

So it's tri-cubic interpolation now or something like that? Ok, you're using smaller 3dlut sizes than yCMS does, right? I guess with small 3dlut sizes using tri-cubic might be worth it.

[janos666]

So it's tri-cubic interpolation now or something like that? Ok, you're using smaller 3dlut sizes than yCMS does, right? I guess with small 3dlut sizes using tri-cubic might be worth it.

64x64x64, 128x128x128 or 192x192x192, according to the settings (Low, Medium, High).
But the values are float16 or float32 numbers, according to the surface settings.

I tried to hit the 256^3 with the High option but it fails with 32-bit numbers. (227^3 is the highest working number but it works with widowed mode only. At least with any VGA cards which it was was tested with... ; 256x256x256@16bit works fine but it's slow to create.)

[Hera]

@Jan
I get corruption (video extremely super contrasted) with this new build when using "Bilinear PS (2.0)" resizer.
This is the Radeon 4250 rig.

EDIT: It might be more appropriate to say Colors become extremely over saturated bright when video is scaled using P2.0 resizer.

[madshi]

64x64x64, 128x128x128 or 192x192x192, according to the settings (Low, Medium, High).
But the values are float16 or float32 numbers, according to the surface settings.

I tried to hit the 256^3 with the High option but it fails with 32-bit numbers. (227^3 is the highest working number but it works with widowed mode only. At least with any VGA cards which it was was tested with... ; 256x256x256@16bit works fine but it's slow to create.)
Ah, interesting. As you (probably) know, madVR/yCMS uses 256x256x256@16bit. If you find any test patterns where you can see or measure a difference between trilinear and tricubic interpolation, please let me know, thanks.

[janos666]

I think the current interpolation is actually worse. :( (But it's only my first impression.)
EDIT: And my second impression is that I should recalibrate my display. :)

[Eliminateur]

Jan,
umfortunately, screencap function is still broken even without FullFP.
i've disabled fullFP (left 10 bit rgb) and look at the result attached

if i disable 10bit then it works as expected.

(this is with RGB32 being fed to the renderer)

[Momber]

Thanks for the recommendations re. renderer settings / subtitle renderer.
And "hi" to madshi in particular. Long time no see :)

I guess I should add that I have already optimized the Renderer / Vsync settings and I'm getting perfectly smooth playback at all appropriate refresh rates just as long as I don't try to display srt subtitles

I use EVR-CP mainly because of the color management it supports. My pj is calibrated and the ICC profile makes quite a noticeable difference when it's getting used by the player.

I'm using D3D fullscreen w/GUI support. Without the use of a GUI, I would probably shoot myself.

Yes, my video card is a Radeon.

My CPUs is an Intel dualcore running at 3.3 GHz per core and Windows task manager shows that it's mostly rather bored, even when playing back BluRay video. No, I'm definitely not using DXVA.

[gngn]

@Jan
I get corruption (video extremely super contrasted) with this new build when using "Bilinear PS (2.0)" resizer.
This is the Radeon 4250 rig.

EDIT: It might be more appropriate to say Colors become extremely over saturated bright when video is scaled using P2.0 resizer.

result is even worser on Nvidia (doesnt matter what decodingfilter is used. doesnt happen with Bicubic or if i check "Video Frame=Normal Size"):
http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/th_bilinearps20.png (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/bilinearps20.png)

[Hera]

result is even worser on Nvidia (doesnt matter what decodingfilter is used. doesnt happen with Bicubic):
http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/th_bilinearps20.png (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/bilinearps20.png)

Looks 'bout the same.

[janos666]

@madshi (mainly, but anybody else)
Which one do you think is better: 256^3@float16 or 192^3@float32 (with the current cubic interpolation...)?

Because it seems that we won't hit the 265^3@float32 any time soon, so may be it would be advisable to use float16 textures exclusively and set the High quality preset to 256^3.

The interpolation theoretically works better with higher precision numbers but I am not sure if the sample point quantity is not more important than the precision of the individual samples (given that these are gamma weighted numbers).

But I think these questions are far away from the precision of the spectrophoto-, and colorimeters which we can afford and use at home. (Not to mention our eyes.)

[dawar49]

this latest build is destroying my graphics card. albeit it's only a 8600m gt. tester 2 based off of 2963 worked fine. iirc gpu-z reported gpu usage below 20%. with this build i can only get a few frames per second and gpu usage gets maxed out. eventually mpc crashes. disabling lcms fixes the problem.

[namaiki]

Is full floating point precision on? My 9600M GT(pretty much the same card) can't handle that, only half.

[madshi]

Which one do you think is better: 256^3@float16 or 192^3@float32 (with the current cubic interpolation...)?
Well, I don't have the ultimate truth for that. I can only speculate. For one thing 256^3@16 = 96MB. 192^3@32 = 81MB. So 256^3@16 has a higher data depth... :p Not sure if that means anything, though. I like it that 256^3@16 exactly matches the bitdepth of the source data (8bit). However, interpolation is still necessary, anyway, so I'm not sure how much worth that has. Having higher "output" bitdepth sounds worthwhile, but then 16bit per component = 48bit per pixel already sounds like plenty to me.

[JanWillem32]

A lot of responses this time.:)
The bilinear shader was subject to an experiment. I forgot to paste the correct code back in. I'll integrate it with the next release. Thanks for the input.
I re-used the code from "Catmull-Rom spline4×4 sphere" in the final pass shader for the 3DLUT, so it's a spline4×4×4 interpolation. I didn't try cubic or Lanczos interpolation for it yet. I just wanted to get gradients behave better in 10-bit mode with debanding. Trilinear filtering is not accurate for interpolating (gamma) curves, so I just tried something better suited.

@dawar49: I guess with a video card that has weak memory management and memory clock, sampling 64 items from a volume texture is a bit too much compared to the 8 items that it used to be. I'll add an option to the settings. I didn't notice slower playback or anything at all, so I wonder what I should set as default.

@janos666: I guess we could also try a 16-bit integer format, as the sign and exponent bits aren't really used with both floating-point 3DLUT textures. The problem of that format is that it has worse support than 32-bit floating point, still has less minimum precision and I don't know how fast the integer to floating point conversion on loading pixels from the 3DLUT is with this type.

@Momber: D3D fullscreen lost GUI support ages ago. The bar at the bottom of the screen is generated by the OSD renderer.

@Eliminateur: I can't replicate this problem, but I guess your video card refuses to convert the 10-bit input to 8-bit when transferring into an off-screen plain surface. I haven't found the right function to generate errors with yet, but it should at least refuse to output a file when conversion fails. Does it?

[burfadel]

My HD4850OC 1gb can, just. There is times when it just looks like its below framerate (compared to normal) i noticed last night. Mind you, I'm also using the v22 shader scripts:
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
sharpen complex v3 + deband + mild denoise
16-235 to 0-256 for SD&HD video input

[madshi]

I just wanted to get gradients behave better in 10-bit mode with debanding. Trilinear filtering is not accurate for interpolating (gamma) curves, so I just tried something better suited.
Is there a sample I can check to see the non-optimal gradients with trilinear interpolation? Thanks!

[JanWillem32]

@burfadel: Do you actually have the ranges expansion bug? It's rather rare.
The "sharpen complex v3 + deband + denoise" shader is the very heaviest of all. I added the comment to use full 3D clocks with it. I can't use it on 30/1.001 Hz or higher input frame rates with mild rendering settings on 2D clocks at all. With subtitles, it's of course even worse.

@madshi: I'll take a look if I can generate a synthetic test, or find a sample without copyrights. I do have a few samples of the worst banding gradients ever. Even 10-bit output with the "blur" shader in FFPP and single-level dithering added fails on those.
Red to brown top-to-bottom and to black right-to-left is my current "favorite" banding picture. It's nearly as horrible as the "nails on a chalkboard" audio sample I edited for a matrix mixing and clarity test.

[burfadel]

I'm pretty sure I don't have that bug, but strangely I think it does look better with it added! (on both the computer screen and TV). I guess basically its like adding a bit of dynamic contrast enhancement?...

Before someone asks - I have calibrated both screens with the Windows calibration tool (accessible from 'display' or 'color management' in the control panel.

Out of curiosity, how many shaders does each shader script use, such as the sharpen complex v3+deband+denoise?

[madshi]

@madshi: I'll take a look if I can generate a synthetic test, or find a sample without copyrights. I do have a few samples of the worst banding gradients ever. Even 10-bit output with the "blur" shader in FFPP and single-level dithering added fails on those.
Red to brown top-to-bottom and to black right-to-left is my current "favorite" banding picture. It's nearly as horrible as the "nails on a chalkboard" audio sample I edited for a matrix mixing and clarity test.
A sample or synthetic test would be awesome - thanks! :)

[JanWillem32]

@burfadel: The expansion shader does nothing but expanding and unbalancing the 3 RGB saturation ranges and expanding the luma range (more for white than black). The source colors that fall out of this range, are clipped to minimum or maximum intensity, so they're lost.
Both "RGB brightness, contrast and gamma control" and "hue, saturation, luma gamma and chroma gamma control for SD&HD video input" have balanced and accurate color controls. If used appropriately, these won't damage the picture as much.
It tends to depend on the source video, but sometimes I de-saturate with the chroma gamma control and I often shift the general RGB gamma. I hardly ever have to change the other controls.
I use a CRT with the analog controls set to near 2.6 gamma and additional digital calibration by a i1 Display. It's pretty hard to get all source videos lined up to look right, but my settings proved to be very rewarding yesterday. (I also have a projector, but it needs some work at the moment.)
For your other question: the scripts all contain a single shader. That's also why the scalers (muti-pass) are in 2 separate scripts.

I've added audio samples to my folder, I don't know if the video samples are going to work out. The synthetic test I tried can't generate any proper gradients, so I'll have to write a gradient shader. (Maybe it's even useful as an integrated banding and gamma bars test.)

[vBm]

This is offtopic but it's kinda important.
Before you go and install SP1 for VS2010 better read THIS (http://msdn.microsoft.com/en-us/visualc/gg697159) first. Pro and Express versions are exposed to this flaw.

[Eliminateur]

I'm using a Radeon 5870 with cat 10.12 (december ones iirc)
It isn't refusing anything, it saves the file as shown(it isn't a printscrn->save the one i attached, it's a result from the save image function)


@Eliminateur: I can't replicate this problem, but I guess your video card refuses to convert the 10-bit input to 8-bit when transferring into an off-screen plain surface. I haven't found the right function to generate errors with yet, but it should at least refuse to output a file when conversion fails. Does it?

[hoborg]

DTS stuttering problem

Hi.
I found some MKV with DTS track that is causing stuttering and droped frames if EVR custom or EVR sync renderer is in use.
Simple EVR have no problem.

Sample video is here (http://rapidshare.com/files/452072726/Sample_PA2.mkv).
I tryed LAVF splitter, FFDshow audio/video decoder, with the same result. Problem seems to be in custom renderer.

[G_M_C]

Janwillem, Janos, i have (another) i hope you have the opportunity to answer;

Currently my setup is as follows;
PC, Ati HD 5770, YUV 4:4:4 full range --> Onkyo TX-SR 875, with REON VX enabled.

As you can see, my receiver has a S.O. Reon video processor build in. It has full 10/12 bit processing. My receiver accepts, among others, YUV 4:4:4 and RGB 4:4:4 (both studio as full range) and some 10-bit color mode I guess.

Through the CTRL-J screen I see that MPC's mixer outputs A32R32G32B32F, I also read that 10 bit color is set for the output of D3DFS.

My question is as follows; In relation to what my video processor accepts, what output color space do i set my HD 5770. I can select YUV 4:4:4 (studio/full) or RGB 4:4:4 (studio/full). My goal is to have as less conversions as possible.

The reason i came to my question: I see the MPC's mixer outputs A32R32G32B32F, but I have set output on my HD5770 as YUV 4:4:4 (full). Isnt there a conversion needed between the two, the RGB (mixer) -> YUV ( output) ?

[janos666]

@janos666: I guess we could also try a 16-bit integer format, as the sign and exponent bits aren't really used with both floating-point 3DLUT textures. The problem of that format is that it has worse support than 32-bit floating point, still has less minimum precision and I don't know how fast the integer to floating point conversion on loading pixels from the 3DLUT is with this type.


EDIT: Hmm... On a second thought it sounds much better to use unsigned 16-bit integers instead of float16 numbers. And we could use bigger LUTs (like 256^3, even with the 32-bit surface mode), and I think it would worth it because 16-bit should be enough while the quantity of the sample points is important too, given the nonlinear nature of the RGB numbers. (And we could still benefit from the extra precision of the float32 surface during the interpolation which is inevitable anyway...)
And it would allow some more simplifications...
However, my first quick attempt to use a D3DFMT_A16B16G16R16 texture didn't go well.


@G_M_C
You have to choose RGB Full in CCC. (It's not a question with today's hardwares and softwares.)
The source is usually YV12 which is YCC 4:2:0 but you can't send it out through any standard connections. You have to resize the chroma first. The result is usually RGB (as your VGA usually works with RGB data) and your VGA should send out it without converting it back to YCC, just to let your external VP to convert it back to RGB again (because your display has RGB pixels ; there is no YCC display).
And the precision of this conversion depends on your Presentation settings. It can be even float32 which is much higher than the precision of your external VP anyway. (More precisely, the surface is float32 at max, but the calculation precision of your GPU can be even higher...)

[Aleksoid1978]

DTS stuttering problem

Hi.
I found some MKV with DTS track that is causing stuttering and droped frames if EVR custom or EVR sync renderer is in use.
Simple EVR have no problem.

Sample video is here (http://rapidshare.com/files/452072726/Sample_PA2.mkv).
I tryed LAVF splitter, FFDshow audio/video decoder, with the same result. Problem seems to be in custom renderer.

Play fine - no drop frames. EVR Custom with internal DTS and ffdshow Audio Decoder.

[hoborg]

Play fine - no drop frames. EVR Custom with internal DTS and ffdshow Audio Decoder.

Whole video? It doesn't appear on begin. Win7x64, ATI 5770, stereo output (no passthrough).

For example MediaPortal users have exactly same issues (http://forum.team-mediaportal.com/watch-edit-videos-104/mkv-dts-dropped-frames-94320/).

EVR:
http://www.volny.cz/hoborg/evr.jpg

EVR Custom:
http://www.volny.cz/hoborg/evr_custom.jpg

[Aleksoid1978]

Whole video? It doesn't appear on begin.

Yes - whole video(http://rapidshare.com/files/452072726/Sample_PA2.mkv). drop frames = 0.

[Mercury_22]

Why isn't bobdynlan & Leo1000's patch AKA BE Mod (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-2-2969.html) in the svn ?
Does anybody oppose to make their mod the default GUI ?

[hoborg]

Yes - whole video(http://rapidshare.com/files/452072726/Sample_PA2.mkv). drop frames = 0.

No stuttering?
Maybe you have some diferent setting in custom renderer.
Ideas?

EDIT:
Stats added:
http://www.volny.cz/hoborg/evr_custom_stats.jpg

[G_M_C]

[...]

@G_M_C
You have to choose RGB Full in CCC. (It's not a question with today's hardwares and softwares.)
The source is usually YV12 which is YCC 4:2:0 but you can't send it out through any standard connections. You have to resize the chroma first. The result is usually RGB (as your VGA usually works with RGB data) and your VGA should send out it without converting it back to YCC, just to let your external VP to convert it back to RGB again (because your display has RGB pixels ; there is no YCC display).
And the precision of this conversion depends on your Presentation settings. It can be even float32 which is much higher than the precision of your external VP anyway. (More precisely, the surface is float32 at max, but the calculation precision of your GPU can be even higher...)

Thanx Janos for the comprehensive explanation :)

[Aleksoid1978]

No stuttering?
Maybe you have some diferent setting in custom renderer.
Ideas?

i don't use any Sync .

http://s54.radikal.ru/i144/1103/d4/104e20ad6c9at.jpg (http://radikal.ru/F/s54.radikal.ru/i144/1103/d4/104e20ad6c9a.png.html)

http://s61.radikal.ru/i172/1103/f8/1de72492357et.jpg (http://radikal.ru/F/s61.radikal.ru/i172/1103/f8/1de72492357e.png.html)

[namaiki]

No stuttering?
Maybe you have some diferent setting in custom renderer.
Ideas?

EDIT:
Stats added:

Perhaps 24fps material might be more tolerable on a screen set to 60Hz, or a multiple of 24.

[Momber]

@Momber: D3D fullscreen lost GUI support ages ago. The bar at the bottom of the screen is generated by the OSD renderer.
What about the context menu?
Anyhoo, I referred to it by its current name. I did not name it that way.

http://i17.fastpic.ru/big/2011/0312/d0/9e21eb59811c6b2a73064d83641772d0.gif

Still waiting on enlightenment regarding the subtitle renderer issue (tearing and/or dropped frames). TIA.

[Hera]

Back to haali ssue, under Filters I have,

Default Direct Sound Device
Video Renderer
Audio Switcher
CoreAVC Video Decoder
DTS Decoder
And a subtitle menu there as well


Subs are enabled in Maroska Splitter and in "Navigate - Subtitle Language" but the right lcik subtitle menu is greyed out and there is no subtitles.Ideas welcome.

[Mercury_22]

How can I apply mod BE patch (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-2-2969.html) to my src ?
Right now I'm using TortoiseSVN's "Apply patch" but it can't apply the patch for mplayerc.rc, resource.h, mplayerc.ru.rc !
I'm receiving the message :
The patch seems outdated! The line and the patchline CONTROL "Haali Renderer**",IDC_DSDXR,"Button",BS_AUTORADIOBUTTON,10,149,93,8 do not match!

What am I doing wrong ? Please help !

[nevcairiel]

Sounds like the patch is outdated. If a line changes that it intends to patch, the patch needs to be updated. You could of course do that manually yourself, but explaining that here is more then i want to write. =)

[janos666]

How can I apply mod BE patch (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-2-2969.html) to my src ?
Right now I'm using TortoiseSVN's "Apply patch" but it can't apply the patch for mplayerc.rc, resource.h, mplayerc.ru.rc !
I'm receiving the message :


What am I doing wrong ? Please help !

It's a problem between the encoding format of those files and your SVN client. It's weird but the patches you create with the TurtoiseSVN tools are valid but they can not be automatically applied by TurtoiseSVN itself.

[mark0077]

Guys can anyone help me with a very strange video frame drop issue I'm having. I have been tweaking avisynth scripts for the past few weeks to see how high quality interpolation from 24~ to 50fps I can achieve and still have 0 frame drops. Well I have it tweaked to perfection now and can watch full 1080p movies like Avatar and by other blu-rays with 0, maybe 1 or 2 frame drops throughout.

But then I have a few 1080p files mkv / mp4 / others that I get the same number of frame drops throughout repeatedly. I have been debugging all day and have found that no matter how low quality I set my avisynth scripts to, I'm still getting frame drops at around the same rate on these particular files. I switched to evr-cp to see the graphs and notice something weird which I'm hoping someone can explain. When I use ctrl-j to show the stats, and when watching avatar at 50fps on 50hz, I see perfectly flat red and green lines. When I watch it at 23.976fps at the same hz, I get perfectly flat lines again, however with these problem files, the green line looks like its jittering up and down very quickly, like it never goes straight. Even with no ffdshow or avisynth involved, the same happens with these files. cpu usage is often below 10% and these files will still show this effect. Does this mean they were encoded incorrectly, ie non smooth timestampes, or what else can explain the strange green jittery line?

I have ruled out all of my external filters, and audio renderer / video renderer (getting frame drops with these with mad vr also). I have tried doing a clean install of some older nvidia drivers to see if they had some sort of quirk... What I find weird is even feeding evr-cp 23.976fps RGB32 of avatar I get perfectly flat lines, but with these problem clips I get the jitter effect so I'm not sure what could possibly be at fault.

[hoborg]

Perhaps 24fps material might be more tolerable on a screen set to 60Hz, or a multiple of 24.

But there is no problem if i use simple EVR.
If i remove DTS track, file play perfectly even with custom renderer.
So it must be related to DTS track.

[namaiki]

Back to haali ssue, under Filters I have,

Default Direct Sound Device
Video Renderer
Audio Switcher
CoreAVC Video Decoder
DTS Decoder
And a subtitle menu there as well


Subs are enabled in Maroska Splitter and in "Navigate - Subtitle Language" but the right lcik subtitle menu is greyed out and there is no subtitles.Ideas welcome.
A fallback video renderer (MPC-HC's video renderer with internal subtitle support is not being used) is being loaded.
What video renderer is selected to load in MPC-HC? (View-> Options-> Output)
Also, what graphics card and version of Windows?

[hoborg]

i don't use any Sync .

http://s54.radikal.ru/i144/1103/d4/104e20ad6c9at.jpg (http://radikal.ru/F/s54.radikal.ru/i144/1103/d4/104e20ad6c9a.png.html)

http://s61.radikal.ru/i172/1103/f8/1de72492357et.jpg (http://radikal.ru/F/s61.radikal.ru/i172/1103/f8/1de72492357e.png.html)

Acording to your screenshot you have droped frames (at last one) and stuttering too.

[hoborg]

Found problem in AVI splitter:
This avi sample (http://forum.team-mediaportal.com/attachments/codecs-331/78293d1299932616-saf-v5-00-experimental-based-ffdshow-dxva-decoder-test.zip) (Nikon D90) play at bad speed if MPC-HC AVI splitter is in use.
If i use default OS AVI splitter - no problem

[G_M_C]

But there is no problem if i use simple EVR.
If i remove DTS track, file play perfectly even with custom renderer.
So it must be related to DTS track.

Can you post a screenshot of all (audio-)filters used, and report what audio decoder & renderer you use ?
Not the one you posted before, but a screenshot of the MPC-Filters menu (right click on video -> filters).

[hoborg]

Can you post a screenshot of all (audio-)filters used, and report what audio decoder & renderer you use ?
Not the one you posted before, but a screenshot of the MPC-Filters menu (right click on video -> filters).

Yes, but not now :/
Right now i am on NetBook.
It is easy to reproduce this issue.

[Hera]

Additionally, Jan's build breaks Haali Renderer on Wx64

A fallback video renderer (MPC-HC's video renderer with internal subtitle support is not being used) is being loaded.
What video renderer is selected to load in MPC-HC? (View-> Options-> Output)
Also, what graphics card and version of Windows?

Yeah, odd...

Fastest one - Haali Renderer
NV 6600, some 2xx series drivers

[G_M_C]

Can you post a screenshot of all (audio-)filters used, and report what audio decoder & renderer you use ?
Not the one you posted before, but a screenshot of the MPC-Filters menu (right click on video -> filters).

Yes, but not now :/
Right now i am on NetBook.
It is easy to reproduce this issue.

Cause i had this issue a long while ago. I'm looking to find out if i can help you.

For a short time i noticed problems with MPC when decoding DTS 1509. When i converted to DTS 1536 it worked fine. Stuttering also happened a short while when 'header compression' in MKV's was first applied. But all these issues have passed.

Are you sure your on a current version of MPC ?

[hoborg]

Cause i had this issue a long while ago. I'm looking to find out if i can help you.

For a short time i noticed problems with MPC when decoding DTS 1509. When i converted to DTS 1536 it worked fine. Stuttering also happened a short while when 'header compression' in MKV's was first applied. But all these issues have passed.

Are you sure your on a current version of MPC ?

Yes.
1.5.1.2959, MSVC 2010 SP1 (SSE), build x86.
As i wrote, it have something to do with Custom Renderer.
Media Portal custom EVR renderer have exactly the same problem.

[Mercury_22]

It's a problem between the encoding format of those files and your SVN client. It's weird but the patches you create with the TurtoiseSVN tools are valid but they can not be automatically applied by TurtoiseSVN itself.

But for the other 15 it's working ! Only for those 3:

resource.h
mplayerc.rc
mplayerc.ru.rc

it's not working
Has anyone else been able to apply the mod BE patch ?
http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-2-2969.html
(near the end of the page)

Maybe I'm wrong but it looks like some files are missing from the patch

[G_M_C]

But there is no problem if i use simple EVR.
If i remove DTS track, file play perfectly even with custom renderer.
So it must be related to DTS track.

Yes.
1.5.1.2959, MSVC 2010 SP1 (SSE), build x86.
As i wrote, it have something to do with Custom Renderer.
Media Portal custom EVR renderer have exactly the same problem.

:confused:

[JanWillem32]

@Eliminateur: Your screenshot isn't approved yet, so I have to ask this: are you using the tester builds downloaded from the folder in my signature (or a direct link)?
I can't imagine that such a new video card would fail on the type of conversion I used in my tester build.

@Momber: D3D full screen GUI support used to work before D3DFS was in exclusive mode. Non-exclusive D3DFS is pretty useless, as it can't do better than the full screen windowed mode. Because of that, I'm against adding a non-exclusive mode. I simply removed the useless option in my builds. If a GUI developer would add buttons to the D3DFS bar or more, it would be most welcome to make the D3DFS mode more functional.
For the subtitles problem: "allow animation on buffering" might help (even for non-animated input), use 3 or 4 subtitle and EVR buffers, and select one installed font that is in a small .ttf file for the default subtitle and OSD font. I patched a minor filtering bug in my builds, so that should help, too.

@mark0077 & quite a few others:
I've seen a lot of questions about synchronizing. It's a complicated thing.
-MKVtoolnix used to allow truncated decimal fractions like 23.98 as a mark for the video stream, instead of the correct 24/1.001. That tiny difference can make synchronizing difficult. Re-muxing with the correct frame rate set for the video stream can help.
-Re-setting the timing registers. If you choose "default or "optimal" rendering settings, these are reset to default numbers. I always reset this if I want to test some timing-critical changes in a new build.
-The handling of de-interlacing and 3:2 pulldown, both in the encoding phase and the decoding phase of the video stream can go very wrong. Check your own settings for de-interlacing and pulldown handling. For EVR I use the de-interlacing filter of the video card, but full support of de-interlacing is limited to the NV12 format. There's support for simple de-interlacing with YUY2 and YVYU. I tested that with DXVAchecker. Jitter or dropped frames by software de-interlacing or decoding can happen if the CPU is slow. Some files are the result of bad encoding. The handling of de-interlacing and 3:2 pulldown while re-encoding (among other things), can really mess up an encoded video.
-Blu-ray and DVD allow 24/1.001, 24 , 25, 30/1.001 and 30 Hz frame rates. 50, 60/1.001 and 60 are allowed with limitations on blu-ray. Of course, you can't use the same synchronization settings for both 24/1.001 and 24 Hz video streams for example.
-The MPEG file container on blu-ray files has a time stamps problem. Use "Enable Frame Time Correction" for only those files, use another container format, or use a splitter that corrects it automatically.

-Not to forget, video tearing on screen also has a big set of problems. Simply said, it's difficult to get a perfect synchronization to a display, without locking a display output in exclusive mode.

If anyone else has some more advise on this, please post it.


I'm not developing this weekend. I'm visiting my parents. Still, I find it very refreshing to see the difference between my own CRT and projector and the LCD panels I see at my current location.
The 4×4 temporal dithering pattern on a cheap 6-bit glossy laptop screen, the TV that damages dynamics of its already awful SCART input and an 8-bit monitor from 2003 that's worn out from its former use at an office, give this developer a view of what many consumers have to endure every day.:)

[Aleksoid1978]

Acording to your screenshot you have droped frames (at last one) and stuttering too.

http://s49.radikal.ru/i123/1103/f5/854e37b1ab93t.jpg (http://radikal.ru/F/s49.radikal.ru/i123/1103/f5/854e37b1ab93.png.html)

[Momber]

If a GUI developer would add buttons to the D3DFS bar or more, it would be most welcome to make the D3DFS mode more functional.
Agreed.

"allow animation on buffering" might help (even for non-animated input), use 3 or 4 subtitle and EVR buffers,
Tried playing with all three settings - no effect.

and select one installed font that is in a small .ttf file for the default subtitle and OSD font.
Okay, that's something I haven't tried yet. The ttf I currently use weighs 317 kB, whereas some other Windows fonts may be as small as 30-50 kB. Thanks for the tip.

I patched a minor filtering bug in my builds, so that should help, too.
Thanks, will try one of your builds ASAP. That would be the file "mpc-hc tester dfr2964.7z" - correct?

Regards

[hoborg]

:confused:

The sample i posted is h.264 with one DTS track.

If i play it in MPC-HC using simple EVR renderer, it play perfectly.
If i use EVR custom or EVR sync, there is stuttering and few druped frames (the stuutering is main problem).

If i use MKV merge and remove DTS track from this video, it will play perfectly using all EVR renderers.

So this mean it have something to doo with DTS audio track.

Using different splitters/decoders didnt change anything.

[ceb]

Hi, I started using MPC-HC a few years ago although only now I'm starting to 'tweak' the settings to have the best quality. I have some questions, I hope someone can answer them even though they come from a newbie. :p
My CPU is an Intel Core i5 2500 and my video card is an ATI 5770. I use Windows 7 64-bit with all the latest drivers, please note that I use the "Only Driver" version of the Catalyst since I don't need the CCC. I use the 64-bit version (with installer) of MPC-HC, currently I have version 1.5.2.2962.
Please don't suggest me using other software (FFDShow, Reclock, etc.) because I want to use onyl MPC-HC.
I mainly watch anime with subtitles, the formats are:
- .mkv - 720p with soft and hard subs
- .mp4 - 720p with hard subs
- .avi - 480p (640x480) (not sure if it is correct, probably DivX quality) with hard subs

1) This is what I do after installing the 64-bit version (with installer) of MPC-HC, correct me if I'm doing something wrong or if I can do anything else to increase video quality. I've only written the changes that affect the video, everything else is at default (except some UI settings).
- change the output resizer to "Bicubic A=-1.00 (PS 2.0)
- in the internal filters, disable the DXVA on MPEG-2, H264/AVC and VC1
- change the maimun texture resolution of subtitles to "Desktop"
- enable the "Sharpen Complex 2" shader - I noticed that this one makes the hard subs look a little bit uglier, but from a certain distance it's not noticable anymore

2) I use the 64-bit version, does it have any downside against the 32-bit one? I don't use any other sfotware (like FFDShow and such), only MPC-HC, so there isn't any problem in that way.

3) When the camera moves in a video, it seems to "stutter" a bit. The audio and subtitles do not go out of sync. Not a big deal, but I would prefer to resolve it.

4) As I've written in the first question, I disable the DXVA. I do this because with .mp4 videos, if the DXVA is enabled, I can only hear the audio with a black video. Maybe it's an incompatibility with the Sandy Bridge processors?
Anyway, since my CPU is powerful enough (I think), should I disable it always?

5) What does the "Round up to power of two" option in the subtitles do?

I know they are a lot of questions, I hope someone has the patience to help me.
Thanks. :)
Can someone help me?

[pirlouy]

Please, to all developers who do own builds, can you create a new thread with your builds, an explanation in the first post on what it's different, and the build number of MPC-HC when it is integrated in the core.
I remember of Beliyaal thread, that was a good solution.

Right now, posting your builds in this thread is not a good solution, you miss a lot of potential testers and this thread is unreadable. :/

[renq]

Perhaps there's a incompatibility/conflict between the CPUs integrated video controller and ATI's dedicated- try disableing GMA HD (the CPU one) if you don't use it. Perhaps that'll solve the DXVA problem.

There are no downside to using 64bit version of MPC-HC compared to the 32bit version in relation to mpc-hc itself. However, Madshi Video Renderer (http://forum.doom9.org/showthread.php?t=146228), for one example, is only 32bit and thus cannot be used on the 64bit version.

[Sina™]

feature request:
aspect ratio: auto format (auto select) & auto zoom (auto pan & scan: scale to screen size & keep aspect ratio, not stretching)

[ceb]

Perhaps there's a incompatibility/conflict between the CPUs integrated video controller and ATI's dedicated- try disableing GMA HD (the CPU one) if you don't use it. Perhaps that'll solve the DXVA problem.
I don't know where to find GMA HD but because I have an Intel P67 motherboard, the intregrated GPU is not usable in any way. Since my CPU is powerful enough, should I just disable DXVA always? I've read that it can cause artifacts. I've disabled DXVA on my previous CPU (Intel Core 2 Duo e5200@3,1GHz) without any problem, my current CPU is a lot more powerful so it should be OK, just would like a confirmation from you experts. :p
There are no downside to using 64bit version of MPC-HC compared to the 32bit version in relation to mpc-hc itself.
Great, for me MPC-HC alone is more than enough. :D

These are the questions left unanswered:
Hi, I started using MPC-HC a few years ago although only now I'm starting to 'tweak' the settings to have the best quality. I have some questions, I hope someone can answer them even though they come from a newbie.
My CPU is an Intel Core i5 2500 and my video card is an ATI 5770. I use Windows 7 64-bit with all the latest drivers, please note that I use the "Only Driver" version of the Catalyst since I don't need the CCC. I use the 64-bit version (with installer) of MPC-HC, currently I have version 1.5.2.2962.
Please don't suggest me using other software (FFDShow, Reclock, etc.) because I want to use only MPC-HC.
I mainly watch anime with subtitles, the formats are:
- .mkv - 720p with soft and hard subs
- .mp4 - 720p with hard subs
- .avi - 480p (640x480) (not sure if it is correct, probably DivX quality) with hard subs

1) This is what I do after installing the 64-bit version (with installer) of MPC-HC, correct me if I'm doing something wrong or if I can do anything else to increase video quality. I've only written the changes that affect the video, everything else is at default (except some UI settings).
- change the output resizer to "Bicubic A=-1.00 (PS 2.0)
- in the internal filters, disable the DXVA on MPEG-2, H264/AVC and VC1
- change the maimun texture resolution of subtitles to "Desktop"
- enable the "Sharpen Complex 2" shader - I noticed that this one makes the hard subs look a little bit uglier, but from a certain distance it's not noticable anymore

2) When the camera moves in a video, it seems to "stutter" a bit. The audio and subtitles do not go out of sync. Not a big deal, but I would prefer to resolve it.

3) What does the "Round up to power of two" option in the subtitles do?

[G_M_C]

The sample i posted is h.264 with one DTS track.

If i play it in MPC-HC using simple EVR renderer, it play perfectly.
If i use EVR custom or EVR sync, there is stuttering and few druped frames (the stuutering is main problem).

If i use MKV merge and remove DTS track from this video, it will play perfectly using all EVR renderers.

So this mean it have something to doo with DTS audio track.

Using different splitters/decoders didnt change anything.

Cannot download the sample anymore to verify, its been removed.

[namaiki]

- change the output resizer to "Bicubic A=-1.00 (PS 2.0)

I prefer -0.60, try upscale a video with different settings in two MPC-HC instances and see which you prefer or if you can see any difference.


- enable the "Sharpen Complex 2" shader - I noticed that this one makes the hard subs look a little bit uglier, but from a certain distance it's not noticable anymore

Personally not a fan of this, but which ever you think looks better.


3) When the camera moves in a video, it seems to "stutter" a bit. The audio and subtitles do not go out of sync. Not a big deal, but I would prefer to resolve it.

Try set your monitor to a multiple of the frame rate of the video. It's probably 24fps, so any easy multiple like 48Hz, 72Hz, 120Hz (also matches 30fps videos), if your monitor supports it would be good.


5) What does the "Round up to power of two" option in the subtitles do?

I noticed that there was less stutter (when subtitle are onscreen) with this unticked on a very weak Intel graphics card - Atom netbook, though it may have been my imagination.

Don't forget to enable subtitle animation and make sure to try JanWillem32 (http://forum.doom9.org/showpost.php?p=1484459&postcount=16575)'s MPC-HC builds for sharper subtitles for one thing.
Or official nightly builds by: XhmikosR (http://xhmikosr.1f0.de/index.php?folder=bXBjLWhj)

[ceb]

Thanks for your answer.
Try set your monitor to a multiple of the frame rate of the video. It's probably 24fps, so any easy multiple like 48Hz, 72Hz, 120Hz (also matches 30fps videos), if your monitor supports it would be good.
My monitor has the refresh rate at 60Hz (max). I also play games on the PC, so lowering the refresh rate isn't quite good for me. Is it possible to change the refresh rate only for MPC-HC when viewing videos?
Anyway, I checked my videos and:
.avi - 23.976 fps

.mp4
Frame rate mode:Variable
Frame rate:24.000 fps
Original frame rate:29.970 fps
Minimum frame rate:17.982 fps
Maximum frame rate:29.970 fps

.mp4 (other video) - 23.976 fps

I noticed that there was less stutter (when subtitle are onscreen) with this unticked on a very weak Intel graphics card - Atom netbook, though it may have been my imagination.
I have it disabled, everything seems OK. Although I'm curious to know what it does.
Don't forget to enable subtitle animation and make sure to try JanWillem32 (http://forum.doom9.org/showpost.php?p=1484459&postcount=16575)'s MPC-HC builds for sharper subtitles for one thing.
Or official nightly builds by: XhmikosR (http://xhmikosr.1f0.de/index.php?folder=bXBjLWhj)
Subtitle animation is enabled (you mean allow animation when buffering right?).
I usually get the builds from xvidvideo.ru but sometimes also from XhmikosR (whichever has the latest). I'll try JanWillem32's builds for the better subtitles.

About the DXVA question, am I fine without it or will I miss something?

[namaiki]

Sorry, but how do I change it? My monitor has the refresh rate at 60Hz (max). I also play games on the PC, so lowering the refresh rate isn't quite good for me.
I checked my videos and:
.avi - 23.976 fps

.mp4
Frame rate mode:Variable
Frame rate:24.000 fps
Original frame rate:29.970 fps
Minimum frame rate:17.982 fps
Maximum frame rate:29.970 fps

.mp4 (other video) - 23.976 fps
......
Does your monitor support anything else than 60Hz? Anway, you can try play with MPC-HC's autochange option. (View-> Options-> Fullscreen)

For me, I have an old CRT monitor set at 72Hz which I sometimes use since my laptop's inbuilt screen doesn't seem to support anything else but 60Hz (which isn't horrible - jitter is only noticable to me when the picture is sliding).

Subtitle animation is enabled (you mean allow animation when buffering right?).
.....
That's the one.

I usually get the builds from xvidvideo.ru but sometimes also from XhmikosR (whichever has the latest). I'll try JanWillem32's builds for the better subtitles.
.....
Hmm... I think all three sources should have the improved subtitles, but JanWillem32 is working on picture quality improvements as well.

About the DXVA question, am I fine without it or will I miss something?
.....
You're not missing a thing. ;D

[ceb]

Thanks again!
Does your monitor support anything else than 60Hz? Anway, you can try play with MPC-HC's autochange option. (View-> Options-> Fullscreen)
No, only 60Hz. So the fullscreen options have no effect?
I also checked an .mkv video, it has 23.976 fps.
For me, I have an old CRT monitor set at 72Hz which I sometimes use since my laptop's inbuilt screen doesn't seem to support anything else but 60Hz (which isn't horrible - jitter is only noticable to me when the picture is sliding).
If jitter means the same thing as stuttering, I think that is exactly my issue.

As suggested by you I tried the different resizers:
nearest neighbor - bad, very noticable
bilinear and PS 2.0 - both were the same to me, they were a little bit less sharp than the bicubic resizers
bicubic 0.6, 0.75. 2.0 - they seem exactly the same, I think I'll use one of these

[namaiki]

No, only 60Hz. So the fullscreen options have no effect?

You could try create a custom resolution/mode, but someone else will have to guide you through that.

[mr.duck]

MPC-HC software MPEG2 decoder has inferior image quality compared to others like Microsoft DTV decoder. I now know why. The decoder needs an option to force NV12 output colorspace. This is because NV12 is compulsory for vector adaptive de interlacing.


Slightly offtopic: I tried forcing NV12 using FFDShow. It says it is outputting "NV21, VU". Quality is excellent but does anyone know if NV21 is better/worse/same than NV12?

[adam777]

mpc-hc software mpeg2 decoder has inferior image quality compared to others like microsoft dtv decoder. I now know why. the decoder needs an option to force nv12 output colorspace. this is because nv12 is compulsory for vector adaptive de interlacing.


Slightly offtopic: I tried forcing nv12 using ffdshow. It says it is outputting "nv21, vu". Quality is excellent but does anyone know if nv21 is better/worse/same than nv12?

nv21, vu is nv12.

* EDIT *
Guess not? :)

[mark0077]

Thanks JanWillem32 regarding your feedback on by video jitter effect with certain files. Here is a screenshot of playback from one of these files with evr-cp. Even frame time correction doesn't seem to get me my perfectly flat green line back. As I say, playing many other content on my pc like m2ts, blu-rays, etc will show perfectly flat graph in evr-cp so I'm not sure how I can workaround this issue with the files I'm having issues with.

http://img832.imageshack.us/img832/6956/waveso.th.jpg (http://img832.imageshack.us/i/waveso.jpg/)

Any suggestions anyone, how to get rid of the green jitter in my video presentation graph above.

[Ger]

MPC-HC software MPEG2 decoder has inferior image quality compared to others like Microsoft DTV decoder. I now know why. The decoder needs an option to force NV12 output colorspace. This is because NV12 is compulsory for vector adaptive de interlacing.

Try JanWillem32's test builds. The internal MPEG-2 decoder uses NV12 in those for me (EVR Custom). Make sure "Set interlaced flags..." is checked in the decoder properties. There may still be differences between how the respective auto algos flag frames in different decoders though, so I'd try a few decoders and pick the one you prefer for your content.

I'm still using ffdshow for MPEG-2 because the internal decoder and Microsoft doesn't support 4:2:2 sources, but most people probably don't have any of those anyway.


Slightly offtopic: I tried forcing NV12 using FFDShow. It says it is outputting "NV21, VU". Quality is excellent but does anyone know if NV21 is better/worse/same than NV12?

Are you using an old ffdshow version? The tray icon says NV12 here if that's what you're referring to. Also, you shouldn't need to force NV12 anymore since build 3765. Resetting the output tab to default settings should be enough to get hardware deinterlacing. EVR renderers will reject YV12 for ATI cards and NV12 will be used. Nvidia cards with fairly recent drivers will use YV12, since they are much less picky and all deinterlacing methods work with many colorspaces with Nvidia hardware.

At least for Win7. I don't think anyone ever tested and reported WinXP (or Intel) behavior during the recent ffdshow changes, but I assume it will work pretty much the same.

[mr.duck]

I thought I was using the latest FFDShow (beta 7 r3154). That's what it says is the current version on the ffdhow-tryouts page.

I just got a new version (r3771). It does indeed output NV12 now :). I wish FFDShow had DXVA though. Without DXVA, my Radeon 5750 clocks up to full 3D clocks! I have to set clock speeds manually if I don't want that.


JanWillem32's test build just crashes for me :(

[pirlouy]

I wish FFDShow had DXVA though
It does.

[nevcairiel]

I wish FFDShow had DXVA though. Without DXVA, my Radeon 5750 clocks up to full 3D clocks! I have to set clock speeds manually if I don't want that.

That doesnt make much sense. With DXVA, it would use the GPU even more, and less CPU, so the GPU is even more likely to clock up.

[ceb]

You could try create a custom resolution/mode, but someone else will have to guide you through that.
OK, but if I understood correctly we have the same problem:
For me, I have an old CRT monitor set at 72Hz which I sometimes use since my laptop's inbuilt screen doesn't seem to support anything else but 60Hz (which isn't horrible - jitter is only noticable to me when the picture is sliding).
So it means there isn't any solution?
Even though I made a custom mode, it shouldn't work since my monitor works only at 60Hz.
I'm very confused. :confused:

[hoborg]

Cannot download the sample anymore to verify, its been removed.

Here: http://rapidshare.com/files/452386185/Sample_PA2.zip

[Ger]

I noticed with hoborg's mkv sample that "Title" in the information bar (seen above the status bar and below the controls in Aleksoid's screenshot a few posts up) is visible with the internal Matroska splitter when View->Information is checked, but not with LAV Splitter.

[tetsuo55]

Please, to all developers who do own builds, can you create a new thread with your builds, an explanation in the first post on what it's different, and the build number of MPC-HC when it is integrated in the core.
I remember of Beliyaal thread, that was a good solution.

Right now, posting your builds in this thread is not a good solution, you miss a lot of potential testers and this thread is unreadable. :/i've asked JanWillem to turn the video renderer into a standalone .ax, that way people can simply replace the .ax to test new versions, and the main mpc-hc.exe does not have to be replaced.

[nevcairiel]

I noticed with hoborg's mkv sample that "Title" in the information bar (seen above the status bar and below the controls in Aleksoid's screenshot a few posts up) is visible with the internal Matroska splitter when View->Information is checked, but not with LAV Splitter.

I don't care to expose such informations yet. I can add it at some point, if someone thinks its important.

[Ger]

I suppose it would be nice to get it working eventually, but no, I don't think it's top of anyones priority list. ;)

[Hera]

Official build / latest official stable, (I can test older to see if they work maybe?)
- Uninstalling and reinstalling Matreshka stuff doesn't fix Haali either. (Are Haali settings somewhere in the registry? - to reset?) {XP Rig}

Jan's Latest build which breaks bilinear (PS 2.0) shader,
- Haali broken (no fallback renderer...) - just one image in the top right (quarter), copy of that image in the top left (quarter of screen), and the bottom half of the screen is green. {W7x64 rig}

Plz Fix!
I need to get my XP rig functional as ASAP - it is supposed to be my living room media center for SD and 720p playback.

[mr.duck]

It does.
MPEG2? No one does DXVA MPEG2 apart from commercial apps. The MPC HC one doesn't work with HD5000 series. Only HD6000 and up.


That doesnt make much sense. With DXVA, it would use the GPU even more, and less CPU, so the GPU is even more likely to clock up.
It's a dumb choice. The card goes to predefined clocks of 400/900 for GPU/Memory when DXVA is in use regardless of the workload. If you edit the card's BIOS you can change it to any value. Without DXVA it clocks up for performance reasons I guess.

[G_M_C]

Here: http://rapidshare.com/files/452386185/Sample_PA2.zip

Strange, i've got the same fluctuations in framerate you report. With both internal DTS decoder as ffdshow decoder on stereo.

My guess is that there is something wrong with the file.

If i still had installed all tools, i'd try EAC3to to rebuild the DTS, and use mkvtoolnix to extract the raw video/subtitles. Then i'd rebuild the whole MKV without using header compression to be sure.

[hoborg]

Strange, i've got the same fluctuations in framerate you report. With both internal DTS decoder as ffdshow decoder on stereo.

My guess is that there is something wrong with the file.

If i still had installed all tools, i'd try EAC3to to rebuild the DTS, and use mkvtoolnix to extract the raw video/subtitles. Then i'd rebuild the whole MKV without using header compression to be sure.

Thanks for confirm.
The strange thing is, there is no problem if system default EVR renderer is in use.

[pirlouy]

i've asked JanWillem to turn the video renderer into a standalone .ax, that way people can simply replace the .ax to test new versions, and the main mpc-hc.exe does not have to be replaced.
Ok.
But his changes still need another thread.
I just discovered another build (BE mod) by bobdynlan, Leo1000. It also should be in a separated thread. The same for xhmikosr's builds.

There are builds everywhere but no organisation. Difficult for users and developers... :confused:

[vBm]

Ok.
But his changes still need another thread.
I just discovered another build (BE mod) by bobdynlan, Leo1000. It also should be in a separated thread. The same for xhmikosr's builds.

There are builds everywhere but no organisation. Difficult for users and developers... :confused:
XhmikosR's builds are official ones so there's no need for a separated thread for those. He's the one that does releases on SF page.

[nevcairiel]

MPEG2? No one does DXVA MPEG2 apart from commercial apps. The MPC HC one doesn't work with HD5000 series. Only HD6000 and up.


Thats because HD5000 does not support MPEG2 VLD Decoding, but MPC-HC supports it just fine. NVIDIA has been supporting it for years, too.

Don't blame the software if you have faulty hardware.

[hayan]

Can you re-check your Video Render or Internal Splitters, to fix the Full speed playing bug???

http://img59.imageshack.us/img59/6418/fspr.png (http://img59.imageshack.us/i/fspr.png/)

you can test this bug in realmedia (RealMediaSplitter.ax 2010-XX+ compile ver) or mpg file.
ie.repetitive drag and drop the media file to mpc-hc

[namaiki]

Are you running the latest graphics drivers for your GPU? What version and what card and OS?

[hayan]

This is not the mpg file problem
I download new mpg file(another), and re-reproduce it.

http://img200.imageshack.us/img200/656/newmpg.jpg (http://img200.imageshack.us/i/newmpg.jpg/)
Can you re-check your Video Render or Internal Splitters...?

EVRCP
MPC-HC x86 ~1.5.2.2962 (xvidvideo or XhmikosR ver)
Geforce 8600GT ~260.99, GT430 ~266.58
Win7 x64 sp1

[clsid]

Feature suggestion:

Currently it is possible to rotate the video an arbitrary number of degrees with Alt+4/6/2/8/1/3 (on numeric keyboard).
I suggest adding Alt+7 for a 180 degree horizontal flip and Alt+9 for a 180 degree vertical flip.
I would also be useful to add those commands to the Pan&Scan menu. Now most people don't know that the rotate feature exists.

[Ger]

@hayan
Pretty sure this is an old issue with the EVR Custom scan line/refresh rate detection. There is an open ticket #805 (https://sourceforge.net/apps/trac/mpc-hc/ticket/805) on the issue. I opened that 6 months ago, but the issue has been around much longer, since Beliyaal's changes. If you disable Vsync (press the v key) in EVR Custom you will probably not see it anymore. Also switching renderers to EVR Sync will help.

If you have any relevant info not already in the ticket, feel free to add it. I don't think splitters have anything to do with it though. I've seen the issue with all kinds of splitters/containers.

@devs
I'd appreciate it if you could take a look at that ticket. Maybe one of you will see right away what goes wrong with the info I added today about the 32-bit minimum signed long scanlines number near the bottom.

[tetsuo55]

@devs
I'd appreciate it if you could take a look at that ticket. Maybe one of you will see right away what goes wrong with the info I added today about the 32-bit minimum signed long scanlines number near the bottom.there are no devs, but maybe janwillems work will help here.

[Ger]

Thanks, but I already know the situation. I use that term (http://en.wiktionary.org/wiki/developer) about anyone who knows how to code in C++ (or other languages for that matter). I've been following this thread and the project since it started.

My point was, I know several bright/skilled devs follow this thread, so I was asking if they maybe could take a look in case it's a "simple" cast issue. I don't have the knowledge to tell. JanWillem is certainly one of those devs I was addressing, especially since he's working on EVR Custom.

[v0lt]

@Ger
What should I do to see a bug?

[Ger]

Sorry, I don't understand what you're asking? If you're asking how to reproduce the issue I can't help. It only seems to happen occasionally on a few systems. I can't even reliably reproduce it myself. Maybe hayan or one of the other people who reported this in different threads here over the years can help.

[hoborg]

Strange, i've got the same fluctuations in framerate you report. With both internal DTS decoder as ffdshow decoder on stereo.

My guess is that there is something wrong with the file.

If i still had installed all tools, i'd try EAC3to to rebuild the DTS, and use mkvtoolnix to extract the raw video/subtitles. Then i'd rebuild the whole MKV without using header compression to be sure.

I found something:
Sturreting seems to be fixed if i use FFDshow audio decoder with disabled jitter correction.

[Hera]

Fixed issue by resetting CoreAVC and manually purging registry from Haali / Matroska.

Two feature suggestions come to mind now,
- Warning Dialog: Current configuration failed, try resetting all settings.
- Warning Dialog: Subtitles cannot be displayed. Please update DirectX.

Both of these errors are silent right now for some reason.

[KornX]

make the buffer adjustable!
sometimes i have ongoing IO on the hdd
but many GBs of free RAM...
so i wanna buffer the file (or parts of it)
(like mplayer -cache N)

KornX

[namaiki]

Fixed issue by resetting CoreAVC and manually purging registry from Haali / Matroska.

Two feature suggestions come to mind now,
- Warning Dialog: Current configuration failed, try resetting all settings.

Only one thing I can think of: Had you changed which colorspaces CoreAVC is allowed to output in CoreAVC configuration?
(Haali's renderer requires YUY2 or RGB32 output, it will not connect if YV12 or NV12 is the only thing selected)


- Warning Dialog: Subtitles cannot be displayed. Please update DirectX.
Both of these errors are silent right now for some reason.
If DirectX is too old, there is an error message.

[Hera]

Only one thing I can think of: Had you changed which colorspaces CoreAVC is allowed to output in CoreAVC configuration?
(Haali's renderer requires YUY2 or RGB32 output, it will not connect if YV12 or NV12 is the only thing selected)


If DirectX is too old, there is an error message.

That might have been it. CoreAVC was setup exactly like it was on my ION rig.

There were no error messages.
- There were no error messages indicating why VMR/EVR options were grayed out.
- There were no error messages indicating that Haali was refusing to work.

If I didn't notice missing subtitles, I would simply be unaware of these issues.

[Momber]

For the subtitles problem: "allow animation on buffering" might help (even for non-animated input), use 3 or 4 subtitle and EVR buffers, and select one installed font that is in a small .ttf file for the default subtitle and OSD font. I patched a minor filtering bug in my builds, so that should help, too.
I tried all these suggestions. They either have no effect at all, or make the problem worse.
Also, Vsync adjustment is fundamentally broken in your test build.

[Frozen-Figo]

I used to run rmvb files with MPC, but this time I don't know what I have do wrong. audio streams won't play whatever I do, I tried to add MPC - RealAudio manually and set it as prefer but no luck ... here's what I have

note: other players run rmvb with no problem

K:\xxxxxx.rmvb::Output 00 (Audio Stream)

Media Type 0:
--------------------------
Audio: RealAudio COOK 44100Hz stereo

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {4B4F4F43-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 1
lSampleSize: 14880
cbFormat: 112

WAVEFORMATEX:
wFormatTag: 0x2004
nChannels: 2
nSamplesPerSec: 44100
nAvgBytesPerSec: 0
nBlockAlign: 930
wBitsPerSample: 16
cbSize: 0 (extra bytes)

pbFormat:
0000: 04 20 02 00 44 ac 00 00 00 00 00 00 a2 03 10 00 . ..D¬......¢...
0010: 00 00|2e 72 61 fd 00 05 00 00 2e 72 61 35 00 00 ...raý.....ra5..
0020: 00 10 00 05 00 00 00 4e 00 18 00 00 03 a2 00 00 .......N.....¢..
0030: 00 00 00 07 55 67 00 00 00 00 00 10 03 a2 00 ba ....Ug.......¢.º
0040: 00 00 00 00 ac 44 00 00 ac 44 00 00 00 10 00 02 ....¬D..¬D......
0050: 67 65 6e 72 63 6f 6f 6b 01 07 00 00 00 00 00 10 genrcook........
0060: 01 00 00 03 08 00 00 25 00 00 00 00 00 06 00 05 .......%........

[hoborg]

No Real Alternative installed?

[Frozen-Figo]

No Real Alternative installed?

It's already installed

[hoborg]

It's already installed

Can you post small sample?

[Damien147]

Hello there!

GPU:ati HD4850,catalyst 11.4 preview(same result with 11.2)

WIN 7 64bit

mpc 32bit

evr. custom pres.

With every build I've tried(xhmikosrR's,xvidvideo.ru,JanWillem32's) in over a month I get no chroma upsampling(or bad?) and the osd color is grey.Can you explain to me where is the problem?

With 1.5.1.2903 none of the above happens but I can reproduce the bad chroma thing by forcing 10 bit rgb input(I don't use that option generally).

Is the YV12 chroma upsampling shader the way to go for now?

[Frozen-Figo]

Can you post small sample?

Found the solution

Copying files below to C:/windows

- cook.dll
- drv33260.dll
- drv43260.dll
- pncrt.dll
- sipr3260.dll

Thank you

====

I wonder if I can use MPC as udp streaming client like VLC, is it possible?

Also I have TS35 RC with 2.5mm jack (come with SkyStar HD2), can use my RC with MPC?

[Hera]

Any ETA for JanW's builds D3D10bit in fix for NVIDIA?

[mr.duck]

I have an MKV file that won't play in MPC with internal filter but does work in MPC with haali.

Would be a good idea to upload sample and post it here? Or make a support ticket? What is best?

[namaiki]

mr.duck, make sure to test with: http://forum.doom9.org/showthread.php?t=156191

Support ticket would be good.

[janos666]

Any ETA for JanW's builds D3D10bit in fix for NVIDIA?

I think it will never work with the current Geforce cards (any on the market right now), except the Qaudro cards with native DisplayPort outputs (so softmodded Geforce cards won't work either, as I don't know any Geforce cards with real DisplayPort output) and official 10-bit support (which only works with real 10-bit capable displays --where the EDID from the display input reports the support-- like professional displays and a few "lucky" mainstream hardwares).

The only reason that it works with many Radeon VGAs that they always output either real 10-bit, or dithered 8 bit/color from their LUT (no matter what is in the frame-buffer), so they can support 10-bit output on capable displays (just like the Quadros) or emulate 10 bit precision on 8-bit displays (as it most likely happens with most of the displays without DisplayPort input -- even though HDMI 1.3+ supports deepcolor up to 12 bit/color as well, but I think the Radeons always output dithered 8 bit on their HDMI outputs, just like they do on single-link DVI, etc... -> but this HDMI thing is only my speculation...)


But it's not a necessarily bad thing at all, as you probably end up using the built-in dithering of the Radeons. However, you can also apply dithering on software level which you can control (completely turn off, choose static or dynamic methods and control the amount of the dynamic noise...) while the spatial/temporal dithering in the hardware is fixed (it can not be turned off or adjusted in any ways).

Moreover, the software dithering works from the surface bit depth (up to 32-bit floating point with the Full floating point presentation mode), while the hardware dithering starts from the framebuffer bit depth which is limited to 10-bit integer (at least in DX9 but I wouldn't expect a DX11 renderer any time soon...)

So, I think I would prefer to eliminate this hardware (VGA) level dithering, if the display doesn't really support 10 bit and use the software level dithering instead.

However, the hardware (VGA) level dithering does a really good job if you calibrate your display through your VGA LUT. In this case, it also makes sense to use 10-bit frame buffers with 8-bit displays as well.


-> So, this is why I tried to improve the CMS implementation in MPC-HC.
In my theory, it would be the best to leave the 1D VGA LUT alone (which has 10-bit effective precision with VGA level dithering and 8-bit otherwise) and do every corrections at software level (with up to 32-bit floating point precision).


I can circumscribe three main cases:

A): 8-bit display (let's forget about the 6-bit TNs now, they will never be accurate) with 8-bit effective VGA LUT precision (most non-TN [or stupid c-PVA] displays with old [pre-HDxxx] Radeons or any Geforce cards)
-> In this case, I belive it's the best to skip any kind of hardware level (display OSD or VGA LUT) calibration and let the software to do the CMS and apply high quality dithering for the 8-bit output.

B): Real 10-bit displays (or native 8-bit displays with internal dithering and 10+ bit capable controllers, as a border-line case) with VGA cards which can really output native 10-bit/color. (As much as I know it's only supported through DisplayPort but HDMI and even though dual-link DVI should theoretically work too, it's not guaranteed...). - This is a very rare case today (only some professional and very few mainstream displays on the market).
-> In this case, I still believe that it's better to avoid the hardware level corrections and do the high quality software corrections with fine dithering for the 10-bit output.

C): Your professional display has 12+ bit programmable internal 3DLUT and >12 bit internal processing (very rare and expensive).
-> Congratulations, you should carry out the hardware calibration and enjoy your perfect display.
(But may be you still need to apply some dithering for the 10-bit output due to the limited range YCC -> full range RGB conversion. But the dithering noise is almost unnoticeable with real 10-bit displays... ; But you don't need ICC profile based color corrections...)

And of course, there are some unique "mixed" situations (like a professional display with only 1D internal LUTs). This requires unique testing and judge what it the best solution. (I think the hardware calibration should aim panel-friendly targets and let the software to carry out most of the 3D color corrections.)


But it's a "small" problem with my ideas that they go straight against the good old professional routines and standards (like ICC standard) which work good enough in practice.
-> But note that these kind of software level corrections which I am talking about were not possible (at least not in real time) until we started to use fast VGA cards to carry them out. (You can see that Full Floating point processing and big 3DLUTs are still heavy for today's hardwares...)
///And note that I said they work "good enough". But it's obviously not perfect because nobody would pay for the expensive professional displays with programmable high precision internal 3DLUTs otherwise...)

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

And a practical problem which I face right now that we mostly use LCD displays (or LCD projectors) today with relatively low contrast ratios which would require smart black-point compensation on the CMS engine but it doesn't seems to exist (or work well) in current ICC based CMS engines.
(And NeoPDP panels offer high contrast but they aren't issue-free either. They apply heavy hardware level dithering for example which makes the profiling and software level dithering harder - if not effectively impossible [in good quality])


-> At this point, I should mention that yCMS goes on a very nice way (according to my opinion) but the development seems slow. (It's still don't work with separated per-channel TRC data to offer proper white balance correction... and some "broken" digital displays would require even more, like the XYZ cLUT based profiles do in the ICC word -> but they have their own "issues" as well, so...)


----
I think I went much further than answering your question, so a little summary:
-> Don't worry about the 10-bit output, it's not the holly grail (only a very little piece of the apple).
(Or you can buy a real 10-bit display and a Quadro with DP output. -> You will still need high quality software CMS unless that high-end display offers high bit internal 3DLUTs - which will still require high quality software processing because of the YCC->RGB conversion, as it's not possible to feed the hardware with the source format directly, so you need software processing --- or hardware processing but that's a whole different story without PCs and player softwares...)

---
Otherwise, I am still looking forward to see when madVR will support 10-bit output. :)
(And I hope this statement doesn't disturb you. :D)

[janos666]

Another thing -> bugreport (?)

I can't play divx SD material with EVR-CP (using JanWillem's latest x86 test build ; even if I disable all the fancy settings) on the PC which I am currently using (not my own home PC but a very similar one - in both software and hardware).

It doesn't matter which source filter or decoder I use. (None of them are DXVA decoders.)

HD plays fine with every fancy settings too...

I can see same artifacts on the first few images and then I need to use the RESET button (on the PC chassis).

The standard EVR works fine.

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

Another possible bug report:

It seems this build has some sync problems. (May be inaccurate refresh rate or source fps detection?)
I also noticed it with my home PC but I wasn't sure about it because that's a fixed-60Hz panel.
Here I use a display with exact 24/1.001*3 Hz timing and it still trys to play with V-sync (and causes some judder). I had to disable V-sync.
(The older build worked fine. -> I don't know which one was that before I updated to the latest...)

----
Sorry that I can't say more. There is no MSVC on this PC and I can't gather more informations after a complete system break-down...)

[namaiki]

janos666, which build number of MPC-HC are you using now? Also, SD divx material is approximately what resolution in your case? Please also tell me what is listed in the menu: Play-> Filters and post a Ctrl+J graph which should cover most other settings. Post a video sample if possible.

[Silent Rain]

Hi guys!
How about the display of these OSD?

http://jpegshare.net/thumbs/9d/78/9d78a231322f17f9d7c99278c8d09f16.jpg (http://jpegshare.net/9d/78/9d78a231322f17f9d7c99278c8d09f16.png.html) >>> Result >>> http://jpegshare.net/thumbs/3b/a0/3ba077945349e7d22d855253393669fc.jpg (http://jpegshare.net/3b/a0/3ba077945349e7d22d855253393669fc.png.html) By analogy with the regulation of the volume: http://jpegshare.net/thumbs/38/d9/38d904b7f54fcb61041105a8cfb5f0f9.jpg (http://jpegshare.net/38/d9/38d904b7f54fcb61041105a8cfb5f0f9.png.html)

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

http://jpegshare.net/thumbs/70/c9/70c9a89a0fa54b0fe98e75e1221e405e.jpg (http://jpegshare.net/70/c9/70c9a89a0fa54b0fe98e75e1221e405e.png.html) Or after pressing these keys: http://jpegshare.net/thumbs/b9/d6/b9d6957fb22ac4463098c3ece904504e.jpg (http://jpegshare.net/b9/d6/b9d6957fb22ac4463098c3ece904504e.png.html) >>> Result >>> http://jpegshare.net/thumbs/07/19/071968e0ea0c90343e142dc62cf36210.jpg (http://jpegshare.net/07/19/071968e0ea0c90343e142dc62cf36210.png.html)

[hoborg]

Hi.
I have question about .bdmv files.
Rev.2980 - i have internal MPEG splitter disabled - using standalone version instead. When i open index.bdmv, MPC-HC popup cannot play - is that OK?

BTW, is there a way how to open index.bdmv automatically in graphstudio?

[nevcairiel]

The .bdmv handling relys on the internal mpeg splitter, if you disable it, there is no reason it should still be used for it. This also allows other DirectShow filters to be used for handling .bdmv, and doesn't force the mpeg splitters parsing on to it.

Any reason you want the .bdmv parsing to still work, but not with the internal mpeg splitter?
Could always separate the options, if there is some useful use-case.

[hoborg]

The .bdmv handling relys on the internal mpeg splitter, if you disable it, there is no reason it should still be used for it. This also allows other DirectShow filters to be used for handling .bdmv, and doesn't force the mpeg splitters parsing on to it.

Any reason you want the .bdmv parsing to still work, but not with the internal mpeg splitter?
Could always separate the options, if there is some useful use-case.

Well, i would like to make .bdmv working for example in MediaPortal or GB-PVR/nPVR.
GB-PVR/nPVR doesn't have any BluRay handler, it only ask DirectShow to render the file like Graphstudio do.
So if there will be a way how to asociate .bdmv to autoopen MPC MPEG splitter, it will be possible to play BluRays easy (without menus of course). But i am not sure if that is possible. Mabye something like ?.bdmv source filter can do it? No idea.

[nevcairiel]

Thats not how it works, the standalone MPC-HC MPEG Splitter does not work with .bdmv files, it only does that when integrated in MPC-HC (there is some trickery going on).

Wait for the 0.20+ series of LAV Splitter, it'll add BluRay support, which should work for most players out of the box (just open the .bdmv, and main movie starts playing, among other features).

A first version should be around next week, i hope.

[chros]

Hi guys!
How about the display of these OSD?

Can you look at this ticket, too? http://sourceforge.net/apps/trac/mpc-hc/ticket/1155

Thanks

[janos666]

Ignore the DivX problem. It seems the VGA was not stable with it's factory clocks (OC edition with refence hardware design and higher BIOS clocks ; not very unusual that this kind of factory OC fails with some cards...).
It runs fine with reference memory colocks.

This is interesting that it played HD movies with DXVA just fine and it also passed the Furmark stability test (I ran it for 20 minutes) but a simple DivX playback (with software decoders) could crash the whole system after a few frames.


The Sync problem is still there, however...

[Damien147]

Hello there!

GPU:ati HD4850,catalyst 11.4 preview(same result with 11.2)

WIN 7 64bit

mpc 32bit

evr. custom pres.

With every build I've tried(xhmikosrR's,xvidvideo.ru,JanWillem32's) in over a month I get no chroma upsampling(or bad?) and the osd color is grey.Can you explain to me where is the problem?

With 1.5.1.2903 none of the above happens but I can reproduce the bad chroma thing by forcing 10 bit rgb input(I don't use that option generally).

Is the YV12 chroma upsampling shader the way to go for now?


Thanks for the help:rolleyes:

Actually it's this http://sourceforge.net/apps/trac/mpc-hc/ticket/915 but without dxva being necessary.
Color space converter filter is my best friend for now(?)

I can't understand exactly what triggers that.Is rgb conversion necessary on a monitor?If yes what happens with dxva or with the last changes that I get NV12 mixer output when decoding with ffdshow?

Catalyst (http://howshittyarecatalystdriversthismonth.com/) is the problem?

[pwimmer]

I've made available the patches for MPC HC filters used in the Stereoscopic Player here:

http://www.3dtv.at/OpenSource

[Momber]

I had to disable V-sync.
Me too.

[Sebastiii]

I've made available the patches for MPC HC filters used in the Stereoscopic Player here:

http://www.3dtv.at/OpenSource

Thanks :)

[vBm]

Hi guys!
How about the display of these OSD?


Open request ticket HERE (https://sourceforge.net/apps/trac/mpc-hc/newticket).

[Silent Rain]

Open request ticket HERE (https://sourceforge.net/apps/trac/mpc-hc/newticket).

Done!
Ticket #1224. (https://sourceforge.net/apps/trac/mpc-hc/ticket/1224)

[pirlouy]

Sina™ claims to be "MPC-HC businessman" (was there under his pseudo). Who is this guy ? For me it's a 10 years old troll. But if he has something to do with the project, can you confirm that ? If it has nothing to do, it has to be banned... Tetsuo ?

[nevcairiel]

He has nothing to do with the project. Nothing at all.

[madshi]

I've done my first open source commit. Phew. :) Any dev willing to double check, just to make sure I didn't screw anything up? Thanks!

[nevcairiel]

I've done my first open source commit. Phew. :) Any dev willing to double check, just to make sure I didn't screw anything up? Thanks!

I looked over the changes, and it all looks pretty straight forward. Looks good. Looking forward to the madVR release to use those. ;)

[madshi]

I looked over the changes, and it all looks pretty straight forward. Looks good. Looking forward to the madVR release to use those. ;)
Thanks for checking! The madVR build you're referring to was just released... :)

[Polcius]

I haven't followed the forum in a long time...

What's "BE Mod"?

[tetsuo55]

I've done my first open source commit. Phew. :) Any dev willing to double check, just to make sure I didn't screw anything up? Thanks!Well done :)

[madshi]

Thanks! :)

[pirlouy]

What's "BE Mod"?
You can find a description on xvideo.ru, at bottom page of latest MPC-HC build.

As an example, you can change some UI stuff with this build.

[sneaker_ger]

It tried registering file types to MPC-HC through options > formats on a restricted Windows 7 user account. This does not work, it will ask for administrator rights but if you enter the admin data it will show the associations of the admin account.

Is this not possible from within MPC-HC?

[ryrynz]

If I start playback in windowed mode the OSD displays the file name for only a short moment, any chance of an option to configure the time on this?
Also if I launch the file from Windows Explorer the file name does not display as it does when playback is launched from MPC.

[clsid]

It tried registering file types to MPC-HC through options > formats on a restricted Windows 7 user account. This does not work, it will ask for administrator rights but if you enter the admin data it will show the associations of the admin account.

Is this not possible from within MPC-HC?
On Vista/7 applications are supposed to use the "Default programs" functionality of Windows for setting file associations. However, the installer of MPC currently does not create the required registry keys for that.

[sneaker_ger]

Ok, thx. (I was not using the installer btw., just the exe)

[Damien147]

Color Space Converter Filter (http://msdn.microsoft.com/en-us/library/dd387892%28v=vs.85%29.aspx)

This transform filter converts from one RGB color type to another RGB type, such as between 24-bit and 8-bit RGB color. Since this type of conversion is generally handled more efficiently within a video decompressor, the main use of the Color Space Converter is when the stream source consists of uncompressed RGB frames.

http://img41.imageshack.us/img41/1008/90989998.th.png (http://img41.imageshack.us/i/90989998.png/)

Uploaded with ImageShack.us (http://imageshack.us)

[Hera]

Ok, thx. (I was not using the installer btw., just the exe)

It might work if you completely destroy UAC in Windows 7 using regedit and removing the UAC driver from the startup list of services.

[mr.duck]

What works best for me in Windows 7 is to just untick everything in MPC options and then right click media file >> open with >> choose program >> tick always open with MPC

[sneaker_ger]

Yes, it seems I will do just that for user accounts. I don't want to mess with the UAC.

[Tom Keller]

This may be a stupid question... but i'll ask it anyway :p :

Why was the "D3D Fullscreen" option for madVR removed in the last builds :confused: ? Yes... i know: madVR has its own settings for using its own exclusive DirectX fullscreen mode. But with MPC-HCs "D3D Fullscreen" option for madVR i could have the player app on display 1, while the video was running fullscreen on display 2. Now this isn't possible anymore.
Furthermore the exclusive mode of madVR does not use the "Fullscreen monitor" settings of MPC-HC! So with madVRs exclusive mode enabled and with the player opened on display 1, jumping to fullscreen will show a fullscreen video on display 1 - even though display 2 is set up as "Fullscreen monitor" in the MPC-HC settings :( .

Damn... i miss that "D3D Fullscreen" option already :scared: !

[madshi]

Why was the "D3D Fullscreen" option for madVR removed in the last builds :confused: ? Yes... i know: madVR has its own settings for using its own exclusive DirectX fullscreen mode. But with MPC-HCs "D3D Fullscreen" option for madVR i could have the player app on display 1, while the video was running fullscreen on display 2. Now this isn't possible anymore.
Furthermore the exclusive mode of madVR does not use the "Fullscreen monitor" settings of MPC-HC! So with madVRs exclusive mode enabled and with the player opened on display 1, jumping to fullscreen will show a fullscreen video on display 1 - even though display 2 is set up as "Fullscreen monitor" in the MPC-HC settings :( .

Damn... i miss that "D3D Fullscreen" option already :scared: !
I've removed it because in my experience it made more problems than it solved. It was originally added by Casimir on my personal request, because I thought it would be needed for a future madVR version. But then I implemented the automatic exclusive <-> windowed mode switch and as a result the MPC-HC fullscreen option didn't make sense, anymore. There were actually a couple of bug reports in the madVR thread which we traced back to be caused by accidently setting this MPC-HC fullscreen option. So, I decided to disable this option in MPC-HC when using madVR.

To be honest, I was not aware of that this option would have any use when using madVR. Of course it would be easy enough to reintroduce it. But I'm not sure if it's a good idea cause (as I said) it also produced a number of problems.

Hmmmm... Looking at the MPC-HC "Fullscreen" tab in the settings dialog, I don't really see why these options should be limited to work only when the "D3D Fullscreen" option is activated. Maybe it would make sense to make these options work also without "D3D Fullscreen"?

[pdanpdan]

@madshi
I also used this feature (D3D Fullscreen) for the same purpose - interface on first monitor, and movie on second one. This way the main interface was not kept on top of other windows.
Can we have it back, please?

@all
And another thing I noticed when this option disappeared: the Start in fullscreen option doesn't seem to work. It is checked, but when I dblclick on a movie in playlist it starts in window mode.

MPC-HC 32/64, madvr renderer

[Midzuki]

Uploaded with imageshack

@ A L L :

please stop using imageshack —

http://forum.videohelp.com/threads/332845-Please-register-videohelp-com-with-imageshack-us

[pankov]

OK
but can you give an alternative?
I found a few with google but I'm not sure which are better.
Anyone with some experience?

[Mercury_22]

Internal mkv splitter doesn't take in consideration correctly the "External Filters" list :
I'm using Nero's decoder for all DTS and it's set as "Prefer" in the "External Filters" list (also it's the only audio decoder in the list) but the internal mkv splitter it's "preferring" the internal DTS decoder, I have to disable the internal DTS decoder to be able to use the external DTS decoder !
But the internal MPEG PS/TS/PVA splitter it's always using the external DTS decoder, as it should, even when the internal DTS decoder it's enable
Can someone fix the merit usage for the internal mkv splitter ?

[nevcairiel]

The splitters do not decide which codecs gets used. It must be something different, like different media types.

[Mercury_22]

The splitters do not decide which codecs gets used. It must be something different, like different media types.

Then how come that the mpeg splitter it's working correctly for the same media type ? :confused:

[vBm]

OK
but can you give an alternative?
I found a few with google but I'm not sure which are better.
Anyone with some experience?

http://imgur.com/ seems to be the best from my experience.

[pawlol83]

Hello, I have a problem with the MicroDVD format, which occurs during video playback in AVI, MKV. Reveals a lack of synchronization. I use MPC Home Cinema Player in the x86 version 1.5.2.2990 and madVR v0.47. There is one already when you correctly the first few lines of inscriptions which are displayed for 2-5 seconds too early. This phenomenon occurs throughout the film. After switching to EVR Custom mode the problem disappears.
Please, download a file from the sample of the video with subtitles. I attach an additional file with the settings Media Player Home Cinema ver. 1.5.2.2990. Please play the file in evr custom mode (the problem does not occur with subtitles) and you madVR (subtitles appear for 2-5 seconds too early).

sample video: http://cid-33b9075ef19e9efa.office.live.com/self.aspx/Public/sample.zip


Thanks for the sample. I can reproduce that madVR shows the subtitles too early. It's about 2 seconds on my PC, though and not 5 seconds. Furthermore with a different clip with different subtitles the problem does not occur. I don't know where the problem is coming from but the Haali Video Renderer shows exactly the same behaviour as madVR with both clips. So it seems to be a bug in MPC-HC and not in madVR. For your information: The Haali Video Renderer and madVR are using the same subtitle mechanism. EVR Custom uses a different mechanism. The solution used for EVR Custom can't be used for external renderers. I wish I could do more for you, but right now all I can say is that it seems to be a bug in MPC-HC and not in madVR.


Please refer to the problem

[Tom Keller]

@madshi
If the "D3D Fullscreen" option of MPC-HC causes some problems with madVR, how about an option for madVR itself, on which display it should use its own exclusive fullscreen mode plus some setting to always force this mode? This would be the solution for anyone, who wants to have the player interface on one display and the fullscreen video on an other...

[tdoll]

@madshi
I also used this feature (D3D Fullscreen) for the same purpose - interface on first monitor, and movie on second one. This way the main interface was not kept on top of other windows.
Can we have it back, please?

@all
And another thing I noticed when this option disappeared: the Start in fullscreen option doesn't seem to work. It is checked, but when I dblclick on a movie in playlist it starts in window mode.

MPC-HC 32/64, madvr renderer

I also used the 3D3 Fullscreen feature in the same way and it worked like a charm. Could you please reinstall it. Please!http://forum.doom9.org/images/smilies/helpful-t.gif

[pirlouy]

http://imgur.com/ seems to be the best from my experience.
Thanks for the info. Bookmarked.

[LigH]

@ A L L :

please stop using imageshack —

http://forum.videohelp.com/threads/332845-Please-register-videohelp-com-with-imageshack-us

OK
but can you give an alternative?
I found a few with google but I'm not sure which are better.
Anyone with some experience?

The Frubar network has some interesting projects which might be useful here - like http://frupic.frubar.net/ (basic image hosting service) or http://sau.frubar.net/ (a tool and webservice for automatic uploading of screenshots)

[iSeries]

Hi,

I've just installed MPC on my daughters new PC, and to keep things as simple as possible I'll be using all internal splitters/decoders etc. However, the audio switcher isn't working and isn't downmixing 5.1 FLAC audio to 2 channels. I've set up the 'enable custom channel mapping' correctly. Anyone got any ideas?

[pirlouy]

Yes: don't use internal decoders. Lots of problems. It's not that difficult to disable all decoders, and install ffdshow. During installation, choose 2.0 (stereo) output for mixer.

[iSeries]

Like I said, to keep things simple, I'm using all internal decoders. MPC should be working as a stand-alone app. Anyone else got any ideas?

[tetsuo55]

Yes: don't use internal decoders. Lots of problems. It's not that difficult to disable all decoders, and install ffdshow. During installation, choose 2.0 (stereo) output for mixer.Do you have any evidence for these claims? afaik we use the exact same codecs as ffdshow.

[clsid]

Do you have any evidence for these claims? afaik we use the exact same codecs as ffdshow.
There are plenty of differences: swscale, ffmpeg-mt, mixer in audio decoder, etcetera. ffdshow also doesn't use LibFLAC like MPC does.

[Moondust]

I am experiencing the strangest thing. Already took me hours. I hope someone can help me out.

I recently switched to Windows 7 64-bit and installed the 32-bit versions of MPC-HC, AC3Filter, MadFlac and Haali. MPC-HC is set to use EVR. Haali handles just the splitting. Now, I have been using this combination for quite some time on my HTPC (Windows Vista 32-bit), but now on my refresh Windows 7 64-bit installation MPC Vide Decoder refuses to work with mkv-files. It runs fine with m2ts-files though. When I disable Haali and let the internal codec of MPC-HC do the splitting, MPC Video Decoder works just fine. When turning Haali on again MPC-HC says that it cannot render some of the pins in the graph. What's is keeping me from using the Haali splitter and the MPC Video Decoder?


Fixed the problem minutes after my post. CoreAVC seemed to be the problem. When uninstalled, Haali and MPC Video Decoder worked just fine.

Now I only need to find out why AC3Filter isn't working when MadFlac is used. Has been working on my HTPC (Vista 32-bit) for ages. When playing AC3 or DTS AC3Filter wokrks just fine. When playing FLAC AC3Filter just doesn't show up.

[janos666]

For those who miss the MPC-HC D3DFS option with madVR: CTRL+D still works.

[burfadel]

To get AC3filter working if it isn't already, click on View --> Options --> External filters (left hand column 2/3 way down the list). Then click add filter on the right hand side, select ac3filter, and make sure it comes up on the list with the box ticked. Then, on the right hand side, click on 'prefer' then ok.

AC3filter will now load at all times. AC3filter works great as an audio enhancement tool when you tweak the settings a little :)

[pdanpdan]

For those who miss the MPC-HC D3DFS option with madVR: CTRL+D still works.

??? as in open DVD? what does CTRL+D does?

[Tom Keller]

Maybe janos666 meant CTRL+F(?).. but this wont work either. It toggles the D3DFS option on/off - but as it's no longer working for madVR, it wont do anything.

[JanWillem32]

It's been a while since I released some tester builds, so I've continued developing further.
I'm still trying to find out what breaks Alternative VSync in my builds, but the timing mechanisms are difficult to manage. Every time I look at the code for timing and sync, I find new basic programming errors. I'm not really familiar with any timing mechanisms, so anyone with some C++ experience is very welcome to take a look at that code and help fix it (or anything else, for that matter).
I made the 3DLUT interpolation mechanisms switchable. It's very fast to switch them, because it doesn't require regeneration of the 3DLUT itself.
I fixed the bilinear scaling shader.
I fixed some mixer handling for EVR and EVR CP with interlaced content. I still have to correct it for the stats screen of EVR CP. VMR-9 (renderless) is unaffected.
I optimized some code for the dithering and color management section, but I'm not so sure about the performance of the new Random Ordered dithering. It's a lot heavier than the random dithering method in my case. Can anyone verify any frame drops, or jitter caused by the new method?
I still need to catch up on this thread, to see if there's anything else I need to address. (I've been away for more than a week.)

New pixel shaders are coming up soon, with a few optimized ones for floating point surfaces input.
Future tester builds from me can go in a separate thread, once I've written good OP for that thread and the shaders thread.

[LigH]

@ Midzuki & pankov:

Even more alternative "photo sharing" / "image hosting" sites (http://www.dmoz.org/Computers/Internet/On_the_Web/Web_Applications/Photo_Sharing/Image_Hosting/)

[Moondust]

To get AC3filter working if it isn't already, click on View --> Options --> External filters (left hand column 2/3 way down the list). Then click add filter on the right hand side, select ac3filter, and make sure it comes up on the list with the box ticked. Then, on the right hand side, click on 'prefer' then ok.

AC3filter will now load at all times. AC3filter works great as an audio enhancement tool when you tweak the settings a little :)

Sorry for my incomplete post, but I've always done what you propose. Also AC3Filter is configured to be used with all the supported formats including LPCM. When there is another track besides a FLAC track in an mkv and I switch to the FLAC track AC3Filter is not loaded. Very strange, never seen this before. Using ReClock as well. Haali splitter -> MadFlac -> AC3Filter -> ReClock.

[tdoll]

For those who miss the MPC-HC D3DFS option with madVR: CTRL+D still works.

Perfect. Thans a lot for the hint!

[madshi]

FWIW, I'll put the "D3D Fullscreen" for madVR back in, since enough people have requested it. Might take a couple of days, though.

[Tom Keller]

@tdoll
Wait... what does CTRL+D for you??? For me it only opens the "DVD path" dialog - which (afaik) is the default setting for this key combination:

http://justpic.info/images2/ca11/mpchc.png

So: i'm a bit confused now :confused: !

EDIT:
FWIW, I'll put the "D3D Fullscreen" for madVR back in, since enough people have requested it. Might take a couple of days, though.
Thanks madshi :) !

[tdoll]

@tdoll
Wait... what does CTRL+D for you??? For me it only opens the "DVD path" dialog - which (afaik) is the default setting for this key combination:

http://justpic.info/images2/ca11/mpchc.png

So: i'm a bit confused now :confused: !

EDIT:

Thanks madshi :) !

Yes, you are right CTRL+D opens the DVD path. You have to use CTRL+F. It is a little bit further down in the keys list.

[Tom Keller]

Ok... i assumed that. But like i said: CTRL+F does nothing for me. It only shows the OSD message "D3D Fullscreen on/off" - but didn't do anything more. I guess i'll better wait for madshi to reintroduce the "D3D Fullscreen" option...

[pirlouy]

Like I said, to keep things simple, I'm using all internal decoders. MPC should be working as a stand-alone app. Anyone else got any ideas?
If you don't want my solution (one download, 3 click to install), then use MPC-HC tracker, fill bugs or fix them yourself. :)

Do you have any evidence for these claims? afaik we use the exact same codecs as ffdshow.
Evidence are not from me since I am not a programmer. But I remember several developers saying MPC-HC decoders are buggy: clsid as you can see, madshi, nevcairiel (at least for splitters); I also remember Albain (in a French interview) saying he plans to integrate ffdshow into MPC-HC.

Personally, as a user, I would prefer MPC-HC project to delete all MPC filters code and recommend ffdshow instead. It would be easier to maintain.
One Open Source Player, One decoder Open Source, and with nevcairiel recent work, it would allow One Open Source Splitter.

For example, I did appreciate ffdshow recent changes, with code removal (buggy, old or non maintain encoder/decoder). Maybe it could give vou some ideas...

[iSeries]

pirlouy - thanks, but I'm already familiar with ffdshow, having been a user for a good few years now.

So you 'remember' several MPC developers saying some decoders are buggy. It seemed to me that in your previous post you knew what you were talking about, i.e had experience with and proof of these 'buggy' decoders and their 'problems'. Please can you point me in the direction of some of the threads where the developers have said these things?

[tetsuo55]

There are plenty of differences: swscale, ffmpeg-mt, mixer in audio decoder, etcetera. ffdshow also doesn't use LibFLAC like MPC does.Okay those difference could influence (percieved) decoding on some levels.
Evidence are not from me since I am not a programmer. But I remember several developers saying MPC-HC decoders are buggy: clsid as you can see, madshi, nevcairiel (at least for splitters); I also remember Albain (in a French interview) saying he plans to integrate ffdshow into MPC-HC.I don't think the intergration is going to happen, instead i see a standalone decoder and standalone postprocessor filter being included. What i meant here though is, do you have any samples that the decoders fail to decode, but that do work with ffdshow.

Personally, as a user, I would prefer MPC-HC project to delete all MPC filters code and recommend ffdshow instead. It would be easier to maintain.
One Open Source Player, One decoder Open Source, and with nevcairiel recent work, it would allow One Open Source Splitter.MPC-HC is a collection of open source filters wrapped into a single directshow player.exe. Additionally capable of loading any external directshow filters. Having to install standalone codecs is a problem that we don't want to get involved in. Intergration of nevcairiel's work is planned.

For example, I did appreciate ffdshow recent changes, with code removal (buggy, old or non maintain encoder/decoder). Maybe it could give vou some ideas...These changes are late to ffdshow, mpc-hc had this kind of cleanup months ago, and is still ongoing.


Keep in mind all choices of directshow filters have different bugs and features, so its always a game of finding the one, or the combination of some that works for your files.

[pirlouy]

What i meant here though is, do you have any samples that the decoders fail to decode, but that do work with ffdshow.
No, I don't. It's been a long time since I use MPC filters. And when I've run into a problem, searching google, I read ffdshow was way better; since then, I did not try anything else. But again, I remember people in madVR thread having problems with MPC filters. And often, it's recommended to test with ffdshow instead, in order to be sure it's not a decoder fault.

Having to install standalone codecs is a problem that we don't want to get involved in. Intergration of nevcairiel's work is planned.
It's your project, and you do whatever you want. But, in my case, I consider filters independent of player. A good directshow filter can be used in any decent video player. And I think you can configure ffdshow + MPC into a portable application if that's something important for some users (to be confirmed).

Keep in mind all choices of directshow filters have different bugs and features, so its always a game of finding the one, or the combination of some that works for your files.
With ffdshow, you can choose your library if you're an advanced user.

In fact, I thinks it's a pity to divide efforts. And like ffdshow is really well done, I think it's too bad to lose time on MPC-HC decoder, when we know that there are no really active developers. But I don't want to flame, I'm just a noob user; don't feel obliged to answer.

[nevcairiel]

Both ffdshow and MPC-HC do not really have active developers, both projects only get rather small changes on life support. Also, both projects really have terrible code which makes it hard for new developers to join. They are kinda similar in that regard, heh.

[darkw1zard]

Hi, I got the following message
"Warning: Creating EVR Custom Renderer .... The installed DirectX End-User Runtime is outdated. Please download and install the June 2010 release or newer in order for MPC-HC to function properly."

Then I updated by downloading the DirectX end-user Runtime Web Installer and run it.
However, the program (MPC-HC) will keep crashing (stopped working) everytime I open after the update.

I don't understand why, if anybody can help I'd really appreciate it.
Thanks!

[janos666]

May be it could be useful to have a button on the Options/Internal filters panel which disables all internal filters with one click.

[hoborg]

May be it could be useful to have a button on the Options/Internal filters panel which disables all internal filters with one click.

Did you tryed right mouse button? :)

[hayan]

mpc-hc.exe x86 1.5.2.2990 (XhmikosR)
Total running time: about 2 hrs
EVRCP, win7 x64 sp1, Fermi driver 266.58
At one time I get a error, mpc-hc srceen freeze/crash
Event ID: 4101 Display driver nvlddmkm stopped responding and has successfully recovered.


After I rollback to 1.5.2.2976 (XvidVideo.RU)

[v0lt]

What do you think about replacing the default Overlay Mixer to VMR-7 (windowed) for Windiws XP?

[nevcairiel]

Overlay has its uses, if only for debugging or as a fallback, it should not be removed.

[v0lt]

I'm not going to remove anything (my english is bad). I propose to make renderer VMR-7 (windowed) by default for Windows XP.

[LigH]

So far I was used to the myth that "Hardware Overlay" is the fastest renderer. Is there any reason not to use this one as default? Where has VMR-7 an advantage?

In fact, I never even tried to use VMR-7, not since the MPC family supported VMR-9 (and who does not yet use DirectX 9+?).

[v0lt]

VMR-7 (windowed) is very stable.
Overlay Mixer is buggy, if the video has a width or height not divisible by 16. It is observed on the integrated video decoder in software mode.
VMR-9 (renderless) sometimes has problems. Wrong to do by default.

[pirlouy]

What do you think about replacing the default Overlay Mixer to VMR-7 (windowed) for Windiws XP?
Overlay Mixer is my second choice. Ok, now I don't have any reason to use something else than madVR, but before madVR exclusive mode, I used Overlay Mixer in order not to have tearing.

Overlay Mixer is buggy, if the video has a width or height not divisible by 16. It is observed on the integrated video decoder in software mode.
Not sure to understand. From what you said, it can be a decoder problem, no ?
With ffdshow, problem is still here ?
By the way, no need to remove a renderer, and WMR-7 is already default one.

[clsid]

It is a bug in the internal decoder. ffdshow works fine.

[DMD]

Good evening

I ask, if possible, insert graphics during playback Audio Files

Thanks

[neoufo51]

I have a question:

Is this playback settings guide as helpful as it can be?

http://files.nyaa.eu/HOW_DID_I_PLAYED_BACK.txt

[KornX]

make the buffer adjustable!
sometimes i have ongoing IO on the hdd
but many GBs of free RAM...
so i wanna buffer the file (or parts of it)
(like mplayer -cache N)

KornX

so no one else has the same scenario sometimes???
:(

KornX

[sneaker_ger]

so no one else has the same scenario sometimes???
:(

KornX

I don't know if that could be a solution and how large you can set it, but Haali's Splitter has an option to set the input buffer size.

[pirlouy]

I ask, if possible, insert graphics during playback Audio Files
You mean Winamp visualisation style ?

I guess you'll prefer a dedicated audio player. I mean I don't think there will ever be a developer to transform MPC into an Audio Player reference.

Is this playback settings guide as helpful as it can be?

http://files.nyaa.eu/HOW_DID_I_PLAYED_BACK.txt
Is it a guide for beginners ? Because honestly, no it's not the best settings...
Haali Media Splitter seems to be less good than LAV Filters (for me).
madVR is the reference video renderer; EVR Sync is not developed anymore I think (?).
I would also recommend to disable all internal filters until Nevcairiel's one are merged in MPC-HC Core.
There's also new decoder from Nevcairiel (GPU accelerated for nvidia cards);
Some people would also mention reclock, powerstrip, autofrequency, coreAVC,etc.

http://forum.doom9.org/showthread.php?t=157897 worths reading even if it's not perfect.

[KornX]

@sneaker_ger

thx, i know...
but i was hoping for a "portable version"...
and I still hope sb wants to integrate it
cause there seems to be some buffering...

[JanWillem32]

@darkw1zard: Dxdiag.exe usually gives a good impression on the status of DirectX components. It's usually a combination of outdated audio and video drivers that give this type of problem. Dxdiag can indicate errors, the build date of components and most importantly, the video DDI version of the installed hardware and software. DDI level 9.0 is the bare minimum for the current renderers. Both x86 and x64 executables will have to be checked on x64 systems.

@KornX: EVR renderers can use larger buffers, but the EVR mixer, the OSD renderer and the subtitle renderer generally store images in video memory. Increasing the buffers to more than 4 will generally lower performance a lot.
System memory is rather unsuitable for video, so it's avoided as much as possible. Ffdshow can buffer a few frames if you enable it in the options, but I doubt it has any positive impact at all.

@neoufo51: I hope you can use this.
Notes about the discriptions in the playback advice list:
-Using a fresh, recent installation of MPC-HC, decoders and splitters is of course a good thing. The popular decoders and splitters have been discussed a lot in this thread. I can only advise people to consider them, and of course update the software once in a while.
-Rebooting for software installation/removal is for changing core system files used during boot time (such as security updates from Windows Update), or the system-mode hardware abstraction layer (low-level hardware drivers). Regular software doesn't require rebooting, it doesn't have any advantages since Windows 2000.
-EVR Sync isn't the best choice in all cases. It's actually quite a bit behind the renderer used by EVR CP and VMR-9 (renderless) (these two are only different in terms of mixers). It's worth it to try the different renderers with different rendering settings, to see what works well for you. I must note we coud use some developers to get EVR Sync updated, as I don't have enough time to work on it and there are no active developers to even check for math or typing errors.
-I might be able to get other resizers integrated soon. I've already written some better multi-pass resizers. I just need to find a way to make rotation work properly with those.
-The advice for the subtitle items is completely correct. It might be worth noting that some animated subtitles are too much for the heavily outdated subtitle renderer. Even on my main PC I have to disable subtitle animation with some sample files.
-I disagree on the DXVA part. DXVA is perfectly fine for AVC and VC-1 to reduce the processing load on the CPU, as long as you feed it 8-bit 4:2:0 chroma down-sampled video. (Higher quality video data seems to be very difficult to decode properly by software decoders, too.)

-The screenshot functions in the main trunk build are broken in combination with 10-bit, half floating point and full floating point processing. I added a dirty fix for it in my builds some time ago, but BMP saving is still broken, and there's no option to save images processed by the renderer.
-I personally prefer to convert a saved PNG screenshot to a final image with external tools (I use GIMP and OptiPNG), so I can select compression options myself. I really don't advise to use JPEG compression with the common 4:2:0 chroma down-sampling for snapshots. As the images are down-scaled a lot, chroma (color difference to the reference grayscale) detail will almost always become an important factor in the perceived image quality. For regular saved images it matters a lot less, as the source is usually 4:2:0 chroma down-sampled too.
The only way to save a processed image is to press "print Screen" on the keyboard during rendering, and paste the resulting image in an image editor (even Paint suffices).

-Audio is certainly a lot easier. (Unless you are into multi-channel mastering, VST chain filtering, live work, et cetera, like me.) It's nice that the text also mentions the less common (but excellent) lossless audio formats.

[KornX]

@JanWillem

i am not talking about the decoded stuff
i am talking about the file itself.... :)

[mr.duck]

KornX, what would be the point of the large buffer? What will it achieve?


MPC-HC should start dropping some of it's internal filters. Starting with the TS splitter, to be replaced with the LAVfilter one.

Would be nice if the MPC-HC audio switcher could support VSTs. Then I could install a proper compressor to normalize the volume output a bit.

[KornX]

expl:
ongoin IO > buffer empty, nothing to decode > framelag
bigger buffer > ongoin io > still data to decode and display
(like the purpose of every buffer)

[v0lt]

It is a bug in the internal decoder. ffdshow works fine.
Can you fix it?

[neoufo51]

Is it a guide for beginners ? Because honestly, no it's not the best settings...
Can you tell me what you think are the best settings? I'd like to create a text file like the one I posted for people who want the very best quality.

[shaolin95]

OK I am trying 10bit again after upgrading to the latest drivers for my ATI HD2400 and the latest ffdshow and mpc-hc builds.
STill cannot get it to work.
I am connected to my Project via HDMI. I have aero set to disable when running MPC-HC and Fullscreen enabled yet this is what I get:
http://img844.imageshack.us/img844/5023/img20110327142116.jpg (http://img844.imageshack.us/i/img20110327142116.jpg/)

[tetsuo55]

Please post a new screenshot with "CTRL+J" statistics active.

[pirlouy]

Can you fix it?
I guess he already tries to maintain ffdshow project. He can't do fixes for all ffmpeg projects... You can use ffdshow if you don't want this issue.

Can you tell me what you think are the best settings? I'd like to create a text file like the one I posted for people who want the very best quality.
Unfortunately, I'm not the one who knows a lot of things on subjects. More, everybody has his opinion on topic.
But you can google what I said in my previous post. JanWillem32 gave you some hints too.
But using a text file is not the best support today for beginners. :)
You can try to make a thread on the subject here; maybe some people will help...

[JanWillem32]

@KornX: http://forum.doom9.org/archive/index.php/t-100668.html A read-ahead buffer... I guess splitters and decoders could take care of a larger buffer of undecoded data. It's already common practice for streaming media. You might want to open a ticket for this and ask a developer to add a simple option to the GUI that allows changing the default read-ahead buffer value.

@shaolin95: Y'CbCr mode for output on HDMI or DisplayPort could cause this.
If the connection is made by converting a legacy DVI port to HDMI mode, it might fail, too. Does the card offer a physical HDMI port on the card or emulation over DVI? HDMI capability on ATI hardware is exposed by the audio over HDMI device for the video card in the device panel and sound panel of the Windows configuration screen. If it isn't there, it means that the card is limited to single-link or sometimes dual-link DVI data transport, which isn't completely compatible with the more advanced data transport types used by HDMI.

[shaolin95]

Please post a new screenshot with "CTRL+J" statistics active.
I left it full size and tried to tweak the color in B&W to make it a bit readable since the letters are red and the background is also red.
Let me know if that works please.
After you get the info you need , I can delete the file cause is huge I know.
Thanks
http://img163.imageshack.us/img163/8708/10biterror.th.jpg (http://img163.imageshack.us/i/10biterror.jpg/)

[pankov]

shaolin95,
please, use the Thumbnail preview option of ImageShak - "Embeded thumbnails of this image"
http://img163.imageshack.us/img163/8708/10biterror.th.jpg (http://img163.imageshack.us/i/10biterror.jpg/)

[Ger]

I have a question:

Is this playback settings guide as helpful as it can be?

http://files.nyaa.eu/HOW_DID_I_PLAYED_BACK.txt

I also prefer LAV Splitter, but maybe it's not ready for newbies yet due to lack of installer etc, if that's your target audience.

I guess the renderer/DXVA choice will always be controversial as you can see from previous comments. There is no one-size-fits-all renderer at the moment IMHO. Depends on the user's hardware/content/needs.

FWIW, I understand it works for other people, but your chosen resizer "Bicubic A=-0.60 (PS 2.0)" is completely broken (http://i.imgur.com/2oGpH.png) for both EVR Sync and EVR CP for me, as is A=-0.75.

I don't really care since since A=-1.00 works fine, but if you want a safer setting for more systems in your guide A=-1.00 is preferable based on my personal experience.

The above fullscreen screenshot is with JanWillem's r2993 tester build, but I'm 99% sure the trunk builds are the same and have been for a long time. I can double check with a recent trunk rev later if someone really wants to know.

[shaolin95]

@shaolin95: Y'CbCr mode for output on HDMI or DisplayPort could cause this.
If the connection is made by converting a legacy DVI port to HDMI mode, it might fail, too. Does the card offer a physical HDMI port on the card or emulation over DVI? HDMI capability on ATI hardware is exposed by the audio over HDMI device for the video card in the device panel and sound panel of the Windows configuration screen. If it isn't there, it means that the card is limited to single-link or sometimes dual-link DVI data transport, which isn't completely compatible with the more advanced data transport types used by HDMI.
It is aHD2600 Pro so it only has DVI ports on the back, is that then my issue?

[neoufo51]

I also prefer LAV Splitter, but maybe it's not ready for newbies yet due to lack of installer etc, if that's your target audience.

I guess the renderer/DXVA choice will always be controversial as you can see from previous comments. There is no one-size-fits-all renderer at the moment IMHO. Depends on the user's hardware/content/needs.

FWIW, I understand it works for other people, but your chosen resizer "Bicubic A=-0.60 (PS 2.0)" is completely broken (http://i.imgur.com/2oGpH.png) for both EVR Sync and EVR CP for me, as is A=-0.75.

I don't really care since since A=-1.00 works fine, but if you want a safer setting for more systems in your guide A=-1.00 is preferable based on my personal experience.
Thanks, I've deleted Haali and went with LAV Splitter and changed it to A=-1.00 and so far I see an improvement with MKV files performancewise.

[JanWillem32]

@Ger: I haven't really changed the default scalers yet, so I might need to do that. I don't exactly like the bicubic 0.75 scaler anyway (it was broken, so it was changed to 0.751). Do you know of any other pixel shaders that won't work in your setup (especially custom scalers)?

@shaolin95: I looked up the HD2600 pro, it can use correct HDMI signals over DVI links. In your screenshot the stats screen reports only 8-bit output, so you might need to change rendering settings. "Reset To Optimal Renderer Settings" + "Enable D3D Fullscreen" is often a good start. If that's too heavy, you can switch to "Half Floating Point Processing". (It's not always lighter on the video card, as HFPP is only lighter on the GPU memory controller, not the GPU itself.)
In the Catalyst Control Center, make sure you use a RGB full range output and while you're there, disable the stupid (unfortunately default) overscan compensation. In the "Video Settings" tab, disable all filters except automatic deinterlacing and pulldown detection. Some of those filters can result in a black screen when the video output of the mixer isn't 8-bit RGB.
That should probably clear up some problems. I've had some problems in the past with my setup, too. It's a pretty steep leaning curve to get things working. On top of that it's safe to assume that all the default settings of all software, drivers and hardware are wrong and sub-optimal.

[shaolin95]

@shaolin95: I looked up the HD2600 pro, it can use correct HDMI signals over DVI links. In your screenshot the stats screen reports only 8-bit output, so you might need to change rendering settings. "Reset To Optimal Renderer Settings" + "Enable D3D Fullscreen" is often a good start. If that's too heavy, you can switch to "Half Floating Point Processing". (It's not always lighter on the video card, as HFPP is only lighter on the GPU memory controller, not the GPU itself.)
In the Catalyst Control Center, make sure you use a RGB full range output and while you're there, disable the stupid (unfortunately default) overscan compensation. In the "Video Settings" tab, disable all filters except automatic deinterlacing and pulldown detection. Some of those filters can result in a black screen when the video output of the mixer isn't 8-bit RGB.
That should probably clear up some problems. I've had some problems in the past with my setup, too. It's a pretty steep leaning curve to get things working. On top of that it's safe to assume that all the default settings of all software, drivers and hardware are wrong and sub-optimal.
Wow that is some awesome explanation and cant thank you enough for taking the time to look this up amigo! :)
Just to confirm I am doing some changes to the ATI Control Center even though I am using ffdshow decoder and not AVIVO or whatever that is called, right?
I will work on that as soon as I get home.
BTW, in ffdshow I have it set to RGB32 high quality conversion and full range input then Computer display output.
Sorry if that is too vague..I can get the details later if that helps you.
Also, is there a particular HTPC card you recommend as an upgrade if mine is not up to par?
Thanks again!! :thanks:

[v0lt]

1. Why are two types of shaders in the player (Pixel Shaders and Screen Space Pixel Shaders)?
I found the answer to the first question. (http://forum.doom9.org/showthread.php?p=1345093#post1345093)

2. Why have two options "Shaders Disabled" and "Toggle Pixel Shaders"? :confused:

[Ger]

@Ger: I haven't really changed the default scalers yet, so I might need to do that. I don't exactly like the bicubic 0.75 scaler anyway (it was broken, so it was changed to 0.751). Do you know of any other pixel shaders that won't work in your setup (especially custom scalers)?


AFAIK, no scalers/shaders are broken on my system apart from the two bicubic variants I mentioned (A=-0.60 and A=-0.75). AFAIR they have been broken for a long time on my system, months/years. If you make some changes to them and want me to test, just let me know. All default shaders work (at least nothing is garbled).

As you know, one of the bilinear resizers produced similar garbled results in one of your previous test builds, but that is fixed in your 2993 build.

I briefly tried a couple of resizers from your shader pack, and they seemed OK as well.

I have a some more EVR-CP questions/issues I want to ask you about as well, but I think I'll send a PM some other day about those issues if that's OK. I need to remind myself what these issues were and write some stuff down first anyway, and I don't think it will be very interesting for anyone else.

2. Why have two options "Shaders Disabled" and "Toggle Pixel Shaders"? :confused:

I think because you can use CTRL-P to toggle shaders on/off and still remember which shaders were last used (it will still be selected, just not enabled).

I never understood why checked means disabled and unchecked means enabled though. Seems like inverted logic to me.

[namaiki]

AFAIK, no scalers/shaders are broken on my system apart from the two bicubic variants I mentioned (A=-0.60 and A=-0.75). AFAIR they have been broken for a long time on my system, months/years.

What GPU/driver version/version of Windows on that PC?

[Ger]

ATI 5770, Cat 11.2, Win7 SP1 x64, Dell 2709W 1920x1200 59.95 Hz connected through DVI as primary monitor.

[kasper93]

I have problem with red object, it looks blocky. Can you help me with this? :)
I'll take screen shot later.

HD5870, win7 64bit, 11.4pre (march 23) drivers.

http://dl.dropbox.com/u/16282309/MPC-HC/red.png
(look at the lights)
In low quality video it looks worse.

[Polcius]

I have problem with red object, it looks blocky. Can you help me with this? :)
I'll take screen shot later.

HD5870, win7 64bit, 11.4pre (march 23) drivers.

http://dl.dropbox.com/u/16282309/MPC-HC/red.png
(look at the lights)
In low quality video it looks worse.

Yeah, same here.

Red looks "blocky" or "lower resolution". I think it has something to do with the chroma. ATI HD4350, Win7 32bit, Catalyst 11.2.

[Damien147]

Me too.I posted a few days ago about this but never got an answer:(
Happens with every build I've tried since february.

OS and driver same as kasper93's with hd4850.

YV12 chroma upsampling shader(I don't know if it's the best option) or change to evr or do rgb conversion with ffdshow if you're using it.

1.5.1.2903 (http://sourceforge.net/projects/mpc-hc/files/) also works fine.

[Ger]

Try enabling the "YV12 Chroma Upsampling" shader (Play -> Shaders). You can then pause the video when you see problematic red areas and press CTRL-P to see the difference instantly with the shader on/off, even with a paused image.

IIRC Leak wrote this a few years ago to combat blocky reds with YV12 and ATI, but it seems to have spread to NV12 at some point. Don't know if MPC-HC changes or driver changes is the reason.

Actually, from a quick test the blocking is far worse in EVR-CP than in EVR Sync. With EVR Sync the difference with the shader on/off is very small. With EVR-CP it is noticeably better with the shader on.

EDIT: Damien147 beat me to it. The above work-around was written for kasper93. Maybe JanWillem can fix it in EVR-CP then, since it apparently was broken not so long ago.

[shaolin95]

@shaolin95: I looked up the HD2600 pro, it can use correct HDMI signals over DVI links. In your screenshot the stats screen reports only 8-bit output, so you might need to change rendering settings. "Reset To Optimal Renderer Settings" + "Enable D3D Fullscreen" is often a good start. If that's too heavy, you can switch to "Half Floating Point Processing". (It's not always lighter on the video card, as HFPP is only lighter on the GPU memory controller, not the GPU itself.)
In the Catalyst Control Center, make sure you use a RGB full range output and while you're there, disable the stupid (unfortunately default) overscan compensation. In the "Video Settings" tab, disable all filters except automatic deinterlacing and pulldown detection. Some of those filters can result in a black screen when the video output of the mixer isn't 8-bit RGB.
That should probably clear up some problems. I've had some problems in the past with my setup, too. It's a pretty steep leaning curve to get things working. On top of that it's safe to assume that all the default settings of all software, drivers and hardware are wrong and sub-optimal.
OK I could not find where to change the RGB to full range in the Control Center nor the overscan unless it is that panel scaling option which is unchecked already.
The others I was able to find but I still get the same redish image. :confused:
Also where can you tell my previous screenshot shows 8bits...I cannot see it anywhere.
Thanks!

[JanWillem32]

@shaolin95: Good luck in getting it to work, even I had some problems in setting everything up. (I mostly had audio initialization delay problems. I solved it with ASIO audio software.)
The EVR and VMR-9 mixers are still influenced by the video settings in the contol panel. Most settings in the control center matter, because a lot of them are applied for the whole system.
http://www.aoclarkejr.com/ati-catalyst-9-9-overcan-and-underscan-options.html This is with the older CCC, the newer version has the items listed under the "My ~ Displays" tab.
RGB32 input for the mixer is a legacy compatibilty fix for graphics cards that can't use Y'CbCr surfaces. In your case, with the common 8-bit 4:2:0 chroma down-sampled video input, NV12 would be correct. When using ffdshow tryouts, it's usually best to let the mixer do a lot of the conversion work. In the output tab of the video decoder, use "Set pixel aspect ratio in output media type", "Set interlace flag in output media type" and "Allow output format changes during playback".
HTPC video cards come in various kinds. I generally prefer a performance model (one that scores well in 3D benchmarks) over silent models. It completely depends on your budget, filter chain/rendering settings and need for a silent setup what would be ideal for you. (In addition to the performance needs for the more recent 3D games, 3D designing, et cetera.)
A reddish image can be caused by white-point compensation. Enabling the "Use ~ (EDID)" item in the "Desktop Management", "Display Color" tab often solves this problem.
Your screenshot mentions "Display: R8G8B8A8" in the top center part.

@Ger: I've made corrections to the default scalers. It will be integrated in the next tester build, but I don't know for sure it will solve the problem.

About the chroma up-sampling: I've written several shaders that work wonders on raw chroma data. It's currently available in the flavors blur (simple bilinear), Spline4 and Spline5. http://forum.doom9.org/showthread.php?t=157634
The "optimized path for up-sampling floating point surfaces" folder contains an optimized chain of up-sampling shaders to use in combination with FFPP or HFPP.
I still need to write a proper OP with a guide how to add and use shaders...

[shaolin95]

@shaolin95: Good luck in getting it to work, even I had some problems in setting everything up. (I mostly had audio initialization delay problems. I solved it with ASIO audio software.)
The EVR and VMR-9 mixers are still influenced by the video settings in the contol panel. Most settings in the control center matter, because a lot of them are applied for the whole system.
http://www.aoclarkejr.com/ati-catalyst-9-9-overcan-and-underscan-options.html This is with the older CCC, the newer version has the items listed under the "My ~ Displays" tab.
RGB32 input for the mixer is a legacy compatibilty fix for graphics cards that can't use Y'CbCr surfaces. In your case, with the common 8-bit 4:2:0 chroma down-sampled video input, NV12 would be correct. When using ffdshow tryouts, it's usually best to let the mixer do a lot of the conversion work. In the output tab of the video decoder, use "Set pixel aspect ratio in output media type", "Set interlace flag in output media type" and "Allow output format changes during playback".
HTPC video cards come in various kinds. I generally prefer a performance model (one that scores well in 3D benchmarks) over silent models. It completely depends on your budget, filter chain/rendering settings and need for a silent setup what would be ideal for you. (In addition to the performance needs for the more recent 3D games, 3D designing, et cetera.)
A reddish image can be caused by white-point compensation. Enabling the "Use ~ (EDID)" item in the "Desktop Management", "Display Color" tab often solves this problem.
Your screenshot mentions "Display: R8G8B8A8" in the top center part.

Thanks again for that. I am thinking on getting a newer 5700 series HTPC. I dont user this for gaming but I will look for decent power just in case.
I will keep playing with it.
Does it make a really good difference in banding or something going with 10bit?
Thanks for all your help mate! :)

[Mercury_22]

For those with SDK 7.1 & VC2010SP1 problems : Microsoft Visual C++ 2010 Service Pack 1 Compiler Update for the Windows SDK 7.1 (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=689655b4-c55d-4f9b-9665-2c547e637b70)2.1.3. Recommended Installation Order

To ensure that your system has a supported configuration, uninstall the following products and then reinstall them in the order listed:

1.Visual Studio 2010
2. Windows SDK 7.1
3. Visual Studio 2010 SP1
4. Visual C++ 2010 SP1 Compiler Update for the Windows SDK 7.1

[ceb]

In a custom installation of the AMD Catalyst drivers, there's an option called "wmv9/vc-1 video playback", is it of any use to MPC-HC? My video card is an ATI 5770.
In the description it says it's hardware acceleration, but I don't use DXVA because my CPU is powerful enough (Intel Core i5 2500), and anyway, even if I wanted to it doesn't work properly.

[Ger]

@Ger: I've made corrections to the default scalers. It will be integrated in the next tester build, but I don't know for sure it will solve the problem.

OK. As I said it's not important to me as long as A=-1.00 is working, but I'm happy to test the other two anyway, and will report back once the next tester build is released.

About the chroma up-sampling: I've written several shaders that work wonders on raw chroma data. It's currently available in the flavors blur (simple bilinear), Spline4 and Spline5. http://forum.doom9.org/showthread.php?t=157634
The "optimized path for up-sampling floating point surfaces" folder contains an optimized chain of up-sampling shaders to use in combination with FFPP or HFPP.
I still need to write a proper OP with a guide how to add and use shaders...

Understood, but as you can see from the last three posts before my last one, people are noticing a regression in EVR-CP when no shaders are used (which will surely be the case for most EVR-CP users out there).

This comment made me start looking through the archives to figure out when the problem started:
1.5.1.2903 (http://sourceforge.net/projects/mpc-hc/files/) also works fine.

@JanWillem
While it's true that the above build is fine, it's actually a bit misleading though, since that particular official/stable build is missing some commits that a trunk r2903 would have, as you can see from the blue OSD background color that was changed in r2863. So I used alexins' archive (xvidvideo.ru) and narrowed the regression down to the revision range 2834-2840 (http://sourceforge.net/apps/trac/mpc-hc/log/trunk?action=stop_on_copy&mode=stop_on_copy&rev=2840&stop_rev=2834&limit=100&verbose=on). In other words, r2833 is fine, but r2840 and later have very blocky reds. Tested up to and including r2994, and also your r2993 tester build. There are no archived trunk builds available between r2833 and r2840 from either alexins or xhmikosr, so I can't narrow it down further.

In that range I think r2837 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2837) and r2839 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2839) are the most likely culprits, both are AFAICS mostly your patches, so I think you would be the guy to talk to for the people hoping to get it fixed (without having to resort to shaders or another renderer).

With a relatively low res red logo upscaled to fullscreen I can clearly see the difference between r2833 and r2840 (http://i.imgur.com/1k7SI.png) (old default 8-bit chain used, but the problem is not limited to 8-bit). As you can see the logo in the middle has noticeably uglier/blockier reds than the other two, proving it was broken between those two revisions.

I stole the red/black/letters idea from madshi's second post in the madVR thread and found a usable logo in a low res xvid upscaled to fullscreen with Bicubic A=-1.00.

For anyone interested I also uploaded all original fullscreen screenshots (http://www.multiupload.com/UF2PP3U826), including some with other renderers for reference/curiosity reasons (madVR, EVR Sync, EVR) and a couple from the 2993 tester build with some additional options like HFPP, 10bOut and dithering in addition to one with the three shaders from "optimized path for up-sampling chroma on floating point surfaces" in shader pack 24. All four MPC-HC builds used during these tests are also included in that archive, in case xvidvideo.ru goes down again (was down for a while yesterday).

All tests done with ATI 5770, Win7 x64 SP1, 32-bit MPC-HC.

[Damien147]

Ger has a point about the ''~when the osd color changed''(I thought it was a problem too:p).I don't know if it's intended but now when using ffdshow(with default settings) I get different output(and different bad chroma result),NV12 instead of rgb32 when using internal decoder.This doesn't happen with 1.5.1.2903,stays rgb32.In general thumbs up for the changes,can't wait for the final result.
Screenshot (http://i.imgur.com/YPy3B.png) with default settings.

Looks the same as described in Ticket #915 (http://sourceforge.net/apps/trac/mpc-hc/ticket/915)(I don't know with nvidia) but without the necessity of dxva usage.

evr cp,win7 64bit sp1,ati 4850(11.4 preview),mpc-hc 32bit

[bobdynlan]

Test-drive this build (http://cid-d561cc7d122f3f32.office.live.com/browse.aspx/Shared/MPCHC%5E_SWSCALER%5E_MOD) featuring some new internal software decoder options.
More info in the readme. Also see ticket 719 (http://sourceforge.net/apps/trac/mpc-hc/ticket/719).

http://public.sn2.livefilestore.com/y1p0zCeMT3iqjbz83hAB4ctETpL_fM5vaUJt1gG6NT7lowch9VgTX8vj1X5mNUtmFzzXNADVagu0ayI2Hbag1lvUg/whatsnew.png?psid=1

[pdanpdan]

@bobdynlan
It seems it's working fine here (win7 64, ATI HD2400Pro, Cat 11.4) - now it's working for non DXVA also.
Thank you.

[fastplayer]

Test-drive this build (http://cid-d561cc7d122f3f32.office.live.com/browse.aspx/Shared/MPCHC%5E_SWSCALER%5E_MOD) featuring some new internal software decoder options.
More info in the readme. Also see ticket 719 (http://sourceforge.net/apps/trac/mpc-hc/ticket/719).
Is BT.601/BT.709 detection done automagically like in ffdshow's HQRGB32 (http://ffdshow-tryout.sourceforge.net/wiki/video:rgb_conversion#auto)?

[Mercury_22]

@bobdynlan
Working fine so far !
Why isn't your other patch, (for the GUI, AKA BE Mod (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-2-2999.html)) in the SVN cause is working fine here?

[bobdynlan]

Is BT.601/BT.709 detection done automagically like in ffdshow's HQRGB32 (http://ffdshow-tryout.sourceforge.net/wiki/video:rgb_conversion#auto)? For now it's not, just dumb resolution enforced, but it could be improved.
YV12/NV12 are still the recommended output formats, RGB32 only gets there quality wise if Chroma to RGB is on 'Full' (with the huge performance drops). At least now there are some options, and as a side effect can overcome some issues until the renderer patches of JanWillem32 get stable. Reading the readme it's a must.
@bobdynlan
Why isn't your other patch, (for the GUI, AKA BE Mod (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-2-2999.html)) in the SVN cause is working fine here? That's based on a old sketch source and I do not support it. I will reboot that mod soon - and now I mean it :)

[Mercury_22]

For now it's not, just dumb resolution enforced, but it could be improved.
YV12/NV12 are still the recommended output formats, RGB32 only gets there quality wise if Chroma to RGB is on 'Full' (with the huge performance drops). At least now there are some options, and as a side effect can overcome some issues until the renderer patches of JanWillem32 get stable. Reading the readme it's a must.
That's based on a old sketch source and I do not support it. I will reboot that mod soon - and now I mean it :)
Ok Can't Wait ! :thanks:

P.S. Cum e vremea la mare ( de 1 mai :) ) ?

[fastplayer]

For now it's not, just dumb resolution enforced, but it could be improved.
YV12/NV12 are still the recommended output formats, RGB32 only gets there quality wise if Chroma to RGB is on 'Full' (with the huge performance drops). At least now there are some options, and as a side effect can overcome some issues until the renderer patches of JanWillem32 get stable. Reading the readme it's a must.
What's the purpose of RGB15/16? If anything, RGB24 would make more sense IMO.
Anyway, I like the idea of taking more advantage of swscale and overcoming some of the deficiencies of the internal renderers. :)

[Damien147]

@bobdynlan
Working fine so far !


+1

..but I'm using ffdshow:o

As I said I get nv12 output with everything when using ffdshow,is it ok to use YV12 chroma upsampling shader for now?Any drawbacks?I like to keep things ''pure''.Changing renderer is not an option for me because I need color management.

[v0lt]

Test-drive this build (http://cid-d561cc7d122f3f32.office.live.com/browse.aspx/Shared/MPCHC%5E_SWSCALER%5E_MOD) featuring some new internal software decoder options.
Need a reset button. :)

[clsid]

Test-drive this build (http://cid-d561cc7d122f3f32.office.live.com/browse.aspx/Shared/MPCHC%5E_SWSCALER%5E_MOD) featuring some new internal software decoder options.
More info in the readme. Also see ticket 719 (http://sourceforge.net/apps/trac/mpc-hc/ticket/719).

http://public.sn2.livefilestore.com/y1p0zCeMT3iqjbz83hAB4ctETpL_fM5vaUJt1gG6NT7lowch9VgTX8vj1X5mNUtmFzzXNADVagu0ayI2Hbag1lvUg/whatsnew.png?psid=1
I would suggest removing the error resilience and idct options. Normal users should never need to change those.
Threads option is also pretty pointless since all ffmpeg decoders used by MPC are single-threaded.
Default input levels should be 16-235. Only formats like Fraps are 0-255, and that isn't even supported by the internal decoder.

[bobdynlan]

Threads option is also pretty pointless since all ffmpeg decoders used by MPC are single-threaded.
Default input levels should be 16-235. Only formats like Fraps are 0-255, and that isn't even supported by the internal decoder. I've only added what's on the right side. Threads option now works at least for swscaler, it will slice the image horizontally into n=nr. of threads, creating n swscontexts. And color defaults are on Auto = 16-235. The 0-255 option is there for some bad authored sources or broken renderers.

[khagaroth]

It would be probably a good idea to nuke all the RGB options (except RGB32). They did that in ffdshow too and I really don't see the point for them, or is there something that uses it.

[mindbomb]

I have a few questions:
The option for maximum texture resolution for subtitles - does this effect text based subtitles, image based, or both?
And why is it best to set it to desktop, aren't the resolution of subtitles considerably lower than that?

And about the yv12 chroma upsampling shader, if im using a dxva filter, there should already be hardware chroma upsampling, so i shouldnt need this in general, right?

[mikleemy]

Could something explaine the 'Jitter' mean ?
I got jitter 0 in MadVR but 8 for output setting to EVR ( custom preset ).

[betaking]

is this a bug?
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/apps/mplayerc/res/mplayerc.rc2?r1=3002&r2=3001&pathrev=3002
Based on the original Media Player Classic v6.4.9.0 (C) Gabest
Based on the original Media Player Classic v6.4.9.0 � Gabest
Copyright (C) 2002-2011 see AUTHORS file
Copyright � 2002-2011 all contributors, see AUTHORS file

[madshi]

Just a note for those who requested it: I've just re-added the "D3D Fullscreen" option for madVR (use revision 1.5.2.3005 or newer).

[HoP]

i unchecked "Keep history of recently opened files"
but mpc remember the last file...why?
my mpc version:mpc-homecinema.1.5.2.3004_(x64)_msvc2010
i didn't have this problem with old versions
http://www.pixelz.fr/1/4/4/fe1f95cda03d396b907dcf019a78b.jpg

[oddball]

Just a note for those who requested it: I've just re-added the "D3D Fullscreen" option for madVR (use revision 1.5.2.3005 or newer).

I have HUUUUUGE problems now with MadVR .47 and your latest build.

The problem is since MPC-HC added subs support to work alongside MadVR's subs support it's alll gone to hell. MPC-HC builds prior to the supported builds playback video in D3D perfectly on my Nvidia G210. The only snag is. No subtitle support.

So I installed a later build prioer to 3005 that supports the subtitles. Only I can't have D3D. If I force fullscreen on my plasma TV it tears like crazy.

If I install 3005 it plays correctly but it seems like it's dropping frames all over the places and I cannot pause it, stop it, access any of the menus on the MPC window etc. I can drag the window about on the primary monitor and I can press the escape key (which I have mapped to exit) to exit the player.

What gives?

[pdanpdan]

@madshi
Thank you. Now it's very usable in my setup. :)
Now the bad thing - with D3D Fullscreen active and automatic exclusive mode active the same thing oddball just reported happens.
With automatic exclusive mode inactive everything is fine.
Edit: And with D3D Fullscreen + automatic exclusive mode I get no seek bar on bottom.

@oddball
Try to disable automatic exclusive mode

[oddball]

@madshi
Thank you. Now it's very usable in my setup. :)
Now the bad thing - with D3D Fullscreen active and automatic exclusive mode active the same thing oddball just reported happens.
With automatic exclusive mode inactive everything is fine.

@oddball
Try to disable automatic exclusive mode


I just tried that and it's back to tearing and dropping tons of frames. I do get the menu's back though. But it still does not let me pause playback. It stops momentarily then carries on playing. If I leave it with exclusive mode it plays back smooth as silk even with subs (But drops frames when animated subs is enabled so I usually disable that). But I lose access to the player window controls. Keyboard shortcuts work fine however (apart from the aformentioned pausing problem).

Is a fix on the way? Or is it not doable while in exclusive mode?

Also I cannot turn subs off with the 'w' key. :(

[pdanpdan]

It's funny:
1. D3D + auto exclusive mode + delay 3 seconds
2. start play (payer interface on display 1, fullscreen on display 2)
3. right-click on movie (display 2) and leave the menu visible
4. now you can use the controls on the player interface on display 1
5. when the movie returns in exclusive mode, no buttons again

[oddball]

It's funny:
1. D3D + auto exclusive mode + delay 3 seconds
2. start play (payer interface on display 1, fullscreen on display 2)
3. right-click on movie (display 2) and leave the menu visible
4. now you can use the controls on the player interface on display 1
5. when the movie returns in exclusive mode, no buttons again

That's because when you right click display 2 it's switching back to windowed mode.

EDIT: At least I can right click the MadVR icon and pause, etc there.

[madshi]

I have HUUUUUGE problems now with MadVR .47 and your latest build.

The problem is since MPC-HC added subs support to work alongside MadVR's subs support it's alll gone to hell. MPC-HC builds prior to the supported builds playback video in D3D perfectly on my Nvidia G210. The only snag is. No subtitle support.

So I installed a later build prioer to 3005 that supports the subtitles. Only I can't have D3D. If I force fullscreen on my plasma TV it tears like crazy.

If I install 3005 it plays correctly but it seems like it's dropping frames all over the places and I cannot pause it, stop it, access any of the menus on the MPC window etc. I can drag the window about on the primary monitor and I can press the escape key (which I have mapped to exit) to exit the player.
I didn't do anything in 3005 except restoring what I removed in 2988. If you have new problems with 3005 then they are probably caused by other changes done by other devs somewhere between 2988 and 3005, I'd guess.

"Only I can't have D3D". Why not?

Now the bad thing - with D3D Fullscreen active and automatic exclusive mode active the same thing oddball just reported happens.
With automatic exclusive mode inactive everything is fine.
Edit: And with D3D Fullscreen + automatic exclusive mode I get no seek bar on bottom.
Is that different or identical to how things were with older MPC-HC builds?

It's funny:
1. D3D + auto exclusive mode + delay 3 seconds
2. start play (payer interface on display 1, fullscreen on display 2)
3. right-click on movie (display 2) and leave the menu visible
4. now you can use the controls on the player interface on display 1
5. when the movie returns in exclusive mode, no buttons again
Was that different with builds older than 2988?

[pdanpdan]

I don't remember (to tell the truth). What I remember is that with older MadVR+MPC-HC it was crashing and often not working, and now it's working, so it's much better.
Just a question - if I use VMR/EVR+D3D Fullscreen I can see the OSD seekbar interface on the second display, and I can pause the movie by dblclick on movie image (dblclick set as pause/play).
With MadVR+D3D Fullscreen (exclusive or non-exclusive - doesn't matter) I cannot pause by dblclick on screen.
Is this by design?

[madshi]

Look, I do not want to officially support this "D3D Fullscreen" switch. I understand some of you guys "misuse" this switch to move playback to the secondary monitor while having the MPC-HC window on the primary monitor. But that's really not what this switch was originally made for. I removed this switch because it doesn't really make sense, from a logical point of view, since madVR switches to "D3D Fullscreen" (which is just another word for "exclusive mode") on the fly whenever it makes sense - no matter how this MPC-HC "D3D Fullscreen" option is configured. So really, logically, this option should be removed for madVR. So that's what I did in revision 2988. But then several people complained, so I brought the option back because I don't want to make things worse for you. But other than that, I'm not really willing to chase bugs that occur when using this switch. If it works as well (or as bad) as it used to in older versions, that's all you will get. However, if it works worse now than it did in older versions then *maybe* you can motivate me to check why it's worse now. But other than that I will not spend any time in the future working on this.

[Thunderbolt8]

there seems to be a problem with directvobsub and the current mpc build (3008; mpc-hc internal subtitle renderer -> enabled unticked). subs often dont get loaded depending on movie codec and renderer.

with madvr, in case of 4 out of 5 mpeg2 hdtv remuxes, madvr doesnt load and all 4 have added subs inside the .mkv file, while the one which does play has none.

in case of haali and evr, in none of all these cases the subs appeared. direcvobsub doesnt load up at all when using haali or evc with these mpeg2 hdtv source remuxes.

in addition, directvobsub doesnt load up with haali at all, while it does at least with evr for (avc) blu-ray remuxes.


edit: in case of madvr, that 1 movie in which case madvr loads is YV12, while the other ones are YUV12.

edit²: set output colour space of dscaler decoder to YV12, now its all fine with madvr and evr. directvobsub still doenst load with haali though, dont know whether this is normal or not.

[JanWillem32]

Some time ago I mentioned the sampling method for the 3D LUT of the color management. I forgot to post the gradient shader later on.
// color gradients
// This shader should be run as a screen space pixel shader.
// This shader requires compiling with ps_2_0, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// If possible, avoid compiling with the software emulation modes (ps_?_sw). Pixel shaders require a lot of processing power to run in real-time software mode.
// This shader will create color gradients.

// fractions, either decimal or not, are allowed
// ColorTopLeft, ColorTopRight, ColorBottomLeft and ColorBottomRight, assign colors in a linear float4(Red, Green, Blue, Alpha) format
#define ColorTopLeft float4(.015625, 0, 0, 1)
#define ColorTopRight float4(.015625, .00390625, .00390625, 1)
#define ColorBottomLeft float4(0, 0, 0, 1)
#define ColorBottomRight float4(0, 0, 0, 1)
// ProcessingGamma, the gamma value used by the color management system, the display gamma value can be used as an alternative
#define ProcessingGamma 1

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return pow(lerp(lerp(ColorTopLeft, ColorTopRight, tex.x), lerp(ColorBottomLeft, ColorBottomRight, tex.x), tex.y), 1/ProcessingGamma);
}The differences are minor, and the most difficult colors are brown and rich, dark blue tints. Of course, it's worst with the 64³ points 3D LUT with a linear input. Don't forget to disable dithering when testing in either 8- or 10-bit mode.
For me, most of the banding problems with the color management were solved by making an accurate calibration (non-bt.709 with a gamma of 2.6). It's rather dark to use with other software that can't do color management (so I changed my desktop image). Luckily, most graphical programs usually feature at least a simple brightness, contrast or gamma setting.
I'm quite happy with the improvements and the only banding issues I still have are caused by (unfortunately common) 8-bit source images.

I've made optimizations on the internal scaling, the color management and the dithering pixel shaders. The VSync problems are difficult to solve, but it's a lot of code, and it contains quite a lot of math and general programming errors. It will take time to get those corrected. The main item that's affected by it is the mostly broken VSync offset function.

[oddball]

Look, I do not want to officially support this "D3D Fullscreen" switch. I understand some of you guys "misuse" this switch to move playback to the secondary monitor while having the MPC-HC window on the primary monitor. But that's really not what this switch was originally made for. I removed this switch because it doesn't really make sense, from a logical point of view, since madVR switches to "D3D Fullscreen" (which is just another word for "exclusive mode") on the fly whenever it makes sense - no matter how this MPC-HC "D3D Fullscreen" option is configured. So really, logically, this option should be removed for madVR. So that's what I did in revision 2988. But then several people complained, so I brought the option back because I don't want to make things worse for you. But other than that, I'm not really willing to chase bugs that occur when using this switch. If it works as well (or as bad) as it used to in older versions, that's all you will get. However, if it works worse now than it did in older versions then *maybe* you can motivate me to check why it's worse now. But other than that I will not spend any time in the future working on this.

I feel that's a little unfair to use as a blanket statement. I understand your reasons but many people use the D3D option in order to get smooth playback and for using on a secondary display. If I simply turn off D3D I get horrible tearing and framedrops using MadVR. If I go back to an earlier build I lose subs in MadVR. I want to be able to use MadVR in order to get the best image quality. I also want to be able to use MPC-HC's high quality subs. I don't see what the problem is with fixing the interface but then I do not know how to program so if it's a technical limitation then so be it. Many people need to be able to operate the video from a different display and keep D3D. DJ's in clubs for instance is one application that comes to mind. I tried builds without D3D support and MadVR does not work for me for some reason. My Nvidia G210 chokes on it when 'windowed' but fullscreen on my Panasonic G20 plasma HDTV. The reasons for this I do not fully comprehend. All I know is that D3D gives me smooth playback with 24P.

BTW I do not get any seek bar on the secondary display and I am unable to seek while in D3D other than using keyboard FF or MadVR's move backwards and forwards by 30 mins, 5 mins etc.

By developing MadVR and MPC-HC to work with each other surely it's in everyones interest to make them work as smoothly as possible with as many of the previous playback options as possible? What you have achieved here is fantastic and I applaud you for it. So please don't feel sour about us asking for such things. I know we can be a very demanding lot so please forgive us for our wants and whims :thanks:

[mark0077]

Hi. Just wondering can mpc when it crashes can it report the cause of the crash.

[madshi]

Some time ago I mentioned the sampling method for the 3D LUT of the color management. I forgot to post the gradient shader later on.

[...]

The differences are minor, and the most difficult colors are brown and rich, dark blue tints. Of course, it's worst with the 64³ points 3D LUT with a linear input.
So this shader allows to reproduce the banding problems you were seeing with the 3D LUTs earlier?

Don't forget to disable dithering when testing in either 8- or 10-bit mode.
Why?

I understand your reasons but many people use the D3D option in order to get smooth playback and for using on a secondary display. If I simply turn off D3D I get horrible tearing and framedrops using MadVR.
I think there's a misunderstanding here. Tearing is a problem which can occur in windowed mode. Exclusive mode fixes that. The "D3D Fullscreen" option in MPC-HC has *nothing* to do with windowed vs. exclusive mode, when using madVR. madVR automatically switches between windowed <-> exclusive mode, whenever it makes sense. E.g. right click on the video to get a context menu and madVR will switch to windowed mode (you'll get an OSD message saying "windowed"). Once the context menu is gone, after 3 seconds madVR switches back to exclusive mode (you'll get an OSD message saying "exclusive"). All of this should work fine with or without the MPC-HC "D3D Fullscreen" option. So while the MPC-HC "D3D Fullscreen" option does fix tearing with VMR/EVR, the situation is different with madVR. When using madVR, the "D3D Fullscreen" option should have zero effect on windowed <-> exclusive mode, and thus zero effect on tearing.

I don't see what the problem is with fixing the interface
The problem is that I don't know the MPC-HC code and fixing bugs in unknown code is a very frustrating and extremely time consuming experience.

Look: There were no complaints about how the "D3D Fullscreen" option worked with madVR before I removed it in 2988. So I'm wondering: Why are there suddenly complaints how it works now that I brought it back?? Does the "D3D Fullscreen" option not work as well as it did before? That's the information I'm trying to squeeze out of you guys in the last couple of posts. But so far nobody has bothered to comment on that.

Many people need to be able to operate the video from a different display and keep D3D.
And you can do so with madVR without needing the "D3D Fullscreen" option. Just start MPC-HC, move it to the secondary monitor, then load the video file and go into fullscreen mode (Alt+Enter). Now madVR should go into exclusive mode on your secondary display. This should work with all media players, including MPC-HC, without the "D3D Fullscreen" option.

My Nvidia G210 chokes on it when 'windowed' but fullscreen on my Panasonic G20 plasma HDTV. The reasons for this I do not fully comprehend. All I know is that D3D gives me smooth playback with 24P.
So madVR does not go into exclusive mode for you without using the MPC-HC "D3D Fullscreen" option? If so, please post this as a problem in the madVR thread and we'll analyze the problem there.

BTW I do not get any seek bar on the secondary display and I am unable to seek while in D3D other than using keyboard FF or MadVR's move backwards and forwards by 30 mins, 5 mins etc.
Did this work with builds older than 2988?

Again, let me repeat: If 3005 (and newer) work worse than builds older than 2988 then I might be willing to look into it. However, if 3005 (and newer) builds work the same way as older builds did, in other words: If things are just the way they used to be before I removed the D3D Fullscreen option in 2988 then I'm not willing to debug any problems with the D3D Fullscreen option.

[oddball]

I have no problems with MadVR playing in exclusive mode. My issue is I cannot use the interface the same way I did previously because I am unable to view the menu options on the secondary display at the distance I watch my TV from even on a 50" display. My PC is situated further back than the sofa (behind it) and simply saying to right click on the secondary display means I have to lean over and squint to see the options (I like to check filter properties and such). It was ideal when the player controls were on my main monitor and the video on the secondary display. It meant I could see EXACTLY what options to click on.
It was also a bit easier to exit because when you click on the icon on the taskbar in it's current form you sometimes end up minimizing the fullscreen to windowed as it's not always easy to tell if you already had it as the forground window. It's one of the things that made MPC-HC great being able to use the player controls with the mouse and not just key shortcuts (which there are not all shortcuts for) on one display whilst having the video play fullscreen on the other. I already got annoyed with Nvidia pulling that stunt by removing overlay mode from S-Video out on older cards in their later drivers. Now this is causing a similar issue. Like I said. It's not just me being awkward. It's a really useful feature. Especially for people like club DJ's who DO NOT wish for people to see the mouse cursor and popup menu's on a projection.

I hope this makes sense now.

EDIT: To answer your questions fullscreen exclusive works just fine and dandy in build 3005. MadVR .47 also worked fine and dandy in builds prior to MPC-HC supporting MadVR subs (But there were no subs obviously). The builds in between removed D3D support and I did not notice this until I got back to my home setup where I use multiple displays. Build 3005 added D3D in again but in the process has broken the seperate controller interface. If you decide not to work on that then that's obviously your decision and all I can do is work around the limitations as best I can. But I may just have to go back to EVR as it's easier to handle (Plus I can do screencaps but that's no biggie to switch back to that renderer just for that purpose).

I guess this is what happens when you have 2 different things going on in seperate fields. MPC-HC devs doing their own thing and you doing your own thing with your renderer.

[madshi]

I have no problems with MadVR playing in exclusive mode.
You're confusing the hell out of me. In your previous post you were talking about tearing problems. Now you say you have no problems with madVR playing in exclusive mode. Now which is it? You can't have it both. Either you have tearing or you don't. If you do, then madVR is not in exclusive mode.

My issue is I cannot use the interface the same way I did previously because I am unable to view the menu options on the secondary display at the distance I watch my TV from even on a 50" display.
But in MPC-HC build 3005 I brought the "D3D Fullscreen" option back. So you should be able to use the interface the same way you did previously.

:confused:

[JanWillem32]

So this shader allows to reproduce the banding problems you were seeing with the 3D LUTs earlier?This shader is quite good at creating perfect gradients. That includes the types that give horrible banding purely due to the 8- or 10-bit RGB output color quantization (source banding of near black colors isn't a big problem with floating-point surfaces). It's quite a good test to see what color management does to a certain gradient. On top of that, it should show the difference the different types of dithering can make. I can see some uneven distribution between the color bands in some transitions with linear interpolation. With better interpolation the bands are spaced more evenly. It's a minor thing, because even the most basic dithering will mask the minor deviations from true curves in the linear interpolation due to the noise.

[oddball]

You're confusing the hell out of me. In your previous post you were talking about tearing problems. Now you say you have no problems with madVR playing in exclusive mode. Now which is it? You can't have it both. Either you have tearing or you don't. If you do, then madVR is not in exclusive mode.


But in MPC-HC build 3005 I brought the "D3D Fullscreen" option back. So you should be able to use the interface the same way you did previously.

:confused:

My bad. I was only experiencing tearing issues when in windowed mode. Sorry for the confusion (I was confused myself because when I made that post I did not know anything about exclusive mode). In build 3005 I can no longer use the player window on the main display when D3D is enabled. The menu options are greyed and if I click on anything nothing works. No pause. No stop. I cannot even click on the exit icon in the top right corner. I mean they click down but nothing actually happens. In builds prior to sub support for MadVR this was not an issue even with D3D ticked. However I can use most keyboard shortcuts and MadVR's right click options for MPC-HC.

[madshi]

My bad. I was only experiencing tearing issues when in windowed mode. Sorry for the confusion (I was confused myself because when I made that post I did not know anything about exclusive mode). In build 3005 I can no longer use the player window on the main display when D3D is enabled. The menu options are greyed and if I click on anything nothing works. No pause. No stop. I cannot even click on the exit icon in the top right corner. I mean they click down but nothing actually happens. In builds prior to sub support for MadVR this was not an issue even with D3D ticked. However I can use most keyboard shortcuts and MadVR's right click options for MPC-HC.
Ok, so to sum up. In the following situation:

- "D3D Fullscreen" mode active
- video playback on secondary monitor
- MPC-HC main window is still on primary monitor

In this situation the MPC-HC main window user interface (play, stop, exit etc) does not work, anymore. Is that correct? Please double check the same problem with EVR and VMR. Does it occur with those renderers, too? Or does this problem only occur with madVR?

[pdanpdan]

Ok, so to sum up. In the following situation:

- "D3D Fullscreen" mode active
- video playback on secondary monitor
- MPC-HC main window is still on primary monitor

In this situation the MPC-HC main window user interface (play, stop, exit etc) does not work, anymore. Is that correct? Please double check the same problem with EVR and VMR. Does it occur with those renderers, too? Or does this problem only occur with madVR?

1. + MadVR with exclusive mode ON + 3 seconds ON => MPC-HC interface does not work in exclusive mode,MPC-HC interface does work in non-exclusive mode, OSD seek bar(MadVR) does not show
2. + MadVR with exclusive mode ON + 3 seconds OFF => MPC-HC interface does not work, OSD seek bar(MadVR) does not show
3. + MadVR with exclusive mode OFF => MPC-HC interface does work, OSD seek bar(MadVR) does not show

4. + EVR-CP => MPC-HC interface does work, OSD seek bar(MPC) does show

[madshi]

Ok, and how does that compare to older MPC-HC builds? There everything worked with madVR, too? That's important for me to know.

And even more important is with which revision the problem started. Can you please try the various older builds from here:

http://xhmikosr.1f0.de/index.php?folder=bXBjLWhjL29sZC94ODY=

And tell me up to which exact revision it still worked and with which revision it broke?

Thanks!

[pdanpdan]

MPC interface: with 2987 it's working, from 2988 to 3007 there is no D3D, 3008 - not working.
MadVR OSD seekbar: not working in any version, so no change in there.

[madshi]

Ok, I think it must be v0lt's change in revision 2991 then:

http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2991

[CruNcher]

Wow just tried http://www.mediafire.com/download.php?7hddy3klaxz9kyf with current MPC-HC TS Parser and it works absolutely flawless (no jitter 0-1ms no drops absolutely flawless) with Cyberlinks Decoder and DXVA (frame interlaced + progressive) (some time ago it jittered like crazy)


WOW WOW WOW

http://img27.imageshack.us/img27/6083/cyberlinkvc1frameinterl.png

http://www.mediafire.com/download.php?46xvi8z0q9vxtvf still no Video Connection to Cyberlinks Decoder, V0lt could you take a look @ that its field interlaced :(

http://img832.imageshack.us/img832/7673/fieldinterlacedvc1ts.png

not sure what for a nonsense the splitter detects here the ID is correct but Audio ?

General
ID : 1 (0x1)
Complete name : C:\mediadatabase\VC1\TS\MC.ts
Format : MPEG-TS
File size : 56.4 MiB
Duration : 17s 664ms
Overall bit rate : 26.7 Mbps
Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : AP@L3
Codec ID : 234
Duration : 17s 117ms
Bit rate : 24.8 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.399
Stream size : 50.5 MiB (90%)

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : 129
Duration : 17s 664ms
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Video delay : -63ms
Stream size : 1.35 MiB (2%)


using Arcsoft Demuxer + Video Decoder it works flawless

http://img225.imageshack.us/img225/2796/arcsoftplaybackvc1field.png

[v0lt]

Ok, I think it must be v0lt's change in revision 2991 then:

http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2991
D3DFullscreen is incompatible with worker thread.
http://msdn.microsoft.com/en-us/library/bb174313(v=vs.85).aspx
This method should not be run during the handling of WM_CREATE. An application should never pass a window handle to Direct3D while handling WM_CREATE. Any call to create, release, or reset the device must be done using the same thread as the window procedure of the focus window.
There was a very nasty bug. Sometimes after closing the file (Ctrl+C), everything freezes except the taskbar.
If we do not use a worker thread, then everything is fine.

[madshi]

D3DFullscreen is incompatible with worker thread.
No, it is not.

http://msdn.microsoft.com/en-us/library/bb174313(v=vs.85).aspx

Any call to create, release, or reset the device must be done using the same thread as the window procedure of the focus window.
Yeah, correct. But that doesn't mean that you can't use a worker thread. You just need to do device reset / release on the worker thread, too. That would be the proper bug fix.

If we do not use a worker thread, then everything is fine.
That's a cheap way to "fix" the problem. And it breaks D3D Fullscreen with madVR. So no, not everything is fine.

[v0lt]

Yeah, correct. But that doesn't mean that you can't use a worker thread. You just need to do device reset / release on the worker thread, too. That would be the proper bug fix.
We tried. It does not help.

Changeset 3011 (http://sourceforge.net/apps/trac/mpc-hc/changeset/3011/)
update for commit 2991: don't use a worker thread in D3DFullscreen mode except madVR

[madshi]

Thanks, v0lt, I appreciate that.

BTW, what I don't understand: CreateDevice, DeviceReset and release is all needed for windowed mode, too. So why do the problems with the worker thread only occcur with D3D Fullscreen mode? Anyway...

So, to those madVR users who want to use D3D Fullscreen mode: It should work as it used to with build 3011 and newer.

[pdanpdan]

@Madhi / @v0lt
Thank you

[janos666]

Does anybody have problems with subtitles and r3010 (I am using xhmikosr's MSVC'10 x86 build).

[v0lt]

@JanWillem32
I was asked to report:
If the Catalyst Control Center is not installed on your system, then the driver does not allow to derive NV12 (which works renderer EVR CP in recent versions). Only RGB32 gives. That is bad for DXVA and get the black screen.

[sneaker_ger]

Does anybody have problems with subtitles and r3010 (I am using xhmikosr's MSVC'10 x86 build).

No problem here using that exact same build. (win 7 x64)

[janos666]

AMD drivers are unable to operate properly without CCC. It also applies for any D3D or OpenGL softwares, not only for video decoding.
Their WDDM drivers are simply useless without the CCC application. (If you want to do anything else than running the Windows Aero and other basic stuffs without hardware acceleration.)

[janos666]

No problem here using that exact same build. (win 7 x64)

Thanks. It works again after I deleted my settings from the registry and reconfigured.

[SamuriHL]

Does anybody have problems with subtitles and r3010 (I am using xhmikosr's MSVC'10 x86 build).

Just tested it. Working fine for me. madVR 0.49 and 3010 MSVC 2010 x86 build.

[oddball]

Thanks guys for listening. I'll let you know how I get on with 3011 when it hits your site.

[pirlouy]

AMD drivers are unable to operate properly without CCC. It also applies for any D3D or OpenGL softwares, not only for video decoding.
Their WDDM drivers are simply useless without the CCC application. (If you want to do anything else than running the Windows Aero and other basic stuffs without hardware acceleration.)
Ah ??
CCC is not started for me, and I don't have problems, in games or when watching videos for example...

[janos666]

I lost the subtitles again after I changed the font size of the default style, and nothing else brings it back except the registry cleaning.

Ah ??
CCC is not started for me, and I don't have problems, in games or when watching videos for example...

CCC sets the proper driver configuration for the 3D applications (loads the application profiles to ensure compatibility with the given software).
You don't need to run the GUI itself all the time but you need it to be installed and you shouldn't kill it's backgroung processes (AMD External Events Service/Client Module...).

Of course, you can live without it, as you can live without the driver itself but you are only asking for trouble because it is needed for full functionality.

[ryrynz]

D3D Fullscreen option gives us automatic fullscreen on playback which I find useful in MPC (I don't have to push the fullscreen button on my remote after I press play) Is it possible to provide us this this feature aside from using this? Launch files in fullscreen does the trick when I launch a file in explorer but if I have files in the playlist it won't enter fullscreen mode.

[Ger]

@JanWillem
Tried tester build 3008. No change in A=-0.60 and A=-0.75 resizers. A=-1.00 is still OK.

FYI:
Desktop ATI 5770 -> DVI -> Dell2790W@1920x1200 = broken.
Laptop Nvidia 9600M GT -> HDMI -> same Dell2790W@1920x1200 = working.


Also tested the chroma upsampling issue (blocky reds (http://i.imgur.com/1k7SI.png)) with that Nvidia laptop and the same monitor connected via HDMI, and it's not affected at all, so that is apparently also (still) an ATI-only issue.

For the people who were asking questions about this issue earlier, a summary of what I've tested:
- ATI + EVR-CP affected (11.2 and 11.3 drivers tested).
- Trunk r2833 OK.
- Trunk r2840 and later affected (issue started in r2834-r2840 range).
- Official 2903 from SorceForge OK (this is not a standard 2903 trunk build).
- JanW mods (-3008) and bobdynlan/BE mods (-3010) also affected.
- Colorspace output by decoder does not seem to matter (exception is RGB32 with HQ conversion done in decoder).
- DXVA or not does not matter (except the issue is much harder to spot in HD material, which is normally what you'd use DXVA for I assume). The improvement by the YV12 shader can still be spotted in HD material played with DXVA, but it's easier to see if you zoom in as much as possible.
- Nvidia OK.
- EVR Sync and other renderers OK.

Workarounds include:
1. The included "YV12 Chroma Upsampling" shader by Leak. The name of the shader does not mean that the decoder's ouput colorspace has to be YV12. It works well with different colorspaces and with both integer and fp surfaces. This is probably the easiest and most flexible workaround. I've not seen this break anything in any situation (may add a slight blur compared to no shaders in old unaffected builds or EVR Sync if you really stare at it).

2. JanWillem's shaders available in his shader packs. The optimized fp path worked for me with NV12 and fp, but also needs to be properly matched to your config or the result can get worse.

3. Perform high quality RGB conversion in the decoder and feed RGB32 to EVR-CP. Warning: This will break ATI's Vector Adaptive hardware deinterlacing (requires NV12) and will obviously not work with DXVA (requires NV12 as well):
a) ffdshow: Set to output RGB32 with "High quality YV12 to RGB conversion checked (unchecking NV12 on the output page is enough to accomplish that on ATI+EVR with the default settings in latest ffdshow builds).
b) bobdynlan's swscaler mod (also included in the Black Edition mods available from xvidvideo.ru). "Chroma to RGB" must be set to "Full" ("High" is not enough) in the MPC Video decoder properties. RGB32 must be moved to the top of the list if the others are still checked. These options are not currently available for the MPEG-2 decoder or in regular trunk builds.

4. Use official 2903 build or trunk r2833 or earlier.

5. Use another video renderer or Nvidia. :p

I'm hoping this can eventually be fixed in EVR-CP by JanWillem or someone else, to get it on par with the old behavior and EVR Sync. In the meantime the first workaround, the "YV12 chroma upsampling shader", is a quick and easy solution for affected ATI/EVR-CP users.

This was all written (and sometimes tested) rather quickly, so there may be some mistakes or erroneous assumptions. Feel free to correct me if that's the case. I hope it answers most of the questions that were asked from a user's perspective. If you want technical details from a dev's perspective, I'm not the guy to ask.

[oddball]

Build 3011 does indeed bring back the menu's etc using D3D option but it broke something in the process. I have a greeny orange seek bar stuck at the bottom on the secondary display showing the video and playback is jerky. I'll investigate further with some default settings in a while to make sure it's not some filter/codec combination causing it (watching a movie at the moment).

[Rain1]

I set Auto-zoom: 100% in Playback and it works well for vids with resolution < my monitor's res. 1920x1200 (They were played 100% at their resolution). However, with full HD vids, MPC-HC plays in maximize window mode & still show the border. Doesn't it suppose to play at full screen (without border, at all) ?

I know there's a full screen option, but that setting overwrite the auto-zoom setting at 100% & always play vids in fullscreen, regardless of their res.

Is there anyway to make the player to auto switch to full screen for fullHD clips, when Auto-zoom is set to 100% ?

Thanks /

[JanWillem32]

@Rain1: Only the "D3D Fullscreen Mode" option will make videos render in full screen on startup, as far as I know.

@Ger: Thank you for testing. I already thought my changes to the bicubic resizer wouldn't make much of a difference (the output assembly didn't change much). Bicubic resizing in a single pass with the current matrix method is sub-optimal anyway. I hope you have more luck when other two-pass resizing modes are added. Luckily, (although blurry) native GPU bilinear filtering is default.

I do have some remarks, of course. (I'm in a technical mood/mode today.)

Chroma up-sampling is something best left to a custom mixer. The native surface blitting from Y'CbCr to RGB on GPUs have incoherent results. Newer nVidia models force a bilinear filter on doubling the dimensions of the chroma data, which can't be disabled. Older nVidia models, ATi and Intel models don't filter, so the chroma is resized with the nearest neighbor method. Of course, neither forcing bilinear filtering nor skipping filtering is a good solution. However, I can understand that adding a GUI option in the video section of the drivers with a range of chroma resizing filters that range from unfiltered to something like Lanczos256 would be rather much to ask from GPU driver developers.
The only thing I can do at the moment is integrating the shaders I've written in a similar way as the color management and dithering function, making in effect half a mixer. That would work okay as a user-selectable option, but not as an automatic one.
The other (preferred) option would be to discard the EVR and VMR-9 mixer and give the shared renderer part of VMR-9 (renderless) and EVR CP a custom mixer. The hard parts are that I've haven't seen any mixers with a GPL license around, I can't just write one on my own, without months worth of lessons in media handling like this in my spare time and lastly, I wouldn't know a good name for the renderer, as (renderless) and CP are what would remain of the original names.

I'm the one that pushed conversion to RGB32 or RGB24 to the very bottom of the mixer input priority list. All the current decoders are natively NV12, YV12, I420 and YUY2 anyway. With the conversion to RGB32 or RGB24, after having conversion from Y'CbCr to RGB, the resulting floating points are rounded to 8-bit integer. With some luck, there's some dithering involved (that can't be compared to the internal 32²||128² dither maps and randomized dithering methods). Anyway, this kind of conversion is pretty lossy. It's completely unacceptable for any renderer chain to be designed like that.
Conversion to RGB32 or RGB24 before the mixer is just a compatibility option for old GPUs that can't provide any suitable Y'CbCr surfaces for the VMR-9 or EVR mixer that for some reason demand such support.

Absolutely all current internal shaders can be replaced by a set I've written (and a selection of a few more). I highly doubt there will be anyone that will deny that the versions I've written are superior. I'll happily defend that statement if someone wants to challenge me. The "YV12" shader was one of the first I've re-written for MPC-HC (last September). See the OP and the first few posts from the shaders thread for reference.

Advanced deinterlacing methods are not exclusive to ATi hardware. The nVidia and (recent) Intel solutions include those, too. Software deinterlacing has included several advanced methods for more than a decade.
The current GPUs just prefer to do deinterlacing with NV12 input it seems. The deinterlacing capabilities of a GPU can be checked with the DXVAchecker program.

[oddball]

I'm quite happy with things the way they are now. I can now use D3D tickbox and get MadVR with exclusive mode on secondary display. All menu's and controls appear to function correctly. The only snag I had was my GPU is not fast enough to handle 720p with subtitle heavy video at 720p (desktop res and power of 2). I wanted to use softcubic 100 on chroma and spline 4 tap on luma up and down. But it was dropping frames too much. I've ended up overclocking my G210 and things are a LOT better (see link below on the overclock)! :)

http://www.techpowerup.com/gpuz/79mv/

I'll probably upgrade my card at some point though as it does get quite hot since it's passively cooled. Max temp after a 25 minute episode was 82 degrees C. But the max operating temp is 105c so not too worried.

[madshi]

The native surface blitting from Y'CbCr to RGB on GPUs have incoherent results. Newer nVidia models force a bilinear filter on doubling the dimensions of the chroma data, which can't be disabled. Older nVidia models, ATi and Intel models don't filter, so the chroma is resized with the nearest neighbor method.
I've recently asked madVR users to run tests for me on their GPUs. The result is that all DX9 NVidia GPUs that have been tested have forced some kind of chroma upsampling with no way to turn it off. On the other hand, with ATI all GPUs have used nearest neighbor when using StretchRect with D3DTEXF_NONE. You can however make ATI GPUs use bilinear chroma upsampling by using D3DTEXF_LINEAR in the NV12 -> RGB StretchRect call.

I'm quite happy with things the way they are now. I can now use D3D tickbox and get MadVR with exclusive mode on secondary display. All menu's and controls appear to function correctly.
Good to hear, thanks for feedback.

[Ger]

@Ger: Thank you for testing. I already thought my changes to the bicubic resizer wouldn't make much of a difference (the output assembly didn't change much). Bicubic resizing in a single pass with the current matrix method is sub-optimal anyway. I hope you have more luck when other two-pass resizing modes are added.

I'm happy as long as A=-1.00 works. I don't remember seeing much of a difference between that and the other two when I was using Nvidia. I don't remember anyone else reporting this issue either, so I don't think it's widespread, so feel free to not worry about it and prioritize other stuff. ;)


I do have some remarks, of course. (I'm in a technical mood/mode today.)
:thanks: for trying. Don't get your hopes up that I will actually understand it though. ;)


Chroma up-sampling is something best left to a custom mixer. The native surface blitting from Y'CbCr to RGB on GPUs have incoherent results. Newer nVidia models force a bilinear filter on doubling the dimensions of the chroma data, which can't be disabled. Older nVidia models, ATi and Intel models don't filter, so the chroma is resized with the nearest neighbor method. Of course, neither forcing bilinear filtering nor skipping filtering is a good solution. However, I can understand that adding a GUI option in the video section of the drivers with a range of chroma resizing filters that range from unfiltered to something like Lanczos256 would be rather much to ask from GPU driver developers.
The only thing I can do at the moment is integrating the shaders I've written in a similar way as the color management and dithering function, making in effect half a mixer. That would work okay as a user-selectable option, but not as an automatic one.
The other (preferred) option would be to discard the EVR and VMR-9 mixer and give the shared renderer part of VMR-9 (renderless) and EVR CP a custom mixer. The hard parts are that I've haven't seen any mixers with a GPL license around, I can't just write one on my own, without months worth of lessons in media handling like this in my spare time and lastly, I wouldn't know a good name for the renderer, as (renderless) and CP are what would remain of the original names.

I'm the one that pushed conversion to RGB32 or RGB24 to the very bottom of the mixer input priority list. All the current decoders are natively NV12, YV12, I420 and YUY2 anyway. With the conversion to RGB32 or RGB24, after having conversion from Y'CbCr to RGB, the resulting floating points are rounded to 8-bit integer. With some luck, there's some dithering involved (that can't be compared to the internal 32²||128² dither maps and randomized dithering methods). Anyway, this kind of conversion is pretty lossy. It's completely unacceptable for any renderer chain to be designed like that.
Conversion to RGB32 or RGB24 before the mixer is just a compatibility option for old GPUs that can't provide any suitable Y'CbCr surfaces for the VMR-9 or EVR mixer that for some reason demand such support.


A lot of this is too technical for me and over my head, because I don't know what goes on inside the renderer or even understand the mixer concept. I still don't quite understand why apparently the old method was bad and the new method is good when only the new method has blocky reds without shaders. I guess for other reasons then.

But let me try to guess/understand from an end-user's perspective, and please let me know if I'm even close to grasping this:

Are you saying that in old unaffected builds, like in 2833 and still in EVR Sync or plain EVR, when the renderer gets NV12 from the decoder (according to pin info) it performs a (high quality) conversion to RGB32 first and uses that for the "mixer input"? And you wanted NV12 mixer input and changed this to prioritize feeding the same NV12 colorspace the renderer gets from the decoder to the mixer in either 2837 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2837) or 2839 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2839) and not in 2863 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2863)? That is why the bad chroma is visible already in r2840?

The "YV12" shader was one of the first I've re-written for MPC-HC (last September). See the OP and the first few posts from the shaders thread for reference.
Obviously if you (re)wrote it you should get credited, and of course I take your word for it. I just said "by Leak" because I think I remember he posted the original in this thread a few years ago because of similar blocky reds with ATI issues. But I'm not even sure I remember that part correctly. I was using Nvidia at the time and didn't really pay attention.


Absolutely all current internal shaders can be replaced by a set I've written (and a selection of a few more). I highly doubt there will be anyone that will deny that the versions I've written are superior. I'll happily defend that statement if someone wants to challenge me.
I have no reason or intention to challenge that. I have only tried a few of your shaders.

The reason I think that particular "YV12" shader is the easiest solution for most people for the time being (which is maybe what you are responding to here?) is that it is embedded already in all builds, and so is easy to use. It fixes the blocky reds in EVR-CP and doesn't break anything (hardly any change at all) if you switch to already "not blocky" EVR Sync or RGB32 (Full/HQ) output from the decoder.

OTOH, if for example I use either of your optimized paths for fp/integer trios of shaders (fixes the blocky reds when present), they will (or at least it did for me) actually cause blocky reds in EVR Sync or with Full/HQ converted RGB32 from the decoder. So we have to remember to switch shaders when we switch settings. Of course if you know/recommend a better shader (or set of shaders) than the YV12 one that doesn't break anything when changing settings/renderers then I'm open to suggestions for my own use, but it will still be to complicated to recommend custom/external shaders for the average ATI/EVR-CP user with blocky reds until they are integrated IMHO.


Advanced deinterlacing methods are not exclusive to ATi hardware. The nVidia and (recent) Intel solutions include those, too. Software deinterlacing has included several advanced methods for more than a decade.
The current GPUs just prefer to do deinterlacing with NV12 input it seems. The deinterlacing capabilities of a GPU can be checked with the DXVAchecker program.

I don't know if that was meant for me as I never said anything different, and I did actually know that already. We have tested with DXVAChecker before. ATI needs NV12 for Vector Adaptive. Nvidia will work with YV12, NV12 and many more for their best "spatial-temporal" method. Not with RGB32 though. None of the software methods in ffdshow look as good as hardware. Yadif2x is pretty good, but has artifacts and increased CPU usage that can make a difference if already decoding by software/CPU. Dscaler ivtc mod is reportedly good for IVTC, but not much use for my interlaced content (which is 99% DVB/PAL).

When your tester builds are used, ATI's hardware deinterlacing with the internal MPEG-2 decoder looks noticeably better than in trunk builds with all of the EVR renderers. :) The decoder is outputting NV12 and not YUY2 as in the trunk builds, so "VectorAdaptiveDevice" (and "MotionAdaptiveDevice") can be used, while YUY2 is restricted to the third best ATI method (AdaptiveDevice). Maybe whatever change you made to accomplish that could be committed sooner than the other stuff, if it's not too integrated with your other features?

[Ger]

I've recently asked madVR users to run tests for me on their GPUs. The result is that all DX9 NVidia GPUs that have been tested have forced some kind of chroma upsampling with no way to turn it off. On the other hand, with ATI all GPUs have used nearest neighbor when using StretchRect with D3DTEXF_NONE. You can however make ATI GPUs use bilinear chroma upsampling by using D3DTEXF_LINEAR in the NV12 -> RGB StretchRect call.

Do you think that will fix the blocky reds in EVR-CP with no manually applied shaders? If it does you all know what my vote is, unless it ruins any significant future plans. ;)

Edit: Maybe something happened here (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/filters/renderer/VideoRenderers/DX9RenderingEngine.cpp?r1=2837&r2=2836&pathrev=2837)?

[pirlouy]

You don't need to run the GUI itself all the time but you need it to be installed and you shouldn't kill it's backgroung processes (AMD External Events Service/Client Module...).

Of course, you can live without it, as you can live without the driver itself but you are only asking for trouble because it is needed for full functionality.
Honestly, I doubt this. CCC is optional, so I really think it's just a GUI. I install it anyway. But I have disabled all services and CCC, and I don't have problems.
Maybe I miss something, and you're right. But it would be cool to know EXACTLY what dependences are.

[mr.duck]

I have some experience with AMDs drivers. DON'T install the CCC and go to services control pannel and block all AMD Radeon related services from loading like external events blah blah. This setup gets best performance/fastest boot times and less problems (like changing AA mode and madVR doesn't work properly won't happen without CCC). I even worked out how to manually edit some of the settings in the registry to turn off all the sh!t video enhancements that ruins picture quality.

[CruNcher]

I've recently asked madVR users to run tests for me on their GPUs. The result is that all DX9 NVidia GPUs that have been tested have forced some kind of chroma upsampling with no way to turn it off. On the other hand, with ATI all GPUs have used nearest neighbor when using StretchRect with D3DTEXF_NONE. You can however make ATI GPUs use bilinear chroma upsampling by using D3DTEXF_LINEAR in the NV12 -> RGB StretchRect call.


Good to hear, thanks for feedback.

I guess you refer to the lossy Surface states in the madnv12test ?, which indeed according to your test just change depending on the Controll Panel settings but stay lossy overall though it might be possible to go deeper via the NVAPI into those settings or ask Nvidia to make them available their though i didn't tried to include madnv12test as a 3D application and change the 3D performance settings for it also the driver was on the default quality level (which is @ application settings though and should have no impact) when i supplied my test results.

1 strange thing for example is this:

Inverse telecine off:

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-235)
D3DFMT_X8R8G8B8: lossy (16-235)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-236)
D3DFMT_A2B10G10R10: lossy (16-236)
D3DFMT_A16B16G16R16: StretchRect failed
D3DFMT_A16B16G16R16F: lossy (16-235)
D3DFMT_A32B32G32R32F: StretchRect failed

D3D9 Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-235)
D3DFMT_X8R8G8B8: lossy (16-235)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-236)
D3DFMT_A2B10G10R10: lossy (16-236)
D3DFMT_A16B16G16R16: lossy (16-235)
D3DFMT_A16B16G16R16F: lossy (16-235)
D3DFMT_A32B32G32R32F: lossy (16-235)

Inverse telecine on:

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-255)
D3DFMT_X8R8G8B8: lossy (16-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-255)
D3DFMT_A2B10G10R10: lossy (16-255)
D3DFMT_A16B16G16R16: StretchRect failed
D3DFMT_A16B16G16R16F: lossy (16-191)
D3DFMT_A32B32G32R32F: StretchRect failed

D3D9 Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-255)
D3DFMT_X8R8G8B8: lossy (16-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-255)
D3DFMT_A2B10G10R10: lossy (16-255)
D3DFMT_A16B16G16R16: lossy (16-255)
D3DFMT_A16B16G16R16F: lossy (16-191)
D3DFMT_A32B32G32R32F: lossy (16-192)

How can this have an impact on chroma in the test, or can results differ per run ?
seems so i just enabled it again and get different results from the two previous ones hehe funny ;)

after reenabling Inverse Telecine:

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-190)
D3DFMT_X8R8G8B8: lossy (16-190)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-191)
D3DFMT_A2B10G10R10: lossy (16-191)
D3DFMT_A16B16G16R16: StretchRect failed
D3DFMT_A16B16G16R16F: lossy (16-178)
D3DFMT_A32B32G32R32F: StretchRect failed

D3D9 Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-190)
D3DFMT_X8R8G8B8: lossy (16-190)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-191)
D3DFMT_A2B10G10R10: lossy (16-191)
D3DFMT_A16B16G16R16: lossy (16-190)
D3DFMT_A16B16G16R16F: lossy (16-178)
D3DFMT_A32B32G32R32F: lossy (16-178)

:) So now the question would be how reliable are these measurements in real, or is Nvidias driver non deterministic ;) ?

[Damien147]

Also tested the chroma upsampling issue (blocky reds (http://i.imgur.com/1k7SI.png)) with that Nvidia laptop and the same monitor connected via HDMI, and it's not affected at all, so that is apparently also (still) an ATI-only issue.

In the meantime the first workaround, the "YV12 chroma upsampling shader", is a quick and easy solution for affected ATI/EVR-CP users.


This is the answer I've been looking.:thanks:

Is this (http://sourceforge.net/apps/trac/mpc-hc/ticket/1120) the patch that changed things?

I'm a noob and I can't understand exactly the description,when using ffdshow for decoding I get nv12 output in mpc-hc.This is intended according to the patch,right?
But when using mpc-hc for decoding on the same video I get rgb32 output with different but bad chroma result:confused:

[madshi]

How can this have an impact on chroma in the test, or can results differ per run ?
seems so i just enabled it again and get different results from the two previous ones hehe funny ;)

:) So now the question would be how reliable are these measurements in real ;) ?
The measurements should reliably show what the StretchRect operation produced. The results are stable with ATI and unstable with NVidia. I don't think it's a bug in madNV12Test. I think it just shows that with NVidia drivers, NV12 -> RGB StretchRect is not always reliable. Which means that madVR for example is never going to use NV12 -> RGB StretchRect with NVidia hardware/drivers.

[CruNcher]

Yep no doubt in that if your measurements are correct then it seems to be not reliable and should be replaced, also a interesting inside look into ATI and Nvidias Video Handling Level some oldshool ATI we are better then Nvidia in Video seems to be still alive deep down in the Driver also seeing some UVD 3 results lately makes me wonder if they didn't back on track also in Video after they run over Nvidia in 3D efficiency ;)

[Ger]

This is the answer I've been looking.:thanks:

Yeah, I think you asked some of the questions I was referring to in that post, so I'm glad it helped.

Regarding your other questions, my tests only show roughly when it happened. I'm no dev either, and I have no idea specifically what change caused it or why it was changed or why it is or isn't a good idea to change it again. That's what I'm trying to ask/understand myself. I'm just testing/reporting and speculating/asking based on the little tidbits I understand.

My theory right now based on what JanW and madshi said is the bilinear filtering vs. nearest neighbor and the changes in r2837, but I'm utterly clueless, so you don't wanna know what my changing theories are all the time. So please ask someone else, or just wait and see how it all develops. ;)

[JanWillem32]

@madshi and CruNcher: StretchRect is in EVR CP and VMR-9 (renderless) as an "all methods failed" backup solution. It disables all further shaders, 10- 16- and 32-bit surfaces, dithering and color management. It's been removed in EVR Sync for a good reason, as the problems with StretchRect are well known.

@Damien147: That's one of my older works. Im my builds I used the format merit list that was already in EVR sync as a base, and expanded the list to include all possible formats that the EVR mixer could accept.
I mostly wrote that patch in the link to eliminate the YV12/I420/IYUV to YUY2 conversion. Doing half chroma up-sampling before the mixer is just dumb. I added conversion to NV12 as a preferred option and set conversion to RGB32 as a backup if that fails.

@Ger: That code in the link was part of my first contribution to the renderer. It was mostly to fix the assignment of surfaces and the 10-bit output mode.
I didn't commit any of the visible shaders in the trunk build. I want to remove all them as a first step, and insert new ones with proper names.
The lack of chroma up-sampling has always been there for those that use NV12 output from external decoders, by the way. It's not that new.
For the problem with RGB32 input: once I figure out how to make message windows, I can add a simple warning message window to indicate that the video stream format in the file doesn't match the input stream of the mixer. (And of course add warnings if items in the renderer fail.)
The reason I don't dare to commit anything at the moment is because I broke the VSync offset function in my build and it's very hard to repair. The code for timing items is complex.

[madshi]

StretchRect is in EVR CP and VMR-9 (renderless) as an "all methods failed" backup solution. It disables all further shaders, 10- 16- and 32-bit surfaces, dithering and color management. It's been removed in EVR Sync for a good reason, as the problems with StretchRect are well known.
What is used instead for the YV12/NV12 -> RGB conversion?

[Ger]

The lack of chroma up-sampling has always been there for those that use NV12 output from external decoders, by the way. It's not that new.


No it's not a problem in r2833 or in EVR Sync when outputting NV12 from ffdshow to the renderer with no manual shaders applied, but it is in r2840. That's what I've been trying to tell you for a while now. It was broken in EVR-CP only, and in that revision range (2834-2840). That's why I'm saying several ATI owners are noticing a regression. That is also why I listed two suspected culprit revisions and maybe especially that last piece of code I linked to.

The situation with YUY2 output from decoder is exactly the same as with NV12. OK in EVR Sync and in old builds. Broken (as in very blocky) in EVR-CP 2840 and up.

It may not be quite as good as madVR or EVR Vanilla in those old builds or in EVR Sync, but it's much much better than EVR-CP in 2840 and later, and not that far away from the other two.

The YV12 shader makes a massive difference when it's broken/blocky and hardly any difference at all when it's already OK. See my previous posts for details on that. Unlike the YV12 shader, your optimized shader path inverts the situation. It makes blocky stuff OK and OK stuff blocky.

You have an ATI card right? Provided all ATI cards behave the same with this issue, which I'm assuming until I'm told otherwise, try feeding NV12 from ffdshow to EVR Sync in any build or to EVR-CP in 2833 (from my uploaded zip or from xvidvideo.ru) and see for yourself with a suitable red logo or something like that.

[v0lt]

@Ger
Bug appeared in version 2837. Here version 2836 and 2837 (http://www.mediafire.com/?6m45dkc837m7k). You can check out.

[Ger]

Thank you v0lt! :)

I confirm 2837 is the culprit. That was the revision I linked to last with the removed/changed stretchrect bilinear filtering stuff madshi was talking about, and one of the two on my first list of suspects.

Finally we're getting somewhere. :)

[JanWillem32]

@madshi: ARGB output is requested from the external EVR/VMR-9 mixer, as far as I can see. Both mixers don't limit or round the outputs, so values beyond the regular [0, 1] interval with floating-point conversions are left intact. The transfer matrix for the conversion is generally selected automatically by EVR. http://msdn.microsoft.com/en-us/library/ms694036%28v=vs.85%29.aspx I expect a similar item will be in VMR-9.

@Ger: http://forum.doom9.org/showthread.php?p=1463132#post1463132 I could also replicate that later on.
EVR sync uses StretchRect (unfortunately I just found that out, it's a bit hidden in the code). I haven't paid much attention to Sync in development. We could use a developer that can help integrate the sync clock into the shared EVR CP/VMR-9 (renderless) renderer where the entire renderer stems from. (And clean up its many flaws in the process.)
I've looked up what the YV12 shader does again. (I haven't looked at it in a while.) It converts an area of 9 pixels with an inaccurate, truncated bt.601 (SD video) matrix and averages all values. My "4÷2÷0 chroma blur for SD&HD video input on old and slow PS 2.0 hardware" shader at least blurs with bilinear filter, using 4 pixels with correct SD and HD color matrices. It indeed hurts quality a lot if the chroma input is filtered with a bilinear filter during color conversion and then filtered again by this type of shaders. (I use "blurring", as "up-sampling" is better reserved for the windowed scalers.)
I very much prefer no filtering to take place by default at all, than having to waste resources on a default or forced bilinear filter on chroma data. Options to up-sample chroma can be added like the regular scaling options. It will need a warning for those with a nVidia card not to enable that option.
Having swscale to convert every input format for the mixer to RGB32 as it was before, would be pretty bad. On low-end CPU's it wasted a lot of processing on the bilinear filtering, RGB conversion and rounding to 8-bit. Output of 10-, 16- or 32-bit color formats is impossible with this method, so the color accuracy also suffers (on top of losing the advanced deinterlacing filters available with NV12 in the mixer).

[madshi]

ARGB output is requested from the external EVR/VMR-9 mixer, as far as I can see.
So basically the conversion from YV12/NV12 to RGB is done by some internal Microsoft EVR/VMR code? So we don't know how it's technically done? Could be StretchRect again?

[JanWillem32]

It could be a modified StretchRect with custom color matrix support or some other interface with the video card's drivers. VMR-9 doesn't take any 4:2:2 formats in my case. Other than that, both mixers use a reasonably well-matching color matrix for both bt.709 and bt.601 automatically with various Y'CbCr inputs.

[madshi]

Ok, thanks, that's good to know.

[Casshern]

Hi Ger,

this behavior is intentional - before 2840 everything was converted to RGB32 before giving it to the mixer. This was probably done to avoid a lot of incompatibilites and had the advantage that the software routine used did some sort of chroma upsampling. This has been removed by Janwillem so that the mixer gets what the decoder outputs, you are now at the mercy of your videocard driver. Unfortunately AMDs driver do not upsample chroma. Another drawback is that you cannot use any Catalyst before 10.11 with the new MPC HC versions, which is extremely annoying as newer versions have the dreaded 99% load bug and the mouse lag bug. I can see where Janwillem is headed and agree with his goals and thank him for his efforts - but he could have left the RGB32 conversion as an option -> that would have made everybody happy.


No it's not a problem in r2833 or in EVR Sync when outputting NV12 from ffdshow to the renderer with no manual shaders applied, but it is in r2840. That's what I've been trying to tell you for a while now. It was broken in EVR-CP only, and in that revision range (2834-2840). That's why I'm saying several ATI owners are noticing a regression. That is also why I listed two suspected culprit revisions and maybe especially that last piece of code I linked to.

The situation with YUY2 output from decoder is exactly the same as with NV12. OK in EVR Sync and in old builds. Broken (as in very blocky) in EVR-CP 2840 and up.

It may not be quite as good as madVR or EVR Vanilla in those old builds or in EVR Sync, but it's much much better than EVR-CP in 2840 and later, and not that far away from the other two.

The YV12 shader makes a massive difference when it's broken/blocky and hardly any difference at all when it's already OK. See my previous posts for details on that. Unlike the YV12 shader, your optimized shader path inverts the situation. It makes blocky stuff OK and OK stuff blocky.

You have an ATI card right? Provided all ATI cards behave the same with this issue, which I'm assuming until I'm told otherwise, try feeding NV12 from ffdshow to EVR Sync in any build or to EVR-CP in 2833 (from my uploaded zip or from xvidvideo.ru) and see for yourself with a suitable red logo or something like that.

[Ger]

StretchRect is in EVR CP and VMR-9 (renderless) as an "all methods failed" backup solution. It disables all further shaders
That can't be true if EVR Sync is using it and EVR-CP was in r2836, since shaders are working in both cases.


10- 16- and 32-bit surfaces

OK, I'll buy that since I can get the 10-bit backbuffer in 2836, but only 8-bit surface. In 2837 I can get 10 and 16-bit surface. However, whatever quality improvement that is supposed to give it's negligible compared to the quality drop from 2836 to 2837 with no shaders. Out of all these new options, that is the really noticeable one, and it's in the wrong direction. Fortunately a shader can save the day for those who are lucky enough to know about it.


dithering


The option is only there in your builds and not in EVR Sync, so I wouldn't know, and I don't understand what what it does really. I was never able to see the difference anyway (not that I looked that hard or compared screenshots or anything). But dithering is apparently better than rounding for audio and I guess that applies to video as well, so I guess I'll have to believe that. Which dithering method do you recommend for general use? I used the static ordered one since it was selected by resetting the settings.


color management

Seems to work for me in 2836. Colors are less bright with it enabled, just like when it's enabled in your recent tester builds. I have no idea how "correct" it is, nor do I care as long as it looks vaguely acceptable to the naked eye, but there is a difference in 2836 with it on/off, that's for sure.


Having swscale to convert every input format for the mixer to RGB32 as it was before, would be pretty bad. On low-end CPU's it wasted a lot of processing on the bilinear filtering, RGB conversion and rounding to 8-bit.
CPU is hardly an issue. tetsou55 has said something along the lines of more than 5-year old CPUs not being supported officially, or non-SSE2. My CPU is actually 5 years old, and the difference between 2836 and 2837 is very small in terms of CPU use.

Output of 10-, 16- or 32-bit color formats is impossible with this method, so the color accuracy also suffers

Well, personally I couldn't care less about color accuracy as long as the colors seem subjectively reasonable to me. The average user certainly isn't calibrating his display, or even aware of what panel he's got. But I understand that people who are really interested in this stuff want accurate colors, so point taken.


@Damien147: That's one of my older works. Im my builds I used the format merit list that was already in EVR sync as a base, and expanded the list to include all possible formats that the EVR mixer could accept.
I mostly wrote that patch in the link to eliminate the YV12/I420/IYUV to YUY2 conversion. Doing half chroma up-sampling before the mixer is just dumb. I added conversion to NV12 as a preferred option and set conversion to RGB32 as a backup if that fails.
The internal software decoders are still doing that in current trunk builds though, by preferring YUY2. But other/external decoders are OK (or internal in your tester builds and the main decoder in bobdynlan's swscaler mod).


EVR sync uses StretchRect (unfortunately I just found that out, it's a bit hidden in the code). I haven't paid much attention to Sync in development. We could use a developer that can help integrate the sync clock into the shared EVR CP/VMR-9 (renderless) renderer where the entire renderer stems from. (And clean up its many flaws in the process.)

The reason I don't dare to commit anything at the moment is because I broke the VSync offset function in my build and it's very hard to repair. The code for timing items is complex.

OK. Thanks for the info. Does the broken vsync in your builds apply only to "Alternative Vsync" as you mentioned before, or to all vsync code in EVR-CP? Also, all vsync options in EVR Sync are untouched and OK right?

When/if EVR Sync and EVR-CP are merged, please keep as many vsync options as you can. EVR Sync with Sync Video to Display (http://www.ostrogothia.com/?page_id=1216) inserts a SyncClock filter and the audio renderer shows slaving info "graph clock" and works differently from all the other options. Even though it probably has other disadvantages, this is the only option that never freezes the picture on seek for me, so it's nice to keep the options, at least for debugging and working around such issues.

My other major issue with EVR-CP's vsync was hopefully fixed in r3009 thanks to Aleksoid.

Beliyaal who's behind most of the vsync code in EVR-CP seems to have moved on to other things, but the vsync code in EVR Sync was written by ar-jar/Arto well after the Beliyaal EVR-CP code because he wasn't quite happy with how EVR-CP did it, I guess. But when Arto upgraded from XP to Win7 his tearing issues were solved by Aero anyway, so he didn't see the point in working on EVR Sync anymore. At least that's how I understood his blog at the time. The point to all this is that maybe Arto would be willing to help out with problematic vsync issues if you ask him. At least he's answered questions on his blog not so long ago, and he seems to understand vsync stuff very well. The last sentence in his last blog post (http://www.ostrogothia.com/?p=1884) indicates he may be at least somewhat interested in working on OSS again.


I've looked up what the YV12 shader does again. (I haven't looked at it in a while.) It converts an area of 9 pixels with an inaccurate, truncated bt.601 (SD video) matrix and averages all values. My "4÷2÷0 chroma blur for SD&HD video input on old and slow PS 2.0 hardware" shader at least blurs with bilinear filter, using 4 pixels with correct SD and HD color matrices. It indeed hurts quality a lot if the chroma input is filtered with a bilinear filter during color conversion and then filtered again by this type of shaders. (I use "blurring", as "up-sampling" is better reserved for the windowed scalers.)

When I try to compile that shader with PS 2.0 or 3.0 I get:
C:\Windows\system32\memory(27,47): error X1516: not enough actual parameters for macro 'sp'
C:\Windows\system32\memory(27,47): error X3000: unrecognized identifier 'sp'

So again, is there another/better shader than the YV12 one that you can recommend that doesn't break anything with filtered (as in not more than adding a slight almost unnoticeable blur like the YV12 shader) or unfiltered chroma, any source res, any display res and any surface type? If not, then I'll stick with the YV12 shader for now.


I very much prefer no filtering to take place by default at all, than having to waste resources on a default or forced bilinear filter on chroma data. Options to up-sample chroma can be added like the regular scaling options. It will need a warning for those with a nVidia card not to enable that option.


So this would work like an embedded/automatic shader, right? This would be like enabling the YV12 shader (or something similar that works reasonable for all surfaces/filtered/unfiltered/resolutions) for ATI users, only from the options like the scalers? If so can it be enabled by default when an ATI card is detected, so the user doesn't have to know about the option and won't get bad chroma if unaware of this issue?

(on top of losing the advanced deinterlacing filters available with NV12 in the mixer).

This can't be true either. Hardware deinterlacing works just fine in EVR Sync and in r2836. I've been using it for years. Feed NV12 from ffdshow and get great quality VectorAdaptiveDevice with ATI. Feed YUY2 and get the third best AdaptiveDevice (still ATI). Nvidia would probably yield similar quality (unnamed spatial-temporal) for both of those colorspaces. Feed RGB32 from ffdshow and get no deinterlacing at all (ProgressiveDevice). You can check this for yourself with ffdshow, and change the flags (auto, force bob, weave) and field order on the fly, and see the visual difference immediately. It matches the results in DXVAChecker where you can see directly the deinterlacing device/method that is used.

Hi Ger,

this behavior is intentional - before 2840 everything was converted to RGB32 before giving it to the mixer. This was probably done to avoid a lot of incompatibilites and had the advantage that the software routine used did some sort of chroma upsampling. This has been removed by Janwillem so that the mixer gets what the decoder outputs, you are now at the mercy of your videocard driver. Unfortunately AMDs driver do not upsample chroma. Another drawback is that you cannot use any Catalyst before 10.11 with the new MPC HC versions, which is extremely annoying as newer versions have the dreaded 99% load bug and the mouse lag bug. I can see where Janwillem is headed and agree with his goals and thank him for his efforts - but he could have left the RGB32 conversion as an option -> that would have made everybody happy.

I guess we roughly agree then.

If we ignore the problem with old drivers for a moment, and it turns out he can add an automatic shader for ATI to fix the issue rather than having to revert to the old filtering, then that is maybe better, since 10-bit and higher surfaces can be used by those who care. Maybe even by me if I don't notice any downside (I've been running HFPP in JanW's builds lately with no issues - with FFPP and color management the GPU clocks increase though which I'm not interested in). I don't mind enabling something that's supposed to improve stuff according to more knowledgeable people, whether it's actually noticeable to me or not. Maybe I can get a placebo effect out of it at the very least. ;)

I still don't understand the above deinterlacing issue though. Why is hw deinterlacing only dependent on what the decoder outputs to the renderer, and not what the mixer gets internally if the deinterlacing happens in the mixer like JanW says, and the mixer gets RBG32 in old builds/EVR Sync. :confused:


@bobdynlan
Some feedback for your swscaler mod (running 3011 Black Edition at the moment):

Since JanW's changes seem to be some time away from making it to the trunk, any chance the options you added to the main decoder can be added to the MPEG-2 one as well? That's were I could really use those options. I'm especially interested in getting NV12 output for hardware deinterlacing (triggers better quality vector adaptive on ATI). The rest of the new options aren't that important to me, since there are other ways to work around the chroma thing.

Support for 4:2:2 sources and controllable hw deint flags like ffdshow has would be nice as well, since ffdshow also has some issues with LAV Splitter (crash on seek with libmpeg2 and chokes on DVB subtitles with both libmpeg2 and libavcodec) that aren't there in the MPC-HC internal libmpeg2 based decoder. But I guess that's not really related to what you've been doing.

Moving on from the wishes; I see the exact same behavior you described in the readme. Everything seems to work as intended, and I hope it will be committed.

I'm also very pleased to hear you're still planning to resurrect the GUI project. :thanks:

I suggest you start your own thread when it's ready for testing again though, specifically four your builds, so it hopefully doesn't get bogged down with endless unrelated general GUI discussions, like in the old GUI thread that was eventually locked.

[clsid]

I understand that a goal is to make MPC output the highest possible quality, but that should not make MPC worse/unusable for a large part of the user base. Everything that requires the use of shaders or other hardware dependent stuff should be optional, meaning that a shader shouldn't be used to fix something that used to work (reasonably) fine in the past without shaders. MPC should continue to work on older hardware.

I will repeat again what I said some time ago: it is unacceptable to force people to update to a specific new driver to be able to use (recent builds of) MPC. Not everyone is a nerd that hangs out at Doom9. Most users are barely able to install basic software, let alone update a driver. Moreover, with older hardware it often isn't even possible to update a driver.

If unconditionally reverting part of the changes from 2837 isn't possible due to new functionality, then the old behavior could be used conditionally. Here is some pseudocode:

bool useOldMixer() {
// check graphics card brand and driver version, return True if they are incompatible with new mixer implementation
// see DXVA compatiblity check for code that does a similar check
}

also add a hidden option "forceOldMixer" for testing purposes to manually force usage of the old mixer behavior.

if(forceOldMixer || useOldMixer) {
// old mixer behavior
} else {
// new mixer behavior
}Is there a list of OS/hardware/drivers that are known to fail (black screen) or give crap output?

The function useOldMixer() could just return false initially, and we can adapt it along the way based on bug reports.

[fastplayer]

rev3006 broke play/pause via left-click when hiding the menu.

[v0lt]

I propose to make a DirectShow mode the default for MOV-files (instead of QuickTime).
What do you think about this?

[v0lt]

rev3006 broke play/pause via left-click when hiding the menu.
I have works fine.

[fastplayer]

I have works fine.
It doesn't work for me, neither in XP or 7. It only does when the menu is not hidden.

[v0lt]

@fastplayer
I see a bug when there is only a frame and caption. Then operate as a "frame only" and "hide borders" (the mouse is used to move the window). It is wrong for "hide menu" mode. I'll see what can be done.
Thanks.

[Mercury_22]

It doesn't work for me, neither in XP or 7. It only does when the menu is not hidden.

Change your mouse PLAY/PAUSE key (to Middle Down)

[Ger]

I propose to make a DirectShow mode the default for MOV-files (instead of QuickTime).
What do you think about this?

I always set both QT and Real to DirectShow anyway (after installing QT Lite and RA) to get the OSD working, and most stuff I try seem to work for me, so I vote yes.

I don't know what (if any) the negative consequences are though, as I don't play much of that material.

Maybe clsid can comment, as I suspect he knows quite a bit about that stuff.

[v0lt]

@fastplayer
r3015: fixed play/pause via left-click when hiding the menu

I always set both QT and Real to DirectShow anyway (after installing QT Lite and RA) to get the OSD working, and most stuff I try seem to work for me, so I vote yes.

I don't know what (if any) the negative consequences are though, as I don't play much of that material.

Maybe clsid can comment, as I suspect he knows quite a bit about that stuff.
There may be problems with very old MOVs. But these files are very rare.

[clsid]

There is probably still stuff that is only playable using QuickTime, but with the recent improvements to the MP4/MOV splitter and the internal audio decoder, most MOV files should be playable with DirectShow. For example 3G2 on the other hand still requires QT.

The current framework selection on the formats page is not very flexible. It is currently also only not very obvious to end-users what the settings do and where to find them. I would suggest adding a new configuration page specifically for the frameworks and removing the dropdowns from the formats page. Something like this:

Options -> Playback-> Frameworks
[x] Use QuickTime framework for: [mov 3g2 3gp2 m4b] [RESETBUTTON]
[x] Use RealMedia framework for: [ra rm ram rt rv rmm] [RESETBUTTON]
So a checkbox for enabling use of a framework. A textbox with a list of file extensions. And a reset button to reset the list of extensions to internal defaults.
Shockwave (.swf) can simply be hardcoded internally.
The RTSP options from the Formats page can be moved to the new page as well.


The file extensions on the formats page also seem to be misused in other parts of the code that are unrelated to file associations. For example in the playlist code (to determine which files in a directory are media files). I suggest to add (four) dedicated internal lists of file extensions for that purpose (video, audio, image, playlist). Might also be a bit quicker than current code.

Once there is no longer any unrelated code depending on the lists on the Formats page, it becomes easier to rewrite the file associations code as well. Something I might do in the future.

[Ger]

A related wish that would make things a bit easier to configure: I'd like to see .mpcpl separated from the other playlists in formats. I always edit out all other playlist extensions from there, in order to use .mpcpl with MPC-HC, .m3u with audio players, .asx with WMP etc. Maybe adding a MPC-specific files (or MPC-specific playlists etc. if that's needed) category, like VLC does, and putting it there. MPC-specific extensions should be enabled by default I guess. I don't know if there are more of them.

[JanWillem32]

A small note on the on the chroma item:
We are discussing EVR CP, as I didn't change the status for VMR-9 (renderless) that never used the RGB32 conversions before the mixer. That means that VMR-9 (renderless) (on 3D surfaces mode) has always been with unfiltered chroma on all hardware, except recent nVidia GPUs.

@Casshern: In my builds I solved compatibility with older ATi drivers by adding conversions to NV12 as an option. It's not in the trunk build yet. RGB conversion before the mixer is still available for GPUs with compatibility problems with Y'CbCr surfaces. I hope that with updating swscale this conversion is fixed with more accurate options, as currently even SD and HD video color matrices are not passed to the convertor properly, along with other flaws.

That can't be true if EVR Sync is using it and EVR-CP was in r2836, since shaders are working in both cases.As far as I can see, EVR CP can't use StretchRect at all, that part of the code is reserved for VMR-9 (renderless) with the 2D surfaces mode. That's what disables shaders.
OK, I'll buy that since I can get the 10-bit backbuffer in 2836, but only 8-bit surface. In 2837 I can get 10 and 16-bit surface. However, whatever quality improvement that is supposed to give it's negligible compared to the quality drop from 2836 to 2837 with no shaders. Out of all these new options, that is the really noticeable one, and it's in the wrong direction. Fortunately a shader can save the day for those who are lucky enough to know about it.I believe it's one of the steps in the right direction. Trunk builds are meant for changing functions. Many updates are often required to make a large thing as a graphics engine to work properly.
For improving things, I've looked up the possibility of integrating a custom mixer to solve the chroma problem, along with other things. Note that I also consider the forced bilinear filter on nVidia hardware a problem.
The option is only there in your builds and not in EVR Sync, so I wouldn't know, and I don't understand what what it does really. I was never able to see the difference anyway (not that I looked that hard or compared screenshots or anything). But dithering is apparently better than rounding for audio and I guess that applies to video as well, so I guess I'll have to believe that. Which dithering method do you recommend for general use? I used the static ordered one since it was selected by resetting the settings.http://en.wikipedia.org/wiki/Dither It contains some very good images in the middle to bottom part of the page. Static ordered dithering used to be activated automatically with 10- and 16-bit surfaces. I only made it optional. The test mode is quite useful to see how a dithering mode works internally.
Static ordered dithering is the lightest option of three modes, so that's why it's in the "Optimal" profile. The random ordered method reduces the risk of creating visible patterns on plain surfaces and light gradients, but it's heavier due to the random turning, flipping and moving the position of the dither maps separately for red, green and blue. Both methods use a dithermap of 128² for FFPP and 32² for other modes. The random ditherer creates heavier (semi-random) noise and has no sampled map. It's mostly to provide a different type of post-processing.
There's no absolutely perfect option, people should just choose what type of dithering they can live with, as it will always generate noise.
Seems to work for me in 2836. Colors are less bright with it enabled, just like when it's enabled in your recent tester builds. I have no idea how "correct" it is, nor do I care as long as it looks vaguely acceptable to the naked eye, but there is a difference in 2836 with it on/off, that's for sure.Color management is for calibrated display devices with a .ICM profile installed system-wide. It's used to provide exact color matching of the rendered picture to the display device. For regular adjustments, the color control shaders can be used. I hope to integrate those in a while, since only the VMR-9 (windowed) renderer has color controls at the moment.
CPU is hardly an issue. tetsou55 has said something along the lines of more than 5-year old CPUs not being supported officially, or non-SSE2. My CPU is actually 5 years old, and the difference between 2836 and 2837 is very small in terms of CPU use.There are plenty of recent low-powered systems that really couldn't use EVR CP with software decoding of the 1080i/30 sample, but were fine with VMR-9 (renderless). It's still not completely even, unfortunately. Even when assuming that all CPUs have a lot more CPU power than those systems, there's currently no excuse for MPC-HC on default settings to be so much more CPU intensive than WMP12. There's a lot more optimizing in the code to do.
OK. Thanks for the info. Does the broken vsync in your builds apply only to "Alternative Vsync" as you mentioned before, or to all vsync code in EVR-CP? Also, all vsync options in EVR Sync are untouched and OK right?The main problem is the VSync offset function that's stuck at 0 internally. It doesn't matter if you don't use it anyway.
The other problem is pulldown. The EVR mixer can assist in dropping fake/duplicated frames in a 3:2 or other pull-down scheme, but the allocator-presenter is counting those frames as error frame drops, so it tries to purge and re-sync the mixer to try to correct it. That interrupts smooth playback, of course.
The last problem is the many conversions with integers, floats and doubles of the 100 nanosecond unit formats and the 1 second unit formats in the synchronization threads. A difficult programming problem, as it's mostly due to rounding issues in between synchronization items that are hard to trace.
Beliyaal who's behind most of the vsync code in EVR-CP seems to have moved on to other things, but the vsync code in EVR Sync was written by ar-jar/Arto well after the Beliyaal EVR-CP code because he wasn't quite happy with how EVR-CP did it, I guess. But when Arto upgraded from XP to Win7 his tearing issues were solved by Aero anyway, so he didn't see the point in working on EVR Sync anymore. At least that's how I understood his blog at the time. The point to all this is that maybe Arto would be willing to help out with problematic vsync issues if you ask him. At least he's answered questions on his blog not so long ago, and he seems to understand vsync stuff very well. The last sentence in his last blog post (http://www.ostrogothia.com/?p=1884) indicates he may be at least somewhat interested in working on OSS again.Thank you, I'll see if the management can convince him.
When I try to compile that shader with PS 2.0 or 3.0 I get:
C:\Windows\system32\memory(27,47): error X1516: not enough actual parameters for macro 'sp'
C:\Windows\system32\memory(27,47): error X3000: unrecognized identifier 'sp'
So again, is there another/better shader than the YV12 one that you can recommend that doesn't break anything with filtered (as in not more than adding a slight almost unnoticeable blur like the YV12 shader) or unfiltered chroma, any source res, any display res and any surface type? If not, then I'll stick with the YV12 shader for now.Over-filtering will always reduce quality and performance. I used to have a red-on black letter comparison picture in the OP between the YV12 shader and my very succesful first attempts to do it better.
The chroma blur shader requires a correction of "n" to "n.x, n.y". I probably forgot to test it after cleaning up some code. It's difficult to keep track of the currently 131 different shaders. That shader isn't the most popular item, anyway.
So this would work like an embedded/automatic shader, right? This would be like enabling the YV12 shader (or something similar that works reasonable for all surfaces/filtered/unfiltered/resolutions) for ATI users, only from the options like the scalers? If so can it be enabled by default when an ATI card is detected, so the user doesn't have to know about the option and won't get bad chroma if unaware of this issue?It's a back-up plan, but integrating the up-sampling and maybe chroma blur shaders with automatic switching for HD, SD, 4:2:0, 4:2:2 and 4:4:4 modes like the dithering function should be quite easy. The the EVR and VMR-9 mixer compatibility code can tell the renderer what format is being used.
Intel GPUs also skip chroma filtering by default, so there are 2 GPU brands to detect. I've never done this type of detection before, so I'll have to see if we can get that to work.
This can't be true either. Hardware deinterlacing works just fine in EVR Sync and in r2836. I've been using it for years. Feed NV12 from ffdshow and get great quality VectorAdaptiveDevice with ATI. Feed YUY2 and get the third best AdaptiveDevice (still ATI). Nvidia would probably yield similar quality (unnamed spatial-temporal) for both of those colorspaces. Feed RGB32 from ffdshow and get no deinterlacing at all (ProgressiveDevice). You can check this for yourself with ffdshow, and change the flags (auto, force bob, weave) and field order on the fly, and see the visual difference immediately. It matches the results in DXVAChecker where you can see directly the deinterlacing device/method that is used.I could never get external Y'CbCr input from ffdshow to up-sample in VMR-9 (renderless) and EVR CP without shaders. I had the same results as the pictures in the link of my earlier post.

[v0lt]

@clsid
I had similar ideas.

[fastplayer]

@fastplayer
r3015: fixed play/pause via left-click when hiding the menu
Confirmed. :thanks:

[tetsuo55]

@clsid
I had similar ideas.Ok then, you can go ahead and change it.


@Clsid: Can you give me an overview of everything you would like to see changed in mpc-hc?
As our biggest reseller you should have a bit more influence on future developments ;)

Maybe you could share your vision for ffdshow too? (but in its own thread)

[clsid]

@tetsuo55
Some ideas for MPC:
- Framework page (see discussion above)
- Remove dependencies of other code on Formats page (see above)
- Change Formats page name to File Associations
- Don't use groups of file extensions, but simple lists of individual file extensions. Use three lists: video, audio, playlist/other. This will simplify the file association code as well.
- Add file association options to installer, also create required reg keys for using the "Default Programs" functionality in Windows. I can do that one day if nobody else beats me to it.
- Improve file association code. Also separate for x86/x64.

- Move internal filters outside of the executable into a configurable location (subfolder by default). They will still be loaded without needing to be registered, so portability is kept intact. This was discussed yesterday in the LAVSplitter topic. Nevcairiel also likes that idea and it is even a requirement for easy integration for his filters.

- Automate the Frame Time Correction workaround. Detect when it is needed and apply it automatically.

- Unify the audio/sub stream selection. Always put it under the Play menu. Now its also under Navigate sometimes.

- Add an "enqueue" option to the playlist right-click menu for adding files.

- Don't dock the Playlist window (and other child windows) inside the MPC window, but let it dock to the sides of the main window. For example Winamp does that too.

- Add flip horizontal/vertical functions to View->Video Frame. Basically PnS rotate 180 degrees. (see Player->Keys). Could for example be mapped to Alt+numpad7/9.

- Separate settings for x86 and x64 builds.

- Only use the animated code paths in the subtitle renderer for formats that are actually animated. Should give nice performance boost.

There are just a few ideas from the top of my head. Most changes are relatively small and should therefore be doable for any dev that is willing to spend some time on MPC.

[madshi]

- Move internal filters outside of the executable into a configurable location (subfolder by default). They will still be loaded without needing to be registered, so portability is kept intact.
Yes, please.

The big question is if there are any devs willing to do these changes. They won't happen just by us wishing them to.

[tetsuo55]

Yes, please.

The big question is if there are any devs willing to do these changes. They won't happen just by us wishing them to.It's true that developers are scarce, but it does help to have a clear to-do list from which people who would like to work on mpc-hc can choose from.

[clsid]

nevcairiel might be willing to do that as it will allow integration of his splitters.

[mr.duck]

nevcairiel might be willing to do that as it will allow integration of his splitters.

That would be excellent. A very good idea IMO.

[Dstruct]

- Don't dock the Playlist window (and other child windows) inside the MPC window, but let it dock to the sides of the main window. For example Winamp does that too.

I prefer current MPC docking behaviour over Winamp's!

[Casshern]

@Casshern: In my builds I solved compatibility with older ATi drivers by adding conversions to NV12 as an option. It's not in the trunk build yet. RGB conversion before the mixer is still available for GPUs with compatibility problems with Y'CbCr surfaces. I hope that with updating swscale this conversion is fixed with more accurate options, as currently even SD and HD video color matrices are not passed to the convertor properly, along with other flaws.

Thanks!!!!!

[SamuriHL]

I'm very much in favor of the proposed changes, as well. Not that my opinion matters at all but I think moving the filters out of the exe should be a top priority so that people can "integrate" the filters they want to use and remove the ones they don't. Just a thought. :-)

[bobdynlan]

Just a personal concern - such drastic change from an all-in-one solution can be a killer blow to the project. At the very least, it should be backed up by some analysis - maybe alexins is able to help with that looking at xvidvideo.ru traffic. I'm willing to bet most people use the standalone exe and not only that, they also "clean up" translation and icons dll's...

Anyway, pushing this as the only way to integrate LAVF filters sounds like taking the easy route... but the outcome may not help MPC-HC.

[madshi]

Just a personal concern - such drastic change from an all-in-one solution can be a killer blow to the project.
?? In what way would it be any different to what we have now? Functionality would be *exactly* the same. It would still be an all-in-one solution in that sense that you download one package, don't have to install anything and it all just works. The only difference would be that it's not all in the exe, but in different files. But let's really SO unimportant.

[SamuriHL]

?? In what way would it be any different to what we have now? Functionality would be *exactly* the same. It would still be an all-in-one solution in that sense that you download one package, don't have to install anything and it all just works. The only difference would be that it's not all in the exe, but in different files. But let's really SO unimportant.

Exactly. The implementation details that were outlined in the LAV Splitter thread basically suggest that the filters used don't have to be registered, which means it can still be a very portable instance. This gives you more control over what to add/remove, not less. This should be seen as good news to those who don't want clutter on their machines.

[bobdynlan]

You can't argue about the massive loss of portability - that is to just drag and drop the exe anywhere and it still works as intended. I hope I'm wrong to think that many users praise not only MPC-HC's spartan looks... but also the fact that it's a true portable application. You take that away, you may cut it's wings over the competition.

I do agree it helps developers, but I'm just worried about the consequences on the long run.

[madshi]

So you have to drag&drop a folder instead of a file. What's the big problem?

[SamuriHL]

Yea, maybe I'm missing the point, as well. MPC-HC's portable power isn't in that it's a single exe...it's that it can be moved to any machine by dragging it and dropping it. I'm with madshi on this, what's the real difference between dragging and dropping a single file or a folder? :confused: I mean sure, a single exe's fine and all, but, that's not really what gives it "portability".

[nevcairiel]

Portable just means you can use it without installation, and settings are stored with the application, and not in the registry or in %USERDATA%. Considering most systems also don't have the D3D libraries required, you can even only use it partially in that capacity. I agree with the others here, i see no difference if its a .exe or a .exe with a handful of dlls/.ax files.

And before anyone says that i'm biased and all, personally, i don't care if LAV Splitter gets ever integrated. It'll probably cause so many issues and whining users, that i would rather not see it happen and keep it hidden and me happy, and leave time for working on new features. :P
But one thing is true, i will never modify LAV Splitter or LAV Audio to work as an embedded component, or with embedded ffmpeg, just because i do believe this is just BS, also because static linking on windows is really a bad thing to do.

[mr.duck]

I do agree it helps developers, but I'm just worried about the consequences on the long run.

Over reacting much? Anyway, you have to have the exe and settings ini file at the minimum for true portability so your argument falls down right there.

[bobdynlan]

Over reacting much? Anyway, you have to have the exe and settings ini file at the minimum for true portability so your argument falls down right there.Don't mind me, I'm just a SinaTM copycat :) BS or not there must be people that think that way and you will not find those among the doom9 members...
But you should just stop now and read nevcairiel response again, it pretty much cleared up this matter, if you want to add something useful it should be about how you can help to make this happen sooner, clsid pointed out some directions. Thank you.

[mr.duck]

if you want to add something useful it should be about how you can help to make this happen sooner
My way is to gently nag people that can do it...

nevcairiel might be willing to do that as it will allow integration of his splitters.

nevcairiel, ;) pretty please! :p

Imagine it... out of the box LAVSplitter goodness :)

[v0lt]

@clsid
Don't use groups of file extensions, but simple lists of individual file extensions.
I propose to make a tree.
http://i.imgur.com/93xwD.png
(this is an example for illustration)
Only I never did this in C++. :)

[clsid]

@v0lt
Looks good ;)
I think adding the leading dot to the extensions might look better. But that is just a cosmetic nitpick and personal taste.

The group names are currently also used as description for the file associations. Those descriptions could be moved to an internal list op tuples (extension+description).

The Video/Audio/All buttons are also not needed anymore with your tree list.

[v0lt]

@clsid
But to draw a working tree is difficult for me. Now I do not so much time.

Firstly it may be worth split window "Formats" on two ("File Associations" and ?). Or should not do this?

[clsid]

Every step towards the desired end result is welcome.
You probably mean first splitting into "File Associations" and the "Frameworks" pages.

[clsid]

@Casshern: In my builds I solved compatibility with older ATi drivers by adding conversions to NV12 as an option. It's not in the trunk build yet.Can you commit that fix?

[v0lt]

@clsid
I do not understand the appointment of "Frameworks" page. What do you mean "Frameworks"?

I found it (http://forum.doom9.org/showthread.php?p=1490068&highlight=Framework+page#post1490068) now I read more closely.

[pirlouy]

I'm just a SinaTM copycat :) Ahah ! No, he is unique ! :D

I fully agree Clsid's ideas (useless surely, but all these support may motivate someone).

[SamuriHL]

Help Please!

Failed to query the needed interfaces for playback.

What the hell is that? My main HTPC just ran into this tonight. It's been running absolutely fine until I turned it on a little while ago and tried to play an h.264 MKV. *NOTHING* plays. I've tried simplifying everything and using the internal filters/splitter. Same error. I've reinstalled DX. Same error. What is going on with this? The only thing I could find is some nonsense about DVD and qdvd.dll not being registered. This ain't no DVD problem. It won't play *ANYTHING*. :(

EDIT: Well, this sucks. It doesn't appear limited to MPC-HC. Something is BADLY corrupted on my main HTPC. Not even TMT5 will play *ANY* video. If anyone has any bright ideas I'm all open to them. Otherwise I'm looking at a reinstall of that machine and THAT is not a pleasant thought. :mad:

[noee]

Try uninstalling then sweep your video driver, then reinstall.

[SamuriHL]

I did. No help at all. PDVD, TMT, MPC-HC...all told me to go away. Doing an upgrade install over the top of my install (don't ask). If that doesn't fix it, that machine is going to need the grace of God to save it from me. :) The Samuri in my name wasn't chosen for no reason. I have a katana hanging on my wall. :D Seriously, though, I'm gonna give it a pseudo clean install (if you've never done this, basically it lays down a clean W7 install and then sucks in your settings and programs...you lose windows updates and any drivers you had installed but all programs and settings are retained) and see if that fixes it. If not, a FULL clean install. I have NO IDEA what happened. I didn't install anything from the time it was working to when it decided not to. sigh.

[fairchild]

I did. No help at all. PDVD, TMT, MPC-HC...all told me to go away. Doing an upgrade install over the top of my install (don't ask). If that doesn't fix it, that machine is going to need the grace of God to save it from me. :) The Samuri in my name wasn't chosen for no reason. I have a katana hanging on my wall. :D Seriously, though, I'm gonna give it a pseudo clean install (if you've never done this, basically it lays down a clean W7 install and then sucks in your settings and programs...you lose windows updates and any drivers you had installed but all programs and settings are retained) and see if that fixes it. If not, a FULL clean install. I have NO IDEA what happened. I didn't install anything from the time it was working to when it decided not to. sigh.

Try running the legacy MPC in a different folder, set it up a bit (choose renderer, decoders, etc how you want to run it). If it runs (and it does for me even when mpc-hc was broken for me), then try running mpc-hc. I don't know what it does, but it fixes my registry somehow and allows me to get mpc-hc working again.

http://www.free-codecs.com/media_player_classic_download.htm

Again, this fixed my problems that I was having a while back where I could get MPC-HC 64-bit to work as well as PotPlayer 32-bit/64-bit but couldn't get MPC-HC 32-bit to work.

The exact one I got was mplayerc_20100214.zip

[SamuriHL]

Try running the legacy MPC in a different folder, set it up a bit (choose renderer, decoders, etc how you want to run it). If it runs (and it does for me even when mpc-hc was broken for me), then try running mpc-hc. I don't know what it does, but it fixes my registry somehow and allows me to get mpc-hc working again.

http://www.free-codecs.com/media_player_classic_download.htm

Again, this fixed my problems that I was having a while back where I could get MPC-HC 64-bit to work as well as PotPlayer 32-bit/64-bit but couldn't get MPC-HC 32-bit to work.

The exact one I got was mplayerc_20100214.zip

Fascinating. A bit late now as my upgrade install is running but that's one I didn't try. I have legacy mpc in my tools dir and didn't think to run that one. I mean, I tried it all...they were all busted. You're right, though...HAS to be some kind of registry corruption. Oh well. I'm hoping this issue will go away shortly. I wanted to run some tests on madVR with the Cyberlink HAM decoder. So I compiled the latest LAV Splitter and MPC-HC code (3017), installed them on my HTPC, and went to try running it. BOOM. No idea what caused it. I just want it back as that's my main video machine! VERY VERY bad.

[clsid]

@clsid
I do not understand the appointment of "Frameworks" page. What do you mean "Frameworks"?

I found it (http://forum.doom9.org/showthread.php?p=1490068&highlight=Framework+page#post1490068) now I read more closely.On the Formats page there are dropdown boxes at the right side where you can choose between DirectShow/QuickTime/RealMedia. Those are the playback 'frameworks'.
The idea is to move those settings to a new page in the options. I explained it in this post:
http://forum.doom9.org/showthread.php?p=1490068#post1490068

[neoufo51]

xvidvideo.ru's downloads are not working.

[betaking]

xvidvideo.ru's downloads are not working.

you can download XhmikosR's builds at here http://xhmikosr.1f0.de/

[ceb]

I'm using version 1.5.2.3018 and EVR CP doesn't work, I get a black screen with only audio, if I switch to EVR Sync it works fine. This is similar to the problem I have when enabling DXVA (black screen with only audio but it seems to flash a little), although I wouldn't use DXVA anyway with my CPU.
Previously I was using version 1.5.2.2990 and it worked fine, is it my or MPC-HC's problem? In the changelog I didn't see any recent fixes for EVR CP but at the same time my hardware/software configuration is the same, I just had to format.
By the way, should I use EVR Sync or CP for best quality? The only thing I do is use Sharpen Complex 2 and changing the resizer to Bicubic A=-0.60 (PS 2.0).
Thanks.

Some details:
Intel Core i5 2500
ATI 5770 with 11.3 Catalyst (driver only version)
Windows 7 SP1 64-bit
MPC-HC 1.5.2.3018 x64 BE mod (with installer)
DirectX 9 updated
video formats: mp4, mkv and avi

[mr.duck]

No issue for me using r3018, Radeon 5750, 11.2 Drivers, Windows 7 x64, EVR CP.

[[ReX]]

So... for some reason, I'm not able to compile MPC-HC anymore, because of MediaInfo.
I use the batch file for VS2010, and it used to work fine until some weeks ago.

It gives me the following errors when I try to build it again:
http://pastebin.com/raw.php?i=am9yRVdX

The batch I use to build:
http://pastebin.com/raw.php?i=PGbwcavV

[SamuriHL]

;1491075']So... for some reason, I'm not able to compile MPC-HC anymore, because of MediaInfo.
I use the batch file for VS2010, and it used to work fine until some weeks ago.

It gives me the following errors when I try to build it again:
http://pastebin.com/raw.php?i=am9yRVdX

The batch I use to build:
http://pastebin.com/raw.php?i=PGbwcavV

That's really odd. I just set up my build env last week (vs2010) and it's been building for me no problem. I'm building 3019 right now, in fact. Are you sure you're pulling all the code?

[mr.duck]

Pleased with what I have achieved for a media setup at home. Summery...


Home Server
- Fanless mini ITX
- TV recording with a http web interface for TV guide and scheduling
- NAS duties for accessing media and for backups/general storage
- Wake on lan to wake server after it has gone to sleep to save energy
- Very quiet with 2 x 3.5" HDD mounted in scythe quiet drive enclosures
- Automatic remuxing TV into MKV for lower overheads and high performance playback
- Automatic streaming of current recording over network using VLC to serve (~4 sec delay compared to live)


Client computers
- Standard windows desktops or laptops connect over wired/wireless network
- A file manager and MPC HC for the HTPC interface
- TV playback is perfect thanks to remux to MKV (subtitles work better and corrupt video gets cut in the remux)
- No TV ads any more and files seek instantly and effortlessly thanks in part to MPC small, medium, large skip steps
- Access the live TV stream using VLC by just clicking a shortcut (used to watch sports which must be live)



But now I have found MPC can access the video stream. See screenshot for proof:

http://i.imgur.com/oXFTy.png

Check the titlebar. That is the home server address and MPC is accessing the http based feed!

But it's not reliable enough. Sometimes takes a few attempts to open it before both the video and audio are working. It stutters a lot at first but usually settles down eventually. It wont use LAVSplitter for the feed, instead it shows "Mpeg splitter (low merit)" whch will be the MPC built-in TS splitter I believe.

Requesting help/ideas to improve reliability so I can watch the F1 in glorious madVR quality! :thanks:

[[ReX]]

That's really odd. I just set up my build env last week (vs2010) and it's been building for me no problem. I'm building 3019 right now, in fact. Are you sure you're pulling all the code?

As you said, something went wrong when pulling the code.
I deleted the contents of ..\MediaInfo\MediaInfo and pulled them manually from here (http://mediainfo.svn.sourceforge.net/svnroot/mediainfo/MediaInfoLib/tags/v0.7.43/Source/MediaInfo).

The build was successful! :devil:

:thanks:

[SamuriHL]

;1491089']As you said, something went wrong when pulling the code.
I deleted the contents of ..\MediaInfo\MediaInfo and pulled them manually from here (http://mediainfo.svn.sourceforge.net/svnroot/mediainfo/MediaInfoLib/tags/v0.7.43/Source/MediaInfo).

The build was successful! :devil:

:thanks:

Very nice! Glad you were able to resolve that!!

[ceb]

No issue for me using r3018, Radeon 5750, 11.2 Drivers, Windows 7 x64, EVR CP.
Thanks for the answer. :)
It seems even you and others had this problem before (ticket #1074 (http://sourceforge.net/apps/trac/mpc-hc/ticket/1074)).
What do you mean by:
The quality is bloody awful since I didn't install CCC it now seems that all the 'enhancements' are on by default rather than off when you don't install CCC.
I also use the version without CCC but it always seemed OK for me.

Anyway, I tried uninstalling 1.5.2.3018, then installed 1.5.2.3019 but still EVR CP doesn't work.
How can I understand what is my problem? It worked fine before the format and now it doesn't. I have the exact same hardware/software as before. :confused:
Is EVR Sync better or worse than EVR CP in image quality? As you may have understood, I'm not an expert. :p

[betaking]

i see Media Player Classic (patched build) compiled by Clsid:
Revision 106 - Directory Listing
Modified Sat Oct 31 18:32:54 2009 UTC (17 months, 1 week ago) by clsid2
Fixed wrong comment for Delay setting in DirectVobSub.
but mpc-hc still not fix this!

[nevcairiel]

i see Media Player Classic (patched build) compiled by Clsid:
Revision 106 - Directory Listing
Modified Sat Oct 31 18:32:54 2009 UTC (17 months, 1 week ago) by clsid2
Fixed wrong comment for Delay setting in DirectVobSub.
but mpc-hc still not fix this!

Its a comment, how important can that possibly be. <.<

[mindz]

I have been looking around for quite some time on this forum and have gotten alot of useful information from it, thank you all for that.

I have a question of my own. I seem to have to use the shader 16-235->0-255[SD][HD], otherwise the picture looks washed out. This doesnt seem right, and i should be able to get the right picture without conversion, right? Also, im trying to get the shaders from JanWillem to work. I know how to activate them in MPC-HC and how to enable them, but they dont show any difference. How come?

[bobdynlan]

mindz, the most visually effective way to test is to activate the Invert shader. Whenever you toggle normal or screen space shaders, you get a status bar message with the name and eventual failure. Also, it's best to use the Combine... Shaders feature, and a (puzzling) note: activated/disabled = with/without checkmark on the popup menu.

If you try to add new shaders by means of a registry file - it's unreliable - you should manually open the Shader Editor and on the first combo box write a new name for it, press Enter, it will auto-complete a dummy shader, the status will say "D3DXCompileShader succeeded". Right click the dummy shader text, Select All, Delete. Paste JanWillem32's shader there. If all ok, status will say again "D3DXCompileShader succeeded".

I guess an import text-file feature is needed, maybe I can make a patch for it.

-----------
About the TV-PC levels, I would recommend the "brightness, contrast and gamma control for RGB" with a calibration video like Section-A.mp4 (starting at 3:00) for the best results. It's not enough to tweak video levels, most displays need also a gamma adjustments.
First increase the 3 gamma values until you see every useful detail in the picture. I'm using more meaningful values of 2.2/2.X for gamma - and adjust only the 2.X part. Then decrease the 3 brightness values in .005 steps to lower the black. And finally, increase the 3 contrast values in .01 steps to increase the white. I did not test the new "brightness, contrast, grayscale gamma, colorfulness gamma, hue and saturation control for SD&HD video input" but it needs similar adjustments.

The reason you need this is because renderers are not consistent when it comes to video levels. In EVR-CP you can use the built in Output Level 0-255 or 16-235 without messing with other shaders, but I remember JanWillem32 said something about clipping with 0-255 so it's best to use a 16-235 there and adjust with the shaders.

[Schrade]

Pleased with what I have achieved for a media setup at home. Summery...


Home Server
- Fanless mini ITX
- TV recording with a http web interface for TV guide and scheduling
- Automatic remuxing TV into MKV for lower overheads and high performance playback
- Automatic streaming of current recording over network using VLC to serve (~4 sec delay compared to live)


Client computers
- Standard windows desktops or laptops connect over wired/wireless network
- A file manager and MPC HC for the HTPC interface
- TV playback is perfect thanks to remux to MKV (subtitles work better and corrupt video gets cut in the remux)
- No TV ads any more and files seek instantly and effortlessly thanks in part to MPC small, medium, large skip steps
- Access the live TV stream using VLC by just clicking a shortcut (used to watch sports which must be live)
:thanks:

Nice setup! Can you share some info in a thread elsewhere (that's more appropriate) for the VLC setup and other things you use?

[Plutotype]

Hi folks,

Sorry for double questioning this.

It is already possible to play back 3D blurays via MPC-HC, 3D capable receiver and watch them on a 3D capable LCD with glasses?

If no, why?

Thanks
Pluto

[nevcairiel]

Its not. Why? Because no-one implemented it.

There is no MVC decoder or a 3D renderer available.

[ceb]

I'm using version 1.5.2.3018 and EVR CP doesn't work, I get a black screen with only audio, if I switch to EVR Sync it works fine. This is similar to the problem I have when enabling DXVA (black screen with only audio but it seems to flash a little), although I wouldn't use DXVA anyway with my CPU.
Previously I was using version 1.5.2.2990 and it worked fine, is it my or MPC-HC's problem? In the changelog I didn't see any recent fixes for EVR CP but at the same time my hardware/software configuration is the same, I just had to format.
By the way, should I use EVR Sync or CP for best quality? The only thing I do is use Sharpen Complex 2 and changing the resizer to Bicubic A=-0.60 (PS 2.0).
Thanks.

Some details:
Intel Core i5 2500
ATI 5770 with 11.3 Catalyst (driver only version)
Windows 7 SP1 64-bit
MPC-HC 1.5.2.3018 x64 BE mod (with installer)
DirectX 9 updated
video formats: mp4, mkv and avi
Thanks for the answer. :)
It seems even you and others had this problem before (ticket #1074 (http://sourceforge.net/apps/trac/mpc-hc/ticket/1074)).
What do you mean by:

I also use the version without CCC but it always seemed OK for me.

Anyway, I tried uninstalling 1.5.2.3018, then installed 1.5.2.3019 but still EVR CP doesn't work.
How can I understand what is my problem? It worked fine before the format and now it doesn't. I have the exact same hardware/software as before. :confused:
Is EVR Sync better or worse than EVR CP in image quality? As you may have understood, I'm not an expert. :p
Can someone help me?
I tried version 1.5.2.3023 but EVR CP still doesn't work.

[betaking]

Microsoft Visual Studio 2008 Service Pack 1 MFC Security Update
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4149f21c-37f7-4516-83e1-d70c738d612b
but install this patch after, i compile last mpc-hc svn mpc-hc.exe and mpc-hc_standalone_filters is very big? and dev can optimization code?

[mr.duck]

Nice setup! Can you share some info in a thread elsewhere (that's more appropriate) for the VLC setup and other things you use?

http://forum.doom9.org/showthread.php?t=160561

[GTPVHD]

http://www.microsoft.com/technet/security/Bulletin/MS11-025.mspx

Microsoft has released a security update for Visual Studio 2008 SP1 for those still using Visual Studio 2008 SP1 to compile MPC-HC. This fix should already be in in Visual Studio 2010 SP1.

[hayan]

mpc-hc.exe x86 1.5.2.2990 (XhmikosR)
Total running time: about 2 hrs

Problem: Srceen freeze/crash

Event ID: 4101 Display driver nvlddmkm stopped responding and has successfully recovered.

What you did: Press ← or → key ( "Fast seek" check box is checked)

display mode: Full Srceen (alt-enter)
Media type:H264/AVC (DXVA) (Internal Filter)
EVRCP, EVR Buffers:5
Vsync: VSync and AVSync
GPU control: all unchecked
Resizer: Bilinear
win7 x64 sp1, Fermi driver 266.58

After I rollback to 1.5.2.2976 (XvidVideo.RU)

mpc-hc.exe x86 1.5.2.3023 (XvidVideo.RU)
Total running time: about 2 hrs+

Problem: Srceen freeze/crash

Event ID: 4101 Display driver nvlddmkm stopped responding and has successfully recovered.

What you did: Press ← or → key ( "Fast seek" check box is checked)

display mode: Windows mode
Media type:H264/AVC (DXVA) (Internal Filter)
EVRCP, EVR Buffers:5
Vsync: VSync and AVSync
GPU control: all unchecked
Resizer: Bicubic A=-0.75
win7 x64 sp1, Fermi driver 266.58


back to 1.5.2.2976 (XvidVideo.RU)...

[v0lt]

Microsoft Visual Studio 2008 Service Pack 1 MFC Security Update
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4149f21c-37f7-4516-83e1-d70c738d612b
but install this patch after, i compile last mpc-hc svn mpc-hc.exe and mpc-hc_standalone_filters is very big? and dev can optimization code?
After your posts I decided not to install the updates for VS2008. :)

[hopstiii]

What's that DXVA and has anybody been able to use it with Radeon HD-3870 and newest DirectX 10 for it.

I did see the DXVA symbol only with 64 bit MPC-HC, but video was messed up with that.

http://static3.nagi.ee/i/p/722/25/180563530fdb33_o.jpg

[nevcairiel]

After your posts I decided not to install the updates for VS2008. :)

Its a security update, not installing those is just irresponsible and stupid.

[betaking]

Its a security update, not installing those is just irresponsible and stupid.

You are right, but i hope mpc-hc dev can optimization mpc-hc code!because compile last mpc-hc svn mpc-hc.exe and mpc-hc_standalone_filters is very big!:(

[nevcairiel]

Use VS2010, i don't even have VS08 installed anymore. :)

[betaking]

Use VS2010, i don't even have VS08 installed anymore. :)

Use vs2010.still big.and some people still ues windows 2000!:(

[nevcairiel]

Windows 2000 is not supported anymore.

Also, just use the bigger version.

[madshi]

MSVC++ 2010 is painfully slow for me. Even just loading MPC-HC and waiting for parsing of the headers and updating of the intellisense information etc takes several minutes. Then the first compile also takes several minutes. I hate all that stupid intellisense stuff. There doesn't seem to be any way to turn it off, either (at least as far as I can see). Maybe the whole MPC-HC project is simply too big (with all the internal filters and stuff) for my old development PC. Developing madVR with MSVC++ 2005 is really quick, though.

[tetsuo55]

The minimum requirements for MPC-HC are: An SSE2 or better CPU, DEP enabled and Windows XP3 or newer.

Its fairly easy to modify the MPC-HC files so it becomes compatible with older hardware and even win2k. These changes are not supported and at least on win2k are known to cause crashes.

About the Vs2008 probleems, we have had the 2008 compile option in maintenance mode for a while now.
We are considering stopping support for it completely (but like above anyone can still maintain the vs2008 solution locally)

Are there any active dev's that currently can not use vs2010?

[nevcairiel]

Maybe the whole MPC-HC project is simply too big (with all the internal filters and stuff) for my old development PC. Developing madVR with MSVC++ 2005 is really quick, though.

MPC-HC is indeed too big to really open quickly. My development PC is however very powerful, and after opening (which isn't that bad on this machine), its perfect. I also like the new GUI of 2010, combined with the IntelliSense improvements from Visual Assist X.

You can at least disable the auto-completion and suggestions, i don't think it'll disable the parsing, but at least once its open and done parsing, it shouldn't keep you waiting anymore.

http://msdn.microsoft.com/en-us/library/ecfczya1.aspx
Additionally whats listed there, in the Advanced folder under the language folder there is also a "Disable IntelliSense" option, which might even disable all parsing and updating. Can also disable the code browsing database which will again give you more performance if you don't use that feature.

For building taking long, well, its just a huge project.
My own projects are building fairly quickly, unless i invoke a complete re-build of all base classes that never change.
For some reason MPC-HC wants to rebuild quite a lot of code way too often - something funny in the project setup, i figure.

[madshi]

MPC-HC is indeed too big to really open quickly. My development PC is however very powerful, and after opening (which isn't that bad on this machine), its perfect. I also like the new GUI of 2010, combined with the IntelliSense improvements from Visual Assist X.

You can at least disable the auto-completion and suggestions, i don't think it'll disable the parsing, but at least once its open and done parsing, it shouldn't keep you waiting anymore.

http://msdn.microsoft.com/en-us/library/ecfczya1.aspx
Additionally whats listed there, in the Advanced folder under the language folder there is also a "Disable IntelliSense" option, which might even disable all parsing and updating. Can also disable the code browsing database which will again give you more performance if you don't use that feature.
Thanks, it was worth a try, but it didn't change or speed up anything for me, unfortunately... :(

[betaking]

The minimum requirements for MPC-HC are: An SSE2 or better CPU, DEP enabled and Windows XP3 or newer.

Its fairly easy to modify the MPC-HC files so it becomes compatible with older hardware and even win2k. These changes are not supported and at least on win2k are known to cause crashes.

About the Vs2008 probleems, we have had the 2008 compile option in maintenance mode for a while now.
We are considering stopping support for it completely (but like above anyone can still maintain the vs2008 solution locally)

Are there any active dev's that currently can not use vs2010?

OK.Next month i will re-install the system and install vs2010sp1 !

[namaiki]

What's that DXVA and has anybody been able to use it with Radeon HD-3870 and newest DirectX 10 for it.

I did see the DXVA symbol only with 64 bit MPC-HC, but video was messed up with that.

Not supported for lossless and for most things with resolution higher than 1920x1080.
Make sure to test with the latest ATi/AMD Catalyst if you want to use it.

[hopstiii]

Not supported for lossless and for most things with resolution higher than 1920x1080.
Make sure to test with the latest ATi/AMD Catalyst if you want to use it.

Oo okey good to know. Will it give smoother fps, or what's it good for. Also i have 8Gb of memory can i pre decode large amount of video to memory as uncompressed for perfect fps, lets say 1000 frames @ 720p.
X264 runs smooth but not ideal, DVD is much more like water in creek.

[namaiki]

Will it give smoother fps, or what's it good for.

X264 runs smooth but not ideal

What is your CPU and what non-DXVA decoder were you using?

If your CPU is lowly, DXVA will allow your GPU to decode the video instead of your GPU. It may or may not be faster at decoding than your CPU.

[nevcairiel]

OAlso i have 8Gb of memory can i pre decode large amount of video to memory as uncompressed for perfect fps, lets say 1000 frames @ 720p.

Frames decoded with DXVA in MPC-HC cannot use your system memory, only the graphics memory.

[hopstiii]

What is your CPU and what non-DXVA decoder were you using?

If your CPU is lowly, DXVA will allow your GPU to decode the video instead of your GPU. It may or may not be faster at decoding than your CPU.

I used haali renderer, i think ffdshow icon comes up when video is playing.

CPU is C2D e4500 2,2GHz, video is smooth but not allways it might benefit by buffering more raw data into memory, because CPU use for decoding is 30-45 %, obviously it must go over 100% if fps isn't constant.

I can see the player isn't using memory "atall", is there way to add option to player to specify buffer me raw frames:
512MB, 1024MB, 2048MB and so on. Homeuser motherboards can take 8 12 24 GB of memory. The 4GB ddr3 models are much cheaper than the ddr2's used to be.

constant frame rate is really good feature :)

[namaiki]

CPU is C2D e4500 2,2GHz, video is smooth but not always

CPU use for decoding is 30-45%


Open a video in MPC-HC. You can check what decoders are being used in the menu: Play-> Filters. If ffdshow is being used, make sure that you are using the ffmpeg-mt decoder for H.264 in 'Codecs.'

For now, to test your CPU limitation, please test with EVR-CP and check the Ctrl+J graph.

The graph should be consistent. If the green line goes up like a mountain, you can say that the video is not being decoded fast enough.

Please play the video and post a screenshot of the Ctrl+J graph where you feel the video is smooth and not smooth.

[ceb]

I'm using version 1.5.2.3026 and EVR CP doesn't work, I get a black screen with only audio, if I switch to EVR Sync it works fine. This is similar to the problem I have when enabling DXVA (black screen with only audio but it seems to flash a little), although I wouldn't use DXVA anyway with my CPU.
It worked fine before the format and now it doesn't. I have the exact same hardware/software as before. Can someone help me?
By the way, should I use EVR Sync or CP for best quality? The only thing I do is use Sharpen Complex 2 and changing the resizer to Bicubic A=-0.60 (PS 2.0).
Thanks.

Some details:
Intel Core i5 2500
ATI 5770 with 11.3 Catalyst (driver only version)
Windows 7 SP1 64-bit
MPC-HC 1.5.2.3026 x64 BE mod (with installer)
DirectX 9 updated
video formats: mp4, mkv and avi

[hopstiii]

Open a video in MPC-HC. You can check what decoders are being used in the menu: Play-> Filters. If ffdshow is being used, make sure that you are using the ffmpeg-mt decoder for H.264 in 'Codecs.'

For now, to test your CPU limitation, please test with EVR-CP and check the Ctrl+J graph.

The graph should be consistent. If the green line goes up like a mountain, you can say that the video is not being decoded fast enough.

Please play the video and post a screenshot of the Ctrl+J graph where you feel the video is smooth and not smooth.

I think the BR-rips 720p MKV's play smoother with DXVA than on CPU. Also the cpu use is 20-25%, with haali it's 50% and jumps really high when i seek.

Now i think the only thing that run worse on DXVA than haali was two pass x264 encode with very high bitrate 40960 kbit/s (5MB/s).

http://static3.nagi.ee/i/p/723/20/180802079c8528_o.jpg

http://static3.nagi.ee/i/p/723/20/18080201ac3516_o.jpg
Where can i get that? Why it's not in Win update?

[namaiki]

Is that image of the graph when the video is looking smooth, or not smooth?

DirectX Runtime: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=direct+x+runtime#hl=en&safe=off&sa=X&ei=acSlTYyRH4aIvgOVxNiXCg&ved=0CBIQBSgA&q=directx+runtime&spell=1&bav=on.2,or.r_gc.r_pw.&fp=384aef4afa8e1652

When you play using Haali's Renderer, what's in the menu: Play-> Filters?

[hopstiii]

Is that image of the graph when the video is looking smooth, or not smooth?

DirectX Runtime: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=direct+x+runtime#hl=en&safe=off&sa=X&ei=acSlTYyRH4aIvgOVxNiXCg&ved=0CBIQBSgA&q=directx+runtime&spell=1&bav=on.2,or.r_gc.r_pw.&fp=384aef4afa8e1652

When you play using Haali's Renderer, what's in the menu: Play-> Filters?

It looks ideally smooth with such graph, when i seek video then few sec its not soo smooth.

Oo yes the haali is not smooth atall. I can turn it on only in 32bit MPC-HC. There is also off aligned pixel/pixture block lines in video (didn't get it on screenshot but when video is playing its visible)

My cpu and int audio can't handle 7.1 192kHz 24bit. Especially when video only takes 60%. Then cpu gets full. Now i don't have such video with 7.1 orig audio to benchmark the DXVA which feature is new for me. But i belive DXVA is perfect for that.

That's haali.
http://static3.nagi.ee/i/p/723/21/18080395c9bd6b_o.jpg

[namaiki]

Hmm... Both MPC Video Decoder and ffdshow Video Decoder are appearing in the Filters menu. Is ffdshow set to decode, or just to post process? The latter would be very inefficient.

hopstiii, please idle in the MPC-HC IRC channel. http://webchat.freenode.net/?channels=mpc-hc
I'll have a chat with you some time and get this stuff fixed up.. :P

[Qaq]

hopstiii, your display is set to 60Hz and video is 24. You have to set your display 1:1 (or 2:1) matched to video.

[renq]

What's that DXVA and has anybody been able to use it with Radeon HD-3870 and newest DirectX 10 for it.

I did see the DXVA symbol only with 64 bit MPC-HC, but video was messed up with that.

http://static3.nagi.ee/i/p/722/25/180563530fdb33_o.jpg

HD3000-series has some limitations on the UVD decoder, for instance, it can't decode H264 Level5/5.1 (with high RefFrames)

[hopstiii]

Does it help?

MPC is also in filters menu with DXVA

MPC
Filter : MPC Video Decoder - CLSID : {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}

- Connected to:

CLSID: {0A68C3B5-9164-4A54-AFAF-995B2FF0E0D4}
Filter: F:\Filmid\Virgin Territory (2007) 720p.mkv
Pin: English (Video 1)

- Connection media type:

Video: MPEG4 Video (H264) 1280x696 24.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 166

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 416666

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 160
dwPictAspectRatioY: 87
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 34
dwProfile: 0x00000064
dwLevel: 0x00000029
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 1280
biHeight: 696
biPlanes: 1
biBitCount: 24
biCompression: AVC1
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 9a 5b 06 00 00 00 00 00 ........š[......
0030: 00 00 00 00 00 00 00 00 a0 00 00 00 57 00 00 00 ........*...W...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 00 05 00 00 ........(.......
0050: b8 02 00 00 01 00 18 00 41 56 43 31 00 00 00 00 ø.......AVC1....
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070: 00 00 00 00 22 00 00 00 64 00 00 00 29 00 00 00 ...."...d...)...
0080: 04 00 00 00|00 19 67 64 00 29 ac 34 e6 01 40 16 ......gd.)¬4ę.@.
0090: 7e 58 40 01 96 e6 c0 4c 4b 40 23 c6 0c 66 80 00 ~X@.–ęĄLK@#Ę.f€.
00a0: 05 68 ee b2 c8 b0 .hī²Č°



Haali
Filter : Haali Video Renderer - CLSID : {760A8F35-97E7-479D-AAF5-DA9EFF95D751}

- Connected to:

CLSID: {04FE9017-F873-410E-871E-AB91661A4EF7}
Filter: ffdshow Video Decoder
Pin: Out

- Connection media type:

Video: 1280x696 24.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_RGB32 {E436EB7E-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3563520
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(1280,696)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 416666

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 160
dwPictAspectRatioY: 87
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1280
biHeight: 696
biPlanes: 1
biBitCount: 32
biCompression: 0
biSizeImage: 3563520
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 05 00 00 b8 02 00 00 ............ø...
0020: 00 00 00 00 00 00 00 00 9a 5b 06 00 00 00 00 00 ........š[......
0030: 81 00 00 00 00 00 00 00 a0 00 00 00 57 00 00 00 �.......*...W...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 00 05 00 00 ........(.......
0050: b8 02 00 00 01 00 20 00 00 00 00 00 00 60 36 00 ø..... ......`6.
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

ffdshow
Filter : ffdshow Video Decoder - CLSID : {04FE9017-F873-410E-871E-AB91661A4EF7}

- Connected to:

CLSID: {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}
Filter: MPC Video Decoder
Pin: Output

- Connection media type:

Video: YV12 1280x696 24.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(1280,696)
rcTarget: (0,0)-(1280,696)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 416666

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 160
dwPictAspectRatioY: 87
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1280
biHeight: 696
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 1336320
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 05 00 00 b8 02 00 00 ............ø...
0010: 00 00 00 00 00 00 00 00 00 05 00 00 b8 02 00 00 ............ø...
0020: 00 00 00 00 00 00 00 00 9a 5b 06 00 00 00 00 00 ........š[......
0030: 81 00 00 00 00 00 00 00 a0 00 00 00 57 00 00 00 �.......*...W...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 00 05 00 00 ........(.......
0050: b8 02 00 00 03 00 0c 00 59 56 31 32 00 64 14 00 ø.......YV12.d..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

[Barlow]

In recent revisions subtitle anti-aliasing appears to have changed.

2827
http://tweakers.net/ext/f/ojvMtRZ4GuWQ0rNj3M0YXn5X/medium.png (http://tweakers.net/ext/f/ojvMtRZ4GuWQ0rNj3M0YXn5X/full.png)

3025
http://tweakers.net/ext/f/FxqgnlWmY0JGRpwNWMMHtncW/medium.png (http://tweakers.net/ext/f/FxqgnlWmY0JGRpwNWMMHtncW/full.png)

I prefer the look of the former, but there doesn't appear to be a way to change it back. I used the same ini file, so settings should be the same. If i missed a switch please tell me :)

I couldn't find the exact build that introduced this change, as binaries aren't available for every revision. In build 2855 subtitles still look like before. 2875 was the first build I could find where the subtitles look different.

[hopstiii]

hopstiii, your display is set to 60Hz and video is 24. You have to set your display 1:1 (or 2:1) matched to video.

Oo ok i will keep it in mind in futture. But what will it change?

[Qaq]

But what will it change?
That makes playback smooth (please don't ask why).

[HowlerX]

In recent revisions subtitle anti-aliasing appears to have changed.


I prefer the look of the former, but there doesn't appear to be a way to change it back. I used the same ini file, so settings should be the same. If i missed a switch please tell me :)

I couldn't find the exact build that introduced this change, as binaries aren't available for every revision. In build 2855 subtitles still look like before. 2875 was the first build I could find where the subtitles look different.

Yes, I also liked how they used to look. Put me down as a vote for at least providing the option for anti-aliased subtitles or blurring them or whatever the old builds used to do.

[chapas]

How can I change the output colorspace for MPC-HC codecs like I do on ffdshow? I ask this because the vanilla internal mpc-hc codecs seem to output RGB32 instead of NV12 for things like Xvid and DivX.

There's a mod called mpc-hc-be that has the options on the codec's config page:

http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-2-3030.html

http://www.xvidvideo.ru/images/stories/my_pic/new_00005.png

Thanks!

[hopstiii]

In 32bit MPC-HC there is option under haali to convert to luma 255 or 235. But under DXVA there isn't, what's that by default 235 or 255.

[namaiki]

In 32bit MPC-HC there is option under haali to convert to luma 255 or 235. But under DXVA there isn't, what's that by default 235 or 255.

View-> Renderer-> Output range. However, if I recall correctly, the options in Haali and EVR are opposite as EVR = output range and Haali = input range.

[LigH]

Using the "Black Edition" from xvidvideo.ru, I experienced a strange seeking behaviour with some AVIs, clicking on the timeline:

The first time I click, the video playback is distorted, like decoding not from an I-frame on. The second time I click (no matter if the same position or another), the decoding is correct. And again - even vs. odd numbers.

I am not certain which keywords to search for ... does this description sound familiar to you? If not, I will try to provide more details (hope my ISP at home has fixed the connection in the meantime).

I guess it may be related to the misc. option to seek to keyframes only.

[Trey_S]

Hello.
I've tried to get HD video from a Canon DSLR to play with HD-acceleration in MPC-HC but I've so far never gotten it to work. All i get is a black screen when dxva is enabled.

The moveis are H.264? in .mov-containers. Tried updating to the latest nvidia drivers (have a 8600m gt card). Had an older MPC-HC version at first which I updated to the version on the sourceforge page but still the same problem.

Are these videos incompatible with HD-acceleration or am i doing something else wrong? Never had any problems with other HD-videos in DXVA-mode...

Links to video samples (scroll down on the pages):
http://www.dpreview.com/reviews/canoneos600d/page15.asp
http://www.dcresource.com/reviews/canon/eos_rebel_t2i-review/using

[Aleksoid1978]

Hello.
I've tried to get HD video from a Canon DSLR to play with HD-acceleration in MPC-HC but I've so far never gotten it to work. All i get is a black screen when dxva is enabled.

The moveis are H.264? in .mov-containers. Tried updating to the latest nvidia drivers (have a 8600m gt card). Had an older MPC-HC version at first which I updated to the version on the sourceforge page but still the same problem.

Are these videos incompatible with HD-acceleration or am i doing something else wrong? Never had any problems with other HD-videos in DXVA-mode...

Links to video samples (scroll down on the pages):
http://www.dpreview.com/reviews/canoneos600d/page15.asp
http://www.dcresource.com/reviews/canon/eos_rebel_t2i-review/using

All sample play fine with Internal DXVA Decoder.

[Trey_S]

Well that sounds good.
Wonder what goes wrong with my setup. How can I proceed with troubleshooting?

I have EVR custom pres. selected.
It says "Playing [DXVA]" but the videos doesn't play at all.
Tried with Haali splitter and with the internal MP4/MOV, and tried renaming file to .mp4 but all give same result.

Do I have to have quicktime installed?

[ceb]

I found out that my problem was caused by the BE Mod, it doesn't work with EVR CP. If I use EVR Sync it works, if I use the normal version of MPC-HC (both EVR CP and Sync) it works. :confused:
I played a video, right click > Filters > MPC Video Decoder and have set my settings as this image (taken from xvidvideo.ru):

http://www.xvidvideo.ru/images/stories/my_pic/new_00005.png

It surely has to do with the BE Mod since the normal version works fine.
I'm using version 1.5.2.3033 (with installer) 64-bit, DXVA disabled (I get black screen), Sharpen Complex 2 and Bicubic A=-1.00 (PS 2.0).
Thanks for any help.

[Ger]

Did you try the 32-bit BE mod? Works for me with HD5770 + Catalyst 11.3. I never tested the 64-bit version.

[nevcairiel]

Move NV12 up one position, above YV12, it should potentially help.

[bobdynlan]

You won't find much support for the "BE" mod, and the new libswscale feature in particular is in testing stage. I would first read this about it (http://cid-d561cc7d122f3f32.office.live.com/self.aspx/Shared/MPCHC^_SWSCALER^_MOD/readme.txt). Then, while playing videos, check the actual output format in Filters->Name-of-video-renderer. Like on the readme, if it's YUY2 you need to put Chroma to RGB to less than Full (this screams for a fix later on). Next time, please specify the renderer used.
alexins said he found a serious mistake leading to crashes, so I'm waiting for more info on it.

I'm also after the big fish, as I try to update the 6-months old ffmpeg. For now, I've completed the libavutil (with merged libavcore, msvc build ok), and libavcodec is 50% ready for GCC build.
When this starting point it's done, I'm guessing more people will contribute to re-apply specific patches, correct mistakes and fix the msvc builds.

[nevcairiel]

I would vote for simply ignoring MSVC builds, it'll make future updates easier and save alot of trouble (and work).
Stick to vanilla ffmpeg as close as possible.

Not that i personally really care, i'll write my own decoder in due time. :d

[Virtual_ManPL]

Not that i personally really care, i'll write my own decoder in due time. :d

waiting for your player next :devil:

[Mercury_22]

You won't find much support for the "BE" mod, and the new libswscale feature in particular is in testing stage. I would first read this about it (http://cid-d561cc7d122f3f32.office.live.com/self.aspx/Shared/MPCHC^_SWSCALER^_MOD/readme.txt). Then, while playing videos, check the actual output format in Filters->Name-of-video-renderer. Like on the readme, if it's YUY2 you need to put Chroma to RGB to less than Full (this screams for a fix later on). Next time, please specify the renderer used.
alexins said he found a serious mistake leading to crashes, so I'm waiting for more info on it.

I'm also after the big fish, as I try to update the 6-months old ffmpeg. For now, I've completed the libavutil (with merged libavcore, msvc build ok), and libavcodec is 50% ready for GCC build.
When this starting point it's done, I'm guessing more people will contribute to re-apply specific patches, correct mistakes and fix the msvc builds.

In the meantime we are still waiting for your GUI patch to make it to the SVN as you promised :p
...
That's based on a old sketch source and I do not support it. I will reboot that mod soon - and now I mean it :)

P.S. BE mod x64 working fine here

[ceb]

Did you try the 32-bit BE mod? Works for me with HD5770 + Catalyst 11.3. I never tested the 64-bit version.
Same problem.
Move NV12 up one position, above YV12, it should potentially help.
It still doesn't work.
Next time, please specify the renderer used.
It's using Enhanced Video Renderer (custom presenter).

I don't understand why before it worked fine and now no, perhaps a recent change?
Also it seems that I'm the only one with this problem. :confused:
What do you guys suggest me to do? Should I stop using the BE Mod or is EVR Sync the same as EVR CP in terms of quality?

[Mercury_22]

Same problem.

It still doesn't work.

It's using Enhanced Video Renderer (custom presenter).

I don't understand why before it worked fine and now no, perhaps a recent change?
Also it seems that I'm the only one with this problem. :confused:
What do you guys suggest me to do? Should I stop using the BE Mod or is EVR Sync the same as EVR CP in terms of quality?

First of all reset MP-HC's settings and display adapter's settings ( Restore factory defaults)

Then if you want us to help you please provide details: OS video drivers, DirectX....

More here http://sourceforge.net/apps/trac/mpc-hc/wiki/Troubleshooting_guidelines

[ceb]

Then if you want us to help you please provide details: OS video drivers, DirectX....
Sorry I forgot about that, here are my details:
Intel Core i5 2500
ATI 5770 with 11.3 Catalyst (driver only version)
Windows 7 SP1 64-bit (with all updates)
MPC-HC 1.5.2.3033 x64 BE mod (with installer)
DirectX 9 updated
DXVA disabled (because of black screen)
Sharpen Complex 2 and Bicubic A=-1.00 (PS 2.0)
video formats: mp4, mkv and avi

[Ger]

I have the same OS, same GPU, same resizer and no black screen.

Differences from your setup:
- Different/older CPU/mobo.
- Full "Catalyst Software Suite" 11.3 (with CCC).
- 32-bit BE mod.
- "YV12 Chroma Upsampling" shader enabled to work around a chroma upsampling issue with EVR-CP + ATI that started in r2837. Other shaders disabled.
- Maybe different splitters and stuff, but I don't think that would matter.

If you tried resetting all MPC-HC/decoder settings to default already, and maybe rerunning the DirectX web setup just in case, I guess reinstalling Catalyst with CCC may be worth a shot. People seem to disagree on the effects. I always install CCC so I have no opinion on the matter.

[tetsuo55]

You won't find much support for the "BE" mod, and the new libswscale feature in particular is in testing stage. I would first read this about it (http://cid-d561cc7d122f3f32.office.live.com/self.aspx/Shared/MPCHC^_SWSCALER^_MOD/readme.txt). Then, while playing videos, check the actual output format in Filters->Name-of-video-renderer. Like on the readme, if it's YUY2 you need to put Chroma to RGB to less than Full (this screams for a fix later on). Next time, please specify the renderer used.
alexins said he found a serious mistake leading to crashes, so I'm waiting for more info on it.

I'm also after the big fish, as I try to update the 6-months old ffmpeg. For now, I've completed the libavutil (with merged libavcore, msvc build ok), and libavcodec is 50% ready for GCC build.
When this starting point it's done, I'm guessing more people will contribute to re-apply specific patches, correct mistakes and fix the msvc builds.Thanks for the update, as Nevcairiel said you can ignore msvc builds. XhmikosR wants to commit your patch asap, so once its in "any" shape to be committed please give him the link.

If you have any other patches waiting to be committed you can give them to him too.

[chapas]

Guys, so there's no way to set the colorspace for Divx/Xvid decoding with MPC-HC filters? It defaults to RGB32 for me, and I can't change it.

The h264/VC-1 decoder works on NV12 colorspace.

[v0lt]

little progress
http://img812.imageshack.us/img812/347/fileassociations3.th.png (http://img812.imageshack.us/img812/347/fileassociations3.png)
now controls are not connected with the settings. a lot of work.

[pirlouy]

You already know that, but: Nice one !

[khagaroth]

Nice redesign. Just a note. When creating dialogs, please keep in mind they will be later translated into other languages -> make all dialog elements as big as possible. Don't know how you create the .rc file, but some resource editors have the stupid habit of automatically shrinking elements to the length of the English string, which usually is not enough space for other languages. One possible show-stopper in the above dialog is the 'Other:' string, align the input field to the right of the above tree box and enlarge the 'Other:' static element.

[ceb]

I have the same OS, same GPU, same resizer and no black screen.

Differences from your setup:
- Different/older CPU/mobo.
- Full "Catalyst Software Suite" 11.3 (with CCC).
- 32-bit BE mod.
- "YV12 Chroma Upsampling" shader enabled to work around a chroma upsampling issue with EVR-CP + ATI that started in r2837. Other shaders disabled.
- Maybe different splitters and stuff, but I don't think that would matter.

If you tried resetting all MPC-HC/decoder settings to default already, and maybe rerunning the DirectX web setup just in case, I guess reinstalling Catalyst with CCC may be worth a shot. People seem to disagree on the effects. I always install CCC so I have no opinion on the matter.
I tried installing the CCC but it still doesn't work, guess I'll have to use EVR Sync.
Are there any advantages/disadvantages in using EVR Sync instead of EVR CP?

[hopstiii]

Hi :)

Are this settings DXVA compatible?

http://static3.nagi.ee/i/p/723/80/180950913729d0_o.jpg

[clsid]

Thanks for the update, as Nevcairiel said you can ignore msvc builds. XhmikosR wants to commit your patch asap, so once its in "any" shape to be committed please give him the link.

If you have any other patches waiting to be committed you can give them to him too.The MSVC builds are used only for the debug version of MPC. So the ffmpeg based internal decoders should be excluded in the debug build if you want to get rid of MSVC compatibility. Getting ffmpeg to compile in MSVC requires a lot of custom code, so getting rid of it is a good idea.

[Avish]

How to add a new shader to mpc-hc's list of shaders? I want to try "SharpenFlou (jim ro)" from PotPlayer's list of shaders.

[bobdynlan]

How to add a new shader to mpc-hc's list of shaders? I want to try "SharpenFlou (jim ro)" from PotPlayer's list of shaders. Only one page back I've posted a hint http://forum.doom9.org/showthread.php?p=1491576#post1491576

[Avish]

Thanks for that! :)

I almost figured it yesterday.. opened editor, pasted the text, pressed enter.. but couldn't figure out how to save it! :)

[Inspector.Gadget]

Holy crap, so am I! What the heck's the model of your screen/graphics card combo? I get 62Hz outputting from the Intel card on this laptop with switchable graphics.

I tried ReClock for a while, it was pretty good for speeding up 30Hz-> 31Hz stuff where there is a noticeable pause in the video during each second of video when VSync is enabled. With ReClock, video was perfectly smooth but the ~5% speedup was quite noticable at times.

Hey namaiki, I wanted to get back to you on this since I see you're using a 9600m GT. I'm on a 9650m GT pushing an AUO "1088" commodity notebook LCD panel and can't find any information about the claimed capabilities of the panel itself (as distinct from the capabilities reported to Windows). Today I decided to try to create a custom resolution in the NVIDIA control panel and decided to go from 1920x1080@62hz@32bitdepth to 1920@1080@72hz@ 32bitdepth. It seems to work well for 24p content so far - the CRTL+J graph in MPC-HC has gone from a spirograph drawing to two mostly flat parallel lines and reported jitter is at zero. I've also been able to create 60hz and even 48z modes without my display immediately puking, though I haven't tested them for stability.

My sense is that most LCD panels take from 50 or 60 through 75 hz vertical refresh without complaint, though it is rumored that pushing a display at a non-recommended resolution can harm it (though wouldn't any modern panel just refuse to display an out-of-bounds signal?).

Anyway, if you feel confident, give this a shot and see if it helps. I'd appreciate also any information from more knowledgable people about whether I'm running a real risk of breaking the panel...

[JanWillem32]

Hey namaiki, I wanted to get back to you on this since I see you're using a 9600m GT. I'm on a 9650m GT pushing an AUO "1088" commodity notebook LCD panel and can't find any information about the claimed capabilities of the panel itself (as distinct from the capabilities reported to Windows). Today I decided to try to create a custom resolution in the NVIDIA control panel and decided to go from 1920x1080@62hz@32bitdepth to 1920@1080@72hz@ 32bitdepth. It seems to work well for 24p content so far - the CRTL+J graph in MPC-HC has gone from a spirograph drawing to two mostly flat parallel lines and reported jitter is at zero. I've also been able to create 60hz and even 48z modes without my display immediately puking, though I haven't tested them for stability.

My sense is that most LCD panels take from 50 or 60 through 75 hz vertical refresh without complaint, though it is rumored that pushing a display at a non-recommended resolution can harm it (though wouldn't any modern panel just refuse to display an out-of-bounds signal?).

Anyway, if you feel confident, give this a shot and see if it helps. I'd appreciate also any information from more knowledgable people about whether I'm running a real risk of breaking the panel...The maximum vertical refresh rate is often reported wrong by Windows. I recommend to use "monitor asset manager" to look up the monitor's Horizontal scan range maximum. The horizontal scan rate is what limits analog D-Sub and digital DVI/HDMI signals (for most devices) on the receiving part. (DisplayPort isn't scanned, but micro-packet based, so it will react differently.) As long as the horizontal scan rate maximum isn't exceeded, no harm can be done. Sometimes the Vertical scan range is wrong in the info, it will often just note the range as a single refresh rate. It's safe to ignore that. I've yet to see a monitor that doesn't indicate the correct maximum horizontal scan rate.
To calculate the maximum vertical scan rate: http://en.wikipedia.org/wiki/Horizontal_scan_rate .
My CRT has a signal-to-blanking ratio of about 1.046875, if the indicated rates of 128.5 kHz and 79.9 Hz are correct on my monitor. The resolution is 2048×1536. 128500/(1536*1.046875) = 79.9
It could be that some digitally connected display devices can use a signal-to-blanking ratio of 1, but I haven't seen or tested that yet.
I once found a list of special case refresh rates. These are 23, 29, 47, 59, 71, 89 and 119 fake Hz. These denote NTSC adapted refresh rates of 24/1.001, 30/1.001, 48/1.001, 60/1.001, 72/1.001, 90/1.001 and 120/1.001 Hz. The 24, 30, 48, 60, 72, 90 and 120 Hz frequencies are treated as whole numbers like all other refresh rates.

Edit: I also found the most probable reason why I never liked standard bicubic scaling: http://photocreations.ca/interpolator/index.html .
A few notes on this page:
-the images were not gamma-corrected during processing, that's why the processed images are so dark,
- 8-bit RGB was used obviously, as both spline and sync methods will never produce gray tints on former white areas like that with 16- or 32-bit floating point surfaces (haloing will still always be present with these methods, though)
-using a stopwatch isn't the most correct method for timing computer operations.

[mindbomb]

question: should the yv12 chroma upsampling shader be used as a screen space shader or a regular shader?

and can it ever be a bad thing to have this shader on?

[Inspector.Gadget]

As long as the horizontal scan rate maximum isn't exceeded, no harm can be done. Sometimes the Vertical scan range is wrong in the info, it will often just note the range as a single refresh rate. It's safe to ignore that. I've yet to see a monitor that doesn't indicate the correct maximum horizontal scan rate.

Thank you for the information and links. Unfortunately, even Monitor Asset Manager can't discover range maximums for vertical and horizontal scans on this display. The best information I could find is pulled from the manufacturer's spec sheet to my laptop's OEM. Any insight as to whether operating at 1920x1080/72hz is a bad idea?:p Thank you for your help.

http://img824.imageshack.us/img824/9009/timingf.png

[JanWillem32]

@Inspector.Gadget: I found a similar image in a document for a similar AUO panel. It also notes a period of 2048 maximum, but with the full list of specifications. It seems that that panel is limited to 75 Hz mostly because of the processor that does the 8-bit to 6-bit color downgrade. Extrapolating the Clock frequency also indicates that a 75 Hz frame rate will use a Clock frequency just below 100 MHz (could be a design limit).

[Inspector.Gadget]

@JanWillem32: Great. Thank you for your help and your extra research into the subject.

[SamuriHL]

So I'm going to pose this question here. This is a subtitle question to whatever developer knows subs the best. :) HD DVD's (I know, I know, a dead format...bear with me for a minute) apparently use some high res vobsub format. I've been taking my HD DVD's and converting them to an MKV container with the subtitles in tact. When I use either ffdshow or preferably mpc-hc's subtitle renderer, these subtitles don't show. At first we thought it might be the splitter, but, I tried multiple splitters and the subtitles are listed, and say they're on, but, they don't display. Does anyone have any time to take a quick look at this issue and see if it's an easy fix? It would make a *LOT* of people happy, myself included. I'd be eternally grateful for anyone who can look at this issue. If a sample is needed, please let me know and I'll make one. Thanks!!

[JanWillem32]

@SamuriHL: It's been discussed a few times on IRC, the problem also exists for other formats, such as DVB subtitles. Yesterday, we analyzed that the 8 bits (in total) format is probably not accepted by the subtitle renderer's mixer. We had a similar thing in the past with the blu-ray subtitles that also required new code to read the subtitle bitmap. I'm not very familiar with these things, but I know it's pretty hard to modify the outdated and badly documented subtitle renderer, unfortunately.

[SamuriHL]

Damn. There's a lot of people in the same boat as I am...converting HD DVD's to MKV in the hopes that we can salvage a dead format without having to repurchase a bunch of movies. I myself have over 30+ HD DVD's (probably more...I'm too lazy to count right now) that I don't mind converting, but, the subs are definitely necessary on some of them. I really do appreciate the response, though. Thank you!

[nevcairiel]

You should be able to use BDSup2Sub (http://forum.doom9.org/showthread.php?t=145277) to convert HD DVD Subs into "ordinary" DVD subs, or PGS subs.
Granted, its a bit more work then just watching the movie, but if you know that some movie really has "must have" subs for you, thats your tool.

[SamuriHL]

You should be able to use BDSup2Sub (http://forum.doom9.org/showthread.php?t=145277) to convert HD DVD Subs into "ordinary" DVD subs, or PGS subs.
Granted, its a bit more work then just watching the movie, but if you know that some movie really has "must have" subs for you, thats your tool.

Yea, I know. As I said in the other thread, I'm lazy and was hoping it'd just work. Technically speaking, I still have HD DVD playback capability with TMT5, but, I like the idea of having them all in MKV format so I can use madVR and MPC-HC.

[robpdotcom]

Samuri: I believe you said you have already put the movies into mkv? You could extract the subs with mkvExtract, convert them to idx, and put them in a separate directory to be loaded externally by MPC-HC.

It would be quicker than remuxing at least.

[SamuriHL]

That's a thought. I'm toying with Another EAC3TO Gui Plus right now to see if I can automate everything off the disc itself. I can rerip if necessary. I've only done a couple of MKV's so far. Trying to get the process down so that I can get all my discs converted. But yea, I could do IDX if I need to. Ideally if I can't use the subs as is I'd like to convert them to PGS subs and remux them in. I'm going to see what I can do. I don't blame the devs for not wanting to play in the subtitle renderer. We've seen the horror stories. I thought at one point someone said they were going to write a new sub renderer from scratch but I haven't seen anything on it recently. I don't know enough about subtitles to be of any help with the code, especially if it's already a mess. sigh.

[JanWillem32]

It's mostly the text-based renderer that needs renewing on the draw/composing parts, really. The font renderer renders in A4R4G4B4, the anti-aliasing quality of the GDI parts is below modern standards and animation can choke even a very a modern CPU (the GPU isn't used). The bitmap-based items can stay, as those won't get much more efficient than they already are. I might add better scaling than the forced bilinear filter later, as the standard scaling pixel shaders are easily shared with other renderers.

[G_M_C]

JanWillem: Was brouwsing your page & mediafire. Saw MPC-HT build 3033. What's new/changed in it (or did you already post changelog ?).

[JanWillem32]

I'm writing patches at the moment for the dfr3038 version to a new branch. There are so many things I patched months to weeks ago, and not to forget that there was a big contribution to the color management section, too. I hope to get everything set up today to get that code into that branch. For the other part, I'm a bit closer to get the VSync Offset function working again and I've made optimizations to the dithering codes.
edit: I just put the dfr3038 file sets in the folder. I've mostly updated the adaptive random and random ordered ditherers to have lower GPU usage this time.

[GrofLuigi]

I stumbled upon something (http://tedwvc.wordpress.com) about compiling and recent VC* MFC updates. Don't know how relevant it is, but I hope someone will find it useful (all posts from April 2011 seem to be).

:helpful:

GL

[tetsuo55]

Nice find GrofLuigi, that should help both vc 2010 and 2008!

[betaking]

I stumbled upon something (http://tedwvc.wordpress.com) about compiling and recent VC* MFC updates. Don't know how relevant it is, but I hope someone will find it useful (all posts from April 2011 seem to be).

:helpful:

GL

thanks find! :)

[betaking]

http://tedwvc.wordpress.com/2011/04/16/static-mfc-code-bloat-problem-from-vc2010-is-now-in-vc2008-sp1security-fix/

[nevcairiel]

That fix doesn't work with MPC-HC, there must be something weird about the setup of MPC-HC that blocks it.

[JanWillem32]

About the size problem with VS2008, can someone compare the size of the assembly blocks between the former builds and the current one? Assembly blocks are the .asm files in the same folders as the .cpp and .h files, they contain the compiled data of all program functions. If any of those files blows up in size considerably, it's most likely that the function in it is the culprit of making the complete .exe so big.

[korsan]

I have media files with srt subtitles on a network drive.
I can play them when I connect through windows explorer \\192.168.2.xxx\.
But the problem is that Mplayerc HC cannot detect the srt subtitles automatically when the files are on the network drive. This problem does not occur with Vlc player.

[alexins]

That fix doesn't work with MPC-HC, there must be something weird about the setup of MPC-HC that blocks it.

In the project for MPC-HC MSVC 2008, everything works fine. I was able to build MPC-HC (2008) and Standalone Filters.
This fix (http://tedwvc.wordpress.com/2011/04/16/static-mfc-code-bloat-problem-from-vc2010-is-now-in-vc2008-sp1security-fix/) should not be used in all the files stdafx.cpp.

[hopstiii]

I made this VirtualDub X264 DXVA guide. Can someone experienced point out if something is wrong there?

http://static3.nagi.ee/i/p/724/85/181214692f9840_o.jpg

[LigH]

:eek:

1) Whoever wants to create MPEG4-AVC (H.264) shall abandon the AVI container, and therefore a VfW codec as well. AVI does not completely support B frames, multiple references, or the difference between I and IDR frames.

2) The encoder "x264" has a lower-case x. The FourCC "X264" is not "the best FourCC" (if you used MP4 or MKV instead of AVI, you did not even need to care about that).

3) Absolutely slower calculation does not necessarily mean absolutely better quality. Especially not for a restricted encoding profile required for DXVA compatibility. The speed preset "Placebo" is exaggeration, not practicable. I would not even be certain if 9 reference frames are DXVA compliant...

[hopstiii]

:eek:

1) Whoever wants to create MPEG4-AVC (H.264) shall abandon the AVI container, and therefore a VfW codec as well. AVI does not completely support B frames, multiple references, or the difference between I and IDR frames.

What if i put that avi afterwards to mkv container with mkvmerge GUI?
-------
L4.1 standard is max 9 reference frames at 720p and 4 reference frames at 1080p. That was in wikipedia. Haven't tested it out jet (blender is still rendering animation (3 days more).

[kypec]

What if i put that avi afterwards to mkv container with mkvmerge GUI?
Why not use x264 CLI -> MKV/MP4 directly and save yourself the trouble of re-muxing?

[gngn]

revision 3035: "Fixed current time goes beyond end of file time (Happens when stepping/jumping)" Apr 16, has introduced a bug: if i open MPC-HC and select from Favorites a file that also has the "Remember position" checked, the file will not start from the saved position, but from the beginning. if i try it again without first closing MPC-HC's window, then it works, the file will play from the saved position.

[Ger]

Thanks for the info. I can confirm the issue. I did notice some weirdness yesterday, but didn't really think about it.

If a fix can't be made quickly, please revert 3035 (one line of code) in the meantime, as this can get very annoying for "Favorites" users.

[hopstiii]

Why not use x264 CLI -> MKV/MP4 directly and save yourself the trouble of re-muxing?

What's best of them:
Handbrake, Xvid4PSP, StaxRip, RipBot264, FairUse Wizard, MEGUI, AutoX264, HDConvertToX.

Im looking something that can mux atleast flac audio and x264 video, and x264 encoder GUI has fully featured options (no 16000 max bitrate.

Old days i used mediacoder but that's very unstable.

I like ripbot264 but that was somewhat not fully featured, but best so far. Megui crashed, seems unstable or not foolproof like i :p

[fastplayer]

^You're off-topic.

[nurbs]

What if i put that avi afterwards to mkv container with mkvmerge GUI?
If you do that the video will be stored in VfW compatibility mode. MKVs normally contain native H.264. Depending on how well the players stick to the MKV spec you might run into trouble, or not. The thing is that most people don't use VfW to encode H.264, so if there are problems there is a good chance that they are not widely known.
I think demuxing the avi to raw streams and muxing those with mkvmerge works, if you don't mind the extra effort.

[sneaker_ger]

If you do that the video will be stored in VfW compatibility mode.

mkvmerge converts VfW H.264 to native format by default.

[hopstiii]

Thanks for info :), and i'm sorry for offtopic :o

[alexins]

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

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

Add : MPEG-4 ASP bitstream decoder support;
Fix: rev. 3035 - it's broken open from favorites with remember position;
Fix: temporary fix "YV12 Chroma Upsampling" for Ati - thanks to judelaw;
Change: remove "BPP" from resolution list in FullScreen page.

[quasit]

Why isn't there an English site for the nightlies?

MPCHC doesn't seem to support PCM/LPCM? When I close the warning the video plays but no audio. Works fin with XBMC.
Warning message: http://pastebin.com/WknqTs3P

[Damien147]

Changes (3042-3043)

Fix: temporary fix "YV12 Chroma Upsampling" for Ati - thanks to judelaw;


Just tested,thanks from me too judelaw.Works with avi files,with mpeg2,mkv file I tried it doesn't.

Just a note for ati users,if using external decoder you still have to activate the shader.

[nevcairiel]

Why isn't there an English site fore the nightlies?


You can get builds from here if you don't trust the russian page :p http://xhmikosr.1f0.de/

Its not really a "site", just a file dump, but it has nightlies for mpc-hc and ffdshow, and other things.

[suanm]

I want built-in second subtitle in mpc-hc,I'm expecting author for mpc-hc can add built-in second subtitle in mpc-hc

[suanm]

thank author in mpc-hc in advance

[fairchild]

Fix: temporary fix "YV12 Chroma Upsampling" for Ati - thanks to judelaw;
[/LIST]

Dumb question but, is this needed at all if you use ffdshow for decoding along with (High Quality YV12 to RGB Conversion + Dithering)?

I'm guessing no, but thought I'd ask anyway. :)

[fastplayer]

^Fortunately, no.

[alexins]

Can someone give me a link for English RC translation file? I cannot seem to find it in the trunk.

/src/apps/mplayerc/mplayerc.rc

[Superb]

Hebrew translation for the installer: http://www.sendspace.com/file/3d4fhz (directly from today's trunk; rev3045)

The only thing I didn't know what to write was the language id:
he.langid=00000000 // FIXME

Will try to translate the rc, next...

[ceb]

I just wanted to say that my problem with EVR CP seems to be resolved, I'm using version 1.5.2.3045 64-bit BE Mod.
Looking at the changelog I think it's the "temporary fix "YV12 Chroma Upsampling" for Ati" although not being an expert I may be totally wrong.
Anyway, thanks judelaw!

[fastplayer]

Revision 3046
Modified Wed Apr 20 17:41:23 2011 UTC by xhmikosr

go back to using SSE for MSVC2010 builds too, now that SP1 is available
Many thanks from my T-Bred 2600+! :D

[Ger]

Fix: rev. 3035 - it's broken open from favorites with remember position;
Fix: temporary fix "YV12 Chroma Upsampling" for Ati - thanks to judelaw;


@Aleksoid and judelaw :thanks:

EVR-CP chroma issue introduced in 2837 is indeed fixed with default 8-bit surface and ATI (I've only tested with r3045 BE mod rather than trunk, but that shouldn't matter). Can also confirm that the favorites issue introduced in 3035 is fixed. Your contributions are very much appreciated. The latest revision is once again the greatest revision AFAIAC. :)

Just a note for ati users,if using external decoder you still have to activate the shader.

Not confirmed. NV12 and YUY2 (and HQ RGB32 as before) from ffdshow to EVR-CP are now working fine for me without shaders. I'm guessing your external decoder is outputting RGB32 but without the High (Full) Quality conversion.

What this fix does AFAICS is to use X8R8G8B8 surface rather than A8R8G8B8 when an ATI card is detected (and no 10, 16, 32 bit surfaces are enabled in renderer settings), and that is apparently enough to get rid of the blocky reds.

So as long as none of the 10-bit or HFPP/FFPP options are checked (as long as the surface is X8R8G8B8), the shader isn't needed for ATI anymore, much like in EVR Sync and in r2836 and earlier. If you're feeding non-HQ RGB32 from the decoder or using either of the 10-bit/FP options it seems you'll still need a shader to get rid of the blocking issue with ATI.

Interesting to note that the same fix also cured ceb's black screen with Catalyst 11.3 and BE mod problem that I was unable to reproduce.

BTW, I think we established Nvidia isn't affected, but does anyone know if a similar check is also needed for Intel?

[Damien147]

@Ger
You are right,I had FFPP on.

By the way guys,is there any point of having ffpp enabled with nv12 output?