1、BRITISH STANDARD Information technology - Generic coding of moving pictures and associated audio information Part 1. Systems * * m The European Standard EN ISO/IEC 138181 : 1997 has the status of a British Standard ICs 35.040 BS EN ISOAEC 13818-1 : 1997 ncorpomting 4menmt No. 1 to 5s ISOIEC 1381 8 :
2、 Part 1 : 1996 (maumbers BS as BS EN ISOLEC 13818-1 : 1997) NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW - - STD-BSI BS EN ISO/IEC L3L-1-ENGL 1995 = Lb24bb9 Ob4L25L 239 BS EN ISOAEC 13818-1 : 1997 hue 2, September 1997 AmdNo. Date This British Stadd having been prepad under
3、 the direction of UieDiSCJjoard, was published under the authority of the Standards Roard and comes into enecton 16 April 1997 O BSI 1997 Text affected National foreword 9625 This British Standard has been prepared by Technical Conunittee ISTB7 and is the English anguage version of EN ISO/IEC 13818
4、infomiation technology - Generic coding of moving pictures and associated audio information Part 1: Systems published by the European Conunittee for Standardization (CEN). It is identica with ISO/IEC 138181 : 1996 published by the Intemational Organization for Standadbation O) and the Intemational E
5、lectrotechnical Commission mC). The UK participation in its preparation was entrusted ta chnid Commiee IsTB7, Coding of picture, audio, multimedia and hypemedia infoon, which has the responsibility to: September 1997 Indicated by a sideline in the margin - aidenquimstounderstandthetext; - priesent t
6、o the nsponsible intemaionaUEumpean committee any enquiries on the inkxpretaion, or proposais for change, and keep the IJK interests iIIf0 - monitor related intemationai and European developments and promulgate themintheuK. A list of oqpnimtions represented on this commiUee can be obtained on reques
7、t. Cross-references The British standards which implement intemational or European publicaiions referred to in this document may be found in the ES1 Standards catalogue under the section entied Internalional slandards Correspondence index, or using the Find fo of the BSI standards Electronic catalog
8、ue. Compliance with a British Standard does not of itself confer immunity from legal obligations. Summary of pages This document comprises a front cover, an inside front cover, the Iso/IEC tie page, pages ii to xv, abankpage, page 1 to 119 and aback cover. STD.BS1 BS EN ISOIIEC L3818-L-ENGL 1975 Lb2
9、LibbS Ob41252 175 Issue 1, September 1997 BS EN ISO/IEC 1381-1 : 1997 1 Page I Issue Summary of pages The foilowing table identities the current issue of each page. Issue 1 indicates that a page has been introduced for the first time by amendment. Subsequent issue numbers indicate an updated page. V
10、ertical sidelining on replacement pages indicates the most recent changes (amendment, addition, deletion). Page Front cover Inside front cover a b EN title page ii Issue 2 2 1 blank 1 1 IS0 title page ii-xv 1 - 119 120 Inside back cover Back cover original original Original blank blank 2 Change of i
11、dentifier Wherever BS ISO/IEC 13818 : Part 1 : 1996 appears in this standard, it should be read as BS EN ISO/IEC 138181 : 1997. * * cn O BSI 1997 STD-BSI BS EN ISOIIEC 13818-1-ENGL 1775 Lb24bb Ob91253 001 EUROPEAN STANDARID EN ISo/IEC 1381 however, one is not a subset or superset of the other. In pa
12、rticular. extracting the contents of a program from a Transport Stream and creating a valid Program Stream is possible and is accomplished through the common interchange formai of PES packets, but not all of the fields needed in a Program Stream are contained within the Transport Stream; some must b
13、e derived. The Transport Stream may be used to span a range of layers in a layered model, and is designed for efficiency and ease of implementation in high bandwidth applications. The scope of syntactical and semantic rules set forth in the systems specification differ: the syntactical rules apply t
14、o systems layer coding only, and do not extend to the compression layer coding of the video and audio specifications; by contrast, the semantic rules apply to the combined stream in its entirety. The systems specification does not specify the architecture or implementation of encoders or decoders, n
15、or those of multiplexors or demultiplexors. However, bit stream properties do impose functional and performance requirements on encoders, decoders, multiplexors and demultiplexors. For instance, encoders must meet minimum clock tolerance requirements. Notwithstanding this and other requirements, a c
16、onsiderable degree of freedom exists in the design and implementation of encoders, decoders, multiplexors, and demultiplexors. _I II E - m Intro. 1 Transport Stream E _I m The Transport Stream is a stream definition which is tailored for communicating or storing one or more programs of coded data ac
17、cording to ITU-T Rec. H.262 I ISO/LEC 13818-2 and ISO/IEC 13818-3 and other data in environments in which significant errors may occur. Such errors may be manifested as bit value errors or loss of packets. Transport Streams may be either fixed or variable rate. In either case the constituent element
18、ary streams may either be fixed or variable rate. The syntax and semantic constraints on the stream are identical in each of these cases. The Transport Stream rate is defined by the values and locations of Program Clock Reference (PCR) fields, which in general are separate PCR fields for each progra
19、m. There are some difficulties with constructing and delivering a Transport Stream containing multiple programs with independent time bases such that the overall bit rate is variable. Refer to 2.4.2.2. * * The Transport Stream may be constructed by any method that results in a valid stream. It is po
20、ssible to construct Transport Streams containing one or more programs from elementary coded data streams, from Program Streams, or from other Transport Streams which may themselves contain one or more programs. The Transport Stream is designed in such a way that several operations on a Transport Str
21、eam are possible with minimum effort. Among these are: 1) Retrieve the coded data from one program within the Transport Stream, decode it and present the decoded results as shown in Figure Intro. 2. Extract the Transport Stream packets from one program within the Transport Stream and produce as outp
22、ut a different Transport Stream with only that one program as shown in Figure Intro. 3. Extract the Transport Stream packets of one or more programs from one or more Transport Streams and produce as output a different Transport Stream (not illustrated). Extract the contents of one program from the T
23、ransport Stream and produce as output a Program Stream containing that one program as shown in Figure Intro. 4. Take a Program Stream, convert it into a Transport Stream to carry it over a lossy environment, and then recover a valid, and in certain cases, identical Program Stream. 2) 3) 4) 5) ix STD
24、*BSI BS EN ISOIIEC L3BLB-L-ENGL 1775 m Lb24bb7 Ob41264 777 m BS ISOAEC 13818-1 : 1996 Channel chmnelspealic Figure Intro. 2 and Figure Intro. 3 illustrate prototypical demultiplexing and decoding systems which take as input a Transport Stream. Figure Intro. 2 illustrates the first case, where a Tran
25、sport Stream is directly demultiplexed and decoded. Transpon Streams are constructed in two layers: - Ckck miel Transpat Stream danUltipkU anddecoder , - - a system layer; and I c TiruispatStm I ccntaining ma cf muipie progm - a compression layer. Audio DeCaded decoder audio R5057709Yd The input str
26、eam to the Transport Stream decoder has a system layer wrapped about a compression layer. Input streams to the Video and Audio decoders have only the compression layer. Operations performed by the prototypical decoder which accepts Transport Streams either apply to the entire Transport Stream (“mult
27、iplex-wide operations”), or to individual elementary streams (“stream-specific Operations”). The Transport Stream system layer is divided into two sub-layers, one for multiplex-wide operations (the Transport Sueam packet layer), and one for stream-specific operations (the PES packet layer). A protot
28、ypical decoder for Transport Streams, including audio and video, is also depicted in Figure Intro. 2 to illustrate the function of a decoder. The architecture is not unique - some system decoder functions, such as decoder timing control, might equally well be distributed among elementary stream deco
29、ders and the channel specific decoder - but this figure is useful for discussion. Likewise, indication of errors detected by the channel specific decoder to the individual audio and video decoders may be performed in various ways and such communication paths are not shown in the diagram. The prototy
30、pical decoder design does not imply any normative requirement for the design of a Transport Stream decoder. Indeed non-audiolvideo data is also allowed, but not shown. Figue Intro. 2 - Prototypicai transport dernuitipiexhg and decoding example Figure Intro. 3 illustrates the second case, where a Tra
31、nsport Stream containing multiple programs is converted into a Transport Stream containing a single program. In this case the re-multiplexing operation may necessitate the correction of Rogram Clock Reference (PCR) values to account for changes in the FCR locations in the bit stream. Transpat Strm c
32、ontaining mitipie programs Figure Intro. 3 - Protatypiu transport multiplexing example STD-BSI BS EN ISO/IEC L38LB-L-ENGL 1775 m Lb2qbbS ObllL2b5 823 BS ISO/IEC 13818-1 : 1996 Channel . Figure Intro. 4 illustrates a case in which an multi-program Transport Stream is first demultiplexed and then conv
33、erted into a Program Stream. i 1 Channelspeclk . Programstream _c Chock decoder decoder Figures Intro. 3 and Intro. 4 indicate that it is possible and reasonable to convert between different types and configurations of Transport Streams. There are specific fields defined in the Transport Stream and
34、Program Stream syntax which facilitate the conversions illustrated. There is no requirement that specific implementations of demultiplexors or decoders include all of these functions. i Figure intra 4 - protdypical Transport Stream to Program Stream conversion Intro. 2 Program Stream The Program Str
35、eam is a stream definition which is tailored for communicating or storing one program of coded data and other data in environments where errors are very unlikely, and where processing of system coding, e.g. by software, is a major consideration. Program Streams may be either fixed or variable rate.
36、In either case, the constituent elementary streams may be either fixed or variable rate. The syntax and semantics constraints on the stream are identical in each case. The Program Stream rate is defined by the values and locations of the System Clock Reference (SCR) and mux-rate fields. A prototypic
37、al audiohidm Program Stream decoder system is depicted in Figure Intro. 5. The architecture is not unique - system decoder functions including decoder timing control might equally well be distributed among elementary stream decoders and the channel specific decoder - but this figure is useful for di
38、scussion. The prototypical decoder design does not imply any normative requirement for the design of an Program Stream decoder. Indeed non-audiohide0 data is also allowed, but not shown. Figure Intro. 5 - Prototypical decoder for Program Stream xi STD.BSI BS EN ISO/IEC 13818-1-ENGL 1775 m 1b24bb7 b4
39、12bb 7bT m BS ISO/IEC 13818-1 : 1996 The prototypical decoder for Program Streams shown in Figure Intro. 5 is composed of System, Video, and Audio decoders conforming to Parts 1, 2. and 3. respectively, of ISO/IEC 13818. In this decoder, the multiplexed coded representation of one or more audio and/
40、or video streams is assumed to be stored or communicated on some channel in some channel-specific format. The channel-specific format is not governed by this Recommendation I International Standard. nor is the channel-specific decoding part of the prototypical decoder. The prototypical decoder accep
41、ts as input a Program Stream and relies on a Program Stream Decoder to extract timing information from the stream. The Program Stream Decoder demultiplexes the stream, and the elementary streams so produced serve as inputs to Video and Audio decoders, whose outputs are decoded video and audio signal
42、s. Included in the design, but not shown in the figure, is the flow of timing information among the Program Stream decoder, the Video and Audio decoders, and the channel-specific decoder. The Video and Audio decoders are synchronized with each other and with the channel using this timing information
43、. Program Streams are constructed in two layers: a system layer and a compression layer. The input stream to the Program Stream Decoder has a system layer wrapped about a compression layer. Input streams to the Video and Audio decoders have only the compression layer. Operations performed by the pro
44、totypical decoder either apply to the entire Program Stream (?multiplex-wide operations*?), or to individual elementary streams (?stream-specific operations*). The Program Stream system layer is divided into two sub-layers, one for multiplex-wide operations (the pack layer), and one for stream-speci
45、fic operations (the PES packet layer). Intro. 3 It may be possible and reasonable to convert between Transport Streams and Program Streams by means of PES packets. This results from the specification of Transport Stream and Program Stream as embodied in 2.4.1 and 2.5.1 of the normative requirements
46、of this Recommendation I Intemational Standard. PES packets may, with some constraints, be mapped directly from the payload of one multiplexed bit stream into the payload of another multiplexed bit stream. It is possible to identify the correct order of PES packets in a program to assist with this i
47、f the programjacket-sequence-counter is present in ali PES packets. Certain other information necessary for conversion, e.g. the relationship between elementary streams, is available in tables and headers in both streams. Such data, if available, shall be correct in any stream before and after conve
48、rsion. Conversion between Transport Stream and Program Stream Intro. 4 Packetized Elementary Stream Transport Streams and Program Streams are each logically constructed from PES packets, as indicated in the syntax definitions in 2.4.3.6. PES packets shall be used to convert between Transport Streams
49、 and Program Streams; in some cases the PES packets need not be modified when performing such conversions. PES packets may be much larger than the size of a Transport Stream packet. A continuous sequence of PES packets of one elementary stream with one stream ID may be used to construct a PES Stream. When PES packets are used to form a PES stream, they shall include Elementary Stream Clock Reference (ESCR) fields and Elementary Stream Rate (ES-Rate) fields, with constraints as defined in 2.4.3.8. The PES stream data shall be contiguous by
