BS (MDEC Bitstream Data)

Compressed image data that MDEC and libpress decode.

BS (MDEC Bitstream Data)
Extension	.BS
MAGIC	0x3800
Encoder	MOVCONV

This is an old revision of this page, as edited by RemmyLee at 02:27, 23 October 2026. Edit this revision | Latest revision

Overview

BS is the image data format used by MDEC and libpress.¹

Original MDEC image data is a series of 24-bit RGB images over time. Each image is called a frame.¹

A frame is a multiple of 16 pixels wide and a multiple of 16 pixels tall. Other sizes need additional processing.¹²

MDEC does not use correlations between frames. Each frame can be processed on its own.¹

Macroblocks

MDEC treats each frame as a collection of 16x16 pixel regions. These regions are called macroblocks.¹

MDEC writes the decoded results to main memory as macroblocks. The CPU and the GPU rebuild the frame from them.¹

The encoder orders macroblocks vertically from the top left. This reduces the number of LoadImage frame buffer transfers.²

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).³

MDEC converts YCbCr to RGB with the following matrix:³

Table 1: 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.³

The inverse matrix is as follows:

Table 2: 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.³

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.⁴

A 16x16 macroblock becomes two color-difference blocks and four luminance blocks. Each 8x8 unit is called a block.⁴

The blocks are in this order:

Table 3: 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.⁴

Block Offset

In 8-bit YCbCr, Y ranges from 0 to 255. Cb and Cr range from -128 to +127.⁵

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.⁵

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.⁵

IDCT is DCT with P replaced by its transpose.⁵

Element (0,0) of the result is the DC element. It equals the average of the block, and the other elements are AC elements.⁶

Frequency rises to the right and down in the matrix. Natural images give small values toward the bottom right, and DCT compression uses this.⁶

Quantization

Each element is divided by its quantization table entry times QUANT. QUANT sets the quantization step for the whole block.⁶

The DC element is not affected by QUANT. MDEC uses the same quantization table for luminance and color-difference blocks.⁶

The quantization table is as follows:

Table 4: 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.⁷

Zig-zag Transformation

The quantized block is numbered in zig-zag order. The order starts from the lowest frequency elements.⁷

The scan order is as follows:

Table 5: 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).⁸

Run is the number of zeros before a non-zero coefficient. Level is the value of that coefficient.⁸

A runlevel code has 16 bits:

Table 6: 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.⁸

Two runlevel codes are packed in each 32-bit word.⁸

NOP

(run, level) = (63, 128) = 0xfe00 is a NOP. It ends a block, and the remaining elements of the block are 0.⁹

A NOP between blocks is skipped. A second NOP in a row is also skipped.⁹

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.⁹

The blocks are in the order Cb, Cr, Y0, Y1, Y2, Y3. The number of blocks must be a multiple of 6.⁹

The header word is as follows:

Table 7: 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.⁹

The RL data syntax on page 1-20 lists QUANT and RUN as 5 bits. Figures 12 and 13 give them as 6 bits.⁸¹⁰

VLC

VLC (Variable Length Coding) is Huffman coding with a fixed code book. Frequent run-level codes get shorter bit codes.¹⁰¹¹

libpress has one standard code book. It is based on the run-level distribution of a typical natural image.¹¹

The code book is compatible with the one in MPEG. EOB (End of Block) stands for a NOP.¹¹¹²

PlayStation byte order is little endian, so coded bit sequences start from the low-order bits. Word boundaries are not significant.¹¹

A run-level code that is not in the code book is coded as an escape code 000001 and a fixed-length code (FLC).¹¹

VLC decoding runs in software. MDEC decodes the run-level data in hardware.¹¹

The library function DecDCTvlc() decodes VLC. DecDCTin() and DecDCTout() run the DCT processing.¹¹

The code book opens as follows:¹²

Table 8: 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.¹²

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.¹³

BS Format

BS data is RL data after VLC. It is made of bitstreams that code the header and the blocks.¹¹

The header is two words. All blocks in the current BS format share one QUANT, so QUANT is stored once in the header.¹¹

The BS header is as follows:

Table 9: 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.¹¹

BS data does not hold the RL footer padding. DecDCTvlc() adds the footer when it decodes.¹⁴

BS data does not hold the frame size or the frame rate. The program must get these settings another way.¹⁴

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.¹⁴

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.¹⁵

Versions

Versions 2 and 3 decode the DC component in different ways:¹⁵

Table 10: 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. Luminance and color-difference blocks use different tables.¹⁵¹⁶

The DC codebook is as follows:

Table 11: 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.¹⁶

In both versions the DC value 511 (0x1ff) is END_OF_FRAME.¹⁶

Decoding Speed

MDEC decompresses up to 9000 macroblocks per second. This equals 30 frames of 320x240 images per second.¹⁶

The speed does not depend on the compression ratio:¹⁶

Table 12: 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.¹⁶

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.¹⁶

The frame rate depends on the data size:

Table 13: 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.¹⁷

Block noise in 16x16 pixel units comes from the Cb and Cr blocks.¹⁷

Interleaving with audio sectors varies the data size of each frame. The quantization step varies with it and shows as noise.¹⁷

Sources with many static areas, such as animation backgrounds, must be encoded with fixed sectors.¹⁷

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.¹²

References

^ ^a ^b ^c ^d ^e ^f Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-8.
^ ^a ^b Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-9, Figure 10.
^ ^a ^b ^c ^d Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-10.
^ ^a ^b ^c Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-11, Figure 11.
^ ^a ^b ^c ^d Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-12.
^ ^a ^b ^c ^d Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-13.
^ ^a ^b Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-14.
^ ^a ^b ^c ^d ^e Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-18, Figures 12 to 14.
^ ^a ^b ^c ^d ^e Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-19, Figure 15.
^ ^a ^b Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-20.
^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-21, Figure 16.
^ ^a ^b ^c ^d Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-26, Table 1-7.
^ Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-31, Tables 1-8 and 1-9.
^ ^a ^b ^c Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-22, Figure 17.
^ ^a ^b ^c ^d Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-23, Table 1-3.
^ ^a ^b ^c ^d ^e ^f ^g Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-24, Tables 1-4 to 1-6.
^ ^a ^b ^c ^d Sony Computer Entertainment Inc. File Formats. November 1998. Page 1-25.

Categories: File formats

	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

	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

	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