ISO/IEC 14496-12:2012多媒体文件格式标准

需积分: 11 163 浏览量更新于2024-07-25 收藏 1.27MB PDF 举报

"ISO_IEC_14496-12_2012_ISO_base_media_file_format" ISO_IEC_14496-12_2012是國際標準化組織（ISO）和國際電信聯盟（IEC）共同制定的ISO base media file format標準，該標準於2012年發布最新版本。這個標準規定了音頻視頻對象的編碼規範，涵蓋了多媒體文件的格式、編碼和解碼等方面的技術規範。在這個標準中，ISO_IEC_14496-12_2012規定了基礎媒體文件格式的技術規範，涵蓋了音頻視頻對象的編碼、解碼、封裝和傳輸等方面的技術規範。這個標準的目的是為了提供一個通用的、開放的多媒體文件格式，實現跨平台、跨設備的多媒體內容共享和交互。 ISO_IEC_14496-12_2012標準由多個部分組成，包括前言、引言、範圍、規範參考、術語、定義和縮略語等。這個標準還涵蓋了多媒體文件的格式、編碼和解碼等方面的技術規範，包括音頻視頻對象的編碼、解碼、封裝和傳輸等。在這個標準中，ISO_IEC_14496-12_2012規定了多媒體文件的基本結構，包括文件頭、 metadata和 payload 等。這個標準還規定了多媒體文件的編碼和解碼規範，包括音頻視頻對象的編碼、解碼和封裝等。此外，ISO_IEC_14496-12_2012標準還涵蓋了多媒體文件的傳輸和存儲規範，包括檔案系統、網路傳輸和存儲設備等。這個標準還規定了多媒體文件的安全規範，包括加密、認證和授權等。總之，ISO_IEC_14496-12_2012標準是一個通用的多媒體文件格式標準，涵蓋了多媒體文件的格式、編碼、解碼、封裝和傳輸等方面的技術規範。這個標準的目的是為了提供一個通用的、開放的多媒體文件格式，實現跨平台、跨設備的多媒體內容共享和交互。總結來說，ISO_IEC_14496-12_2012標準具有以下幾個特點： * 通用的多媒體文件格式標準 * 涵蓋了多媒體文件的格式、編碼、解碼、封裝和傳輸等方面的技術規範 * 實現跨平台、跨設備的多媒體內容共享和交互 * 提供了一個開放的多媒體文件格式標準 * 實現了多媒體文件的安全傳輸和存儲因此，ISO_IEC_14496-12_2012標準對於多媒體文件的處理和應用具有重要的參考意義。

ISO/IEC 14496-12:2012(E)

samples forms the correct presentation of the media starting at the decoded sample that has the earliest composition time;

a media format may provide a more precise definition of a sync sample for that format.

3.1.17

segment

portion of an ISO base media file format file, consisting of either (a) a movie box, with its associated media

data (if any) and other associated boxes or (b) one or more movie fragment boxes, with their associated

media data, and other associated boxes

3.1.18

subsegment

time interval of a segment formed from movie fragment boxes, that is also a valid segment

3.1.19

track

timed sequence of related samples (q.v.) in an ISO base media file

NOTE For media data, a track corresponds to a sequence of images or sampled audio; for hint tracks, a track

corresponds to a streaming channel.

3.2 Abbreviated terms

For the purposes of this document, the following abbreviated terms apply.

ALC Asynchronous Layered Coding

FD File Delivery

FDT File Delivery Table

FEC Forward Error Correction

FLUTE File Delivery over Unidirectional Transport

IANA Internet Assigned Numbers Authority

LCT Layered Coding Transport

MBMS Multimedia Broadcast/Multicast Service

4 Object-structured File Organization

4.1 File Structure

Files are formed as a series of objects, called boxes in this specification. All data is contained in boxes; there

is no other data within the file. This includes any initial signature required by the specific file format.

All object-structured files conformant to this section of this specification (all Object-Structured files) shall

contain a File Type Box.

4.2 Object Structure

An object in this terminology is a box.

Boxes start with a header which gives both size and type. The header permits compact or extended size (32

or 64 bits) and compact or extended types (32 bits or full Universal Unique IDentifiers, i.e. UUIDs). The

standard boxes all use compact types (32-bit) and most boxes will use the compact (32-bit) size. Typically

only the Media Data Box(es) need the 64-bit size.

The size is the entire size of the box, including the size and type header, fields, and all contained boxes. This

facilitates general parsing of the file.

ISO/IEC 14496-12:2012(E)

The definitions of boxes are given in the syntax description language (SDL) defined in MPEG-4 (see reference

in Clause 2). Comments in the code fragments in this specification indicate informative material.

The fields in the objects are stored with the most significant byte first, commonly known as network byte order

or big-endian format. When fields smaller than a byte are defined, or fields span a byte boundary, the bits are

assigned from the most significant bits in each byte to the least significant. For example, a field of two bits

followed by a field of six bits has the two bits in the high order bits of the byte.

aligned(8) class Box (unsigned int(32) boxtype,

optional unsigned int(8)[16] extended_type) {

unsigned int(32) size;

unsigned int(32) type = boxtype;

if (size==1) {

unsigned int(64) largesize;

} else if (size==0) {

// box extends to end of file

}

if (boxtype==‘uuid’) {

unsigned int(8)[16] usertype = extended_type;

}

The semantics of these two fields are:

size is an integer that specifies the number of bytes in this box, including all its fields and contained

boxes; if size is 1 then the actual size is in the field largesize; if size is 0, then this box is the last

one in the file, and its contents extend to the end of the file (normally only used for a Media Data Box)

type identifies the box type; standard boxes use a compact type, which is normally four printable

characters, to permit ease of identification, and is shown so in the boxes below. User extensions use

an extended type; in this case, the type field is set to ‘uuid’.

Boxes with an unrecognized type shall be ignored and skipped.

Many objects also contain a version number and flags field:

aligned(8) class FullBox(unsigned int(32) boxtype, unsigned int(8) v, bit(24) f)

extends Box(boxtype) {

unsigned int(8) version = v;

bit(24) flags = f;

}

The semantics of these two fields are:

version is an integer that specifies the version of this format of the box.

flags is a map of flags

Boxes with an unrecognized version shall be ignored and skipped.

4.3 File Type Box

4.3.1 Definition

Box Type: `ftyp’

Container: File

Mandatory: Yes

Quantity: Exactly one (but see below)

Files written to this version of this specification must contain a file-type box. For compatibility with an earlier

version of this specification, files may be conformant to this specification and not contain a file-type box. Files

with no file-type box should be read as if they contained an FTYP box with Major_brand='mp41',

minor_version=0, and the single compatible brand 'mp41'.

ISO/IEC 14496-12:2012(E)

A media-file structured to this part of this specification may be compatible with more than one detailed

specification, and it is therefore not always possible to speak of a single ‘type’ or ‘brand’ for the file. This

means that the utility of the file name extension and Multipurpose Internet Mail Extension (MIME) type are

somewhat reduced.

This box must be placed as early as possible in the file (e.g. after any obligatory signature, but before any

significant variable-size boxes such as a Movie Box, Media Data Box, or Free Space). It identifies which

specification is the ‘best use’ of the file, and a minor version of that specification; and also a set of other

specifications to which the file complies. Readers implementing this format should attempt to read files that

are marked as compatible with any of the specifications that the reader implements. Any incompatible change

in a specification should therefore register a new ‘brand’ identifier to identify files conformant to the new

specification.

The minor version is informative only. It does not appear for compatible-brands, and must not be used to

determine the conformance of a file to a standard. It may allow more precise identification of the major

specification, for inspection, debugging, or improved decoding.

Files would normally be externally identified (e.g. with a file extension or mime type) that identifies the ‘best

use’ (major brand), or the brand that the author believes will provide the greatest compatibility.

This section of this specification does not define any brands. However, see subclause 6.3 below for brands for

files conformant to the whole specification and not just this section. All file format brands defined in this

specification are included in Annex E with a summary of which features they require.

4.3.2 Syntax

aligned(8) class FileTypeBox

extends Box(‘ftyp’) {

unsigned int(32) major_brand;

unsigned int(32) minor_version;

unsigned int(32) compatible_brands[]; // to end of the box

}

4.3.3 Semantics

This box identifies the specifications to which this file complies.

Each brand is a printable four-character code, registered with ISO, that identifies a precise specification.

major_brand – is a brand identifier

minor_version – is an informative integer for the minor version of the major brand

compatible_brands – is a list, to the end of the box, of brands

5 Design Considerations

5.1 Usage

5.1.1 Introduction

The file format is intended to serve as a basis for a number of operations. In these various roles, it may be

used in different ways, and different aspects of the overall design exercised.

5.1.2 Interchange

When used as an interchange format, the files would normally be self-contained (not referencing media in

other files), contain only the media data actually used in the presentation, and not contain any information

ISO/IEC 14496-12:2012(E)

5.1.3 Content Creation

During content creation, a number of areas of the format can be exercised to useful effect, particularly:

• the ability to store each elementary stream separately (not interleaved), possibly in separate files.

• the ability to work in a single presentation that contains media data and other streams (e.g. editing

the audio track in the uncompressed format, to align with an already-prepared video track).

These characteristics mean that presentations may be prepared, edits applied, and content developed and

integrated without either iteratively re-writing the presentation on disc – which would be necessary if interleave

was required and unused data had to be deleted; and also without iteratively decoding and re-encoding the

data – which would be necessary if the data must be stored in an encoded state.

In the following diagram, a set of files being used in the process of content creation is shown.

media file

video frames, possibly

un-ordered with other

unused data

ISO File

…other boxes (inc. moov)

mdat

Video and Audio frames

possibly

un-ordered with other

unused data

ISO file

moov

…other boxes

trak (audio)

trak (video)

Figure 2 — Content Creation File

5.1.4 Preparation for streaming

When prepared for streaming, the file must contain information to direct the streaming server in the process of

sending the information. In addition, it is helpful if these instructions and the media data are interleaved so that

excessive seeking can be avoided when serving the presentation. It is also important that the original media

data be retained unscathed, so that the files may be verified, or re-edited or otherwise re-used. Finally, it is

helpful if a single file can be prepared for more than one protocol, so differing servers may use it over

disparate protocols.

5.1.5 Local presentation

‘Locally’ viewing a presentation (i.e. directly from the file, not over a streamed interconnect) is an important

application; it is used when a presentation is distributed (e.g. on CD or DVD ROM), during the process of

development, and when verifying the content on streaming servers. Such local viewing must be supported,

with full random access. If the presentation is on CD or DVD ROM, interleave is important as seeking may be

slow.

剩余195页未读，继续阅读

CupidArrow

粉丝: 2
资源: 6

ISO/IEC 14496-12:2012多媒体文件格式标准

ISO_IEC_14496-15_2013_AVCFF.pdf

iso_iec_14496-12_2015.pdf

c071851_ISO_IEC_14496-12_2015_Amd_2_2018 Support for image file format

ISO_base_media_file_format.rar_14496_14496-14_3GPP_3GPP协议_iso-ba

ISO_IEC_14496-12_2015_MPEG-4_ISO_BMFF.pdf

ISO_IEC_14496-12

ISO_IEC_14496-12_2008

ISO_IEC_14496-12_2015.pdf

H.264官方中文版和ISO_IEC_14496-12_2012标准

ISO_IEC_14496-12+14.tar.gz

最新资源