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.


Copyright  2003 by THE SOCIETY OF              THIS PROPOSAL IS PUBLISHED FOR COMMENT ONLY
MOTION PICTURE AND TELEVISION ENGINEERS
595 W. Hartsdale Ave., White Plains, NY 10607
(914) 761-1100
SMPTE EG42


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 (www.aafassociation.org)
   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
   None.




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
(SMPTE EG41).

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
    metadata.
 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
     authoring.
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
SMPTE EG42


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.)




                                                                                                                                                       Interchange
                                                                                                                                                        Authoring
  Priority                            User Requirement




   A List

    A++      Must be easy to understand & apply and standardized                Y                                       Y                          Y   Not
                                                                                                                                                       easy
             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.)




                                                                                                                                                                        Interchange
                                                                                                                                                                         Authoring
  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: Haptic Communication between Humans and Robots

    Haptic Communication between Humans and Robots

    File Size: 752.03 KB, Pages: 12, Views: 252 views

    Haptic Communication between Humans and Robots Takahiro Miyashita1 , Taichi Tajika12 , Hiroshi Ishiguro12 , Kiyoshi Kogure1 , and Norihiro Hagita1 1 Intelligent Robotics and Communication Labs., ATR, Kyoto, JAPAN {miyasita,kogure,hagita}@atr.jp 2 Dept. of Adaptive Machine Systems, Osaka University, Osaka, JAPAN {Taichi.TAJIKA,ishiguro}@ams.eng.osaka-u.ac.jp Summary. This paper …
  • Picture: RETURN PREPARER FRAUD: The IRS Still Refuses to Issue

    RETURN PREPARER FRAUD: The IRS Still Refuses to Issue

    File Size: 336.64 KB, Pages: 9, Views: 501 views

    Most Serious Legislative Most Litigated Case Advocacy Appendices Problems Recommendations Issues MSP RETURN PREPARER FRAUD: The IRS Still Refuses to Issue #8 Refunds to Victims of Return Preparer Misconduct Despite Ample Guidance Allowing the Payment of Such Refunds RESPONSIBLE OFFICIAL John Koskinen, Commissioner of Internal …
  • Picture: 1 Spectrum Lab User's Manual - QSL.net

    1 Spectrum Lab User’s Manual – QSL.net

    File Size: 1,551.67 KB, Pages: 138, Views: 509 views

    1 Spectrum Lab User's Manual This ,,document" is just a collection of all HTML files from Spectrum Lab's built-in help system. They were simply combined in a master document in OpenOffice, by means of 'including' the html pages as sub-documents. Unfortunately, the links between these …
  • Picture: South-Western Federal Taxation Comprehensive Volume

    South-Western Federal Taxation Comprehensive Volume

    File Size: 524.04 KB, Pages: 16, Views: 447 views

    Study Guide South-Western Federal Taxation Comprehensive Volume 2009 EDITION Eugene Willis, Ph.D., CPA University of Illinois, Urbana-Champaign William H. Hoffman, Jr., J.D., Ph.D., CPA University of Houston David M. Maloney, Ph.D., CPA University of Virginia William A. Raabe, Ph.D., CPA The Ohio State University Prepared …
  • Picture: Peachtree by Sage: A True Business Management Solution for

    Peachtree by Sage: A True Business Management Solution for

    File Size: 0.00 KB, Pages: 11, Views: 171 views

    Peachtree by Sage: A True Business Management Solution for Serious Small Business Owners By K2 Enterprises Table of Contents Peachtree by Sage Overview . . . . . . . . . . . . . . . . . . . . . . …

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>