MXF文件格式规范：SMPTE_377m-2004详解

5星 · 超过95%的资源需积分: 16 34 浏览量更新于2024-07-31 1 收藏 842KB PDF 举报

"SMPTE_377m-2004是关于MXF（Material eXchange Format）文件格式的规范文档，由SMPTE（电影与电视工程师学会）在2004年发布。该标准详细定义了音频和视频素材交换的数据结构，适用于网络传输和存储媒体上的应用。它不涉及MXF兼容设备的内部存储格式，但全面涵盖了MXF文件规范的各个组件，包括文件头、文件主体和文件尾。标准中还特别提到了分区的运用，这使得MXF文件能够满足多种应用需求，并具备部分接收文件的恢复能力。" SMPTE 377M-2004标准的内容分为多个部分： 1. **范围**：这个标准明确了MXF格式的主要目标，即提供音频和视频素材的交换数据结构，用于网络传输和存储，同时也定义了文件的结构和组件。 2. **规范性参考**：列出与其他标准或文档的关联，确保MXF的实现符合行业标准。 3. **缩写词、术语和数据类型**：定义了在标准中使用的专业词汇和数据类型，以便于理解和实现。 4. **介绍**：概述MXF的基本概念和重要性，以及其在不同应用中的作用。 5. **整体规范**：描述MXF文件的整体结构和规定，包括文件的组成要素。 6. **分区**：详细说明MXF文件如何通过分区来实现灵活的结构，以适应不同的应用场景和错误恢复。 7. **操作模式**：定义了MXF文件中允许的不同操作模式，这些模式决定了如何处理和解释数据。 8. **头部元数据**：这部分详细阐述了文件头包含的信息，如文件元数据、时间码和其他与内容相关的描述。 9. **文件主体**：文件主体包含实际的音视频数据，可能按照特定的编码和封装格式。 10. **索引表**：索引表用于快速定位文件中的特定数据，提高访问效率。 11. **随机索引包**：提供一种方法，以便于在不按顺序读取文件的情况下，也能高效地访问MXF中的内容。 12. **附录A到E**：提供了关于根元数据集、通用包、MXF中使用的包、基于文件的描述符以及图片实质描述符项目的具体规范。 13. **参考文献**：列出了编写标准时参考的相关文献和技术资料，为深入研究提供路径。 SMPTE 377M-2004标准对于理解并实现MXF文件格式至关重要，它不仅定义了文件的物理结构，还包括了元数据的组织和操作模式的规范，是音视频行业进行素材交换的重要基础。

SMPTE 377M-2004

Page 16 of 101 pages

5.3.6 Variable-length pack lengths

The key of a variable-length pack shall comply with the values defined in SMPTE 336M. By default, most

variable-length packs are coded with a 2-byte length field, but decoders shall not assume that this is the only

case.

NOTE – The length field of items in variable-length packs is always coded as a big-endian (MSB first), non-BER value.

5.3.7 MXF keys and Universal labels

SMPTE keys and Universal labels (ULs) may be any length in steps of 4 bytes; the length being defined in the

second byte of the key or UL according to SMPTE 298M. MXF files shall have keys and ULs that are 16 bytes

long and no other lengths are permitted.

5.3.8 KLV recursive grouping (as defined in SMPTE 336M)

SMPTE 336M places no limits on the depth of recursive grouping allowed in KLV coded data sets (i.e., sets

contained within sets) to provide a hierarchical structure. However, MXF files shall only contain sets or packs

with individual data items unless otherwise specifically defined in a descriptive metadata or essence container

specification. Note that the use of recursive group structures could prevent backwards compatibility with

existing implementations and is therefore prohibited in MXF defined sets. Dark metadata is not constrained.

Parts of an MXF file (with particular reference to the header metadata) may contain a logical grouping of sets

or packs that defines a hierarchical structure. The method of coding this structure in the MXF file format

specification is to provide each data set with an instance UID metadata item that provides each set in the

structure with a unique identification. This allows any set to be referenced from any other set. It provides the

same logical effect as recursive grouping, and results in all sets being coded in a single layer as a contiguous

sequence of sets.

Section 8.3 describing the header metadata provides more details of coding logical data structures.

5.3.9 Primer Pack – KLV local sets, dark metadata and MXF extensions

MXF local sets in the header metadata use 2-byte local tags as a shorthand for the 16-byte Universal label

which fully identifies any item within a set. In MXF these local tags are defined as having the scope of the

partition in which they occur. This means that all local tags are unique within a partition. To ensure the

uniqueness of these tags, a primer pack is provided which defines the mapping between the local tags and

their 16-byte Universal label equivalents.

Implementers who insert metadata extensions in MXF defined sets shall use the primer mechanism for

generating local tags. This will ensure that no two extended metadata items in a set will use a common local

tag for different data Items. Metadata extension schemes may be added using other mechanisms such as

Universal sets, Universal items, local sets with different sized tags and lengths.

Full details of the primer pack are given in section 8.2.

5.4 MXF Encoding Requirements

The contents of an MXF file may be viewed as a multiplex of data items or objects:

Run-in — only used in specialized operational patterns.

Partition metadata — the metadata used to describe the structure of each partition in the file and defines the

header partition, any body partitions and the footer partition.

Header metadata — metadata describing the file body, its essence, its structure and possibly its meaning.

Index tables — to convert from a position in a track to a byte offset within the essence container.

Essence containers (when present) — the essence data of the file body.

SMPTE 377M-2004

Page 17 of 101 pages

Random index pack — used to rapidly locate the partitions in the file.

All MXF data types shall be KLV coded (with the sole exception of the optional run-in).

The ordering of the various components of a partition and the use of the fill item between these components

shall follow the rules given below.

Partition

Pack

Header

Metadata

Index

Table

Essence

Container

Next Partition

Pack

Partition with optional Fill included

Fill

HeaderByteCount

bytes used for

Header Metadata

IndexByteCount

bytes used for

Index Table

Partition

Pack

Index

Table

Essence

Container

Next Partition

Pack

Partition with optional Fill included

Fill

IndexByteCount

bytes used for

Index Table

Partition

Pack

Essence

Container

Next Partition

Pack

Partition with optional Fill included

Fill

HeaderByteCount=0

IndexSID=N

HeaderByteCount=0

IndexSID=0

HeaderByteCount = 0

IndexSID=N

Figure 6 – Ordering in a partition and the use of fill

Each partition shall comprise the following items (in the order defined):

1. A partition pack optionally followed by one KLV fill item to ensure grid alignment when required or to

provide padding.

2. Optional header metadata. If present, it may be followed by one KLV fill item to ensure grid alignment

when required or to provide padding.

3. Zero or more index table segments. If present, each may be followed by one KLV fill item to ensure grid

alignment when required or to provide padding.

4. Zero or more bytes of essence container data. If present, KLV fill items may be added to provide grid

alignment when required or padding as required by the essence container.

5.4.1 KLV alignment grid (KAG)

In certain operations, it may be desirable to align certain KLV elements to specific byte boundaries. This can

be achieved with the insertion of KLV fill items to ensure the desired items are aligned. One example might be

a VBR picture stream with a peak rate of 1-Mbyte/picture. It might be desirable to align each picture on a

1-Mbyte boundary despite the increase in file size. KLV Fill items can be used to create an alignment grid for

this purpose.

SMPTE 377M-2004

Page 18 of 101 pages

Each partition may align certain KLV elements to a KLV alignment grid (KAG). The KLV alignment grid

defines the number of bytes between gridlines to which the first byte of the Key of certain KLV elements may

be aligned. The first gridline in any partition is the first byte of the key of the partition pack that defines that

partition. Specific KLV items that may be aligned to a gridline include the preface set (of the header metadata)

and the index table segment set. Individual essence container specifications shall define which KLV elements

shall lie on a gridline. All partitions that use the KAG shall ensure that the end of that partition is padded to a

gridline defined by that partition.

A KAG value of “0” defines that the grid value is undefined; e.g., there may once have been a KAG but it may

no longer be valid for some reason. A KAG value of “1” defines that there is no grid; i.e., byte alignment. Any

KAG value between, and including, “2” and “1048576” defines a valid grid size. A KAG value in excess of

“1048576” (1 Mbyte, 2

) is not permitted.

NOTE –

The upper limit of 1 Mbyte is provided to minimize receiver buffer requirements.

If grid alignment is used, then all partitions of the same type in the file should use grid alignment. The KAG

size is specified in every partition pack and is valid for that partition only. The KAG size shall be constant for

all partitions with segments from the same essence container. However, specific applications may require a

different KAG size value for different essence containers (for example, an MXF file that has a high resolution

primary video and an alternate low resolution preview video might use different KAG sizes for the essence

container of each video).

If the KAG size of any partition is changed, then the values of appropriate items within the partition (e.g.,

partition pack, index tables) should be changed accordingly. If an MXF application modifies the KAG size in a

partition and the dependant partition items are not updated, then the KAG value should be set to 0. The KAG

size parameter is a performance enhancement parameter. It is possible that some files may have the KAG

value incorrectly set.

Essence container specifications may define a KAG value which MXF encoders should use, however, all

decoders shall correctly parse a file whether the KAG parameter is correct or not.

NOTE – Application writers should be aware that incorrect values of KAG size may lead to performance degradation,

especially when MXF files are transferred to and from certain classes of machine. Applications may also be degraded by

the requirements of KAG implementation. Its use is therefore optional.

5.4.2 MXF byte order

This section defines the byte order of the value fields in KLV packets used in MXF files. The byte order of

essence data as a value in a KLV packet shall be defined by the appropriate specification.

For all other parts of the MXF specification, all multi-byte values in any KLV packet shall be coded as big-

endian (most significant byte first), wherever the value is sensitive to the byte order. Examples of simple multi-

byte values affected by byte order are: UInt16, Uint32, Uint64 and UTF-16.

Compound data types shall have all component multi-byte values coded as big-endian.

5.4.3 Encoding constraints

This document constrains several aspects of MXF encoding. Other documents, such as operational pattern

and essence container specifications, may further constrain aspects of MXF encoding for reasons particular

to their requirements.

5.5 Run-in sequence

In certain specialized operational patterns, the header partition may be preceded by a non-KLV coded run-in. This is

to allow synchronization bytes or “camouflage” bytes to be added at the front of the file in specialized applications.

SMPTE 377M-2004

Page 19 of 101 pages

One example of this use is when a broadcast WAV header is added to the start of the MXF file to make it look like a

WAV file to a WAV machine and an MXF file to an MXF machine with no change in byte structure. In all other

circumstances, there will be no run-in and the entire file must consist of only of KLV packets with NO gaps.

MXF decoders shall ignore the run-in sequence and parse the input data until either the first 11 bytes of the

partition pack label has been located or the maximum run-in length has been exceeded.

The run-in sequence shall be less than 65536 bytes long and shall not contain the first 11 bytes of the

partition pack label. The maximum length of the run-in prevents a decoder from searching through an

excessively large non-MXF file if incorrectly applied to an MXF decoder.

The default run-in sequence shall have a length of zero.

MXF encoders may insert any necessary run-in sequence providing it conforms to the rules given above, and

any rules given in the appropriate specialized operational pattern document.

5.6 Minimum decoder

The concept of a minimum decoder is useful in defining the minimum behavior of any device which claims to

be MXF aware. The following is a list of required functionality:

1. It must locate the first Key in the file and determine that it is the key of the header partition pack (open or

closed).

2. It must then locate, in the value fields of the header partition pack, the ULs for the operational pattern and

the essence container, where present (some commissioning files may have no essence container and be

metadata only).

3. It must determine if the operational pattern UL is compatible with the capabilities of this decoder.

4. It must further determine if the essence container(s) UL is compatible with the capabilities of this decoder.

5. It must have a defined behavior (such as reporting an error) if the operational pattern or essence

containers(s) are incompatible with its capabilities.

Useful decoders that are compatible with the indicated operation pattern and essence container(s) will then

perform additional operations as needed such as to verify the KLV syntax, verify the remaining partition

packs, locate the header metadata in a closed partition, decode the contents of that header metadata, decode

the contents of selected compatible essence container(s) and decode the contents of other parts of the file

such as primer pack, index tables, descriptive metadata and the RIP (where present).

5.7 Strong/weak reference integrity (informative)

This section is a guidance note to point out that MXF decoders may not be able to find the target of all the

references in an MXF file. This may be because the target is a dark set. This situation can occur for many

reasons including additions to the MXF specification (extensions, new essence types etc.) or it may be

because private additions to the specification have been included in specific files. In general, the following

points should be observed:

1. References are made from a property in one set of type WeakRef or StrongRef to the InstanceUID

property in another set.

2. All header metadata sets (other than the primer) shall be strongly referenced (directly or indirectly) to the

preface set.

3. All strong references in a file shall match one and only one set.

SMPTE 377M-2004

Page 20 of 101 pages

4. Weak references may be made to "global definitions" which may be inside or outside the file, in these

cases the WeakRef will be either a UUID or a UL. Therefore, if a weak reference cannot be matched in the

file, then it can be regarded as a global definition.

5. As dark metadata can exist in the header this means that references of any kind may appear to be

unresolved even though they are correct. MXF decoders shall be able to cope with this.

6 Partitions

6.1 Partition pack

Partition packs shall be KLV coded, fixed length packs as defined in SMPTE 336M. Header partition packs,

body partition packs and footer partition packs, whether open or closed, complete or incomplete, shall be

variants of partition pack.

The key of the partition pack is given in table 1.

Table 1 – Partition pack key value

Byte No. Description Value (hex) Meaning

1 Object Identifier 06h

2 Label size 0Eh

3 Designator 2Bh ISO, ORG

4 Designator 34h SMPTE

5 Registry Category Designator 02h KLV Sets & Packs

6 Registry Designator 05h Fixed Length Packs (no length fields)

7 Structure Designator 01h Set / Pack registry

8 Version Number 01h Registry Version 1

9 Item Designator 0Dh Organizationally registered

10 Organization 01h AAF

11 Application 02h MXF File Structure

12 Structure Version 01h Version 1

13 Structure Kind 01h MXF File Structure sets & packs

14 Set / Pack Kind Sections 6.2, 6.3, 6.4 Header Partition, Body Partition or Footer Partition

15 Partition Status Sections 6.2, 6.3, 6.4 Open and Incomplete (01h

Closed and Incomplete (02h)

Open and Complete (03h)

Closed and Complete (04h)

16 Reserved 00h

Byte 15 provides four alternate partition pack key values for the combinations provided by an open or closed

partition and a complete or incomplete header metadata as defined in section 5.2.3.

The data in a partition pack is defined in table 2 and the notes which follow. Note that the values shall appear

in the order presented in table 2 because this is a pack.

剩余100页未读，继续阅读

guyan1220

粉丝: 0
资源: 2

MXF文件格式规范：SMPTE_377m-2004详解

SMPTE 272M-2004

SMPTE_330m-2004

SMPTE_377M MXF文档

smpte-12m-1

smpte-2110-10 标准

SMPTE2059协议与1588的区别

smpte 421m csdn

smpte 424m标准

vertical-grabber

smpte 424m

最新资源