Material Exchange Format

Text Preview:
Proposed SMPTE Engineering Guideline                                                       EG 42
   for Television 

   Material Exchange Format (MXF)
   MXF Descriptive Metadata
                                                                                         Page 1 of 27 pages

Table of contents

1 Scope

2 References

3 Glossary of Acronyms, Terms and Data Types

4 Introduction

5 Relating Descriptive Metadata to Essence

6 Issues relating to MXF and AAF

7 Metadata Coding

8 Guide To Implementing Descriptive Metadata Schemes in MXF

Annex A    (Informative) Descriptive Metadata Characteristics

Annex B    (Informative) Metadata Modelling

Annex C        (Informative) XML Schema Implementation

Annex D        (Informative) Bibliography

1 Scope
The MXF standard (SMPTE 377M) provides for descriptive metadata schemes as "plug-ins" to the MXF header
metadata. This EG is intended to provide guidance for the use of MXF descriptive metadata schemes. This
document is a supplement to SMPTE EG41.

This EG explains the common structural metadata components by which all MXF descriptive metadata schemes
can be related to the essence they describe. Additional constraints required for MXF descriptive metadata
schemes are also described.

595 W. Hartsdale Ave., White Plains, NY 10607
(914) 761-1100

This EG describes how MXF descriptive metadata is related to the essence using the structural metadata
defined in SMPTE 377M. It also describes how MXF descriptive metadata is coded as KLV data for use in MXF
files and as XML for text-based metadata exchange. This EG further provides guidelines for implementing MXF
descriptive metadata schemes.

Descriptive metadata is a complex topic and requires at least some basic understandings of the various
attributes of descriptive metadata together with data modelling techniques. This EG provides annexes that
summarize these topics.

2 References
The following documents contain provisions that, through reference in this text, constitute provisions of this
document. For dated references, subsequent amendments to, or revisions of, any of these publications do not
apply. However, parties to agreements based on this document are encouraged to investigate the possibility of
applying the most recent editions of the documents indicated below. For undated references, the latest edition of
the documents referred to applies.
    SMPTE EG41, MXF Engineering Guidelines.
    SMPTE 377M, MXF File Format Specification.
    SMPTE 336M, 2001: For Television  Data Encoding Protocol Using KLV.
    SMPTE 298M, 1997: For Television  Universal Labels for Unique Identification of Digital Data

3 Glossary of Acronyms, Terms and Data Types
The full glossary of acronyms, terms and data types used in the MXF specification is given in the MXF File
Format Specification. It is not repeated here to avoid any divergence of meaning.

3.1 Acronyms
   AAF:          Advanced Authoring Format (
   DM:           Descriptive Metadata
   DMS:          Descriptive Metadata Scheme
   HTML:         Hyper-Text Markup Language
   ISO:          International Standards Organisation
   IP:           Intellectual Property (as used in rights management)
   O-O:          Object Oriented
   TFHS:         Task Force for the Harmonisation of Standards (Bibliography)
   UML:          Unified Modelling Language
   XML:          eXtensible Markup Language (text-based data coding)

3.2 Terms
   Element:      An atomic constituent of a data model.
   Property:     A named value denoting the characteristics of an Element.
   Attribute:    A named property of a classifier that describes a range of values that instances of a property
                 may hold.
   Entity:       An entity is an abstract term that can mean a single data element, a set of data elements or a
                 higher construct.

3.3 Data Types

Page 2 of 27 pages
                                                                                                      SMPTE EG42

4 Introduction
This engineering guideline is intended to provide guidance for implementing descriptive metadata within the
header metadata of an MXF file (SMPTE 377M). This document supplements the MXF Engineering Guideline

This document is divided into a number of core sections, each section describing a particular aspect of
descriptive metadata. The sections (together with their section number) are as follows:
 1. Section 4 : This introduction, including the usage of descriptive metadata and a catalogue of user
    requirements for descriptive metadata.
 2. Section 5 : The mechanisms by which descriptive metadata in the MXF header metadata may be
    linked to the essence in the MXF essence container.
 3. Section 6 : A description of the issues related to implementing a descriptive metadata model from the
    perspective of both MXF and AAF.
 4. Section 7 : How to implement descriptive metadata as a sequence of KLV packets in the MXF header
    metadata and as XML for text-based interfacing.
 5. Section 8 : Guidance for implementing both MXF descriptive metadata and non-MXF descriptive
 6. Annex A: Provides a discussion of metadata characteristics.
 7. Annex B: Provides an introduction to data modelling techniques.
 8. Annex C: Provides an example of the options for XML coding
 9. Annex D: Bibliography of useful reading.
4.1 Dimensions of Descriptive Metadata Use
In general terms, the use of descriptive metadata has many dimensions as follows:
1.   It is in widespread use within different content-based industries, including broadcast, film, music and web
2.   It is in widespread use in different content-based applications, including capture/creation, production, post-
     production and archive/libraries.
3.   It can be divided into several different broad categories including business transactions, publication
     information, content identification and labeling, compositional information and formatting, etc.
4.   It may have different states such as being static for a defined duration, being dynamic (with several kinds
     of dynamic including transitory, metronomic, incrementing and so on).
5.   It may have different levels of stability with elements having durable values that remain stable or transient
     values that may frequently change.
In the header metadata of an MXF file, the metadata is persisted and may be distributed over many copies.
Thus descriptive metadata in an MXF file should include only that metadata which can be considered copy
persistent. This does not mean that a value can never change between copies, but that, once written, individual
copies must be edited where changes are required. For some types of metadata, this is not only acceptable, but
encouraged, e.g. a property that defines the number of copies made.

One of the primary aims of this document is to identify that metadata which can be used to enhance the
description of the content in a file. Metadata that is appropriate for use in databases is not part of this document.
Annex A describes metadata characteristics that may aid the reader to understand the attributes of different
kinds of metadata items.

                                                                                               Page 3 of 27 pages

4.2 User Requirements for Descriptive Metadata
Many major content production facilities have custom methods for handling the descriptive metadata associated
with the content. As audio-visual content exchange moves from tape-based to file-based operations, the
opportunity arises to be able to both embed descriptive metadata in the file and to provide an intimate
relationship between the metadata and the audio-visual content. This process allows metadata to be accrued
within a file as it passes between operations in a way that has rarely before been achieved. Many users see the
ability to embed metadata into an MXF file as a key requirement that extends the use of MXF beyond that
primarily for the simple exchange of audio-visual content. As a result of this desire, a list of user requirements for
descriptive metadata has been developed as below.

SMPTE EG41 (MXF Engineering Guidelines) gives a table of user requirements for file formats as developed by
the EBU. Although not all entries are valid for descriptive metadata, the following may apply:
Note: the following priorities were assigned:

A = Baseline ("Must"), B = Enhanced ("Can"), C = Extended ("May") U = Undecided or not determined, X = not allowed
(should not be allowed).

                         Table 1: User Requirements Table for Descriptive Metadata (tentative)

                                                                       Publication (Emission,

                                                                                                                            Finished Interchange
                                                                       Transmission, Store &

                                                                                                   Content Repository
                                                                           Forward, etc.)

  Priority                            User Requirement

   A List

    A++      Must be easy to understand & apply and standardized                Y                                       Y                          Y   Not
             Low implementation overhead                                        Y                E.g. Could be                                     Y     No
                                                                                                  complex if
                                                                                                editing required
     A       Must be open (as per ITU definition)                               Y                                       Y                          Y      Y
     A       Must provide Identification of the metadata scheme                 Y                                       Y                          Y      Y
     A       Must provide for normative templates                               Y                                       Y                          Y      Y
     A       Must be extensible in header and body (by KLV coding?)             Y                                       Y                          Y      Y
             (E.g. from one frame to many frames)

     A       Scalability (small file/single frame to large file)                Y                                       Y                          Y      Y
     A       Must provide synchronisation for multiple essence types            Y                                       Y                          Y      Y
             e.g. Audio/Video/Data Essence and certain Metadata

     A       Must be usable on major platforms/OSs                              Y                                       Y                          Y      Y
     A       Must be application independent                                    Y                                       Y                          Y      Y

Page 4 of 27 pages
                                                                                                                                                                    SMPTE EG42

                                                                                   Publication (Emission,

                                                                                                                                         Finished Interchange
                                                                                   Transmission, Store &

                                                                                                            Content Repository
                                                                                       Forward, etc.)

  Priority                           User Requirement

     A       Must be transport and storage mechanism independent                            Y                                     Y                             Y          Y
     A       Simple and complex template (backward-forward compatibility?)              Y                                         Y                  Y                    Y
                                                                                      simple                                     Both              simple              complex
     A       Extensibility to include non-predefined data (e.g. dark Metadata)    Undesirable               Undesirable                 Undesirable                        Y
   B List

     B       Link Metadata to structural composition information                            N                                     Y               Maybe                    Y
     B       Can accommodate a range of GoPs (e.g. MPEG)                                    Y                                     Y                             Y          Y
     B       Assignable granularity of Metadata (field, frame/clip/file)                    Y                                     Y                             Y          Y
   C List

     C       Extensible for internet. Metadata as binary and text format                    Y                                     Y                             Y          Y
     C       Allow externally referenced essence files for certain applications             N               Undesirable                                         N          Y
             such as Archiving. A proper standardisation/documentation is
             prerequisite if external references are used.

  X/U List

     X       Allow proprietary vendor created templates                                     ?                                     ?                             ?      Maybe

5 Relating Descriptive Metadata to Essence
The MXF format specification includes a standardised mechanism to link descriptive metadata to any individual
essence track, a defined group of essence tracks or all the essence tracks. Furthermore, this mechanism
defines the start and stop points along the essence track(s) where the descriptive metadata applies.

5.1 Provisions of the MXF Structural Metadata
The MXF structural header metadata describes the audio-visual content divided into individual essence tracks.
Thus each track has associated with it a descriptor of the essence, where each property of that descriptor is
static for that track duration. All the descriptors defined so far are file descriptors. In MXF, each track may be
divided into one or more segments, where each segment comprises a link to the appropriate segment of
essence in the MXF essence container. This applies whether or not the essence is embedded in the file body.
The same principles apply for descriptive metadata tracks.

MXF has extended the AAF object model to introduce descriptive metadata tracks that can be used to describe
the content of the essence container. Additional objects include a "DM Segment" that defines a descriptive
metadata track that can be used to describe the essence tracks and a "DM Source Clip" that can be used to link

                                                                                                                                        Page 5 of 27 pages
Download Link:
Share Link: Forum Link:

More on Computer & Internet

  • Picture: Name: Period GL UNIT 5: SIMILARITY

    Name: Period GL UNIT 5: SIMILARITY

    File Size: 648.11 KB, Pages: 15, Views: 502,142 views

    Name: Period GL U N IT 5 : S IM IL A R I T Y I can define, identify and illustrate the following terms: Similar Cross products Scale Factor SAS ~ Similar Polygons Similarity Ratio Indirect measurement Ratio Similarity Statement AA ~ Proportion Geometric …
  • Picture: Medical Office Communication -

    Medical Office Communication –

    File Size: 6,159.55 KB, Pages: 40, Views: 472,887 views

    Medical Office 26 Communication The daily functioning of a medical practice relies on good communication skills. As you have learned in previous chapters, effective communication involves excellent skills not only in speaking and listening but also in conveying nonverbal and written messages. Medical assistants …
  • Picture: State Income Tax Return Amendment Form provided by

    State Income Tax Return Amendment Form provided by

    File Size: 2,802.37 KB, Pages: 8, Views: 418,999 views

    State Income Tax Return Amendment Form provided by You can download this form to file a state income tax amendment. For details on how to file or efile the amendment please check the California tax return amendment page. You can also get your tax …


    File Size: 0.00 KB, Pages: 5, Views: 39,982 views

    OPEN CHANNEL HYDRAULICS AKAN SOLUTION MANUAL STARTUP HANDBOOK FEBRUARY 18, 2015 Open Channel Hydraulics Akan Solution Manual Startup Handbook OPEN CHANNEL HYDRAULICS AKAN SOLUTION MANUAL DOWNLOAD: OPEN CHANNEL HYDRAULICS AKAN SOLUTION MANUAL Getting Open Channel Hydraulics Akan Solution Manual is easy and simple. Mostly you …
  • Picture: Lab 9: Respiratory Physiology - College of Charleston

    Lab 9: Respiratory Physiology – College of Charleston

    File Size: 365.27 KB, Pages: 8, Views: 22,723 views

    Lab 8 Respiratory Physiology Laboratory 8 Respiratory Physiology The primary function of the respiratory system is to exchange oxygen and carbon dioxide between air and blood. This function sustains metabolism (via increasing blood oxygen and releasing blood carbon dioxide) and regulates blood pH. To completely …

Leave a Reply

Your email address will not be published. Required fields are marked *