MS06 Specification
From AMWA
AMWA Specification
Model Specification MS-06: Integration of MXF with BXF
Executive Summary
Mapping and addition of MXF metadata to BXF (SMPTE S2021-2008) to provide compatibility between BXF messages and MXF files.
Contents |
Scope
Conformance Notation
Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.
All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as "Informative" or individual paragraphs that start with "Note:”
The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.
The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.
The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.
The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future.
A conformant implementation according to this document is one that includes all mandatory provisions ("shall") and, if implemented, all recommended provisions ("should") as described. A conformant implementation need not implement optional provisions ("may") and need not implement them as described.
Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; Tables shall be next; followed by formal languages; then figures; and then any other language forms.
Reference Documents
The following standards contain provisions which, through reference in this text, constitute provisions of this recommended practice. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this recommended practice are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below.
List of normative references.
- SMPTE 377M MXF
- XPath 2
- XML
- XML namespaces
- SMPTE 2021
- SMPTE 2001
- DMS-1?
- AAF object spec
Overview
Overview of the project.
BXF object model (informative)
An iformative description of a BXF object model based on BXF version 1 (SMPTE S2021-2008). This normative parts the specification specify compatibility betweem MXF and BXF messages with reference to XML schemas. The section is provided as a basis for the associated reference implementation and to provide a common platform for discussion of the AAF/MXF technical specifications and BXF.
Annex A provides a set of AMWA-registered universal labels for BXF classes, properties, types and extendible enumeration values. The intention is to ask the SMPTE BXF group if this model would be of use to them in their future standardization activities. If so, this section will be kept in step with any such activities and may become a reference to the normative section of a SMPTE published specification in the future.
UML notation
Brief overview of the UML notation used in this model description.
BXF messages
BXF types
Video, audio and data elements
Content metadata
Content messages
Content transfer messages
Format messages
Event schedule messages
As run schedue messages
Mapping MXF data into BXF messages
Generic mapping of MXF data into BXF messages
For any MXF file with contents that is referenced by a BXF message, fragments of data from the preface section of the MXF may be copied into that BXF message. Any such fragment shall be encoded according to SMPTE S2001 Registered Data XML and shall appear as a child element of a BXF PrivateInformation element.
A BXF message should not contain fragments of XML data from an MXF file that it does not make any form of reference to.
Note: Specific rules about where data fragments should appear are defined for specific kinds of messages.
The namespace of all registered data XML elements shall be clearly identified and distinguished from BXF elements by using the "xmlns" attribute defined for XML namespaces.
The BXF namespace used shall be X. All BXF elements and attributes defined in the BXF namespace should be preceded in XML documents by the prefix "bxf:". (PMCP and RP extension namespace here too?)
All registered data XML elements and attributes defined by the AAF object model v1.1, including MXF preface metadata, shall have namespace X. All such XML elements and attributes should be preceded in XML documents by the prefix "aaf:".
Identifying fragments with XPath
Mapping BXF data into MXF messages
Use of BXF fragments as a MXF descriptive metadata scheme
BXF defined elements may be used as annotations on descripitive metadata tracks in an MXF file. The RegXML class is defined for namespace (define a MXFBXF mapping namespace) and shall extend AAF class DescriptiveFramework. The RegXML class shall have an attribute that contains elements that are instances of BXF-defined classes.
When an MXF file is encoded according to S2001 registered data XML,
Identifying fragments with XPath
Data mappings
Essence kind
Carrying various parts of the EssenceDescriptor of the MXF file in a BXF message.
Track strucutre
Carrying the track structure of the MXF file in a BXF message.
Content identification
A common approach to content identification between BXF and MXF messages.
Descriptive metadata
AS-03 slate metadata and reference to shims.
Program segmentation
Type 1: Single MXF file
Note: Mapping of composition mob segmentation to approach adopted by this project.
Type 2: MXF file per segment
Specification of a transcode operation
Using BXF content transfer messages to request a transcode operation.
Message protocol (informative)
Description of one possible way to carry these messages between systems, to inherit from previous IS02 work.
Carrying BXF messages in SOAP messages
An IS-02 approach to SOAP messages.
Message sequence
Sequence diagram defining message protocol.
Message reliability
A minimum expected reliability level.
