actually mplayer@windows is WAY slower than cccp default settings, at least when using only one core cpu to do the job so using it porbably won't improve performance
just like all the vlc, rarplayer or any other "no codecs needed" players, cccp is just fastest solution
Granted that the build is new enough to give a good'ish performance comparison, mplayer(2) should be faster than MPC-HC + most DShow components in decoding and subtitle rendering. Not only does mplayer use libass, which is much faster than VSFilter (and xy-vsfilter) subtitle rendering wise, but you also lose the DShow overhead between filters. I don't think the fact that we're dealing with a single core CPU matters much, in theory an up-to-date mplayer2 build should be the fastest with software decoding.
But with real problematic cases the real fun only begins from there. Usually the biggest problem is rendering. There are many VOs, and some drivers just don't want to play nicely with some, and some drivers don't want to play nicely with pretty much anything. Meanwhile some basic renderer (overlay, Haali, VMR7 etc.) from MPC-HC might handle the job in a better way and thus give a feeling that CCCP's setup is faster than mplayer(2)'s.
actually mplayer@windows is WAY slower than cccp default settings, at least when using only one core cpu to do the job
-lavdopts threads=whatevernumberyouwant
I think he was just trying to imply that mplayer < CCCP's default DShow setup on a single core machine, not that it wouldn't be able to use multiple threads
And to the opening poster:
Anyways, in this case the CPU is an old 3GHz Pentium 4, the IGPU an Intel 82945G, and the "problematic 1080p clip" 10bit H.264. You can try of course, but I'll say that I wouldn't be surprised even if 8bit H.264 at that resolution wouldn't work on that CPU. It probably just lacks the computational power to handle it.
Author
Topic: Video lag during playback of 1080p MKV in MPC-HC (Read 4710 times)