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:  <

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 :

<

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