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