MXF工程指南：电视材料交换格式详解

需积分: 10 86 浏览量更新于2024-07-20 1 收藏 496KB PDF 举报

"SMPTE EG41 - MXF工程指南" SMPTE EG41是电影与电视工程师学会（Society of Motion Picture and Television Engineers）发布的一个工程指南，专门针对电视行业的材料交换格式（Material Exchange Format，简称MXF）。这份指南的目的是提供MXF格式的介绍、背景知识和技术细节，以便于在实际应用中使用该格式进行文件交换。 1. 范围该工程指南涵盖了MXF格式的主要方面，包括它的设计目标、文件结构以及如何在不同工作流程中使用它。这份文档不仅适用于MXF，也适用于一般性的文件格式理解。 2. MXF文档结构 MXF文件是一种容器格式，它将媒体数据（如音频和视频）与元数据封装在一起，形成了一个可互操作的文件。文件结构包含多个组件，如KLV（键-长度-值）编码的数据包，这些数据包可以包含音视频片段、时间码等信息。 3. 文件交换需求 MXF旨在解决不同制作和后期制作系统之间的兼容性问题，使得内容在不同设备和软件之间无缝传输。它支持多种编解码器和帧率，适应广泛的行业标准。 4. MXF标准表述指南标准中的术语和定义是明确且一致的，以确保所有开发者和使用者都能准确理解和实现MXF规范。 5. 元数据分类与放置元数据在MXF文件中扮演着关键角色，它们被分类并嵌入到文件的不同部分，比如头信息、索引和数据包中，以提供关于媒体内容的详细信息，如时间码、剪辑信息、色彩空间等。 6. MXF详解详细介绍了MXF格式的各个组成部分，如Essence元素、Header Metadata、Index Table等，以及它们如何协同工作以实现高效的文件交换。 7. MXF工作示例通过实例展示了如何创建、读取和修改MXF文件，帮助用户理解实际操作中的MXF应用。 8. 附录附录B提供了推荐的枚举字符串值，而附录C则列出了相关的参考文献，为深入学习MXF提供了资料。 SMPTE EG41是一个全面的指南，对理解MXF格式的内部工作原理及其在电视和电影行业中的应用至关重要。它不仅适合技术开发者，也对制作人、编辑和其他与媒体处理相关的专业人士非常有用。通过这份指南，读者能够更好地掌握MXF格式的使用，从而提升工作效率并减少在媒体内容交换过程中的兼容性问题。

SMPTE EG41

Page 13 of 74 pages

An Essence Container specification defines a unique SMPTE Label for identification as well as a method for

encapsulating the essence in a KLV structure. Different Essence Containers may place restrictions on the

interleaving of the essence data to be compatible with existing applications. The SMPTE Label allows decoders

to make a fast go/no-go check of the essence type at the very beginning of the file.

An MXF file may have more than one Essence Container. The precise number of Essence Containers and their

relationships is constrained by the Operational Pattern with which the file complies.

A “Generic Container” is defined within MXF. This is intended to carry all the mainstream Essence types in

existence at the time of creating SMPTE 377M. It is very simple in operation, yet flexible enough to carry

uncompressed material as well as re-ordered MPEG compressed material. Associated with the Generic

Container are a number of mapping documents that define how the actual Essence byte stream should be

placed in the Essence Container.

3.5.9 How have we specified the Essence Container?

There are several specific questions that need to be asked when putting an Essence Container into an MXF file.

These are notably:

1. What limitations are placed on the Essence Container when it is in an MXF file?

2. Are there interleaved variants of the Essence Container?

3. How do we KLV code the contents of the Essence Container?

4. How do we pad the Essence Containers to fit the chosen KAG size?

5. What do we do with the metadata embedded within the Essence Container?

6. How do we use Index Tables with the Essence Container?

The Essence Container and mapping specifications are basically recommended answers to these questions. It

is the intention of the Essence Container and mapping documents to restrict the choices of an Essence

Container implementation sufficiently to allow interoperability between devices, yet with enough flexibility to

solve real world problems.

3.6 How does MXF interoperate with Stream Interfaces?

MXF files may be directly created from standardized formats such as MPEG2 system and elementary streams,

AES3 data streams and DV DIF packet streams. These formats may be mapped from one of several real-time

interfaces such as SMPTE 259M (SDI), SMPTE 305M (SDTI), SMPTE 292M (HD-SDI), or transport interfaces

with real-time protocols such as IEEE-1394, ATM, IEEE802 (ethernet), ANSI Fibre Channel and so on.

When a streaming file is captured, a File Header is created and the essence is KLV wrapped on the fly. The

data rate increases due to the KLV wrapping and addition of headers. Real Time streaming devices must ensure

that any buffering requirements of a streaming interface are catered for with this change of data rate.

Conversion to and from the source format is always possible, but sometimes there will be loss of information.

Not all streaming and storage formats are able to store the rich metadata constructs available in an MXF file.

Often there will be a lossy data mapping where information in one format cannot be represented in the other.

Eliminating this undesired loss is a function of the systems engineering that interconnects MXF and non-MXF

systems. In many formats such as the MPEG2 Transport Stream, research is being done to find ways in which

MXF headers can be “tunneled” through the Transport Stream so that its use in an MXF system provides

transparency as well as interoperability.

3.7 How does MXF interoperate with other files?

As previously stated, MXF files apply a subset of the AAF class model. The Material Exchange Format provides

a data structure together with a set of constraints and plug-ins to create files that can be directly written and read

by AAF systems. MXF is also able to inter-operate with other existing file formats by utilizing techniques such as

external essence and using the run-in to “camouflage” the appearance of the file (see the end of 3.2.1 above).

Different metadata models can be plugged into the MXF file Format to provide extensions and the KLV structure

itself can be converted to formats such as XML for exporting MXF data to other systems.

SMPTE EG41

Page 14 of 74 pages

When an application needs to convert the contents of an MXF File to and from other formats, such as AVI, the

entire file will normally need to be unwrapped and re-coded in the new format. Often the Essence itself (for

example, MPEG Long GOP video) will not need re-MPEG encoding, however it is very likely that Metadata will

be lost when an MXF file is converted to another format.

3.8 What is meant by simplicity?

MXF files must be amenable to implementation in high throughput hardware or software devices. This translates

into the need for well-defined design parameters for buffer size, latency, and the need for algorithmic simplicity.

MXF is also intended to cover a very large application space, and not all the requirements apply to all the

applications. The examples below are all application specific:

Example constraints:

• Buffer size must be minimized for low latency streamability.

• KLV wrapping and file partitioning latency must be small and bounded.

• Algorithms should not require distant look-ahead to calculate parameter values.

• Algorithms should not require deep stacks or high performance coprocessors, and should preferably be

straight-line (no looping).

• Operational Patterns should create controlled and bounded application environments that are

constrained enough to ensure interoperability, yet broad enough to allow many implementations.

The design can also be kept simple through the proper use of layering. Network, transport and session layer

functions and data units must be kept separate at all costs, so as not to burden any layer with processing that

belongs to another layer.

3.9 Why does MXF need to work with stream interfaces?

MXF files will often be processed in streaming environments. This will include streaming to and from videotape

and data tape, and transmission over unidirectional links or links with a narrow-band return-channel.

In these environments it is impractical to rewind the stream to update parameter values so files must be written

sequentially. This implies that the minimum buffer size and latency are determined by (among other things) the

maximum KLV packet size. Implementations of MXF streaming should take into account all the constraints of

the Operational Pattern in use, as well as extra restrictions imposed by the particular streaming data link before

recommending buffer sizes or latency requirements.

Sequential writing is necessary when source or link or destination operate only in streaming mode. Random

access writing is permissible before or after data transfer, for example, to optimize downstream access

performance.

Operational Patterns have a special qualifier bits that indicates that the file has been created for streaming.

3.10 How does MXF provide for stream recovery?

Streaming environments also impose requirements for recovery and re-synchronization in several different

circumstances:

1. When a packet or other data block is lost.

2. When a decoder joins a transfer that is already in progress.

3. When a transfer or partial transfer is restarted.

4. When it is necessary to access or retransmit a file that is still being received (“Pre-Play”).

5. When overall metadata is modified during the time of transfer.

The first of these (packet loss) usually requires a return-channel or forward error correction for effective

protection. The other circumstances are addressed by judicious design of the Format to allow for re-

synchronization points and for repetition of important metadata.

SMPTE EG41

Page 15 of 74 pages

3.11 How does MXF provide for application diversity?

Different applications may require Metadata to be processed separately from the Essence. Other applications

(such as archive) may require Metadata to be stored with the Essence. This requires efficient insertion and

extraction of the Metadata from the Essence Container(s) of the file.

Some applications may prefer Index Tables to be accessed separately from the Essence; others may require

the two to be accessed together. In some cases, the Index Tables are most naturally stored at the start of the

file; however, while recording, the most natural location is at the end of the file. This diversity requires efficient

insertion, extraction and relocation of Index Tables within the file.

3.12 How does MXF make references to its different components?

MXF uses different referencing mechanisms for different purposes. One example that causes confusion is the

difference between references to the Top-Level “File Package” and “The Essence”. The MXF Content Storage

Set uses Instance UIDs to reference all the Packages in an MXF File. One of these will match the Instance UID

of a File Package within the File. This is a strong reference to the package. The package itself is a description of

the Essence, but is not the Essence itself.

The Content Storage Set also uses Instance UIDs to keep a list of Essence Container Sets. These are used to

group the various IDs that enable an MXF Decoder to work out which Partitions and Index Tables relate to which

Top-Level File Package. Specific details are given in section 7.5.

This seems straightforward until we look at how a Material Package SourceClip references the Essence. This

structure does not use the Instance UID values, it uses the 32 byte UMID of the essence as a reference. This is

because the Material Package is referencing the Essence of which the Top-Level File Package is a description.

4 File Interchange Requirements

There are two basic types of File Interchange requirement: User requirements and Technical requirements. The

User requirements are lists of things that users want to be able to do with files. The technical requirements are

features of the file that allow applications to be accommodated.

4.1 User Requirements for an Interchange File

The MXF Format, at its lowest level, should support functionality that is commonly available in today’s video file-

servers. The MXF / AAF Joint File Interchange Working Group, in co-operation with the EBU P/PITV group and

the SMPTE have summarized the user requirements for MXF as follows:

Table 1 : User Requirements table

User Requirements

General

Priority LIST

PROFESSIONAL APPLICATIONS

That are assigned the following priorities:

A = Baseline ("Must"),

B = Enhanced ("Can"),

C = Extended ("May”),

U = Undecided or not determined,

X = not allowed (should not be allowed)

Publication (Emission,

Transmission, Store &

Forward, etc.)

Content Repository

Finished Interchange

Authoring Interchange

剩余73页未读，继续阅读

back963

粉丝: 1
资源: 8

MXF工程指南：电视材料交换格式详解

SMPTE-EG41

SMPTE EG 16：2014 Measurement Methods for Film and Digital Motion

SMPTE标准

smpte 2110协议下载

smpte 421m csdn

smpte st-2082频率

smpte 424m标准

smpte-12m-1

smpte st2082-12

vivado smpte_sdi

最新资源