MXF in the AAF SDK

1
MXF in theAAF SDK

• Dudley Beenham, Peter Schmidt,Gareth
  Sylvester-Bradley

2
Introduction

• The AAF SDK core currently supports the AAF
  structural metadata saved as MS Structured
  Storage only
• MXF descriptive metadata and (KLV) storage is
  being added as a project at SONY BP Labs
• Status of this project as of November 2001 AAF
  DevCon (Barcelona)

3
Topics of Discussion

• AAF and MXF Standards
• Standards fit
• Implementation
• Overall strategy
• Issues and proposed solutions
• Goals

4
Standards

• The baseline version of the AAF SDK for the MXF
  implementation work is currently that from
  SourceForge as on 24 September 2001 but well
  track changes!
• The MXF implementation will track the standard
  were currently working with version 8 (SMPTE
  ballot) documents

5
Standards Fit

• The MXF and AAF dictionaries are similar enough
  that the differences between them can be
  accommodated by the AAF plug-in mechanism with
  a few exceptions
• These exceptions are non-trivial!

6
Implementation Overall Strategy (1)

• Applications will access MXF descriptive metadata
  through COM interfaces provided by an AAF
  metadata extension plug-in
• Descriptive metadata can then be saved in AAF MSS
  files!
• A new kind of plug-in is needed for the Object
  Manager to handle MXF tailored KLV storage and
  most of the exceptional cases where the AAF and
  MXF structural metadata models differ

7
Implementation Overall Strategy (2)
Client Apps
Client Apps
Client Apps
API Broker
Metadata Plug-in
Data Manager
Storage System
Object Manager Plug-in
Object Manager
8
Implementation Issues and Proposed Solutions

• Issues addressed here are
• Metadata extension plug-in requirements
• Issues driving an Object Manager plug-in
• Miscellaneous implementation policies
• Useful core SDK extensions
• Remaining problems
• Or skip the detail! Where next?

9
Issues Metadata Extension Plug-in Requirements
(1)

• An abstract extension class implied by the MXF
  specification (which lists only concrete classes)
• Make up a new UL for the class
• How to prevent the class from being instantiated?

10
Issues Metadata Extension Plug-in Requirements
(2)

• A concrete extension class logically derived from
  an abstract extension base class 3 issues
• Maintenance of binary compatibility
• Currently carry only the new functionality in the
  extended interface
• Implementation of derived-ness (COM)
• Currently hold a pointer to the base class
• Implementation of derived-ness (dictionary)
• Small bug fix checked into SourceForge

11
Issues Metadata Extension Plug-in Requirements
(3)

• Define a new property on an existing core SDK
  class
• An extended Register() interface that accepts
  pre-defined PIDs
• Current solution
• Property is only available through
  IAAFObjectGetProperties()
• Maintains binary compatibility

12
Issues Metadata Extension Plug-in Requirements
(4)

• MXF-only InstanceID property required in order to
  store many core AAF classes in MXF KLV
• Use Register() interface makes InstanceID
  visible to all AAF applications
• Modify core SDK to support InstanceIDs as
  optional properties same visibility problem
• Handle entirely at the KLV storage layer current
  solution, implemented in OM plug-in

13
Issues OM Plug-in (1)

• Differences between AAF and MXF data models
• Represent the AAF root object and dictionaries
  using KLV mock objects
• Missing mandatory properties like stored byte
  order (on the header) must be reported too
• Could byte order be made optional in AAF?
• Generation of InstanceIDs, Fillers, Partitions,
  header repeats etc. when saving an MXF file
• OM traits interface a long term solution?

14
Issues OM Plug-in (2)

• Local sets are specified by 0x53 in byte 6 of an
  MXF UL. AAF uses 0x06 (to indicate MSS?)
• Currently substitute to and from the AAF values
  in the OM plug-in
• Differences in the AAF SDK handling of UUIDs,
  AUIDs and ULs (to be investigated I now
  understand the rationale!)
• Currently mangle the byte order of all these data
  types in the OM plug-in to conform

15
Issues OM Plug-in (3)

• References to essence streams are handled
  differently by AAF (MS Structured Storage) and
  MXF (KLV)
• Handle in the OM plug-in (to be investigated)
• Even more OM Detail

16
Issues Miscellaneous Implementation Policies (1)

• Descriptive metadata will be handled in AAF by a
  new Segment class derived from SourceClip (or
  Event?)
• This Descriptive Metadata Segment contains a DM
  Collection property on which all descriptive
  metadata hangs
• DMSegment can be used in any Mob (Package)

17
Issues Miscellaneous Implementation Policies (2)

• No requirement to cater for multiple byte orders
  within MXF KLV storage always stored big-endian
  (pass through of dark metadata is impossible if
  you were to switch endian-ism)
• Should AAF KLV storage provide support for
  multiple byte orders? Consensus seems to be NO!

18
Issues Miscellaneous Implementation Policies (3)

• Example AAF plug-ins seem to be written in a very
  different style to that of the core SDK
  investigate each of the following
• A plug-in equivalent to AAFMetaDictionary.h
• Similar (extended?) use of DODO for plug-ins
• A more automated (less error-prone) approach to
  dictionary registration than currently used by
  IAAFClassExtensionRegisterDefinitions()

19
Issues Useful Core SDK Extensions

• MXF has several ISO 7-bit string properties
• E.g.
• Put the type definition into the metadata plug-in
  to be investigated
• Or add it to the core SDK
• Or transparently convert to/from UTF-16 in the OM
  plug-in (current solution)
• Favoured by app. developers?

20
Issues Remaining Problems (1)

• AAF data model assumes mandatory dictionary is
  present in file (dark to MXF)
• Change AAF spec to make it optional?
• Special case handling in core SDK or OM plug-in?
• (Optional?) suppression when saving (as) MXF files

21
Issues Remaining Problems (2)

• Current band-aid code in ImplAAFFile to allow MXF
  dictionary processing during file reading
• Breaks SDK layer separation
• Registration of default property definitions is
  allowed until after dictionary restoration
• The EssenceDescription property of SourceMob (MXF
  FilePackage) is a single descriptor in AAF, but a
  vector (one per track) in MXF
• Will be fixed by AAF v2.0?

22
Issues Remaining Problems (3)

• Accessing essence in MXF files through the AAF
  SDK
• Extraction to a temporary file and use of an
  external, non-AAF, codec is good first step for
  many AAF applications
• Existing code for reading essence from MXF files
  can be integrated into OM plug-in
• MXF versions of the 2 Gb / 32-bit limits?

23
Goals

• Read a subset of the Geneva Scheme descriptive
  metadata hierarchy with the AAF SDK from both MXF
  and AAF files
• Write MXF files from the AAF SDK that contain the
  same subset (harder)
• Read/write MXF essence... (different!)
• Complete the full Geneva Scheme, fully document
  and integrate the plug-ins and AAF SDK changes
  into SourceForge (for AAF v2.0?)

24
Registering Properties withPre-defined PIDs

• A mechanism to register MXF plug-in properties
  identified by pre-defined PIDs
• T. Binghams recommended DODO method used to
  extend AAFClassDef
• Further work to ensure the AAF PID allocation
  mechanism for plug-ins avoids these pre-defined
  PIDs
• Not necessarily complicated!

25
MXF Use of ISO 7-bit Strings

• ISO 7-bit
• Language codes for text, spoken, subtitle,
  currency,
• URLs
• Enumerations (ident kind, clip kind, )
• Numbers (telephone, contract, clip, episode, )
• Real strings are UTF-16

26
Even More OM Detail

• Pre-condition needed weakening in
  OMStrongReferencePropertygetValue()
• OMStoredForm isnt used in the MXF KLV storage
  process (yet?)
• Currently use an additional identifier SF_UNKNOWN

27
AAF class hierarchy proposal to attach Geneva
Scheme metadata