Subversion Repositories mpeg2fpga

Draft Text for the video sections of ISO/IEC 13818-4 (MPEG-2 Compliance)
Nov 11, 1995 (Dallas)

This is only a draft of the video sections.  The final, complete and
normative text of the ISO/IEC 13818-4 standard should be purchased
from ISO.



        2.4 Video

        2.4.1 Introduction

In the video sections of part-4, except where stated otherwise, the
following terms are used for practical purposes:

The term 'bitstream' means ISO/IEC 13818 video bitstream.

The term 'decoder' means ISO/IEC 13818 video decoder, i.e., an
embodiment of the decoding process specified by ISO/IEC 13818-2.

The term 'Chapter 8' means Chapter 8 of ISO/IEC 13818-2 (definition of
authorized profile-and-level combinations), as well as any future
amendments of the standard which defines additional profile-and-level
combinations not currently defined in Chapter 8.

The term 'verifier' means a ISO/IEC 13818 video bitstream verifier,
i.e., a process by which it is possible to test and verify that all the
requirements specified in ISO/IEC 13818-2 are met by the bitstream.

If any statement stated in this section accidentally contradicts a
statement or requirement defined in ISO/IEC 13818-2,  the text of
ISO/IEC 13818-2 prevails.

The following sections specify the normative tests for verifying
compliance of video bitstreams and video decoders.  Those normative
tests make use of test data (bitstream test suites) provided as an
electronic annex to this document, and of a software verifier specified
in ISO/IEC 13818-5 with source code available in electronic format.

Conformance of scalable hierarchies of bitstreams and scalable profile
decoders is defined in section 2.4.6.

        2.4.2 Definition of video bitstream compliance

An ISO/IEC 13818 video bitstream is a bitstream that implements the
specification defined by the normative sections of ISO/IEC 13818-2
(including Annexes A, B and C).

A compliant bitstream shall meet all the requirements and implement all
the restrictions defined in the generic syntax defined by the ISO/IEC
13818-2 specification, including the restrictions defined in Chapter 8
for the profile-and-level specified in the sequence_extension() of the
bitstream.

Section 2.4.3 of this specification defines the normative test that a
bitstream shall pass successfully in order to be claimed compliant with
this specification.

A compliant bitstream of a given profile-and-level may be called an
"MPEG-2 Profile@Level bitstream" or simply a "Profile@Level bitstream"
(e.g. an MP@ML bitstream).

The following sections clarify some of the important requirements on
bitstreams and on encoders producing bitstreams:

        2.4.2.1 Requirements and restrictions related to profile-and-level

The profile_and_level_indication shall be one of the valid codes
defined in Chapter 8. The profile-and-level derived from the
profile_and_level_indication indicates that additional restrictions and
constraints have been applied to several syntactic and semantic
elements, as defined in Chapter 8.

The restrictions defined for a given profile-and-level are aimed at
reducing the cost of decoder implementation and at facilitating
interoperability.  A compliant bitstream shall be decodable by any
compliant ISO/IEC 13818 video decoder that supports the
profile-and-level combination specified in the bitstream.

        2.4.2.2 Additional restrictions on bitstream applied by the encoder

The video encoder may apply any additional restrictions on the
parameters of the video bitstream, in addition to restrictions defined
in the generic video syntax and the restrictions defined for the
specified profile-and-level in Chapter 8.  Not all additional
restrictions can be known a priori without analyzing or decoding the
entire bitstream, since the syntax does not provide explicit mechanisms
which signal such restrictions in advance for all cases.

        2.4.2.3 Encoder requirements and recommendations

        2.4.2.3.1 Encoder requirements

Although encoders are not directly addressed by ISO/IEC 13818-2, an
encoder is said to be an ISO/IEC 13818-2 Profile@Level encoder if it
satisfies the following requirements:

1) The bitstreams generated by the encoder are compliant Profile@Level
bitstreams.

2) For encoding methods which include embedded decoding operations to
produce the coded bitstream, these decoding operations shall be
performed with the full arithmetic precision specified in ISO/IEC
13818-2.

This second requirement is necessary to guarantee that only compliant
decoders will produce images that have optimum quality.

With this requirement on ISO/IEC 13818-2 encoders,  any compliant
decoder decoding a bitstream generated by a compliant encoder will
normally reconstruct images of higher quality,  compared to the images
reconstructed from the same bitstream by a non-compliant decoder.

        2.4.2.3.2 Encoder recommendations

It is strongly recommended that video encoders capable of producing
P-pictures implement Note 2 of section 7.4.4 of ISO/IEC 13818-2.
Failure to implement this recommendation may cause significant
accumulation of mismatch between the reconstructed samples produced by
the hypothetical decoder sub-loop embedded within an encoder and those
produced by a (downstream) decoder using the coded bitstream produced
by the encoder.

It is strongly recommended that video encoders capable of generating
concealment motion vectors produce such concealment vectors that will
help the concealment process for decoders  which implement the specific
concealment technique described in  sections D.13.1.1.2,  D.13.1.1.3,
and 7.6.3.9 of ISO/IEC 13818-2.

The concealment motion vector transmitted with a macroblock should be a
frame motion vector that would provide a "good" frame prediction for
predicting the macroblock that lies vertically below the macroblock in
which the motion vector occurs.

If the encoder is capable of generating bitstreams with
slice_picture_id, it is recommended that temporal interval between
pictures using the same value for slice_picture_id be as large as
possible, so that error bursts causing loss of several consecutive
pictures can be detected.

        2.4.3 Procedure for testing bitstream compliance

The technical report (ISO/IEC 13818-5) contains the source code of a
software video verifier that checks that a bitstream implements
properly the normative requirements defined in ISO/IEC 13818-2.

A bitstream that claims compliance with this standard shall pass the
following normative test:

When processed by the technical report verifier,  the bitstream shall
not cause any error or non-conformance messages to be reported by the
verifier.  This test shall be applied only to bitstreams that are known
to be free of errors introduced by transmission.

Successfully passing the technical report verifier test only provides a
strong presumption that the bitstream under test is compliant, i.e.
that it does indeed meet all the requirements specified in ISO/IEC
13818-2.

Additional tests may be necessary to check more thoroughly that the
bitstream implements properly all the requirements specified in ISO/IEC
13818-2.  These complementary tests may be performed using other video
bitstream verifiers that perform more complete tests than those
implemented by the technical report software.

In particular,  ISO/IEC 13818-2 contains several informative
recommendations. When testing a bitstream for compliance, it is useful
to tests whether or not the bitstream follows those recommendations.

To check correctness of a bitstream, it is necessary to parse the
entire bitstream and to extract all the syntactic elements and other
values derived from those syntactic elements and used by the decoding
process specified in ISO/IEC 13818-2 (e.g. r_size,
macroblock_pattern).

A verifier does not necessarily perform all stages of the decoding
process described in ISO/IEC 13818-2 in order to verify bitstream
correctness.  Many tests are performed on syntax elements in a state
prior to their use in some processing stages.  However, some arithmetic
may need to be performed on combinations of syntax elements. For
example, motion vectors used for  prediction in the motion compensation
stage (section 7.6 in ISO/IEC 13818-2) may need to be fully
reconstructed in order to verify that predictions do not make reference
to samples outside coded boundaries of the reference picture.

A verifier which *does* perform the IDCT transform and calculates the
reconstructed samples must comply with all the arithmetic precision
requirements specified in ISO/IEC 13818-2.  In addition,  the IDCT of
such a verifier shall be an embodiment of the saturated mathematical
integer-number IDCT specified in Annex A of ISO/IEC 13818-2 (a software
implementation using 64-bit double-precision floating-point is
sufficient).

Performing the IDCT transform and calculating the reconstructed samples
in a verifier, although not necessary, is useful for several reasons:

- It allows to test the subjective quality of the reconstructed
frames.  ISO/IEC 13818-2 does not put any requirement on subjective
quality, but it is desirable that an encoder generates bitstreams for
which the subjective quality of reconstructed frames is as good as
possible.

- Checking the output of the IDCT can provide an indication of whether
or not the encoder that produced the bitstream observed the
recommendation of Note 2 in section 7.4.4 of ISO/IEC 13818-2)

If a bitstream contains a P-picture with many occurrences of coded
blocks of DCT coefficients (i.e., blocks that are not all zeros) for
which the output of the reference IDCT is all zeros, then the encoder
that produced the bitstream can be suspected of not implementing this
important recommendation.

The best chance to discover this problem is when a still image (with no
motion at all and no noise) is encoded.

        2.4.4 Definition of video decoder compliance

In this section, except where stated otherwise, the term 'bitstream'
means compliant ISO/IEC 13818 video bitstream (as defined in this
document) that has the profile_and_level_indication corresponding to
the profile-and-level combination considered for the decoder.

Compliance of an ISO/IEC 13818-2 decoder is defined only with regard to
a legal profile-and-level combination, as specified in Chapter 8.

The normative tests that a decoder shall pass in order to claim
compliance with a given profile-and-level combination are specified in
section 2.4.5.6.  A decoder can claim compliance with regard to several
profile-and-level combinations if and only if it passes the normative
tests defined for each of the profile and level combinations.

Only a decoder that passes the conformance test for a given
profile-and-level may be called "MPEG-2 Profile@Level decoder" or
simply "Profile@Level decoder" (e.g., an MPEG-2 MP@ML decoder).

A decoder that fails the normative tests defined by this specification
may only claim limited accuracy compliance to the standard.  A limited
accuracy decoder shall be accompanied upon request by a technical
description of the results of each of the normative tests.  This
technical description of the results shall include at least the result
of the IDCT accuracy test, the peak error for all static tests,  and
for the all dynamic tests, all the peak temporal errors or jitters when
presenting the reconstructed samples,  the description of the
reconstructed samples not presented,  etc.  Real-time software decoders
may have to use limited accuracy if the resources of the processor are
not sufficient to achieve real-time performances with the full
accuracy.

A limited accuracy decoder is not a compliant decoder and may only be
called "MPEG-2 limited accuracy Profile@Level decoder" or simply
"limited accuracy Profile@Level decoder".

In the following text, decoder compliance is always considered with
regard to a particular profile-and-level combination, even when this is
not specifically mentioned.

A compliant decoder shall implement a decoding process that is
equivalent to the one specified in ISO/IEC 13818-2 and meets all the
general requirements defined in ISO/IEC 13818-2 that apply for the
profile-and-level combination considered, and if it can decode
bitstreams with any options or parameters with values permitted for
that profile-and-level combination.  The permitted options and
parameter range for each profile-and-level combinations are defined in
Chapter 8.

A decoder which implements only a subset of the options or ranges of
syntax and semantics for a given profile-and-level combination is not a
compliant decoder for that profile-and-level, even if it passes the
normative tests specified in section 2.4.5.6.  In effect such a decoder
would not be capable of decoding all compliant bitstreams of the
considered profile-and-level combination.

In the following sections the term 'reference decoder' means the
technical report software verifier (ISO/IEC 13818-5).

The reference decoder is a decoder that implements precisely the
decoding process as specified in ISO/IEC 13818-2.  The IDCT function
that shall be used when running the reference decoder is the very
accurate approximation of the mathematical saturated integer-number
IDCT f '' (x, y) specified in Annex A of ISO/IEC 13818-2 obtained by
implementing f '' (x, y)  with double-precision arithmetic.

Except for possible mismatches caused by ambiguous half-values rounding
at the output of the IDCT function,  the output of the reference
decoder (reconstructed samples) is defined unambiguously by ISO/IEC
13818-2.

Fundamental requirement areas for decoders are listed in the following
sections.

        2.4.4.1 Requirement on arithmetic accuracy (without IDCT)

With the exception of IDCT, the specification of ISO/IEC 13818-2
defines the decoding process absolutely unambiguously.  Only the IDCT
may yield different results among different implementations.  The
requirements on the accuracy of the IDCT used by a compliant decoder
are specified in Annex A of ISO/IEC 13818-2.

There is a requirement that for a block that contains no coefficient
data (i.e. if pattern_code[i] is zero, or if the macroblock is skipped)
the sample domain coefficients f[x][y] for the block shall all take the
value zero (Cf. Section 7.5.1 of ISO/IEC 13818-2).

Therefore, the following is a the requirement on the arithmetic
accuracy of the decoder:

When a coded picture is decoded from a bitstream, for each 8x8 block of
the coded picture that is "not-coded" or that contains only zero DCT
coefficients, a compliant decoder shall produce reconstructed samples
numerically identical to those produced by the reference decoder when
the reference frames used by both decoders are numerically identical.
A decoder that reconstructs one sample with a value different from that
reconstructed by the reference decoder for the same sample is not a
compliant decoder.

In other words, all compliant decoders shall produce numerically
identical reconstructed samples when the IDCT is applied only to blocks
of zero coefficients (assuming that they use numerically identical
reference frames).

        2.4.4.2 Requirement on arithmetic accuracy (with IDCT)

When a bitstream contains some 8x8 blocks with non-zero DCT
coefficients, the output of a compliant decoder may differ from the
output of the reference decoder. However, because of the accuracy
requirements on the IDCT transform used by the decoder, there exist
some accuracy requirements on the output of a compliant ISO/IEC 13818
video decoder.

The IDCT used in a compliant decoder shall meet all the requirements
defined in Annex A of ISO/IEC 13818-2.

Annex A of ISO/IEC 13818-2 defines additional requirements above those
defined by the IEEE Std 1180-1990 standard.  In order to claim that the
IDCT transform used by the decoder conforms to the specification of
Annex A, the IDCT transform shall comply with the IEEE Std 1180-1990
standard and pass successfully the following test:

The test is derived from the specification given in the IEEE Std
1180-1990 standard, with the following modifications:

1) In item (1) of section 3.2 of the IEEE specification, the last
sentence is replaced by:  <<Data sets of 1,000,000 (one million) blocks
each should be generated for (L=256, H=255), (L=H=5) and (L=384,
H=383). >>

2) The text of section 3.3 of the IEEE specification is replaced by :
<<For any pixel location, the peak error shall not exceed 2 in
magnitude.  There is no other accuracy requirement  for this test.>>

Successfully passing the conformance test defined in this document only
provides a strong presumption that the IDCT transform is compliant,
i.e. that it does meet all the requirements specified in Annex A of
ISO/IEC 13818-2.

Additional tests may be necessary to check more thoroughly that the
IDCT implements properly all the requirements and recommendations
specified in Annex A of ISO/IEC 13818-2.

        2.4.4.3 Requirement on output of the decoding process and timing

The output of the decoding process is specified by section 7.12 of
ISO/IEC 13818-2.

It is a requirement that all the reconstructed samples of all the coded
frames be output by a compliant decoder to the display process.  For
example, a decoder that occasionally does not output some of the
reconstructed B-frames or that occasionally outputs incomplete
reconstructed frames to the display process is not compliant.  The
actual output of the display process is not specified by this
standard.

It is a requirement that a compliant decoder outputs the reconstructed
samples at the rates specified in section 7.12 of ISO/IEC 13818-2.

For example, when decoding an interlaced sequence, there is a
requirement that the samples of each field be output at intervals of
1/(2 * frame_rate).

        2.4.4.4 Requirement for compatibility with ISO/IEC 11172-2 (MPEG-1
        video)

The requirements for compatibility with ISO/IEC 11172-2 (MPEG-1 video)
are specified in section 8.1 of ISO/IEC 13818-2.

It is a requirement that a compliant ISO/IEC 13818-2 decoder shall
decode all compliant ISO/IEC 11172-2 constrained parameters
bitstreams.  It should be noted that the permitted ranges for the
parameters of ISO/IEC 11172-2 constrained parameters bitstreams are
different and not necessarily a subset of the permitted ranges for
equivalent parameters of ISO/IEC 13818-2 bitstreams.

For example ISO/IEC 11172-2 constrained parameters bitstreams can have
horizontal_size up to 768 samples, and vertical size > 480 is possible
with a frame_rate different from 25 Hz.  A compliant decoder should
decode such ISO/IEC 11172-2 constrained parameters bitstreams (i.e.
constrained_parameter_flag  = 1).

In addition, it is a requirement that a compliant decoder shall decode
D-pictures-only ISO/IEC 11172-2 bitstreams which are within the level
constraints of the decoder including some that may have
constrained_parameter_flag set to 0.

        2.4.4.5 Requirements for compatibility between various
        profile-and-level combinations

Chapter 8 defines additional requirements for compatibility between
various profile-and-level combinations.  Those requirements are defined
by Table 8-15 in Chapter 8.  The decoder shall meet all those
compatibility requirements.

For example, a compliant Main Profile at Main Level decoder shall also
be a compliant Main Profile at Low Level and Simple Profile at Main
Level decoder.

        2.4.4.6 Requirement for forward compatibility of future extensions

ISO/IEC 13818-2 defines several requirements on decoder that are needed
for allowing forward compatibility of future extension to ISO/IEC
13818-2 with existing compliant decoders.

A compliant decoder that encounters an extension with an extension
start code described as "reserved" in ISO/IEC 13818-2 shall discard and
ignore all subsequent data until the next start code.

A compliant decoder that encounters the syntactic element
extra_information_picture described as "reserved" in ISO/IEC 13818-2
shall discard this syntactic element and any subsequent one until it
encounters extra_bit_picture with the value 0.

A compliant decoder that encounters the syntactic element
extra_information_slice described as "reserved" in ISO/IEC 13818-2
shall discard this syntactic element and any subsequent one until it
encounters extra_bit_slice with the value 0.

        2.4.4.7 Requirements related to zero byte stuffing, user data and
        reserved extensions

A compliant decoder shall be able to decode bitstreams with any
permitted amount of zero byte stuffing, user data and reserved
extensions, at any place where those can legally occur.  The maximum
permitted amount of these data is limited by VBV requirements specified
in Annex C of ISO/IEC 13818-2.

The output of a compliant decoder shall be identical between two
bitstreams which differ only in the amount of user_data,
extra_information_slice, extra_information_picture, and start code
stuffing present in each respective bitstream.  For example, a
compliant decoder shall produce the same output when decoding a
bitstream that contains user data and when decoding the bitstream
derived by replacing all user data by zero byte stuffing.

Note that it is permitted in ISO/IEC 13818-2 that a majority of coded
data in a video sequence be in the form of  zero stuffing bytes, user
data and/or reserved extensions.

        2.4.4.8 Recommendations

In addition to the requirements, it is desirable that compliant
decoders implement various recommendations defined in ISO/IEC 13818-2.

This section lists some of the recommendations.

It is recommended that a compliant decoder be able to resume the
decoding process as soon as possible after an error (or the occurrence
of a sequence_error_code).  In most cases it is possible to resume
decoding at the next start code.

It is recommended that a compliant decoder be able to perform
concealment for the macroblocks or slices for which all the coded data
has not been received.

        2.4.5 Procedure to test decoder compliance

In this section, except where stated otherwise, the term 'bitstream'
means compliant ISO/IEC 13818 video bitstream (as defined in this
document), that has the profile_and_level_indication corresponding to
the profile-and-level combination for which conformance of the decoder
is considered.

There are two types of tests for decoders: static tests and dynamic
tests.

        2.4.5.1 Static tests:

Static tests of a video decoder requires testing of the reconstructed
samples.  This section will explain how this test can be accomplished
when the reconstructed samples at the output of the decoding process
are available.

It may not be possible to perform this type of test with a production
decoder.  In that case this test should be performed by the
manufacturer during the design and development phase.

Static tests are used for testing the arithmetic accuracy used in the
decoding process.

There are two sorts of static tests.

- The static tests that do not involve the use of IDCT, in which case
the test will check that the values of the samples reconstructed by the
decoder under test shall be identical to the values of the samples
reconstructed by the reference decoder when the reference frames used
by both decoders are numerically identical.

- The static tests that involve the use of IDCT, in which case the test
will check that the peak absolute error between the values of the
samples reconstructed by the decoder under test and the values of the
samples reconstructed by the reference decoder shall not be larger than
2 when the reference frames used by both decoders are numerically
identical.

        2.4.5.2 Dynamic tests

Dynamic tests are applied to check that all the reconstructed samples
are output to the display process and that the timing of the output of
the decoder's reconstructed samples to the display process conforms to
the specification of section 7.12 of ISO/IEC 13818-2, and to verify
that the decoder buffer (as defined by Annex C, VBV specification) does
not underflow or overflow when the bits are delivered at the proper
rate.

        2.4.5.3 Specification of the test bitstreams

This section provides the list of specifications that are used to
produce the bitstream test suites for testing decoder compliance.

Not all the decoder requirements are covered by these tests,  but tests
for the most fundamental decoder requirements are believed to be
covered by this test suite specification.  These tests include :

1. General static tests:

Bitstreams using all the possible coding options permitted by ISO/IEC
13818-2.

2. Memory bandwidth dynamic tests:

Bitstreams with all macroblocks predicted with average (bi-directional)
prediction or dual-prime, with half-sample interpolation in both the
horizontal and vertical directions, for both the luminance and
chrominance blocks if possible,  using smallest possible prediction
blocks and accessing as many different samples of the reference
pictures as possible.

3. VLC/FLC decoding static tests:

Bitstream using all the possible events within a table.

4. Bits and Symbol distribution (burst) dynamic tests:

Bitstream containing very irregular distribution of bits or symbols.

5. ISO/IEC 11172-2 compatibility tests:

ISO/IEC 11172-2 Bitstreams.

To test a decoder for conformance with regard to a particular
profile-and-level combination, a bitstream test suite can be made
according to this specification.  Each bitstream of the test suite must
have its profile_and_level_indication corresponding to the
profile-and-level combination considered for the decoder, and must be
fully compliant with ISO/IEC 13818-2, or with ISO/IEC 11172-2 when
specified.

When a bitstream requires the use of an option or parameter value not
permitted with the profile-and-level combination considered (e.g.,
B-pictures in the case of Simple Profile at Main Level), the test
bitstream must be omitted from the bitstream test suite.

All the bitstreams in the test suite must be such that the output of
the non-saturated integer number mathematical IDCT f ' (x, y),  as
defined in Annex A of ISO/IEC 13818-2,  has values but values within
the range [-384, 383] for each coded block.

A set of bitstreams constructed according to some of those
specifications is provided as an electronic annex to this document.

Test Bitstream #1

Specification: A series of consecutive frame B-pictures with all
macroblocks using bi-directional field-based prediction.  Luminance
sample rate and bitrate are the maximum allowed for the
profile-and-level combination.  Half-sample interpolation in both the
horizontal and vertical directions, for all luminance and chrominance
blocks.

Functional stage:  prediction bandwidth

Purpose: Check that the decoder handles the worst case of prediction
bandwidth.  Field-based prediction in frame pictures have the largest
prediction bandwidth overhead. Picture buffers organized as frames
(interleaved fields) and macroblocks stored in contiguous address page
segments would have the greatest penalty. Effective filtered block size
is 16x8.

Test Bitstream #2

Specification: A bitstream with a B-picture as large as the maximum
vbv_buffer_size allowed for the profile-and-level combination, using
long VLCs (not via escapes) as much as possible.  Luminance sample rate
and bitrate are the maximum allowed for the profile-and-level
combination.

Functional stage:  VLD

Purpose: Check that decoder works in this situation. A large B-picture
located after several smaller coded pictures can catch a decoder off
guard.

Test Bitstream #3

Specification: A series of consecutive frame P-pictures with all
macroblocks using dual-prime prediction.  Luminance sample rate and
bitrate are the maximum allowed for the profile-and-level combination.
Maximize number of half-sample prediction in both the horizontal and
vertical directions, for both luminance and chrominance blocks.

Functional stage:  prediction bandwidth

Purpose: Check that the decoder handles the worst case of prediction
bandwidth.  Prediction bandwidth is at a maximum in this mode due to
the small block sizes and two prediction sources.

Test Bitstream #4

Specification: A bitstream with all macroblock_type transitions in
frame and field pictures.

Functional stage:  parser

Purpose: Check that decoder handles all scenarios in parsing tree.

Test Bitstream #5

Specification: A bitstream where every slice contains only one
macroblock, and where intra_slice_bit is present in every slice.
Luminance sample rate and bitrate are the maximum allowed for the
profile-and-level combination.

Functional stage:   VLD and parser

Purpose: Check that decoder handles bitstreams with very short slices.
CPU-oriented designs have large overhead for each slice and macroblock
header.

Test Bitstream #6

Specification: A bitstream with many different combinations of values
for top_field_first, repeat_first_field, alternate_scan,
intra_vlc_format,  picture_structure, concealment_motion_vectors,
intra_dc_precision, f_codes, q_scale_type, progressive_frame,
frame_pred_frame_dct, variable numbers of consecutive coded B-frames,
coded P-frames and coded I-frames, with some coded I-frames in the form
of "I-P field-pictures",  with downloaded quantization weighting
matrices.  Ideally the bitstream should contain all possible legal
combinations.  Various syntax switches are toggled from
picture-to-picture.

Functional stage:   parser and control

Purpose:  Check that decoder handle all scenarios.

Test Bitstream #7

Specification: A bitstream with simultaneous burst of coded bits and
maximum bandwidth dual-prime MC, followed by remaining macroblocks
outside the burst with Dual Prime MC.  Luminance sample rate and
bitrate are the maximum allowed for the profile-and-level combination.
Maximize number of half-sample predictions in both the horizontal and
vertical directions, luminance and chrominance blocks.

Functional stage:   VLD and prediction bandwidth

Purpose:  DRAM is shared by VLD, MCP, and Display functions. This
combination presents the longest sustainable period (whole picture) for
DRAM bandwidth

Test Bitstream #8

Specification: All possible VLCs symbols and IDCT mismatch.  Mismatch
and saturation.

Functional stage:   parser ; IDCT accuracy

Purpose: Test that decoders has included the complete VLC tables and
implements mismatch control.

Test Bitstream #9

This test has been removed from the test suite specification.

Test Bitstream #10

Specification: Bitstream with only intra macroblocks using only the DC
coefficient and predicted macroblocks having no DCT coefficients.
Reconstructed motion vectors used for predicting both luminance and
chrominance have all possible combinations of half-sample and
full-sample values, both for the horizontal and the vertical
coordinates, and all those combinations are used for each prediction
mode in both frame and field pictures, and with both interlaced and
progressive chroma format in the case of 4:2:0 frame pictures.

Functional stage:   MCP

Purpose: Check that decoder implements motion compensation stages with
full accuracy in all cases.  Except for reconstruction of Intra DC
blocks, the test does not involve other decoder functions such as IDCT,
inverse quantization and mismatch control. When a static decoder test
is performed using the static test technique described in this
document, the decoder under test shall reconstruct samples identical to
those reconstructed by a reference decoder for all predicted
macroblocks.

Test Bitstream #11

Specification: Flat distribution of VLC events (worst case for constant
rate symbolic VLDs) on B and P pictures.  Luminance sample rate and
bitrate are the maximum allowed for the profile-and-level combination.

Functional stage:   VLD

Purpose: Check that decoder does not  rely on statistically low count
of symbols over global areas to meet real-time constraints.

Test Bitstream #12

Specification: Bursty case for number of bits per macroblock with
different burst location within picture (top, bottom), followed
Bi-directional macroblocks.  All motion vectors with half-sample
components.  Macroblocks outside the burst concentration have all
bi-directional prediction Luminance sample rate and bitrate are the
maximum allowed for the profile-and-level combination.  Half-sample in
both the horizontal and vertical directions, luminance and chrominance
blocks.  Maximize number of prediction blocks required to reconstruct a
macroblock.

Functional stage:   VLD and prediction bandwidth

Purpose:  Check that decoder does not rely upon statistically small
number of coded bits over local areas.

Test Bitstream #13

Specification: A series of consecutive Field-coded P-pictures, all
macroblocks using Dual Prime prediction.  As many half-sample
components as possible in both the horizontal and vertical directions,
luminance and chrominance blocks.  Luminance sample rate and bitrate
are the maximum allowed for the profile-and-level combination.
Maximize number of prediction blocks required to reconstruct a
macroblock.

Functional stage:   prediction bandwidth

Purpose:  Check that decoder handles largest prediction bandwidth with
field-coded P-pictures.  This test is somehow similar to Test Bitstream
#3, except that it uses field-pictures with Dual Prime.

Test Bitstream #14

Specification: A bitstream with a series of consecutive Field coded
B-pictures with 16x8 bi-directional macroblock motion compensation.
Sequence contains many consecutive B pictures. Luminance sample rate
and bitrate are the maximum allowed for the profile-and-level
combination.  Use half-sample prediction in both the horizontal and
vertical directions,  for all luminance and chrominance blocks.
Maximize number of prediction blocks required to reconstruct a
macroblock.

Functional stage:   prediction bandwidth

Purpose:  Check that decoder can cope with this case of worst case
bandwidth.  This test is somehow similar to Test Bitstream #1, except
that it uses field-pictures.

Test Bitstream #15

Specification: Bitstream with R/P bits worth of extra_bit_slice in
picture.  Luminance sample rate and bitrate are the maximum allowed for
the profile-and-level combination.

Functional stage:   Parser

Purpose:  Check that decoder is capable of handling a large number of
bits concentrated in the extra bit slice loop.

Test Bitstream #16

Specification: ISO/IEC 11172-2 (MPEG-1) constrained parameter
bitstream.  Luminance sample rate and bitrate are the maximum allowed
for MPEG-1 constrained parameter bitstream.

Functional stage:   overall

Purpose:  Check that decoder can decode MPEG-1 constrained bitstreams.

Test Bitstream #17

This test has been removed from the test suite specification.

Test Bitstream #18

Specification: Low delay sequence with skipped pictures.  Luminance
sample rate and bitrate are the maximum allowed for the
profile-and-level combination.

Functional stage:   controller

Purpose: Check that decoder is capable of decoding low delay mode and
knows how to recognize and deal with skipped pictures and buffer
underflows in the VBV model.

Test Bitstream #19

Specification: A bitstream implementing a test close to the IEEE 1180
IDCT mismatch test, to test the decoder's IDCT statistical accuracy.
Can be done using P-pictures with a flat custom quantization matrix
with all 16, and a quantizer stepsize of 0.5. Use whatever number of
frames are required to satisfy statistic count.  Note that because of
saturation in [0, 255], the test cannot emulate exactly the IEEE 1180
IDCT test.

Functional stage:   IDCT

Purpose:  Check IDCT decoder accuracy.  This is not a drift test since
all macroblocks are of type Intra.

Test Bitstream #20

Restriction: Only for profile-and-level combinations supporting SNR
scalability:

Specification:  Maximum VLD bandwidth on both layers (base and
enhancement) with burst of escape codes, bursts of short VLCs and
maximum buffer size on both layers Luminance sample rate and bitrate
are the maximum allowed for the profile-and-level combination.

Functional stage:   test of parser(s)

Purpose: Test of the maximum VLD bandwidth on both layers (base and
enhancement) with burst of escape codes, bursts of short VLCs and
maximum buffer size on both layers.  Some designs may not be able to
handle both layers

Test Bitstream #21

Restriction: Only for profile-and-level combinations supporting SNR
scalability:

Specification: Skipped macroblocks on base layer, on enhancement layer,
and on both layers together.  Test of the DCT type in the enhancement
layer while macroblocks are skipped in the base layer.  Luminance
sample rate and bitrate are the maximum allowed for the
profile-and-level combination.

Functional stage:   test of parser

Purpose:  Test of skipped MBs on base layer, on enhancement layer, and
on both layers together.  Test of the DCT type in the enhancement layer
while macroblocks are skipped in the base layer.  Sloppy decoders may
not be able to handle skipped macroblocks in one of the layers.

Test Bitstream #22

Restriction: Only for profile-and-level combinations supporting SNR
scalability:

Specification: Different weighting matrices, different scanning on the
two layers. Luminance sample rate and bitrate are the maximum allowed
for the profile-and-level combination.

Functional stage:   test of decoder

Purpose:  Test of different weighting matrices, different scanning on
the two layers. Sloppy decoders may not be able to handle different
weighting matrices or scanning order.

Test Bitstream #23

Restriction: Only for profile-and-level combinations supporting Spatial
scalability:

Specification: All macroblock transitions in enhancement layer, all
possible VLC symbols in enhancement layer, and all cases of motion
vector updating, 3:1 horizontal and 2:1 vertical up-sampling, panning,
all cases of up-conversion (interlace to interlace, interlace to
progressive, progressive to interlace, etc.), all weight code tables,
regions with spatial prediction only.

Functional stage:   static test of spatially scalable decoder

Purpose: Test of all macroblock transitions in enhancement layer, all
possible VLC symbols in enhancement layer, and all cases of motion
vector updating.  Sloppy decoders may not be able to handle all
possible cases.

Test Bitstream #24

Restriction: Only for profile-and-level combinations supporting Spatial
scalability:

Specification: Different numbers of consecutive I, P and B frames in
base and enhancement layer, spatial prediction based on the second most
recently decoded base layer picture, mixing frame and field pictures,
2:1 upsampling in both directions.

Functional stage:   static test of spatially scalable decoder

Purpose:  Test that decoder can cope with different numbers of
consecutive I, P and B frames in base and enhancement layer, test that
decoder handles properly spatial predictions based on the second most
recently decoded base layer picture, test that decoder handles properly
mixed frame and field pictures.

Test Bitstream #25

Specification:  Bitstream causing maximum saturation of the inverse
quantization by creating the greatest amplitude combinations of
macroblock quantization (code 31), visual weighting matrix (value 255),
and DCT coefficient (value -2047 or 2047).

Functional stage:   inverse quantization

Purpose:  Test that decoder implements properly the saturation of the
inverse quantization (before the mismatch control).

Test Bitstream #26

Specification:  Bitstream causing large positive sample domain
coefficients f[y][x] (e.g., 255) added to large predicted values
p[y][x] (e.g., 255), or large negative sample domain coefficients
f[y][x] (e.g., -256) added to small predicted values p[y][x] (e.g.,
0).

Functional stage:   addition of the output of IDCT f[y][x] to the
predicted values p[y][x] and saturation of the result to the range [0,
255].

Purpose:  Test that decoder implements properly the addition of the
output of IDCT f[y][x] to the predicted values p[y][x] and saturation
of the result to the range [0, 255].

Test Bitstream #27

Specification:  A bitstream with 16 bytes "extra_information_slice" in
slice headers, and groups of 4096 bit of reserved and compatible
extensions.

Functional stage:   parser (discarding of reserved data).

Purpose:  Test that decoder implements correctly parsing and discarding
of certain types of reserved data (to ensure forward compatibility with
future extensions of the standard), at least when a reasonable amount
of those reserved data are present.

Test Bitstream #28

Specification:  A bitstream with zero byte stuffing :

 In the first half of the bitstream : at one of the legal positions in
 the bitstream, there will be at least 0.9*VBV_buffer_size worth of
 zero bit stuffing.

  In the second half of the bitstream, there will be in each picture,
  at a legal position, between R/P and 0.9*R/P zero bit stuffing
  (R=maximum bit rate of the bitstream ; 1/P= time between two
  consecutive pictures).

Functional stage:   parser (discarding of stuffing).

Purpose:  Test that decoder is capable of discarding stuffing in the
worst case (almost a full VBV worth of stuffing).

Test Bitstream #29

Specification:  A bitstream with frame pictures, with motion vectors
that are as large as permitted by the profile-and-level combination.

Functional stage:   reconstruction of motion vectors, MCP, control

Purpose:  Check that decoder implements motion compensation properly
when motion vectors are very large.

Test Bitstream #30

Specification:  A bitstream with quantizer matrices (intra and
non-intra, and if permitted, chroma matrices too).  Matrices are not
symmetrical (e.g.,  matrix coefficients are random numbers in the range
[1, 255]).  If permitted, use of both scanning orders.

Functional stage:   quantizer matrix download, matrix scanning.

Purpose:  Check that decoder can download properly quantizer matrices
and that it uses of correct scanning of the matrices (i.e. not
transposed).

Test Bitstream #31

Specification:  An ISO/IEC 11172-2 bitstream with D-pictures only, with
constrained_parameter_flag = 0, frame size, bitrate and vbv_buffer_size
set to the maximum allowed by the profile-and-level combination of the
decoder.

Functional stage:   overall

Purpose:  Check that decoder can decode ISO/IEC 11172-2 bitstreams with
D-picture only, with parameters in the range supported by the
profile-and-level combination of the decoder.

Test Bitstream #32

Specification:  An ISO/IEC 11172-2 bitstream with
constrained_parameter_flag = 1 and horizontal_size = 768.

Functional stage:   overall

Purpose:  Check that decoder can decode ISO/IEC 11172-2 constrained
parameter bitstreams with the maximum .horizontal_size allowed when
constrained_parameter_flag = 1.

Test Bitstream #33

Specification:  An ISO/IEC 11172-2 bitstream with
constrained_parameter_flag = 1, vertical_size > 480 lines and
frame_rate different from '25Hz'.

Functional stage:   overall

Purpose:  Check that decoder can decode ISO/IEC 11172-2 constrained
parameter bitstreams vertical_size > 480 lines and frame_rate different
from '25Hz' (this combination is not allowed in some profile-and-level
combinations, but is allowed for ISO/IEC 11172-2 constrained parameter
bitstreams, as long as horizontal_size is small enough).

Test Bitstream #34

Specification: A bitstream in which the output of the non-saturated
integer number mathematical IDCT f ' (x, y),  as defined in Annex A of
ISO/IEC 13818-2,  has large absolute values but values within the range
[-384, 383] for each coded block.  If decoder under test uses the same
IDCT for decoding ISO/IEC 11172-2 and ISO/IEC 13818-2  bitstreams,
then this test bitstream can be implemented as an ISO/IEC 11172-2
constrained parameter bitstream.

Functional stage:   IDCT

Purpose:  Check that IDCT decoder accuracy meets the requirements
defined in Annex A.  The peak error for a compliant decoder shall be
less or equal to than 2 when decoding this bitstream.  Note that for
blocks where f ' (x, y) has values within the range [-300, 300],
decoders that have a peak error larger than 1 may not be compliant with
the IEEE 1180 IDCT specification.

        2.4.5.4 Implementation of the static test

For each bitstream of the test suite, the following operations are
performed.

The bitstream is decoded by the decoder under test.  All the samples
reconstructed by the decoder under test are captured and stored for
future use.

The bitstream is then decoded by the reference decoder as follows:

Before decoding each P- or B-picture, the frame buffers of the
reference decoder are initialized with the reconstructed samples
captured from the decoder under test that correspond to those reference
frames.

This method called "frame buffer intercept method" guarantees that the
decoder under test and the reference decoder use the same reference
frames,  and therefore that mismatch does not accumulate.  See Figure
1.

Then the samples reconstructed by the reference decoder are captured
for each reconstructed picture, and compared to those reconstructed by
the decoder under test (previously captured) for the same picture.

This methodology guarantees that there cannot be accumulations of
errors, and that the difference observed for each sample only involves
one IDCT process.


  Figure 1.  Frame buffer intercept method
     
   [B]---->[S]---> (+) --[C]-------->  [O]
       |            ^            
       |            |              Test Decoder
       |            |            
       |          [MCP]<--[R]
       |                  [e]
       |                  [f]
       |                  [e]
       |                  [r]
       |                  [e]
       |                  [n]
       |                  [c]
       |          [MCP]<--[e]     Reference Decoder
       |            |                         
       |            |                         
       --->[S]---->(+) ---[C]--------> [O] 


   B:   test bitstream 
   S:   decoding processing units ISO/IEC 13818-2 sections 7.2 to 7.5
   MCP: motion compensation unit (ISO/IEC 13818-2 Section 7.6)
   R:   reference frame 
   O:   output of decoder (reconstructed samples)
   C:   clipping stage    [0,+255]
   U:   current frame
   
Note:  R is kept identical in both the Reference and Test Decoders.

        2.4.5.5 Implementation of the dynamic test

The dynamic test is often easier to perform on the complete decoder
system, which includes a systems decoder, a video decoder and a display
process.  It is possible to record the output of the display process
and to check that display order and timing of fields or frames are
correct.  However, since the display process is not within the
normative scope of ISO/IEC 13818-2, there may be cases where the output
of the display process is wrong even though the video decoder is
compliant.  In this case, the output of the video decoder itself
(before the display process) must be captured in order to perform the
dynamic tests on the video decoder.

The test includes verifying that the output of the decoding process
matches exactly the specification of section 7.12 of ISO/IEC 13818-2,
both in terms of sequence of events and in terms of timing between
events, the evens considered being the output of a reconstructed field
or frame by the decoder to the display process.

In particular the field or frame order and timing  shall be correct,
field parity must be accurate (e.g. the first output field of
interlaced frame with top_field_first equals to zero must be the bottom
field), and that fields or frames that are coded as being repeated are
indeed repeated at the output of the decoding process.

        2.4.5.6 Decoder conformance

In order for a decoder of a particular  profile-and-level to claim
compliance to the standard described by this document, the decoder
shall pass successfully both the static test defined in section 2.4.5.1
and the dynamic test defined in section 2.4.5.2 with all the bitstreams
of the normative test suite specified for testing decoders of this
particular profile-and-level.

The normative test suites for each profile-and-level combination are
defined by Table 1-1.  The test suite for a particular
profile-and-level combination is the list of bitstreams that are marked
with an 'x' in the column corresponding to that profile-and-level
combination.  In Table 1-1, "test bitstream directory" is the name of
the directory that contain the test bitstream (and associated data) in
the electronic annex.

When the test suite for a profile-and-level combination does not
include any bitstream of this same profile-and-level,  it is not
possible to test adequately compliance to the standard for decoders of
that profile-and-level.  At this time this standard provides no
adequate tests to verify compliance of decoders of the following
profile-and-level:  HP@HL, HP@H-14, HP@ML, SNR@LL, MP@HL, MP@H-14,
MP@LL.

Table 1-1

Normative test suite for HP@HL------------------------------------+
Normative test suite for HP@H-14--------------------------------+ |
Normative test suite for HP@ML--------------------------------+ | |
Normative test suite for Spt@H-14---------------------------+ | | |
Normative test suite for SNR@ML---------------------------+ | | | |
Normative test suite for SNR@LL-------------------------+ | | | | |
Normative test suite for MP@HL------------------------+ | | | | | |
Normative test suite for MP@H-14--------------------+ | | | | | | |
Normative test suite for MP@ML--------------------+ | | | | | | | |
Normative test suite for MP@LL------------------+ | | | | | | | | |
Normative test suite for SP@ML----------------+ | | | | | | | | | |
Normative test suite for 4:2:2@ML-----------+ | | | | | | | | | | |
Profile-and-level of the bitstream-+        | | | | | | | | | | | |
+- Bitstream specification #       |        | | | | | | | | | | | |
|  +--test bitstream directory     |        | | | | | | | | | | | |
|  |                               |        | | | | | | | | | | | |
V  V                               V        V V V V V V V V V V V V
30 tcela/tcela-16-matrices        11172-2   x x x x x x x x x x x x
31 tcela/tcela-18-d-pict          11172-2   x x x x x x x x x x x x
34 compcore/ccm1                  11172-2   x x x x x x x x x x x x
32 tcela/tcela-19-wide            11172-2   x x x x x x x x x x x x
 3 toshiba/toshiba_DPall-0        SP@ML     x x . x x x x x x x x x
 3 nokia/nokia6                   SP@ML     x x . x x x x x x x x x
 3 nokia/nokia_7                  SP@ML     x x . x x x x x x x x x
 3 tcela/tcela-14-bff-dp          SP@ML     x x . x x x x x x x x x
 7 ibm/ibm-bw-v3                  SP@ML     x x . x x x x x x x x x
13 tcela/tcela-8-fp-dp            SP@ML     x x . x x x x x x x x x
13 tcela/tcela-9-fp-dp            SP@ML     x x . x x x x x x x x x
16 mei/MEI.stream16v2             SP@ML     x x . x x x x x x x x x
16 mei/MEI.stream16.long          SP@ML     x x . x x x x x x x x x
18 ntr/ntr_skipped_v3             SP@ML     x x . x x x x x x x x x
27 teracom/teracom_vlc4           SP@ML     x x . x x x x x x x x x
28 tcela/tcela-15-stuffing        SP@ML     x x . x x x x x x x x x
29 tcela/tcela-17-dots            SP@ML     x x . x x x x x x x x x
 1 gi/gi4                         MP@ML     x . . x x x x x x x x x
 1 gi/gi6                         MP@ML     x . . x x x x x x x x x
 1 gi/gi_from_tape                MP@ML     x . . x x x x x x x x x
 1 gi/gi7                         MP@ML     x . . x x x x x x x x x
 1 gi/gi_9                        MP@ML     x . . x x x x x x x x x
 1 ti/TI_c1_2                     MP@ML     x . . x x x x x x x x x
 2 tceh/tceh_conf2                MP@ML     x . . x x x x x x x x x
 2 mei/mei.2conftest.4f           MP@ML     x . . x x x x x x x x x
 2 mei/mei.2conftest.60f.new      MP@ML     x . . x x x x x x x x x
 4 tek/Tek-5.2                    MP@ML     x . . x x x x x x x x x
 4 tek/Tek-5-long                 MP@ML     x . . x x x x x x x x x
 5 tcela/tcela-6-slices           MP@ML     x . . x x x x x x x x x
 5 tcela/tcela-7-slices           MP@ML     x . . x x x x x x x x x
 6 sony/sony-ct1                  MP@ML     x . . x x x x x x x x x
 6 sony/sony-ct2                  MP@ML     x . . x x x x x x x x x
 6 sony/sony-ct3                  MP@ML     x . . x x x x x x x x x
 6 sony/sony-ct4                  MP@ML     x . . x x x x x x x x x
 8 att/att_mismatch               MP@ML     x . . x x x x x x x x x
 8 teracom/teracom_vlc4           MP@ML     x . . x x x x x x x x x
10 ccett/mcp10ccett               MP@ML     x . . x x x x x x x x x
11 lep/bits_conf_lep_11           MP@ML     x . . x x x x x x x x x
12 hhi/hhi_burst_short            MP@ML     x . . x x x x x x x x x
12 hhi/hhi_burst_long             MP@ML     x . . x x x x x x x x x
14 tcela/tcela-10-killer          MP@ML     x . . x x x x x x x x x
23 tceh/tceh_conf23.v2            Spt@H-14  . . . . . . . . x . x x
24 hhi/hhi_spat23                 Spt@H-14  . . . . . . . . x . x x
20 tceh/tceh25_conf               SNR@ML    . . . . . . . x x x x x
22 hhi/hhi22_snr                  SNR@ML    . . . . . . . x x x x x
21 ti/ti_snr                      SNR@ML    . . . . . . . x x x x x
 2 Tek6-422-bigBpic               4:2:2@ML  x . . . . . . . . . . .
 2 Tek6-422-bigBpic-long          4:2:2@ML  x . . . . . . . . . . .
 5 Tek7-422-smallSlices           4:2:2@ML  x . . . . . . . . . . .
 5 Tek7-422-smallSlices-long      4:2:2@ML  x . . . . . . . . . . .
14 Tek8-422-16x8inBpics           4:2:2@ML  x . . . . . . . . . . .
14 Tek8-422-16x8inBpics-long      4:2:2@ML  x . . . . . . . . . . .
11 Tek9-422-uniformVLC            4:2:2@ML  x . . . . . . . . . . .
11 Tek9-422-uniformVLC-long       4:2:2@ML  x . . . . . . . . . . .
 7 ibm_dp_intra_422               4:2:2@ML  x . . . . . . . . . . .
 1 sony_422_id01-1                4:2:2@ML  x . . . . . . . . . . .
 3 sony_422_id03-1                4:2:2@ML  x . . . . . . . . . . .
13 sony_422_id13-1                4:2:2@ML  x . . . . . . . . . . .
      
Successfully passing the conformance tests defined in this document
only provides a strong presumption that the decoder under test is
compliant, i.e. that it does indeed meet all the requirements specified
in ISO/IEC 13818-2.

Additional tests may be necessary to check more thoroughly that a
decoder implements properly all the requirements specified in ISO/IEC
13818-2.

        2.4.6 Conformance of scalable bitstreams and decoders

This section contains additional information to clarify the compliance
assessment procedure for profile-and-level combinations that include
any of the scalable video coding methods that are defined in chapters
7.7 to 7.11 of ISO/IEC 13818-2.  It is to be seen as a supplement to
the preceding part of chapter 2.4 of this specification.

Scalable video coding involves a plurality of video bitstreams forming
a scalable hierarchy of bitstreams and the appropriate encoders and
decoders to generate and decode them, respectively.

Some profiles-and-level combinations in Chapter 8 of ISO/IEC 13818-2
define requirements for such scalable hierarchies of bitstreams and the
associated decoders.

The assessment of the compliance of scalable video bitstream
hierarchies and corresponding decoders is generally done as detailed in
the preceding part of this chapter 2.4. However a couple of
differences, related to the presence of a plurality of bitstreams in
the scalable hierarchy must be noted:

The term 'bitstream' now refers to one out of a set of ISO/IEC 13818
video bitstreams forming a scalable hierarchy of bitstreams.

The term 'encoder' now refers to a ISO/IEC 13818 video encoder defined
as a process that generates a scalable hierarchy of ISO/IEC 13818 video
bitstreams.

The term 'decoder' now refers to a ISO/IEC 13818 video decoder, i.e.,
an embodiment of the decoding process for decoding a scalable hierarchy
of bitstreams as specified by ISO/IEC 13818-2.

        2.4.6.1 Definition of scalable video bitstream hierarchy compliance

In a compliant scalable hierarchy of bitstreams each individual
bitstream shall be conformant (as defined in section 2.4.2) to its
profile-and-level as specified in the sequence_extension() of the
bitstream.  Furthermore, the individual bitstreams of a scalable
hierarchy shall meet additional (stricter) constraints defined in
Chapter 8 of ISO/IEC 13818-2 for scalable profile-and-level
combinations.

        2.4.6.1.1 Requirements and restrictions related to profile-and-level

A compliant bitstream with a profile-and-level indication as specified
in its sequence_extension() in conjunction with the associated
(compliant) lower layer bitstream(s) of this scalable hierarchy shall
be decodable by any compliant ISO/IEC 13818 video decoder that supports
this profile-and-level combination.

        2.4.6.1.2 Encoder requirements and recommendations

        2.4.6.1.2.1 Encoder requirements

The requirements detailed in section 2.4.2.3 must be met for each
individual bitstreams of the scalable hierarchy generated by an
encoder.

        2.4.6.1.2.2 Encoder recommendations

It is strongly recommended that scalable video encoders capable of
producing P-pictures implement Note 2 of clause 7.4.4 of ISO/IEC
138181-2 in each layer of the ordered set of bitstreams.

It is also strongly recommended that the temporal interval between
frames using the same value for temporal_reference be as large as
possible, so that ambiguities in the synchronisation of the bitstreams
of a scalable hierarchy is unlikely when the hierarchy is not embedded
in a systems multiplex according to ISO/IEC 13818-1 (MPEG-2 Systems).

        2.4.6.2 Procedure for testing bitstream compliance

When testing the compliance of a bitstream that is member of a scalable
hierarchy, the conformance test shall verify that the decoder does not
violate the following two sets of constraints.

Constraints corresponding to the profile-and-level as specified in the
sequence_extension() of the bitstream under test.

Additional constraints for the bitstream under test as given in the
definition of the profile-and-level as specified in the
sequence_extension() of the other layer bitstreams of the scalable
hierarchy.

        2.4.6.3 Definition of video decoder compliance

When a decoder claims to be compliant with a given scalable
profile-and-level, the embedded decoder(s) that decode the associated
lower layer bitstream(s) of a scalable bitstream hierarchy shall pass
the conformance test corresponding to its (their) respective
profile-and-level combination(s).

Any profile-and-level combination, options and parameter values that
are allowed for the lower layer bitstream(s) according to the
definition of the given profile-and-level of the decoder under test
must be supported.

        2.4.6.4 Procedure to test decoder compliance

Tests of the scalable functionalities of a decoder always involve the
decoding of a bitstream from a scalable hierarchy including its lower
layer bitstream(s), unless the base layer bitstream or any applicable
non-scalable test bitstream is the only decoder input for a specific
test.

Note that the test of a scalable decoder not only includes decoding of
scalable hierarchies of bitstreams but also of non-scalable bitstreams
conforming to those profile-and-level indications that must also be
decodable by the scalable decoder under test according to Chapter 8.

        2.4.6.4.1 Dynamic tests

Dynamic tests of a scalable decoder shall also check that the timing
relation between the bitstreams of a scalable hierarchy is correct.

        2.4.6.4.2 Specification of the test bitstreams

To test the compliance of a decoder of a profile-and-level allowing
scalable coding, it is necessary to generate scalable hierarchies of
bitstreams. The test bitstreams of the normative test suites provided
for testing scalable profiles are individual video bitstreams.  However
it is necessary to multiplex these bitstreams according to ISO/IEC
13818-1 (MPEG-2 Systems) to unambiguously convey the necessary timing
information to the decoder.  This simple exercise is left to the reader
who is advised to study carefully ISO/IEC 13818-1 before generating a
multiplexed bitstream.

        2.4.6.4.3 Implementation of the static test for SNR scalability

In the case of SNR scalability, the frame buffer intercept method as
detailed in section 2.4.5.4 shall be applied with a base layer and an
enhancement layer bitstream instead of one input bitstream B.  The
decoding process S of the figure in section 2.4.5.4 decodes the two
bitstreams according to ISO/IEC 13818-2 sections 7.2 to 7.5 and 7.8.

        2.4.6.4.4 Implementation of the static test for spatial scalability

In case of spatial scalability, the frame buffer intercept method as
detailed in section 2.4.5.4 shall be applied also to the spatial
reference frames (i.e. the output frames of the lower layer decoder).

More precisely this means:

All bitstreams of the scalable hierarchy are decoded by the decoder
under test.  All the samples reconstructed by the decoder under test,
including the samples reconstructed from decoding the lower layer
bitstream(s), that are used for spatial prediction, are captured and
stored for future use.

The compliance of the embedded lower layer decoder must be tested
first, as described in chapter 2.4.5. Assuming a compliant embedded
lower layer decoder within the decoder under test, now the upper layer
bitstream is decoded by the reference decoder as follows:

Before decoding each P- or B-picture, the frame buffers for temporal
prediction reference frames in the reference decoder are initialized
with the reconstructed samples captured from the decoder under test
that correspond to those reference frames.

Additionally the frame buffer for the spatial prediction reference
frame of the reference decoder is initialized from the reconstructed
samples corresponding to this reference frame and captured from the
embedded lower layer decoder within the decoder under test.

        2.4.6.4.5 Implementation of the dynamic test

A dynamic test of a scalable decoder should be done using a complete
decoder system, which includes a systems decoder, a video decoder and a
display process. This is to assure a proper timing relation between the
bitstreams of a scalable hierarchy to be decoded.

<end of the video sections>