The present and future of post production business and technology | Philip Hodgetts

Nov/11

6

Three companies, three different approaches to 64 bit.

During the week I got this email, and it’s a really good question, so I decided to clean up my response and post it here.
I figured you could answer this question, one which has been knawing on me since I first saw the beta of MC6.0.  How is it possible that Apple, and Adobe had to rewrite their apps virtually from scratch in order to switch to 64 bit, but Avid didn’t?  Is MC6.0 really 64 bit?

It’s a really good question. When an application needs to move from 32 bit to 64 bit, there are many approaches, but one thing is certain: all the code has to be 64 bit, including any dependencies or plug-ins. By dependencies I mean where the application relies on OS frameworks or libraries, such as QuickTime or AVI or other OS level service.  All these must be 64 bit or the application can’t compile to 64 bit. So all three companies had some rewriting to do, but because of their histories it’s actually different for each app.

Even though Premiere Pro is the most modern app of the three (Premiere Pro, Media Composer and Final Cut Pro) having been completely rewritten ahead of the 2003 release, it still largely depended on AVI (Windows) and QuickTime (OS X) for media handling. Neither have been adequately rewritten for 64 bit: AVI because all development stopped in 1996 (the zombie format that will not die) and QuickTime because Apple decided to transition to AVFoundation for media handling in applications, after attempting a partial rewrite of QuickTime as QTKit in 64 bit.

So, Adobe decided to write their own media engine so they could go to 64 bit without the external dependencies. (Premiere Pro still imports and plays QuickTime media by use of a complex workaround.) Most of Adobe’s code is C or similar with only an OS level wrapper around the cross platform code. So it’s “true” Cocoa on OS X because the interface is a heavily subclassed Cocoa frameworks (subclassed to make it look like an Adobe app, in the same way many Cocoa frameworks are subclassed in FCP X for its unique look).

Avid also decided to rewrite all their code from scratch, but instead of one big hit, they have been progressively rewriting their code for the last  three or four releases, if not longer.  You can write the code and have it compile into a 32 bit application (MC before 6) and then when you have all the app ready in 64 bit, you recompile it into 64 bit. Avid did not need to radically change the application, although there are two very major changes from the original code base. Avid Media Architecture was Avid’s approach to the multiplicity of non-tape sources, and it was all new code ready to recompile to 64 bit when the main application did. Avid also appear to have changed their approach to hardware interfaces with Media Composer 6, integrating a hardware abstraction layer so that third parties can integrate with Media Composer without needing to make any changes to Media Composer code. (Previously the Media Composer code needed to be rewritten to talk to each piece of changed hardware.

Apple had to rewrite because their media engine – QuickTime – was only partially rewritten to 64 bit and was lacking most of what the Pro Apps team needed for a modern video application. The solution to the media engine was AVFoundation originally created as the media frameworks for iOS and ported back to OS X with 10.6.7 and Lion,  which is why FCP X requires 10.6.7 or later.

Adobe relies on its own proprietary media engine. Avid relies on its proprietary media engine.  Final Cut Pro  X relies on AVFoundation, which only exists on OS X and iOS and is very, very new to code to0. (This was the likely reason that broadcast video out was delayed, because they had to wait for AVFoundation to be finished before BMD, AJA etc could even start work on drivers no longer based on QuickTime.)

All are really 64 bit, but they’ve taken different paths to get there, as they had different needs.

No tags

4 comments

  • Benni · November 7, 2011 at 1:05 am

    Interesting & Informative

    Thanks.

  • Andrew Richards · November 7, 2011 at 4:31 am

    QTKit still had some development in Lion: http://bit.ly/sGOZvV

    It looks like QTKit has been relegated to wrapper handling while AVFoundation and CoreMedia have been handed the reins for media handling.

    I also noticed that there is a new Device Abstraction Layer plug-in API in Lion for CoreMedia that seems to be the ticket for AJA, BMD, et al: http://bit.ly/v0gjax

    • Author comment by Philip · November 7, 2011 at 8:18 am

      I was aware that there was some additional QTkit development on Lion but it’s very minor. QTkit is deprecated (don’t use for new code) and really provides a wrapper around a tiny, tiny portion of the QT C API – not enough to build a complex app in 64 bit. And you’re right that AJA, BMD et al have had to wait for that Device Abstraction layer before they could start work on broadcast video out of Final Cut Pro X.

  • Carey Dismore · November 7, 2011 at 5:26 am

    Hi Philip,

    This is a great post, in that it sums up and crystallizes into one, concise, linkable page the overall sense of the software architectures and development curves of these three major editing tools and I will be happily sharing the link in the hope that others can get a good working knowledge of the subject. Thank You!

<<

>>

November 2011
M T W T F S S
« Oct   Dec »
 123456
78910111213
14151617181920
21222324252627
282930