Closed GoogleCodeExporter closed 8 years ago
None, at least not anytime soon.
Original comment by cyber.sp...@gmail.com
on 9 Jan 2012 at 2:09
When working with high bit-rate masters of my work, I use MPC-HC 64-bit, and
require good subtitle rendering through such player. Is there any way a 64-bit
build will ever come? Right now both MPC-HC and LAV have 64 bit builds that run
flawlessly with my workflow and on my highest-quality finished masters, while
MadVR and xy-vsfilter (this) have shunned 64-bit, despite the soon-to-be total
transition to 64-bit code. Putting off such a build and pointing to a 32-bit
version only delays the inevitable. Why not get it done sooner rather than
later, and garner more support and use by those who want to afterward.
Original comment by dylan...@gmail.com
on 30 Apr 2012 at 2:27
As of January 8th, the day before Shark007 asked this question, the project has
been on hiatus and still is. Hence my "None, at least not anytime soon"
response on January 9th.
The reason why x64 support is low priority to us is because x64 useless to
VSFilter. Our dev time is better spent working on things which are actually
useful.
That said, recently members of the MPC-HC project have expressed interest in
xy-VSFilter, so whenever the merge into their codebase occurs, x64 support will
likely be added (assuming our project is off haitus at that point).
> When working with high bit-rate masters of my work
I'm curious as to why you feel the need to use x64 for playback of "high
bit-rate" masters in MPC-HC? Using x86 should work just as well if not faster,
and with lower memory use.
If you've done tests which show using x64 MPC-HC offers a significant benefit
over x86 MPC-HC in your workflow, would you care to share them?
Original comment by cyber.sp...@gmail.com
on 30 Apr 2012 at 8:19
I've made some tests with recent beta build x64 MPC-HC (1.6.2.4573) and I got
surprised. The application did use more memory, but not so many as I though
(maybe 20-50 MB which let's say, it's not that many. But my playback was way
more flawless, I couldn't even think about playing 1080p files, since my modest
Core 2 Duo @2.20 can't even handle properly 720p 10-bit (with x86). Here's some
numbers:
MPC-HC 1.6.2.4573 x86:
CPU resources - about 11% average, flawless playback. (480p)
CPU resources - about 27% average, flawless playback, with some stutter in
high-bitrate sources. (720p)
CPU resources - about 100% average, lot of dropped frames. (1080p)
MPC-HC 1.6.2.4573 x64:
CPU resources - about 12% average, flawless playback. (480p)
CPU resources - about 29% average, flawless playback, even with high
bitrate/effects used in subtitles. (720p)
CPU resources - about 99% average, more flawless playback, although I get 70%
of the time some dropped frames.
The RAM pretty much was raped here, with both builds, about 160 MB to 890 MB
for each type of source.
Both builds were tested with LAV Filters 0.50.1, madVR 82.5, and xy-VSfilter
3.0.0.8.
Just a little heads up, my laptop configuration is overall modest, so these
results will most probably be better/worse with other computer specs, although
I believe x64 is still useful, I agree that there's a lot of other more useful
things to work on, I'm just here to make the statement of the issue a little
more solid.
Original comment by kyuny...@gmail.com
on 3 May 2012 at 3:16
Forgot to mention that madVR was only used in the x86 build. For the reason we
all know.
Original comment by kyuny...@gmail.com
on 5 May 2012 at 5:48
madVR always uses a few percent more CPU resources and is more sensitive to
dropping frames than other renderers.
madVR will stutter if you don't have the flush settings optimally set.
madVR without a powerful enough GPU can cause both stuttering and dropped
frames.
I'd recommend you repeat the x86 test with the same renderer as the x64 build.
Original comment by cyber.sp...@gmail.com
on 5 May 2012 at 6:28
I've been using madVR for quite some time that I forgot to use these
attributions, my apologies. I'll do some thoroughly tests today and post them
tomorrow maybe, my Windows need some tweaking first, since I'll be using both
Windows 7 and 8.
Original comment by kyuny...@gmail.com
on 6 May 2012 at 10:43
Managed to post this before sleep time.
I removed madVR from the tests as it should, and xy-VSFilter itself (to make a
more cleaner benchmark).
My laptop specs are:
Intel Core 2 Duo @2.20 GHz
Intel Graphics 4500MHD (64MB)
4GB DDR2 RAM
MPC-HC build 1.6.2.4622
LAV Filters 0.50.2
Windows 8 Consumer Preview x64
# CPU Resources #
x86
480p: 6.7% average | 28.4% was the higher one.
720p: 13.2% average | 33.9% was the higher one.
x64
480p: 9.4% average | 18.9% was the higher one.
720p: 17.8% average | 38.1% was the higher one.
# RAM resources #
x86
480p: About 67 MB.
720p: About 101 MB.
x64
480p: About 89 MB.
720p: About 134 MB.
One thing I should point out here again, is that I'm just doing these to prove
that aside the higher amount use of resources in the x64 builds, the overall
performance is really noticeable, the start up of MPC-HC itself is instant, and
the load of video too, even using other applications don't cause video to
stutter or crash (rare cases). I removed the 1080p rank because I can't handle
it without madVR (although x64 can play it, the dropped frames are way too big,
so it's not watchable). If there's something that I should point out/did wrong,
you're free to correct me.
Original comment by kyuny...@gmail.com
on 6 May 2012 at 11:46
Hello
I'm gentle pinging this bug and asking what's the status and future plans to
compile 64bit builds. I hope it's not to hard to do that and only you will need
to compile it with 64bit mode.
Best regards
Original comment by gis12l...@gmail.com
on 15 Aug 2012 at 9:10
Original comment by cyber.sp...@gmail.com
on 13 Oct 2012 at 3:47
64-bit builds of xy-VSFilter are now available
Original comment by cyber.sp...@gmail.com
on 20 Nov 2012 at 9:31
Yay!
Thank you! :)
Original comment by dominik.rutschmann@gmail.com
on 20 Nov 2012 at 10:15
Thank you very much!
We appreciate this hard work.
Original comment by Bern...@gmail.com
on 22 Nov 2012 at 8:39
[deleted comment]
@yuyuanzeng123
I'd suggest asking this question on their forums:
http://shark007.net/forum/index.php
Original comment by cyber.sp...@gmail.com
on 27 Feb 2014 at 2:41
Original issue reported on code.google.com by
Shark007...@gmail.com
on 9 Jan 2012 at 1:19