Media Player Classic - Home Cinema (MPC-HC) - v1.7.13

[GCRaistlin]

When I use Alt+I to capture a snapshot, after entering the filename and clicking Save, instead of the dialog immediately closing I have to click Save again. In fact Save seems to act like Cancel.

Worse, I find that on about 10% of occasions Alt+I stops working (possibly after much use of Ctrl+Arrow to advance forward and backward) and the only option is to re-open that clip.


I confirm this, it happens to me too.

[Armada]

Thank you, duly removed!

I've no idea how it got switched ON.

--
Terry, East Grinstead, UK
It's a default option, it's switched on unless you turn it off.

[terrypin]

It's a default option, it's switched on unless you turn it off.

Yes, I know, but it was OFF for as long as I can remember. Then suddenly ON.

Perhaps my setting wasn't preserved when updating to the last version?

--
Terry, East Grinstead, UK

[Sparktank]

Is there any chance/news of Matroska's PixelCropXXX tag being supported? (when "--cropping x,x,x,x" is stated when remuxing with MKVmerge; recognized in VLC)
https://trac.bunkus.org/wiki/FAQ%3ACroppingIgnored

I did some googling and searching through the MPC-HC site and found a pull request from last April that didn't seem to progress.
I use MPC-HC as my main media player and often forget there are others installed.
The PixelCrop recognition would be neat for remuxed BD's.

[Thunderbolt8]

thanks for fixing this annoying nvidia related mpc startup message

[GCRaistlin]

I'd like to remind the developers about the feature I asked a long time ago - to allow switching to a particular PGC while playing an IFO file that contains multiple PGCs. It would allow to play such files with external audio tracks and external subtitles.

[sergeo78]

anyone else can gather the latest release of mpc-hc lite under math: IA32 noSSE. or place the source code that I had myself collected in 2010 studio.

[vBm]

I'd like to remind the developers about the feature I asked a long time ago - to allow switching to a particular PGC while playing an IFO file that contains multiple PGCs. It would allow to play such files with external audio tracks and external subtitles.
devs rarely read d9. make a request on https://trac.mpc-hc.org/ unless there is one already.

[GCRaistlin]

It's been made there 8 month ago...

[Mangix]

It's been made there 8 month ago...

I made a report 3 months ago about a different issue. Same deal.

[nevcairiel]

MPC-HC is a open source project. The developers do all the work in their spare time, and because of that they usually work on issues that interest them personally.

In consequence, while feature requests are always welcome, there is no guarantee on when they will be implemented, or if at all.

[NikosD]

MPC-HC is an open source project, referring to users.

Users do all the work of testing features and trying different configurations to find bugs, in their spare time.

They are not professional beta testers, they aren't paid for testing and using MPC-HC to check and test features and find bugs.

If the developers want to implement only their own stuff (what they have in mind about the program), without respecting and listening what users say about these or other user requests, then probably developers will be left alone, testing and using their own programs on their own features/requests/plans.

So, we need two to tango.

[GCRaistlin]

I didn't really want to demand anything from devs, I'm just reminding and maybe hope to find some other users who would find the feature (https://trac.mpc-hc.org/ticket/3656) useful and vote for it.

[vBm]

I didn't really want to demand anything from devs, I'm just reminding and maybe hope to find some other users who would find the feature (https://trac.mpc-hc.org/ticket/3656) useful and vote for it.

I made a report 3 months ago about a different issue. Same deal.

Like nev said, they do this in their SPARE time, so ... they don't have to respect nor listen to any of us at all.
At one point all of 'em were just regular users that decided to step up and fix/implement something that was bugging 'em for quite some time. It's just the way it is.

Also keep in mind that it's not necessarily true that each and every dev has knowledge about everything that is going on in project. Maybe no one knows about your particular issue , on how to fix it that is.

[Raylan Givens]

Guys wouldn't be great if the devs could get rid of years old code, drop support for XP/Vista and start taking advantage of some of the new features Win7/8/8.1 have to offer?

[GCRaistlin]

Guys wouldn't be great if the devs could ... drop support for XP/Vista

Definitely no.

[clsid]

Guys wouldn't be great if the devs could get rid of years old code, drop support for XP/Vista and start taking advantage of some of the new features Win7/8/8.1 have to offer?And which features would that be? It seems this suggestion is hypothetical and you don't even know what you are asking for.

MPC-HC already has functionality that is specific for Win7/8. For example taskbar preview.

Providing such functionality does NOT require removing support for XP. MPC-HC is able to check which version of Windows it is running on. It basically requires just a single line of extra code. So its trivial, easy, and requires no real effort at all.

The only real reason to drop XP support would be if a future version of Visual Studio also drops it, and that version becomes a requirement for building MPC-HC. That could take a few years.

Apart from the lack of security updates (for consumers), XP still works the same as it did a few months ago. I am no fan of XP, but 25% of the world still uses it, so no reason to drop it over bullshit reasons.

[filler56789]

Hmmm.... since MPC-HC uses LAV Filters as a replacement for the old internal filters,

shouldn't the MPC-HC "nightly builds" be updated every time nevcairiel updates the source-code of LAV Filters? :confused:

[Armada]

Hmmm.... since MPC-HC uses LAV Filters as a replacement for the old internal filters,

shouldn't the MPC-HC "nightly builds" be updated every time nevcairiel updates the source-code of LAV Filters? :confused:
We update the internal LAV Filters every time there is a release or when there is an update that fixes an issue our users are experiencing. Blindly updating the internal filters to untested versions of LAV Filters invites stability problems.

But since we dynamically link to LAV Filters you can also replace the internal filters with your own compiled version if you want. However if you do that and have an issue, related or not, please note in the ticket that you are using a custom internal filter.

[minaust]

Guys wouldn't be great if the devs could get rid of years old code, drop support for XP/Vista and start taking advantage of some of the new features Win7/8/8.1 have to offer?
Absolutely not!!!!:(

[Motenai Yoda]

Question-time:
with lavfilters (now internal) what rgb levels should be setted?
Isn't better set "untouched" and let evr or madvr do the levels correction? (I just realized that I could be so much wrong.)

[nevcairiel]

Question-time:
with lavfilters (now internal) what rgb levels should be setted?
Isn't better set "untouched" and let evr or madvr do the levels correction? (I just realized that I could be so much wrong.)

EVR is unable to do proper correction, if you use EVR, then you probably always want "Full".

With madVR, it doesn't matter at all, since the code that requires this setting is never going to be used (unless you force it to by disabling all other output formats).

[vBm]

v1.7.6 is released
This release has a couple new features, many subtitle performance optimizations and bugfixes, as usual.

Highlights of this release:


Move the user interface language selection to the Options dialog
Many improvements and fixes for subtitles including:
- Support loading external PGS subtitles
- Faster subtitle parsing (around 20%)
- Reworked “Default Style” option
- Improve internal renderer compatibility with VSFilter behavior for anamorphic videos
- Fix override placement option

You can download the new version here (http://mpc-hc.org/downloads/). For the complete changes see the changelog (http://mpc-hc.org/changelog/).

[Megalith]

Looks like the zoom issue has been fixed, great!

[nuhkka]

how do you make it so it auto-crops the black bars on the side if the video is too big for your screen? last version had it but this newest one doesn't

[Raylan Givens]

Guys, can I please have a kinda short answer? Intel's QuickSync or the good ol' DXVA Native?

[detmek]

Whatever works better and more stable for you. Also:
http://www.anandtech.com/show/7007/intels-haswell-an-htpc-perspective/5

[Raylan Givens]

Thanks, bro!

The thing is, both work fine but I notice even less resources being used when DXVA Native is the choice. I'm gonna read that page on anand now, thanks again.

[foxyshadis]

DXVA Native is always faster and lower power, when it's supported. Quicksync lets you do cool things to the video, like adding subtitles (though some renderers support this natively now). Use the latter if you want its extra capabilities, use the former the rest of the time. Most people won't notice the difference.

[Stereodude]

how do you make it so it auto-crops the black bars on the side if the video is too big for your screen? last version had it but this newest one doesn't
Right click on the video when it's playing and pick Video Frame, Touch Window From Outside.

[Soukyuu]

Has anyone done a performance comparison between the ISR and xy-Subfilter? I saw ISR can now handle anamorphic subtitle positioning correctly, so is there still a need for xy-Subfilter?

[huhn]

correct colors very hard typeset

[Soukyuu]

Sorry, could you elaborate please? I assume you mean there are scenarios where colors are not correct for ISR, as well as it being slower for complex typesets?

[huhn]

a video is YCbCr and needs is rendered to rgb but how ?

bt 709 or 601 or even 2020. the subtitle are rendered in a colorspace too and that doesn't always match the video colorspace.

so in a lot of cases you need 601 for subtitle and 701 for video. XY vsfilter and xy subfilter can deal with it. i don't think any other renderer can do the same. i haven't check this in a long time and the last time i saw performance comparison xy vobsub was a lot faster.

[JanWillem32]

The situation is actually worse than that. There are quite a few more parameters that the old VSfilter messed up rather than just failing to adapt to any other Y'CbCr specification than the one used in BT.601, and that's just for the ASS2/ASS/SSA-type subtitles. Remember that there are quite a few more types of subtitle sources, which usually fail to render properly with the old VSfilter.
The color quantization, color gamut and transparency quantization used by any of the existing subtitle types are abysmal as well. I dare to say that getting matching subtitle colors with video of decent quality is impossible at this moment.

[kasper93]

And bottom line is that ISR works very good for most typesets out there and unless you really have some samples that fail I see no point in using any alternative. ISR is way more user friendly. There is so much hate from the old days, but things are different now, really.

And as always if you have samples that fail in anyway with ISR please send them to https://trac.mpc-hc.org/ .

[huhn]

and you are sure you like any color miss match with the mpc-hc ISR as sample?

[kasper93]

Like I said if your samples works with (mpc-hc's) ISR you can use it. Proper subtitles are adjusted for the video and works just fine.

[huhn]

i run in a out of memory bug with the ISR and MadVR. xy subfilter work total fine. if you use control + left arrow key the subtitle will disappear and the player will run out of memory when playback is started and no subtitle is shown.
i use a 128 decoder buffer with MadVR for livestreamer this has most likely something to do with this normal playback is at about 850 mb~ totally save with a 64 bit os.

i can PM you a sample if you like.
it is rendered totally wrong too.

Proper subtitles are adjusted for the video and works just fine.

by default aegisub forces bt 601 and uses bt 601 for YCbCr->RGB so if you don't know this and didn't change this to bt 709 you get wrong colors with ISR on a bt 701 source. XY subfilter doesn't have a problem with that it knows what was used for the subtitles and it knows what MadVr uses so it doesn't matter.

on this small sample i used the color was different the ass was done with bt 601 and the file is bt 709.


i can't use the ISR anyway because i use a 3D lut and the ISR doesn't know about this. most people don't use a 3d lut so this is no real problem just a limitation for 3d lut user.

[vivan]

by default aegisub forces bt 601 and uses bt 601 for YCbCr->RGB so if you don't know this and didn't change this to bt 709 you get wrong colors with ISR on a bt 701 source.... because aegisub is broken?

Colors in ASS are defined as RGB values, period.

[madshi]

... because aegisub is broken?

Colors in ASS are defined as RGB values, period.
That may be correct in theory. But...

Which program was virtually every ASS file created with? Yes, aegisub. Of course you can claim that all ASS files on the planet earth are invalid/broken and simply refuse to render them "as intended" by the ASS author. But if you do that, you don't develop for end users, but you're just stubbornly following a spec which has no real world meaning, IMHO. We developers have a responsibility to find solutions that allow end users to have the best possible experience.

Just my 2 cents, of course.

[kasper93]

I'm not saying ISR is perfect, I know it isn't but it works well for many users. We are trying to improve it and it will get only better.

@huhn: Please send this sample. Any sample helps us.

I agree with madshi, though if everyone tell "ISR is garbage, don't use it" it doesn't help in anyway. MPC-HC is open source we make changes for it in our spare time and would really love to get more contributions from community. But well it is how it is.

[madshi]

FWIW, I've no problems with the ISR at all and no plans to reduce/remove support for it. If there are wishes/ideas for how to further improve it, I'm willing to add more work into it, too. More options for end users is always a good thing. There will be some new madVR features coming soon (masking, automatic black bar detection/removal etc) which might put XySubFilter at a certain advantage due to higher integration / more communication with the video renderer, though, and I do believe that the new subtitle interface used by XySubFilter is technically superior to the ISR interface, but in the end the end user experience is the one and only important thing. It should be possible to tune the ISR for these new madVR features, too, if the ISR devs want to do that.

The ASS color matrix issue could also be solved within the ISR by asking some additional information from madVR. The ISR could call "IMadVRInfo.GetString("yuvMatrix", ...)" to ask which YCbCr -> RGB matrix madVR is using and use this to perform the necessary conversions to display color matched ASS subtitles as intended by the ASS author. Here's a little sample you can use to test the color matching:

http://madshi.net/assColorSpace.mkv

[JanWillem32]

There's also the option to just send the texture COM pointers from the ISR to MadVR in combination with vertices. As you might expect, the video renderer I edit doesn't even use remotely similar methods as the methods in place for the external renderers at the moment. (The subtitles should be blended and pixel shaded to compensate the botched color conversion before the video renderer applies color management, dithering and such.)

[huhn]

... because aegisub is broken?

Colors in ASS are defined as RGB values, period.

but how do we get these RGB colors. the video is YCbCr so we have to transform this to RGB.
we know about colorspaces but the normal subtitle creator didn't know about this but thanks to the current behavior of aegi it doesn't matter if the creator doesn't have a clue about this topic. the video is converted with BT 601 and all RGB values are based on the video the ASS file has a line with BT 601 in it so we have all info to display the video in any colorspace and correct colored subs for it.

so let's think about doing this right. we take a BD with BT 709.
Aegi uses BT 709 for conversation and adds BT 709 in the ASS.
now we go and downscale it to 480p because the source is not worth 720p or 1080p and add the colorspace to the H264 stream. EVR still uses BT 601 for the video and ISR will use BT 709 so we get broken subtitle color again. now we can argue that EVR is broken.
VLC uses BT601 any way for everything so we get wrong colors there too.


so the current Aegisub behavior makes it easy for the creator and the current XY subfilter filter can deal with it so a win win situation for the user.
so giving the ISR a way to correct the colors is the right way in my eyes not changing the subtitle creating process. this way we get correct color with matching colorspaces and with not matching colorspaces. a win win situation for the end user again.

i should write longs text in english i'm sorry.

[JanWillem32]

The colors in ASS are actually defined as 8-bit R'G'B'(A) of unknown XYZ-relative primaries, but with an implicitly defined Y'CbCr-R'G'B' conversion (the BT.601 type). This means in practice that you have to convert the R'G'B' colors to Y'CbCr with the BT.601 matrix if the video is of another type, and then do onward transforms using the video's own Y'CbCr to R'G'B' to RGB to XYZ transforms to achieve absolute color.
This situation is just ridiculous. The organizations that design tv and other user-grade video standards have failed on a lot of occasions to produce decent standards in the past 62 years (and there is still no user-grade video standard that can match common studio formats of over fifteen years ago), but they never made blunder as big as the color "specification" in the old VSFilter.
Also, down-scaling a video doesn't have to mean that the Y'CbCr to R'G'B' to RGB to XYZ transforms have to change. Files can be tagged with BT.709 or SMPTE 240M just as easily on video streams that we don't usually qualify as (user-grade) 'HD'. For studios this is uncommon though. They convert from absolute color (while trying to make the video look acceptable when encoding to consumer-grade video standards) directly to correct BT.709, BT.601 NTSC, BT.601 PAL/SECAM or SMPTE 240M video, depending on the destination media. (Note the distinction between NTSC and PAL/SECAM, they actually do have different RGB to XYZ transforms.) These all have different Y'CbCr to R'G'B' to RGB to XYZ transforms. When applying the same botched ASS color subtitles, you can only match either the BT.709, the BT.601 NTSC, or the BT.601 PAL/SECAM version because of this bug.
Correcting this bug would require a color standard for the successor of SSA/ASS/ASS2 that can be directly related to absolute color (preferably including standard observer specifications similar to the ITU-R BT.1886 standard so that white points can be adapted or by using direct specification of the white point handling per subtitle file). This is actually already the case for the DVD, BD and DVB subtitle types.

[kasper93]

The ASS color matrix issue could also be solved within the ISR by asking some additional information from madVR. The ISR could call "IMadVRInfo.GetString("yuvMatrix", ...)" to ask which YCbCr -> RGB matrix madVR is using and use this to perform the necessary conversions to display color matched ASS subtitles as intended by the ASS author. Here's a little sample you can use to test the color matching:

http://madshi.net/assColorSpace.mkv

I have already fixed color space and luminance range for PGS/DVB subtitles so all we need to do is to adjust ASS rendering path.

Thanks for the sample. This might be dumb question, but what I suppose to see? I might be tired, but actually I think "background" text should be the same color and I should see both borders all the time? Or quite the opposite? Because to my logic EVR-CP display it fine...

[madshi]

I have already fixed color space and luminance range for PGS/DVB subtitles so all we need to do is to adjust ASS rendering path.
It would be nice if you could ask the YUV->RGB matrix from madVR and use that for the ISR color corrections, if possible.

Thanks for the sample. This might be dumb question, but what I suppose to see? I might be tired, but actually I think "background" text should be the same color and I should see both borders all the time? Or quite the opposite? Because to my logic EVR-CP display it fine...
Here's how it looks like with the ISR and XySubFilter on my PC:

ISR (http://madshi.net/ISR.png) -|- XySubFilter (http://madshi.net/XySubFilter.png)

The background of the first line should be invisible. It's not when using the ISR on my PC. However, I'm not using the very latest MPC-HC version atm...

[sneaker_ger]

Disregard madshi's sample file - it uses experimental tagging that has become deprecated. I made a fixed version:
http://www.file-upload.net/download-9195431/assColorSpace_fixed.mkv.html

[dansrfe]

Anyone know what I can do if setting a renamed mpc-hc.exe to use "High-performance NVIDIA processor" doesn't work? The player itself freezes and the result is the same for any renderer I use. Including madVR. I would prefer to restrict mpc-hc to using the discrete GPU.

Things I've tried: updating intel hd drivers, updating nvidia drivers to latest stable, installing D3D9 web installer.

System (XPS 15): 4712HQ (Intel HD 4600), GT 750M