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: <> 2) The text of section 3.3 of the IEEE specification is replaced by : <> 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.