ISO/IEC 14496-12:2008/Amd.1:2009(E)

所需积分/C币:10 2012-02-09 10:52:31 465KB PDF
收藏 收藏

ISO/IEC 14496-12:2008/Amd.1:2009(E),3gp文件格式国际标准
lsO/EC14496122008/Amd.1:2009(E) Foreword Iso(the International Organization for Standardization) and iec(the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISo and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental ind non-governmental, in liaison with Iso and IEC, also take part in the work. In the field of information technology, IsO and lEC have established a joint technical committee, ISOnEC JTC 1 International Standards are drafted in accordance with the rules given in the iso/EC Directives, part 2 The main task of the joint technical committee is to prepare International Standards. Draft Internationa Standards adopted by the joint technical committee are circulated to national bodies for voting Publication as an International Standard requires approval by at least 75 of the national bodies casting a vote Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISo and lEC shall not be held responsible for identifying any or all such patent rights Amendment 1 to ISO/EC 14496-12: 2008 was prepared by Joint Technical Committee ISO/EC JTC 1 Information technology, Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information This Amendment provides a number of new hint track formats and improvements in other areas, including metadata support O ISO/EC 2009- All rights reserved lsO/EC14496122008/Amd.1:2009(E) Information technology- Coding of audio-visual objects Part 12 so base media file format AMENDMENT 1: General improvements including hint tracks metadata support and sample groups Reformat the table of contents, including the new subclauses and revised page numbers Add the following normative references to clause 2 ISO/EC 23002-3, Information technology- MPEG video technologies- Part 3: Representation of auxiliary video streams and supplemental information IETF RFC 5052, Forward Error Correction(FEC) Building Block, WATSON, M. et al., August 2007 In 6.2.3, Table 1, add the following line after tref 8.3.4 track grouping indication In 6.2.3, Table 1, add the following line after ' ctts cslg.6.1. 4 composition to decode timeline mapping In 6.2. 3, add the following after paen fire 8.13. file reservoir In 6.2.3, Table 1, add the following lines after tse/ dat 11.11 item data ref 8.11.12 item reference After 6.2.3, add the following new subclause 6.2.4 URIs as type indicators When URIs are used as a type indicator(e. g. in a sample entry or for un-timed meta-data) the URI must be absolute, not relative and the format and meaning of the data must be defined by the URI in question. This identification may be hierarchical, in that an initial sub-string of the URI might identify the overall nature or family of the data( e.g. urn: oid: identifies that the metadata is labelled by an ISo-standard object identifier) O ISO/EC 2009- All rights reserved sOEC1449612:2008/Amd.1:2009E) The URI should be, but is not required to be, de-referencable. It may be string compared by readers with the set of URI types it knows and recognizes. URIs provide a large non-colliding non-registered space for type identifiers If the URI contains a domain name(e.g. it is a URL), then it should also contain a month-date in the form mmyyyy. That date must be near the time of the definition of the extension, and it must be true that the URI was defined in a way authorized by the owner of the domain name at that date. (This avoids problems when domain names change ownership Replace Clause 7 with the following 7 Streaming Support 7.1 Handling of Streaming Protocols The file format supports streaming of media data over a network as well as local playback. The process of sending protocol data units is time-based, just like the display of time-based data, and is therefore suitably described by a time-based format. a file or 'movie that supports streaming includes information about the data units to stream. This information is included in additional tracks of the file called"hint tracks. Hint tracks may also be used to record a stream these are called reception hint tracks to differentiate them from plain (or server, or transmission)hint tracks Transmission or server hint tracks contain instructions to assist a streaming server in the formation of packets for transmission. These instructions may contain immediate data for the server to send(e.g. header information or reference segments of the media data these instructions are encoded in the file in the same way that editing or presentation information is encoded in a file for local playback. Instead of editing or presentation information, information is provided which allows a server to packetize the media data in a manner suitable for streaming using a specific network transport The same media data is used in a file that contains hints, whether it is for local playback, or streaming over a number of different protocols. Separate hint tracks for different protocols may be included within the same file and the media will play over all such protocols without making any additional copies of the media itself. In addition, existing media can be easily made streamable by the addition of appropriate hint tracks for specific protocols. The media data itself need not be recast or reformatted in any way This approach to streaming and recording is more space efficient than an approach that requires that the edia information be partitioned into the actual data units that will be transmitted for a given transport and media format. Under such an approach, local playback requires either re-assembling the media from the packets, or having two copies of the media one for local playback and one for streaming. Similarly, streaming such media over multiple protocols using this approach requires multiple copies of the media data for each transport. This is inefficient with space, unless the media data has been heavily transformed for streaming(e.g. by the application of error-correcting coding techniques, or by encryption) Reception hint tracks may be used when one or more packet streams of data are recorded. Reception hint tracks indicate the order, reception timing, and contents of the received packets among other things NOTE 1: Players may reproduce the packet stream that was received based on the reception hint tracks and process the reproduced packet stream as if it was newly received 7.2 Protocol 'hint' tracks Support for streaming is based upon the following three design parameters The media data is represented as a set of network-independent standard tracks, which may be played, edited, and so on, as normal O ISO/EC 2009-All ric lsO/EC14496122008/Amd.1:2009(E) There is a common declaration and base structure for hint tracks this common format is protocol independent, but contains the declarations of which protocol(s)are described in the hint track (s) There is a specific design of the hint tracks for each protocol that may be transmitted; all these designs use the same basic structure. For example, there may be designs for rTP (for the Internet) and mPEG-2 transport(for broadcast), or for new standard or vendor-specific protocols The resulting streams, sent by the servers under the direction of the server hint tracks or reconstructed from the reception hint tracks, need contain no trace of file-specific information. This design does not require that the file structures or declaration style be used either in the data on the wire or in the decoding station. For example, a file using ITU-T H 261 video and DVI audio, streamed under RTP, results in a packet stream that is fully compliant with the IE T F specifications for packing those codings into RTP 7 3 Hint Track Format Hint tracks are used to describe elementary stream data in the file. Each protocol or each family of related protocols has its own hint track format. a server hint track format and a reception hint track format for the same protocol are distinguishable from the associated four-character code of the sample description entry. In other words, a different four-character code is used for a server hint track and a reception hint track of the same protocol. The syntax of the server hint track format and the reception hint track format for the same protocol should be the same or compatible so that a reception hint track can be used for re-sending of the stream provided that the potential degradations of the received streams are handled appropriately. Mos protocols will need only one sample description format for each track Servers find their hint tracks by first finding all hint tracks, and then looking within that set for server hint tracks using their protocol (sample description format). If there are choices at this point, then the server chooses on the basis of preferred protocol or by comparing features in the hint track header or other protocol-specific information in the sample descriptions. Particularly in the absence of server hint tracks, servers may also use reception hint tracks of their protocol. However, servers should handle potential degradations of the received stream described by the used reception hint track appropriately Tracks having the track in movie flag set are candidates for playback, regardless of whether they are media tracks or reception hint tracks Hint tracks construct streams by pulling data out of other tracks by reference. These other tracks may be hint tracks or elementary stream tracks. The exact form of these pointers is defined by the sample format for the protocol, but in general they consist of four pieces of information a track reference index, a sample number an offset, and a length Some of these may be implicit for a particular protocol. These 'pointers' always point to the actual source of the data. If a hint track is built 'on top' of another hint track then the second hint track must have direct references to the media track(s) used by the first where data from those media tracks is placed in the stream all hint tracks use a common set of declarations and structures Hint tracks are linked to the elementary stream tracks they carry, by track references of type thint They use a handler-type of hintin the Handler Reference Box They use a Hint Media Header Box They use a hint sample entry in the sample description, with a name and format unique to the protocol they represent Server hint tracks are usually marked as disabled for local playback, with their track header track_in_movie and track_in preview flags set to O Hint tracks may be created by an authoring tool, or may be added to an existing presentation by a hinting tool Such a tool serves as a bridge between the media and the protocol, since it intimately understands both. This O ISO/EC 2009- All rights reserved sO/EC14496-12:2008/Amd1:2009(E permits authoring tools to understand the media format, but not protocols and for servers to understand protocols(and their hint tracks) but not the details of media data Hint tracks do not use separate composition times; the 'ctts table is not present in hint tracks. The process of hinting computes transmission times correctly as the decoding time NOTE 1: Servers using reception hint tracks as hints for sending of the received streams should handle the potential degradations of the received streams, such as transmission delay jitter and packet losses, gracefully and ensure that the constraints of the protocols and contained data formats are obeyed regardless of the potential degradations of the received streams NOTE 2: Conversion of received streams to media tracks allows existing players compliant with earlier versions of the iso base media file format to process recorded files as long as the media formats are supported However, most media coding standards only specify the decoding of error-free streams, and consequently it should be ensured that the content in media tracks can be correctly decoded. Players may utilize reception hint tracks for handling of degradations caused by the transmission, i.e., content that may not be correctly decoded is located only within reception hint tracks. The need for having a duplicate of the correct media samples in both a media track and a reception hint track can be avoided by including data from the media track by reference into the reception hint track In. 3.2.1, change Hint tracks should have the track header flags set to 0, so that they are ignored for local playback and preview. Server hint tracks should have the track_in_ movie and track_in_ preview track header flags set to 0 so that they are ignored for local playback and preview. In 8.3. 3.3(Track Reference BoX, Semantics), replace the definition of reference type as follows The reference_type shall be set to one of the following values, or a value registered or from a derived specification or registration hint the referenced track(s)contain the original media for this hint track cdsc this track describes the referenced track hind this track depends on the referenced hint track, i. e, it should only be used if the referenced hint track is used dep this track contains auxiliary depth video information for the referenced video track plxthis track contains auxiliary parallax video information for the referenced video track After 8.3.3, add the following new subclause 8.3. 4 Track Group box 8. 3.4.1 Definition Box Type: trgr Container: Track Box (trak) Mandatory: No Quantity: Zero or one This box enables indication of groups of tracks, where each group shares a particular characteristic or the tracks within a group have a particular relationship. The box contains zero or more boxes, and the particular O ISO/EC 2009-All rights reserved lsO/EC14496122008/Amd.1:2009(E) characteristic or the relationship is indicated by the box type of the contained boxes. The contained boxes include an identifier, which can be used to conclude the tracks belonging to the same track group. The tracks that contain the same type of a contained box within the track group box and have the same identifier value within these contained boxes belong to the same track group Track groups shall not be used to indicate dependency relationships between tracks. Instead, the Track Reference Box is used for such purposes Syntax aligned(8)class TrackGroupBox('trgr )[ aligned(8) class TrackGroupType Box (unsigned int(32) track group type)extends FullBox(track group type, version =0, flags =0) unsigned int(32)track group id //the remaining data may be specified for a particular track group type 8. 3.4.3 Semantics track_group_type indicates the grouping type and shall be set to one of the following values or a value registered, or a value from a derived specification or registration msrc indicates that this track belongs to a multi-source presentation. The tracks that have the same value of track_group_ia within a group Type Box of track_ group_ type msrc are mapped as being originated from the same source. For example, a recording of a video telephony call may have both audio and video for both participants, and the value of track_group_id associated with the audio track and the video track of one participant differs from value of track group id associated with the tracks of the other participant The pair of track_group_id and track_group_type identifies a track group within the file. The tracks that contain a particular track group type box having the same value of track_group_id belong to the same track group. In 8.4.3. 1, (Handler Reference Box, definition), before the NOTEs, add the following paragraph An auxiliary video track is coded the same as a video track, but uses this different handler type, and is not intended to be visually displayed (e. g. it contains depth information, or other monochrome or color two dimensional information). Auxiliary video tracks are usually linked to a video track by an appropriate track reference In, after the line for 'meta'add the following line auxv Auxiliary video track At the end of 8.5.2. 1 Sample Description, Definition), add the following The URIMeta SampleEntry entry contains, in a box, the URI defining the form of the metadata, and optiona initialization data the format of both the samples and of the initialization data is defined by all or part of the URI for An optional bitrate box may be used in the URIMeta Sample Entry entry, as usual It may be the case that the URI identifies a format of metadata that allows there to be more than one ' stated fact within each sample. However, all metadata samples in this format are effectively I frames, defining the entire set of metadata for the time interval they cover. This means that the complete set of metadata at any O ISO/EC 2009- All rights reserved sO/EC14496-12:2008/Amd1:2009(E instant, for a given track, is contained in(a)the time-aligned samples of the track(s)(if any describing that track, plus()the track metadata(if any), the movie metadata(if any) and the file metadata(if any) If incrementally-changed metadata is needed, the MPEG-7 framework provides that capability Information on URI forms for some metadata systems can be found in Annex G In 8 5.2.2, add before l/Visual Sequences aligned(&)class uriBox extends FullBox(uri version =00) string theUR工; aligned(8)class URIInitBox extends FullBox('uriI', version =00)[ unsigned int(8)uri_initialization data[]; class URIMetasampleEntry() extends MetaDatasampleEntry ('urim')i UR工box the labeli UR工 ni tBox init // optional MPEG4BitRateBox ( op At the end of 8 5.2.3, add the following theurI is a URI formatted according to the rules in 6.2.4 nitialization data is opaque data whose form is defined in the documentation of the uri orm In 1(Composition Time to Sample, Definition), replace the body text with the following This box provides the offset between decoding time and composition time. In version 0 of this box the decoding time must be less than the composition time, and the offsets are expressed as unsigned numbers such that CT(n)=dT(n)+ ctTs(n)where CTTs(n)is the(uncompressed) table entry for sample n In version 1 of this box, the composition timeline and the decoding timeline are still derived from each other, but the offsets are signed. It is recommended that for the computed composition timestamps, there is exactly one with the value(zero) For either version of the box, each sample must have a unique composition timestamp value, that is, the timestamp for two samples shall never be the same may be true that there is no frame to compose at time 0; the handling of this is unspecified (systems might display the first frame for longer, or a suitable fill colour When version 1 of this box is used, the Composition ToDecode Box may also be present in the sample table to elate the composition and decoding timelines. When backwards-compatibility or compatibility with an unknown set of readers is desired, version o of this box should be used when possible. In either version of this box, but particularly under version 0, if it is desired that the media start at track time 0, and the first media sample does not have a composition time of 0, an edit list may be used to 'shift the media to time 0 The composition time to sample table is optional and must only be present if dt and ct differ for any samples Hint tracks do not use this box Move the table and its header For example in table 2 from 8.6. 1.3. 2 to the end of 1 O ISO/EC 2009-All rights reserved

试读 54P ISO/IEC 14496-12:2008/Amd.1:2009(E)
立即下载 低至0.43元/次 身份认证VIP会员低至7折
河豚 文档不全啊,可以参考
shuitianyimu 不错....这部分下载下来先学习一下
pcvvv 第6章开始,可能是修订版的原因吧?谁有2012版本啊?
boxfile 问下,这个文件怎么是从第6章开始的啊
  • 签到新秀

关注 私信 TA的资源
ISO/IEC 14496-12:2008/Amd.1:2009(E) 10积分/C币 立即下载
ISO/IEC 14496-12:2008/Amd.1:2009(E)第1页
ISO/IEC 14496-12:2008/Amd.1:2009(E)第2页
ISO/IEC 14496-12:2008/Amd.1:2009(E)第3页
ISO/IEC 14496-12:2008/Amd.1:2009(E)第4页
ISO/IEC 14496-12:2008/Amd.1:2009(E)第5页
ISO/IEC 14496-12:2008/Amd.1:2009(E)第6页
ISO/IEC 14496-12:2008/Amd.1:2009(E)第7页
ISO/IEC 14496-12:2008/Amd.1:2009(E)第8页
ISO/IEC 14496-12:2008/Amd.1:2009(E)第9页
ISO/IEC 14496-12:2008/Amd.1:2009(E)第10页
ISO/IEC 14496-12:2008/Amd.1:2009(E)第11页

试读结束, 可继续读6页

10积分/C币 立即下载 >