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

XhmikosR

20th April 2010, 15:54

I can compile MPC-HC with VS2010, but ... it's not stable and has bug in GUI(like without themes support).

Even after yesterday's commits I still cannot compile mpc-hc with MSVC 2010 successfully. I'm getting the following errors when linking mpc-hc:

Error 62 error LNK2019: unresolved external symbol __imp____lc_codepage referenced in function _wcsrtombs C:\Users\USER\Desktop\mpc-hc\src\apps\mplayerc\MPCVideoDecRU.lib(wcrtomb.o) mpc-hc
Error 63 error LNK2001: unresolved external symbol __imp____lc_codepage C:\Users\USER\Desktop\mpc-hc\src\apps\mplayerc\MPCVideoDecRU.lib(mbrtowc.o) mpc-hc
https://sourceforge.net/apps/trac/mpc-hc/ticket/153#comment:9

Can you describe how exactly you solved these errors?

gngn

20th April 2010, 19:47

rev1802 of MPC-HC introduced some seeking-problems with DXVA on and H264 files that have b_pyramid=2 (and "b-pyramid=normal" is now default in x264 since r1455 Feb 21 2010)
when seeking the image freezes (but sound continues, even the video-playback time goes on). after a few seconds showing that frozen frame playback will start, first very jerky, until it becomes normal.

problem is more pregnant with HaaliSplitter then with the internal matroska splitter.

torpedo

21st April 2010, 01:05

@clsid:
The SSE optimization of ffMpeg compilation has been deprecated since svn 1792. The current optimization option is MMX. Why the optimization option was reverted to MMX?

Superb

21st April 2010, 01:32

Even after yesterday's commits I still cannot compile mpc-hc with MSVC 2010 successfully. I'm getting the following errors when linking mpc-hc:

https://sourceforge.net/apps/trac/mpc-hc/ticket/153#comment:9

Can you describe how exactly you solved these errors?http://forum.doom9.org/showthread.php?p=1339108#post1339108
http://forum.doom9.org/showthread.php?p=1339154#post1339154

mingwex points to a removed variable (Microsoft removed it in VS2010).

Aleksoid1978

21st April 2010, 05:21

Even after yesterday's commits I still cannot compile mpc-hc with MSVC 2010 successfully. I'm getting the following errors when linking mpc-hc:

https://sourceforge.net/apps/trac/mpc-hc/ticket/153#comment:9

Can you describe how exactly you solved these errors?

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

Superb

21st April 2010, 05:40

@Aleksoid1978: did you simply remove this symbol from the lib itself? or did you compile a new, fixed mingwex lib (which doesn't import this deprecated/removed variable)?

Aleksoid1978

21st April 2010, 06:02

@Aleksoid1978: did you simply remove this symbol from the lib itself? or did you compile a new, fixed mingwex lib (which doesn't import this deprecated/removed variable)?

Just remove ... as here - http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=1&t=891

_xxl

21st April 2010, 06:37

The SSE optimization of ffMpeg compilation has been deprecated since svn 1792. The current optimization option is MMX. Why the optimization option was reverted to MMX?
FFmpeg has hand written optimizations and doesn't need any forced SSE optimizations, will just make ffmpeg slower, that was proven years ago.

tetsuo55

21st April 2010, 07:41

FFmpeg has hand written optimizations and doesn't need any forced SSE optimizations, will just make ffmpeg slower, that was proven years ago.that proof is no longer valid and will have to be re-tested.

_xxl

21st April 2010, 08:05

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

romanesque

21st April 2010, 09:07

Subtitles still don't work in build 1802. :(

XhmikosR

21st April 2010, 10:42

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

Thanks, now mpc-hc successfully links.

Superb

21st April 2010, 12:33

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

21st April 2010, 14:09

Subtitles still don't work in build 1802. :(
They auto-load in mine :confused:

tetsuo55

21st April 2010, 15:49

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

21st April 2010, 16:10

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

21st April 2010, 17:42

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

21st April 2010, 19:18

madshi

21st April 2010, 19:24

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

21st April 2010, 19:33

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

tetsuo55

21st April 2010, 19:53

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

21st April 2010, 20:23

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

22nd April 2010, 01:33

Subtitles still don't work in build 1802. :(

True - and extremely annoying.

Snowknight26

22nd April 2010, 05:52

Aleksoid1978

22nd April 2010, 06:15

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

22nd April 2010, 06:20

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

22nd April 2010, 06:57

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 (http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx) 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

22nd April 2010, 07:39

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%20leak%20-%20-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)

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

22nd April 2010, 09:24

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%20leak%20-%20-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 ) :)

liquidskin76

22nd April 2010, 10:34

Hi,

I'm seeing a strange thing when using MPC's matroska splitter. When chapter seeking on mkv's (containing encoded h264 video), immediately after the seek the video speeds up for a few seconds, then goes back to normal playing speed.

It doesn't happen at every chapter point, however it is consistent at the chapters point that it's present at.

This problem isn't present if using haali. Basically i get it on any player when using MPC's matroska splitter.

Happens with software decoding and dxva.

Any ideas? Has anyone else experienced this?

Cheers

[EDIT: it's not present on sd h264 video]

[EDIT (Again!): haven't tested on original unencoded h264 however it's not present on unencoded vc1]

clsid

22nd April 2010, 10:37

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 ) :)Which could mean the leak is possibly in the splitter and not in the H264 decoder. An interesting test would be to see if the same problem occurs with a Matroska file that contains a different video format, for example MPEG-4.

Mercury_22

22nd April 2010, 11:55

Which could mean the leak is possibly in the splitter and not in the H264 decoder. An interesting test would be to see if the same problem occurs with a Matroska file that contains a different video format, for example MPEG-4.

For me it happens with all type of big files which are in use at the same time by other app (= µ...) so it might not be the same problem

_xxl

22nd April 2010, 12:57

MSVC build of libavcodec
This is only used for debugging. MSVC can't compile release builds of ffmpeg.

_xxl

22nd April 2010, 13:03

that proof is no longer valid and will have to be re-tested.
Please see ffdshow-tryouts thread.

clsid

22nd April 2010, 14:07

For me it happens with all type of big files which are in use at the same time by other app (= µ...) so it might not be the same problem The splitters all share some base code, so the leak is probably in the code that handles the file reading and buffering.

Mercury_22

22nd April 2010, 16:17

The splitters all share some base code, so the leak is probably in the code that handles the file reading and buffering.

I've done more testing with external splitter and external decoder but the result it's the same also I've forgot to mention that after exiting MPC-HC memory usage doesn't decrease !
Testing the same file with the same external splitter and decoder but with WMP doesn't produce an abnormal increase in memory usage and after exiting WMP the memory usage it's been restore to the previous value

Also playing the same file with WMP after exiting MPC-HC result in a decrease in memory usage

P.S. Disabling Windows caching of disk reads also solves this problem but this is not a solution

tetsuo55

22nd April 2010, 16:43

I've done more testing with external splitter and external decoder but the result it's the same also I've forgot to mention that after exiting MPC-HC memory usage doesn't decrease !
Testing the same file with the same external splitter and decoder but with WMP doesn't produce an abnormal increase in memory usage and after exiting WMP the memory usage it's been restore to the previous value

Also playing the same file with WMP after exiting MPC-HC result in a decrease in memory usage

P.S. Disabling Windows caching of disk reads also solves this problem but this is not a solutionI had the same problem, it was a bug in my intel SATA driver.
i manually updated it from the last ini file intel released.

Mercury_22

22nd April 2010, 16:58

I had the same problem, it was a bug in my intel SATA driver.
i manually updated it from the last ini file intel released.
I have the latest drivers too so no it's not the drivers also as I've said WMP has no problem

Also I've just done a test with tmt3 on the same conditions and surprise surprise... the memory usage it's increasing abnormal like in the MPC-HC case except that when TMT exits the memory usage it's decreasing to previous value

tetsuo55

22nd April 2010, 17:17

I have the latest drivers too so no it's not the drivers also as I've said WMP has no problem

Also I've just done a test with tmt3 on the same conditions and surprise surprise... the memory usage it's increasing abnormal like in the MPC-HC case except that when TMT exits the memory usage it's decreasing to previous valueits a leak in the system caching.

mariush

22nd April 2010, 17:42

Run the cacheset.exe utility from SysInternals Suite I mentioned above and set the maximum system cache to some sane value. On my Windows 2008 dedicated server with 2 GB of ram, the system cache was set by default at 30 or 32GB. Obviously, those 2GB of memory were always used at the max screwing up my mysql server so I used that cacheset utility to lock the system cache at 1 GB.

Mercury_22

22nd April 2010, 17:58

Snowknight26

22nd April 2010, 18:11

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 ) :)

Nothing else was using it.

Which could mean the leak is possibly in the splitter and not in the H264 decoder. An interesting test would be to see if the same problem occurs with a Matroska file that contains a different video format, for example MPEG-4.

It seemed to happen with all video types that I tried (MPEG-2, VC-1, H.264) and MKV/M2TS. When I started using Haali Media Splitter (tried with M2TS), the issue went away, so it's definitely a splitter/file reader issue.

Also confirmed the issue on an entirely different set of hardware.

samab

23rd April 2010, 00:50

It seems that the new .net 4 release --- at least for windows xp sp3 --- brings in new evr.dll and dxva2.dll files.

Keiyakusha

23rd April 2010, 01:38

It seems that the new .net 4 release --- at least for windows xp sp3 --- brings in new evr.dll and dxva2.dll files.

By having quick look at the installer I found these dll's in netfx_Core.mzz archive but it says product version 6.0.6002.18084, and the ones in windows7 are 6.1.7600.16385. So they are from Vista? But who knows, maybe the last part is a revision number or something.

Snowknight26

23rd April 2010, 02:13

6.1 = NT version
7600 = Windows build
16385 = Windows revision

So that 6.0.xxxx one is a Vista dll.

iron2000

23rd April 2010, 06:20

MPCHC can't seem to write settings to ini when installed in Program Files with UAC turn on.
Maybe the developers can make the function request for privilege level elevation when MPCHC is in Program Files with UAC turn on?
(Just turn UAC back on yesterday, feels so restricted :P)

Or maybe default installers to install elsewhere?

namaiki

23rd April 2010, 08:04

In my setup it seemed to put the ini file into the roaming/appdata/programdata folder. Forgot which..

G_M_C

23rd April 2010, 08:19

Nope i didn't. It's a clean Win7-64bit install from DVD (firefox is the only other app ... that clean). I use BitDefenter internet security 2010, and are still working with a 1950XT and Catalyst 10.2. Also used the DX web installer to get DX up to spec, also all updates and patches from windows-update are applied (ofcourse with a legit windows :) )

I just grabbed the installer version of MPC-HT 1788 from xvid-video.ru and installed that on this clean system.

one point of interest maybe: Windows 7 insists on numbering my secondary-display, my TV, as "1" and my main screen as "2". Have no idea how to reverse that order, and why windows does that for that matter. Maybe Windows chooses the main display based on which has the highest resolution ?
Second point of interest: User account control [UAC] is switched. on. It protects by limiting reading from and writing to registry, am i right ? It does pop up when i dont start up in vista compatilbillity mode. Might that be what's preventing MPC-HT to start up reguarly ?

Same thing happened with my attempts to get madFlac running.

I installed it, tried to use it in MPC-HT. Didn't work, disabled other flac decoders, but still didn't get it running. The MPC-HT decoder was used instead with low merit.

Ended up uninstalling madflac :sad: Don't know to get my multichannel flacs running now

It's not straightforward to get Win 7-64 running as i was used to in XP. Guess i'll have to consider reverting to 32 bit also.

Maybe the MPC-HT flac decoder can be updated to multichannel ?

Well i did go back to 32 bit (same build 1788, only 32-bit version). And that one works flawlessly. There is no start-up-problem, and no need for "Vista SP1 compatilbillity" as i reported. madFlac works as intended.

Too bad 64 bit isnt equal to 32 bit yet.