Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4539

Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF)

Pages: 6
Informational

Top   ToC   RFC4539 - Page 1
Network Working Group                                         T. Edwards
Request for Comments: 4539                                           PBS
Category: Informational                                         May 2006


                    Media Type Registration for the
      Society of Motion Picture and Television Engineers (SMPTE)
                     Material Exchange Format (MXF)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

This document serves to register a media type for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF). MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata.

Table of Contents

1. Introduction ....................................................2 2. Security Considerations .........................................3 3. IANA Considerations .............................................3 3.1. Media Type for SMPTE Material Exchange Format (MXF) ........3 4. References ......................................................5 4.1. Normative References .......................................5 4.2. Informative References .....................................5
Top   ToC   RFC4539 - Page 2

1. Introduction

The present document registers a media type for SMPTE Material Exchange Format (MXF). MXF, defined by SMPTE 377M [SMPTE377M], is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata. Essence is the raw video, audio, and data streams contained and described by MXF. Metadata carried by MXF includes structural metadata and descriptive metadata. Structural metadata relates to the structure and capabilities of the MXF file and is generally required for proper decoding. Some examples of structural metadata are descriptions of essence types, information to help synchronize playout of audio and video, and content length. Descriptive metadata gives information about the program content in the file and is not essential for decoding. Some examples of descriptive metadata are program title, actors, and scene descriptions. The essence in MXF files may itself carry data, such as vertical blanking interval data used for carriage of Closed Captioning and other purposes. MXF is an important tool in providing interoperation between different video systems as well as digital cinema systems. MXF also aids in the development of video production and distribution workflows that are more efficient, multi-vendor, file based, and IT oriented. SMPTE currently has standards for the mapping of the following essence types to the MXF generic container: MPEG (including MPEG-1 and MPEG-2 video streams, as well as MPEG audio), DV-DIF (Digital Video Digital Interface Format for the DV family of related video encodings), Uncompressed Pictures, SDTI-CP (Serial Digital Transport Interface Content Package for delivering packetized audiovisual content over the SDI interface), D-10 (a specialized video stream incorporating MPEG-2 4:2:2P@ML), D-11 (a high-definition video compression standard), AES3 audio, Broadcast Wave audio, and A-Law audio. The flexibility of the MXF generic container allows for the possibility of mappings of additional essence types in the future. The media type defined here is needed to correctly identify MXF files when they are served over HTTP or other network connections, included in multi-part documents, indexed by operating systems and digital asset management systems, or used in other places where media types are used.
Top   ToC   RFC4539 - Page 3

2. Security Considerations

Security requirements for the application/mxf media type are discussed in the IANA media type registration (Section 3.1).

3. IANA Considerations

The IANA has registered the media type application/mxf as specified in Section 3.1. The registration uses the template present in [RFC4288].

3.1. Media Type for SMPTE Material Exchange Format (MXF)

To: ietf-types@iana.org Subject: Registration of media type application/mxf Type name: application Subtype name: mxf Required parameters: none Optional parameters: ULs The optional parameter ULs is a single Uniform Resource Name (URN), or a comma-separated list of multiple URNs of SMPTE Universal Labels (which are defined by SMPTE 400M [SMPTE400M]). This optional parameter provides hints to the decoder regarding the structure of the MXF file, which could include Operational Pattern, essence types, descriptive metadata schemes, and other elements that are identified by their SMPTE Universal Label. SMPTE Universal Labels are Object Identifiers (OIDs), as specified by [ASN1]. Thus, a URN of a SMPTE Universal Label can use the OID URN namespace specified in [RFC3061], or any other future URN namespace that is appropriate for SMPTE Universal Labels. Note that, per [RFC2045], some characters (including the comma used to separate multiple values) require that the entire parameter value be enclosed in quotes. Below is an example of use of the optional parameter. The two SMPTE Universal Labels indicate that the MXF file uses the OP1a Operational Pattern and contains IEC DV video at 25 Mbps, 525 lines, 59.94 fps interlaced essence.
Top   ToC   RFC4539 - Page 4
      Content-Type:  application/mxf;
         ULs="urn:oid:1.3.52.4.1.1.1.13.1.2.1.1.1,
         urn:oid:1.3.52.4.1.1.1.4.1.2.2.2.1.1"

   Encoding considerations: binary

   Security considerations: Application/mxf objects are not signed but
   may be partially encrypted internally.  External security mechanisms
   must be employed to ensure content confidentiality.  MXF, through
   metadata extensions, may allow executable code to be transferred in
   the file.  It is suggested that no unauthenticated executables
   decoded from an MXF file be executed.  Some compressed essence types
   carried in MXF may carry a risk that certain pathological bitstreams
   could lead to potential denial-of-service attacks against these
   essence decoders.

   Interoperability considerations: MXF provides a standard wrapping for
   a number of audio and video essence types according to a number of
   different Operational Patterns (OP).  Thus, interoperability depends
   upon whether the MXF file decoder has the capability to match the
   features of the MXF file encoder.  An Application Specification (AS)
   can ensure that MXF encoders and decoders can interoperate
   effectively.

   Published specification: RFC 4539, SMPTE 377M [SMPTE377M]

   Applications that use this media type: MXF is a wrapper for many
   types of audio and video essence types in use by many applications in
   the broadcast and digital cinema industries.  These include
   non-linear editing systems, video servers, video camera systems,
   digital asset management systems, and digital video distribution
   systems.

   Additional information:

      Magic number(s): none

      File extension(s): .mxf

      Macintosh File Type Code(s): "mxf "

   Person & email address to contact for further information:
   Thomas Edwards
   email: tedwards@pbs.org

   Intended usage: COMMON

   Restrictions on usage: none
Top   ToC   RFC4539 - Page 5
   Author/Change controller:

   Thomas Edwards
   email: tedwards@pbs.org

4. References

4.1. Normative References

[SMPTE377M] Society of Motion Picture and Television Engineers, "Material Exchange Format (MXF) File Format Specification", SMPTE 377M-2004, <http://www.smpte.org>. [SMPTE400M] Society of Motion Picture and Television Engineers, "SMPTE Labels Structure", SMPTE 400M-2004, <http://www.smpte.org>.

4.2. Informative References

[ASN1] International Telephone and Telegraph Consultative Committee, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.209, January 1988. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

Author's Address

Thomas G. Edwards PBS 6453 Stephenson Way Alexandria, VA 22312 US Phone: +1 703 739 5000 EMail: tedwards@pbs.org URI: http://www.pbs.org
Top   ToC   RFC4539 - Page 6
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).