Why is there a 64 Bit Edition of MPC-HC?????

[Snappy Phoenix]

Just wondering, it's been years since there are always variants of the x64 edition of MPC-HC and I am wondering, why does it even exist?

1) Is there a 64 bit ffdshow?

2) People say LAV doesn't work well on 64 bit yet there is a 64 bit LAV? I am confused, what gives?

3) Does madVR work on the 64 bit edition of MPC-HC?

I don't see the point in this 64 bit edition thing :(

Today I was watching a movie which is around 2.5 GB and I got an error from MPC-HC that the program ran out of memory and I must restart it, this is what made me think, I wish I Was able to install the 64 bit edition of MPC-HC and make use of the 16 GB RAM that I have

[Superb]

1) Yes.
2) LAV works well on 64bits.
3) No. madVR is 32bits only. You have to use 32bits MPC-HC to use madVR.

About you running out of memory: You don't need 16GB of RAM to play a 2.5GB movie. You can (theoretically) even use 256MB of RAM and still be able to play the file. The player doesn't cache the entire file to the computer's RAM. It only reads the part it currently plays (while decoding a few frames forward). I'm guessing one of your filters (or the MPC-HC build you're using) has a memory leak (=doesn't free memory of unneeded data).

[vivan]

1) Yes.
2) I don't see any 64-bit-related bugs here (http://code.google.com/p/lavfilters/issues/list), so no. What it gives? Ability to use it with 64-bit players.
3) No, madVR is 32-bit only.

Out of memory? How much MPC-HC is consuming RAM if you open that video (before crashing)? Is it >1080p? Are you using SVP?

[LoRd_MuldeR]

You ask why there is a 64-Bit variant of MPC-HC? The real question is: Why not?

64-Bit operating systems have become the standard nowadays, so using 64-Bit binaries seems natural. Besides the fact the 64-Bit binaries eliminate the 4 GB memory limitation of 32-Bit binaries (may not be that relevant for MPC-HC), 64-Bit code also can be quite a bit faster! That's mostly because x86-64 has extended the size of all "general purpose" registers from 32-Bit to 64-Bit and also increased the number of those registers.

Of course a 64-Bit MPC-HC can only use 64-Bit DirectShow filters, but most of the relevant DirectShow filters should be available in 64-Bit nowadays. In the past there have been some problems with 64-Bit builds. Sometimes they haven even been slower than 32-Bit, because the Assembly stuff had not been ported to 64-Bit yet. But this kind of "teething troubles" should have been sorted out long ago for most projects, now that 64-Bit has become more major.

Last but not least, MPC-HC comes with a whole lot of Splitter/Decoder filters built-in, so in most cases you don't even need any "external" DirectShow filters ;)

[Snappy Phoenix]

1) Yes.
2) I don't see any 64-bit-related bugs here (http://code.google.com/p/lavfilters/issues/list), so no. What it gives? Ability to use it with 64-bit players.
3) No, madVR is 32-bit only.

Out of memory? How much MPC-HC is consuming RAM if you open that video (before crashing)? Is it >1080p? Are you using SVP?

Yes I am using SVP how'd you figure that out? very smart of you :)

[Snappy Phoenix]

You ask why there is a 64-Bit variant of MPC-HC? The real question is: Why not?

64-Bit operating systems have become the standard nowadays, so using 64-Bit binaries seems natural. Besides the fact the 64-Bit binaries eliminate the 4 GB memory limitation of 32-Bit binaries (may not be that relevant for MPC-HC), 64-Bit code also can be quite a bit faster! That's mostly because x86-64 has extended the size of all "general purpose" registers from 32-Bit to 64-Bit and also increased the number of those registers.

Of course a 64-Bit MPC-HC can only use 64-Bit DirectShow filters, but most of the relevant DirectShow filters should be available in 64-Bit nowadays. In the past there have been some problems with 64-Bit builds. Sometimes they haven even been slower then 32-Bit, because the Assembly stuff had not been ported to 64-Bit yet. But this kind of "teething troubles" should have been sorted out long ago for most projects, now that 64-Bit has become more major.

Last but not least, MPC-HC comes with a whole lot of Splitter/Decoder filters built-in, so in most cases you don't even need any "external" DirectShow filters ;)

Thanks for the explanation

so if I wanna use madVR I am stuck to 32 bit version of MPC-HC :(

Do I really miss out on a lot if I stop using madVR and only revert to using LAV 64 bit with the 64 bit version of MPC-HC?

What do you suggest?

[Snappy Phoenix]

I think I am stuck to using the 32 bit version if I want to use SVP, what a shame :( as I love the smoothness of 60 FPS that SVP gives :(

[LoRd_MuldeR]

Well, if you want to use MadVR and as long as there isn't a 64-Bit version of MadVR available, you'll have to stick with 32-Bit MPC-HC, obviously.

If, however, the 32-Bit version MPC-HC does run fast enough for "smooth" playback on your computer (with the files you want to watch), then having to stick with the 32-Bit version is no big deal.

As the others already said, the "out of memory" problem you mentioned is most likely the result of a memory leak and not a problem of using the 32-Bit version.

(If you have a memory leak somewhere in the program, then using a 64-Bit build would only give you more time before you run out of memory. It doesn't fix the actual problem at all!)

[Snappy Phoenix]

Well here is thing that's pissing me off guys, I have many video files and occasionally, when I am moving the seekbar to skip to diff. portions of the video, MPC-HC would freeze completely and I have to force shut down

Do you think this is a problem with SVP or the fact that I am using LAV?

What are the benefits of using LAV for me as opposed to sticking with DXVA decoder?

Here are my system specs:

ASUS G75VW-T1086V
CPU: i7-3610QM 2.30/3.30 GHz.
Memory: 16 GB DDR3 1600 Mhz. RAM
Storage: LiteOn LAT-256M3S 256GB SSD + Seagate Momentus 5400RPM 1TB HDD
Graphics: GeForce GTX 670M 3GB
Screen: 17.3' Full HD LED Screen
OS: Windows 7 Professional (x64)

[Snappy Phoenix]

hmm, interesting, the moment I switched LAV from CUVID to DXVA (native) that constant hanging when navigating through diff. parts of the movie has disappeared

[vivan]

Out of memory error is the result of very heavy settings + lot of threads.
You can start by:1. Change settings to more lite values for memory usage (Motion vector grid, Decrease grid step, Motion vector precision).
2. Reduce threads number: in the tray menu - Processing threads.

There's no x64 SVP because x64 avisynth is buggy (http://forum.doom9.org/showthread.php?p=1571950#post1571950). Also SVP wouldn't be faster, because 90% of time is spent for SAD/SATD that is identical for both x86 and x64. And same applies to all other filters in chain, except decoder, that is 1-2% faster (software decoder, if you're using h/w decoder it also wouldn't be faster).

[Snappy Phoenix]

Out of memory error is the result of very heavy settings + lot of threads.
You can start by:
There's no x64 SVP because x64 avisynth is buggy (http://forum.doom9.org/showthread.php?p=1571950#post1571950). Also SVP wouldn't be faster, because 90% of time is spent for SAD/SATD that is identical for both x86 and x64. And same applies to all other filters in chain, except decoder, that is 1-2% faster (software decoder, if you're using h/w decoder it also wouldn't be faster).

My SVP settings are all on default, I didn't change a thing except enabling "Detect Variable framerate" mode

Things have improved drastically since I changed the LAV decoder from CUVID to DXVA, no more hangs when moving through diff. sections of a movie. I don't know if I am missing out on any quality by doing that but I am stil using madVR so.... I dunno

[JarrettH]

I've always wondered this :D

[Pat357]

My SVP settings are all on default, I didn't change a thing except enabling "Detect Variable framerate" mode
Things have improved drastically since I changed the LAV decoder from CUVID to DXVA, no more hangs when moving through diff. sections of a movie. I don't know if I am missing out on any quality by doing that but I am stil using madVR so.... I dunno

If you're using MadVR, LAV will fall back from dxva to software (pure cpu) decoding.
My conclusion : your GPU HW decoding has apparently some issues (probably caused by SVP), so you better use software decoding. Again : Madvr doesn't support dxva ;)
Oh.. and a general suggestion : start reading the docs from the things you use :p :readguid: