|
Developing Successful Omf Interchange - Support for Omf (Open Media Framework) exists in most editing products from Avid, including DigiDesign Protools, and presents the most important portal of project interchange with Avid products. Any Omf solution must work usefully with the Avid products - if not that system is an island, putting it at a disadvantage in the market. Manufacturers contemplating support of Omf interchange in their products have encountered the complexity of the subject. Those who have attempted implementation have experienced the difficulty. This challenge stems from several factors -
The Omf Specification Omf is an edit data interchange format introduced by Avid Technology in 1990. Omf is a binary file format using object-oriented technology. It uses a 'Bento' object container (an Apple technology) into which data in the form of the 'Omf Object Model' is placed. The use of the Bento container provides the foundation for building an extensible interchange format. The Avid Omf Object Model is an insightful design for capturing edit data. As a whole the format provides the capability of interchanging very rich edit information about a project. This comes at the cost of abstraction and complexity - it is not so easy to understand. Originally released as Omf1, Omf2 was introduced in 1996 to enhance the capabilities and efficiencies. Omf2 is very different from Omf1. They share similar technologies, but data types, properties, and semantics changed in important ways. This bifurcation of the format caused more complexity and most applications will need to support both. The specifications are published by Avid. The Avid Omf Toolkit Avid also supplies the "Omf Toolkit" to help promote the Omf interchange format. The Omf Toolkit is a remarkable piece of programming. The Toolkit includes a libraries to implement the Bento container, media 'codecs', and the Omf Model itself. The Toolkit is written (quite brilliantly) in C (not C++) making it dense and difficult. It also has some bugs. However there is no practical alternative - any Omf project must begin with the Omf Toolkit if all the features, including Omf2, are to be effectively implemented.It includes both high-level and low-level calls. Experience shows that the higher-level calls do not always satisfy application needs and so, typically, much programming is done with low-level calls. On the face of it it appears the Omf Toolkit can be used directly to implement interoperability applications, and this is true in some limited circumstances. However, the Omf Toolkit does not, by itself, address all the issues presented by edit data interchange in general and the Avid product line in particular. Real-World Omf The Omf specification and its toolkit are only part of the story - not all implementations comply with the specification as strictly as one would hope.In particular, Avid's own Omf implementations are based on proprietary code - not on the Omf Toolkit code. Hence Omfs from Avid products do not have an identical footprint nor behave exactly as might be expected from the specification or from examining the Tookit. There are a couple reasons why this is so. First, the Omf specification intentionally leaves room for proprietary data. The Avid uses and requires certain types of private data to operate correctly. The Toolkit does not take care of all the Avid's needs to interchange a 'baseline' project. Of course some types of data are *intentionally* obscured. Second, Omf and its implementation in the Avid emerged together. Any complex software project can have bugs, and this is no exception. Edit Data Management In addition to these difficulties, edit data interchange is a complex business in itself. Edit data from modern edit systems is complex. It is easy to underestimate the difficulties in dealing with that complexity. Issues that appear to be simple, such as timecodes and track mapping, are discovered to be challenging. Mapping from one system to another requires thorough understanding of both target architectures. Mapping a client application's edit data to and from Omf demands knowledge of the Omf Object Model and the file format. The Testing Matrix Testing is an important aspect of edit data interchange and is particularly daunting where Omf is concerned. Any interchange system must be tested carefully between systems. In Omf this also means Omf1 and Omf2, Macintosh and Windows, NTSC, PAL, and Film, and each and all of these on the many versions of Avid Media Composer and Protools. If audio media is considered then the testing expands to include SD2, AIFF, WAVE, Broadcast WAVE, all in 44.1K and 48K and their pullup and pulldowns. This is a large testing matrix and it is easy to see how this can be a very large component of development costs. Taken together these factors paint an expensive picture of Omf development. MaxOmfSdk Developer's Toolkit The MaxOmfSdk provides OEMs with a practical path to Omf interchange. MaxOmfDSdk is a c++ .dll wrapped in an extern "C" api. It provides functions for parsing an Omf file to an internal database, populating the database with client application edit data, retrieving edit data, and writing Omf files, including audio media data. Both Omf1 and Omf2 are supported . MaxOmfSdk is the result of years of experience with Omf and EDLs. Brooks Harris is developer of EdlMax and has created several OEM Omf implementations including the Avid MCXpress. |
