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

[clsid]

Seems more logical to do a x*y check. In the example above only the width has a high value, which is typical for subs.

[JanWillem32]

I really hate checks like these that go by any assumptions. What is the cold, hard texture size limit for this renderer? It obviously can handle more than 4000 pixels.
If it is just a memory issue;
The only memory limit you can assume is the addressing limit of a particular system; 32 bits for unsegmented x86-32, 48 bits for segmented x86-32 and 64 bits on x86-64. For all other address/memory statuses, we query the operating system. Usually we omit such an extra check, and just check if an allocation function fails.
Although the person that programmed the next part of the memory allocation routine really lacked any decent programming skill (there is a check for a nullptr after regular operator new in the code), I see no problem in using the usual method of letting the memory allocator gracefully fail in this particular routine.

[JEEB]

Just to make it clear, I hate such arbitrary "sanity checks" as well. :)


If it is just a memory issue;

Yes, it is just a memory issue. Memory issue because if your script happens to have either a typo or an insane thing it can quite possibly just go through your local process's memory space limit :) (esp. with 32bit Windows). Unfortunately I've had the "pleasure" to receive reports on such things getting into the wild.


For all other address/memory statuses, we query the operating system. Usually we omit such an extra check, and just check if an allocation function fails.
Although the person that programmed the next part of the memory allocation routine really lacked any decent programming skill (there is a check for a nullptr after regular operator new in the code), I see no problem in using the usual method of letting the memory allocator gracefully fail in this particular routine.
Agreed. So switching that new statement later on (mpScanBuffer = DEBUG_NEW unsigned int[mHeight];) to a malloc should be the real fix and should let the null pointer check do its work instead of breaking havoc? I think I'll try that with one of the samples that were problematic, actually.

Edit:
No, it still crashes with an insane sample I was pointed towards before on a 32bit Windows XP, even if that new is changed to be a malloc, and it is then checked. This (http://www.cccp-project.net/beta/test_files/hadena_maoyuu_isr_xy_crash_sample.mkv) is the sample in question.

// mpScanBuffer = DEBUG_NEW unsigned int[mHeight];
mpScanBuffer = (unsigned int*)malloc(mHeight * sizeof(unsigned int));
if (!mpScanBuffer) {
TRACE(_T("Error in Rasterizer::ScanConvert: mpScanBuffer is NULL"));
return false;
}

Any other ideas on how to properly fix this?

[JanWillem32]

For that particular one, malloc() returning a nullptr on failure is at least standard behavior, and can be checked. Using other options such as nothrow new or system calls probably don't have any advantages in this case.
There are actually numerous errors in various allocation routines. In terms of handling memory, PartialEndPath() is probably the worst. Examples:
-DebugBreak() is followed up after failing something. DebugBreak() compiles to assembly "int 3": a hardware interrupt that is only recoverable if a debugger is attached. It is useful in debug builds in debug mode, but not there.
-The checks after realloc() are bad. I don't have to comment on this part, I think...
-And again usage of regular operator new twice without facilitating its throw part for failures. I see this issue everywhere in the code. It's okay for debug and temporary code to assume things won't throw, but it's not acceptable for any release.

As there are some checks after GDI calls and there is staging in the rendering passes, the people who wrote this must have read some sort of programming cookbook at least. However, I don't understand why there are such basic errors in the programming everywhere.

[JanWillem32]

Edit:
No, it still crashes with an insane sample I was pointed towards before on a 32bit Windows XP, even if that new is changed to be a malloc, and it is then checked. This (http://www.cccp-project.net/beta/test_files/hadena_maoyuu_isr_xy_crash_sample.mkv) is the sample in question.

// mpScanBuffer = DEBUG_NEW unsigned int[mHeight];
mpScanBuffer = (unsigned int*)malloc(mHeight * sizeof(unsigned int));
if (!mpScanBuffer) {
TRACE(_T("Error in Rasterizer::ScanConvert: mpScanBuffer is NULL"));
return false;
}

Any other ideas on how to properly fix this?Are you certain that this particular allocation is the point in the code that's directly crashing? I saw it take 8545269 * 8 on input, which is a little over 65 MB, and only once. That's not really a lot. What sort of crash was it, anyway? I've actually never seen malloc() crashing.

[JEEB]

Are you certain that this particular allocation is the point in the code that's directly crashing? I saw it take 8545269 * 8 on input, which is a little over 65 MB, and only once. That's not really a lot. What sort of crash was it, anyway? I've actually never seen malloc() crashing.
It can be somewhere else, let me transfer the crash dump from the virtual machine to this laptop, and check the actual backtrace. The glyph that is the problem in that sample gives an error "[ass] Glyph bounding box too large: 614x667599px" in libass, which should tell you about the size of that thing :)

Edit:
Sorry for the commotion, I don't seem to be able to replicate the crash with the ISR any more with or without that change of new to malloc, if it ever crashed on my VM with VMR7 or Haali's renderer... The triangle does seem to come up, but I am not exactly sure how big it ends up being rendered. The screen resolution of my VM is 800x600.

An older MPC-HC VSFilter crashes, though, and the one I was testing all the time (xy-VSFilter) follows suite. After trying to see where the hell the latter crashes for a few hours, I no longer have the power in myself tonight to check if a current MPC-HC VSFilter with that new->malloc change crashes or not with that sample. Maybe tomorrow. That is all I have to report for now...

Edit2:
Actually yes, just built an MPC-HC VSFilter with that new->malloc change and it does crash as well. Backtrace:

> VSFilter.dll!Rasterizer::Draw_noAlpha_sp_Body_sse2(RasterizerNfo & rnfo={...}) Line 1311 C++
VSFilter.dll!Rasterizer::Draw(SubPicDesc & spd={...}, CRect & clipRect={...}, unsigned char * pAlphaMask=0x00000000, int xsub=0, int ysub=0, const unsigned long * switchpts=0x0315f92c, bool fBody=true, bool fBorder=false) Line 1548 C++
VSFilter.dll!CLine::PaintBody(SubPicDesc & spd={...}, CRect & clipRect={...}, unsigned char * pAlphaMask=0x00000000, CPoint p={...}, CPoint org={...}, int time=0, int alpha=0) Line 1040 C++
VSFilter.dll!CRenderedTextSubtitle::Render(SubPicDesc & spd={...}, __int64 rt=95190000, double fps=30.303030303030305, tagRECT & bbox={...}) Line 2805 C++
VSFilter.dll!CSubPicQueueImpl::RenderTo(ISubPic * pSubPic=0x02bbebbc, __int64 rtStart=95190000, __int64 rtStop=95520000, double fps=30.303030303030305, int bIsAnimated=1) Line 130 C++
VSFilter.dll!CSubPicQueue::ThreadProc() Line 466 C++
VSFilter.dll!CAMThread::InitialThreadProc(void * pv=0x02bba9a8) Line 117 C++
VSFilter.dll!_callthreadstartex() Line 314 C
VSFilter.dll!_threadstartex(void * ptd=0x02bbaa58) Line 292 C
kernel32.dll!_BaseThreadStart@8() Unknown

Also suddenly VS12 doesn't want to take in my MPC-HC binary for whatever reason... So I am not 100% sure if this backtrace is correct, but replicating this crash should be rather easy >_> . 32bit OS + 32bit build and that sample should do it.

[betaking]

S.Chinese update
http://www.sendspace.com/file/h7r7gv
PS: to all dev last mpc-hc git include/version.h bump version still 1.6.7 not 1.6.8!
:D may be XhmikosR forget to change?

[heyer]

Is there any way to open named pipes with MPC-HC?

[vBm]

S.Chinese update
http://www.sendspace.com/file/h7r7gv
PS: to all dev last mpc-hc git include/version.h bump version still 1.6.7 not 1.6.8!
:D may be XhmikosR forget to change?

Thanks for the update, should be pushed soon.
EDIT: Pushed as 3be9b80 (https://github.com/mpc-hc/mpc-hc/commit/3be9b80ce2c699643f1bcfd8f7fc3abb0a9ccbd1) (comment added that you were author because we forgot to change it when doing a commit. Sorry for that.)

And yeah, he forgot to push version bump to main repo. Pushed as of 7ae4697 (https://github.com/mpc-hc/mpc-hc/commit/7ae4697a110ab5632e1a7d5d793e641a5a635415)

[JanWillem32]

heyer, about named pipes and other UNC names; MPC-HC could easily support them, but its input device and file verification system is really flawed on first inspection. I'll see if I can fix that right now...
update:
I fixed some parts of the file opening system and disc handling parts to be able to better interpret UNC and other network names. I can't add support for the feature of path names longer than 260 characters, as that would take a lot more work. If anyone wants to try; I uploaded two binaries.
single-issue only tester builds deviated from revision 7112: (does not include my regular stuff)
x64: http://www.mediafire.com/download.php?kbrtc2kzbjwstbx
x86 SSE2: http://www.mediafire.com/download.php?x4aa3d4ll4rjv3h

JEEB, about that error, Line 1311 of rasterizer.cpp is a comment. Draw_noAlpha_sp_Body_sse2() doesn't do any allocations by itself, so it's a bit odd. You also didn't mention the exception code/name and possible address. Do you have a dump file? Maybe I can analyze anything from that. Setting up a PC to test a 32-bit OS would take a while. (I haven't used 32-bit Windows installs since late 2007, so I don't have any 32-bit setup disks, nor do I have extra licenses.)

[wanezhiling]

http://pan.baidu.com/share/link?shareid=457911&uk=3558042035

MPC-HC: 3min25s, wrong
LAV Splitter: 3min34s, accurately correct

[JEEB]

JEEB, about that error, Line 1311 of rasterizer.cpp is a comment. Draw_noAlpha_sp_Body_sse2() doesn't do any allocations by itself, so it's a bit odd. You also didn't mention the exception code/name and possible address. Do you have a dump file? Maybe I can analyze anything from that. Setting up a PC to test a 32-bit OS would take a while. (I haven't used 32-bit Windows installs since late 2007, so I don't have any 32-bit setup disks, nor do I have extra licenses.)
My version of the MPC-HC source tree isn't too old (de5611c, Apr 17th), but it seems like line 1311 in it for MSVS is the first alpha_blend_sse2 call inside Draw_noAlpha_sp_Body_sse2 (line 1321 (https://github.com/mpc-hc/mpc-hc/blob/master/src/Subtitles/Rasterizer.cpp#L1321) in current github). Most probably some memory allocation goes wrong before that, or something just goes plain wrong within that function. Or the stack trace is completely bonkers...

Exception code is 0xC0000005, which is the "Read/write to a virtual address for which it does not have the appropriate access" one. Which generally means "Segfault due to null pointer somewhere that was getting accessed."

Also I finally got MSVS to read the debug symbols for the MPC-HC build used in this all, but the reason of crashing didn't change at all.

Locals for the crashing point were:

+ s 0x0012f888 <Error reading characters of string.> unsigned char *
gran 0 int
end_gran 12 int
color 0 int
h 44302592 int
color2 44302336 int
end_w 1376256 int
- rnfo {w=616 h=620 spdw=1280 ...} RasterizerNfo &
w 616 int
h 620 int
spdw 1280 int
overlayp 616 int
pitch 5120 int
color 4294964746 unsigned long
xo 0 int
yo 0 int
+ sw 0x0315f92c {4294964746} const unsigned long *
+ s 0x00000000 <NULL> unsigned char *
+ src 0x00000000 <NULL> unsigned char *
+ dst 0x0c7fd1b0 {???} unsigned long *
+ am 0x0001f464 <Error reading characters of string.> unsigned char *


P.S.
Microsoft gave out 32bit XP licenses for virtual machines with, among other things, certain Windows 7 versions (howto (http://blog.zeltser.com/post/15781390680/windows-xp-mode-for-vmware-virtualization) on how to use it in VMware). Also virtual machines for web development that contain XP are IIRC also available (link (http://www.modern.ie/en-us/virtualization-tools#downloads)). Not to mention that if you just do not input a license key during the installation, you will be able to test the OS for a limited amount of time, which is enough for a couple of tests :) .

P.P.S.
The recommendation from nielsm/jfs was to use a sanity test like this in general:
<@jfs> JEEB: that's my suggestion, check for (x*y)>(1<<26)

[JanWillem32]

That's a lot better. I just put a simple debug session on one of my samples that contains a complex subtitle. The passed RasterizerNfo structure contains "s" and "src" that point to the same, valid binary input. The allocation of this memory evidently failed in that session, as both are nullptr. That error is left unchecked somewhere. RasterizerNfo's "s" and "src" pointers derive from struct SubPicDesc's "bits" pointer. That pointer is initialized to nullptr by SubPicDesc::SubPicDesc(), and after that it should be assigned by CMemSubPicAllocator::Alloc(). As that function fails on allocating memory, it throws bad_alloc (it will probably be visible as a first-chance exception in your debug session log). As it is never caught, the main routine just continues until it derails at that particular point of the subtitle renderer.
I actually re-wrote CMemSubPicAllocator::Alloc() already some time ago (actually more for the various optimizations I made).
I don't agree on any 'sanity' check based on no hard limitation of the given renderer, hard limitation of the platform total address space or queried limits from the environment. Common servers and workstations are already heading towards multiple terabytes of memory, so unless the expression "(x*y)>(1<<26)" uses a unit vector of quite a lot of bytes, it's again nowhere near platform limitations.

[Aleksoid1978]

Missing PGS subtitle at the start on this file http://aleksoid.voserver.net/Sample/Subtitle/PGS/PGS_Multiple.m2ts

[cyberbeing]

Aleksoid1978, I seem to remember you posting essentially the same sample months ago (PGS_StartBroken.m2ts (http://forum.doom9.org/showpost.php?p=1593106&postcount=20207)) for corrupted display of those first lines, and MPC-HC committed this (https://github.com/mpc-hc/mpc-hc/commit/747bc341764b44e8254bec5a4a1709b96ec0078c) in response. The first PGS subtitle lines in that sample lack a color palette, so they are made transparent in order to follow the PGS/HDMV specification. If MPC-BE handles it differently, what do you use as the color palette?

[Aleksoid1978]

Aleksoid1978, I seem to remember you posting essentially the same sample months ago (PGS_StartBroken.m2ts (http://forum.doom9.org/showpost.php?p=1593106&postcount=20207)) for corrupted display of those first lines, and MPC-HC committed this (https://github.com/mpc-hc/mpc-hc/commit/747bc341764b44e8254bec5a4a1709b96ec0078c) in response. The first PGS subtitle lines in that sample lack a color palette, so they are made transparent in order to follow the PGS/HDMV specification. If MPC-BE handles it differently, what do you use as the color palette?

When parse Palette - fill m_pDefaultPalette.
And then use it - if CompositionObject have no palette.

[JEEB]

When parse Palette - fill m_pDefaultPalette.
And then use it - if CompositionObject have no palette.
Please do correct me if I am reading this incorrectly, but if there is no such palette parsed, then according to the specification the undefined palette values should be transparent, no?

A Palette Definition Segment is not required to carry data for every entry in a Palette and, as defined in Section 9.14.4.2.2.1, by default each Palette entry is assigned a fully transparent color...

and then later in the more technical section 9:

T_value: The Opacity output value for the Palette entry denoted by this palette_entry_id. A value of zero identifies full transparency...

Each Palette entry shall have a default T_value of ‘0’; the default values of Y_value, Cr_value and Cb_value are undefined.


If there is a palette available in the stream so that it can be read and known before those subpictures, then of course this is a bug :)

[Aleksoid1978]

Correct palette parse later then this sample - but before it's render. And when it's render - use m_pDefaultPalette.

[PetitDragon]

Does anyone know for what reason XhmikosR stopped icl13 compiling?

[vBm]

Does anyone know for what reason XhmikosR stopped icl13 compiling?

There's no worth in doing so at the moment. It takes double time to build it and at the moment there's a problem being that compiler is broken. (we have already made (http://software.intel.com/en-us/forums/topic/370930) a bug report and waiting for a fix)

Until that happens we will not provide ICL13 builds.

[clsid]

Plus, the 0.1% increase in performance is not worth the trouble.

[PetitDragon]

Thank vBm and clsid for the answer.

[Reino]

Audio Switcher: Improve normalization algorithm.
Use a much better regain strategy (similar to ffdshow's) and fix the regain rate to be linear rather than completely exponential.I don't understand why anyone has reported this yet, but what exactly is the improvement in this? I always use the Audio Switcher's normalize-feature for (low-volume)movies, but now even without(!) "Normalize" ticked in the Audio Switcher options, everything is clipping frantically; dialogs, music, everything. Not to mention how it sounds with "Normalize" ticked.
Luckily MPC-BE hasn't integrated this commit.

[Underground78]

I don't understand why anyone has reported this yet, but what exactly is the improvement in this? I always use the Audio Switcher's normalize-feature for (low-volume)movies, but now even without(!) "Normalize" ticked in the Audio Switcher options, everything is clipping frantically; dialogs, music, everything. Not to mention how it sounds with "Normalize" ticked.
My bet is that you are using a crazy boost setting (which is unrelated to "normalize" settings) because after that commit the amplification used for normalization tends to be smaller overall... So please double-check your settings and if boost was unrelated, just open a ticket and we will have a closer look. :thanks:

[Reino]

Hah, seems you're right. I never knew a boost setting existed and although I never touched it, it was somehow set all the way to 300%. Putting it back to 0% fixed it.

[Underground78]

Hah, seems you're right. I never knew a boost setting existed and although I never touched it, it was somehow set all the way to 300%. Putting it back to 0% fixed it.

Maybe wrong hotkey but open a ticket if that setting changes from its own will.

[ceb]

I always use the Audio Switcher's normalize-feature for (low-volume)movies...
In regards to this, what is the difference between normalize and boost?
Whenever I have a file with low volume I use the boost slider, should I have being using normalize instead?

[karamancho]

In regards to this, what is the difference between normalize and boost?
Whenever I have a file with low volume I use the boost slider, should I have being using normalize instead?

normalize increases the volume of the quieter parts only, boost amplifies the whole audio

[Virtual_ManPL]

Plus, the 0.1% increase in performance is not worth the trouble.

But wasn't it a 20% boost with ICL12 compared to MSVC2008 when you do decoding+filtering as I recall correctly from 2011 year tests? ;)

[ceb]

normalize increases the volume of the quieter parts only, boost amplifies the whole audio
Wish I had known this before...
Thanks!

[LigH]

This sounds rather wrong to me.

2-pass peak normalization changes the whole volume linearly by scanning the whole audio in the first pass to find the volume peak, calculating one amplification factor, and multiplying the whole audio with this factor in the second pass. Disadvantage: The whole audio has to be scanned once before the peak factor is known; probably not applicable in a media player. Exception: A "replay gain" volume is stored in the audio channel or container already by the encoder, then the normalization factor is already known before playing.

1-pass adaptive normalization (in fact rather a kind of DRC = Dynamic Range Compression) may do that only for a short lookahead window, changing the amplification factor while the audio is being played (a.k.a. AGC = Automatic Gain Control). Disadvantage: Pumping volume when the volume range changes often and briefly.

[nevcairiel]

"Boost" is just a static volume increase, no adaptive anything.
"Normalize" is your standard 1-pass normalization, with all the disadvantages it comes with.

[clsid]

But wasn't it a 20% boost with ICL12 compared to MSVC2008 when you do decoding+filtering as I recall correctly from 2011 year tests? ;)You remember wrong. That was a test long ago for a specific processing filter inside ffdshow, which since then has been rewritten and optimized.

[turbojet]

It's nice to see audio normalization is being worked on. I had always found mpc-hc to have the least amount of volume pumping compared to ffdshow and reclock but still could be improved upon. I watched a few videos with the new fixes and didn't notice any pumping but it also takes specific sounds like loud sudden claps to trigger pumping in the old mpc-hc. It seemed to drop way too low and then regain a lot slower than it should. I'll keep an eye out for a sample.

After giving up on mpc-hc normalization a couple years ago I switched to windows 7 loudness equalization which works great with no pumping, how does it do this? But it comes with one big disadvantage, it affects all audio.

EDIT: Found a decent sample (http://www.sendspace.com/file/889a7i) for testing the normalize. The new code handles it much better than old but the reverb at 2 seconds is quieter than it should be. At least when the guy starts talking it's at the level it should be, it's very quiet with the old. The new doesn't get nearly as loud as the old at 0db (no clipping) boost, even with new boost at 300% (clipping) could this be fixed along with the reverb issue in the sample?

[DrNein]

Nevermind, latest nightly still has no exit problem. I'll go back and see if I can find out where it started.

I have encountered this problem too (after exit/close, the process remains running).

MPC-HC.1.6.5.6366.x86 okay
MPC-HC.1.6.6.6957.x86 process remains
MPC-HC.1.6.7.7114.x86 process remains

[Armada]

I have encountered this problem too (after exit/close, the process remains running).

MPC-HC.1.6.5.6366.x86 okay
MPC-HC.1.6.6.6957.x86 process remains
MPC-HC.1.6.7.7114.x86 process remains
This is a known problem and has been fixed (https://github.com/mpc-hc/mpc-hc/commit/9c5bdfe645a41622e6fd4bfa471ff55014a62e30) in the nightlies since build 7157.

[Dodgexander]

Great to see the problem has been fixed

Sent from my Blade S using Tapatalk 2

[krohm]

im having a problem where mpc doesnt allow scrubbing for camstudio codec recorded with hypercam... it plays through ok but wont allow scrubbing....

any assistance/word on the issue etc would be appreciated,

cheers

[LigH]

You mean an AVI file which doesn't support seeking?

Try to remultiplex it with VirtualDub or AviMux-GUI. It may miss some keyframe list or similar AVI chunks.

[Superb]

This is a known problem and has been fixed (https://github.com/mpc-hc/mpc-hc/commit/9c5bdfe645a41622e6fd4bfa471ff55014a62e30) in the nightlies since build 7157.Great work. Might be a good time to officially release 1.6.8... I've personally encountered this bug more than a few times.

[v0lt]

mpc-hc_7173.x86_avitest_2.7z
* attempt to improve playback for non interleaved AVI files
* reduced memory consumption when playing AVI files
* there are other improvements and bugs

Introduced in 1.6.8.7182 (a8719e5).
Get it here (http://www.mediafire.com/?xfgh33iws56bh).

[krohm]

You mean an AVI file which doesn't support seeking?

Try to remultiplex it with VirtualDub or AviMux-GUI. It may miss some keyframe list or similar AVI chunks.

i have tried this actually,..

doesnt allow seeking, but plays fine if not...

[jkauff]

i have tried this actually,..

doesnt allow seeking, but plays fine if not...
You could try converting to .mkv using mkvmerge. That's what I do with all my .avi files.

[krohm]

You mean an AVI file which doesn't support seeking?

Try to remultiplex it with VirtualDub or AviMux-GUI. It may miss some keyframe list or similar AVI chunks.

apparently yea, quote from videohelp.com re me posting this problem.. '...RIFF tree architecture it creates. For some reason it produces garbage after the end of the Legacy Index. It is not a corrupt chunk, it's just completely invalid data possibly some internal method for storing variables.'

Have tried using vdub and avimux to no avail... im going to start using lagarith to encode.

cheers

[Toku]

Might be slightly off topic, but I just bought a Windows 8 tablet which I installed MPC-HC on, but since the program isn't really touch optimised some bits are slightly annoying to use. (Bringing up the seekbar for example) Does anyone know of a media player similar to MPC-HC which is touch optimised?

[vood007]

No real alternatives to MPCHC let alone any better control options. What about gestures? Have a look here: http://www.strokesplus.com/

[DrNein]

This is a known problem and has been fixed (https://github.com/mpc-hc/mpc-hc/commit/9c5bdfe645a41622e6fd4bfa471ff55014a62e30) in the nightlies since build 7157.

Great work. Might be a good time to officially release 1.6.8... I've personally encountered this bug more than a few times.

Have been using MPC-HC.1.6.8.7163.x86 without the process remaining issue for a few days now. Thanks!

[filler56789]

Does anyone know for what reason XhmikosR stopped icl13 compiling?
There's no worth in doing so at the moment. It takes double time to build it and at the moment there's a problem being that compiler is broken. (we have already made (http://software.intel.com/en-us/forums/topic/370930) a bug report and waiting for a fix)

Until that happens we will not provide ICL13 builds.

He stopped the "lite" builds too, apparently :scared:

[nevcairiel]

Lite builds are done on a longer interval, not daily.

[filler56789]

^ But today is 2013/05/13,

the lite builds were last-updated on 2013/05/04,

and info.md says:
The Lite and ICL13 builds are built every 4 days. :confused: