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

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