BS (MDEC Bitstream Data): Difference between revisions
| Revision as of 02:46, 23 October 2026 RemmyLee (SPU and CD-ROM at register depth; CPU overview rewritten) | Revision as of 02:47, 23 October 2026 RemmyLee (Formats: Sony paragraph voice; HMD, RSD extended files, full BS code book; sprite editor formats) | ||
| Line 11: | Line 11: | ||
| ## Overview | ## Overview | ||
| − | BS is the image data format used by MDEC and libpress.[^ff18] | + | BS is the image data format used by MDEC and libpress. Original MDEC image data is a series of 24-bit RGB images arranged over time, and each image is called a frame. A frame is a multiple of 16 pixels wide by a multiple of 16 pixels tall, and a source of any other size needs additional processing. Because MDEC does not use correlations between frames, each frame can be processed independently.[^ff18][^ff19] |
| − | Original MDEC image data is a series of 24-bit RGB images over time. Each image is called a frame.[^ff18] | ||
| − | |||
| − | A frame is a multiple of 16 pixels wide and a multiple of 16 pixels tall. Other sizes need additional processing.[^ff18][^ff19] | ||
| − | |||
| − | MDEC does not use correlations between frames. Each frame can be processed on its own.[^ff18] | ||
| − | |||
| ## Macroblocks | ## Macroblocks | ||
| − | MDEC treats each frame as a collection of 16x16 pixel regions. These regions are called macroblocks.[^ff18] | + | MDEC treats each frame as a collection of small regions of 16x16 pixels, which are called macroblocks. A 320x240 image, for example, is split into 16x16 macroblocks and each macroblock is then compressed. MDEC writes the decoded results back to main memory as macroblocks, and the CPU and the GPU reconstruct the frame from them.[^ff18] |
| − | MDEC writes the decoded results to main memory as macroblocks. The CPU and the GPU rebuild the frame from them.[^ff18] | + | When encoding, the pixels of a frame are reordered so that each macroblock is unified. The encoder orders the macroblocks vertically from the top left. This reduces the number of times the frame buffer transfer command (LoadImage) is executed during playback.[^ff19] |
| − | The encoder orders macroblocks vertically from the top left. This reduces the number of LoadImage frame buffer transfers.[^ff19] | ||
| − | |||
| ### Color Space Conversion | ### Color Space Conversion | ||
| − | MDEC works internally in the YCbCr color system. RGB macroblocks must be converted to YCbCr. This step is called CSC (Color Space Conversion).[^ff110] | + | MDEC performs its internal processing in the YCbCr color system, so RGB macroblocks must be converted to YCbCr. This process is called CSC (Color Space Conversion). It can be understood as a coordinate transformation in the three-dimensional space formed by the R, G and B components. MDEC converts YCbCr to RGB with the following matrix:[^ff110] |
| − | MDEC converts YCbCr to RGB with the following matrix:[^ff110] | ||
| − | |||
| Table: YCbCr to RGB conversion | Table: YCbCr to RGB conversion | ||
| Line 41: | Line 31: | ||
| | B | 1.0 | 1.772 | 0 | | | B | 1.0 | 1.772 | 0 | | ||
| − | The MOVCONV encoder converts RGB to YCbCr with the inverse matrix.[^ff110] | + | The inverse of this matrix is used to convert from RGB to YCbCr, and the MOVCONV encoder uses it:[^ff110] |
| − | The inverse matrix is as follows: | ||
| − | |||
| − | |||
| Table: RGB to YCbCr conversion | Table: RGB to YCbCr conversion | ||
| Line 54: | Line 41: | ||
| | Cr | 0.5 | -0.4187 | -0.0813 | | | Cr | 0.5 | -0.4187 | -0.0813 | | ||
| − | Y is the luminance signal. Cb and Cr are the color-difference signals.[^ff110] | + | Physically, Y is the luminance signal and Cb and Cr are the color-difference signals. The PlayStation converts the RGB frame buffer to YCbCr for its video (S terminal) output, and the monitor converts the signal back to RGB. Because so many color space conversions are performed, the final color can differ from the expected color through gamma correction or the conversion matrices.[^ff110] |
| ### Blocks | ### Blocks | ||
| − | The color-difference signals are reduced to 1/4 (1/2 in x and 1/2 in y). Y is split into four 8x8 blocks.[^ff111] | + | The luminance signal generally needs higher resolution than the color-difference signals. The color-difference data is therefore reduced to 1/4 (1/2 in x and 1/2 in y), while Y is split into four 8x8 blocks. A 16x16 macroblock consequently becomes two color-difference blocks and four luminance blocks, and each 8x8 unit is called a block. The blocks are arranged in the following order:[^ff111] |
| − | A 16x16 macroblock becomes two color-difference blocks and four luminance blocks. Each 8x8 unit is called a block.[^ff111] | ||
| − | |||
| − | The blocks are in this order: | ||
| − | |||
| − | |||
| Table: Macroblock arrangement | Table: Macroblock arrangement | ||
| Line 76: | Line 58: | ||
| | 6 | Y3 | Luminance | | | 6 | Y3 | Luminance | | ||
| − | MOVCONV reduces the color-difference blocks by averaging four adjacent points. The average acts as a two-dimensional lowpass filter.[^ff111] | + | The color-difference blocks can be reduced by taking only the even-numbered points, but elements at or over 1/4 of the sampling frequency are then carried over as aliasing noise. MOVCONV instead averages four adjacent points, which acts as a two-dimensional lowpass filter and gives better results. Some aliasing still remains, and a filter with more dimensions would need more encoding time.[^ff111] |
| ### Block Offset | ### Block Offset | ||
| − | In 8-bit YCbCr, Y ranges from 0 to 255. Cb and Cr range from -128 to +127.[^ff112] | + | In 8-bit YCbCr, Y ranges from 0 to 255 while Cb and Cr range from -128 to +127. To unify the ranges of the luminance and color-difference blocks, 128 is subtracted from every luminance value. During decoding MDEC checks whether a block is a luminance block and, if it is, adds 128 to return the value to its original range.[^ff112] |
| − | The encoder subtracts 128 from the luminance values so that all blocks share one range. MDEC adds 128 back when it decodes a luminance block.[^ff112] | ||
| − | |||
| ## Encoding | ## Encoding | ||
| ### DCT | ### DCT | ||
| − | DCT (Discrete Cosine Transformation) is applied to each block. It is an orthogonal transformation Y = P x X x Pt of the 8x8 block X.[^ff112] | + | DCT (Discrete Cosine Transformation) is applied to each block of the macroblock. It is an orthogonal transformation Y = P x X x Pt of the 8x8 block X, where P x Pt is the unit matrix. IDCT is therefore DCT with P replaced by its transpose.[^ff112] |
| − | IDCT is DCT with P replaced by its transpose.[^ff112] | + | Physically, DCT is a frequency transformation. Element (0,0) of the result is the DC element and equals the average of the block. The other elements are AC elements whose frequency rises to the right and down. In natural images the values grow smaller toward the bottom right, and compression with DCT takes advantage of this tendency.[^ff113] |
| − | Element (0,0) of the result is the DC element. It equals the average of the block, and the other elements are AC elements.[^ff113] | ||
| − | |||
| − | Frequency rises to the right and down in the matrix. Natural images give small values toward the bottom right, and DCT compression uses this.[^ff113] | ||
| − | |||
| ### Quantization | ### Quantization | ||
| − | Each element is divided by its quantization table entry times QUANT. QUANT sets the quantization step for the whole block.[^ff113] | + | After DCT each element is quantized by dividing it by the product of its quantization table (Q table) entry and QUANT, which sets the quantization step for the whole block. DC elements are not affected by QUANT. MDEC currently uses the same table for luminance and color-difference blocks:[^ff113] |
| − | The DC element is not affected by QUANT. MDEC uses the same quantization table for luminance and color-difference blocks.[^ff113] | ||
| − | |||
| − | The quantization table is as follows: | ||
| − | |||
| − | |||
| Table: MDEC quantization table (x 1/16) | Table: MDEC quantization table (x 1/16) | ||
| Line 118: | Line 89: | ||
| | 7 | 27 | 29 | 35 | 38 | 46 | 56 | 69 | 83 | | | 7 | 27 | 29 | 35 | 38 | 46 | 56 | 69 | 83 | | ||
| − | A larger QUANT loses more data and lowers image quality. It also gives more zero elements and smaller run-level data.[^ff114] | + | The table values increase toward the bottom right because high-frequency elements need less accuracy than low-frequency elements. A large QUANT loses more data and lowers the image quality after decoding. However, it also increases the number of zero elements and therefore decreases the size of the run-level data.[^ff113][^ff114] |
| ### Zig-zag Transformation | ### Zig-zag Transformation | ||
| − | The quantized block is numbered in zig-zag order. The order starts from the lowest frequency elements.[^ff114] | + | The quantized block is numbered one-dimensionally in zig-zag order, and quantization and the zig-zag transformation are performed together. The order starts from the low-frequency elements, so more zero elements fall toward the end of the series and run-level compression becomes easier. The scan order is as follows:[^ff114] |
| − | The scan order is as follows: | ||
| − | |||
| − | |||
| Table: Zig-zag scan order (zscan) | Table: Zig-zag scan order (zscan) | ||
| Line 144: | Line 112: | ||
| ### Runlevel Code | ### Runlevel Code | ||
| − | Run-level conversion compresses the runs of zeros in a zig-zag ordered block. Each code is a pair (run, level).[^ff118] | + | Zig-zag ordered blocks tend to contain sequences of zeros, so the data is compressed by combining runs of zeros. This is called runlevel conversion. Each code is a pair (run, level), in which run is the number of zeros before a value and level is the value of the element. An actual runlevel code has 16 bits:[^ff118] |
| − | Run is the number of zeros before a non-zero coefficient. Level is the value of that coefficient.[^ff118] | ||
| − | |||
| − | A runlevel code has 16 bits: | ||
| − | |||
| − | |||
| Table: Runlevel code format | Table: Runlevel code format | ||
| Line 158: | Line 121: | ||
| | 0..9 | LEVEL | The non-zero coefficient (signed, 10 bits) | | | 0..9 | LEVEL | The non-zero coefficient (signed, 10 bits) | | ||
| − | The first code of a block always has a run of 0. Its run field holds QUANT, and its level field holds the DC coefficient.[^ff118] | + | The first code of a block always has a run of 0, even when the DC element is 0. The quantization step (QUANT) is therefore always placed in the run field of the first code, and its level field holds the DC coefficient. Runlevel codes are transferred two to a 32-bit word.[^ff118] |
| − | Two runlevel codes are packed in each 32-bit word.[^ff118] | ||
| − | |||
| ### NOP | ### NOP | ||
| − | (run, level) = (63, 128) = 0xfe00 is a NOP. It ends a block, and the remaining elements of the block are 0.[^ff119] | + | The number of runlevel pairs varies from block to block. (run, level) = (63, 128) = 0xfe00 is therefore inserted after the final pair of each block as a NOP. A NOP ends the block, and the remaining elements of the block are 0. A NOP between blocks is skipped, and when two NOPs appear in the middle of a block the second is skipped.[^ff119] |
| − | A NOP between blocks is skipped. A second NOP in a row is also skipped.[^ff119] | ||
| − | |||
| ### RL Data | ### RL Data | ||
| − | RL data holds all the run-level blocks needed for decoding. It has a one-word header and a footer that keeps 32-word boundaries.[^ff119] | + | RL data combines all the runlevel blocks required for decoding. It has a one-word header and a footer that maintains 32-word boundaries. The blocks are in the order Cb, Cr, Y0, Y1, Y2, Y3, so six blocks make one macroblock and the number of blocks must be a multiple of 6. The header word has the following format:[^ff119] |
| − | The blocks are in the order Cb, Cr, Y0, Y1, Y2, Y3. The number of blocks must be a multiple of 6.[^ff119] | ||
| − | |||
| − | The header word is as follows: | ||
| − | |||
| − | |||
| Table: RL header word | Table: RL header word | ||
| Line 184: | Line 138: | ||
| | 0..15 | SIZE | Data size in words, not including the header | | | 0..15 | SIZE | Data size in words, not including the header | | ||
| − | The data size must be a multiple of 32. A footer of NOPs pads the data to that length.[^ff119] | + | The data size must be a multiple of 32. Consequently a footer of NOPs is added as padding to make the data a fixed length.[^ff119] |
| − | The RL data syntax on page 1-20 lists QUANT and RUN as 5 bits. Figures 12 and 13 give them as 6 bits.[^ff118][^ff120] | + | The RL data syntax on page 1-20 lists QUANT and RUN as 5 bits. Figures 12 and 13 on page 1-18 give them as 6 bits.[^ff118][^ff120] |
| ## VLC | ## VLC | ||
| − | VLC (Variable Length Coding) is Huffman coding with a fixed code book. Frequent run-level codes get shorter bit codes.[^ff120][^ff121] | + | VLC (Variable Length Coding) is based on Huffman coding, which is a reversible compression with a fixed dictionary (code book). Words with a high probability of occurrence are assigned shorter codes. For example, (run, level) = (0, 1) occurs often and is assigned a 2-bit code, while (23, 1) occurs rarely and is assigned 14 bits.[^ff120][^ff121] |
| − | libpress has one standard code book. It is based on the run-level distribution of a typical natural image.[^ff121] | + | The best code book differs with the image source. To simplify things, libpress prepares a single standard code book that is based on the runlevel distribution of a typical natural image. Applications such as animation, whose distribution differs from natural images, would need different code books.[^ff121] |
| − | The code book is compatible with the one in MPEG. EOB (End of Block) stands for a NOP.[^ff121][^ff126] | + | Word boundaries are not significant in the coded data. Because byte ordering on the PlayStation is little endian, coded bit sequences are ordered starting with the low-order bits, and code sequences packed in this way are called bitstreams. A runlevel code that is not in the code book is coded as the escape code 000001 followed by an FLC (fixed-length code).[^ff121] |
| − | PlayStation byte order is little endian, so coded bit sequences start from the low-order bits. Word boundaries are not significant.[^ff121] | + | VLC decoding is performed in software, while MDEC decodes the run-level data in hardware. The two are therefore generally run as a pipeline to decrease processing time. In the library DecDCTvlc() performs VLC decoding, and DecDCTin() and DecDCTout() perform the DCT processing.[^ff121] |
| − | A run-level code that is not in the code book is coded as an escape code 000001 and a fixed-length code (FLC).[^ff121] | + | ### AC Code Book |
| − | VLC decoding runs in software. MDEC decodes the run-level data in hardware.[^ff121] | + | The VLC code book is compatible with the one used in MPEG. In the table below the final bit s of each code is the sign of the level. It is 0 for a positive level and 1 for a negative level. EOB is the code for a NOP (0xfe00).[^ff121][^ff126] |
| − | The library function DecDCTvlc() decodes VLC. DecDCTin() and DecDCTout() run the DCT processing.[^ff121] | + | Table: AC code book |
| − | The code book opens as follows:[^ff126] | + | | Bit pattern | Run | Level | |
| + | | --- | --- | --- | | ||
| + | | 10 | EOB (End Of Block) | | | ||
| + | | 11s | 0 | 1 | | ||
| + | | 011s | 1 | 1 | | ||
| + | | 0100s | 0 | 2 | | ||
| + | | 0101s | 2 | 1 | | ||
| + | | 00101s | 0 | 3 | | ||
| + | | 00111s | 3 | 1 | | ||
| + | | 00110s | 4 | 1 | | ||
| + | | 000110s | 1 | 2 | | ||
| + | | 000111s | 5 | 1 | | ||
| + | | 000101s | 6 | 1 | | ||
| + | | 000100s | 7 | 1 | | ||
| + | | 000001 | ESC (Escape) | | | ||
| + | | 0000110s | 0 | 4 | | ||
| + | | 0000100s | 2 | 2 | | ||
| + | | 0000111s | 8 | 1 | | ||
| + | | 0000101s | 9 | 1 | | ||
| + | | 00100110s | 0 | 5 | | ||
| + | | 00100001s | 0 | 6 | | ||
| + | | 00100101s | 1 | 3 | | ||
| + | | 00100100s | 3 | 2 | | ||
| + | | 00100111s | 10 | 1 | | ||
| + | | 00100011s | 11 | 1 | | ||
| + | | 00100010s | 12 | 1 | | ||
| + | | 00100000s | 13 | 1 | | ||
| + | | 0000001010s | 0 | 7 | | ||
| + | | 0000001100s | 1 | 4 | | ||
| + | | 0000001011s | 2 | 3 | | ||
| + | | 0000001111s | 4 | 2 | | ||
| + | | 0000001001s | 5 | 2 | | ||
| + | | 0000001110s | 14 | 1 | | ||
| + | | 0000001101s | 15 | 1 | | ||
| + | | 0000001000s | 16 | 1 | | ||
| + | | 000000011101s | 0 | 8 | | ||
| + | | 000000011000s | 0 | 9 | | ||
| + | | 000000010011s | 0 | 10 | | ||
| + | | 000000010000s | 0 | 11 | | ||
| + | | 000000011011s | 1 | 5 | | ||
| + | | 000000010100s | 2 | 4 | | ||
| + | | 000000011100s | 3 | 3 | | ||
| + | | 000000010010s | 4 | 3 | | ||
| + | | 000000011110s | 6 | 2 | | ||
| + | | 000000010101s | 7 | 2 | | ||
| + | | 000000010001s | 8 | 2 | | ||
| + | | 000000011111s | 17 | 1 | | ||
| + | | 000000011010s | 18 | 1 | | ||
| + | | 000000011001s | 19 | 1 | | ||
| + | | 000000010111s | 20 | 1 | | ||
| + | | 000000010110s | 21 | 1 | | ||
| + | | 0000000011010s | 0 | 12 | | ||
| + | | 0000000011001s | 0 | 13 | | ||
| + | | 0000000011000s | 0 | 14 | | ||
| + | | 0000000010111s | 0 | 15 | | ||
| + | | 0000000010110s | 1 | 6 | | ||
| + | | 0000000010101s | 1 | 7 | | ||
| + | | 0000000010100s | 2 | 5 | | ||
| + | | 0000000010011s | 3 | 4 | | ||
| + | | 0000000010010s | 5 | 3 | | ||
| + | | 0000000010001s | 9 | 2 | | ||
| + | | 0000000010000s | 10 | 2 | | ||
| + | | 0000000011111s | 22 | 1 | | ||
| + | | 0000000011110s | 23 | 1 | | ||
| + | | 0000000011101s | 24 | 1 | | ||
| + | | 0000000011100s | 25 | 1 | | ||
| + | | 0000000011011s | 26 | 1 | | ||
| + | | 00000000011111s | 0 | 16 | | ||
| + | | 00000000011110s | 0 | 17 | | ||
| + | | 00000000011101s | 0 | 18 | | ||
| + | | 00000000011100s | 0 | 19 | | ||
| + | | 00000000011011s | 0 | 20 | | ||
| + | | 00000000011010s | 0 | 21 | | ||
| + | | 00000000011001s | 0 | 22 | | ||
| + | | 00000000011000s | 0 | 23 | | ||
| + | | 00000000010111s | 0 | 24 | | ||
| + | | 00000000010110s | 0 | 25 | | ||
| + | | 00000000010101s | 0 | 26 | | ||
| + | | 00000000010100s | 0 | 27 | | ||
| + | | 00000000010011s | 0 | 28 | | ||
| + | | 00000000010010s | 0 | 29 | | ||
| + | | 00000000010001s | 0 | 30 | | ||
| + | | 00000000010000s | 0 | 31 | | ||
| + | | 000000000011000s | 0 | 32 | | ||
| + | | 000000000010111s | 0 | 33 | | ||
| + | | 000000000010110s | 0 | 34 | | ||
| + | | 000000000010101s | 0 | 35 | | ||
| + | | 000000000010100s | 0 | 36 | | ||
| + | | 000000000010011s | 0 | 37 | | ||
| + | | 000000000010010s | 0 | 38 | | ||
| + | | 000000000010001s | 0 | 39 | | ||
| + | | 000000000010000s | 0 | 40 | | ||
| + | | 000000000011111s | 1 | 8 | | ||
| + | | 000000000011110s | 1 | 9 | | ||
| + | | 000000000011101s | 1 | 10 | | ||
| + | | 000000000011100s | 1 | 11 | | ||
| + | | 000000000011011s | 1 | 12 | | ||
| + | | 000000000011010s | 1 | 13 | | ||
| + | | 000000000011001s | 1 | 14 | | ||
| + | | 0000000000010011s | 1 | 15 | | ||
| + | | 0000000000010010s | 1 | 16 | | ||
| + | | 0000000000010001s | 1 | 17 | | ||
| + | | 0000000000010000s | 1 | 18 | | ||
| + | | 0000000000010100s | 6 | 3 | | ||
| + | | 0000000000011010s | 11 | 2 | | ||
| + | | 0000000000011001s | 12 | 2 | | ||
| + | | 0000000000011000s | 13 | 2 | | ||
| + | | 0000000000010111s | 14 | 2 | | ||
| + | | 0000000000010110s | 15 | 2 | | ||
| + | | 0000000000010101s | 16 | 2 | | ||
| + | | 0000000000011111s | 27 | 1 | | ||
| + | | 0000000000011110s | 28 | 1 | | ||
| + | | 0000000000011101s | 29 | 1 | | ||
| + | | 0000000000011100s | 30 | 1 | | ||
| + | | 0000000000011011s | 31 | 1 | | ||
| − | Table: AC code book (first entries) | + | ### FLC Code |
| − | | Bit pattern | (run, level) | | + | ESC is followed by a fixed-length code. The run is 6 bits and runs from 000000 for 0 to 111111 for 63. Levels from -127 to 127 take 8 bits in two's complement form. Levels from -256 to -128 and from 128 to 255 take 16 bits:[^ff131] |
| − | | --- | --- | | ||
| − | | 10 | EOB | | ||
| − | | 110 | 0, +1 | | ||
| − | | 111 | 0, -1 | | ||
| − | | 0110 | 1, +1 | | ||
| − | | 0111 | 1, -1 | | ||
| − | | 01000 | 0, +2 | | ||
| − | | 01001 | 0, -2 | | ||
| − | | 01010 | 2, +1 | | ||
| − | | 01011 | 2, -1 | | ||
| − | | 000001 | ESCAPE | | ||
| − | The full code book is Table 1-7 on pages 1-26 to 1-31.[^ff126] | + | Table: Fixed Code (Level) |
| − | The FLC after an escape is a 6-bit run followed by the level. Levels from -127 to 127 take 8 bits, and larger levels take 16 bits.[^ff131] | + | | Fixed Length Code | Level | |
| + | | --- | --- | | ||
| + | | 1000 0000 0000 0001 | -256 | | ||
| + | | 1000 0000 0111 1111 | -129 | | ||
| + | | 1000 0000 1000 0000 | -128 | | ||
| + | | 1000 0001 | -127 | | ||
| + | | 1111 1111 | -1 | | ||
| + | | 0000 0001 | 1 | | ||
| + | | 0111 1111 | 127 | | ||
| + | | 0000 0000 1000 0000 | 128 | | ||
| + | | 0000 0000 1111 1111 | 255 | | ||
| ## BS Format | ## BS Format | ||
| − | BS data is RL data after VLC. It is made of bitstreams that code the header and the blocks.[^ff121] | + | RL data on which the VLC transformation has been performed is called BS data. The BS format is made up of bitstreams in which the header and the blocks are coded. All blocks in the current BS format are assumed to have the same quantization step, so QUANT is stored only once in the two-word header:[^ff121] |
| − | The header is two words. All blocks in the current BS format share one QUANT, so QUANT is stored once in the header.[^ff121] | ||
| − | |||
| − | The BS header is as follows: | ||
| − | |||
| − | |||
| Table: BS header format | Table: BS header format | ||
| Line 243: | Line 305: | ||
| | 1 | 0..15 | QUANT | Quantization step | | | 1 | 0..15 | QUANT | Quantization step | | ||
| − | A block holds a 10-bit DC element and a bitstream of the AC run-levels. Block boundaries are not always on word boundaries.[^ff121] | + | A block contains a 10-bit DC element followed by the bitstream of the AC run-levels, and block boundaries are not necessarily on word boundaries. The RL footer padding is not included in BS data, so DecDCTvlc() adds the footer automatically when it decodes. BS data also does not hold the frame size or the frame rate. These settings must be given to the program in other ways.[^ff121][^ff122] |
| − | BS data does not hold the RL footer padding. DecDCTvlc() adds the footer when it decodes.[^ff122] | ||
| − | |||
| − | BS data does not hold the frame size or the frame rate. The program must get these settings another way.[^ff122] | ||
| − | |||
| ### Decoding the DC Component | ### Decoding the DC Component | ||
| − | The first 10 bits of a block are the DC value. In the manual's example the bits 1111 0000 11 give -60.[^ff122] | + | The first 10 bits of a block are the DC value as a fixed code. In the manual's example the bits 1111 0000 11 have the MSB set, so the DC value is negative and equals -60. For a color-difference block this is the DC value as is. For a luminance block an offset of 128 is added, and the example therefore gives 68 (-60 + 128). This value is the average luminance of that 8x8 area.[^ff122][^ff123] |
| − | A luminance block adds an offset of 128 to its DC value, so the example gives 68. A color-difference block uses the DC value as is.[^ff123] | ||
| − | |||
| ### Versions | ### Versions | ||
| − | Versions 2 and 3 decode the DC component in different ways:[^ff123] | + | Versions 2 and 3 of the BS format decode the DC component in different ways:[^ff123] |
| Table: BS format versions | Table: BS format versions | ||
| Line 266: | Line 322: | ||
| | 3 | VLC (Variable Length Code) | | | 3 | VLC (Variable Length Code) | | ||
| − | Version 3 codes the difference from the DC component of the previous block.[^ff123] | + | Version 3 codes the difference from the DC component of the previous block. The bit width of the difference is VLC coded, and the coded width is followed by the difference value itself. Luminance and color-difference blocks use different tables for the width:[^ff123][^ff124] |
| − | The bit width of the difference is VLC coded. Luminance and color-difference blocks use different tables.[^ff123][^ff124] | ||
| − | |||
| − | The DC codebook is as follows: | ||
| − | |||
| − | |||
| Table: DC codebook | Table: DC codebook | ||
| Line 287: | Line 338: | ||
| | 8 | 1111110 | 11111110 | | | 8 | 1111110 | 11111110 | | ||
| − | Version 3 compresses better and takes more processing time. Version 2 suits applications whose bottleneck is CPU time.[^ff124] | + | The Huffman coding of the DC component in version 3 improves the compression ratio but increases the processing time. Version 2 should therefore be used where CPU time can be a bottleneck. In both versions the DC value 511 (0x1ff) is END_OF_FRAME.[^ff124] |
| − | In both versions the DC value 511 (0x1ff) is END_OF_FRAME.[^ff124] | ||
| − | |||
| ## Decoding Speed | ## Decoding Speed | ||
| − | MDEC decompresses up to 9000 macroblocks per second. This equals 30 frames of 320x240 images per second.[^ff124] | + | The maximum MDEC decompression speed is 9000 macroblocks per second, which equals 30 frames of 320x240 images per second. The speed does not depend on the compression ratio, so the playback frame rate is in inverse proportion to the resolution:[^ff124] |
| − | The speed does not depend on the compression ratio:[^ff124] | ||
| − | |||
| Table: Decompression speed | Table: Decompression speed | ||
| Line 303: | Line 350: | ||
| | Frames/second | 60 | 30 | 15 | 7.5 | | | Frames/second | 60 | 30 | 15 | 7.5 | | ||
| − | The CPU runs VLC decoding in the background. Other heavy CPU work can make VLC decoding the bottleneck.[^ff124] | + | In practice the CPU performs the VLC decoding in the background, and other heavy CPU work can make it the bottleneck. The CD-ROM transfers 150 KB/sec at standard speed and 300 KB/sec at double speed. At double speed, 30 frames per second therefore needs a bitstream of 10 KB or less per frame (300 KB / 30):[^ff124] |
| − | The CD-ROM reads at 150 KB/sec (standard speed) or 300 KB/sec (double speed). At double speed, 30 frames per second needs 10 KB or less per frame.[^ff124] | ||
| − | |||
| − | The frame rate depends on the data size: | ||
| − | |||
| − | |||
| Table: Transfer speed at double speed | Table: Transfer speed at double speed | ||
| Line 318: | Line 360: | ||
| ## Image Quality | ## Image Quality | ||
| − | Image sources must be at least 24-bit images. Noise at the input stage is the largest factor in playback quality.[^ff125] | + | Noise at the image input stage is the biggest factor in the quality of playback, so image sources must be at least 24-bit images. Block noise in 16x16 pixel units comes from the Cb and Cr blocks, and it is conspicuous when the coded noise changes between frames.[^ff125] |
| − | Block noise in 16x16 pixel units comes from the Cb and Cr blocks.[^ff125] | + | Such changes occur when the quantization step varies between adjacent frames. When BS data is interleaved with audio sectors, the data size of each frame varies and the quantization step varies with it. Sources with many static areas, such as animation backgrounds, must consequently be encoded with fixed sectors.[^ff125] |
| − | Interleaving with audio sectors varies the data size of each frame. The quantization step varies with it and shows as noise.[^ff125] | + | Playback in 24-bit mode generally gives better results than playback in 16-bit mode. This is because a standard encoder truncates the low-order bits when going from 24 to 16 bits.[^ff126] |
| − | Sources with many static areas, such as animation backgrounds, must be encoded with fixed sectors.[^ff125] | ||
| − | |||
| − | Playback in 24-bit mode gives better results than 16-bit mode. A standard encoder truncates the low-order bits from 24 to 16 bits.[^ff126] | ||
| − | |||
| ## References | ## References | ||
| Line 345: | Line 383: | ||
| [^ff124]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-24, Tables 1-4 to 1-6. | [^ff124]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-24, Tables 1-4 to 1-6. | ||
| [^ff125]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-25. | [^ff125]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-25. | ||
| − | [^ff126]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-26, Table 1-7. | + | [^ff126]: Sony Computer Entertainment Inc. File Formats. November 1998. Pages 1-26 to 1-30, Table 1-7. |
| [^ff131]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-31, Tables 1-8 and 1-9. | [^ff131]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-31, Tables 1-8 and 1-9. | ||