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

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

"SMPTE_377m-2004是关于MXF（Material eXchange Format）标准的详细规范，由SMPTE（Society of Motion Picture and Television Engineers）于2004年发布。这个标准主要用于音频和视频素材的交换，适用于网络传输和存储媒体。它不涉及MXF兼容设备的内部存储格式，而是全面定义了MXF文件规格，包括文件头、文件主体和文件尾的所有组件。" SMPTE 377M-2004标准主要涵盖以下几个方面： 1. **范围**：该标准定义了MXF的数据结构，用于音频-视频素材的交换，同时适用于网络传输和存储介质。它不包含MXF设备的内部存储格式规定。 2. **规范引用**：文档可能引用了其他相关标准和技术规范，这些规范对于理解和实现MXF标准至关重要。 3. **缩写词、术语和数据类型定义**：标准提供了必要的术语解释和数据类型定义，确保所有读者对术语有统一的理解。 4. **介绍**：这部分通常概述MXF标准的目的、背景和目标，以及其在音视频行业中的重要性。 5. **整体规范**：详细描述了MXF文件的整体结构，包括文件的组成部分及其相互关系。 6. **分区**：MXF文件中的分区是其一大特色，允许文件根据不同的应用需求服务，并支持部分接收文件的恢复。 7. **操作模式**：定义了MXF文件在不同应用场景下的操作方式，例如编辑、播放等。 8. **头部元数据**：包含了文件的重要信息，如素材的元数据、时间码、剪辑信息等。 9. **文件主体**：存储实际的音频和视频数据，以及可能的辅助数据，如字幕或时间码。 10. **索引表**：帮助快速定位和访问文件中的特定数据段。 11. **随机索引包**：提供了快速访问文件内容的另一种方式，特别是对于大型文件。 12. **附录**：包括了根元数据集、通用包、MXF中使用的包、基于文件的描述符以及图片本质描述符等具体规范。 13. **参考文献**：列举了制定标准时参考的相关文献和技术资料。 MXF格式的设计目标是为了促进不同制作和后期制作设备之间的兼容性，允许在不同系统之间无缝交换音频和视频内容。通过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页未读，继续阅读

gzjspace

粉丝: 0
资源: 2

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

SMPTE_330m-2004

SMPTE_377M MXF文档

程序设计竞赛题册生成.zip

海康威视SDK实例QtDemo显示NVR视频窗口(Linux+Qt)

Proteus是英国Lab Center Electronics公司出版的EDA工具软件，是一款功能强大的电子电路仿真和物理特性

springboot基于大数据的音乐数据可视化分析系统毕业论文.docx

BAAlgorithmUtils-1.0.10-py3-none-any.whl

西安理工大学竞赛管理系统.zip

阿里天池竞赛.zip

Sigrity-SPEED2000 Examples 2.rar

最新资源