Media Player Classic Home Cinema (MPC-HC) - DXVA! [Archive] - Page 274

SoLoR

30th July 2010, 14:29

I tryed others, same result... mpc-hc crashes with "stoped responding"... could this be issue in how url looks like? example: "http://10.0.0.1:4022/udp/239.1.1.8:5000" (runing udpxy on port 4022 playing multicast stream from 239.1.1.9:5000). I would get if player would error out with "hey i can not play this stream/file" but thing is, if i capture part of stream with for example wget i can play it normaly... it just does not work from http link.

here is sample (~15MB): http://solor.wtf.la/test.ts you can open this http link directly inside mpc-hc and it will start playing. Sample was captured with wget from local http://10.0.0.1:4022/udp/239.1.1.8:5000 address.

edit: i figured it out exactly what might be an issue, when i add stream in to playlist it connects it and start to transfer data and since that data never ends (point of TV) mpc-hc stops responding, even tho it is still transfering data of that stream in the background. As soon as i unplug network cable mpc-hc starts to respond... It seems like it have only problems with continuous streams that never ends.

PetitDragon

30th July 2010, 20:43

Could anyone tell me how to configure mpc-hc revisions after 2116 to use madFlac to play .flac files?

For revisions 2116 and before, I am able to disable the internal flac source and decode filters to force madFlac to play .flac files. This method won't work for revisions after 2116. Unfortunately using the internal flac source and decode filters to play .flac files couses sound stutter.

please help!

BrollyLSSJ

30th July 2010, 21:52

Does someone know why the standalone filters compiled with VS 2010 are that much bigger in size than the filters compiled using VS 2008?

Aleksoid1978

31st July 2010, 00:59

Does someone know why the standalone filters compiled with VS 2010 are that much bigger in size than the filters compiled using VS 2008?

VS2010 generate binary biggest size that VS2008.

Ger

31st July 2010, 01:17

At least basic playing functions (if not choosing different audio tracks and teletext) because currently im kinda forces to use VLC for IPTV and mpc-hc for everything else and in all honesty i dont like picture quality of VLC...

I'm in the same situation with ts http streams from Enigma2 (Dreambox). I have to use VLC for that (both Haali and internal splitter fails to open ts streams but works fine* when it's saved to a .ts file), but I prefer MPC-HC, so I only use VLC when I have to.

*Like you say, audio/subtitle switching/recognition in ts/DVB files is far superior in VLC as well, compared to both Haali and the Gabest/MPC-HC splitter.

Anyway, if you create a ticket (http://sourceforge.net/apps/trac/mpc-hc/wiki/Bugs_-_Reporting) it's at least a little more likely to get attention from a developer compared to posting in this thread.

I think there was some talk in this thread about using splitter code from other projects, but I don't know what the status is there.

@Aleksoid1978
I like your "show filename in OSD instead of play/pause on open" change a lot. Very useful in full screen. But the filename/OSD disappears far to quickly to be able to read it. Could you make it stay on screen for a few more seconds? Edit: Just read the 2166 changelog entry and tested 2166. Thanks. I still think 3 seconds is a little short though. Perhaps increase to 5 seconds or make it configurable?

Also if the CTRL-I "remaining time" OSD is enabled, other OSD messages disappear very quickly. Example: Try to adjust the volume and see how quickly the volume message disappears compared to when "remaining time" OSD is disabled. A solution to make sure "remaining time" doesn't overwrite other temporary OSD messages is perhaps to position temporary OSD messages after/ to the right of remaining time if it's enabled, or to move "remaining time" to the other (top right) corner and keep temporary OSD messages on the left. Another option could be to somehow give temporary OSD messages higher priority than the permanent OSD.

diizzy

31st July 2010, 14:40

Just an issue I've noticed recently, is there a way to apply subs before upscaling/resizing the video using the builtin (vsfilter) subtitle filter in EVR CP?
The reason I'm asking is because if you have subs with signs they get scaled improperly / dislocated if they're applied on a video that's not it's native size. I believe this is only an issue with the internal subtitler since running it as a stand alone filter it gets applied before resizing (I havent tried but I think it worked that way in the past at least). Keep up the good work!

allak

31st July 2010, 14:49

I think you must fully check "Position subtitles relative to the video frame" on Options -> Subtitles -> Default Style.

Keiyakusha

31st July 2010, 15:30

namaiki

31st July 2010, 15:36

Internal one gets applied after everything, external one gets pasted to and resized with the video.

diizzy

31st July 2010, 15:54

@ allak

That worked, thanks...
Mine was "grayed/filled" so I don't really know when it's applied. Checking it worked.

@ Keiyakusha

I used the internal but as namaiki confirmed (and what I remembered) using it externally doesn't need this "fix".

Would be nice though if it got applied if script contains \pos .

oddball

31st July 2010, 18:03

@XhmikosR your builds are still broken with the exit player bug even on build 2166.

Faulting application name: mpc-hc.exe, version: 1.3.2166.0, time stamp: 0x4c5297e4
Faulting module name: ntdll.dll, version: 6.1.7600.16559, time stamp: 0x4ba9b29c
Exception code: 0xc0000374
Fault offset: 0x000cdc9b
Faulting process id: 0x12f4
Faulting application start time: 0x01cb30d20138d3f0
Faulting application path: C:\Program Files (x86)\Media Player Classic - Home Cinema\mpc-hc.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: 49b22be0-9cc5-11df-be47-001a921cbab6

XhmikosR

31st July 2010, 18:12

BrollyLSSJ

31st July 2010, 18:12

VS2010 generate binary biggest size that VS2008.
Thank you for the answer. If 2010 does not have any advantages, I will stick with the 2008 filters for the portable version of KMPlayer and PotPlayer.

oddball

31st July 2010, 18:21

Some people just never get it. It's NOT my builds' fault. Period. It's a bug in MPC-HC since ever which is more present if compiled with MSVC2010. This is the last time I say that. If you don't like my builds just simply do NOT use them.

Not that I know anything about such things but why compile it with that then if it exhibits the bug? I don't know anything about programming so if that's a stupid question so be it. :)

And is anyone going to fix the bug in the core code?

SamuriHL

31st July 2010, 18:25

Not that I know anything about such things but why compile it with that then if it exhibits the bug? I don't know anything about programming so if that's a stupid question so be it. :)

And is anyone going to fix the bug in the core code?

I'll answer this for him as he's tired of explaining it by now I'm sure. The bug in MPC-HC has *NOTHING* to do with VS2010. This bug has been there for a very long time. It exists in the VS2008 compiled version, too. It's just that something in VS2010 triggers it more. He's hoping that as such, some developer can pinpoint the bug and finally fix it. There's no functional difference between the VS2008 and VS2010 compiled builds so if you're concerned, just get the VS2008 compiled build and your chances of hitting this bug are less. Albeit not 0.

Ger

31st July 2010, 20:11

But pretty close to 0 for most systems I think. I use MPC-HC (and MPC before that) almost daily, and I don't remember a crash on exit for several years. I think the last time I saw it was when I was still on WinXP years ago (I'm using Win7-x64 now and Vista x86 before that). With VS2010 builds I get the crash on exit every time (have only tested 32-bit builds). So for me the "crash on exit ratio" is close to 0% for VS2008 and close to 100% for VS2010, and judging from the rush of posts about this issue I suspect I'm not alone.

What I'm trying to say is that I suspect that for most people there is a huge difference, and not just a case of a few percent more likely to happen.

I'm aware that some people have seen the crash with VS2008/VS2005 as well, but at least now it should be easy to reproduce with VS2010 builds. Hopefully someone will figure out the exact cause eventually.

XhmikosR

31st July 2010, 20:15

I'm aware that some people have seen the crash with VS2008/VS2005 as well, but at least now it should be easy to reproduce with VS2010 builds. Hopefully someone will figure out the exact cause eventually.
That is exactly the reason I keep uploading the MSVC 2010 builds and I committed the MSVC 2010 project files. Open source doesn't mean complaining only, but submitting patches and help in any way one can.
If it wasn't for that and a bug in the shader editor window, which hopefully someone will fix soon, MSVC 2010 builds feel faster for me.

SamuriHL

31st July 2010, 20:18

I don't have VC 2010 installed yet on either my laptop or my HTPC so I can't take a look at it. I'm not even sure I could fix it even if I did. Been in java too long. :D But does this crash happen with a debug build? If so, you might be able to narrow down where it happens at least.

XhmikosR

31st July 2010, 20:22

Yes it does happen with the debug builds but I have no clue.

--> if (!AfxIsValidAddress(pOb, pOb->GetRuntimeClass()->m_nObjectSize, FALSE))
{
TRACE(traceAppMsg, 0, "ASSERT_VALID fails with illegal pointer.\n");
if (AfxAssertFailedLine(lpszFileName, nLine))
AfxDebugBreak();
return; // quick escape
}
pOb->AssertValid();
}

Keiyakusha

31st July 2010, 20:25

isn't the reason already was known - because MPC-HC uses some old and not really supported api when it closes? I have read about this in this thread not so long ago but forgot the details.

XhmikosR

31st July 2010, 20:29

That's what tetsuo55 said, but unless it's proved, the reason remains unknown.

SamuriHL

31st July 2010, 20:34

What error is it throwing back? That's some nasty code anyway. I don't know exactly what that's doing but it seems like it's asserting the validity of pOb and from what little I can gather about that call it checks to see if it's within the memory space of the calling app. However, to do so it's making a call against the object? Um, if the object is invalid in the first place, won't that second argument blow up? :) Again, I've been in java quite a while but basic C++ memory management tells me that's not good! :)

tetsuo55

31st July 2010, 23:06

It should have something to do with the way open threads are destroyed during or after the exit call.

A similar bug occurs when trying to destroy dxva surfaces created by the internal dxva decoder.

More detail on the "crash on exit bug"
* In VS2010 it crashes 100% of the time on exit.
* In VS2008/2005 it will almost never crash, but instead threads will remain open
* In some cases all that closes is the gui, the rest of the app stays on and is visable from the task manager
* Appverfier or Windows logo check gave me an "dangerous exit api" warning some time in the past, a quick check seems to point to us using the correct calls as described on msdn (Someone with more knowhow will have to verify this)

The "leaked" parts of mpc-hc are the cause of bugs like settings that dont get saved, or some forms of stuttering that dont occur at first startup after a reboot, but from next play on.

madshi

1st August 2010, 09:00

It should have something to do with the way open threads are destroyed during or after the exit call.
Which exit API are you using (you say it's outdated)?

Generally it's a BAD design to have secondary threads still running when the main thread is shutting down. The proper design is for the main thread to set a signal/event to let all secondary threads close down properly. The main thread should wait until all secondary threads are gone, and only after that the main thread finally is allowed to close down, too.

Octo-puss

1st August 2010, 09:07

I use MPC-HC on two computers. Mine is P45-based with 5850 card, and my gf's is H55 with Core i3, using integrated graphics. On my pc everything works fine, but the other freezes a lot with EVR custom pres. output. Switching to Haali renderer fixes it, but some stuff I am used to doesn't work then.
Does anyone have an idea what might be the problem? Both computers run Windows7 x64.

namaiki

1st August 2010, 09:09

Try disable DXVA.

Octo-puss

1st August 2010, 09:14

Care to explain a bit further? :)

Steveo08

1st August 2010, 09:25

i have a large number of dropped frames during playback mostly over 100 for a movie with 120 minutes and it's for 720p & 1080p movies. my settings are "present at nearest vsync" with a value of 0.12ms. so i am planing to buy a bigger graphic card (now i have a xfx gt220), but i am not sure, if it really healps. or is that normal, how many dropped frames have the other here?

namaiki

1st August 2010, 10:19

How about if you use EVR-Custom Pres instead of EVR Sync?

Steveo08

1st August 2010, 10:28

How about if you use EVR-Custom Pres instead of EVR Sync?

when i change to evr-custom pres than is my green line going slowly up for a while and after that the line goes fast down to the red and the same procedure starts again. and i am using direct3d too.

namaiki

1st August 2010, 10:32

You would have to change the refresh rate of your screen to match the fps of the video if you want the line to be straight.

If it isn't perfectly matched, you can still use ReClock. i.e. 23.976fps -> ~24Hz, 48Hz, 96Hz, 120Hz; 29.970fps -> 30Hz, 60Hz, 120Hz.

Care to explain a bit further? :)
I think you would be able to figure it out if you had a little look. In MPC-HC: View-> Options-> Internal Filters-> untick anything in the right column that says DXVA.

Steveo08

1st August 2010, 10:50

You would have to change the refresh rate of your screen to match the fps of the video if you want the line to be straight.

If it isn't perfectly matched, you can still use ReClock. i.e. 23.976fps -> ~24Hz, 48Hz, 96Hz, 120Hz; 29.970fps -> 30Hz, 60Hz, 120Hz.

well, my refresh rate is 23Hz this means in windows 24p and this is for my tv the best solution, because it has a 4:4 Pulldown and it only works when i watch my movies with 24p.

namaiki

1st August 2010, 10:57

ReClock seems to be the solution as it is not perfectly matched.

Steveo08

1st August 2010, 11:02

ReClock seems to be the solution as it is not perfectly matched.

hmm......the only thing i don't like at reclock is, that is no 64bit version available.

but if i use the x86 version, is there any problems with spdif?

namaiki

1st August 2010, 11:05

64bit vs x86
Generally no difference.

any problems with spdif?
Personally, I don't use SPDIF so unfortunately I can't say.

decapitado

1st August 2010, 11:23

Where can we see the changelog in xhmikosr builds?

XhmikosR

1st August 2010, 11:26

Where the official changelog is.

http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/?view=log

Steveo08

1st August 2010, 11:47

Generally no difference.

Personally, I don't use SPDIF so unfortunately I can't say.

ok, than i will test it, if there is a difference for spdif.

Octo-puss

1st August 2010, 14:06

I think you would be able to figure it out if you had a little look. In MPC-HC: View-> Options-> Internal Filters-> untick anything in the right column that says DXVA.
I am not an idiot. I asked WHY, not HOW.

namaiki

1st August 2010, 14:14

I am not an idiot. I asked WHY, not HOW.

"Care to explain a bit further?" is quite open.

Anyways, try it first. If it works, it works. If there are still issues, then it's probably not the fault of DXVA.

Hint: DXVA doesn't work with Haali's Renderer. (or at least, I don't think it does...) Besides that, no idea.

tetsuo55

1st August 2010, 17:03

Which exit API are you using (you say it's outdated)?

Generally it's a BAD design to have secondary threads still running when the main thread is shutting down. The proper design is for the main thread to set a signal/event to let all secondary threads close down properly. The main thread should wait until all secondary threads are gone, and only after that the main thread finally is allowed to close down, too.i agree with that idea, but i have no idea what it looks like in the code right now, or even where it is.

madshi

1st August 2010, 17:13

i agree with that idea, but i have no idea what it looks like in the code right now, or even where it is.
Should not be too hard to find all code locations where a thread is created (e.g. search for CreateThread, _beginthread(ex) and AfxBeginThread) and then to make sure that all of these secondary threads are properly run through before allowing the process to close down. Of course it needs a bit of programming time and maybe one of the devs needs to get his hands dirty a bit. But it's not really rocket science for any programmer with experience in multi threaded programming.

Boulder

1st August 2010, 18:39

I'm getting a crash every time I try to open an AC3 file in MPC-HC (build 2172 by XhmikosR, MSVC2008). Is there anything I can do to track down the error? I have had similar errors lately but I cannot find anything to point my finger at.. If I open the MSVC2008 debugger, it always shows the line with "mov dword ptr [edx],ecx" as the breakpoint.

Updating ffdshow or changing to a different AC3 decoder didn't help either.

XhmikosR

1st August 2010, 18:44

@Boulder: Do you by any chance use the ICL11 ffdshow build?

Boulder

1st August 2010, 18:46

Yes, I tried that too but the problem occurs also with clsid's generic ffdshow build.

XhmikosR

1st August 2010, 18:48

Weird, I always got a crash with some specific files with AC3 audio and only with the ICL11 ffdshow builds; generic builds are fine for me. With the debug ffdshow builds I get no crash. I still haven't found the cause.

Boulder

1st August 2010, 18:50

I think this problem lies somewhere else.. for example I got the infamous "crash when exiting" problem with the same breakpoint a while ago with mkvmerge. I fixed it by changing the language once, restarting mmg and then changing the language back to English. Now it doesn't crash anymore. I've got no clue what may have caused these issues since I've not installed much of anything lately.