psx.wiki
Log in
Main page
Hardware
Hardware tests
System software
SDKs
File formats
Games
Tools
History
All pages
page
view source
history
View source for BS (MDEC Bitstream Data)
← BS (MDEC Bitstream Data)
You do not have permission to edit this page.
Log in
to edit.
--- title: BS (MDEC Bitstream Data) type: format summary: Compressed image data that MDEC and libpress decode. category: File formats info: Extension = .BS info: MAGIC = 0x3800 info: Encoder = MOVCONV --- ## Overview 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] ## Macroblocks 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] 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] ### Color Space Conversion 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] Table: YCbCr to RGB conversion | Output | Y | Cb | Cr | | --- | --- | --- | --- | | R | 1.0 | 0 | 1.402 | | G | 1.0 | -0.3437 | -0.7143 | | B | 1.0 | 1.772 | 0 | The inverse of this matrix is used to convert from RGB to YCbCr, and the MOVCONV encoder uses it:[^ff110] Table: RGB to YCbCr conversion | Output | R | G | B | | --- | --- | --- | --- | | Y | 0.299 | 0.587 | 0.114 | | Cb | -0.16871 | -0.33130 | 0.5 | | Cr | 0.5 | -0.4187 | -0.0813 | 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 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] Table: Macroblock arrangement | Order | Block | Kind | | --- | --- | --- | | 1 | Cb | Color difference | | 2 | Cr | Color difference | | 3 | Y0 | Luminance | | 4 | Y1 | Luminance | | 5 | Y2 | Luminance | | 6 | Y3 | Luminance | 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 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] ## Encoding ### DCT 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] 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] ### Quantization 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] Table: MDEC quantization table (x 1/16) | | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 0 | 2 | 16 | 19 | 22 | 26 | 27 | 29 | 34 | | 1 | 16 | 16 | 22 | 24 | 27 | 29 | 34 | 37 | | 2 | 19 | 22 | 26 | 27 | 29 | 34 | 34 | 38 | | 3 | 22 | 22 | 26 | 27 | 29 | 34 | 37 | 40 | | 4 | 22 | 26 | 27 | 29 | 32 | 35 | 40 | 48 | | 5 | 26 | 27 | 29 | 32 | 35 | 40 | 48 | 58 | | 6 | 26 | 27 | 29 | 34 | 38 | 46 | 56 | 69 | | 7 | 27 | 29 | 35 | 38 | 46 | 56 | 69 | 83 | 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 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] Table: Zig-zag scan order (zscan) | Positions | Elements | | --- | --- | | 0..7 | 0, 1, 8, 16, 9, 2, 3, 10 | | 8..15 | 17, 24, 32, 25, 18, 11, 4, 5 | | 16..23 | 12, 19, 26, 33, 40, 48, 41, 34 | | 24..31 | 27, 20, 13, 6, 7, 14, 21, 28 | | 32..39 | 35, 42, 49, 56, 57, 50, 43, 36 | | 40..47 | 29, 22, 15, 23, 30, 37, 44, 51 | | 48..55 | 58, 59, 52, 45, 38, 31, 39, 46 | | 56..63 | 53, 60, 61, 54, 47, 55, 62, 63 | ## Run-level Data ### Runlevel Code 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] Table: Runlevel code format | Bits | Field | Contents | | --- | --- | --- | | 10..15 | RUN | Number of zeros before a non-zero coefficient (unsigned, 6 bits) | | 0..9 | LEVEL | The non-zero coefficient (signed, 10 bits) | 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] ### NOP 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] ### RL Data 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] Table: RL header word | Bits | Field | Contents | | --- | --- | --- | | 16..31 | MAGIC | Magic number, constant 0x3800 | | 0..15 | SIZE | Data size in words, not including the header | 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 on page 1-18 give them as 6 bits.[^ff118][^ff120] ## VLC 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] 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] 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] 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] ### AC Code Book 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] Table: AC code book | 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 | ### FLC Code 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] Table: Fixed Code (Level) | 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 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] Table: BS header format | Word | Bits | Field | Contents | | --- | --- | --- | --- | | 0 | 16..31 | MAGIC | Magic number, constant 0x3800 | | 0 | 0..15 | RLSIZE | Data size of the run-level data in words, not including the header | | 1 | 16..31 | VER | Version number | | 1 | 0..15 | QUANT | Quantization step | 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] ### Decoding the DC Component 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] ### Versions Versions 2 and 3 of the BS format decode the DC component in different ways:[^ff123] Table: BS format versions | Version | Block DC component | | --- | --- | | 2 | FLC (Fixed Length Code) | | 3 | VLC (Variable Length Code) | 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] Table: DC codebook | Differential value bit width | Luminance block | Color difference block | | --- | --- | --- | | 0 | 100 | 00 | | 1 | 00 | 01 | | 2 | 01 | 10 | | 3 | 101 | 110 | | 4 | 110 | 1110 | | 5 | 1110 | 11110 | | 6 | 11110 | 111110 | | 7 | 111110 | 1111110 | | 8 | 1111110 | 11111110 | 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] ## Decoding Speed 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] Table: Decompression speed | Resolution | 160x240 | 320x240 | 640x240 | 640x480 | | --- | --- | --- | --- | --- | | Frames/second | 60 | 30 | 15 | 7.5 | 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] Table: Transfer speed at double speed | Data size | 5KB | 10KB | 20KB | 40KB | | --- | --- | --- | --- | --- | | Frames/second | 60 | 30 | 15 | 7.5 | ## Image Quality 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] 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] 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] ## References [^ff18]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-8. [^ff19]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-9, Figure 10. [^ff110]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-10. [^ff111]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-11, Figure 11. [^ff112]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-12. [^ff113]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-13. [^ff114]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-14. [^ff118]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-18, Figures 12 to 14. [^ff119]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-19, Figure 15. [^ff120]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-20. [^ff121]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-21, Figure 16. [^ff122]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-22, Figure 17. [^ff123]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-23, Table 1-3. [^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. [^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.