Indeo 3 - Revision history

Trixter: /* Introduction */

2011-06-21T17:49:27Z

Introduction

← Older revision		Revision as of 10:49, 21 June 2011
Line 8:		Line 8:

	Indeo Video 3 is a proprietary video compression algorithm developed by [[Intel]]. It is primarily used to encode video in		Indeo Video 3 is a proprietary video compression algorithm developed by [[Intel]]. It is primarily used to encode video in
	AVI files. The format was seen commonly since 1992 ~~around~~ the release of Windows 3.1 and was superseded by Indeo Video Interactive version 4 and 5 (see [[Indeo 4]] and [[Indeo 5]]).		AVI files. The format was seen commonly since 1992 after the release of Windows 3.1 and was superseded by Indeo Video Interactive version 4 and 5 (see [[Indeo 4]] and [[Indeo 5]]).

	There are several versions of this codec (R3.1, R3.2) but the version R3.2 (FOURCC 'IV32') is the most common. There is a support for this codec for all major platforms (Windows, Macintosh, Linux).		There are several versions of this codec (R3.1, R3.2) but the version R3.2 (FOURCC 'IV32') is the most common. There is a support for this codec for all major platforms (Windows, Macintosh, Linux).

Trixter: /* Introduction */

2011-06-21T17:48:52Z

Introduction

← Older revision		Revision as of 10:48, 21 June 2011
Line 8:		Line 8:

	Indeo Video 3 is a proprietary video compression algorithm developed by [[Intel]]. It is primarily used to encode video in		Indeo Video 3 is a proprietary video compression algorithm developed by [[Intel]]. It is primarily used to encode video in
	AVI files. The format was commonly ~~seen~~ around the ~~time~~ of ~~1996~~ and ~~has since been~~ superseded by Indeo Video Interactive version 4		AVI files. The format was seen commonly since 1992 around the release of Windows 3.1 and was superseded by Indeo Video Interactive version 4 and 5 (see [[Indeo 4]] and [[Indeo 5]]).
	and 5 (see [[Indeo 4]] and [[Indeo 5]]). There are several versions of this codec (R3.1, R3.2) but the version R3.2 (FOURCC 'IV32') is the most common. There is a support for this codec for all major platforms (Windows, Macintosh, Linux).
			There are several versions of this codec (R3.1, R3.2) but the version R3.2 (FOURCC 'IV32') is the most common. There is a support for this codec for all major platforms (Windows, Macintosh, Linux).

	This document focuses on principles necessary to implement an Indeo Video 3 decoder.		This document focuses on principles necessary to implement an Indeo Video 3 decoder.

Maxpol: /* Run-length codes */

2009-07-23T23:18:32Z

Run-length codes

← Older revision		Revision as of 16:18, 23 July 2009
Line 252:		Line 252:
	\| align="center" \| RLE_ESC_FC \|\| 0xFC \|\| apply null delta to all remaining lines of this block and to whole next block \|\| all		\| align="center" \| RLE_ESC_FC \|\| 0xFC \|\| apply null delta to all remaining lines of this block and to whole next block \|\| all
	\|-		\|-
	\| align="center" \| RLE_ESC_FB \|\| 0xFB, counter \|\| apply null delta to n blocks/skip n blocks. The "counter" ~~value~~ should be interpreted as follows:		\| align="center" \| RLE_ESC_FB \|\| 0xFB, counter \|\| apply null delta to n blocks/skip n blocks. The "counter" is a byte and should be interpreted as follows:
	* bits 0...4 => number of blocks to process		* bits 0...4 => number of blocks to process
	* bit 5 => 0 - copy blocks, 1 - mark blocks as skipped		* bit 5 => 0 - copy blocks, 1 - mark blocks as skipped
			* bits 6 and 7 are unused and should be set to "0"
	\|\| all		\|\| all
	\|-		\|-

Maxpol: /* Software vector operations */

2009-07-23T23:16:16Z

Software vector operations

← Older revision		Revision as of 16:16, 23 July 2009
Line 52:		Line 52:
	dst_pixels = src_pixels + delta; // dst_pixels contains 0x1E232221 now		dst_pixels = src_pixels + delta; // dst_pixels contains 0x1E232221 now

	Example 3: ~~averaging~~ four pixels at once		Example 3: Averaging four pixels at once

	dst_pixels = ((src_pixels1 + src_pixels2) >> 1) & 0x7F7F7F7F;		dst_pixels = ((src_pixels1 + src_pixels2) >> 1) & 0x7F7F7F7F;


	=== Internal picture representation ===		=== Internal picture representation ===

Maxpol: /* Run-length codes */

2009-07-23T23:08:00Z

Run-length codes

← Older revision		Revision as of 16:08, 23 July 2009
Line 270:		Line 270:
	\| align="center" \| RLE_ESC_F8 \|\| 0xF8 \|\| seems to be never used \|\|		\| align="center" \| RLE_ESC_F8 \|\| 0xF8 \|\| seems to be never used \|\|
	\|}		\|}


	Depends on coding mode, block size and block type there are some variations in the processing of this codes. For a detailed description see the explanation of the VQ coding modes below.		Depends on coding mode, block size and block type there are some variations in the processing of this codes. For a detailed description see the explanation of the VQ coding modes below.

Maxpol: /* Run-length codes */

2009-07-23T23:07:31Z

Run-length codes

← Older revision		Revision as of 16:07, 23 July 2009
Line 239:		Line 239:
	===== Run-length codes =====		===== Run-length codes =====

	Values 0xF8...0xFF of the VQ data codes are reserved for the special run-length codes. Their meaning is described in the table below:		Values 0xF8...0xFF of the VQ data codes are reserved for the special run-length codes. Their generalized meaning is described in the table below:

	{\| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"		{\| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
Line 257:		Line 257:
	* bit 5 => 0 - copy blocks, 1 - mark blocks as skipped		* bit 5 => 0 - copy blocks, 1 - mark blocks as skipped
	\|\| all		\|\| all
			\|-
			\| align="center" \| RLE_ESC_FA \|\| 0xFA \|\|
			* INTRA: mark this block as skipped
			* INTER: copy data from the corresponding reference block
			\|\| 0
			\|-
			\| align="center" \| RLE_ESC_F9 \|\| 0xF9 \|\|
			* INTRA: mark this block and the next one as skipped
			* INTER: copy data from the corresponding two reference blocks
			\|\| 0
			\|-
			\| align="center" \| RLE_ESC_F8 \|\| 0xF8 \|\| seems to be never used \|\|
	\|}		\|}

			Depends on coding mode, block size and block type there are some variations in the processing of this codes. For a detailed description see the explanation of the VQ coding modes below.

	== Pseudocode examples ==		== Pseudocode examples ==

Maxpol: /* VQ data codes */

2009-07-23T22:59:26Z

VQ data codes

@@ Line 235: / Line 235: @@
   code 0, type = DYAD for the dyad 0, line 0
   code 1, type = QUAD --------> ERROR!!!
 == Pseudocode examples ==

Maxpol: /* Plane data */

2009-07-23T22:41:28Z

Plane data

← Older revision		Revision as of 15:41, 23 July 2009
Line 187:		Line 187:

	The C-pseudocode example [[#Parsing binary tree codes\|here]] shows how to parse the binary tree segmentation properly.		The C-pseudocode example [[#Parsing binary tree codes\|here]] shows how to parse the binary tree segmentation properly.

			==== VQ data codes ====

			The VQ data for each cell contains one-byte VQ codes of the following three types:

			* '''DYAD''': this indicates a two-byte delta applied to two pixels at once.
			* '''QUAD''': this indicates a four-byte delta applied to four pixels at once.
			* '''RLE_ESC''': one of the special run-length codes (see below).

			Each 4x4 block is coded using 8 dyads. The following table shows the order of dyads and their pixels in a block:

			{\| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
			\|- bgcolor="#f0f0f0" \|
			! line !! pixels of the dyad 1 !! pixels of the dyad 0
			\|-
			\| align="center" \| 0 \|\| 3, 2 \|\| 1, 0
			\|-
			\| align="center" \| 1 \|\| 7, 6 \|\| 5, 4
			\|-
			\| align="center" \| 2 \|\| 11, 10 \|\| 9, 8
			\|-
			\| align="center" \| 3 \|\| 15, 14 \|\| 13, 12
			\|}

			According with the table above a 4x4 block can be coded using 8 codes of the type "DYAD" as follows:

			code 0 for the dyad 0, line 0
			code 1 for the dyad 1, line 0
			code 2 for the dyad 0, line 1
			code 3 for the dyad 1, line 1
			code 4 for the dyad 0, line 2
			code 5 for the dyad 1, line 2
			code 6 for the dyad 0, line 3
			code 7 for the dyad 1, line 3

			Two dyads can form a quad (four-byte delta). In this case the corresponding line will be coded using only one code of the type "QUAD". The following example shows a valid block encoding intermixing both "DYAD" and "QUAD" codes:

			code 0, type = DYAD for the dyad 0, line 0
			code 1, type = DYAD for the dyad 1, line 0
			code 2, type = QUAD for the dyads 0 and 1, line 1
			code 3, type = DYAD for the dyad 0, line 2
			code 4, type = DYAD for the dyad 1, line 2
			code 5, type = QUAD for the dyads 0 and 1, line 3

			As we've seen above a line in a 4x4 block can be coded using either two codes of the type "DYAD" or one code of the type "QUAD". All other combinations are forbidden. The following example shows an invalid encoding intermixing both "DYAD" and "QUAD" codes:

			code 0, type = DYAD for the dyad 0, line 0
			code 1, type = QUAD --------> ERROR!!!

	== Pseudocode examples ==		== Pseudocode examples ==

Maxpol: /* Plane data */

2009-07-23T22:02:29Z

Plane data

← Older revision		Revision as of 15:02, 23 July 2009
Line 186:		Line 186:
	VQ codes for the cell n		VQ codes for the cell n

			The C-pseudocode example [[#Parsing binary tree codes\|here]] shows how to parse the binary tree segmentation properly.

	== Pseudocode examples ==		== Pseudocode examples ==

Maxpol: /* Parsing binary tree codes */

2009-07-23T22:00:08Z

Parsing binary tree codes

← Older revision		Revision as of 15:00, 23 July 2009
Line 186:		Line 186:
	VQ codes for the cell n		VQ codes for the cell n


			== Pseudocode examples ==

	=== Parsing binary tree codes ===		=== Parsing binary tree codes ===