CAN CSA-ISO IEC 13818-6C-2003 Information technology - Generic coding of moving pictures and associated audio information - Part 6 Extensions for DSM-CC AMENDMENT 3 Transport buffe.pdf

《CAN CSA-ISO IEC 13818-6C-2003 Information technology - Generic coding of moving pictures and associated audio information - Part 6 Extensions for DSM-CC AMENDMENT 3 Transport buffe.pdf》由会员分享，可在线阅读，更多相关《CAN CSA-ISO IEC 13818-6C-2003 Information technology - Generic coding of moving pictures and associated audio information - Part 6 Extensions for DSM-CC AMENDMENT 3 Transport buffe.pdf（9页珍藏版）》请在麦多课文档分享上搜索。

1、 Reference number ISO/IEC 13818-6:1998/Amd.3:2001(E)ISO/IEC 2001 Information technology Generic coding of moving pictures and associated audio information Part 6: Extensions for DSM-CC AMENDMENT 3: Transport buffer model in support of synchronized user-to-network download protocol Technologies de li

2、nformation Codage gnrique des images animes et des informations sonores associes Partie 6: Extensions pour DSM-CC AMENDEMENT 3: Modle de tampon de transport en support du protocole de chargement utilisateur-rseau synchronis Amendment 3:2003 toNational Standard of CanadaCAN/CSA-ISO/IEC 13818-6:02Amen

3、dment 3:2001 to International Standard ISO/IEC 13818-6:1998 has been adopted without modification asAmendment 3:2003 to CAN/CSA-ISO/IEC 13818-6:02. This Amendment was reviewed by the CSA TechnicalCommittee on Information Technology (TCIT) under the jurisdiction of the Strategic Steering Committee on

4、Information Technology and deemed acceptable for use in Canada.July 2003ISO/IEC 13818-6:1998/Amd.3:2001(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobes licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which ar

5、e embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therein the responsibility of not infringing Adobes licensing policy. The ISO Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe Systems Incorpo

6、rated. Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event that

7、a problem relating to it is found, please inform the Central Secretariat at the address given below. ISO/IEC 2001 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying a

8、nd microfilm, without permission in writing from either ISO at the address below or ISOs member body in the country of the requester. ISO copyright office Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.ch Web www.iso.ch ii ISO/IEC 2001 All rights r

9、eserved ISO/IEC 13818-6:1998/Amd.3:2001(E) ISO/IEC 2001 All rights reserved iiiForeword 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

10、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,

11、 governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3. In the field of information technology, ISO and IEC have established a joint technical committee, ISO

12、/IEC JTC 1. Draft International 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 e

13、lements of this Amendment may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Amendment 3 to International Standard ISO/IEC 13818-6:1998 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommi

14、ttee SC 29, Coding of audio, picture, multimedia and hypermedia information. ISO/IEC 13818-6:1998/Amd.3:2001(E) ISO/IEC 2001 All rights reserved 1Information technology Generic coding of moving pictures and associated audio information Part 6: Extensions for DSM-CC AMENDMENT 3: Transport buffer mode

15、l in support of synchronized user-to-network download protocol Add the following new subclause: 9.2.9 T-STD buffer model for synchronized download protocol 9.2.9.1 Introduction The MPEG-2 Transport System Target Decoder (T-STD) buffer model is defined for the Synchronized Download protocol. The buff

16、er model includes a secondary multiplexing stage based on the table_id_extension field of the DSM-CC section structure. The secondary multiplexing stage allows multiple data modules of a single program element to be independently synchronized. A secondary channel is referenced as a data module chann

17、el. The table_id_extension field conveys a copy of the moduleId of the data module. Each data module channel is identified by the moduleId value shared by all data modules conveyed in this data module channel. The primary, conventional multiplexing stage uses the MPEG-2 Transport Stream packets PID

18、value to forward the packet payloads to their respective smoothing buffer. The payloads of the Transport Stream packets are all portions of DSM-CC sections of a program element of stream_type value 0x14. The DSM-CC sections convey Download Control messages or Download Data messages. Download control

19、 messages are conveyed in sections with table_id value 0x3B while Download Data messages are conveyed in sections with table_id value 0x3C. The section_number field identifies the block number of the data module conveyed in the section. The payloads of the DSM-CC section sharing the same table_id, t

20、able_id_extension and version_number field values are re-assembled in-order in the receiver to reconstruct the synchronized data modules. 9.2.9.2 Definitions Table 9-7 below defines the DSM-CC section payload as the bytes between the section header bytes and the CRC32 or checksum bytes at the end of

21、 the section. The concept of DSM-CC section payload is used in the definition of the T-STD for the Synchronized Download protocol. ISO/IEC 13818-6:1998/Amd.3:2001(E) 2 ISO/IEC 2001 All rights reserved Table 9-7 DSM-CC Section Format Syntax No. of bits Mnemonic DSMCC_section() table_id 8 uimsbf secti

22、on_syntax_indicator 1 bslbfcomplement_indicator 1 bslbf reserved 2 bslbf section_length 12 uimsbf table_id_extension 16 uimsbf reserved 2 bslbf version_number 5 uimsbf current_next_indicator 1 bslbf section_number 8 uimsbf last_section_number 8 uimsbfDSM-CC section payload if(section_syntax_indicato

23、r = 0) checksum 32 uimsbf else CRC_32 32 rpchof DSM-CC section header bytes shall correspond to the first 8 bytes of the DSM-CC section (from the table_id field to the last_section_number field included) and the last 4 bytes of the section (checksum or CRC_32 field). The section payload bytes are th

24、e bytes starting immediately following the last_section_number field and up to the field immediately preceding the checksum or CRC_32 field. A DSM-CC section payload includes a Download message header and a Download message. In the case of a Download Control message (table_id 0x3B), the message head

25、er is a dsmccMessageHeader structure. In the case of a Download Data message (table_id 0x3C), the message header is a dsmccDownloadDataHeader structure and the Download message is a DownloadDataBlock message. The payload of a DownloadDataBlock message shall be referenced as the Download data message

26、 payload. The payload of the DownloadDataBlock message shall not include the moduleId, moduleVersion, reserved and blockNumber fields at the beginning of the message. The Download Data Message payload represents a portion of a synchronized data module. 9.2.9.3 Data module channels The secondary mult

27、iplexing/de-multiplexing stage operates on the table_id_extension fields of DSM-CC sections with table_id value 0x3C. DSM-CC sections conveying other messages (like the DownloadInfoIndication message) may be conveyed in the same program element. It is only in the case of table_id equal to 0x3C that

28、the table_id_extension field values are used to identify the data module channels. The Transport System Target Decoder buffer model for synchronized data elementary streams includes a Transport Buffer, a Smoothing Buffer and a Data Module Buffer. The purpose of the Data Module buffer is to allow for

29、 the re-assembly of the synchronized data modules before they are decoded and presented in the receiver. 9.2.9.4 Transport system target decoder buffer model Complete Transport Stream packets containing data from program element n of stream_type 0x14 are passed to the transport buffer for program el

30、ement n, TBn. The size of TBn is fixed and equal to 512 bytes. This includes duplicate Transport Stream packets and packets with no payloads. Transfer of any data from the System Target Decoder input to TBn is considered instantaneous. All data that enter TBn are removed from TBn at a rate RXn. When

31、 there are no data in TBn, the rate RXn is equal to 0. Bytes that are part of a DSM-CC section are delivered to the Smoothing buffer SBn. Other bytes are not and may be used to control the system. Duplicate Transport Stream packets are not delivered to SBn. All bytes enter SBn ISO/IEC 13818-6:1998/A

32、md.3:2001(E) ISO/IEC 2001 All rights reserved 3instantaneously upon leaving the buffer TBn. All bytes that enter the smoothing buffer SBn leave the smoothing buffer SBn. The data module stream bytes in buffer SBn are all delivered to their associated data module buffer at the rate sb_leak_n. The val

33、ue of sb_leak_n is either defined implicitly or listed explicitly in the ISO/IEC 13818-1 smoothing_buffer_descriptor. The value of the leak rate may follow the classification specified in Table 7-13 of Section 7.5.5 of this specification. The size of SBn, SBSn, is implicitly declared or listed expli

34、citly in the ISO/IEC 13818-1 smoothing_buffer_descriptor. Only synchronized data module data bytes (bytes of a Download data message payload) in data module k of program element n enter the data module buffer DMBnk. If there is DSM-CC section data in SBn and buffer DMBnk is not full, the data is tra

35、nsferred from SBn to DMBnk at a rate defined by sb_leak_n. When there is no DSM-CC section data in SBn, no data is removed from SBn. Bytes from a DSM-CC section header are removed instantaneously and discarded and may be used to control the system. Bytes from a DSM-CC section CRC_32 field or checksu

36、m field that immediately follow the last data module byte in the DSM-CC section payload are removed instantaneously and discarded and may be used to verify the integrity of the data. Bytes from the dsmccDownloadDataHeader message header and the first 6 bytes of the DownloadDataBlock message (represe

37、nting the moduleId, moduleVersion, reserved and blockNumber fields of the message) are discarded and may be used to control the system. Bytes from the payload of a DSM-CC section with a table_id value other than 0x3C are taken out of buffer SBn at rate sb_leak_n. These bytes are subsequently discard

38、ed and may be used to control the system. All bytes that enter the smoothing buffer SBn leave it. All data module bytes of data module stream n enter the data module de-multiplexer instantaneously upon leaving SBn. The size of the buffer DMBnk is DMBSnk. The value of DMBSnk shall be at least equal t

39、o the largest size that synchronized module k can take in program element n. In buffer DMBnk, the synchronized data modules shall be reconstructed from the in-order concatenation of the DownloadDataBlock data message payloads as indicated by the section_number field of the DSM-CC section headers. Th

40、e DSM-CC sections conveying a synchronized data module are identified by unique table_id, table_id_extension and version_number values. For the Data Elementary Buffer DMBnk, all data for the data module that has been in the buffer longest are removed instantaneously at time td_nk. The Decoding time

41、td_nk may be specified by the Presentation Time Stamp located in the adaptation field of the dsmccDownloadDataMessageHeader in the first section (section_number 0x00) conveying the synchronized data module and a Data Module Decode Time (DMDT) common to all data modules in the program element n. The

42、value of DMDT may be signaled in the MPEG-2 Transport Stream (e.g., in the moduleInfoBytes in the DowloadInfoIndication message). Alternatively, the value of td_nk may be equal to the PTS of the previous data module in the data module channel when the value of DMDT is not specified. The presentation

43、 data unit resulting from decoding the data module is presented at the instant specified by the PTS field associated with the synchronized data module. Buffer TBn shall not overflow. Buffer SBn shall not overflow. Buffer DMBnk shall not overflow nor underflow. Underflow of DMBnk occurs when one or m

44、ore bits of the data module is not present in DMBnk at the Data Module Decode Time associated with the data module. In the example shown in Figure 9-1 below, three synchronized or synchronous data elementary streams, nk, nj and nh, multiplexed within the same program element referenced by PID value

45、0x0FDA. To the right of the smoothing buffer SBn, a secondary de-multiplexing operates on the table_id_extension field to route the data module bytes to their respective data module channels. A collection of synchronized data streams is conveyed in MPEG sections where table_id is equal to 0x3C and t

46、able_id_extension is equal to 0xABCD, 0x9876 and 0x1122. Each value of the table_id_extension field identifies the secondary channel on which a data elementary sub-stream is being conveyed. Figure 9-1 also shows three synchronized or synchronous data elementary streams mk, mj and mh multiplexed in t

47、he MPEG-2 program element referenced by PID value 0x1753 and in MPEG sections with table_id field value equal to 0x3C. The following notation is used in Figure 9-1: TBnis the transport buffer. SBnis the smoothing buffer for program element n. DMBnkis the data module buffer for data module channel k

48、of program element n. Rxnis the rate at which data is removed from TBn. sb_leaknis the rate at which data is removed from SBn. Ank(j) is the jthaccess unit for data module channel k of program element n. tdnk(j) is the decoding time in the system target decoder of the jth access unit in data module

49、channel k of program element n. ISO/IEC 13818-6:1998/Amd.3:2001(E) 4 ISO/IEC 2001 All rights reserved tpnk(j) is the presentation time in the system target decoder of the jth access unit in data module channel k of program element n. t(i) indicates the time in seconds at which the ithbyte of the Transport Stream enters the system target decoder. Figure 9-1 T-STD for DSM-CC Synchronized Download Protocol TBn SBn DMBnk Transport Stream (PID-based) de- multiplexer MPEG section de-multiplexer (table_id_extension-based) T-STD i