Can anyone confirm 64 bit?
havent found any reference on Apple's site and the marketing doesn't seem to show much difference from 3.5 :/
Apple Event: May 7th at 7 am PT
havent found any reference on Apple's site and the marketing doesn't seem to show much difference from 3.5 :/
It is 64 bit. Other than that, they added a bunch of new formats (Hello, Open EXR and TIFF!) and there are more and easier hooks into Qmaster for distributed rendering.
It's quicker too!
Would love to see it in new FCP black though.
It is 64 bit. Other than that, they added a bunch of new formats (Hello, Open EXR and TIFF!) and there are more and easier hooks into Qmaster for distributed rendering.
It's quicker too!
Would love to see it in new FCP black though.
thanks i'll consider that solved!
No it is isn't.
Open Compressor, then open Activity Monitor... do you see an "Intel (64-bit) tag" next to it? Because I don't...
See above...
Open Compressor, then open Activity Monitor... do you see an "Intel (64-bit) tag" next to it? Because I don't...
Leaped before I looked on that one. RedHavoc is right. The CompressorJobController is 64 bit. The application itself (and its individual, processor core specific instances) are still 32 bit. So it seems the only real reason to buy it is to tie into FCPX.
Still seems faster, but maybe that's just wishful thinking on my part. Stranger things have happened. 😉
Even though the new Compressor is not 64 bit. It may well be faster, depending on the job. It does require a better video card than 3.5 because it would let me install it on my Mac Pro until I upgraded to a ATI Radeon 5770. I assume that it is farming out some of the work to the video card. I have only done a couple of jobs but the settings are not the same as in Compressor 3.5 so it is difficult to make a comparison. It doesn't seem significantly faster but the quality seems better going to DVD but this was only one experiement. Gerry
The CompressorTranscoder is still 32-bit which means that all of the "heavy lifting" is still being done within a 32-bit process. This is probably happening because all of the codecs are still 32-bit (i.e. QuickTime 7 based). This may change in Lion but we won't know that until Mac OS X 10.7 ships and we (potentially) get a new 64-bit version of Compressor 4.
Just lost a long post because the Apple Discussions went off line for an update (what's up with these frequent interruptions to the discussions area?).
In any case, I just noticed that the H.264 codec still APPEARS to be limited to two cores/threads so you get no real benefit from having a quad-core (or higher) CPU when running a job in Compressor v4. Moreover, it appears that Compressor only runs one CompressorTranscoder process so even when you have multiple jobs queued for output they are done serially, one after another and using only two CPU cores.
Well, at least that is what I see when running an HTML Live Streaming job on my quad-core Mac Pro running Mac OS X 10.6.7. HTML Streaming outputs six different versions of the file in H.264 format and each is done serially in Compressor 4. It would seem that the job time could easily be cut in half (or better with additional cores) if they just used separate processes for each compression job.
Are others seeing the same thing? Maybe I've got a configuration or resource problem on my system.
im assuming you have 4 instances selected in your cluster node options…
ubernaut wrote:
im assuming you have 4 instances selected in your cluster node options…
Thanks, I'll look into that. However, I seem to recall that under Compressor 3.X that made little difference on my quad-core machine. In fact, it may have even caused a slowdown in the job processing.
nope if you dont set it to 4 instances (or however many cores that node has up to a possible 12 currently) you'd never be able to utilize all cores if you do then you will i can confirm this works in earlier versions.
Something I don't know here... how do I do this?
Right, surely that only makes a difference if you are using your computer for distributed rendering over a network?
I got the impression above that you were talking about something that had to be done to ensure compressor uses all cores within your own computer?
yes this makes a difference for any multicore node wether it is one machine or many. try it you should see a noticeable difference in encoding times for any sufficiently large transcodes. i get about ~150% (with 2 cores) when processing as This Computer, as a cluster my utilization is usually 180 to 190 range.
Can anyone confirm 64 bit?