MXF标准详解：SMPTE 377M规范

需积分: 16 32 浏览量更新于2024-07-24 1 收藏 842KB PDF 举报

"SMPTE 377M标准详细解读" SMPTE 377M，全称为“Society of Motion Picture and Television Engineers (电影与电视工程学会) 377M标准”，是一个关键性的行业标准，它规定了媒体交换格式（Material eXchange Format, MXF）的数据结构，用于在音频和视频内容之间进行交换。MXF旨在统一不同设备、系统和应用之间的媒体数据格式，提高互操作性，降低集成成本。 1. **标准范围**： SMPTE 377M标准主要关注MXF文件的数据结构，不涉及内部存储格式。该标准涵盖了MXF文件的所有组件，包括文件头、文件主体和文件尾。此外，它还定义了文件中的分区，这些分区提供诸如适应多种应用需求和部分接收文件恢复等特性。 2. **规范引用**：标准文档通常会引用其他相关的技术规范或标准，以确保一致性与兼容性。这部分可能包括其他SMPTE标准、国际标准组织如ISO或IEC的标准，以及其他行业的技术规范。 3. **缩写、术语和数据类型定义**：这一部分对标准中使用的专业术语、缩写和数据类型进行解释，以确保所有读者都能理解文档内容。 4. **介绍**：提供标准的基本背景和目的，解释MXF格式如何解决行业中的问题，以及它在音频-视觉内容交换中的作用。 5. **总体规范**：描述MXF文件的通用格式，包括网络传输和存储媒体上的应用。 6. **分区**： MXF文件内的分区是其结构的重要组成部分，它们允许文件被划分为逻辑段，每个段包含特定类型的数据，如元数据或实际的媒体数据。这有助于实现高效的数据管理和处理。 7. **操作模式**：操作模式定义了MXF文件在不同应用场景下的具体使用方式，例如多轨音频、单节目或多个节目组合等。 8. **头部元数据**：包含关于文件内容的描述性信息，如时间码、音轨配置、编码信息等。 9. **文件体**：存储实际的媒体数据，如音频样本和视频帧。 10. **索引表**：提供快速访问文件内容的途径，例如时间码到物理位置的映射，以支持随机访问和播放。 11. **随机索引包**：一种特殊类型的索引，可以快速定位文件内的任意位置，这对于大型MXF文件的处理至关重要。 12. **附录**：包含对根元数据集、通用包、MXF中使用的包、基于文件的描述符以及图片本质描述符项目的详细规格说明。这些附录提供了额外的详细信息，以帮助实现者更好地理解和实现MXF标准。 SMPTE 377M标准的制定使得不同制造商的设备和软件能够无缝地交换和处理多媒体内容，对于广播、电影制作、后期制作和媒体资产管理等行业具有重要意义。通过遵循这一标准，业界可以减少技术障碍，提升效率，推动音频和视频内容的创新。

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页未读，继续阅读

猎尘

粉丝: 0
资源: 2

MXF标准详解：SMPTE 377M规范

SMPTE 协议大全

SMPTE 336M标准 MXF KLV

mxf 标准文档

MXF文件格式规范 - SMPTE 377M标准详解

SMPTE 377M-2004: MXF 格式规范与音频视频材料交换

KLV编码详解：SMPTE 336M标准与MXF

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

SMPTE_377m-2004

SMPTE_330m-2004

s378m-MXF-Operational-pattern-1A.

最新资源