BS (MDEC Bitstream Data): Difference between revisions

Revision as of 02:22, 23 October 2026 RemmyLee (Hardware and system software pages from the Sony manuals)	Revision as of 02:27, 23 October 2026 RemmyLee (File format pages from the Sony File Formats manual)
Line 1:	Line 1:
	+	---
	+	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.[^ff18]
	+
	+	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
	+
	+	MDEC treats each frame as a collection of 16x16 pixel regions. These regions are called macroblocks.[^ff18]
	+
	+	MDEC writes the decoded results to main memory as macroblocks. The CPU and the GPU rebuild the frame from them.[^ff18]
	+
	+	The encoder orders macroblocks vertically from the top left. This reduces the number of LoadImage frame buffer transfers.[^ff19]
	+
	+	### 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 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 MOVCONV encoder converts RGB to YCbCr with the inverse matrix.[^ff110]
	+
	+	The inverse matrix is as follows:
	+
	+
	+	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 \|
	+
	+	Y is the luminance signal. Cb and Cr are the color-difference signals.[^ff110]
	+
	+	### 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]
	+
	+	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
	+
	+	\| Order \| Block \| Kind \|
	+	\| --- \| --- \| --- \|
	+	\| 1 \| Cb \| Color difference \|
	+	\| 2 \| Cr \| Color difference \|
	+	\| 3 \| Y0 \| Luminance \|
	+	\| 4 \| Y1 \| Luminance \|
	+	\| 5 \| Y2 \| 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]
	+
	+	### Block Offset
	+
	+	In 8-bit YCbCr, Y ranges from 0 to 255. Cb and Cr range from -128 to +127.[^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
	+
	+	### 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]
	+
	+	IDCT is DCT with P replaced by its transpose.[^ff112]
	+
	+	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
	+
	+	Each element is divided by its quantization table entry times QUANT. QUANT sets the quantization step for the whole block.[^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)
	+
	+	\| \| 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 \|
	+
	+	A larger QUANT loses more data and lowers image quality. It also gives more zero elements and smaller run-level data.[^ff114]
	+
	+	### Zig-zag Transformation
	+
	+	The quantized block is numbered in zig-zag order. The order starts from the lowest frequency elements.[^ff114]
	+
	+	The scan order is as follows:
	+
	+
	+	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
	+
	+	Run-level conversion compresses the runs of zeros in a zig-zag ordered block. Each code is a pair (run, level).[^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
	+
	+	\| 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. Its run field holds QUANT, and its level field holds the DC coefficient.[^ff118]
	+
	+	Two runlevel codes are packed in each 32-bit word.[^ff118]
	+
	+	### NOP
	+
	+	(run, level) = (63, 128) = 0xfe00 is a NOP. It ends a block, and the remaining elements of the block are 0.[^ff119]
	+
	+	A NOP between blocks is skipped. A second NOP in a row is also skipped.[^ff119]
	+
	+	### 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]
	+
	+	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
	+
	+	\| 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. A footer of NOPs pads the data to that 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]
	+
	+	## VLC
	+
	+	VLC (Variable Length Coding) is Huffman coding with a fixed code book. Frequent run-level codes get shorter bit codes.[^ff120][^ff121]
	+
	+	libpress has one standard code book. It is based on the run-level distribution of a typical natural image.[^ff121]
	+
	+	The code book is compatible with the one in MPEG. EOB (End of Block) stands for a NOP.[^ff121][^ff126]
	+
	+	PlayStation byte order is little endian, so coded bit sequences start from the low-order bits. Word boundaries are not significant.[^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]
	+
	+	VLC decoding runs in software. MDEC decodes the run-level data in hardware.[^ff121]
	+
	+	The library function DecDCTvlc() decodes VLC. DecDCTin() and DecDCTout() run the DCT processing.[^ff121]
	+
	+	The code book opens as follows:[^ff126]
	+
	+	Table: AC code book (first entries)
	+
	+	\| Bit pattern \| (run, level) \|
	+	\| --- \| --- \|
	+	\| 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]
	+
	+	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]
	+
	+	## BS Format
	+
	+	BS data is RL data after VLC. It is made of bitstreams that code the header and the blocks.[^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
	+
	+	\| 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 holds a 10-bit DC element and a bitstream of the AC run-levels. Block boundaries are not always on word boundaries.[^ff121]
	+
	+	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
	+
	+	The first 10 bits of a block are the DC value. In the manual's example the bits 1111 0000 11 give -60.[^ff122]
	+
	+	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 2 and 3 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.[^ff123]
	+
	+	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
	+
	+	\| 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 \|
	+
	+	Version 3 compresses better and takes more processing time. Version 2 suits applications whose bottleneck is CPU time.[^ff124]
	+
	+	In both versions the DC value 511 (0x1ff) is END_OF_FRAME.[^ff124]
	+
	+	## Decoding Speed
	+
	+	MDEC decompresses up to 9000 macroblocks per second. This equals 30 frames of 320x240 images per second.[^ff124]
	+
	+	The speed does not depend on the compression ratio:[^ff124]
	+
	+	Table: Decompression speed
	+
	+	\| Resolution \| 160x240 \| 320x240 \| 640x240 \| 640x480 \|
	+	\| --- \| --- \| --- \| --- \| --- \|
	+	\| 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]
	+
	+	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
	+
	+	\| Data size \| 5KB \| 10KB \| 20KB \| 40KB \|
	+	\| --- \| --- \| --- \| --- \| --- \|
	+	\| Frames/second \| 60 \| 30 \| 15 \| 7.5 \|
	+
	+	## Image Quality
	+
	+	Image sources must be at least 24-bit images. Noise at the input stage is the largest factor in playback quality.[^ff125]
	+
	+	Block noise in 16x16 pixel units comes from the Cb and Cr blocks.[^ff125]
	+
	+	Interleaving with audio sectors varies the data size of each frame. The quantization step varies with it and shows as noise.[^ff125]
	+
	+	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
	+
	+	[^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. Page 1-26, Table 1-7.
	+	[^ff131]: Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-31, Tables 1-8 and 1-9.

Recent changes · Upload file · Special pages