The reason FCP is not 64-bit
by Alan Okey
on
Sep 14, 2009 at 7:58:45 pm
Ars Technica has a very technical, in-depth review of Snow Leopard, in which Quicktime X is discussed. Essentially, Quicktime is only just now making the 64-bit transition, and Quicktime X has very limited functionality relative to Quicktime 7. The features of Quicktime that are used extensively by Final Cut Pro are not yet 64-bit, so it's impossible for FCP to be a 64-bit application until Quicktime X is developed enough to fully support all of the features present in Quicktime 7. This isn't likely to happen in the near future.
To quote the article:
"As anxious as developers may be for a full-featured, 64-bit successor to the QuickTime 7 engine, Apple itself is sitting on top of one of the largest QuickTime-riddled (and Carbon-addled, to boot) code bases in the industry: Final Cut Studio. Thus far, It remains stuck in 32-bit. To say that Apple is "highly motivated" to extend the capabilities of QuickTime X would be an understatement."
This is one of the most comprehensive discussions of Quicktime and 64-bitness that I've come across. Hopefully it will address many of the questions from the editing community about why FCP isn't yet a 64-bit application. It's because Quicktime is undergoing a complete overhaul to become 64-bit capable, and since Quicktime is pervasive throughout FCP's basic structure, FCP will share the same fate as Quicktime when it comes to its development pace.
Please link back to this post when this topic pops up again (and it will) on this forum.
Re: The reason FCP is not 64-bit by walter biscardi on Sep 14, 2009 at 8:39:09 pm
Nice find Alan.
Walter Biscardi, Jr.
Editor, Colorist, Director, Writer, Consultant, Author.
Credits include multiple Emmy, Telly, Aurora and Peabody Awards.
Owner, Biscardi Creative Media featuring HD Post Biscardi Creative Media
Creative Cow Forum Host:
Apple Final Cut Pro, Apple Motion, Apple Color, AJA Kona, Business & Marketing, Maxx Digital.
Re: The reason FCP is not 64-bit by Alan Okey on Sep 15, 2009 at 3:39:38 pm
[Craig Shields]"hen you say "not likely to happen in the near future" are you talking NAB or later than that? "
I have no clue. I'm a skeptic at heart, so I wouldn't hold my breath for any NAB revelations. John Siracusa, the author of the article, might have more insight into your question than I do.
I'm not convinced that FCP is constrained by RAM usage at this point, however. Rendering is CPU-constrained much more than it is RAM-constrained. I think there's more performance to be eked out of FCP through multithreading/multicore optimization than from maximum RAM usage. Technologies like Grand Central and OpenCL need to be tapped by FCP just as much as the increased RAM made available through 64-bit addressing.
There's no magic 64-bit fairy dust that immediately makes everything run faster and better if an app is natively 64-bit. There are certain kinds of applications that use large data sets that can benefit from 64-bit memory addressing, but I'm not sure that FCP is one of them. Considering that video is frame-based, and even the very largest formats have frame sizes that fit well within the 4GB limit of a 32-bit app, I'm not sure how 64-bit memory addressing would speed up rendering beyond allowing for the rendering of multiple concurrent frames, something that would have to be supported at the thread level as well. But this is just conjecture on my part. I don't have a degree in computer science, and I'm sure someone with the proper credentials could shed more light on the subject, if only in theory.
Re: The reason FCP is not 64-bit by Zak Mussig on Sep 15, 2009 at 9:06:38 pm
Alan,
I also read the Ars review and found the bits about QT especially interesting, but didn't think to post it here... thanks for sharing.
With regards to FCP adding support for Grand Central Dispatch and Open CL vs becoming 64 bit, it's not an either/or situation, but more like a both/and. Using the new technologies from Snow Leopard and taking advantage of more RAM by becoming 64 bit both involve a rewrite of the FCP code from Carbon to Cocoa. I'm just hoping they hold back on use of core animation when they do make the switch... I'm not particularly ken to watch my clip physically move from the viewer to the timeline when I make an overwrite edit.
With all the potential benefits to FCP users it would surprise me if this rewrite hadn't been in the works for a while and that FCS 3/09/o-rama represents more of a "we haven't forgotten about you / here are some new tweaks we came up with that didn't break the old code too much" release along the way.
Re: The reason FCP is not 64-bit by Erik Lindahl on Sep 16, 2009 at 8:51:56 am
The problem is as mentioned above quite complex since FCP uses alot of the core of the OS for it's operation. But, even if we disregard a full move to QuickTime X (which today might not even be possible even if they wanted to) moving to cocoa and the new features of SL should be. Someone more wizzy than me might be able to answer if the old 32-bit QuickTime can reside in a new 64-bit app, as I understand it it can since all calls go to QTX how then has a "side-kick" (the old QT7) and that means gradually we can see more and more benefits come to FCP.
In regards of using technologies such as Core Animation, no, this should def. only be used when required. But a timeline / UI that is 100% hardware accelerated can do some magic things. I just think porting a huge app like FCP to Cocoa take time since it need to be done right and there are a lot of things to sort out on the way (and probably a lot of architectural re-thinking to be done).
Erik Lindahl
Freecloud Communication
------------------------
