Media Player Classic Home Cinema (MPC-HC) - DXVA!

[_xxl]

I"ll compile libavcodec with MMX and SSE and post the results.

[romanesque]

Subtitles still don't work in build 1802.

[XhmikosR]

Originally Posted by Aleksoid1978

Try this libmingwex.a - http://aleksoid.tosei.ru/Dist/lib/libmingwex.7z

Thanks, now mpc-hc successfully links.

[Superb]

Originally Posted by romanesque

Subtitles still don't work in build 1802.

They do "load" (i.e. if you drag them into the mpc-hc window)... they simply don't "auto-load". And yes, it is annoying.

[decapitado]

Originally Posted by romanesque

Subtitles still don't work in build 1802.

They auto-load in mine

[tetsuo55]

Originally Posted by _xxl

I"ll compile libavcodec with MMX and SSE and post the results.

thanks, if you could also compare with msvc, icc and with and without PGO that would be even better

[clsid]

Originally Posted by tetsuo55

thanks, if you could also compare with msvc, icc and with and without PGO that would be even better

MSVC and ICC generate bad performing builds of libavcodec because they don't support the ASM stuff, so testing those is pointless.

[tetsuo55]

Originally Posted by clsid

MSVC and ICC generate bad performing builds of libavcodec because they don't support the ASM stuff, so testing those is pointless.

Can you back that up with scientificly run benchmarks?

Lets stick to facts instead of repeating claims of the past over and over. (and lets store these benchmarks in an easy to find place this time)

[clsid]

I am sticking to facts. You obviously have no clue what you are talking about. Did you really think all that hard-written optimized assembly code in libavcodec was put there just for fun? A GCC build is 300% faster than a MSVC build of libavcodec. Yes, 4 times as fast, do you see the pointlessness now?

[madshi]

Why does MSVC not compile that libavcodec assembler code? I have some MSVC projects with assembler code and they compile just fine. No fancy SSE stuff, though. Maybe SSE is problematic?

[clsid]

It doesn't support the syntax of the inline assembly code from libavcodec.

[tetsuo55]

Originally Posted by clsid

I am sticking to facts. You obviously have no clue what you are talking about. Did you really think all that hard-written optimized assembly code in libavcodec was put there just for fun? A GCC build is 300% faster than a MSVC build of libavcodec. Yes, 4 times as fast, do you see the pointlessness now?

those values are pointless without a way to reproduce your results. Also your just quoting something again instead of providing a benchmark.

[clsid]

101 dfps versus 24 dfps for a random h.264 sample
Satisfied now?

Download Haali's TimeCodec tool and you can do your own benchmarks with whatever files and builds you want.

[Momber]

Originally Posted by romanesque

Subtitles still don't work in build 1802.

True - and extremely annoying.

[Snowknight26]

http://sourceforge.net/apps/trac/mpc-hc/ticket/409
Still happens with the latest version. You can watch your free ram in the resource monitor dwindle down from 2GB to 0 while playing, then after you've closed MPC-HC, watch it shoot back up to 2GB.

[Aleksoid1978]

With Catalyst 10.4a MPC fine play H264 FullHD with ref_num up to 16 with DXVA.
Win 7, Evr Custom/Evr Sync, 5770.

[Aleksoid1978]

Originally Posted by Snowknight26

http://sourceforge.net/apps/trac/mpc-hc/ticket/409
Still happens with the latest version. You can watch your free ram in the resource monitor dwindle down from 2GB to 0 while playing, then after you've closed MPC-HC, watch it shoot back up to 2GB.

What is the time you look video(1 hour, 2 hour ...)
I often look HD (H264) and did not observe such effect not to time.

[mariush]

Originally Posted by Snowknight26

http://sourceforge.net/apps/trac/mpc-hc/ticket/409
Still happens with the latest version. You can watch your free ram in the resource monitor dwindle down from 2GB to 0 while playing, then after you've closed MPC-HC, watch it shoot back up to 2GB.

Look carefully at what filters are used to decode the videos - the player may use a file splitter filter that just loads in memory the whole file instead of parsing it.

You could also download the SysInternals Suite from Microsoft and use the procmon.exe (Process Monitor) and procexp.exe (Process Explorer) to see exactly what dll files is mpc-hc loading and how it reads the file and how it allocates memory and so on. Maybe you find something helpful for the developers.

[Snowknight26]

Originally Posted by Aleksoid1978

What is the time you look video(1 hour, 2 hour ...)
I often look HD (H264) and did not observe such effect not to time.

Happens pretty fast. I can see the free RAM go down instantly. Took about 7.5 minutes to go from 1.5GB to 0, so about 3.4MB/s. I'll have a video uploaded soon showing the effect. One thing you'll notice though that is only present when Fraps is recording is the constant usage of 0-100MB as its cache in RAM is written to disk.

Video of it in progress: http://stfcc.org/misc/MPC-HC%20DXVA%...0-lossless.mkv (~9:30, 350kbps)
(You have to disable DXVA to play this as it's lossless... you wouldn't have to if that one bug was fixed, hint hint. :P)

Originally Posted by mariush

Look carefully at what filters are used to decode the videos - the player may use a file splitter filter that just loads in memory the whole file instead of parsing it.

Internal Matroska splitter, MPC Video Decoder, EVR CP, default DS device, ffdshow's audio decoder (5.1 PCM -> 2.0 PCM), madFLAC (FLAC -> PCM), and audio switcher.

Nothing out of the ordinary in Process Explorer.. first thing I checked, too.

[Mercury_22]

Originally Posted by Snowknight26

Happens pretty fast. I can see the free RAM go down instantly. Took about 7.5 minutes to go from 1.5GB to 0, so about 3.4MB/s. I'll have a video uploaded soon showing the effect. One thing you'll notice though that is only present when Fraps is recording is the constant usage of 0-100MB as its cache in RAM is written to disk.

Video of it in progress: http://stfcc.org/misc/MPC-HC%20DXVA%...0-lossless.mkv (~9:30, 350kbps)
(You have to disable DXVA to play this as it's lossless... you wouldn't have to if that one bug was fixed, hint hint. :P)



Internal Matroska splitter, MPC Video Decoder, EVR CP, default DS device, ffdshow's audio decoder (5.1 PCM -> 2.0 PCM), madFLAC (FLAC -> PCM), and audio switcher.

Nothing out of the ordinary in Process Explorer.. first thing I checked, too.

No such problem here (all internal) but I have the same problem if I try to play a file which is in use at the same time by other app (µ) which it seems to be your case too ( or not )