Indeo 5

From MultimediaWiki
Jump to navigation Jump to search

Introduction

Indeo5 is the latest version of Indeo Video Interactive(IVI). For an introduction to this compression algorithm see Indeo Video Interactive.

Indeo Video Interactive Version 5 (Indeo5)

For a description of the coding techniques see Brief description of the coding techniques.

For a description of the interactive features see Brief description of the interactive features.

Indeo5 algorithm is mostly the same as indeo4 with the following differences:

- indeo5 uses another bitstream format that allows to store compressed frames more compactly.

- indeo5 utilizes only the Slant transform. The Haar transform used in indeo4 was dropped due to its low quality.

- indeo5 uses another wavelet decomposition/recomposition filter instead of the haar wavelet used in indeo4 in order to provide a better quality for the scalability mode.

- bidirectional frames mode seems to be dropped. Actually there is no indeo5 encoder supports its creating. Mac and Xanim decoders contain no code for handling of this kind of frames.

- indeo5 performs a partially encryption of the bitstream if a numeric password ("access key") was specified during encoding.

Decoder specification

Indeo5 has the same picture layout and bitstream organization as indeo4. A detailed description can be found here Indeo4 picture layout.

Picture header

Picture header of indeo5 consists of three parts: 

Picture_start_code, frame_type, frame_number
[GOP header]
Frame header

The first two bytes of a frame tell the decoder how the following data should be interpreted. These include three fields:

size in bits name value comments
5 PSC always = 0x1F indeo5 picture start code
3 frame_type
  • 0 => INTRA (key) frame
  • 1 => INTER frame
  • 2 => unused
  • 3 => INTER frame
  • 4 => NULL frame
  • 5...7 are illegal
 frame type
8 frame_number 0...0xFF frame number in GOP (0 for I frame)

Null frames don't contain anything else than this header.

GOP header

This header is present in INTRA (key) frames only. It's used for transfering of some general information (i.e. picture layout) that will be either rarely or never changed during a video sequence. The values in this header are valid for all frames in the GOP.

size in bits name condition value(s) comments
8 gop_flags
  • bit 0 => 1 - gop_hdr_size field is present
  • bit 1 => subsampling format: 0 - YVU9, 1 - YV12
  • bit 2 => unknown meaning
  • bit 3 => transparency status?
  • bit 4 =>
  • bit 5 => access key protection: 1 - enabled
  • bit 6 => local decoding: 1 - enabled
  • bit 7 =>
 GOP header flags
16 gop_hdr_size gop_flags & 0x01 Size of this header in bytes. Only present in the bitstream if indicated by the gop_flags bit 0.
32 lock_word gop_flags & 0x20

Only present in the bitstream if "access key protection" is active (as indicated by the bit 5 of the gop_flags). For a description of how to use this field see Access key protection.

2 slice_size_id gop_flags & 0x40
  • 0 => 64 x 64
  • 1 => 128 x 128
  • 2 => 256 x 256
  • 3 => unused
 ID of slice size. Only present if "local decoding mode" is enabled (indicated by the bit 6 of the gop_flags).
2 luma_bands_id
  • 0 => 1 band
  • 1 => 4 bands
  • 2 and 3 are forbidden
 number of wavelet bands the luma plane subdivided into.
3 value4 legal values are 0, 1, 2 and 6
4 res_id see Resolution table
13 height res_id == 15 frame height
13 width frame width
6 value5 2*n (n == 1 always?)
2 value6 value5 >> 3 need to be = 0
4 value7 gh_flags & 0x08
24 value8
?? alignment1 align bits reader on next byte
24 value9
16 value10 value9 & 0x800000

Conventions

Headers are described in some tables. Each row of those tables describes a value which may be read from the frame. Those tables and rows are presented in the order of appearance in the frame.

Here are the meaning of each columns:

  • size: The size of this value in bits. Bits are counted in LSB to MSB order. As an example, with the byte 01110000b, reading 3 bits then 5 bits will return 000b then 01110b. Reading more than 8 bits thus reads as a little-endian value. Think of the get_bits function as filling up the return value from its LSB, using the bits from each byte starting from their LSB.
  • name: Kind of variable name, used to reference the value. When a value is named valueX, it generally means we don't know it's purpose. Lines named alignmentX means that bits reader need to skip bits until next byte boundary.
  • condition: The value is present in the frame only if this condition is matched. No condition means that the value is always present.
  • nb times: How many times the value is repeated.
  • comments: Some details about the content of the value. It may also explain that a value is repeated until a certain condition is reached.

Headers

GOP header

This header is present in I frames only. The values in this header are valid during the whole GOP starting at this frame.

size name condition nb times comments
8 gh_flags gh_flags & 0x02 => YV12 (default YVU9)
16 value1 gh_flags & 0x01 discard in decoding
32 value2 gh_flags & 0x20
2 value3 gh_flags & 0x40
3 value4 legal values are 0, 1, 2 and 6
4 res_id see Resolution table
13 height res_id == 15 frame height
13 width frame width
6 value5 2*n (n == 1 always?)
2 value6 value5 >> 3 need to be = 0
4 value7 gh_flags & 0x08
24 value8
?? alignment1 align bits reader on next byte
24 value9
16 value10 value9 & 0x800000 loops while value10 & 0x8000 (probably some kind of VLC ?)

More header

This header is present in all kinds of frame except null.

size name condition nb times comments
8 mh_flags
24 frame_size mh_flags & 0x01 tolal size of frame data
16 value11 mh_flags & 0x10
8 counter1 mh_flags & 0x20 this whole block loops while counter1 != 0
8 value12 counter1
3 value13 mh_flags & 0x40
4 counter2 value13 == 7
4 value14 counter2
3 value15
?? alignment2 align bits reader on next byte

Plane header

This header is present at the beginning of every plane.

size name condition nb times comments
8 ph_flags
24 plan_size mh_flags & 0x80 tolal size of plan data
8 counter3 ph_flags & 0x10 must be < 0x3E
8 value16 counter3
8 value17
3 value18 ph_flags & 0x40
3 table1_id ph_flags & 0x80 see Table 1
4 counter4 table1_id == 7 used instead of Table1
4 value19 counter4
1 value20
16 value21 value20
5 value22
?? alignment3 align bits reader on next byte
8 counter5 ph_flags & 0x20 all of this is repeated as long as value23 is true
8 skip1 counter5
1 value23
?? alignment4 align bits reader on next byte


Planes

Plane data

Needs more analysis. Follows plane header.

size name condition nb times comments
1 value24
1 value25 ! value24 plan_data_size = value25
8 value26 value25 == 1 plan_data_size = value26
24 value27 value26 == 0xFF plan_data_size = value27

Block header

Each plane is split into a number of blocks in the x and y directions. There is one of these headers one after another for each block in the plane.

size name condition nb times comments
1 value28
vlc value29 value28 && plane_state17
1 value30 !value28 && plane_state12 && plane_state1
4 value31 !value28 && four_blocks
1 value32 !value28 && !four_blocks
vlc value33 !value28 && plane_state14 && !plane_state13 && (plane_state17 || value31/2)
vlc value34 !value28 && !(block_state4 & 2) && !plane_state12
vlc value35

The 'plane_state' states come from plane parsing; they are yet to be connected to the previous data.

block_state4 is too complicated to explain here, sorry!

Block data

Follows block header. One of these for each plane that has 'plane_flags&1'. The variable 'run' starts at -1 and carries over from one coded plane to the next. I don't really know what I'm doing with vlc's so the names might not be correct... but their functional description is.

size name condition nb times comments
vlc vlc while (vlc != vlcEnd)
vlc run_add vlc == vlcEsc run += run_add + 1
vlc lindex_lo lindex = lindex_lo | (lindex_hi<<6)
vlc lindex_hi


If vlc != vlcEsc then run_add is run_table[vlc], lindex is lindex_table[vlc].

After each loop, stored coefficient is: block[ scan_table[run] ] = level_tables[run][lindex-1].

The values of vlcEnd and vlcEsc are variable, as is the vlc table itself. However, they are all fixed for all the planes in the same block. run_table, lindex_table, scan_table are also fixed-per-block. level_tables is per-plane.

Annexes

Resolution table

res_id 0 1 2 3 4 5 6 7 8 9 10 11
width 640 320 160 704 352 352 176 240 640 704 80 88
height 480 240 120 224 240 288 144 180 240 240 60 72

Table 1

table1_id 0 1 2 3 4 5 6 default
counter4 10 11 12 13 11 13 13 9
value19
1
2
3
4
4
7
5
5
4
1
2
3
4
4
4
7
5
4
3
3
2
2
4
5
5
5
5
6
4
4
3
1
1
3
3
4
4
5
6
6
4
4
3
2
1
1
3
4
4
5
5
5
6
5
4
2
2
3
4
5
5
5
5
6
4
3
3
2
1
1
3
4
5
5
5
6
5
4
3
3
2
1
1
3
4
4
5
5
5
6
5
5

default is used when !(ph_flags & 0x80)

Retrieved from "https://wiki.multimedia.cx/index.php?title=Indeo_5&oldid=11623"