View Full Version : Media Player Classic Home Cinema (MPC-HC) - DXVA!
oddball
23rd July 2010, 00:01
Is there any way to get animated subtitles without dropped frames (Or flashing on and off briefly if set to buffering animation option)? If I set buffering to 0 I get dropped frames whenever ANY subs appears (Not just animated). I tried enabling buffering for animated subs but then all I get is a brief flash of the animated subs which kinda defeats the point. It's either 1. No animated subs. 2. Animated subs but dropped frames or 3. Animated subs with no dropped frames but they flash on and off briefly. :(
betaking
23rd July 2010, 03:28
Revision 2140 - Directory Listing
Modified Wed Jul 21 02:26:19 2010 UTC (47 hours, 21 minutes ago) by Aleksoid
Fix : Can't open specific mp3, Ticket #363(modify path by koolspin);
this not good fix!:devil:
if i use mpc-hc Internal MPEG Audio Source Filter and standalone mpc-hc AviSplitter ,mpc-hc can not show video for some avi files! but if i not use standalone mpc-hc AviSplitter and use Internal avisplitter play is fine! and i use mpc-hc 1.3.2138 use Internal MPEG Audio Source Filter and standalone mpc-hc AviSplitter! play is fine too! can fix it?
I repot bug at here
http://sourceforge.net/apps/trac/mpc-hc/ticket/586/
namaiki
23rd July 2010, 04:58
Is there any way to get animated subtitles without dropped frames (Or flashing on and off briefly if set to buffering animation option)? If I set buffering to 0 I get dropped frames whenever ANY subs appears (Not just animated). I tried enabling buffering for animated subs but then all I get is a brief flash of the animated subs which kinda defeats the point. It's either 1. No animated subs. 2. Animated subs but dropped frames or 3. Animated subs with no dropped frames but they flash on and off briefly. :(
Animation enabled, buffers is 3, seems to work for me. No flashing. edit: never seen flashing subtitles, buffers can't be 1.
Aleksoid1978
23rd July 2010, 05:21
Revision 2140 - Directory Listing
Modified Wed Jul 21 02:26:19 2010 UTC (47 hours, 21 minutes ago) by Aleksoid
Fix : Can't open specific mp3, Ticket #363(modify path by koolspin);
this not good fix!:devil:
if i use mpc-hc Internal MPEG Audio Source Filter and standalone mpc-hc AviSplitter ,mpc-hc can not show video for some avi files! but if i not use standalone mpc-hc AviSplitter and use Internal avisplitter play is fine! and i use mpc-hc 1.3.2138 use Internal MPEG Audio Source Filter and standalone mpc-hc AviSplitter! play is fine too! can fix it?
I repot bug at here
http://sourceforge.net/apps/trac/mpc-hc/ticket/586/
I revert 2140 changes.
Snowknight26
23rd July 2010, 05:48
Any recent builds? Want to test r2139 as I'm afraid it's a slapped together solution that doesn't fix the underlying issue.
betaking
23rd July 2010, 07:44
I revert 2140 changes.
thanks!and can you compiled mpc-hc svn 2143 and standalone_filters_1.3.2143.0?:)
XhmikosR
23rd July 2010, 07:48
You can always find some new builds in the link in my signature.
betaking
23rd July 2010, 07:57
You can always find some new builds in the link in my signature.
i can not vist you signature! can you up it to http://hotfile.com/ ?
XhmikosR
23rd July 2010, 07:59
No sorry. If someone can provide some FTP space that would be the best.
roozhou
23rd July 2010, 08:02
@XhmikosR
Why is your build so big in size (11.5M)? The build on xvidvideo.ru is only ~7M.
betaking
23rd July 2010, 08:05
No sorry. If someone can provide some FTP space that would be the best.
can you sent to my EMAIL? My email is yzonline@gmail.com?
thanks?
i need MPC-HC MSVC2008
XhmikosR
23rd July 2010, 08:13
@XhmikosR
Why is your build so big in size (11.5M)? The build on xvidvideo.ru is only ~7M.
What build exactly? vs2010 builds are bigger because of vs2010.
Hypernova
23rd July 2010, 08:15
You can always find some new builds in the link in my signature.
I always get an error no matter how I exit your VS2010 build. Do you have any idea why? :thanks:
XhmikosR
23rd July 2010, 08:19
Yep, it's a known issue since mpc-hc was created by Casimir on 2006. No one was able to pinpoint the cause of the crash on exit. It seems that with vs2010 the problem happens a lot more, which is a good thing. Hopefully someone will help and debug this issue. VS2010 projects will go in the svn in the near future. There are a few more stuff I need to change first and Aleksoid or someone else has to create a patch to compile the needed libmingwex.a for vs2010 since it needs a slightly modified lib than with vs2008.
Hypernova
23rd July 2010, 08:26
Yep, it's a known issue since mpc-hc was created by Casimir on 2006. No one was able to pinpoint the cause of the crash on exit. It seems that with vs2010 the problem happens a lot more, which is a good thing. Hopefully someone will help and debug this issue. VS2010 projects will go in the svn in the near future. There are a few more stuff I need to change first and Aleksoid or someone else has to create a patch to compile the needed libmingwex.a for vs2010 since it needs a slightly modified lib than with vs2008.
Got it. Thank you for detailed answer.
Keiyakusha
23rd July 2010, 08:35
Hey guys, there is no way for EVR to use GLslang shaders (vertex+fragment), right? They need to be converted to something, maybe HLSL?
Is it theoretically possible to use scaling shader that will do 2x or 4x upscale? Maybe it absolutely needs something like bicubic scaler on top of it or it will take care of it automatically?
Virtual_ManPL
23rd July 2010, 11:06
...Hopefully someone will help and debug this issue....
http://www.mediafire.com/file/tq5pdbhdsnq8n6u/drwtsn32.log
just opened MPC-HC and closed it
XhmikosR
23rd July 2010, 11:13
I should make my statement more clear. Someone has to find what part of the code is the cause. That's why more people who know how to code are needed.
Mangix
23rd July 2010, 21:08
lmao the msvc2010 build is very funny. i openned up mpc-hc, clicked open file and the crash dialog popped up. however i was still able to watch a movie just fine by minimizing the windows error thing. very strange.
roozhou
23rd July 2010, 22:20
What build exactly? vs2010 builds are bigger because of vs2010.
I guess you are getting something wrong in vs2010 project settings or you configure ffmpeg with unnecesary codecs.
Don't fool me with such word because I am also a C/C++ coder.
XhmikosR
23rd July 2010, 22:40
Then all I can say is wait to submit your patches when/IF the vs2010 projects go in the trunk and IF you still find that it's just a project setting that's causing the increase in size. Maybe the following link will help you. Or just create the projects for everything and submit your patch now and I can make sure it will go in if it's ok.
http://connect.microsoft.com/VisualStudio/feedback/details/504714/statically-linked-mfc-applications-are-massive
No sorry. If someone can provide some FTP space that would be the best.
If it really needed, I can provide some ftp space at Monday, when I'll be at work
Snowknight26
24th July 2010, 00:15
Any recent builds? Want to test r2139 as I'm afraid it's a slapped together solution that doesn't fix the underlying issue.
Sigh, just as I had expected. I hope MPC-HC doesn't keep going in this direction.
Aleksoid1978
24th July 2010, 03:00
has to create a patch to compile the needed libmingwex.a for vs2010 since it needs a slightly modified lib than with vs2008.
I use last MingW(4.5.1) from Alexins - author of xvidvideo.ru
And don't need any patch for libmingwex.a for vs2010.
I use the same libgcc.a and libmingwex.a for vs2008 and vs2010.
x64 libmingwex.a - build with buildmingwlibs.sh
If need - can upload both x86 & x64 libgcc.a and libmingwex.a
Aleksoid1978
24th July 2010, 03:08
Some information about bigger size in VS 2010 - http://tedwvc.wordpress.com/2010/05/27/how-to-make-small-statically-linked-mfc-exes-in-visual-c-2010/
XhmikosR
24th July 2010, 09:51
I use last MingW(4.5.1) from Alexins - author of xvidvideo.ru
And don't need any patch for libmingwex.a for vs2010.
I use the same libgcc.a and libmingwex.a for vs2008 and vs2010.
x64 libmingwex.a - build with buildmingwlibs.sh
If need - can upload both x86 & x64 libgcc.a and libmingwex.a
With Alexin's MinGW 4.4.4:
Error 1088 error LNK2019: unresolved external symbol __imp____lc_codepage referenced in function _wcsrtombs C:\Users\xmr\Desktop\mpc-hc\src\apps\mplayerc\MPCVideoDec.lib(wcrtomb.o) mpc-hc
Error 1089 error LNK2001: unresolved external symbol __imp____lc_codepage C:\Users\xmr\Desktop\mpc-hc\src\apps\mplayerc\MPCVideoDec.lib(mbrtowc.o) mpc-hc
With Alexin's MinGW 4.5.1 experimental I don't get those errors but I don't want to use an experimental compiler.
With your posted (http://forum.doom9.org/showthread.php?p=1393463&highlight=libmingwex#post1393463) lib everything works ok, at least for x86 since I didn't even try x64 builds.
Aleksoid1978
24th July 2010, 10:09
With Alexin's MinGW 4.4.4:
With Alexin's MinGW 4.5.1 experimental I don't get those errors but I don't want to use an experimental compiler.
With your posted (http://forum.doom9.org/showthread.php?p=1393463&highlight=libmingwex#post1393463) lib everything works ok, at least for x86 since I didn't even try x64 builds.
In last Mingw fix this link error about codepage.
About 4.5.1 - i use long time, 2 or 3 month - all ok.
XhmikosR
24th July 2010, 11:02
Still it's experimental. I'll wait for 4.5.1 stable. Thanks for the info though.
Do we still need a modified libmingwex.a for the x64 build with VS2008/2010 with the newer MinGW?
Aleksoid1978
24th July 2010, 13:14
Do we still need a modified libmingwex.a for the x64 build with VS2008/2010 with the newer MinGW?
No. don't need.
Steveo08
24th July 2010, 13:20
mpc-hc x64 is crashing for me, since build r2132, always when mpc used the autochange for changing frequency
Stephen R. Savage
24th July 2010, 22:19
Could a developer or informed user of MPC-HC please explain the "Mixer Output" field on the EVR Ctrl+J diagnostics? I see in some screenshots that it reads RGB32, but on my system it always reads YUY2, even if ffdshow is configured to transport RGB to the renderer. Does this indicate that a second colorspace conversion is occurring? If so, how does MPC-HC decide to set the colorspace of the renderer output — is it specified by the display driver?
namaiki
25th July 2010, 00:11
Could a developer or informed user of MPC-HC please explain the "Mixer Output" field on the EVR Ctrl+J diagnostics? I see in some screenshots that it reads RGB32, but on my system it always reads YUY2, even if ffdshow is configured to transport RGB to the renderer. Does this indicate that a second colorspace conversion is occurring? If so, how does MPC-HC decide to set the colorspace of the renderer output — is it specified by the display driver?
Check EVR pin info.
Stephen R. Savage
25th July 2010, 01:25
Check EVR pin info.
This is unhelpful. Video renderers only have input pins, and that information is already known. What I want to know is if the video undergoes a further colorspace conversion before reaching the display, in which case software RGB conversion would be pointless.
Snowknight26
25th July 2010, 02:48
The DTS decoder causes visual and audible corruption in this sample (http://stfcc.org/misc/mpc-hc.dts.sample.m2ts). Switching to ffdshow for the audio decoding fixes the corruption.
XhmikosR
25th July 2010, 07:58
Please, everybody, report the issues to the trac. No one is going to browse through so many pages to spot the reported bugs in the future. Actually this thread is pretty much useless IMHO.
namaiki
25th July 2010, 10:16
This is unhelpful. Video renderers only have input pins, and that information is already known. What I want to know is if the video undergoes a further colorspace conversion before reaching the display, in which case software RGB conversion would be pointless.
Well, I will tell you that at least from what I have seen with my eyes, RGB32+Dither is much better than letting EVR handle it (test video with a gradient, I can't tell the difference during 'normal' viewing). Overlay is a different animal, however.
D.A.S.
25th July 2010, 10:51
How to make that MPC-HC display default external subtitle, ignoring the subtitle in the MKV?
stasi
25th July 2010, 11:09
xvidvideo.ru hasnīt been updated since 3 weeks. Anyone knows whatīs going on?
oddball
25th July 2010, 11:54
OK I have another bug to report.
When playing back 29.97FPS sources on a 24Hz HDTV I get audio dropout when used with ffdshow as the decoder (MPEG2 source). When played with the internal decoder there is no audio dropout. Also if I switch the output to my 60Hz monitor I get no audio dropout. I want 24FPS output to my 24P HDTV but am unable to get MPC HC to play nice with ffdshow as a decoder on 29.97FPS sources. MPC HC plays 29.97FPS as 24FPS which is fine and dandy most of the time. But when ffdshow is thrown into the equation it breaks it.
Can someone look into this? It needs someone who has a 24P/Hz capable display to test.
BTW I use ffdshow as opposed to the internal MPEG2 decoder because I use the extra processing to clean up and resize sources so using the internal decoder is no good to me.
BTW tsMuxer shows there is no 3:2 pulldown in the video. It thinks it's a straight 29.97FPS. If I try to convert the video to 23.976 the muxing fails with some buffer overflow error. Maybe that can offer some clues?
EDIT: Well this is interesting. Even if I use Avisynth in ffdshow to do a realtime pulldown to 23.976 I still get audio dropout every few seconds. Outputting to soundcard (No ReClock involved here which I originally thought was the problem). I also tried using MPC HC's internal audio decoder. Same problem. Video decoding with ffdshow is the deciding factor here and nothing else. Basically when using MPC HC + ffdshow + 24P output on 29.97FPS sources = audio dropout. EVR CP renderer shows it's playing at 24FPS fine and I get no problems with video playback. If you were to say to me that I need to switch to 60Hz I would think 'OK' but the fact that it plays back 24P from 29.97 with no audio dropout when using MPC HC's internal MPEG2 decoder says otherwise.
xvidvideo.ru hasnīt been updated since 3 weeks. Anyone knows whatīs going on?
It was explained a couple of pages before - alexins is on vacation
Kado
25th July 2010, 18:36
@stasi
You can get XhmikosR builds here (http://xhmikosr.1f0.de/).
dansrfe
26th July 2010, 00:05
MPC-HC refuses to start when Photoshop CS5 is running. I have noticed it happens when a particular process of photoshop is working named: CSSServiceManager.exe
Keiyakusha
26th July 2010, 01:01
I'm using CS5 and don't have such problem. What is CSSServiceManager.exe? Never heard of it. Perhaps some useless service that I disabled and forgot about that? :P
Stephen R. Savage
26th July 2010, 04:07
Well, I will tell you that at least from what I have seen with my eyes, RGB32+Dither is much better than letting EVR handle it (test video with a gradient, I can't tell the difference during 'normal' viewing). Overlay is a different animal, however.
The question was whether or not the RGB32 got converted back to YUY2 in the EVR renderer. Since nobody was able to give me a straight-up answer, I thought up an exercise in Avisynth to determine what was happening.
Interleave(BlankClip(color=color_green, height=320), BlankClip(color=color_blue, height=320))
AssumeFieldBased()
Weave()
TurnRight()
Seems that the output is RGB despite the OSD claiming it to be YUY2.
a_afra
26th July 2010, 11:23
Seems that the output is RGB despite the OSD claiming it to be YUY2.
I've studied the source code of the custom EVR renderer a bit, and it tries to set the output format of the EVR mixer to anything but RGB. Despite this, it always renders into RGB textures, so obviously the output can only be RGB. It doesn't make any sense, and I think this behavior is erroneous. According to an MSDN article (http://msdn.microsoft.com/en-us/library/bb530107(VS.85).aspx#allocatingdirect3dsurfaces), the output format you set and the one you actually use must match.
By the way, I believe this also explains why the 10-bit video path is so buggy. Yes, the GPU drivers have faults (the mixer should return an error code instead of crashing the entire application), but MPC tries to do something which is not really supported. For example, my NVIDIA NVS 5100m reports that 10-bit RGB mixer output is not supported, but it seems to be working anyway (only with progressive content). MPC should definitely check whether 10-bit output is truly supported before using it. However, I doubt that there are any such GPUs at the moment. The bottom line is, this feature in MPC is pretty much broken. The only valid solution I see is to use a non-EVR/VMR renderer that natively supports a full 10-bit video rendering path.
It seems that the drivers are too tolerant (lazy), but MPC should not rely on this. If the MPC developers agree, I will gladly help to fix this.
_xxl
26th July 2010, 12:53
xvidvideo.ru hasnīt been updated since 3 weeks. Anyone knows whatīs going on?
mpc-hc x86 r2153:
http://www.mediafire.com/?lenll0k4hyoa6yc
oddball
26th July 2010, 13:01
OK playing back the 29.97FPS MPEG2 clip using the internal decoder must have been a fluke because it's now doing it on all 29.97FPS sources. Must I really switch to 60Hz everytime I want to play anything at this framerate??? I have no audio dropout playing 25FPS (Just juddering on pans but I can use ReClock to fix that. The audio dropout occurs with or without ReClock). But 29.97 = audio dropping out every few seconds.
OK after further testing this is a problem with EVR CP with D3D enabled. Using EVR Sync or VMR9 I get no audio dropouts. I tried to capture the stats but it won't capture them just the sync bar and it crashes the player too. The green line goes WAAAAAAAY up off the screen then back down again and after a few seconds the player crashes. The red line has a few hiccups but is generally straight.
namaiki
26th July 2010, 13:05
Are you using Reclock when you get the audio dropping out?
THX-UltraII
26th July 2010, 13:19
@stasi
You can get XhmikosR builds here (http://xhmikosr.1f0.de/).
what are the differences between his and alexins versions?
oddball
26th July 2010, 13:21
Are you using Reclock when you get the audio dropping out?
No. See post above (Refresh page because I edit a lot).
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.