Edit data in an Omf file is complex. It contains many types of objects which are recursively linked. Extracting data from an Omf or creating a valid Omf file is notoriously difficult.
The point to MaxOmfSdk is to simplify reading and writing Omf files.
On input, an Omf is "flattened" and normalized into structures which represent the Omf's edit data at the "top" or "final" level. All recursive and reentrant objects have been eliminated - the data representing the final composition has been "percolated" to a single layer. The structures and data are in no way recursive or reentrant and all data is normalized, that is, all timecodes are of the same type, etc.
On output, MaxOmfSdk data is written to an Omf file with all SDK data components transformed to native Omf representation.
To serve these purposes, the design of the MaxOmfSdk edit data borrows characteristics from conventional EDL and Omf architectures.
First, The MaxOmfSdk object design is roughly analogous to Omf because this is useful in retaining crucial edit data relationships. But, while Omf allows unlimited nesting between its objects, the MaxOmfSdk design reduces this complexity to a single level of indirection.
Second, MaxOmfSdk uses a design for its Events which is similar to conventional EDLs. This makes position and length along the timeline explicit, helping reduce development complexity.
The Tracks of a composition are organized similar to Omf. The composition (mxOmfProjectInfo_t) hold a list of Tracks (mxOmfTrackInfo_t). Each Track contains a list of Events.
|-------------------------------|
| |
| Project / Composition |
| |
| |-------| |-------| |-------| |
| | Video | | Audio | | Audio | |
| | Track | | Track | | Track | |
| |-------| |-------| |-------| |
| | | | |
| Event Event Event |
| Event Event Event |
| Event Event Event |
| |
|-------------------------------|
Events (mxOmfEventInfo_t) along the timeline track and event data are arranged similarly to a conventional EDL event, with some important differences.
In a conventional EDL, events come in two most important forms, a single-line event for cuts, and a two-line event for transitions. (There are others, including 'keys', not covered here)
edit tape sourceIN sourceOUT recordIN recordOUT
001 REEL1 V C 03:00:00:00 03:00:12:00 01:00:00:00 01:00:12:00
002 REEL1 V C 03:00:12:00 02:00:12:00 01:00:12:00 01:00:12:00
002 REEL2 V D 30 02:00:20:00 02:00:26:00 01:00:12:00 01:00:18:00
Here, event 001 is a cut, and the two lines of event 002 are a dissolve. Note that the first line of event 002 is a 'match-cut' to event 001. In EDLs, event 001 is called the "From" event, and the second line of event 002 is the "To" event.
This organization supports the fact that EDL events can be multi-channel (video plus audio) and that the "From" and "To" events may not follow each other in the list.
In contrast, Events in MaxOmfSdk (the mxOmfEventInfo_t data struct) represent either a cut or, in the case of transitions, the "To" event, as referred to in EDL-speak. The EDL's first-line "match-cut" data is not necessary because in MaxOmf the "From" event is *always* the previous event on the track. There are no "video plus audio" events in MaxOmf - all tracks are a single video or audio channel.
Transition Duration
|------|
TimeLine IN Timeline OUT
| --------------------- |
|\ |
| \ |
| \ |
| \ |
| \ |
| \ |
|------- Event ------|
|
Source IN
Each Event has an explicit timeline IN and OUT point and a single source IN point (mxOmfEventInfo_t::m_tcRIn, m_tcROut, and m_tcSIn).
(This is very much in contrast to Omf's scheme where the event position on a track is represented by the accumulated durations of events preceding it.)
If a transition is in effect, it *begins* at the event's IN point and its duration is given as a data field (mxOmfEventInfo_t::m_lTransDur).
The events are strung along a given Track in order from the project start:
Track->
|---------|---------|---------|---------|
| | |\ | |
| | | \ | |
|- Event -|- Event -|- Event -|- Event -|
"Holes" in the track (black or silence) are always represented with a "Fill" event. Thus, the entire track from program start to the end of the timeline is represented by an event, active or fill. The total duration of all events of all Tracks is the same - all Tracks are the same total length.
This "fill" mechanism is similar to Omf. However, MaxOmf events contain an explicit timeline IN and OUT position. This is very much in contrast to Omf's scheme where the event position is represented by the accumulated durations of events preceding it.
A 'fill' event is flagged with a BOOL m_bEventIsFill. If this flag is TRUE (the event is fill) the *only* valid data fields are m_tcRIn, m_tcROut, m_bEventIsTran, m_lTransDur, m_usWipePattern - there is never any valid Master, File, or Tape for a fill event.
Each Event gets its source from a group of objects called Master, File and Tape, which together form the source clip. This design is similar to Omf, but the details are different and the source clip data is not nested.
A Master (mxOmfMasterInfo_t) contains information about a source clip, such as its name and length, and represents the top of the group of source objects.
A File (mxOmfFileInfo_t) contains information about a media file, such as a media descriptor and path to the media file.
A Tape (mxOmfTapeInfo_t) contains information about a tape source, such the tape name and timecode.
|--------| |--------| |--------|
| | | | | |
| Master |->| File |->| Tape |
| | | | | |
|--------| |--------| |--------|
A Master holds these source clip components together. It may contain several Files, representing separate video and audio channels, and a single Tape :
|--------|
| File |
|--------| | -Video-| |--------|
| |->|--------| | |
| Master |------------->| Tape |
| |->|--------| | |
|--------| | File | |--------|
| -Audio-|
|--------|
A source clip, or Master with its siblings, may be referenced by any number of Events :
|--------|
| |
| Event |\
| | \
|--------| \
\
|--------| |--------| |--------| |--------|
| | | | | | | |
| Event |--| Master |->| File |->| Tape |
| | | | | | | |
|--------| |--------| |--------| |--------|
/
|--------| /
| | /
| Event |/
| |
|--------|
Internally, MaxOmfSdk stores objects in following manner :
* Project / Composition
List of Tracks
Track
List of Events
Event
Link to Master
Event
Link to Master
...
Track
List of Events
Event
Link to Master
Event
Link to Master
...
...
* List of Masters
Master
Link to Tape
List of Files
Link to File
Link to File
...
Master
Link to Tape
List of Files
File
File
...
...
* List of Files
File
File
...
* List of Tapes
Tape
Tape
...
Edit Data API explains accessing the internal data