Now that we actually have a good reason for 64 bit (much faster HEVC software decoding with LAV x64) and there is a 64 bit build of madVR it would be wonderful if there was also a 64 bit build of Zoom Player.
64-bit Zoom Player?
Posted 23 April 2015 - 01:30 AM
At the moment, I don't know what bLight's plans are for 64bit. We have had a small number of requests for it previously in the forums (going back a while), but I did mention to bLight when madshi released his 64bit build recently that it would probably trigger some more requests for 64bit Zoom (which it has, about three more now I think). Just keep in mind that the main requirement for a 64bit build is that a 64bit compiler actually exists. Zoom is coded in Delphi - which Embarcadero make the compiler for. For the longest time (some years), they resisted making a 64bit compiler, meaning everything coded in Delphi was restricted to 32bit. I think they may have finally got off their backsides and made a 64bit version of the Delphi compiler, at least this webpage seems to indicate:
Now that it appears that a 64bit compiler exists, it should be possible for a 64bit version without having to totally rewrite Zoom in a language that has a 64bit compiler (the well known file manager Total Commander had this exact same problem, and the dev got tired of waiting for Embarcadero and totally rewrote the code into Lazarus for the 64bit version, but that isn't something bLight would have had the time to do). Having said that - it isn't a simple matter of ticking a '64bit executable' box and running the compiler - 32bit and 64bit are different, and there will need to be code changes.
Even though bLight is aware of 64bit madVR, I think what I will do is to create a 64bit feature request in the tracker, and we will start trying to collect user support for it. I will link this thread into the report, so anyone wanting 64bit, please add your vote here. I will also go back through the forums and try and find the other requests for the 64bit version and link them into the report as well.
One last thing to keep in mind - if anyone uses reclock, you are out of luck. There is no 64bit version of reclock, and the current reclock maintainer has said that he has no plans to create one (oddly, I note the separate 64bit request thread seems to have been deleted from the reclock forums) - so even if there is a 64bit version of Zoom available, you would still have to use the 32bit version for reclock.
Edit: Request number is 775 in the tracker.
Edited by ehathgepiurhe, 23 April 2015 - 01:51 AM.
Posted 23 April 2015 - 11:28 PM
Hi, my first post, long time forum reader and zoom max user.
Yes I too wanted to know this answer having got the madvr x64 build installed. I also use reclock and the news above is not great. I wonder what 2-5 years down the road will bring in regards to developers changing their minds on being so resistant to x64 builds.
I use a window 7 computer with 16 Gb of ram, and am planning a new build next year with 2016's new tech. So 32GB of fast DDR4. I use Firefox and palemoon web browsers, with up to 1600 tabs in my current session. Using session manager and on demand tabs. A little excessive yes but palemoon x64 handles ity so beautifully. In similar respects it will eventually just feel more natural to have everything working in x64 bit when we have a lot of ram, lots of CPU cores.
A lot of resistance to x64. Maybe not enough time has passed yet and new ways of working to be fully fleshed out and developed. In 5 years time I suspect the x64 bit transition will be well underway, if not almost complete.
Posted 25 April 2015 - 01:39 AM
Welcome to the forums Jonny I know there are a few people over on Doom9 who are in the same boat as you regarding Reclock - so you are not alone! A few people posted in the previous Reclock release thread asking for a 64bit build, so I think at least the developer knows that there are people who want it:
https://forum.slysof...7594#post407594(and following posts)
You are right in saying that there has been some resistance to 64bit builds of programs by developers. There are reasons for that - a lot of programs do not require 64bit builds to work correctly on a 64bit system (a text editor for example), and would provide absolutely no benefit to being 64bit even if they were so - so for the developer, the question arises as to why they would bother doing it. Video playback was in this exact same position up until relatively recently - but now at least there is a clear benefit for 64bit video playback. HEVC (aka H265) specifically - the performance of the 64bit decoders is very much higher than the 32bit decoders. For us Zoom users, we have long had a 64bit build of a good set of decoders (LAV), but the second last missing piece of the puzzle has been the video renderer. With madshi's surprise 64bit release of madVR recently, that piece is now in place - all we need now is the player. As I say, it isn't just a case of ticking a "64bit compile" box and then compiling the code again, but hopefully we can gather enough support to convince bLight it is worth the time to do it.
(Of course, Reclock is another matter entirely!)
Posted 25 April 2015 - 03:54 AM
When zoom player goes x64, would it not also be a good idea to try and create your own version of reclock intergrated into zoomplayer x64 (supoporting 24bit high sample rate). lav, madvr and an x64 internal reclock like feature. Zoomplayer would then be the ultimate player.
Posted 25 April 2015 - 06:00 AM
would it not also be a good idea to try and create your own version of reclock intergrated into zoomplayer x64
That's very unlikely to ever happen I'm afraid. The design philosophy behind Zoom is that it relies on non-integrated, stand-alone, third party, playback components - bLight doesn't want to create or maintain his own playback components essentially. The MPC-HC guys are developing a new audio renderer which will apparently be available in the near future - I've been wondering if i. It will be a stand-alone filter and ii. If so, will it have some Reclock like functionality (not sure about this, haven't been able to find a great deal of information on it). If the answer to both those is yes, then it may be a solution.
I say 'may' because while Zoom does have an ability to use a custom video renderer but it does not have an ability to use a custom audio renderer - if the new MPC-HC renderer is stand-alone and does have some benefits, I will be suggesting to bLight a custom audio renderer option however (assuming it doesn't come as a stand-alone filter version, which is something we can already make use of in Zoom just by adding it to the relevant Smart Play profile - I understand the MPC-BE audio renderer can be used in this fashion). Edit: See Post #11 below, Zoom can already use a custom audio renderer.
Edited by ehathgepiurhe, 18 May 2015 - 10:23 AM.
Posted 25 April 2015 - 06:45 AM
Ah ok I see. Thanks for the reply.
Will have to see what the landscape looks like at the end of the year going into 2016 and beyond.
Posted 25 April 2015 - 07:57 AM
Will have to see what the landscape looks like at the end of the year going into 2016 and beyond.
Yep, I think the main thing at the moment is to get Zoom itself as a 64bit version, and then see where we stand at that point
Posted 28 April 2015 - 06:27 AM
Thanks for the update, it is great news that Delphi has a 64 bit compiler. Here's hoping that a 64-bit build wouldn't be too much work.
Posted 03 May 2015 - 08:39 PM
Right now I don't see much need for the 64-bit version of Zoom Player because there are no major benefits of using such a version ... but in the near future (hopefully even this year) when UHD H.265 content (both Blu-Ray and TV - Satellite/Cable and streaming) becomes more popular the need for 64-bit version will become bigger. As you may already know there are some pretty big benefits in the decoding chain (like 50~100% better decoding speed in LAV Video) when using 64-bit ... and this might be very important for users with older PC hardware.
Posted 18 May 2015 - 10:21 AM
I say 'may' because while Zoom does have an ability to use a custom video renderer but it does not have an ability to use a custom audio renderer
I must have been half asleep when I wrote that - it is nonsense (ie incorrect). While it is true that Zoom does not have an option named 'Custom' in the Audio Renderer field as the Video Renderer field does, that is because it doesn't actually need it. Once you install a new audio renderer, it will appear in the Audio Renderer field automatically, as I show in the following screenshot with the MPC-BE audio renderer, which I installed on my system:
Relating it back to the topic at hand (64bit), if the new audio renderer for MPC-HC has Reclock functionality, we should be able to use it in Zoom without any changes as long as they release it in the standalone filters package they offer for download (that is how I installed the MPC-BE audio renderer - I used the 32bit package as Zoom is still only 32bit, but it has a 64bit version available, and I am assuming the MPC-HC renderer would come in both 32bit and 64bit).
The reason why I decided to install the MPC-BE audio renderer was that someone posted over on Doom9 that now that they could use the MPC-BE renderer inside MPC-HC, they would be getting rid of Reclock. Checking the MPC-BE renderer's options, I am not sure what they are referring to. The main reason why Reclock is used AFAIK is PAL speedup:
If so, there is nothing like that listed in the MPC-BE renderer's options - but there is a WASAPI option. I assume that Reclock also offers WASAPI - I know it is important to a small number of people - and maybe this is why the user would be able to get rid of Reclock:
Reclock users: What do you personally use Reclock for? If it is something other than PAL speedup, there may already be alternatives, and thus one less obstacle when it comes to a 64bit version of Zoom.
Posted 20 May 2015 - 01:17 PM
Not being to technical, but I have been using reclock for some years now to keep things all matched up sync and speed wise. Maybe I could do without it now. I use the 24bit / 48khz stereo output (WASAPI) to my plasma TV via HDMI. Seems to work well.
But I would like to see the back of it in favour of something zoom would install as part of its install centre. So I hope things do move on in this area soon and in turn we get a replacing and x64 zoom.
I'm not sure what we gain if zoom was x64, lav x64 and mVR x64 and what ever audio x64 renderer we end up with. Can someone explain why x64 might/is better. My only real experience with x64 being better is with using palemoon x64 browser and my 16Gb ram and it handling my 1000+ tabs I have in my current session. Sometimes 1600 tabs. palemoon x64 handles that with ease.
Posted 21 May 2015 - 10:34 AM
I use the 24bit / 48khz stereo output (WASAPI) to my plasma TV via HDMI.
I must admit, I am testing the WASAPI option in the MPC-BE audio renderer at the moment, sometimes I get strange 'pops' in the audio of files, and I am wondering if it may be due to latency, and if so, the exclusive mode that WASAPI offers might be able to help with this. Anyway, I shall see if it helps.
Can someone explain why x64 might/is better.
No difference in functionality or visual quality at all, the single thing we gain is performance increases. This won't apply across the board - for example, if you play a simple AVI file on 32bit Zoom and then played it on a hypothetical 64bit Zoom, you should not see any difference in performance or visual quality. Where you will see a difference is this (quoting mitko from post #10):
. but in the near future (hopefully even this year) when UHD H.265 content (both Blu-Ray and TV - Satellite/Cable and streaming) becomes more popular the need for 64-bit version will become bigger. As you may already know there are some pretty big benefits in the decoding chain (like 50~100% better decoding speed in LAV Video) when using 64-bit
So, H265 (HEVC) is the real target of 64bit playback. There is not too much H265 content out there compared to H264 - I'm not even sure I have any H265 files in my test file collection, let alone any real content encoded with this - but some people have high hopes of it overtaking H264. We'll see.
There is one other thing we gain - some people have a weird desire to see every process running on their 64bit system as true 64bit, even when it would make utterly no difference at all (don't get me wrong, there are programs where 64bit is critical for running on 64bit Windows, but there are vast amounts of programs that would not benefit from 64bit in any way, shape or form). That is, Task Manager on Windows will show a "*32" beside a process for 32bit processes on Windows 64bit and some people do have a desire to see nothing in their Task Manager screen with "*32" beside it.
Posted 21 May 2015 - 11:37 PM
I see. Thanks for taking the time to explain. I've been following so muych about x64 everything but only really have experienced the benefit of x64 palemoon browser with my 16gb ram and 1000+ open tabs I run. So I am looking forward to the stable official Firefox x64 finals release (not the beta) and at time when all the plugins also work well enough for me to make the move over.
Posted 22 May 2015 - 10:57 AM
Indeed, web browsing with lots of tabs open will benefit greatly from 64bit. Along those lines, that is one other potential advantage a 64bit Zoom would have. See this post and following (the discussion on large address aware):
Zoom as a 32bit process can only address a certain amount of RAM, even with the large address aware flag set. A 64bit version would essentially remove that limitation for the foreseeable future (64bit still has an addressing limit, but it's very large). In short, it is possible to crash 32bit Zoom under certain circumstances (with a very high resolution video, a high resolution screen and a lot of subtitles with a lot of formatting for example). The crash is because Windows hits the RAM process limit for 32bit processes - a 64bit version would not crash under these circumstances.
Posted 28 July 2015 - 10:02 AM
I mentioned a new audio renderer being developed for MPC-HC, in a couple of posts above (#6 and #11) - particularly in relation to it maybe being a possible replacement for Reclock, which looks like it will never have a 64bit version. The first version of that audio renderer has now been released:
It is called 'sanear'. It is standalone, it does work in Zoom (I'm using it now), and it does come in 64bit as well (Zoom obviously can only use the 32bit version at the moment). As for the Reclock functionality, some Reclock functionality is planned by the developer, but atm, it is not clear exactly what is planned:
He calls it "guided Reclock interface" - I don't find that very descriptive, but hopefully in the near future we will see what that actually means. Anyway, this doesn't really get us any closer to a 64bit Zoom, but if we do get a 64bit replacement for Reclock, literally the only thing left standing - as 32bit only - will be Zoom itself...
Posted 05 August 2015 - 05:59 PM
Thanks for the sanear info. I'll give it a try as well.
Posted 22 August 2015 - 02:08 AM
Just reposting this on this x64 thread.
Also, came across this today, MPDN Reclock (post on the MPDN player thread)
Having some reclock like 'in house' feature for zoomplayer would be good, that works well with sanear also. For future proofing. Breaking free of reclock stand alone, and embracing x64 for zoom. I'll buy that zoom player upgrade for sure.
Posted 22 August 2015 - 03:39 AM
Indeed, it appears that MPDN has some collaboration with sanear, judging from the Reclock issues thread for sanear:
If that is what has been added to MPDN, it may well be that it can be added to other players (eg Zoom) as well. I've asked bLight about it (though if it is going to be added to sanear, my guess is that bLight will prefer that Zoom makes use of that rather than adding it to Zoom directly).