Iso-Iec 13818-4

INTERNATIONAL ORGANISATION FOR STANDARDISATION
ORGANISATION INTERNATIONALE DE NORMALISATION

ISO/IEC JTC1/SC29/WG11
CODING OF MOVING PICTURES AND ASSOCIATED AUDIO
ISO/IEC JTC1/SC29/WG11 N0804

11 November 1994 (Singapore)
Compliance
INFORMATION TECHNOLOGY -
GENERIC CODING OF MOVING PICTURES AND
ASSOCIATED AUDIO
ISO/IEC 13818-4
Committee Draft
7/30/2002 9:12 PM
ISO/IEC 13818-4 Compliance (Committee Draft)
Page ii of 100 July 30, 2002
CONTENTS
1. CONTENTS ..................................................................................................................................ii
2. INTRODUCTION..........................................................................................................................vi
3. SCOPE..........................................................................................................................................7
4. NORMATIVE REFERENCES.......................................................................................................7
5. DEFINITIONS ...............................................................................................................................9
6. ABBREVIATIONS AND SYMBOLS...........................................................................................20

6.1 ARITHMETIC OPERATORS .............................................................................................................20
6.2 LOGICAL OPERATORS ...................................................................................................................20
6.3 RELATIONAL OPERATORS .............................................................................................................20
6.4 BITWISE OPERATORS ...................................................................................................................20
6.5 ASSIGNMENT ...............................................................................................................................21
6.6 MNEMONICS ................................................................................................................................22
6.7 CONSTANTS ................................................................................................................................23
7. BITSTREAM CHARACTERISTICS............................................................................................24
7.1 SYSTEM BITSTREAMS ...................................................................................................................24
7.1.1 General System bitstream characteristics..........................................................................24
7.1.2 Transport Stream specific characteristics ..........................................................................24
7.1.3 Program Stream specific characteristics............................................................................25
7.2 VIDEO BITSTREAMS ......................................................................................................................26
7.2.1 Main Profile compliance bitstreams ...................................................................................26
7.2.2 SNR Profile compliance bitstreams....................................................................................28
7.2.3 Spatial Profile compliance bitstreams ................................................................................28
7.2.4 Compliance bitstream characteristics ................................................................................28
7.3 AUDIO BITSTREAMS ......................................................................................................................30
7.3.1 Descriptions of the ISO/IEC 13818 (MPEG) audio test bitstreams....................................31
8. DECODER CHARACTERISTICS...............................................................................................37
8.1 GENERAL SYSTEM DECODER CAPABILITIES ...................................................................................37
8.1.1 Introduction.........................................................................................................................37
8.1.2 Handling of decoder discontinuities (mandatory)...............................................................37
8.1.3 Presentation synchronization (mandatory) ........................................................................38
8.1.4 Support of variable bitrate within a program (mandatory)..................................................38
8.1.5 General capabilities for program acquisition (mandatory) .................................................39
8.1.6 Private data handling (mandatory) .....................................................................................40
8.1.7 Support of Trick Modes (optionally) ...................................................................................41
8.1.8 DECODER CHARACTERISTICS BEYOND COMPLIANCE .............................................42
8.2 VIDEO DECODERS ........................................................................................................................44
8.3 AUDIO DECODERS ........................................................................................................................45
8.3.1 Extension of ISO/IEC 11172-3 Audio Coding to Lower Sampling Frequencies ................45
8.3.2 Low bit rate coding of Multichannel Audio..........................................................................45
9. PROCEDURES TO TEST BITSTREAM COMPLIANCE...........................................................48
9.1 SYSTEMS BITSTREAM TESTS .........................................................................................................48
9.1.1 Tests on Transport .............................................................................................................48
9.1.2 System bitstream tests for Program Stream ......................................................................66
9.1.3 Tests on timing accuracy....................................................................................................72
9.1.4 Buffer overflow/underflow test ............................................................................................73
9.2 VIDEO BITSTREAM TESTS..............................................................................................................77
9.2.1 Global tests of Profiles and Levels.....................................................................................77
ii
Page iii of 100 July 30, 2002
9.2.2 SNR Scalability Profile .......................................................................................................85

9.2.3 Spatial scalability Profile.....................................................................................................86
9.3 AUDIO BITSTREAM TESTS .............................................................................................................88
9.3.1 General tests ......................................................................................................................88
10. PROCEDURES TO TEST DECODER COMPLIANCE............................................................93
10.1 SYSTEM DECODER TESTS ...........................................................................................................93
10.2 VIDEO DECODER TESTS ..............................................................................................................93
10.2.1 statistical behaviour of decoders on conformance bitstreams .........................................93
10.3 AUDIO DECODER TESTS..............................................................................................................95
10.3.1 Calculation for RMS .........................................................................................................95
11. ANNEX A ..................................................................................................................................97
12. ANNEX B ..................................................................................................................................99

Page iv of 100 July 30, 2002
FOREWORD
The ITU-T (the ITU Telecommunication Standardisation Sector) is a permanent organ of the International
Telecommunications Union (ITU). The ITU-T is responsible for studying technical, operating and tariff
questions and issuing Recommendations on them with a view to developing telecommunication standards
on a world-wide basis.
The World Telecommunication Standardisation Conference, which meets every four years, establishes the
program of work arising from the review of existing questions and new questions among other things. The
approval of new or revised Recommendations by members of the ITU-T is covered by the procedure laid
down in the ITU-T Resolution No. 1 (Helsinki 1993). The proposal for Recommendation is accepted if
70% or more of the replies from members indicate approval.
ISO (the International Organisation for Standardisation) and IEC (the International Electrotechnical
Commission) form the specialised system for world-wide standardisation. National Bodies that are
members of ISO and IEC participate in the development of International Standards through technical
committees established by the respective organisation to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organisations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC
JTC1. 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.
This specification is a committee draft that is being submitted for approval to the ITU-T, ISO-IEC/JTC1
SC29. It was prepared jointly by SC29/WG11, also known as MPEG (Moving Pictures Expert Group), and
the Experts Group for ATM Video Coding in the ITU-T SG15. MPEG was formed in 1988 to establish
standards for coding of moving pictures and associated audio for various applications such as digital
storage media, distribution and communication. The Experts Group for ATM Video Coding was formed
in 1990 to develop video coding standard(s) appropriate for B-ISDN using ATM transport.
In this specification Annex A, Annex B and Annex C contain normative requirements and are an integral
part of this specification. Annex D, Annex E, Annex F and Annex G are informative and contain no
normative requirements.
iv
Page v of 100 July 30, 2002
ISO/IEC
This International Standard is published in four Parts.
13818-1 Systems specifies the system coding of the specification. It defines a multiplexed structure
for combining audio and video data and means of representing the timing
information needed to replay synchronised sequences in real-time.
13818-2 Video specifies the coded representation of video data and the decoding process
required to reconstruct pictures.
13818-3 Audio specifies the coded representation of audio data.
13818-4 Compliance specifies the procedures for determining the characteristics of coded bitstreams
and for testing compliance with the requirements stated in 13818-1, 13818-2 and
13818-3.
13818-5 Software provides software example of Parts 1, 2, and 3 of 13818.
v
Page vi of 100 July 30, 2002
Introduction
Parts 1, 2 and 3 of ISO/IEC 13818 specify a multiplex structure and coded representations of audiovisual
information. Parts 1, 2 and 3 of ISO/IEC 13818 allow for large flexibility, achieving suitability of this
International Standard for many different applications. The flexibility is obtained by including
parameters in the bitstream that define the characteristics of coded bitstreams. Examples are the audio
sampling frequency, picture size, picture rate and bitrate parameters.
This part of ISO/IEC 13818 specifies how tests can be designed to verify whether bitstreams and decoders
meet the requirements as specified in parts 1, 2 and 3 of ISO/IEC 13818. These tests can be used for
various purposes such as:
- manufacturers of encoders, and their customers, can use the tests to verify whether the encoder
produces valid bitstreams.
- manufacturers of decoders and their customers can use the tests to verify whether the decoder
meets the requirements specified in parts 1,2 and 3 of ISO/IEC 13818 for the claimed decoder
capabilities.
- applications can use the tests to verify whether the characteristics of a given bitstream meet the
application requirements, for example whether the size of the coded picture does not exceed the
maximum value allowed for the application.
vi
Page 7 of 100 July 30, 2002
INTERNATIONAL STANDARD 13818-4
ITU-T RECOMMENDATION H.262
INFORMATION TECHNOLOGY -
GENERIC CODING OF MOVING PICTURES AND ASSOCIATED AUDIO
Scope
This Recommendation | International Standard specifies the coded representation of picture information
for digital storage media and digital video communication and specifies the decoding process. The
representation supports constant bitrate transmission, variable bitrate transmission, random access, channel
hopping, scalable decoding, bitstream editing, as well as special functions such as fast forward playback,
fast reverse playback, slow motion, pause and still pictures. This Recommendation | International Standard
is forward compatible with ISO/IEC13818-2 and upward or downward compatible with EDTV, HDTV,
SDTV formats.
This Recommendation | International Standard is primarily applicable to digital storage media, video
broadcast and communication. The storage media may be directly connected to the decoder, or via
communications means such as busses, LANs, or telecommunications links.
Normative references
The following ITU-T Recommendations and International Standards contain provisions which through
reference in this text, constitute provisions of this Recommendation | International Standard. At the time of
publication, the editions indicated were valid. All Recommendations and Standards are subject to revision,
and parties to agreements based on this Recommendation | International Standard are encouraged to
investigate the possibility of applying the most recent editions of the standards indicated below. Members
of IEC and ISO maintain registers of currently valid International Standards. The TSB
(Telecommunication Standardisation Bureau) maintains a list of currently valid ITU-T Recommendations.
7
Page 8 of 100 July 30, 2002
Recommendations and reports of the CCIR, 1990
XVIIth Plenary Assembly, Dusseldorf, 1990 Volume XI - Part 1
Broadcasting Service (Television) Rec. 601-2 "Encoding parameters of digital television for
studios"
CCIR Volume X and XI Part 3 Recommendation 648: Recording of audio signals.
CCIR Volume X and XI Part 3 Report 955-2: Sound broadcasting by satellite for portable and
mobile receivers, including Annex IV Summary description of advanced digital system II.
ISO/IEC 11172 (1993) "Information technology Ñ Coding of moving picture and associated
audio for digital storage media at up to about 1,5 Mbit/s"
IEEE Standard Specifications for the Implementations of 8 by 8 Inverse Discrete Cosine
Transform, IEEE Std 1180-1990, December 6, 1990.
IEC Publication 908:198, "CD Digital Audio System"
IEC Standard Publication 461 Second edition, 1986 "Time and control code for video tape
recorders"
ITU-T Recommendation H.261 (Formerly CCITT Recommendation H.261) ÒCodec for
audiovisual services at px64 kbit/s" Geneva, 1990
ISO/IEC 10918-1 | ITU-T Rec. T.81 (JPEG) "Digital compression and coding of
continuous-tone still images"
8
Page 9 of 100 July 30, 2002
Definitions
For the purposes of this Recommendation | International Standard, the following definitions apply.
1. ac coefficient [video]: Any DCT coefficient for which the frequency in one or both dimensions is
non-zero.
2. AC coefficient: Any DCT coefficient for which the frequency in one or both dimensions is non-zero.
3. access unit [system]: A coded representation of a presentation unit. In the case of compressed audio
an access unit is an Audio Access Unit. In the case of compressed video an access unit is the coded
representation of a picture.
4. adaptive bit allocation [audio]: The assignment of bits to subbands in a time and frequency varying
fashion according to a psychoacoustic model.
5. adaptive multichannel prediction [audio]: A method of multichannel data reduction exploiting
statistical inter-channel dependencies.
6. adaptive noise allocation [audio]: The assignment of coding noise to frequency bands in a time and
frequency varying fashion according to a psychoacoustic model.
7. adaptive segmentation [audio]: A subdivision of the digital representation of an audio signal in
variable segments of time.
8. alias [audio]: Mirrored signal component resulting from sub-Nyquist sampling.
9. almost-compliant: decoder which does not pass all bitstream tests.
10. analysis filterbank [audio]: Filterbank in the encoder that transforms a broadband PCM audio signal
into a set of subsampled subband samples.
11. audio access unit [audio]: For Layers I and II, an audio access unit is defined as the smallest part of
the encoded bit stream which can be decoded by itself, where decoded means "fully reconstructed
sound". For Layer III, an audio access unit is part of the bit stream that is decodable with the use of
previously acquired main information.
12. audio buffer [audio]: A buffer in the system target decoder for storage of compressed audio data.
13. audio sequence [audio]: A non-interrupted series of audio frames in which the following parameters
are not changed:- ID- Layer- Sampling Frequency- For Layer I and II: Bitrate index
14. B-field picture [video]: A field structure B-Picture.
15. B-frame picture [video]: A frame structure B-Picture.
16. B-picture; bidirectionally predictive-coded picture [video]: A picture that is coded using motion
compensated prediction from past and/or future reference fields or frames.
17. backward compatibility: A newer coding standard is backward compatible with an older coding
standard if decoders designed to operate with the older coding standard are able to continue to operate
by decoding all or part of a bitstream produced according to the newer coding standard.
18. backward motion vector [video]: A motion vector that is used for motion compensation from a
reference picture at a later time in display order.
19. backward motion vector [video]: A motion vector that is used for motion compensation from a
reference frame or reference field at a later time in display order.
20. Bark [audio]: Unit of critical band rate. The Bark scale is a non-linear mapping of the frequency scale
over the audio range closely corresponding with the frequency selectivity of the human ear across the
band.
9
Page 10 of 100 July 30, 2002
21. bidirectionally predictive-coded picture; B-picture [video]: A picture that is coded using motion
compensated prediction from a past and/or future reference picture.
22. bitrate: The rate at which the coded bitstream is delivered from the storage medium to the input of a
decoder.
23. block [video]: An 8-row by 8-column matrix of samples, or 64 DCT coefficients (source, quantised
or dequantised).
24. block companding [audio]: Normalising of the digital representation of an audio signal within a
certain time period.
25. bottom field [video]: One of two fields that comprise a frame. Each line of a bottom field is spatially
located immediately below the corresponding line of the top field.
26. bound [audio]: The lowest subband in which intensity stereo coding is used.
27. byte aligned: A bit in a coded bitstream is byte-aligned if its position is a multiple of 8-bits from the
first bit in the stream.
28. byte: Sequence of 8-bits.
29. center channel [audio]: An audio presentation channel used to stabilise the central component of the
frontal stereo image.
30. channel [audio]: A sequence of data representing an audio signal being transported.
31. channel: A digital medium that stores or transports a CD 13818 bit stream.
32. chroma simulcast: A type of scalability (which is a subset of SNR scalability) where the
enhancement layer (s) contain only coded refinement data for the DC coefficients, and all the
data for the AC coefficients, of the chrominance components.
33. chrominance format [video]: Defines the number of chrominance blocks in a macroblock.
34. chrominance (component) [video]: A matrix, block or single pel representing one of the two colour
difference signals related to the primary colours in the manner defined in CCIR Rec 601. The symbols
used for the colour difference signals are Cr and Cb.
35. critical band rate [audio]: Psychoacoustic function of frequency. At a given audible frequency, it is
proportional to the number of critical bands below that frequency. The units of the critical band rate
scale are Barks.
36. coding parameters: The set of user-definable parameters that characterise a coded video bitstream.
Bitstreams are characterised by coding parameters. Decoders are characterised by the bitstreams that
they are capable of decoding.
37. coded audio bit stream [audio]: A coded representation of an audio signal as specified in this part of
the CD.[video]
38. coded B-frame [video]: A B-frame picture or a pair of B-field pictures.
39. coded frame [video]: A coded frame is a coded I-frame, a coded P-frame or a coded B-frame.
40. coded I-frame [video]: An I-frame picture or a pair of field pictures, where the first one is an I-picture
and the second one is an I-picture or a P-picture.
41. coded order [video]: The order in which the pictures are stored and decoded. This order is not
necessarily the same as the display order.
42. coded order [video]: The order in which the pictures are transmitted and decoded. This order is not
necessarily the same as the display order.
43. coded P-frame [video]: A P-frame picture or a pair of P-field pictures.
10
Page 11 of 100 July 30, 2002
44. coded picture [video]: A coded picture is made of a picture header, the optionnal extensions
immediately following it, and the following picture data. A coded picture may be a frame picture or
a field picture.
45. coded representation: A data element as represented in its encoded form.
46. coded video bit stream [video]: A coded representation of a series of one or more pictures as
specified in this CD.
47. coding parameters [video]: The set of user-definable parameters that characterise a coded video bit
stream. Bit streams are characterised by coding parameters. Decoders are characterised by the bit
streams that they are capable of decoding.
48. component [video]: A matrix, block or single pel from one of the three matrices (luminance and two
chrominance) that make up a picture.
49. component [video]: A matrix, block or single sample from one of the three matrices (luminance and
two chrominance) that make up a picture.
50. compression: Reduction in the number of bits used to represent an item of data.
51. constant bitrate coded video [video]: A compressed video bit stream with a constant average bitrate.
52. constant bitrate: Operation where the bitrate is constant from start to finish of the coded bitstream.
53. constrained parameters [video]: The values of the set of coding parameters defined in 2.4.3.2 of
ISO/IEC 11172-2.
54. constrained system parameter stream (CSPS) [system]: An ISO/IEC 11172 multiplexed stream for
which the constraints defined in 2.4.6 of ISO/IEC 11172-1 apply.
55. CRC: The Cyclic Redundancy Check to verify the correctness of data.
56. critical band [audio]: Psychoacoustic measure in the spectral domain which corresponds to the
frequency selectivity of the human ear. This selectivity is expressed in Bark.
57. D-Picture [video]: A type of picture that shall not be used except in ISO/IEC 11172-2.
58. data element: An item of data as represented before encoding and after decoding.
59. data partitioning: A method for dividing a bitstream into two separate bitstreams for error
resilience purposes. the two bitstreams have to be recombined before decoding.
60. DC coefficient: The DCT coefficient for which the frequency is zero in both dimensions.
61. dc-coded picture; D-picture [video]: A picture that is coded using only information from itself. Of
the DCT coefficients in the coded representation, only the dc-coefficients are present.
62. dc-coefficient [video]: The DCT coefficient for which the frequency is zero in both dimensions.
63. DCT coefficient: The amplitude of a specific cosine basis function.
64. de-emphasis [audio]: Filtering applied to an audio signal after storage or transmission to undo a
linear distortion due to emphasis.
65. decoded stream: The decoded reconstruction of a compressed bit stream.
66. decoder input buffer [video]: The first-in first-out (FIFO) buffer specified in the video buffering
verifier.
67. decoder input rate [video]: The data rate specified in the video buffering verifier and encoded in the
coded video bit stream.
68. decoder: An embodiment of a decoding process.
69. decoding (process): The process defined in this specification that reads an input coded bitstream and
produces decoded pictures or audio samples.
11
Page 12 of 100 July 30, 2002
70. decoding time-stamp; DTS [system]: A field that may be present in a PES packet header that
indicates the time that an access unit is decoded in the system target decoder.
71. dequantisation [video]: The process of rescaling the quantised DCT coefficients after their
representation in the bit stream has been decoded and before they are presented to the inverse DCT.
72. dequantisation: The process of rescaling the quantised DCT coefficients after their representation in
the bitstream has been decoded and before they are presented to the inverse DCT.
73. digital storage media; DSM: A digital storage or transmission device or system.
74. discrete cosine transform; DCT: Either the forward discrete cosine transform or the inverse discrete
cosine transform. The DCT is an invertible, discrete orthogonal transformation. The inverse DCT
is defined in Annex A of this specification.
75. display order [video]: The order in which the decoded pictures should be displayed. Normally this is
the same order in which they were presented at the input of the encoder.
76. downmix [audio]: A matrixing of n channels to obtain less than n channels.
77. dual channel mode [audio]: A mode, where two audio channels with independent programme
contents (e.g. bilingual) are encoded within one bit stream. The coding process is the same as for the
stereo mode.
78. dynamic crosstalk [audio]: A method of multichannel data reduction in which stereo-irrelevant
signal components are copied to another channel.
79. dynamic transmission channel switching [audio]: A method of multichannel data reduction by
allocating the most orthogonal signal components to the transmission channels.
80. editing: The process by which one or more compressed bit streams are manipulated to produce a new
compressed bit stream. Conforming edited bit streams must meet the requirements defined in this CD.
81. elementary stream; ES [system]: A generic term for one of the coded video, coded audio or other
coded bit streams.
82. emphasis [audio]: Filtering applied to an audio signal before storage or transmission to improve the
signal-to-noise ratio at high frequencies.
83. encoder: An embodiment of an encoding process.
84. encoding (process): A process, not specified in this specification, that reads a stream of input pictures
or audio samples and produces a valid coded bitstream as defined in this specification.
85. entitlement control message; ECM: Entitlement Control Messages are private conditional access
information which specify control words and possibly other, typically stream-specific, scrambling and
and/or control parameters.
86. entitlement management message; EMM: Entitlement Management Messages are private
conditional access information which specify the authorization levels or the services of specific
decoders. They may be addressed to single decoders or groups of decoders.
87. entropy coding: Variable length lossless coding of the digital representation of a signal to reduce
redundancy.
88. evil bitstreams: bitstreams orthogonal to reality.
89. fast reverse playback: The process of displaying the picture sequence in the reverse of display
order faster than real-time.
90. fast forward playback [video]: The process of displaying a sequence, or parts of a sequence, of
pictures in display-order faster than real-time.
12
Page 13 of 100 July 30, 2002
91. FFT: Fast Fourier Transformation. A fast algorithm for performing a discrete Fourier transform (an
orthogonal transform).
92. field [video]: For an interlaced video signal, a ÒfieldÓ is the assembly of alternate lines of a frame.
Therefore an interlaced frame is composed of two fields, a top field and a bottom field.
93. field period [video]: The reciprocal of twice the frame rate.
94. field picture; field structure picture [video]: A field structure picture is a coded picture with
picture_structure is equal to "Top field" or "Bottom field".
95. filterbank [audio]: A set of band-pass filters covering the entire audio frequency range.
96. fixed segmentation [audio]: A subdivision of the digital representation of an audio signal into fixed
segments of time.
97. flag: A variable which can take one of only the two values defined in this specification.
98. forbidden: The term "forbidden" when used in the clauses defining the coded bit stream indicates that
the value shall never be used. This is usually to avoid emulation of start codes.
99. forced updating [video]: The process by which macroblocks are intra-coded from time-to-time to
ensure that mismatch errors between the inverse DCT processes in encoders and decoders cannot build
up excessively.
100.forward compatibility: A newer coding standard is forward compatible with an older coding
standard if decoders designed to operate with the newer coding standard are able to decode bitstreams
of the older coding standard.
101.forward motion vector [video]: A motion vector that is used for motion compensation from a
reference picture at an earlier time in display order.
102.frame [audio]: A part of the audio signal that corresponds to audio PCM samples from an Audio
Access Unit.
103.frame [video]: A frame contains lines of spatial information of a video signal. For progressive video,
these lines contain samples starting from one time instant and continuing through successive lines to
the bottom of the frame. For interlaced video a frame consists of two fields, a top field and a bottom
field. One of these fields will commence one field period later than the other.
104.frame period: The reciprocal of the frame rate.
105.frame picture; frame structure picture [video]: A frame structure picture is a coded picture with
picture_structure is equal to "Frame".
106.frame rate: The rate at which frames are be output from the decoding process.
107.free format [audio]: Any bitrate other than the defined bitrates that is less than the maximum valid
bitrate for each layer.
108.future reference frame (field): A future reference frame(field) is a reference frame(field) that
occurs at a later time than the current picture in display order.
109.future reference picture [video]: The future reference picture is the reference picture that occurs at a
later time than the current picture in display order.
110.granules [Layer III] [audio]: 576 frequency lines that carry their own side information.
111.group of pictures [video]: A series of one or more coded pictures intended to assist random access.
The group of pictures is one of the layers in the coding syntax defined in ISO/IEC 13818-2.
112.Hann window [audio]: A time function applied sample-by-sample to a block of audio samples before
Fourier transformation.
13
Page 14 of 100 July 30, 2002
113.header: A block of data in the coded bitstream containing the coded representation of a number of
data elements pertaining to the coded data that follow the header in the bitstream.
114.Huffman coding: A specific method for entropy coding.
115.hybrid filterbank [audio]: A serial combination of subband filterbank and MDCT.
116.hybrid scalability: Hybrid scalability is the combination of two (or more) types of scalability.
117.I-field picture [video]: A field structure I-Picture.
118.I-frame picture [video]: A frame structure I-Picture.
119.I-picture; intra-coded picture [video]: A picture coded using information only from itself.
120.IMDCT [audio]: Inverse Modified Discrete Cosine Transform.
121.intensity stereo [audio]: A method of exploiting stereo irrelevance or redundancy in stereophonic
audio programmes based on retaining at high frequencies only the energy envelope of the right and
left channels.
122.interlace [video]: The property of conventional television frames where alternating lines of the frame
represent different instances in time. In an interlaced frame, one of the field is meant to be displayed
first. This field is called the first field. The first field can be the top field or the bottom field of the
frame.
123.intra coding [video]: Coding of a macroblock or picture that uses information only from that
macroblock or picture.
124.intra-coded picture; I-picture [video]: A picture coded using information only from itself.
125.ISO/IEC 11172 (multiplexed) stream [system]: A bit stream composed of zero or more elementary
streams combined in the manner defined in ISO/IEC 11172-1.
126.ISO/IEC 13818 (multiplexed) stream [system]: A bit stream composed of 0 or more elementary
streams combined in the manner defined in Part 1 of this Recommendation | International Standard.
127.joint stereo coding [audio]: Any method that exploits stereophonic irrelevance or stereophonic
redundancy.
128.joint stereo mode [audio]: A mode of the audio coding algorithm using joint stereo coding.
129.layer [audio]: One of the levels in the coding hierarchy of the audio system defined in this part of the
CD.
130.layer [video and systems]: One of the levels in the data hierarchy of the video and system
specifications defined in Part 1 and Part 2.
131.level : A defined set of constraints on the values which may be taken by the parameters of this
specification within a particular profile. A profile may contain one or more levels.
132.low frequency enhancement channel [audio]: A limited bandwidth channel for low frequency audio
effects in a multichannel system.
133.luminance (component) [video]: A matrix, block or single pel representing a monochrome
representation of the signal and related to the primary colours in the manner defined in CCIR Rec 601.
The symbol used for luminance is Y.
134.macroblock [video]: The four 8 by 8 blocks of luminance data and the two (for 4:2:0 chrominance
format), four (for 4:2:2 chrominance format) or eight (for 4:4:4 chrominance format)
corresponding 8 by 8 blocks of chrominance data coming from a 16 by 16 section of the luminance
component of the picture. Macroblock is sometimes used to refer to the sample data and sometimes
to the coded representation of the sample values and other data elements defined in the macroblock
header of the syntax defined in this part of this specification. The usage is clear from the context.
14
Page 15 of 100 July 30, 2002
135.mapping [audio]: Conversion of an audio signal from time to frequency domain by subband filtering
and/or by MDCT.
136.masking [audio]: A property of the human auditory system by which an audio signal cannot be
perceived in the presence of another audio signal .
137.masking threshold [audio]: A function in frequency and time below which an audio signal cannot be
perceived by the human auditory system.
138.MDCT [audio]: Modified Discrete Cosine Transform which corredpond to the Time Domain Aliasing
Cancellation Filter Bank.
139.motion compensation [video]: The use of motion vectors to improve the efficiency of the rediction of
sample values. The prediction uses motion vectors to provide offsets into the past and/or future
reference frames or reference fields containing previously decoded sample values that are used to form
the prediction error signal.
140.motion estimation [video]: The process of estimating motion vectors during the encoding process.
141.motion vector [video]: A two-dimensional vector used for motion compensation that provides an
offset from the coordinate position in the current picture to the coordinates in a reference picture.
142.MS stereo [audio]: A method of exploiting stereo irrelevance or redundancy in stereophonic audio
programmes based on coding the sum and difference signal instead of the left and right channels.
143.multichannel [audio]: A combination of audio channels used to create a spatial sound field.
144.multilingual [audio]: A presentation of dialogue in more than one language.
145.non-intra coding [video]: Coding of a macroblock or picture that uses information both from itself
and from macroblocks and pictures occurring at other times.
146.non-tonal component [audio]: A noise-like component of an audio signal.
147.Nyquist sampling: Sampling at or above twice the maximum bandwidth of a signal.
148.P-field picture [video]: A field structure P-Picture.
149.P-frame picture [video]: A frame structure P-Picture.
150.P-picture; predictive-coded picture [video]: A picture that is coded using motion compensated
prediction from past reference fields or frame.
151.pack [system]: A pack consists of a pack header followed by zero or more packets. It is a layer in
the system coding syntax described in clause Error! Reference source not found. on page Error!
Bookmark not defined. this Recommendation | International Standard.
152.packet [system]: A packet consists of a header followed by a number of contiguous bytes from an
elementary data stream. It is a layer in the system coding syntax described in clause [XX] of this
Recommendation | International Standard.
153.packet data [system]: Contiguous bytes of data from an elementary stream present in a packet.
154.packet header [system]: The data structure used to convey information about the elementary stream
data contained in the packet data.
155.packet identifier; PID [system]: A unique integer value used to associate elementary streams of a
program in a single or multi-program Transport Stream as described in [XXXX]
156.padding [audio]: A method to adjust the average length of an audio frame in time to the duration of
the corresponding PCM samples, by conditionally adding a slot to the audio frame.
157.parameter: A variable within the syntax of this specification which may take one of a large range of
values. A variable which can take one of only two values is a flag and not a parameter.
158.past reference frame (field): A past reference frame(field) is a reference frame(field) that occurs at
an earlier time than the current picture in display order.
15
Page 16 of 100 July 30, 2002
159.past reference picture [video]: The past reference picture is the reference picture that occurs at an
earlier time than the current picture in display order.
160.pel [video]: Picture element.
161.pel aspect ratio [video]: The ratio of the nominal vertical height of pel on the display to its nominal
horizontal width.
162.PES [system]: An abbreviation for Packetized Elementary Stream.
163.PES packet [system]: The data structure used to carry elementary stream data. It consists of a PES
packet header followed by PES packet payload and is described in clause [XXX]
164.PES Stream [system]: A PES Stream consists of PES packets, all of whose payloads consist of data
from a single elementary stream, and all of which have the same stream_id. Specific semantic
constraints apply.
165.picture period [video]: The reciprocal of the picture rate.
166.picture rate [video]: The nominal rate at which pictures should be output from the decoding process.
167.picture: Source, coded or reconstructed image data. A source or reconstructed picture consists of
three rectangular matrices of 8-bit numbers representing the luminance and two chrominance signals.
For progressive video, a picture is identical to a frame, while for interlaced video, a picture can refer
to a frame, or the top field or the bottom field of the frame depending on the context.
168.polyphase filterbank [audio]: A set of equal bandwidth filters with special phase interrelationships,
allowing for an efficient implementation of the filterbank.
169.prediction [audio]: The use of a predictor to provide an estimate of the subband sample in one
channel from the subband samples in other channels.
170.prediction [video]: The use of a predictor to provide an estimate of the pel value or data element
currently being decoded.
171.prediction error [video]: The difference between the actual value of a pel or data element and its
predictor.
172.prediction: The use of a predictor to provide an estimate of the sample value or data element
currently being decoded.
173.predictive-coded picture; P-picture [video]: A picture that is coded using motion compensated
prediction from past reference frames or reference fields.
174.predictor: A linear combination of previously decoded sample values or data elements.
175.presentation channel [audio]: audio channels at the output of the decoder corresponding to the
loudspeaker positions left, center, right, left surround and right surround.
176.presentation time-stamp; PTS [system]: A field that may be present in a packet header that indicates
the time that a presentation unit is presented in the system target decoder.
177.presentation unit; PU [system]: A decoded audio access unit or a decoded picture.
178.profile: A defined subset of the syntax of this specification.
179.program [system]: A program is a collection of elementary streams with a common time base.
180.Program Specific Information; PSI [system]: PSI consists of normative data which is necessary for
the demultiplexing of Transport Streams and the successful regeneration of programs and is described
in clause [XX]. One case of PSI, the non-mandatory network information table, is privately defined.
181.progressive [video]: The property of film frames where all the samples of the frame represent the
same instances in time.
182.psychoacoustic model [audio]: A mathematical model of the masking behaviour of the human
auditory system.
183.quantisation matrix [video]: A set of sixty-four 8-bit values used by the dequantiser.
16
Page 17 of 100 July 30, 2002
184.quantised DCT coefficients: DCT coefficients before dequantisation. A variable length coded
representation of quantised DCT coefficients is transmitted as part of the compressed video bitstream.
185.quantiser scalefactor [video]: A data element represented in the bit stream and used by the decoding
process to scale the dequantisation.
186.random access: The process of beginning to read and decode the coded bit stream at an arbitrary
point.
187.reconstructed frame [video]: A reconstructed frame consists of three rectangular matrices of 8-bit
numbers representing the luminance and two chrominance signals. A reconstructed frame is obtained
by decoding a coded frame.
188.reconstructed picture [video]: A reconstructed picture is obtained by decoding a coded picture. A
reconstructed picture is either a reconstructed frame (when decoding a frame picture), or one field of a
reconstructed frame (when decoding a field picture). If the coded picture is a field picture, then the
reconstructed picture is the top field or the bottom field of the reconstructed frame.
189.reference field [video]: A reference field is one field of a reconstructed frame. Reference fields are
used for forward and backward prediction when P-pictures and B-pictures are decoded. Note that
when field P-pictures are decoded, prediction of the second field P-picture of a coded frame uses the
first reconstructed field of the same coded frame as a reference field.
190.reference frame [video]: A reference frame is a reconstructed frame that was coded in the form of a
coded I-frame or a coded P-frame. Reference frames are used for forward and backward prediction
when P-pictures and B-pictures are decoded.
191.reference picture [video]: Reference pictures are the nearest adjacent I- or P-pictures to the current
picture in display order.
192.reorder buffer [video]: A buffer in the system target decoder for storage of a reconstructed I-picture
or a reconstructed P-picture.
193.requantisation [audio]: Decoding of coded subband samples in order to recover the original
quantised values.
194.reserved: The term "reserved" when used in the clauses defining the coded bitstream indicates that
the value may be used in the future for ISO/IEC defined extensions.
195.reverse playback [video]: The process of displaying the picture sequence in the reverse of display
order.
196.sample aspect ratio [video]: (abbreviated to SAR). This specifies the distance between samples. It is
defined (for the purposes of this specification) as the vertical displacement of the lines of luminance
samples in a frame divided by the horizontal displacement of the luminance samples. Thus its units are
(metres per line) Ö (metres per sample)
197.scalability: Scalability is the ability of a decoder to decode an ordered set of bitstreams to produce
a reconstructed sequence. Moreover, useful video is output when subsets are decoded. The minimum
subset that can thus be decoded is the first bitstream in the set which is called the base layer. Each
of the other bitstreams in the set is called an enhancement layer. When addressing a specific
enhancement layer, "lower layer" refer to the bitstream which precedes the enhancement layer.
198.scalefactor [audio]: Factor by which a set of values is scaled before quantisation.
199.scalefactor band [audio]: A set of frequency lines in Layer III which are scaled by one scalefactor.
200.scalefactor index [audio]: A numerical code for a scalefactor.
17
Page 18 of 100 July 30, 2002
201.sequence header [video]: A block of data in the coded bit stream containing the coded representation
of a number of data elements.
202.side information: Information in the bitstream necessary for controlling the decoder.
203.skipped macroblock [video]: A macroblock for which no data are stored.
204.slice: A series of macroblocks.
205.slot [audio]: A slot is an elementary part in the bit stream. In Layer I a slot equals four bytes, in
Layers II and III one byte.
206.SNR scalability [video]: A type of scalability where the enhancement layer (s) contain only coded
refinement data for the DCT coefficients of the lower layer.
207.source stream: A single non-multiplexed stream of samples before compression coding.
208.spatial scalability: A type of scalability where an enhancement layer also uses predictions from
sample data derived from a lower layer without using motion vectors. The layers can have different
frame sizes, frame rates or chrominance formats
209.spreading function [audio]: A function that describes the frequency spread of masking effects.
210.start codes [system and video]: 32-bit codes embedded in that coded bitstream that are unique.
They are used for several purposes including identifying some of the structures in the coding syntax.
211.STD input buffer [system]: A first-in first-out buffer at the input of the system target decoder for
storage of compressed data from elementary streams before decoding.
212.stereo mode [audio]: Mode, where two audio channels which form a stereo pair (left and right) are
encoded within one bit stream. The coding process is the same as for the dual channel mode.
213.stereo-irrelevant [audio]: a portion of a stereophonic audio signal which does not contribute to
spatial perception.
214.stuffing (bits); stuffing (bytes) : Code-words that may be inserted into the compressed bit stream that
are discarded in the decoding process. Their purpose is to increase the bitrate of the stream.
215.subband [audio]: Subdivision of the audio frequency band.
216.subband filterbank [audio]: A set of band filters covering the entire audio frequency range. In this
part of the CD, the subband filterbank is a polyphase filterbank.
217.subband samples [audio]: The subband filterbank within the audio encoder creates a filtered and
subsampled representation of the input audio stream. The filtered samples are called subband samples.
From 384 time-consecutive input audio samples, 12 time-consecutive subband samples are generated
within each of the 32 subbands.
218.surround channel [audio]: An audio presentation channel added to the front channels (L and R or L,
R, and C) to enhance the spatial perception.
219.syncword [audio]: A 12-bit code embedded in the audio bit stream that identifies the start of a frame.
220.synthesis filterbank [audio]: Filterbank in the decoder that reconstructs a PCM audio signal from
subband samples.
221.system header [system]: The system header is a data structure defined in clause of this
Recommendation | International Standard that carries information summarizing the system
characteristics of the ISO/IEC 13818 multiplexed stream.
222.system target decoder; STD [system]: A hypothetical reference model of a decoding process used to
describe the semantics of an ISO/IEC 13818 multiplexed bit stream.
18
Page 19 of 100 July 30, 2002
223.temporal scalability [video]: A type of scalability where an enhancement layer also uses
predictions from sample data derived from a lower layer using motion vectors. The layers have
identical frame size, and chrominance formats, but can have different frame rates.
224.time-stamp [system]: A term that indicates the time of an event.
225.tonal component [audio]: A sinusoid-like component of an audio signal.
226.top field [video]: One of two fields that comprise a frame. Each line of a top field is spatially located
immediately above the corresponding line of the bottom field.
227.Transport Stream packet header [system]: A data structure used to convey information about the Deleted: transport packet
Transport Stream payload.

228.triplet [audio]: A set of 3 consecutive subband samples from one subband. A triplet from each of the
32 subbands forms a granule.
229.variable bitrate: Operation where the bitrate varies with time during the decoding of a compressed
bit stream.
230.variable length coding; VLC: A reversible procedure for coding that assigns shorter code-words to
frequent events and longer code-words to less frequent events.
231.video buffering verifier; VBV: A hypothetical decoder that is conceptually connected to the output
of the encoder. Its purpose is to provide a constraint on the variability of the data rate that an
encoder or editing process may produce.
232.video sequence: The highest syntactic structure of coded video bitstreams. It contains a series of one
or more coded frames.
233.zig-zag scanning order [video]: A specific sequential ordering of the DCT coefficients from
(approximately) the lowest spatial frequency to the highest.
19
Page 20 of 100 July 30, 2002
Abbreviations and symbols
The mathematical operators used to describe this specification are similar to those used in the C
programming language. However, integer divisions with truncation and rounding are specifically defined.
Numbering and counting loops generally begin from zero.
Arithmetic operators
+ Addition.
- Subtraction (as a binary operator) or negation (as a unary operator).
++ Increment.
-- Decrement.
×

∗ Multiplication.
^ Power.
/ Integer division with truncation of the result toward zero. For example, 7/4 and -7/-4 are
truncated to 1 and -7/4 and 7/-4 are truncated to -1.
// Integer division with rounding to the nearest integer. Half-integer values are rounded away
from zero unless otherwise specified. For example 3//2 is rounded to 2, and -3//2 is rounded
to -2.
DIV Integer division with truncation of the result toward minus infinity. For example 3†DIV†2 is
rounded to 1, and -3†DIV†2 is rounded to -2.
˜ Used to denote division in mathematical equations where no truncation or rounding is
intended.
% Modulus operator. Defined only for positive numbers.
Logical operators
|| Logical OR.
&& Logical AND.
! Logical NOT.
Relational operators
> Greater than.
>= Greater than or equal to.
< Less than.
<= Less than or equal to.
== Equal to.
!= Not equal to.
max [,...,] the maximum value in the argument list.
min [,...,] the minimum value in the argument list.
Bitwise operators
& AND
| OR
>> Shift right with sign extension.
20
Page 21 of 100 July 30, 2002
<< Shift left with zero fill.

Assignment
= Assignment operator.
21
Page 22 of 100 July 30, 2002
Mnemonics
The following mnemonics are defined to describe the different data types used in the coded bit stream.
bslbf Bit string, left bit first, where "left" is the order in which bit strings are written
in ISO/IEC 11172. Bit strings are written as a string of 1s and 0s within single
quote marks, e.g. '1000 0001'. Blanks within a bit string are for ease of reading
and have no significance.
center_chan Index of center channel.
center_limited Variable which indicates whether a subband of the center is not transmitted. It
is used in the case of phantom coding of center channel.
ch Channel. If ch has the value 0, the left channel of a stereo signal or the first of
two independent signals is indicated. (Audio)
gr Granule of 3 * 32 subband samples in audio Layer II, 18 * 32 subband samples
in audio Layer III. (Audio)
L, C, R, LS, RS Left, center, right, left surround and right surround audio signals
Lw, Cw, Rw, Weighted left, center, right, left surround and right surround audio signals. The
LSw, RSw weighting is necessary for two reasons:
1) All signals have to be attenuated prior to encoding to avoid overload when
calculating the compatible stereo signal.
2)The weighted and processed signals are actually coded and transmitted, and
denormalised in the decoder
left_sur_chan Index of left surround channel.
main_data The main_data portion of the bit stream contains the scalefactors, Huffman
encoded data, and ancillary information. (Audio)
mono_sur_cha Index of the mono surround channel. This index is identical to the index of the
n left surround channel. (Audio)
msblimit Maximum used subband
nch Number of channels; equal to 1 for single_channel mode, 2 in other modes.
(Audio)
nmch Number of channels in the multichannel extension part
dyn_cross dyn_cross means that dynamic crosstalk is used for a certain transmission
channel and a certain subband.
npredcoeff Number of prediction coefficients used.
part2_length The number of main_data bits used for scalefactors. (Audio)
right_sur_chan Index of right surround channel.
rpchof Remainder polynomial coefficients, highest order first. (Audio)
sb Subband. (Audio)
sbgr Groups of individual subband according to subbandgroup table in subclause
3.5.2.10
sblimit The number of the lowest subband for which no bits are allocated. (Audio)
scfsi Scalefactor selection information. (Audio)
switch_point_l Number of scalefactor band (long block scalefactor band) from which point on
window switching is used. (Audio)
22
Page 23 of 100 July 30, 2002
switch_point_s Number of scalefactor band (short block scalefactor band) from which point on
window switching is used. (Audio)
tc Transmitted channel. (Audio)
uimsbf Unsigned integer, most significant bit first.
vlclbf Variable length code, left bit first, where "left" refers to the order in which the
VLC codes are written.
window Number of the actual time slot in case of block_type==2, 0 <= window <= 2.
(Audio)
The byte order of multi-byte words is most significant byte first.
Constants
π 3,14159265359...
e 2,71828182845...
23
Page 24 of 100 July 30, 2002
Bitstream characteristics
Bitstream characteristics specify the constraints that are applied by the encoder in generating the bitstream.
These syntactic and semantic constraints may for example restrict the range or the values of parameters
that are encoded directly or indirectly in the bitstream. The constraints applied to a given bitstream may
or may not be known a priori .
System bitstreams
In this Clause characteristics of MPEG-2 system streams are described. Clause 7.1.1 contains the
characteristics that are applicable to both Transport Streams and Program streams. The Transport Stream,
respectively Program Stream specific characteristics are contained in Clause 7.1.2 and Clause 7.1.3.
General System bitstream characteristics
Transport Stream and Program Stream encoders may apply restrictions to the following parameters of
Transport and Program Streams (see ITU-T Rec. H.222.0 | ISO/IEC 13818-1) :
• constraints for STD Model

• use of smoothing buffer parameters
• delay caused by system target decoder input buffering
• length of PES packets
• presence of time stamps in PES packet headers (DTS, PTS)
• frequency of encoding time stamps in PES packet headers (DTS, PTS)
• use of private streams
• fixed or variable bitrate operation
• number of multiplexed audio streams in a program
• number of multiplexed video streams in a program
• decoding of trick modes
• use of PES Packet CRCs
• carriage of Program Stream data
• carriage of private data
• use of descriptors
• constraints for sending descriptors
Transport Stream specific characteristics
System encoders that produce Transport Streams may apply restrictions to the following parameters of
Transport Streams (see ITU-T Rec. H.222.0 | ISO/IEC 13818-1) :
• use of transport priority indication
24
Page 25 of 100 July 30, 2002
• application of scrambling
• frequency of opening an adaptation header field
• frequency of flagging random access points using the random_access_indicator
• use of elementary_stream_priority_indicator
• frequency of encoding PCRs
• use of option to encode OPCRs
• occurence of splice points
• carriage of private data
• use of LTW concept
• support of seamless splicing
• encoding of a valid value in the PES_packet_length field in the case of a PES packet carrying
MPEG-2 video data
• frequency of transmitting PSI tables
• use of Network Information Table
• use of Conditional Access Table
• use of private sections
Program Stream specific characteristics
Program Stream encoders may apply restrictions to the following parameters of Transport and Program
Streams (see ITU-T Rec. H.222.0 | ISO/IEC 13818-1) :
• program mux_rate
• rate_bound
• P-STD_buffer_size
• P-STD_buffer_size_bound
• delay caused by system target decoder input buffering
• difference between two SCRs in successive packs
• length of a pack
• length of a PES packet
• number of PES packets in a pack
• presence of time stamps in packet headers (DTS, PTS)
• CSPS_flag
• use of private streams
• packet rate
• fixed or variable bitrate operation (fixed_flag parameter)
• number of multiplexed audio streams (audio_bound parameter)
• number of multiplexed video streams (video_bound parameter)
• locking of audio sampling frequency and frequency of system clock locking of video picture rate and
frequency of system clock
• constraints for use of Program Stream Map Table
• constraints for use of Program Stream Direstory Table
25
Page 26 of 100 July 30, 2002
Video bitstreams
A requirement for MPEG video encoders is that the arithmetic precision in the decoder process used in the
encoder to produce the coded bitstream shall have the full accuracy specified in ISO/IEC 13818-2.
The following three clauses list bitstreams used to test decoder compliance. Future versions of this
document may list additional bitstreams for additional combinations of Profiles and Levels.
Main Profile compliance bitstreams
The following bitstreams are part of a test suite for Main Profile, Main Level.
N Level Description Contributing
o Organization
1 ML Frame pictures with all Bi-directional, Field-MC GI, TI
2 ML B pictures with maximum vbv_buffer_size (1.75 Mbit) TCE-H
3 ML All dual-prime macroblocks in frame-coded picture. Nokia
vectors
4 ML All MB_type transitions (frame coding only Tektronix
5 ML Frequent slices (e.g. Slice = MB TCE-LA
6 ML Alternating top/bottom, ZZ/Alternative, Intra/Non-intra Sony
VLC tables in I pictures, Field and Frame pictures,
variable M/N, downloaded quantization weighting
matrices
7 ML Max. bit burst and simultaneous Dual Prime MC IBM
8 ML All possible VLCs symbols and IDCT mismatch. Swedish
Mismatch and saturation Telecom,
TRAB
9 [temporarily unassigned test number]
10 ML MCP decoder test (MPEG 94/426)) CCETT
11 ML Flat distribution of VLC events on B and P pictures LEP
12 ML Bursty case for number of bits per MB with different HHI
burst location within picture (top, bottom), followed
Bi-directional macroblocks.
13 ML Field-coded pictures, all Dual Prime. TCE-LA
14 ML Field coded pictures with 16x8 bidrectional macroblock TCE-LA
motion compensation. Sequence contains many
consequitive B pictures.
15 ML Stream with R/P bits worth of slice start code zero Hitachi
padding in a single slice.
16 ML MPEG-1 bitstream Matsushita
17 ML Concatenated sequences of different picture sizes with Hitachi
VBV continuity.
26
Page 27 of 100 July 30, 2002
18 ML Low delay sequence with skipped pictures. NTR

19 ML simulated IEEE 1180 mismatch bitstream test IBM
27
Page 28 of 100 July 30, 2002
SNR Profile compliance bitstreams
The following bitstreams are part of a test suite for SNR Profile, Main Level with 5 Mbit/sec coded for the
base layer, and 10 Mbit/sec for the enhancement layer.

o Organization
20 ML Maximum VLD bandwidth on both layers (base and TCE-H
enhancement) with burst of escape codes, bursts of short
VLCs and maximum buffer size on both layers
21 ML Skipped MBs on base layer, on enhancement layer, and TI Japan
on both layers together. Test of the DCT type in the
enhancement layer while MBs are skipped in the base
layer.
22 ML Different weighting matrices, different scanning on the HHI
two layers
Spatial Profile compliance bitstreams
The following bitstreams are part of a test suite for Spatial Profile, High 1440 Level.
o Organization
23 High All MB transitions in enhancement layer, all posible VLC HHI,TCE-H
1440 symbols in enhancement layer, and all cases of motion
vector updating
Compliance bitstream characteristics
The bitstream suite employs two fundamental categories to help determine the compliance of a decoder
under test. The first type is an arithmetic test which is intended to verify the arithmetic accuracy of a
decoder. Examples include: IDCT and quantization precision, motion vector arithmetic, rounding at
various stages, and clipping at various stages. The second type is a performance test which is intended to
verify the performance capability of a decoder. Examples include: prediction bandwidth, variable length
token event rate and bit rate. In order to less ambiguously verify stages of the decoder, many tests are
constructed near or at the parameter limits specified by the Profile and Level.
Parameter or Condition
bitstream element
f_code[][] maximize f_code for Profile and Level
motion_code motion vectors which explore the full range
specified by f_code[][]
28
Page 29 of 100 July 30, 2002
prediction mode Field MC in Frame pictures, 16x8 MC in

Field-pictures, or Dual Prime MC in either Field or
Frame pictures to maximize prediction bandwidth
macroblock_type presense of backwards motion vectors are signalled,
maximizing prediction bandwidth in B pictures
vbv_buffer_size maximum value specified by profile and level
bit_rate maximize coded bit rate
Event rate maximize coded token rate
Half-pel reconstructed motion vectors with half-pel values
interpolation for both luminance and chrominance components of
both horizontal and vertical directions
Quantizer scales maximum scale values for both macroblock
quantization scale and quantization matrices
produce the greatest combined dynamic range for
testing decoder arithmetic precision.
All bistreams observe the rule that only 2 macroblocks per macroblock row can exceed the legal 3:2 coded
bit rate expansion factor specified in ISO/IEC 13818-2, Clause 8.
29
Page 30 of 100 July 30, 2002
Audio bitstreams
Audio encoders may apply restrictions to the following parameters of audio bitstreams (see ISO/IEC 13818-3):
2.3.3.1 Extension of ISO/IEC 11172-3 Audio Coding to Lower Sampling Frequencies
a) ID
b) layer
c) bitrate_index
d) sampling_frequency
e) mode
f) mode_extension
g) emphasis
h) generation of crc_check
i) value of fixed bitrate when coding in free format mode.
j) generation of ancillary data
2.3.3.2 Low bit rate coding of Multichannel Audio
a) ID
b) layer
c) bitrate_index
d) sampling_frequency
e) mode in MPEG-1 header, and center, surround and LFE in MC-header
f) mode_extension in MPEG-1 header
g) emphasis
h) generation of crc_check
i) value of fixed bitrate when coding in free format mode.
j) generation of ancillary data
k) use of extension stream
l) audio_mix
m) dematrix_procedure
n) no_of_multi_lingual_ch
o) multi_lingual_fs
p) multi_lingual_layer
q) n_ad_bytes
r) tc_sbgr_select
s) dyn_cross_on
t) mc_prediction_on
The use of higher order prediction (more than zero-order), and/or delay compensation will limit the
editability of the coded bit streams.
30
Page 31 of 100 July 30, 2002
Descriptions of the ISO/IEC 13818 (MPEG) audio test bitstreams
For Layer II compressed bitstreams according to DIS 13818-3 are provided. Detailed descriptions of the
bitstreams are furnished below. The following file name extensions are used to identify different parts
name.mpg : MPEG2 bit stream - MPEG1 compatible part

name.ext : MPEG2 extension bit stream (valid for bit rates > 384 kbit/s)
name.txt : description file
1. dis_bs01
files: dis_bs01.mpg, dis_bs01.txt
Originator: CCETT
layer: II
total bitrate: 384 kbit/s
sampling frequency: 48 kHz
number of subbands: 27
MPEG1 COMPATIBLE PART
bit rate: 384 kbit/s

mode: stereo
MULTICHANNEL EXTENSION
center channel: present

surround channels: stereo
LFE channel: none
presentation matrix: -3dB surround -3dB center
number of multilingual channels: 0
additional bitstream: none
transmission channel allocation: variable
dynamic_crosstalk: off
prediction: off
REMARKS
none
31
Page 32 of 100 July 30, 2002
2. dis_bs02
Originator: CCETT
layer: II

mode: stereo
center channel: with phantom coding

LFE channel: none
prediction: off
REMARKS
none
3. dis_bs03
files: dis_bs03.mpg, dis_bs03.ext, dis_bs03.txt
Originator: CCETT
layer: II
32
Page 33 of 100 July 30, 2002

mode: stereo

LFE channel: none
additional bitstream: yes
extension bitstream length 384 bytes/frame (= 128 kbit/s)
MPEG1 ancillary data length: 3 bytes/frame
prediction: off
REMARKS
none
4. dis_bs04
Originator: CCETT
layer: II
33
Page 34 of 100 July 30, 2002
mode: stereo
center channel: with phantom coding

LFE channel: none
MPEG1 ancillary data length: 3 bytes/frame
prediction: off
REMARKS
none
5. dis_bs05
Originator: IRT
layer: II

mode: stereo
34
Page 35 of 100 July 30, 2002

LFE channel: none
prediction: on
REMARKS
predictor order always 0, no delay compensation
6. dis_bs06
Originator: CCETT
layer: II

mode: stereo

LFE channel: none
35
Page 36 of 100 July 30, 2002
prediction: off
REMARKS
none
36
Page 37 of 100 July 30, 2002
Decoder characteristics
The characteristics of a decoder specify the properties and capabilities of the decoding process applied in
the decoder. An example of a property is the arithmetic accuracy that is applied. The capabilities of a
decoder specify which coded bitstreams the decoder can reconstruct, by defining the subset of the standard
that may be exploited in decodable bitstreams. A bitstream can be decoded by a decoder if the
characteristics of the coded bitstream are within the subset of the standard defined by the decoder
capabilities. Compliance to ISO/IEC 13818 by a decoder requires that the capabilities of the decoder
are specified. That is, each constraint on the subset of the standard that may be exploited in bitstreams
decodable by the decoder shall be specified.
General System Decoder capabilities
Introduction
In this Clause System Decoder Capabilities are provided. Most of those capabilities cannot be tested in a
mathematical way. These capabilities should therefore be considered as a functional checklist as a focus
point for application and decoder developers. Some of the capabilities are mandatorily required for each
compliant decoder, while others are only optionally required.
Handling of decoder discontinuities (mandatory)
Sequence Concatenation; Decoding Discontinuities; Splicing; Format Changes
In compliant Transport Streams, at any audio access unit boundary or any video sequence boundary, the
following discontinuities in the decoding process parameters can occur:
• for video, any parameter set in the sequence header or lower layer headers, such as profile/level, frame rate,
bitrate, GOP parameters, picture format, etc.;
• for audio, any parameter such as audio layer, bitrate, sample rate, etc.;
• for both video and audio, the decoding time of the first access unit after the boundary can be larger than
would have been expected had the boundary not been present. This can happen independently for all, some,
or one of the elementary streams of a program. It may or may not be indicated by the presence of extra
information referring to a seamless or non-seamless splice point.
Assuming any combination of change(s) in decoding process parameter(s) which lead(s) to parameter values
that are supported by the decoder under test, the decoder under test shall:
• maintain correct presentation synchronization between the different elementary streams of the program;
37
Page 38 of 100 July 30, 2002
• not produce unacceptable audio or video artefacts, such as chirps, blocking etc. However, when a
decoding discontinuity occurs, there may not be any data to present during some time interval. At such
instants, audio decoders are recommended to mute and video decoders to freeze frame/field.
• present all presentation units at least once;
• present all presentation units using the correct format, such as picture format, resolution, audio sample rate
etc.
•
Time base synchronization (mandatory)
Transport Stream decoders shall synthesize a decoder STC which is a local replica of the STC used to
encode PCRs in the PCR_PID of the program being decoded. PCR discontinuities which are indicated
by the discontinuity_indicator must produce corresponding discontinuities in the decoder STC. The
decoder STC shall be used to derive the video and audio sampling rates
Program Stream decoders shall synthesize a decoder STC which is a local replica of the STC used to
encode the SCRs in the pack_headers. If either the system_audio_lock_flag or the
system_video_lock_flag is set, the decoder STC shall be used to derive the corresponding sampling rate.
In both TS and PS decoders, the decoder STC shall be used as a basis for processing DTS and PTS
timestamps in the program.
The amount of jitter on the PCR (SCR) samples is application dependent. The decoder STC must track
the received (jittered) PCRs, which may have discontinuities indicated, (or SCRs) with sufficient accuracy
that the program can be decoded and presented without artifacts, such as dropping or repeating
presentation units, or malfunctions, such as buffer overflow, due to poor synchronization. The output
quality (frequency stability and phase noise) of the decoder STC must be sufficient to support all functions
for which it is used e.g. chroma subcarrier generation if a composite video signal is being reconstructed.
Presentation synchronization (mandatory)
Timing of the presentation of decoded elementary streams shall be based on the encoded and interpolated
PTSs for each presentation unit, as specified in Part 1 of this Recommendation |International Standard.
The timebase used shall be the replica of the STC synthesized in the decoder. The delay due to the
implementation of the decoder must be accounted for when calculating the actual presentation time from
the PTS. In normal operation (not trick modes) all presentation units in the program shall be presented,
and the variation in the difference between the PTS and the actual presentation times of presentation units
shall not be perceivable.
Support of variable bitrate within a program (mandatory)
38
Page 39 of 100 July 30, 2002
For an STD and VBR-VBV compliant VBR video service in a program, a compliant decoder shall decode
and present all presentation units without any decoding or presentation artifacts, such as blocking or
unintended dropping or freezing of frames. The decoder shall also maintain presentation synchronization
between audio and video.
General capabilities for program acquisition (mandatory)
Change in program definition (mandatory)
A change in program definition may be noticed from a change in the information contained in a
program_map_section defining a specific program. A change can be assumed to have occurred when a
section with the current_next_indicator set to current and the program_number of the wanted program is
detected, with a version number different from that of the previous version_number being used. A change in
PID filtering should be accomplished within 1 second of the time that the last byte of the CRC_32 of the
program_map_section carrying the change exits the buffer Bsys.
Audio: Decoders should be able to follow such a change, muting between streams if necessary. No
audible artifacts should occur when such a change has been signalled in a program_map_section. If
different languages are offered within one program, then the decoder should continue to present the same
language after a change as before it, provided that the initial language is still available after the change and is
supported by descriptors.
Video: Decoders should be able to follow such a change, freezing the frame if necessary. No visible
artifacts should occur when such a change has been signaled in a program_map_section.
39
Page 40 of 100 July 30, 2002
Note on Conditional Access
Decoders which do not support conditional access or descrambling functionality do not need the ability to
access Transport Stream packets with PID value of 0x0001. For decoders which do claim this functionality
it may be desirable to continuously monitor such Transport Stream packets.
Private data handling (mandatory)
The normal operation of compliant MPEG decoders shall not be affected by the presence of private data in
a Transport Stream or a Program Stream.
Private Data in Transport Streams

Decoders shall at a minimum be capable of recognizing and discarding all packets for which the
stream_type is private (stream_type = 0x05, 0x06, 0x80-0xFF). These include the NIT. The presence
of such packets in a transport stream shall not cause interruption or degradation of service in a decoder
processing that transport stream.
Decoders shall at a minimum be capable of recognizing and ignoring all private fields. These fields are:
• In PES and Adaptation Field structures
IN AF: private_data_byte when
transport_private_data_flag=‘1’, and
transport_private_data_length > ‘0’.
IN PES: PES_private_data when
PES_extension_flag = ‘1’, and
PES_private_data_flag = ‘1’.
• In the Conditional Access Table (PID 1)
This data is contained in the private_data_byte field of the CA_descriptor
(tag = ‘9’) when the descriptor_length field > ‘4’.
• In CA_descriptors (tag = ‘9’) in TS_program_map_sections
This data is contained in the private_data_byte field of the CA_descriptor
when the descriptor_length field > ‘4’.
• In private_sections found in PIDs containing TS_program_map_sections
These private_sections are identified by having their value of the table_id field
NOT set to values of 0x00, 0x01 or 0x02.
• In the private_data_indicator_descriptor (tag = ‘15’)
This data is contained in the private_data_indicator field when the
descriptor_length field > ‘0’.
• In the User Private Descriptors (tag = ‘64’ - ‘255’).
Private Data in Program Streams
Decoders shall at a minimum be capable of recognizing and discarding all packets for which:
• stream_id = private_stream_1 (‘1011 1101’)

• stream_id = private_stream_2 (‘1011 1111’)
40
Page 41 of 100 July 30, 2002
• stream_id = ECM_stream (‘1111 0000’)

• stream_id = EMM_stream (‘1111 0001’)
Support of Trick Modes (optionally)
The following requirements apply only to decoders which support trick modes.
Decoders shall continue to display meaningful video while performing the trick mode functions. The
displayed video should also be indicative of the function it is attempting to represent. In addition, the
following constraints are placed upon the individual trick mode functions themselves.
Fast Forward
Decoders shall display only the field(s) indicated by field_id.
If intra_slice_refresh is set, then no constraints are placed upon the display of missing macroblocks
between coded slices. However, it is strongly recommended that decoders display visually acceptable
material in these locations, e.g., co-sited macroblocks from previous pictures.
Slow Motion
For interlaced pictures decoders shall first display the top field for field_rep_cntrl periods, followed by the
bottom field for field_rep_cntrl periods. For progressive pictures, the entire frame shall be displayed for
field_rep_cntrl periods.
Freeze Frame
Decoders shall display only the field(s) indicated by field id.
The field(s) displayed are from the first video presentation unit in the PES packet that contains the field_id
parameter. If no video presentation unit is contained in that PES packet, then the field(s) displayed are
from the most recent previous video presentation unit.
Fast Reverse
Decoders shall display only the field(s) indicated by field_id.
If intra_slice_refresh is set, then no constraints are placed upon the display of missing macroblocks
between coded slices. However, it is strongly recommended that decoders display visually acceptable
material in these locations, e.g., co-sited macroblocks from previous pictures.
Slow Reverse
41
Page 42 of 100 July 30, 2002
For interlaced pictures decoders shall first display the bottom field for field_rep_cntrl periods, followed by
the top field for field_rep_cntrl periods. For progressive pictures, the entire frame shall be displayed for
field_rep_cntrl periods.
Discontinuities may occur upon entering, changing, or leaving the trick mode state, therefore compliance
requirements for the handling of discontinuities must also be met by the decoder. Audio/video
synchronization compliance may not be applicable while in the trick mode state.
DECODER CHARACTERISTICS BEYOND COMPLIANCE
NUMBER OF PIDS THAT CAN BE PROCESSED

A compliant decoder must be able to demultiplex and process all PIDs carrying information related to the
program it is receiving. These include PID 0 (which carries the PAT), the PMT_PID, and at least one
PID for the service data. The PCR does not necessarily have a different PID, but if it does then the
PCR_PID must also be demultiplexed. If a program with video and audio elementary streams is being
decoded, at least four PIDs must be demultiplexed. The following table shows the number of PIDs which
it may be necessary for a decoder to demultiplex in order to receive a single program. For some
applications it may not be necessary for the decoder to process all these PIDs simultaneously.
DATA IN PID NUMBER OF PIDS

PAT (PID 0) 1
PMT_PID 1
PCR_PID 0-1
Video 0-V
Audio 0-A
CA (PID 1) 0-1
EMM 0-1
ECM 0-C
NIT 0-1
Other 0-N
The values V, A, C, and N are the maximum number of PIDs carrying the corresponding data in a single
program.
ERROR HANDLING
For error conditions that do not result in unacceptable decoding artifacts, a decoder should:
• maintain the system time base in the event of errored or missing packets that carry PCRs
• maintain its program information database in the event of receiving PSI sections with errors that are
detectable using the CRC-32 fields.
A decoder should detect and process error conditions which are indicated by one or more of the following:
• transport_error_indicator = 1
• continuity_counter errors
• CRC-32 errors in PSI sections.
42
Page 43 of 100 July 30, 2002
Program Acquisition (MANDATORY)

Decoders shall be able to use PSI information to support acquiring a program. This entails:
1. Accessing Transport Stream packets with PID value of 0x0000, and finding the start of a section, parsing
the sections in order to read the program_map_PID value of the wanted program. Since during the
continuous existence of a program, the program_map_PID may not change, it is not strictly necessary to
continuously monitor Transport Stream packets of PID value 0x0000.
2. Accessing Transport Stream packets with the PID value listed in the PAT as carrying the
program_map_PID for the wanted program; identifying sections within this PID which have table_id
0x02, and which have the program_number field which is the wanted program.
3. Reading the data within any such sections, to identify the Transport Stream packets which may contain
PCRs for the program, to identify video and audio streams which compose the program, and if necessary
using descriptors, to identify which stream(s) is/are chosen for decoding. Note that it is possible within
the duration of a program for a program definition to change, for example for the required video PID to
change value, therefore it is a desirable feature to continuously monitor such sections.
Input processing capabilities
An ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Transport Stream or Program Stream decoders may support
specific values only, or a specific range of input rates. The STD buffer sizes will be constrained and in
case of a Program Stream, there will be a constraint on the PES Packet rate
A Program Stream decoder may constrain the support of fixed and/or variable bitrate operation (see
definition of the fixed_flag field in xxxx of ITU-T Rec. H.222.0 | ISO/IEC 13818-1), and may require
locking between the 27 MHz system clock and the audio sampling frequency and/or the video picture rate
(see the system_audio_lock_flag and the system_video_lock_flag fields in xxxx of ITU-T Rec. H.222.0 |
ISO/IEC 13818-1).
43
Page 44 of 100 July 30, 2002
Video decoders
An ISO/IEC 13818-2 video decoder may support specific values only, or a specific range, or a specific
combination of values or ranges of the following parameters in video bitstreams. These parameters are
encoded directly or indirectly in the bitstream.
a) horizontal_size
b) vertical_size
c) pel_aspect_ratio
d) picture_rate
e) bit_rate
f) VBV_buffer_size
g) The total number of macroblocks in a picture.
h) The total number of macroblocks per second.
i) range of motion vectors (encoded in the various fields related to motion vectors)
Furthermore, an ISO/IEC 13818-2 video decoder may constrain:
a) IPB structure. That is the picture coding types and sequences of different picture coding
types that are supported, such as for example the number of consecutive B frames, may
be restricted.
b) the support of fixed and/or variable bitrate operation.
An ISO/IEC 13818-2 video decoder shall specify how sequence_error_codes and user data are handled.
For a video decoder to be compliant to ISO/IEC 13818-2 a statement of whether or not computation is
carried out with the full accuracy specified in ISO/IEC 13818-2 is required. If the full arithmetic
precision is not implemented, the accuracy shall be specified. In the case of the inverse DCT,
compliance testing requires performing the tests described in IEEE standard P1180/D2, as indicated in
annex A of ISO/IEC 13818-2, and a statement of the numerical results for peak error and mean square
error.
The legal ranges of the above parameters are defined in Chapter 8 of ISO/IEC 13818-2.
44
Page 45 of 100 July 30, 2002
Audio decoders
Extension of ISO/IEC 11172-3 Audio Coding to Lower Sampling Frequencies
An ISO/IEC 13818-3 Low Sampling Frequency audio decoder may support only specific values, or a
specific range, or a specific combination of values or ranges of the following parameters in audio
bitstreams. These parameters are encoded directly or indirectly in the bitstream.
a) layer
b) bitrate_index
c) sampling_frequency
d) mode
e) mode_extension
f) emphasis
Furthermore, an ISO/IEC 13818-3 Low Sampling Frequency audio decoder may constrain the support of
free format mode. For an ISO/IEC 13818-3 Low Sampling Frequency audio decoder the handling of
ancillary data and error protection (crc_check) shall be specified, as shall the single channel performance
(single channel output at one or at both output channels).
Compliance of an audio decoder to ISO/IEC 13818-3 Low Sampling Frequency requires that the output
signal of the decoder is reconstructed accurately. For actual tests see 2.6.3.
An ISO/IEC 13818-3 Low Sampling Frequency compliant audio decoder that is able to support at least
one but not all combinations of the options defined in 2.4.3.1 such as bit rates, sampling rates and modes,
will be designated as an ISO/IEC 13818-3 Low Sampling Frequency Layer N audio decoder. Decoders
that support all combinations are designated as Full ISO/IEC 13818-3 Low Sampling Frequency Layer N
audio decoders, where N indicates I, II or III.
Low bit rate coding of Multichannel Audio
An ISO/IEC 13818-3 Multichannel audio decoder may support only specific values, or a specific range, or
a specific combination of values or ranges of the following parameters in audio bitstreams. These
parameters are encoded directly or indirectly in the bitstream.
a) layer
b) bitrate_index
c) sampling_frequency
d) mode in MPEG-1 header, and center, surround and LFE in MC-header
e) mode_extension in MPEG-1 header
f) emphasis
g) generation of ancillary data
45
Page 46 of 100 July 30, 2002
h) use of limited extension stream (length = 1152 Bytes)

i) use of full extension stream length
j) dematrix_procedure
k) no_of_multi_lingual_ch
l) multi_lingual_fs
m) multi_lingual_layer
n) tc_sbgr_select
o) dyn_cross_on
p) mc_prediction_on
Furthermore, an ISO/IEC 13818-3 Multichannel audio decoder may constrain the support of free format
mode. For an ISO/IEC 13818-3 Multichannel audio decoder the handling of ancillary data and error
protection (crc_check) shall be specified, as shall the single channel performance (single channel output at
one or at both output channels).
Compliance of an audio decoder to ISO/IEC 13818-3 Multichannel Audio requires that the output signal
of the decoder is reconstructed accurately. For actual tests see 2.6.3.
An ISO/IEC 13818-3 Multichannel compliant audio decoder that is able to support at least one but not all
combinations of the options defined in 2.4.3.2 such as bit rates, sampling rates and modes, will be
designated as an ISO/IEC 13818-3 Multichannel Layer N audio decoder.
An ISO/IEC 13818-3 Multichannel compliant audio decoder that is able to support at least the features
according to the following table will be designated as a Core ISO/IEC 13818-3 Multichannel Layer N
decoder or as a Full ISO/IEC 13818-3 Multichannel Layer N decoder respectively.
Layer I Layer II Layer III
bitstream characteristic Core Full Core Full Core Full
MPEG-1 Layer I Y Y N Y N Y
MPEG-1 Layer II N N Y Y N Y
MPEG-1 Layer III N N N N Y Y
Configuration 3/2 Y Y Y Y Y Y
Configurations 3/1, 3/0, 2/2, N Y N Y N Y

2/1
Configuration 2/0, 1/0 Y Y Y Y Y Y
2nd stereo N Y N Y N Y
LFE N Y N Y N Y
free format N Y N Y N Y
46
Page 47 of 100 July 30, 2002
extension bitstream N Y N Y N Y
channel switching Y Y Y Y Y Y
dynamic cross-talk Y Y Y Y
prediction zero order Y Y Y Y Y Y
prediction higher order, delay N Y N Y Y
dematrix procedure Y Y Y Y Y Y
‘0’,’1’,’3’
dematrix procedure ‘2’ N Y N Y N Y
multilingual Layer II N Y N Y N Y
multilingual Layer II half Fs N Y N Y N Y
multilingual Layer III N N N N N Y
multilingual Layer III half Fs N N N N N Y
47
Page 48 of 100 July 30, 2002
Procedures to test bitstream compliance
This clause describes procedures to verify compliance of system, video and audio decoders. All tests are
performed using error free bit streams. For correct interpretation of syntax and semantics, test sequences
covering a wide range of parameters shall be supplied to the decoder under test and its output sequence
shall be compared with the output of a reference decoder. The comparison can be done, for example, by
performing subjective tests, by evaluation of the difference signal and by comparing the timing
performance. Each compliant decoder shall be able to decode all compliant ISO/IEC 13818 streams
within the subset of the standard defined by the specified capabilities of the decoder. The procedures to
test decoder compliance are given for parts 1, 2 and 3 of ISO/IEC 13818 in separate sub-clauses.
Systems bitstream tests
Tests on Transport
Tests at the transport_packet() level
sync_byte: each TS packet shall contain the value 0x47 as the first byte of the packet.
transport_error_indicator: if the transport_error_indicator is set to'1', all other test of fields within the
packet may not yield valid results.
payload_unit_start_indicator: if the payload_unit_start_indicator is set to '1', and if the TS packet

contains the start of a PES packet, the first five bytes of the TS packet payload shall contain the
PES start code, which consists of packet_start_code_prefix followed by stream_id. The latter
contains a value in the range permitted by Table 2-18 in ITU_T Rec. H.222.0 | ISO/IEC 13818-1.
Otherwise if the payload_unit_start_indicator is set to '1', and if the TS packet contains PSI data,
the first byte of data_byte shall be the first byte of a PSI section.In case of PSI data : check
whether pointer field is available and that its value is consistent with the descriptor length fields.
transport_priority: no tests are applied to transport_priority.
PID: the PID value shall be one of 0x0000, 0x0001, or 0x0010, through to 0x1FFF. Other values
represent an error. If the PID value is 0x1FFF the payload_unit_start_indicator shall be set to '0',
and the transport_scrambling_control field shall be '00'.
transport_scrambling_control: must be '00'
adaptation_field_control: if the adaptation_field_control is set to '00', then there is an error. If the

adaptation_field_control is set to '01' there is no adaptation field in this TS packet. If the
adaptation_field_control is set to '10', then the adaptation_field_ length field shall have a value of
183. If the adaptation_field_ control is set to '11', then the adaptation_field_length field shall
48
Page 49 of 100 July 30, 2002
have a value in the range of 0 to 183.In case of a null packet check whether the adaptation_field_
control is set to '01'.
continuity_counter: if the continuity_counter field value is equal to the continuity_counter field value
of the previous TS packet, then either the adaptation_field_control has a value of '00' or '10', the
discontinuity_indicator field is set to '0' and the entire TS packet is a replica of the previous TS
packet of the same PID, except for the PCR field, the discontinuity_indicator field is set to '1', or
there is an error. If the continuity_counter field value is not equal to, or is not one greater
(modulo 16) than the continuity_ counter field value of the previous TS packet, then either the
discontinuity_indicator is set to '1', or there is an error.
data_byte: tests of packet payload are performed consistent with the stream_type.
Tests at the adaptation_field() level
adaptation_field_length: the adaptation_field_length shall be consistent with the

adaptation_field_control field.
discontinuity_indicator: the discontinuity_indicator field shall be set to '1' if there is a PCR

discontinuity. If the discontinuity_indicator is set to '1' the discontinuity state is true and remains
true until the next packet of the same PID with the discontinuity_indicator equal to '0'. For each
discontinuity state (consecutive packets of the same PID fo which the continuity state is true) the
continuity_counter may be discontinous once. More than one continuity counter discontinuity
constitutes an error. For each discontinuity state there may be one PCR discontinuity. More than
one PCR during a discontinuity state constitutes an error. If the PID is not a PCR_PID no more
than two consecutive packets of the same PID shall have the discontinuity_indicator set to '1'. In
addition, the first byte after a continuity_counter should be the first byte of an elementary stream
access point, it may be discontinous in version numbers of PSI sections, with section_length equal
to 13, and old versus new PTS and DTS values. If there is a time base discontinuity, then old
PTSs and DTSs shall not arrive after the discontinuity. Likewise, new PTSs and DTSs shall not
arrive before the discontinuity point.
random_access_indicator: if the TS packet contains PES data and the random_access_indicator is set
to '1' and the payload_unit_start_indicator is set to '1', then the PES packet shall start in the
transport packet. If the TS packet contains PES data and the random_access_indicator is set to
'1', and the PID is PCR_PID then there shall be a PCR.
elementary_stream_priority_indicator: If packet carries video, then the Transport Packet payload

contains one or more bytes from an intra coded slice.
PCR_flag: if the PCR_flag is set to '1' then there shall be a PCR field present in this TS packet.
49
Page 50 of 100 July 30, 2002
OPCR_flag: if the OPCR_flag is set to '1' then there shall be an OPCR field present in this TS packet. If
OPCR = 0 , then also the PCR flg is set to 1 mbit/second.
splicing_point_flag: if the splicing_point_flag is set to '1' then there shall be a splice_countdown field
present in this TS packet.
transport_private_data_flag: if the transport_private_data_flag is set to '1' then there shall be one or

more private_data_byte fields present in this TS packet.
adaptation_field_extension_flag: if the adaptation_field_extension_flag is set to '1' then there shall be

an adaptation_field_ extension_field present in this TS packet ..... value
PCR: Check whether the error in the encoded PCR value does not exceed the specified tolerance.
OPCR: if single program Transport Stream, then check whether OPCR = PCR.
splice_countdown: this field is checked only in packets containing payload. Duplicate packets are not
checked. If splice_countdown then for all consecutive packets with splicing_point_flag equal to
'1', the splice_countdown field shall decrement with each packet. (2's complement numbers roll
over from 1000 0000 (-128) to 0111 111 (+127)). If the splice_countdown is set to '1' then the
packet payload starts with the first byte of a PES packet which starts with the first byte of an
access point.
transport_private_data_length: check whether length fits within adaptation header.
ltw_flag: check whether LTW_offset field is present
piecewise_rate_flag: check whether piecewise_rate field is present
seamless_splice_flag: check whether the associated fields are present
ltw_offset: if LTW_valid_flag is true, then verify whether all deliveries within LTW are valid
splice_type: verify whether the splicing constraints from the splice parameters are met
DTS_next_au: check whether encoded value corresponds to value derived from nominal decoding after
previously encoded DTS
stuffing_byte: check whether value equals '1111 1111'
Tests at the PES header level
50
Page 51 of 100 July 30, 2002
packet_start_code_prefix: Test that the value is 0x000001.
stream_id: Test that the value of stream_id is not between 11110100 and 11111110 If the PES packet
resides in a TS, test that the value is not 10111100 or 11111111. If the PES packet resides in a TS,
test that the value is not different than other stream_ids of the same PID.
pes_packet_length: In a TS, verify that the value is not zero in any PES packet that does not contain
video. In a PS, verify that the value is not zero. If value is not equal to zero, check that the length
addresses the next startcode prefix.
PES_scrambling_control: check whether value equaks '00'
data_alignment _indicator: If the value is 1, check whether the required alignment is applied
PTS_DTS_flags: check that the value is not 01. If a PTS or DTS is indicated, check whether the field(s) is
(are) present.
ESCR_flag: if set to '1', test that the ESCR field is present
ES_rate_flag: if set to '1', test that the ES_rate field is present
DSM_trick_mode_flag: if set to '1', test that the associated fields are present
PES_CRC_flag: if set to '1', test whether the PES_CRC field is present
PES_extension_flag: if set to '1', test the presence of the associated fields
PES_header_data_length: check consistency with other length fields
Presentation_time_stamp: verify consistency within the context of the STD. If other layers, check PTS
consistency
Decoding_time_stamp: verify consistency within the context of the STD
intra_slice_refresh: if set to '1', test that there are no missing macroblocks between coded slices
field_rep_cntrl: check that value is not equal to 0
previous_PES_packet_CRC: verify whether encoded value is correct
pack_header_field_flag: If in Program Stream, test that this bit is '0'
program_packet_sequence_counter: check that the counter increments with one each PES packet
51
Page 52 of 100 July 30, 2002
original_stuff_length: test whether this value does not exceed the permitted range P-STD Buffer scale: if
audio test that the value is '0', if video test that the value is '1'
stuffing byte: check that the value equals '1111 1111". Test that there are no more than 32 stuffing bytes
padding byte: check that the value equals '1111 1111".
Tag descriptors
Never refer to a reserved PID ie 0x0002-0x000F or 1FFF
The checks on descriptor_tag and descriptor_length are common to all descriptors.
descriptor_tag (8): Check that tag does not take the following values: 0-1, 16-63.
descriptor_length (8): Check that the total length of descriptors described in their associated PSI
structures, is equal to the sum of the lengths of all the included descriptors plus 2 times the number of
descriptors.
(Check also that the CRC_32 transmitted at the end of a section agrees with the CRC 32 calculated over
the section (minus the CRC) received.)
Video stream descriptor - Can only refer to video ES (is it allowed at program level)
multiple_frame_rate_flag (1):- Cross verify with video. When set to '0' check that there is only one frame
rate (as defined in frame_rate_code) in the video stream(s) refered to.
frame_rate_code (4): Check that no frames rate(s) higher than that signalled in this field as permitted do
occur.
MPEG_1_only_flag (1): If set to 1, check the associated fields occur,(descriptor_length = 3) and that the
ES described contains ISO/IEC 13818-2. Check associated stream_type takes value 0x02. Check first 4
bits of stream_id coded to 1110. Check constrained_parameter_flag is set to 0. If set to 0 then, check
that fields do not occur (descriptor_length = 1) and that the ES described is an ISO/IEC 11172-2 stream
and stream_type is set to 01. Check first 4 bits of stream_id coded to 1110. Check that
constrained_parameter_flag is same as value for MPEG-1 video data
constrained_parameter_flag .(covered above)
still_picture_flag (1): No test.
profile_and_level_indication (8): check set to same as in video. Check MPEG-2_flag has been set.
52
Page 53 of 100 July 30, 2002
chroma_format (2): cross check with video - must be MPEG-2
frame_rate_extension_flag (1): if set to 0, do nothing. If set to 1, then check that at least one of video
frame rate extension fields is non-zero.
reserved (5): Check set to '1111 1'.
Audio stream descriptor - can only apply to audio stream

Note: descriptor_length checked to be '1'
free_format_flag (1):- cross check with audio bitrate_index field
ID (1):- cross check with audio ID field
layer (2): -cross check with audiolayer field.
reserved (4): Check set to '1111'.
Hierarchy descriptor - can only apply to MPEG-2 streams or programs, except that an embedded layer
could be MPEG1.possibly this could be extended to include private data (dependent on NB comment)
Note: descriptor_length checked to be 4.
hierarchy_type (4):- cross check to video / audio as appropriate; cross check with profile_and_level fields
in video and audio descriptors
hierarchy_layer_index (6): -check the index does not appear more than once in the program definition.
hierarchy_embedded_layer_index (6) - check you can't decode the ES this is attached to unless you
have the ES of the index. Check the ES of the index is present.
hierarchy_priority (6)- check the base layer has the lowest example of all the values which occur. Check
that streams are in ascending order (if this check can be done)
53
Page 54 of 100 July 30, 2002
Registration Descriptor - Can only be treated after the IS is finished
format_identifier (32): Check this is one of the values allocated by the designated registration authority.
additional_identification_info -
Data stream alignment descriptor - can only apply to Video or Audio streams
Note: descriptor_length checked to be '1'.
alignment_type (8): - go into PES packet and check the alignment exists (dependent on Vor A)
Target background grid descriptor - can only apply to video

vertical_size (14); horizontal_size (14): No check.
pel_aspect_ratio (4): check against video sequence header
Video window descriptor - can only apply to video

Question asked if this can only be present if target_background_grid_descriptor present
horizontal_offset (14): This value should not exceed the value of horizontal_size as coded in the
target_background_grid_descriptor when present.
vertical_offset (14): This value should not exceed the value of vertical_size as coded in the
target_background_grid_descriptor when present.
window_priority (4): No check.
Conditional access descriptor - only in PMT or CAT or stream_id field in PS.
CA_system_ID (16): no test
CA_PID (13): Check this is not a reserved PID (0x0002-0x000F or 0x1FFF)
ISO 639 Language descriptor -
54
Page 55 of 100 July 30, 2002
language_code (24): - check values are allocated/permitted according to ISO 639 and ISO 8859-1, and
in order.
audio_type (8): Check this does not take a value outside the given range. If set to 'aa' then check that
elementary stream this describes is video. If set to 'bb-cc' then check that elementary stream this describes
is audio. No check on anything else.
System clock descriptor - only applied on a program level in a PMT

external_clock_reference_indicator (1): No check.
clock_accuracy_integer (6): No check.
clock_accuracy_exponent (3): No check
Multiplex buffer utilization descriptor -

mdv_valid_flag (1): If set to '0' then no test on other fields.
multiplex_delay_variation (15): - see ltw test method??
multiplex_strategy (3): Check not set to 4-7.
Copyright descriptor - applies only to Ess. May only be present if copyright bit set to 1 - ie check this
copyright_identifier (32): check this value is one of those allocated by SC29s designated registration
authority
additional_copyright_info (8): No check.
Maximum bitrate descriptor - can be used at program or ES level

55
Page 56 of 100 July 30, 2002
maximum_bitrate (22): test against the measured rate of the ES or program; test against the bitrate fields
of video and audio if ES.
Private data indicator descriptor -

Note: descriptor_length checked to be '4'. can not be tested
NIT
& if its there it follows the private section syntax
& if its there, its where it is referenced in the PAT under program_number zero.
Descriptors
Certain descriptors can only apply to certain stream types, and may be some only apply to either programs
or elementary streams (Japanese DIS comment results will be relevant here). Some descriptor tags are
reserved. Note specifically that the following are not required for a compliant bitstream.
a. There is no requirement to carry version of sections with the current_next_indicator set to a value of '0'.
b. There is no requirement for the sections of a table to be found in section_number order within the
bitstream.
c. There is no requirement for all sections of a particular version number to be found in the Transport
Stream an equal number of times.
d. There is no requirement for PSI data to be found at any minimum interval.
Bitstream tests for PAT
PID0: Confirm that in the Transport Stream under test , there is at least one Transport Stream packet with
PID==0x0000 and length 188 bytes.
PID(13): Check set to 0x0000.
transport_scrambling_control (2): Check set to '00' - ie not scrambled.
payload_unit_start_indicator (1): If this is set to a value of '1' then the first data byte of the Transport
Packet shall be understood to be a pointer_field. If the payload_unit_start_indicator is set to '0' then no
56
Page 57 of 100 July 30, 2002
pointer_field shall be present in that Trasnport Stream packet and it is not conformant for a section to start
in that Transport Stream packet.
table_id (8): Check that the byte pointed to by the pointer_field takes the value '0x00'.
section_syntax_indicator (1): Check set to '1'.
'0' (1): Check set to '0'.
section_length (8): Check first two bits are set to '00'.
9 <= section_length <= 1021
if section_length == n then byte n+1 == 0x00 or 0xFF (or 0x47 if start of next Transport Stream
packet).
The nth byte of the section shall be checked to be the last byte of of the CRC_32.
transport_stream_id (16): No check on value but should be same in all sections of that version number.
version_number (8); current_next_indicator (8); section_number (8); last_section_number (8):

These fields are analysed together. For this purpose, the following notation is used inthe draft.
A section is denoted with the following attributes:
S(v, c, s,l) where

v is the value of the version_number field
c is the value of the current_next_indicator flag
s is the value of the section_number field of the section
l is the value of the last_section_number field
program_number (16): Check that the program_number field does not take any single value more than
once within all sections of any version of the program association table.
reserved (3): Check these are set to '111'.
If program_number == 0x0000 then

network_PID (13): check that this field does not take any value from 0x0000 - 0x000F. Check also
that it does not take any values identified as Transport Packets carrying video or audio data. Note that it
57
Page 58 of 100 July 30, 2002
is permitted for the network_PID to be the same as a program_map_PID. Check that if there are any
Transport Stream packets with the PID denoted the network_PID then these packets contain
private_sections.
If program_number != 0x0000 then

program_map_PID (13): check that this field does not take any value from 0x0000 - 0x000F and
also does not take the value 0x1FFF. Check also that it does not take any values identified as Transport
Packets carrying video or audio data.
Then check that the PID pointed to contains a TS_program_map_section, with the program_number
field coded the same as the program_number field in the PAT
CRC_32 (32): Check that this is correctly calculated such that the field value gives a zero output of the
registers in the decoded defined in Annex B of part 1 of this International Standard after processing the
entire conditional access section (excluding the CRC field itself.
CONSISTENCY CHECK: Check that the first byte after the last byte of the CRC_32 field in any
Transport Packet with PID==0x0000 takes either the value 0x00 (in which case this is the start of the
following section) or 0x47 (the start of the next Transport Stream packet) or the value 0xFF. If the value of
0xFF is found then check all following bytes to the end of the Transport Packet are also 0xFF.
If the value 0xFF was present then it should be checked that following Transport Packet of PID==0x0000
either i) consists only of adaptation_field
or ii) has the payload_unit_start_indicator set to '1', has the pointer_field set to zero and
then has either a) table_id==0x00, starting a new section; or b) table_id==0xFF, with 0xFF stuffing to
the end of the Transport Packet.
Check that there are no sections with table_id == 00 in any Transport Packet with a PID value other than
0x0000.
If there is a change in the program_number fields of the programs present in the TSUT then it shouldbe
checked that a new version of the PAT is present in the TSUT prior to the change, giving the new
configuration. An example of such a change would be adding a new program, or deleting a program in
order to be able to re-use the program_number.
Check that all the sections of the PAT for a given version_number contain a complete list of all the
programs present within the TSUT. This is done by checking that every section in the TSUT with
table_id==0x02 are listed through their program_numbers in the PAT. ie no sections with table_id==0x02
should be found in the TSUT unless their program number is listed in the PAT.
Program Map Table tests
Program Map Section PIDs
58
Page 59 of 100 July 30, 2002
The entries of the program_association_table should be used to obtain the values of PM PIDs. Each
separate PM PID should then be checked with this procedure to ensure the PSI is compliant. Check that
PID consists of sections, including for any private data.
transport_scrambling_control_flags (2):Check they are set to '00' - ie not scrambled.
payload_unit_start_indicator (1): If set to a value of '1' in a Transport Stream packet of PMT_PID then
the first data byte of the Transport Packet shall be assumed to be a pointer_field. If set to '0' then no
pointer_field shall be present in that Transport Stream packet and it is not conformant for a section to start
in that Transport Stream packet.
table_id (8): Check this does not take a value 0x00, 0x01 or 0x03-0x3F. If table_id 0xFF appears then
check that stuffing occurs to the end of the Transport Packet. Only sections with table_id value 0x02 are
then to be subject to the following tests, as only they are TS_program_map_sections. (Other sections may
be private sections).
section_syntax_indicator (1): Check this is set to '1'.
'0' (1): Check set to '0'.
section_length (8): Check that first two bits are coded '00'.
if section_length == n then byte n+1 == next table_id value, (or 0x47 if new Transport Stream
packet)
program_number (16): Check this is coded to be the same as one of the values of program_number listed
in the PAT as having the PMT_PID value which is the same as the PID value in which the section is found.
Check that this field does not take the value 0x0000, which is reserved for the NIT.
version_number (8); current_next_indicator (1); section_number (8); last_section_number (8): These

fields are analysed together. For this purpose, the following notation is used inthe draft.
S(v, c, s,l) where
59
Page 60 of 100 July 30, 2002

PCR_PID (13): Check that in the adaptation_field s in the Transport Stream packets having a PID the
same as the PCR_PID, a PCR occurs with the required regularity - see the part of this document which
defines how to test for correct PCRs.
program_info_length (12): Check that the first two bits are coded '00'. Check that when this length
field is assumed to be correct, then along with the descriptor lengths, the CRC_32 field is shown to be
correct. This length only codes the length of the immediately following descriptors.
descriptor ():To test each individual descriptor, see the section on descriptors below, however, at this
point check that only descriptors listed as being permitted at 'program level' are included here, or private
descriptors (those with tags 64-255).
The program_info_length is assumed to be correct. The length specified by this field is counted over, and
the next field is assumed to be a stream_type byte.
stream_type (8): Check that the stream_type field does not take the following values:
0x00, 0x0A-0x7F.
• If the field takes the value 0x01, check that the Transport Stream packets of the PID listed in the next
elementary_PID contain ISO/IEC 11172-2 data.
elementary_PID contain ISO/IEC 13818-1 data in private_sections.
60
Page 61 of 100 July 30, 2002
elementary_PID contain data in ISO/IEC 13818-1 PES packet form.
elementary_PID contain ISO/IEC 13522 data.
elementary_PID contain ISO/IEC 13818-1 DSM-CC data, as defined in normative Annex A of that
standard.
elementary_PID contain ISO/IEC 13818-1 or 11172-1 auxiliary data.
elementary_PID (13): Check that this field never takes the values 0x0000- 0x000F or 0x1FFF.
ES_info_length (12): Check that the first two bits are coded '00'. Assume that the length field is coded
correctly in each loop over descriptors.
descriptor ():To test each individual descriptor, see the section on descriptors below, however, at this
point check that only descriptors listed as being permitted at 'ES level' are included here, or private
CRC_32 (32): Assuming that all the length fields were correct, check that the four bytes after the last
descriptor byte in the last loop of ES descriptors are the same as a CRC_32 calculated over the whole
section excluding these bytes.
Conditional Access Table tests

PID 1
PID (13): Check set to '0x0001'.
transport_scrambling_control (2): Check set to '00' .ie. not scrambled.
payload_unit_start_indicator (1): If set to a value of '1' in a Transport Stream packet of PID==0x0001

then the first data byte of the Transport Packet shall be assumed to be a pointer_field. If the
payload_unit_start_indicator is set to '0' then no pointer_field shall be present in that Transport Stream
packet and it is not conformant for a section to start in that Transport Stream packet.
table_id (8): Check that the byte pointed to by the pointer_field takes the value '0x01' ie table_id=0x01
61
Page 62 of 100 July 30, 2002
section_syntax_indicator (1): Check this is set to '1'.
'0' (1): Check set to '0'.
section_length (8): Check first two bits are set to '00'.
if section_length == n then byte n+1 == 0x01 or 0xFF (or 0x47 in the case of this being the start of
the next Transport Stream packet)
reserved (18): Check set to '1111 1111 1111 1111 11'.
version_number (8); current_next_indicator (8); section_number (8); last_section_number (8):

These fields are analysed together. The same rules apply for this as for program_association_sections
above.
descriptor() :To test each individual descriptor, see the section on descriptors below, however, at this
point check that only descriptors listed as being permitted here are included here,( or private descriptors
(those with tags 64-255).
There should be sufficient cases of the CA_descriptor to identify program related access control
information for all scrambled streams. Since the content of the descriptor is primarily private, it is not
possible to verify whether this private data is 'correct' or not.
CRC_32 (32): Check that the CRC_32 field is correctly caluclated such that the field value gives a zero
output of the registers in the decoded defined in Annex B of part 1 of this standard after processing the
entire conditional access section.
CONSISTENCY CHECK: Check that the first byte after the last byte of the CRC_32 field in any
Transport Packet with PID==0x0001 takes either the value 0x01 (in which case this is the start of the
following section) or the value 0xFF. If the value of 0xFF is found then check all following bytes to the
end of the Transport Packet are also 0xFF.
If the value 0xFF was present then the it should be checked that following Transport Packet of
PID==0x0001 either i) consists only of adaptation_field
or ii) has the payload_unit_start_indicator set to '1', has the pointer_field set to zero and
then has either a) table_id==0x01, starting a new section
62
Page 63 of 100 July 30, 2002
or b) table_id==0xFF, with 0xFF stuffing to the end of the Transport Packet.
If no section started in the following Transport Packet, then the same test should be carried out untila
Transport Packet is found with the table_id==0x01 condition is found.
PID CHECK: Check that there are no sections with table_id == 01 in any Transport Packet with a PID
value other than 0x0001.
Network Information Table tests
Network Information Table (private section also in this file)
If in the PAT, a program_number == 0x0000 occurs, then a check should be made for a network
information table.
Check for any Transport Stream packets with a PID value of NIT as indicated in the PAT.
transport_scrambling_control (2): If flags set to a value other than '00' then no further tests are required.
Otherwise, the assumption should be made that such packets are in section format.
payload_unit_start_indicator (1): When set to '1' then the first byte of the payload should be assumed
to be a pointer field. This pointer should be used to identify the first byte of a section (table_id)
table_id (8): Check it takes a value other than 0x00- 0x3F. If table_id is 0xFF then check that the rest of
the Transport Stream packet is also filled with 0xFF bytes too. Otherwise the next test should be
carried out on section_length field.
section_length (8): Assume this is correct. Using this information, skip over the full length of the
section. The next byte should not take a value 0x00-0x3F as in 3. Continue to repeat the procedure of
payload_unit_start_indicator and section_length checks until either a value of 0xFF is found as a first
section byte (table_id), or until a section is found to end at the end of a Transport Stream packet.
Note 1: Sections may be continued within the payload of several consecutive Transport Stream packets of
the same PID. Note also that when the payload_unit_start_indicator is set, this signals that a new section
starts within the Transport Stream packet, and therefore the first byte of the payload must be assumed to
be a pointer field which implies two things to be checked:
i) that the section data is interrupted by a pointer field, and that this has been taken into account in
calculating where a section should end.
ii) that if a section does start in a Transport Stream packet, then the pointer is present, the
payload_unit_start_indicator is set to '1', and the pointer does point to the first byte of the first section to
start within the Transport Stream packet.
63
Page 64 of 100 July 30, 2002
Note 2: It need not be checked whether the NIT conforms to the short or the long private_section syntax,
since this is not a compliance issue - only the first 'short' part need be present.
Private Section
If Transport Stream packet PIDs are listed in a program definition as containing private data in section
form, then the following check should be performed.
payload_unit_start_indicator (1): If set to '1' in such a Transport Stream packet, then assume that the
first byte of the payload of that Transport Stream packet is a pointer field. Use this pointer field to find the
first byte of a section.
transport_scrambling_control (2): If set to anything other than '00', then no further check. If these
sections occur in Transport Stream packets which are listed in the PAT as being PMT_PIDs then the
transport_scrambling_control flags shall be set to '00' to be compliant.
table_id (8): Check this does not take one of the table_id values 0x00-0x3F. If coded to 0xFF then check
that all other bytes to the end of the Transport Stream packet also take the value 0xFF.
section_syntax_indicator (1): If this bit is set to '1' then test all fields following. If this bit is set to '0'
then skip tests till CONSISTENCY CHECK.
private_indicator (1): No test.
private_section_length (12): Assumed to be correct and used later.
table_id_extension (16): No test.
version_number (5), current_next_indicator (1), section_number (8), last_section_number (8) : These

fields are analysed together. For this purpose, the following notation is used inthe draft.
S(v, c, s,l) where

64
Page 65 of 100 July 30, 2002
The private_section_length field is then used to identify the end of the section.
CRC_32 (32): Check these are the same as a CRC 32 calculated over the whole of the section (excluding
those four bytes).
CONSISTENCY CHECK: Assume the private_section_length field is correct, and use it to skip to the
table_id of the next section. If this is in the following Transport Stream packet check that the
payload_unit_start_indicator is set to '1' and that the pointer field in that Transport Stream packet also
points to the start of the next section. Repeat procedure on next section.
Real Time Interface
Assumptions
This text assumes an RTI specification that is developed along the lines of ..... The actual parameters of
the interface may be changed before the finalization of the text. These parameters (clock accuracy, slew
rate, and PCR jitter) are referred to in the text below by variable names, D_f, R_slew, and t_jitter,
respectively. The formulas that tie these parameters to certain buffer sizes, however, are supposed to
remain fundamentally unchanged.
Objectives
The objectives of a testing procedure for the RTI specification are the following:
1. Test for compliance with the frequency accuracy spec.

2. Test for compliance with the slew rate spec.
3. Test for compliance with the PCR jitter spec.
4. Test for compliance with the buffer requirements.
For some streams, all of these requirements cannot be reached in the sense that it's not possible to measure
them accurately enough or to separate them from each other. In principle, it can be said that streams need
to have a certain length for the concept of compliance with all four points to have any meaning. The
procedures for the different objectives are outlined briefly below.
Procedure
Frequency Accuracy, Slew Rate, and PCR jitter
1. The compliance test is carried out for one program at a time. The rest of the procedure is described
for one program called P.
2. For each byte that carries the last bit of a PCR field for P, the arrival time of that byte and the value of
the corresponding PCR itself are noted. These values are called t(i) and PCR(i), respectively.
65
Page 66 of 100 July 30, 2002
3. When all PCR values in the segment of stream to be tested have been noted, these are plotted against
their arrival values.
4. The stream is now compliant if a graph can be drawn such that its slope in each point is compliant
with the requirement for STC frequency
5. accuracy; its curvature in each point is compliant with the requirement for maximum STC frequency
slew; andits vertical distance to any of the points (t(i), PCR(i)) is not greater than t_jitter in any case.
Finding a graph such as in d. will sometimes be difficult. A stream is compliant whenever such a graph
can be found, and a stream is not proven non-compliant until it can be proven that no such graph exists.
This can be proven in some cases by for example taking a suspect point (t(i), PCR(i)) and draw a region
which includes all other permissible points in the bitstream . If another point falls outside that region, the
stream is non-compliant. A stream shall be assumed to be compliant unless it can be proven to be
non-compliant.
Buffer Compliance
The buffer compliance test shall be performed exactly as the corresponding test for the T-STD, except for
obvious changes due to different arrival times and buffer sizes, as well as the extra requirement for TB_r
occupancy at the start of Transport Stream Packets.
System bitstream tests for Program Stream
Tests on the pack level
system_clock_reference: in successive packs, the system_clock_ reference field contains encoded values
which are samples of a nominal 27MHz system clock. The maximum interval between system_clock_
reference fields is limited by the difference between encoded values in successive packs; this difference
shall not exceed 0,7*90 000, as specified in xxxx of ITU-T Rec. H.222.0 | ISO/IEC 13818-1.
mux_rate (1): the value encoded in the mux_rate field shall be sufficently large that, if all bytes in the
pack are transmitted at that rate, they are delivered to the system target decoder before the time the first
byte of the subsequent pack is delivered. The time that the first byte of the subsequent pack is delivered
may be derived from the system_clock_reference and mux_rate fields in that subsequent pack.
mux_rate (2): the mux_rate field shall not be encoded with the value zero.
packet rate: if the CSPS_flag in the system header is set to '1' and the rate specified in the mux_rate field
is less than 4.5 Mbit/s then the rate at which packets arrive at the input of the system target decoder shall
be less than 300 packets/s. If CSPS_flag is set to '1' and the rate specified in the mux_rate field is greater
than 4.5 Mbit/s, the packet rate is bounded by a linear relation to the value encoded in the mux_rate field,
as specified in 2.7.9 of ITU-T Rec. H.222.0 | ISO/IEC 13818-1.
66
Page 67 of 100 July 30, 2002
length of a pack: the length of a pack may be determined by counting the bytes between successive pack
start codes.
length of a packet: the length of a packet may be determined by counting the bytes between successive
packet start codes.
Tests on the system header
general test (1): the first pack of an ISO/IEC 13818 stream shall contain a system header.
general test (2): a system header, if present in a pack, shall immediately follow the pack header.
general test (3): if an ISO/IEC 13818 stream contains more than one system header, then the values
encoded in all the headers shall be identical.
header_length: the header_length field shall be encoded with a value equal to the number of bytes in the
system header that follow the header_length field.
rate_bound: the rate_bound field shall denote a bitrate which is greater than or equal to the maximum
bitrate value encoded in any mux_rate field in the same ISO/IEC 13818 stream.
audio_bound (1): the value encoded in the audio_bound field shall be greater than or equal to the
maximum number of simultaneously active ISO/IEC 13818-3 audio streams in the ISO/IEC 13818 stream.
For the purpose of this clause, an ISO/IEC 13818-3 audio stream is active if :
a) the input buffer of the system target decoder of that ISO/IEC 13818-3 audio stream is not empty, or if
b) one of the presentation units decoded from that ISO/IEC 13818-3 audio stream is being presented.
audio_bound (2): the value encoded in the audio_bound field shall be less than or equal to 32.
fixed_flag: if the fixed_flag is set to "1", then the values encoded in all system_clock_ reference fields
shall satisfy 2.4.4.2 in ISO/IEC 13818-1.
CSPS_flag: if the CSPS_flag is set to "1", then the packet rate and the system target decoder buffer size
shall satisfy 2.4.6 in ISO/IEC 13818-1.
system_audio_lock_flag: if the system_audio_lock_flag is set to "1", then the difference between the
values encoded in any two presentation_time_stamp fields in audio packets of the same ISO/IEC 13818-3
audio stream shall correspond to the duration of the decoded audio access units in that ISO/IEC 13818-3
audio stream. For this purpose the duration (in terms of units of the system clock frequency) shall be
derived from the number of samples and the sampling frequency of the decoded access units and the ratio
SCASR as specified in 2.4.4.2 of ISO/IEC 13818-1. This assumes that no discontinuities occurred in the
67
Page 68 of 100 July 30, 2002
ISO/IEC 13818-3 audio stream in the presentation of the access units during the presentation period
defined by both fields. See 2.4.5.4 of ISO/IEC 13818-1 for the definition of discontinuities.
system_video_lock_flag: if the system_video_lock_flag is set to "1", then the difference between the
values encoded in any two presentation_time_stamp fields in video packets of the same ISO/IEC 13818-2
video stream shall correspond to the duration of the decoded pictures in that ISO/IEC 13818-2 video
stream. For this purpose the duration (in terms of units of the system clock frequency) shall be derived
from the picture rate of the decoded pictures and the ratio SCPR as specified in 2.4.4.2 of ISO/IEC
13818-1. This assumes that no discontinuities occurred in the ISO/IEC 13818-2 video stream in the
presentation of the access units during the presentation period defined by both fields. See 2.4.5.4 of
ISO/IEC 13818-1 for the definition of discontinuities.
video_bound (1): the value encoded in the video_bound field shall be greater than or equal to the
maximum number of simultaneously active ISO/IEC 13818-2 video streams in the ISO/IEC 13818 stream.
For the purpose of this clause, an ISO/IEC 13818-2 video stream is active if:
a) the input buffer of the system target decoder of that ISO/IEC 13818-2 video stream is not empty, or if
b) the reorder buffer of the system target decoder of that ISO/IEC 13818-2 video stream is not empty, or
if
c) one of the presentation units decoded from that ISO/IEC 13818-2 video stream is being presented.
video_bound (2): the value encoded in the audio_bound field shall be less than or equal to 16.
stream_id (1): the value encoded in the stream_id field shall be one of the values permitted by table 2-18
(stream_id) in 2.4.3.7 in ISO/IEC 13818-1.
stream_id (2): the stream_id mechanism refers exactly once to each elementary stream in the multiplex.
STD_buffer_bound_scale: if the stream_id shall refer to an ISO/IEC 13818-3 audio stream, the
STD_buffer_bound_scale shall be set to "0". If the stream_id refers to an ISO/IEC 13818-2 video stream,
the STD_buffer_bound_scale shall be set to "1".
STD_buffer_size_bound: in the STD_buffer_size_bound field a value shall be encoded greater than or

equal to the maximum value encoded in any of the STD_buffer_size fields in packets of the same
elementary stream.
Tests on Program Stream Map
packet_start_code_prefix (24): Check takes the value '0x000001'.
map_stream_id (8): Check coded '0xBC'.
68
Page 69 of 100 July 30, 2002
program_stream_map_length (16):Check they do not contain a value greater than 1018. Assume the
value coded to be correct.
current_next_indicator (1): The value of this bit is considered with

program_stream_map_version
reserved (2):Check the next two bits are '11'.
program_stream_map_version (5):This is analysed in conjunction with the current_next_indicator. Any

value of either field is permitted within the Program Stream, but the order in which they occur is restricted,
and should be tested as follows.
If version number v with current_next_indicator set to '0' is encountered then check that it is only followed
by a PSM with version number v and current_next_indicator set to '1', with identical data.
If version_number v with current_next_indicator set to '1' is encountered then check that it is only
followed by one of the following:
i) an identical copy of itself
ii) a PSM with version number v+1 with current_next_indicator set to '1' or '0'
reserved (7): Check coded '1111 111'.
marker_bit (1): Check coded '1'.
program_stream_info_length (16): Check that when this length field is assumed to be correct, then along
with the descriptor lengths and other length fields, the CRC_32 field is shown to be correct. This length
only codes the length of the immediately following descriptors.
descriptor():
To test each individual descriptor, see the section on descriptors below, however, at this point check that
only descriptors listed as being permitted at 'program level' are included here, or private descriptors (those
with tags 64-255).
The program_info_length is assumed to be correct. The length specified by this field is counted over, and
the next field is assumed to be a elementary_stream_map_length.
elementary_stream_map_length (16): Assume this length to be correct each time it occurs.
stream_type (8): Check that the stream_type field does not take the following values: 0x00, 0x05,
0x0A-0x7F.
69
Page 70 of 100 July 30, 2002
elementary_stream_id (8): Check that this does not take one of the following values: '1011 1100'; '1111
0100'-'1111 1111'.
• Check that there is no contradiction between the elementary_stream_id and the stream_type fields:
• If the stream_type field takes the value 0x01, check that the elementary_stream_id takes a value '1110
xxxx' and that PES packets with a stream_id equal to the elementary_stream_id contain ISO/IEC
11172-2 data.
13818-2 data.
• If the stream_type field takes the value 0x03, check that the elementary_stream_id takes a value '110x
11172-3 data.
• If the stream_type field takes the value 0x04, check that the elementary_stream_id takes a value '110x
13818-2 data.
1101' or '1011 1111' and that PES packets with a stream_id equal to the elementary_stream_id
contain ISO/IEC 11172-1 or 13818-1 private_stream_1 or private_stream_2 data.
0011' and that PES packets with a stream_id equal to the elementary_stream_id contain ISO/IEC
13522 data.
0010' and that PES packets with a stream_id equal to the elementary_stream_id contain ISO/IEC
13818-1 DSM-CC data, as specified in normative Annex A of that standard.
• If the stream_type field takes the value 0x09, check that, if the elementary_stream_id takes a value
'1111 1111' then PES packets with a stream_id equal to the elementary_stream_id contain a ISO/IEC
13818-1 program_stream_directory, or if the elementary_stream_id takes a value '1011 1011' then
PES packets with a stream_id equal to the elementary_stream_id contain a ISO/IEC 13818-1 or
11172-1 system_header, or if the elementary_stream_id takes a value '1011 1010' then PES packets
with a stream_id equal to the elementary_stream_id contain a ISO/IEC 13818-1 or 11172-1
pack_header.
70
Page 71 of 100 July 30, 2002
elementary_stream_info_length (16): Check that when this length field is assumed to be correct, then
along with the descriptor lengths and other length fields, the CRC_32 field is shown to be correct. This
length only codes the length of the immediately following descriptors.
descriptors():
To test each individual descriptor, see the section on descriptors below, however, at this point check that
only descriptors listed as being permitted at 'elementary stream level' are included here, or private
The elementary_stream_info_length is assumed to be correct. The length specified by this field is counted
over, and the next field is assumed to be a stream_type. Repeat from stream_type entry.
CRC_32 (32): Assuming that all the length fields were correct, check that the four bytes after the last
descriptor byte in the last loop of ES descriptors are the same as a CRC_32 calculated over the whole
section excluding these bytes.
Tests on Program Stream Directory
packet_start_code_prefix (24): Check they are coded '0x000001'.
stream_id (8): Check coded 'FF'
PES_packet_length (16): Count to the end of the PES packet assuming the PES_packet_length field
to be correct, and check that the following three bytes are coded '0x000001'. Then test with next field.
number_of_access_units (15): .Check that PES_packet_length is equal to 14 + (18 x

number_of_access_units).
reserved (1): check set to '1'.
previous_directory_offset (48): Bits 16, 32, and 48 should be checked to be '1'. It should be checked
that at least one of the other bits is non-zero, or else there should have been no previous PSD in the
Program Stream. Check that the 45 bits of the previous directory offset fields together correctly indicate
the first byte of the previous PES packet which contained a Program Stream Directory.
next directory offset (48): Bits 16, 32, and 48 should be checked to be '1'. It should be checked that at
least one of the other bits is non-zero, or else it should be checked that there is no subsequent PSD within
the Program Stream. Check that the 45 bits of the next directory offset together correctly indicate the first
byte of the next PES packet which contains a program stream directory.
71
Page 72 of 100 July 30, 2002
The following 18 bytes all refer to a single access unit, and the fields should be repeated once for each
access unit signalled in the number_of_access_units field.
packet_stream_id (8): check they do not take any value but one of the following:'110x xxxx'; '1110
xxxx'.
PES_header_position_offset_sign (1): May be set to any value. It is considered in conjunction with the
PES header position offset fields which follow.
PES_header_position_offset (47): Bits 15, 31 and 47 should be checked as being '1'. The other 44 bits
should be checked to together correctly give the byte offset of a PES packet of stream_id =
packet_stream_id containing the first byte of an access unit. The PES packet follows the directory if the
PES_header_position_offset_sign is coded '0', and preceeds it if the sign is coded '1'. If the
PES_header_position_offset is coded to '0' then there is no test.
reference_offset (16): Check to point to the first byte of the access unit relative to the first byte of the PES
packet (ie packet_start_code_prefix) signalled to contain the access unit.
marker_bit (1): Check to be '1'.
reserved (3): Check to be '111'.
PTS (36): Bits 4, 20 and 36 should be checked as being '1'. The other bits should be considered together as
a PTS. Its coding should be checked according to the check for PTSs defined elsewhere within this CD.
bytes_to_read (24): Bit 16 should be checked as being '1'. The other bits should be considered together
as the number of bytes to be read to completely decode the access unit refered to. It should be checked
that this is the case.
marker_bit (1): Check to be '1'.
intra_coded_indicator (1): If set to '1', check that the access unit pointed to is predictively coded, and if
coded to '0' then check the access unit is not be predictively coded.
coding_parameters_indicator (2): need not be checked.
reserved (4): Check coded as '1111'.
Tests on timing accuracy
72
Page 73 of 100 July 30, 2002
The entire ISO/IEC 13818 stream shall be constructed so that, in addition to meeting all other
requirements, when the values and semantics of the presentation_time_stamp fields are compared with the
audio and video samples to which they refer and their nominal sample rates, the calculated tolerance
betweeen the actual sample frequency and the system_clock_frequency shall not exceed 100 parts per
million. The timing relationships can be verified in practice solely by examining the bitstream. For
example, to verify that the relationship between the audio sample rate and the system clock frequency
meets this constraint, the following test can be performed:
a) Determine the nominal audio sample frequency as specified in the audio bitstream.
b) Find a PTS (PTS1) associated with audio and the sample it refers to.
c) Count the number of audio samples until any other PTS (PTS2) is found that refers to audio in the
same stream, as long as no discontinuities occur between these two points.
d) Find the value of that second PTS (PTS2), and the difference between PTS2 and PTS1.
e) Calculate the effective audio sample rate by dividing the number of samples passed by the difference
in time as indicated by the PTSs (PTS2 minus PTS1) times 1/27 000 000).
f) If the calculated sample rate differs from the nominal by more than 100 ppm (allowing for integer
arithmetic rounding effects) then this bitstream is not compliant.
Buffer overflow/underflow test
ISO/IEC 13818-1 specifies the requirement for the bitstream to be decodable by a System Target Decoder
(STD). This means that, using the hypothetical STD model, when all audio and video streams are
decoded and presented with exact synchronisation as specified by the respective Presentation Time Stamps,
the STD buffers never underflow nor overflow. In other words, all bytes required for decoding audio and
video are present in the STD buffers when they are needed, and the STD buffers are never filled beyond
the capacity of the STD buffer sizes specified. The STD model is defined and described in 2.4.2 of
ISO/IEC 13818-1.
In an ISO/IEC 13818 multiplexed bitstream, the buffer control mechanism specified for ISO/IEC 13818-2
video, using the vbv_delay field and the VBV model, is not directly applicable. In this case it is
superseded by the STD model. The STD model allows for direct decoding of elementary streams from
the multiplexed stream without the need to reconstruct the elementary streams first. However, it is
possible to reconstruct elementary streams from the multiplex. In the case that an ISO/IEC 13818-2
video stream is reconstructed from the multiplexed stream, the VBV model again becomes applicable.
For buffer overflow/underflow tests in cases where the VBV model is applicable, see 2.5.2.3.
73
Page 74 of 100 July 30, 2002
Underflow and overflow of the STD buffer may be tested by constructing an STD model decoder. The
test need not be performed in real time. For example, to test the behaviour of the STD video buffer, a test
may be performed as follows:
a) The STD test model has a 90kHz time base (the system_clock_frequency) which is used to increment
a counter.
b) Begin parsing the ISO/IEC 13818 stream starting at the first byte.
c) When a pack header is encountered, the system clock reference (SCR) is extracted, converted to its
33 bit value, and loaded onto a counter variable called System Time Clock which is incremented by the
90kHz time base.
d) Also from the pack header, extract the mux_rate field.
e) Calculate the number of bytes per unit of increments of the 27MHz time base as an accurate ratio of
mux_rate to 27 MHz (not an integer ratio). Note that mux_rate is coded in units of 50 bytes/s.
f) Read data from the source into the input buffer of the system target decoder at the rate indicated by
the ratio of mux_rate to 27 MHz, calculated in step e). Note that accuracy must be maintained over the
course of the bitstream, and the average number of bytes per system clock frequency increment is in
general not an integer.
g) When packets of the video stream under test are encountered, the STD_buffer_scale and
STD_buffer_size are extracted and converted to the STD buffer size in bytes. This is subsequently used
as the upper limit on the STD buffer fullness. Presentation_time_ stamps and decoding_time_stamps are
extracted and stored temporarily.
h) All packet_data bytes from the video stream under test are put into a fifo buffer in the order that they
are received. This buffer is at least as large as the STD_buffer_size as specified for this stream in the
packet header.
i) When a PTS or DTS is extracted, the PTS or DTS is saved temporarily until a video
picture_start_code is encountered, and then the PTS or DTS is associated with the coded picture that
immediately follows that picture_start_code. Note that if only the PTS is coded, the value of the DTS
equals the value of the PTS.
j) When the System Time Clock value equals the DTS value of the picture that has been in the STD
buffer the longest, the data of that coded picture is removed instantaneously from the STD buffer as
specified in 2.4.2 in ISO/IEC 13818-1.
k) For a coded picture which has no DTS associated with it, the value of the DTS is derived from:
74
Page 75 of 100 July 30, 2002
• the DTS of the last coded picture to which a PTS or DTS is associated; this coded picture is referred to
as coded picture (n);
• the number (k) of coded pictures between coded picture (n) and the current coded picture;
• the picture rate as encoded in the picture_rate field in the video sequence_header for the coded
pictures between coded picture (n) and the current picture;
• the derived DTS value is the sum of the previous coded DTS, which may have been implied by a
coded PTS value, and the product of the number of succeeding pictures (k) and the picture period in
units of (1/90 000) seconds.
75
Page 76 of 100 July 30, 2002
l) Compliance requires that the STD buffer neither overflows nor underflows.
Such a region could be e.g. a truncated wedge with corners in (t(i), PCR(i) + t_jitter) and (t(i),
PCR(i)-t_jitter) and upper and lower sides that have slopes corresponding to the maximum and minimum
permissible frequency, respectively.
76
Page 77 of 100 July 30, 2002
Video bitstream tests
Global tests of Profiles and Levels
Tests on the sequence header
horizontal_size (1): the value encoded in the horizontal_size field shall be at least 1.
horizontal_size (2): in 4:2:0 and 4:2:2 chroma structure sequences, horizontal_size must be a multiple of
2.
horizontal_size (3): within a video sequence, all horizontal_size fields shall be encoded with the same
value.
horizontal_size (4): horizontal and vertical sizes are checked not to be a multiple of 4096.
vertical_size (1): the value encoded in the vertical_size field shall be at least 1.
vertical_size (2): In a frame picture, the derived value mb_height is checked against the actual number of
coded macroblocks in the bitstream such that the line count is a multiple of 16. In field pictures, it is
checked to be a multiple of 32.
vertical_size (3): within a video sequence, all vertical_size fields shall be encoded with the same value.
vertical_size (4): in 4:2:0 chroma structure sequences with progressive_sequence==1, vertical_size must
be a multiple of 2.
vertical_size (5): in 4:2:0 chroma structure sequences with progressive_sequence==0, vertical_size must
be a multiple of 4.
vertical_size (6): in 4:2:2 and 4:4:4 chroma structure sequences with progressive_sequence==0,
vertical_size must be a multiple of 2.
aspect_ratio_information (1): the binary value encoded in the aspect_ratio_information field shall be in
the range from 0001 up to 0100
frame_rate_code (1): the binary value encoded in the picture_rate field shall be in the range from 0001
up to 1000.
frame_rate_code (2): The value, frame_rate, calculated by:
frame_rate = frame_rate_code * (frame_rate_extension_n+1)/(frame_rate_extension_d+1)
77
Page 78 of 100 July 30, 2002
is checked such that it could not be represented by an entry in ISO/IEC DIS 13818-2 Table 6.4
frame_rate_extension_n, frame_rate_extension_d (1): frame_rate_extension_n and

frame_rate_extentsion_d shall not have the same value except if both have '0' value.
frame_rate (3): within a video sequence, all frame_rate shall have the same value.
bit_rate (1): the value encoded in the bit_rate field shall not be equal to zero.
bit_rate (2): within a video sequence, all bit_rate fields shall be encoded with the same value.
vbv_buffer_size (1): within a video sequence, all vbv_buffer_size fields shall be encoded with the same
value.
constrained_parameter_flag: within a 13818-2 video sequence, all constrained_parameter_flag fields

shall have value '0'
intra_quantizer_matrix (1): the intra_quantizer_matrix field shall contain no values of intra_quant[i][j]

equal to zero.
intra_quantizer matrix (2): the value of intra_quant[0][0] shall be equal to 8.
non_intra_quantizer_matrix (1): the non_intra_quantizer_matrix field shall contain no values of

non_intra_quant[i][j] equal to zero.
user_data: user data shall not contain a string of 23 or more zero bits.
profile_and_level_indication (1): shall be a legal profile and level combination specified in ISO/IEC
13818-2 Chapter 8.
chroma_format(1): shall be in the range 01 to 11.
chroma_format(2): shall be consistent with Profile and Level indication.
low_delay(1): shall be consistent with Profile and Level indication.
video_format(1): shall be in the range 000 to 101.
colour_primaries(1): shall be in the range 0000 0001 and 0000 0010 or 0000 0100 and 0000 0111
transfer_characteristics(1): shall be in the range 0000 0001 and 0000 1000 or 0000 0100 and 0000
0111
78
Page 79 of 100 July 30, 2002
matrix_coefficients(1): shall be in the range 0000 0001 and 0000 0010 or 0000 0100 and 0000 0111
Tests on the group of pictures layer
In this section, a number of parameters are used. The values of these parameters are obtained from the
values encoded in the time_code fields at the Group of Pictures layer and in the picture_rate field in the
Sequence Header as follows:
M is the value encoded in the time_code_minutes field;
S is the value encoded in the time_code_seconds field;
P is the value encoded in the picture_rate field in the sequence header, rounded to the nearest
integer number.
drop_frame_flag: the drop_frame_flag may only be set to "1", if the picture_rate field in the Sequence
Header indicates a picture rate of 29,97 Hz.
time_code_hours: the value encoded in the time_code_hours field shall be in the range from zero up to
23.
time_code_minutes: the value encoded in the time_code_minutes field shall be in the range from zero up
to 59.
time_code_seconds: the value encoded in the time_code_seconds field shall be in the range from zero up
to 59.
time_code_pictures: the value encoded in the time_code_pictures field shall be in the range from F0 up to
(P-1), where
F0 = 2 , if the drop_frame_flag is set to "1" and S = 0 and M % 10 _ 0
=0 otherwise.
time_code: the time_code field shall be encoded in compliance with ISO/IEC 13818-2.
user_data: user data shall not contain a string of 23 or more zero bits.
Tests on the picture layer
temporal_reference (1): for the first picture, in display order, within a Group of Pictures the
temporal_reference field shall be encoded with the value zero.
79
Page 80 of 100 July 30, 2002
temporal_reference (2): the value encoded in the temporal_reference field shall be the display order
number modulo 1024 of the frame within the Group of Pictures.
temporal_reference (3):In the second field of a field-coded picture, temporal_reference should have the
same value as the first coded field.
picture_coding_type (1): the binary value encoded in the picture_coding_type field shall be in the range
from 001 up to 011.
picture_coding_type (2): the last picture, in display order, of a Group of Pictures shall be an I-, P picture
picture_coding_type (3): if a Group of Pictures contains at least two pictures of type I or P, the last two
of which have coding order numbers m and n, then all B-pictures with coding order numbers m+1, ..., n-1
shall also be included in the Group of Pictures.
picture_coding_type (4): Let m and n be the natural display order of any I- or P-pictures and j and k be
the decoding order. If m>n, then j>k and vice-versa.
picture_coding_type (4): A sequence shall contain at least one I or P picture.
picture_coding_type (5): Both fields in an interlaced picture shall have the same coding type with the
exception that an Intra-field may have a P field-picture as the second field of the pair.
picture_coding_type (6): B pictures (011) shall not occur in Simple Profile or low delay sequences
vbv_delay (1): if the bit_rate field in the Sequence Header indicates variable bitrate operation, then the
vbv_delay field shall be encoded with the hexadecimal value FFFF.
vbv_delay (2): if the bit_rate field in the Sequence Header indicates constant bitrate operation, then the
vbv_delay field shall be encoded such that neither overflow nor underflow occurs in the VBV buffer.
Overflow and underflow do not occur, if the following conditions apply:
a) all bytes of picture (i) shall arrive before picture (i) is to be decoded.
N(i) / R _ V(i) / 90 000,
where
i indicates the number of the picture in coding order
N(i) is the number of bits after the final byte of the picture start code
of picture (i) that are removed from the VBV buffer at decoding of picture (i)
(see also ISO/IEC 11172-2, annex C)
80
Page 81 of 100 July 30, 2002
R is the bitrate in bits/s, derived from the bit_rate field as encoded in the
sequence header
V(i) is the value encoded in the vbv_delay field of picture (i) in units of the 90
kHz system clock
b) the bitrate at which all picture data are delivered shall be constant.
N(i)/T(i) = R(i)
where
i as specified in a)
N(i) as specified in a)
T(i) is the elapsed time in seconds between the arrival of the final bytes of the
two successive picture start codes of pictures (i) and (i+1), as derived from :
T(i) = (V(i)/90 000) + (1/P) - (V(i+1)/90 000),
where
V(i) is the value of the vbv_delay of picture (i), as encoded in
the vbv_delay field of picture i in units of the 90 kHz system
clock
P is the picture rate
R(i) is the bitrate in bits/s during delivery of the coded data of picture (i) applied
by the encoder. The encoder used constant bitrate operation. The value of R(i)
found from this formula should therefore be constant for each picture (i) within
the accuracy constraints of the parameters. If underflow occurs for picture (i), a
higher value of R(i) is found. R(i) rounded upwards equals R, the value
encoded in the Sequence Header in units of 400 bits/s.
c) the number of bits in the VBV buffer immediately before picture (i) is decoded shall be less
than the size of the VBV buffer.
H(i) + V(i)*R(i)/90 000 _ B(vbv),
where
i as specified in a)
81
Page 82 of 100 July 30, 2002
H(i) is the number of bits of the picture start code and any preceding (header)
data that is removed instantaneously at decoding of picture (i); see annex C of
ISO/IEC 11172-2.
V(i) as specified in a)
R(i) as specified in b)
B(vbv) is the value of the vbv_buffer_size in bits
forward_f_code, backward_f_code (1): shall have the value 111 in MPEG-2 sequences.
full_pel_forward_vector, full_pel_backward_vector(1): shall have the value '0' in MPEG-2 sequences.
f_code(1): shall not have zero values.
f_code(2): shall have 1111 in Intra pictures with no error concealment vectors.
f_code(3): [r][1][t] (backward) shall have value 0xF in I and P pictures.
f_code(4): shall be limited to one value less in field coded pictures than the limit imposed by Profile and
Level for frame coded pictures.
intra_dc_precision(1): shall agree with Profile and Level.
picture_structure(1): shall have value between 01 and 11.
picture_structure(2): 10 and 11 are illegal in progressive sequences.
picture_structure(3): the field parity shall be alternately top and bottom.
frame_pred_frame_dct(1): shall have value '1' in progressive sequences and pictures.
frame_pred_frame_dct(2): shall have value '0' in field pictures.
repeat_first_field(1): shall be zero in field pictures.
chroma_420_type(1): shall have the same parity as progressive_frame.
progressive_frame(1): shall be '1' in progressive sequences.
user_data: user shall not contain a string of 23 or more zero bits.
82
Page 83 of 100 July 30, 2002
Tests on the slice layer
slice_vertical_position (1): the value encoded in the slice_vertical_position field shall be in the range
from 1 to 175.
slice_vertical_position (2): the value encoded in the slice_vertical_position shall not be greater than the
vertical picture size in units of 16 lines, rounded upwards. The vertical picture size is indicated in the
Sequence Header.
quantizer_scale: the value encoded in the quantizer_scale field shall not be equal to zero.
reserved_bits: shall have zero value.
extra_bit_slice is checked to have 0 value, however as a service to delinquent bitstreams,

extra_information_slice may be parsed out.
Tests on the macroblock layer
macroblock_address_increment (1): the indicated macroblock shall be within the boundaries of the
picture.
macroblock_address_increment (2): the first slice of the picture shall start with the first macroblock in
the picture.
macroblock_address_increment (3): the first macroblock of a slice shall not be skipped.
macroblock_address_increment (4): the horizontal position of the first macroblock of a slice shall be
less than or equal to the width of the picture in units of macroblocks.
macroblock_address_increment (5): the last macroblock of a slice shall not be skipped.
macroblock_address_increment (6): the last slice of the picture shall end with the last macroblock of the
picture.
macroblock_address_increment (7): slices shall not overlap.
macroblock_address_increment (8): there shall be no gaps between slices in the same picture.
macroblock_address_increment (9): within Main Profile, skipping of Intra picture macroblocks shall not
occur.
macroblock address increment (10): in B pictures, macroblock skipping is not permitted after an Intra
macroblock
83
Page 84 of 100 July 30, 2002
macroblock_address_increment(11): macroblock stuffing is illegal in MPEG-2 sequences.
macroblock_type (1): each macroblock shall be intra-coded at least once per every 132 times it is coded
in a P-picture without an intervening I-picture.
macroblock_type (2): if the macroblock_type field indicates macroblock_motion_forward and in case the
picture is a B-picture that is preceded by exactly one I-picture in the same Group of Pictures, then the
closed_gop flag shall be set to "0".
macroblock_type (3): if the macroblock_type field indicates macroblock_motion_forward and in case the
picture is a B-picture that is preceded by exactly one I-picture in the same Group of Pictures, and if that
Group of Pictures is the first Group of Pictures in the sequence, then the broken_link flag shall be set to
"1".
macroblock_type(4): When intraa_slice is set, all macroblocks within that slice are checked to be of type
Intra.
macroblock_type(5): Dual prime (11) shall not occur in Simple or Main Profile B pictures.
macroblock_type(6): No B-coded pictures shall exist between a picture containing at least one Dual
Prime macroblock and the reference picture.
macroblock_type(7): for the special IP case (first field Intra, second field P):
• (macroblock_motion_forward==0 && macroblock_intra==0)combination in macroblock_type is
illegal.
• Dual Prime is checked not to occur.
• motion_vertical_field_select shall always have a value of opposite parity to current picture.
• No skipped macroblocks
frame_motion_type and field_motion_type shall have values ranging from 01 to 11.
reconstructed motion vectors(1): All reconstructed vectors are checked such they fall within the legal
range bounded by [low, high ] in Clause 7 of DIS 13818-2.
reconstructed motion vectors(2): Intermediate and final motion vectors for Dual Prime (same parity
vectors, scaled opposite parity vectors, and the scaled +dmv vectors, and scaled + dmv + any ±1
corrections) shall lie within the [low, high] ranged imposed by f_code[][] and picture boundaries.
reconstructed motion vectors:(3) Field MV in frame pictures are checked to have half the range
(high:low) of the range specified by f_code.
84
Page 85 of 100 July 30, 2002
reconstructed motion vectors(4): each reconstructed motion vector shall refer to a macroblock that is
fully within the boundaries of the picture [horizontal_size - 16, vertical_size - 16].
Tests on the block layer
number of DCT coefficients: for each transformed block the block indices of the coefficients shall be in
the range from zero to sixty-three. The block index defines the position of the coefficient in the array of
quantized DCT coefficients in zig-zag or alternate scanning order.
SNR Scalability Profile

The folowing tests are specific to programs which contain at least one SNR layer.
The sequence header of the enhancement layer has to be identical to the one in the lower layer except for
the values of bit_rate, vbv_buffer_size, load_intra_quantiser_matrix, intra_quantiser_matrix,
load_non_intra_quantiser_matrix and non_intra_quantiser_matrix. The value of
load_intra_quantiser_matrix has to be zero in the enhancement layer.
Fields within sequence extension() shall be identical to those in the lower layer except for the values of
profile_and_level_indication, chroma_format, bit_rate_extension and vbv_buffer_size_extension.
If there is a quant_matrix_extension() in the enhancement layer, the values of

load_intra_quantiser_matrix and load_chroma_intra_quantiser_matrix shall be zero.
sequence_display_extension: shall not be present in the enhancement layer.
layer_id: for two bitstreams, the respective layer_id has to be consecutive numbers.
chroma_format: of the enhancement layer shall not be less than the one in the base layer.
scalable_mode: sequence_scalable_extension shall be present in the enhancement layer with

scalable_mode = "SNR scalability"
vbv_buffer_size(1): If the level is Main level, the sum of the VBV buffer sizes of both layers shall not
exceed 1835008 bit. For this level, the VBV buffer size of the base layer shall not exceed 1212416 bit.
vbv_buffer_size(2):The VBV buffer size and VBV delays shall not be zero.
Tests on the group of pictures layer

The GOP header in the enhancement layer, will be identical to the one in the base layer.
Tests on the picture layer
85
Page 86 of 100 July 30, 2002
There shall be no pan_scan_extension() in the enhancement layer.
The picture_coding_extension() in the enhancement layer shall be identical to the one in the base layer
except for the vlaue of q_scale_type and alternate_scan
vbv_delay: The picture headers in the enhancement layer shall be identical to the ones in the base layer,
except for the values of vbv_delay.
Slices of the enhancement layer have to coincide with the slices of the base layer.
dct_type: if present in both layers, it shall have the same value.
Spatial scalability Profile
picture_structure: In the case of interlaced sequences in both layers, the picture_structure has to be the
same in the coded picture of the enhancement layer and in the reference picture of the base layer.
lower_layer_prediction_horizontal_size, lower_layer_prediction_vertical_size: The values of

lower_layer_prediction_horizontal_size and lower_layer_prediction_vertical_size shall have exactly the
same value as the lower layer horizontal_size and vertical_size respectively.
picture_spatial_scalable_extension(): There shall be no picture_spatial_scalable_extension() in a

bitstream if there was no sequence_scalable_extension() with scalable_mode==01 (i.e., spatial scalability)
since the most recent sequence header.
slice_vertical_position:There shall be no gaps between slices.
No spatial prediction shall be made for macroblocks in the enhancement layer that not lie wholly within
the upsampled lower layer reconstructed frame.
macroblock_address_increment: There shall be no skipped macroblock following a spatial-only

macroblock in B-pictures.
spatial_temporal_weight_code_table_index: The value shall only have values that are allowed in DIS
13818-2 table 7-20, according to the scanning formats in both layers.
86
Page 87 of 100 July 30, 2002
87
Page 88 of 100 July 30, 2002
Audio bitstream tests
2.5.3.1 Extension of ISO/IEC 11172-3 Audio Coding to Lower Sampling Frequencies
General tests
layer: the Layer field shall not be encoded with the binary value 00.
bitrate: the bitrate field shall not be encoded with the binary value 1111.
sampling_frequency: the sampling frequency field shall not be encoded with the binary value 11.
padding: padding shall be applied such that the accumulated length of the coded audio frames, after a
certain number of audio frames, shall not deviate more than (+0,-1) slot from the value specified in
2.4.2.3 of ISO/IEC 11172-3. This shall apply only if the layer, the bitrate and the sampling frequency do
not change in the course of the considered audio frames.
emphasis: the emphasis field shall not be encoded with the binary value 10.
protection: if the protection bit is set to "0", then the correct CRC16 value shall be in the crc_check field
ID: the ID flag shall be set to "0".
Tests on Layer I
allocation: the allocation[sb] or allocation[ch][sb] field shall not be encoded with the binary value 1111.
scalefactor: the scalefactor[sb] or scalefactor[ch][sb] field shall not refer to index 63.
samples: for the coded representation of subband samples the valid range is from zero up to (nlevels -2),
where nlevels equals the number of levels used for quantization of that sample, that is the coded
representation of a sample shall not consist of a bitstring with only "1"s.
frame length (1): the bit allocation shall be such that the total number of bits for a frame does not exceed
the frame length for Layer I.
frame length (2): for Layer 1 the frame length shall equal the number of slots times the slot size for
Layer†I.
Tests on Layer II
scalefactor: the scalefactor[sb][p] or scalefactor[ch][sb][p] field shall not refer to index 63
88
Page 89 of 100 July 30, 2002
samples: for un-grouped samples the coded representation of subband samples the valid range is from
zero up to (nlevels -2), where nlevels equals the number of levels used for quantization of that sample, that
is the coded representation of a sample shall not consist of a bitstring with only "1"s. For grouped
samples the range shall be from zero up to 26 if nlevels equals 3, from zero up to 124 if nlevels equals 5,
and from zero up to 728 if nlevels equals 9.
frame length (1): the bit allocation and the scalefactor select information shall be such that the total
number of bits for a frame does not exceed the frame length for Layer II.
frame length (2): for Layer II the frame length shall equal the number of slots times the slot size for Layer
II.
Tests on Layer III
part2_3_length: the value encoded in the part2_3_length[gr] or part2_3_length[gr][ch] field shall

correspond to the total length of scalefactors and Huffman encoded data.
table_select: the table_select[region][gr] or table_select[region][gr][ch] fields shall be encoded correctly.
frame_length (1): the Huffman code data shall be such that the total number of bits for a frame does not
exceed the frame length for Layer III.
frame length (2): for Layer III the frame length shall equal the number of slots times the slot size for
Layer III.
buffer control: the value of main_data_begin shall comply with the buffer considerations specified in
2.4.3.4 of ISO/IEC 11172-3.
Low bit rate coding of Multichannel Audio
Due to the compatibility of ISO/IEC 13818-3 multichannel audio coding with ISO/IEC 11172-3, ISO/IEC
11172-4 applies to the MPEG-1 part of the bit stream. Furthermore, the following tests apply to an
ISO/IEC 13818-3 bit stream.
89
Page 90 of 100 July 30, 2002
General tests
The following table gives an overview of the allowed combinations of mode in the MPEG-1 header and
the multichannel options in the mc_header.
MPEG-1 MPEG-2 multichannel option
mode Center mono/stereo 2nd stereo LFE multilingual

surround programme
mono/dual no no yes no yes
stereo/joint stereo yes yes yes yes yes
dematrix_procedure: The dematrix_procedure ë10í may only occur in 3/1 or in 3/2 configuration.
Tests on Layer I and Layer II
tc_allocation: The following combinations of configuration and tc_allocation are not allowed.
configuration forbidden
tc_allocation
3/1 5, 6, 7
3/0 or 3/0+2/0 3
2/1 3
If phantom coding is used, the combinations of configuration and tc_allocation are further restricted:
tc_allocation
3/2 1, 2, 6, 7
3/1 1, 2, 5, 6, 7
3/0 or 3/0+2/0 1, 2, 3
2/2 and 2/1 not applicable

with phantom
coding
dyn_cross_mode: The following combinations of configuration and dyn_cross_mode are not allowed.
90
Page 91 of 100 July 30, 2002
dyn_cross_mode
3/2 15
3/1 5, 6, 7
2/2 5, 6, 7
lf_scalefactor, scalefactor[mch][sb][p],scalefactor[mlch][sb][p]: the lf_scalefactor and

scalefactor[mch][sb][p] and scalefactor[mlch][sb][p] fields shall not refer to index 63.
lf_sample[gr], sample[mch,sb,s], sample[mlch,sb,s], samplecode[mch,sb,gr], samplecode[mlch,sb,gr]:

for un-grouped samples the coded representation of subband samples the valid range is from zero up to
(nlevels -2), where nlevels equals the number of levels used for quantization of that sample, that is the
coded representation of a sample shall not consist of a bitstring with only "1"s. For grouped samples the
range shall be from zero up to 26 if nlevels equals 3, from zero up to 124 if nlevels equals 5, and from zero
up to 728 if nlevels equals 9.
frame length (1): the bit allocation and, in Layer II, the scalefactor select information of the MPEG-1
defined part, and the bit allocation, scalefactor select information, and composite status info of the
multichannel extension, and the bit allocation and the scalefactor select information of the multilingual
extension, shall be such that the total number of bits for a frame does not exceed the frame length plus the
length of the extension frame.
frame length (2): the frame length shall equal the number of slots times the slot size.
frame length (3): the MPEG-1 defined part and the MPEG-2 header shall be such that the total number of
bits for a frame does not exceed the ìMPEG-2 Audio Frame - MPEG-1 Compatible Partî.
Tests on Layer III
part2_3_length: the value encoded in the part2_3_length[gr] or part2_3_length[gr][ch] field shall

correspond to the total length of scalefactors and Huffman encoded data.
table_select: the table_select[region][gr] or table_select[region][gr][ch] fields shall be encoded correctly.
frame_length (1): the Huffman code data shall be such that the total number of bits for a frame does not
exceed the frame length for Layer III.
frame length (2): for Layer III the frame length shall equal the number of slots times the slot size for
Layer III.
91
Page 92 of 100 July 30, 2002
frame length (3): the MPEG-1 defined part and the MPEG-2 header shall be such that the total number of
bits for a frame does not exceed the ìMPEG-2 Audio Frame - MPEG-1 Compatible Partî.
buffer control: the value of main_data_begin shall comply with the buffer considerations specified in
2.4.3.4 of ISO/IEC 13818-3.
92
Page 93 of 100 July 30, 2002
Procedures to test decoder compliance
System decoder tests
The objective of System Decoder compliance testing is whether a decoder meets its claimed functionality.
To test decoder capabilities, specific test streams can be used.
Video decoder tests
statistical behaviour of decoders on conformance bitstreams
testing conditions
Confomance testing should be ideally possible on every type of decoder. However, the video MPEG2
specification only concerns the decoding process from a bitstream to a digital video output. This output, in
the case of MP@ML, is only in the form of a 4:2:0 signal.
The conformance testing of systems that provide only an analog video output (NTSC, PAL, SECAM,
RGB...), or systems of which the only output is the display, is not considered in this section. It will be
considered in the next section on decoder breakdown
The proposed method can be applied to video systems with digital video output. In the case of MP@ML
video decoders tests can be performed either on 4:2:0, or on 4:2:2 output. However, the results of tests on
4:2:2 signals should be carefully interpreted as the chroma conversion from 4:2:0 to 4:2:2 is outside the
scope of the standard and will certainly bias the results on chrominance. As a consequence, it should be
recommended to perform the test in 4:2:0 format, and , if not possible 4:2:2 should be considered as an
alternative of limited value for chrominance signals.
The proposed set up for the test is shown on the following figure:
reference 4:2:0
decoder
bitstream
report
decoder 4:2:0 difference

under test
file
Figure: test configuration for a decoder with a digital output
report on the analysis of difference files
A report on the difference file is generated for each conformance bitstream.
93
Page 94 of 100 July 30, 2002
The report consists of:
• the histogram of the pel difference per field between the output of the reference decoder and the
decoder under test for each component (Y,U,V) of the signal
• the number and addresses and the Mean Absolute Error of erroneous [errors not explained by
mismatch] MBs, and the erroneous component in each erroneous MB. A MB is declared erroneous
when at least one pixel of the difference file has an absolute value that cannot be explained by
mismatch.
94
Page 95 of 100 July 30, 2002
Audio decoder tests
To test audio decoders, ISO/IEC JTC1 SC29/WG11 supplies a number of test sequences. Supplied
sequences cover Full Layer N Decoders and Core Layer N decoders. For a supplied test sequence, testing
can be done by comparing the output of a decoder under test with a reference output also supplied by
ISO/IEC JTC1 SC29/WG11. Measurements are carried out relative to full scale where the output signals
of the decoders are normalized to be in the range between -1 and +1.
To be called an ISO/IEC 13818-3 audio decoder, the decoder shall provide an output such that the rms
level of the difference signal between the output of the decoder under test and the supplied reference
output is less than 2-15/sqrt(12) for the supplied sine sweep (20Hz-10kHz) with an amplitude of -20dB
relative to full scale. In addition, the difference signal shall have a maximum absolute value of at most
2-14 relative to full-scale.
To be called a limited accuracy ISO/IEC 13818-3 audio decoder, the decoder shall provide an output for a
provided test sequence such that the rms level of the difference signal between the output of the decoder
under test and the supplied reference output is less than 2-11 /(sqrt(12) for the supplied sine sweep
(20Hz-10kHz) with an amplitude of -20dB relative to full scale.
The above two tests only verify the computational accuracy of an implementation.
Calculation for RMS
All measurements are carried out relative to full scale where the output signals of the decoder and supplied
test sequences are normalised to be in the range between -1,0 and +1,0. The supplied sine sweep with an
amplitude of -20dB relative to full scale has an absolute amplitude of +-0,1. This test sequence has a
precision (P) of 24 bit. i.e. the MSB represents the value of -1, the MSB-1 bit represents the value of
+1/2, etc.
MSB -1/2^0 = -1
MSB-1 1/2^1 = _
MSB-2 1/2^2 = 1/4
MSB-23 1/2^23 = 1/8 388 608.
The output signal of the decoder under test requires to be in the same format. In the case that the output
of the decoder has a precision of P' bits and if P' is smaller than 24, then the values for the bits between the
positions P'-1 and 24 shall be set to zero.
MSB -1/2^0 = -1
MSB-1 1/2^1 = 1/2
...
95
Page 96 of 100 July 30, 2002
MSB-(P'-1) 1/2^P' = 1/2^P'

MSB-P' 0 = 0
...
MSB-23 0 = 0
In the next step the difference (diff) of the samples of these signals has to be calculated. If two channels
are present (in case of stereo, joint-stereo and dual-channel) both channels shall be tested. The total
number of samples for each channel is N.
diff(n) = 'output signal of decoder under test(n)' - 'supplied sine sweep(n)'

for n = 1 to N
The values of all difference samples shall be squared, summed, divided by N and then the square-root shall
be calculated. This calculation finally gives the rms level.
rms := sqrt(1/N*sum(diff^2))
The decoder under test may be called an ISO/IEC 13818-3 audio decoder, if the rms is less than
1/(2^15 * 12^0,5) and if the maximum absolute value is less than or equal to 1/2^14.
The decoder under test may be called a limited accuracy ISO/IEC13818-3 audio decoder, if the rms is less
than 1/(2^11 * 12^0,5).
96
Page 97 of 100 July 30, 2002
Annex A
I. Patent statements
(This annex does not form an integral part of this Recommendation | International Standard)
The user's attention is called to the possibility that, for some of the processes specified in this part of
ISO/IEC 13818, conformance with this specification may require use of an invention covered by patent
rights.
By publication of this part of ISO/IEC 13818, no position is taken with respect to the validity of this claim
or of any patent rights in connection therewith. However, each company listed in this Annex has
undertaken to file with the Information Technology Task Force (ITTF) a statement of willingness to grant
a license under such rights that they hold on reasonable and non-discriminatory terms and conditions to
applicants desiring to obtain such a license.
Information regarding such patents can be obtained from the following organisations.
The table summarises the formal patent statements received and indicates the parts of the standard to
which the statement applies. The list includes all organisations that have submitted informal patent
statements. However, if no "X" is present, no formal patent statement has yet been received from that
organisation.
97
Page 98 of 100 July 30, 2002
Company V A S
AT&T X X X
BBC Research Department
Bellcore X
Belgian Science Policy Office X
BOSCH X X X
CCETT
CSELT X
David Sarnoff Research Center X X X
Deutsche Thomson-Brandt GmbH X X X
France Telecom CNET
Fraunhofer Gesellschaft X X
GC Technology Corporation X X X
General Instruments
Goldstar
Hitachi, Ltd.
International Business Machines Corporation X X X
IRT X
KDD X
Massachusetts Institute of Technology X X X
Matsushita Electric Industrial Co., Ltd. X X X
Mitsubishi Electric Corporation
National Transcommunications Limited
NEC Corporation X
Nippon Hoso Kyokai X
Nippon Telegraph and Telephone X
Nokia Research Center X
Norwegian Telecom Research X
Philips Consumer Electronics X X X
OKI
Qualcomm Incorporated X
Royal PTT Nederland N.V., PTT Research (NL) X X X
Samsung Electronics
Scientific Atlanta X X X
Siemens AG X
Sharp Corporation
Sony Corporation
Texas Instruments
Thomson Consumer Electronics
Toshiba Corporation X
TV/Com X X X
Victor Company of Japan Limited
98
Page 99 of 100 July 30, 2002
Annex B
I. Bibliography
(This annex does not form an integral part of this Recommendation | International Standard)
1 Arun N. Netravali & Barry G. Haskell "Digital Pictures, representation and compression"
Plenum Press, 1988
2 Didier Le Gall "MPEG: A Video Compression Standard for Multimedia Applications" Trans.
ACM, April 1991
3 C Loeffler, A Ligtenberg, G S Moschytz "Practical fast 1-D DCT algorithms with 11
multiplications" Proceedings IEEE ICASSP-89, Vol. 2, pp 988-991, Feb. 1989
4 See the Normative Reference for ITU-R Rec 601 (formerly CCIR Rec 601)
5 See the Normative Reference for IEC Standard Publication 461
6 See the Normative Reference for ITU-T Rec. H.261
7 See the Normative reference for IEEE Standard Specification P1180-1990
8 ISO/IEC 10918-1 | ITU-T T.81 (JPEG)
9 E Viscito and C Gonzales "A Video Compression Algorithm with Adaptive Bit Allocation and
Quantization", Proc SPIE Visual Communications and Image Proc '91 Boston MA November
10-15 Vol. 1605 205, 1991
10 A Puri and R Aravind "Motion Compensated Video Coding with Adaptive Perceptual
Quantization", IEEE Trans. on Circuits and Systems for Video Technology, Vol. 1 pp 351 Dec.
1991.
11 C. Gonzales and E. Viscito, "Flexibly scalable digital video coding". Image Communications,
Vol. 5, Nos. 1-2, February 1993
12 A.W.Johnson, T.Sikora and T.K. Tan, "Filters for Drift Reduction in Frequency Scalable Video
Coding Schemes" <Transmitted for publication to Electronic Letters.>
13 R.Mokry and D.Anastassiou, "Minimal Error Drift in Frequency Scalability for
Motion-Compensated DCT Coding". IEEE Transactions on Circuits and Systems for Video
Technology, <accepted for publication>
14 K.N. Ngan, J. Arnold, T. Sikora, T.K. Tan and A.W. Johnson. "Frequency Scalability
Experiments for MPEG-2 Standard". Asia-Pacific Conference on Communications, Korea,
August 1993.
15 T. Sikora, T.K. Tan and K.N. Ngan, "A Performance Comparison of Frequency Domain
Pyramid Scalable Coding Schemes Within the MPEG Framework". Proc. PCS, Picture
Coding Symposium, Lausanne, pp. 16.1 - 16.2, Switzerland March 1993.
16 Masahiro Iwahashi, ÒMotion Compensation Technique for 2:1 Scaled-down Moving
PicturesÓ. 8-14, Picture Coding Symposium '93.
17 Sikora, T. and Pang, K., "Experiments with Optimal Block-Overlapping Filters for Cell Loss
Concealment in Packet Video", Proc. IEEE Visual Signal Processing and Communications
Workshop, Melbourne, 21-22 Sept. 1993, pp. 247-250.
18 A. Puri "Video Coding Using the MPEG-2 Compression Standard", <to appear> Proc SPIE
Visual Communications and Image Proc '93 Boston MA November,1993.
19 A. Puri and A. Wong "Spatial Domain Resolution Scalable Video Coding", <to appear> Proc
SPIE Visual Communications and Image Proc '93 Boston MA November,1993.
99
Page 100 of 100 July 30, 2002
100

Iso-Iec 13818-4

Uploaded by

Copyright:

Available Formats

Iso-Iec 13818-4

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Iso-Iec 13818-4

Uploaded by

Copyright:

Available Formats

INTERNATIONAL ORGANISATION FOR STANDARDISATION

ORGANISATION INTERNATIONALE DE NORMALISATION

ISO/IEC JTC1/SC29/WG11 N0804

6. ABBREVIATIONS AND SYMBOLS...........................................................................................20

9.2.2 SNR Scalability Profile .......................................................................................................85

12. ANNEX B ..................................................................................................................................99

13818-3 Audio specifies the coded representation of audio data.

13818-5 Software provides software example of Parts 1, 2, and 3 of 13818.

INTERNATIONAL STANDARD 13818-4

ITU-T RECOMMENDATION H.262

GENERIC CODING OF MOVING PICTURES AND ASSOCIATED AUDIO

Transport Stream payload.

Abbreviations and symbols

<< Shift left with zero fill.

General System bitstream characteristics

• constraints for STD Model

Transport Stream specific characteristics

• use of transport priority indication

Program Stream specific characteristics

Main Profile compliance bitstreams

18 ML Low delay sequence with skipped pictures. NTR

N Level Description Contributing

Spatial Profile compliance bitstreams

Compliance bitstream characteristics

prediction mode Field MC in Frame pictures, 16x8 MC in

2.3.3.1 Extension of ISO/IEC 11172-3 Audio Coding to Lower Sampling Frequencies

2.3.3.2 Low bit rate coding of Multichannel Audio

name.mpg : MPEG2 bit stream - MPEG1 compatible part

MPEG1 COMPATIBLE PART

bit rate: 384 kbit/s

center channel: present

MPEG1 COMPATIBLE PART

bit rate: 384 kbit/s

center channel: with phantom coding

MPEG1 COMPATIBLE PART

bit rate: 384 kbit/s

center channel: present

MPEG1 COMPATIBLE PART

bit rate: 384 kbit/s

center channel: with phantom coding

MPEG1 COMPATIBLE PART

bit rate: 384 kbit/s

center channel: present

surround channels: stereo

predictor order always 0, no delay compensation

MPEG1 COMPATIBLE PART

bit rate: 384 kbit/s

center channel: present

General System Decoder capabilities

Handling of decoder discontinuities (mandatory)

Sequence Concatenation; Decoding Discontinuities; Splicing; Format Changes

Presentation synchronization (mandatory)

Support of variable bitrate within a program (mandatory)

General capabilities for program acquisition (mandatory)

Change in program definition (mandatory)

Note on Conditional Access

Private data handling (mandatory)

Private Data in Transport Streams