SpeedHQ - Revision history

Kostya: SpeedHQ is pretty much discovered

2021-01-01T11:50:18Z

SpeedHQ is pretty much discovered

← Older revision		Revision as of 04:50, 1 January 2021
Line 1:		Line 1:
	* FOURCCs: SHQ0, SHQ1, ..., SHQ5, SHQ7, SHQ9		* FOURCCs: SHQ0, SHQ1, ..., SHQ5, SHQ7, SHQ9
	* Company: NewTek (note: NewTek has provided samples and support in understanding the format)		* Company: NewTek (note: NewTek has provided samples and support in understanding the format)
			* Decoder: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/speedhq.c

	This is a simple intermediate codec with different subsampling and alpha support. It is generally very similar to MPEG-2 intraframe. Several variants exist:		This is a simple intermediate codec with different subsampling and alpha support. It is generally very similar to MPEG-2 intraframe. Several variants exist:
Line 160:		Line 161:
	Y'CbCr conversion uses BT.601 coefficients. Chroma positioning is center, as in MPEG-2.		Y'CbCr conversion uses BT.601 coefficients. Chroma positioning is center, as in MPEG-2.

	~~[[Category:Undiscovered Video Codecs]]~~
	[[Category:Video Codecs]]		[[Category:Video Codecs]]

Sesse: Alpha is never coded as chroma.

2017-01-08T12:11:01Z

Alpha is never coded as chroma.

← Older revision		Revision as of 05:11, 8 January 2017
Line 7:		Line 7:
	* <code>SHQ2</code>/<code>SHQ3</code> are 4:2:2 with/without alpha.		* <code>SHQ2</code>/<code>SHQ3</code> are 4:2:2 with/without alpha.
	* <code>SHQ4</code>/<code>SHQ5</code> are 4:4:4 with/without alpha.		* <code>SHQ4</code>/<code>SHQ5</code> are 4:4:4 with/without alpha.
	* <code>SHQ7</code> is 422 with alpha coded as luma ~~and chroma blocks~~		* <code>SHQ7</code> is 422 with alpha coded the same way as luma
	* <code>SHQ9</code> is the same for 444 format.		* <code>SHQ9</code> is the same for 444 format.

Sesse: Added information about old-style alpha

2017-01-07T18:48:22Z

Added information about old-style alpha

@@ Line 100: / Line 100: @@
 Escape works similarly to MPEG-2; the next six bits contain the run (non-reversed), and the next 12 bits contain the level (non-reversed), offset by 2048. There'a always an EOB at the end of each block (as in MPEG-2), and there's never a block without a DC coefficient (also as in MPEG-2). All other codes are followed by the coefficient sign (again as in MPEG-2).
-Alpha for SHQ1/3/5 is coded as run-level too: first it has a codeword telling how many elements to skip (or whether this is end of block) and then a codeword for nonzero element, repeat.
+=== Alpha ===
-Alpha for SHQ7/9 is encoded identically to luma, and comes after chroma (so e.g. SHQ7 is YYYY UV UV AAAA).
+Alpha for SHQ1/3/5 is coded in 16x8 blocks without zigzag, coming after chroma (so e.g. SHQ3 is YYYY UV UV AA), top first, then bottom. It does not use DCT, but is still coded as run/level; first it has a codeword telling how many elements to skip (or whether this is end of block) and then a codeword for nonzero element, repeat until the EOB code. The code for run is (remember that all bit strings and literals go in little-endian order, even though they're written left to right here):
 === Quantiser ===

Sesse: Alpha for SHQ7/SHQ9.

2017-01-06T18:19:44Z

Alpha for SHQ7/SHQ9.

← Older revision		Revision as of 11:19, 6 January 2017
Line 100:		Line 100:
	Escape works similarly to MPEG-2; the next six bits contain the run (non-reversed), and the next 12 bits contain the level (non-reversed), offset by 2048. There'a always an EOB at the end of each block (as in MPEG-2), and there's never a block without a DC coefficient (also as in MPEG-2). All other codes are followed by the coefficient sign (again as in MPEG-2).		Escape works similarly to MPEG-2; the next six bits contain the run (non-reversed), and the next 12 bits contain the level (non-reversed), offset by 2048. There'a always an EOB at the end of each block (as in MPEG-2), and there's never a block without a DC coefficient (also as in MPEG-2). All other codes are followed by the coefficient sign (again as in MPEG-2).

	Alpha is coded as run-level too: first it has a codeword telling how many elements to skip (or whether this is end of block) and then a codeword for nonzero element, repeat.		Alpha for SHQ1/3/5 is coded as run-level too: first it has a codeword telling how many elements to skip (or whether this is end of block) and then a codeword for nonzero element, repeat.

			Alpha for SHQ7/9 is encoded identically to luma, and comes after chroma (so e.g. SHQ7 is YYYY UV UV AAAA).

	=== Quantiser ===		=== Quantiser ===

Sesse: More info based on the samples

2017-01-06T00:20:46Z

More info based on the samples

← Older revision		Revision as of 17:20, 5 January 2017
Line 1:		Line 1:
	* FOURCCs: SHQ0, SHQ1, ..., SHQ5, SHQ7, SHQ9		* FOURCCs: SHQ0, SHQ1, ..., SHQ5, SHQ7, SHQ9
	* Company: NewTek (note: NewTek has provided support in understanding the format)		* Company: NewTek (note: NewTek has provided samples and support in understanding the format)

	This is a simple intermediate codec with different subsampling and alpha support. It is generally very similar to MPEG-2 intraframe. Several variants exist:		This is a simple intermediate codec with different subsampling and alpha support. It is generally very similar to MPEG-2 intraframe. Several variants exist:

	* <code>SHQ0</code>/<code>SHQ1</code> are 4:2:0 with/without alpha ~~(SHQ1 is either rare or nonexistant in practice)~~.		* <code>SHQ0</code>/<code>SHQ1</code> are 4:2:0 with/without alpha.
	* <code>SHQ2</code>/<code>SHQ3</code> are 4:2:2 with/without alpha.		* <code>SHQ2</code>/<code>SHQ3</code> are 4:2:2 with/without alpha.
	* <code>SHQ4</code>/<code>SHQ5</code> are 4:4:4 with/without alpha.		* <code>SHQ4</code>/<code>SHQ5</code> are 4:4:4 with/without alpha.
Line 20:		Line 20:
	Each field is split into four slices that can be independently decoded; each slice codes 16 lines, then skip 48 lines (coded by the other three slices), code 16 more lines, and so on until at the bottom of the field, which implicitly ends the slice. The first three bytes of each slice form a length of the slice in bytes (including the three length bytes). The next slice starts on the byte immediately after the end of the previous one, as given by the length (this might mean skipping 1–7 bits).		Each field is split into four slices that can be independently decoded; each slice codes 16 lines, then skip 48 lines (coded by the other three slices), code 16 more lines, and so on until at the bottom of the field, which implicitly ends the slice. The first three bytes of each slice form a length of the slice in bytes (including the three length bytes). The next slice starts on the byte immediately after the end of the previous one, as given by the length (this might mean skipping 1–7 bits).

	Blocks are 8x8 pixels, and macroblocks are 16x16 pixels (coded top-left, top-right, bottom-left, bottom-right). 4:4:4 is coded YYYY UV UV UV UV. 4:2:2 is coded YYYY UV UV. 4:2:0 is coded YYYY UV.		Blocks are 8x8 pixels, and macroblocks are 16x16 pixels. Luma is coded top-left, top-right, bottom-left, bottom-right. 4:4:4 is coded YYYY UV UV UV UV (chroma is top-left, bottom-left, top-right, bottom-right). 4:2:2 is coded YYYY UV UV (chroma is top, then bottom). 4:2:0 is coded YYYY UV.

	Blocks are coded with static VLCs. DC coefficients are coded exactly as in MPEG-2 (same luma/chroma tables, same scheme for storing the coefficient and sign). DC prediction is taken from the previous block of the same coefficient, and restarts at 1024 for each new macroblock row (not 128 as in MPEG-2). Curiously enough, one needs to _subtract_ the stored DC value from the prediction, not add as usual.		Blocks are coded with static VLCs. DC coefficients are coded exactly as in MPEG-2 (same luma/chroma tables, same scheme for storing the coefficient and sign). DC prediction is taken from the previous block of the same coefficient, and restarts at 1024 for each new macroblock row (not 128 as in MPEG-2). Curiously enough, one needs to _subtract_ the stored DC value from the prediction, not add as usual.

Sesse: Some corrections based on information from NewTek

2017-01-05T19:16:44Z

Some corrections based on information from NewTek

Sesse: Fixed table mispaste

2017-01-04T20:12:03Z

Fixed table mispaste

Show changes

Sesse: /* Quantiser */ Chroma positioning

2017-01-04T17:28:19Z

Quantiser: Chroma positioning

← Older revision		Revision as of 10:28, 4 January 2017
Line 129:		Line 129:
	As an optimization, DC-only blocks are special-cased; all pixels in the block get exactly the value (dc + 1032) >> 3.		As an optimization, DC-only blocks are special-cased; all pixels in the block get exactly the value (dc + 1032) >> 3.

	Y'CbCr conversion uses BT.601 coefficients. Chroma positioning is ~~unknown~~.		Y'CbCr conversion uses BT.601 coefficients. Chroma positioning is center, as in MPEG-2.

	[[Category:Undiscovered Video Codecs]]		[[Category:Undiscovered Video Codecs]]
	[[Category:Video Codecs]]		[[Category:Video Codecs]]

Sesse at 20:06, 3 January 2017

2017-01-03T20:06:10Z

← Older revision		Revision as of 13:06, 3 January 2017
Line 2:		Line 2:
	* Company: NewTek		* Company: NewTek

	This is a simple intermediate codec with different subsampling and alpha support. It is generally very similar to MPEG-2 ~~infraframe~~. Several variants exist:		This is a simple intermediate codec with different subsampling and alpha support. It is generally very similar to MPEG-2 intraframe. Several variants exist:

	* <code>SHQ0</code>/<code>SHQ1</code> are 4:2:0 with/without alpha (SHQ1 is either rare or nonexistant in practice).		* <code>SHQ0</code>/<code>SHQ1</code> are 4:2:0 with/without alpha (SHQ1 is either rare or nonexistant in practice).
Line 129:		Line 129:
	As an optimization, DC-only blocks are special-cased; all pixels in the block get exactly the value (dc + 1032) >> 3.		As an optimization, DC-only blocks are special-cased; all pixels in the block get exactly the value (dc + 1032) >> 3.

	Y'CbCr conversion uses BT.601 coefficients. Chroma positioning is unknown		Y'CbCr conversion uses BT.601 coefficients. Chroma positioning is unknown.

	[[Category:Undiscovered Video Codecs]]		[[Category:Undiscovered Video Codecs]]
	[[Category:Video Codecs]]		[[Category:Video Codecs]]

Sesse at 20:05, 3 January 2017

2017-01-03T20:05:39Z

← Older revision		Revision as of 13:05, 3 January 2017
Line 21:		Line 21:

	Blocks are 8x8 pixels, and macroblocks are 16x16 pixels (coded top-left, top-right, bottom-left, bottom-right). 4:4:4 is coded YYYY UV UV UV UV. 4:2:2 is coded YYYY UV UV. 4:2:0 is coded YYYY UV.		Blocks are 8x8 pixels, and macroblocks are 16x16 pixels (coded top-left, top-right, bottom-left, bottom-right). 4:4:4 is coded YYYY UV UV UV UV. 4:2:2 is coded YYYY UV UV. 4:2:0 is coded YYYY UV.

	Blocks are coded with static VLCs. DC coefficients are coded exactly as in MPEG-2 (same luma/chroma tables, same scheme for storing the coefficient and sign). DC prediction is taken from the previous block of the same coefficient, and restarts at 0 for each new macroblock row (not 128 as in MPEG-2). Curiously enough, one needs to _subtract_ the stored DC value from the prediction, not add as usual.

	Blocks are coded with static VLCs. DC coefficients are coded exactly as in MPEG-2 (same luma/chroma tables, same scheme for storing the coefficient and sign). DC prediction is taken from the previous block of the same coefficient, and restarts at 0 for each new macroblock row (not 128 as in MPEG-2). Curiously enough, one needs to _subtract_ the stored DC value from the prediction, not add as usual.		Blocks are coded with static VLCs. DC coefficients are coded exactly as in MPEG-2 (same luma/chroma tables, same scheme for storing the coefficient and sign). DC prediction is taken from the previous block of the same coefficient, and restarts at 0 for each new macroblock row (not 128 as in MPEG-2). Curiously enough, one needs to _subtract_ the stored DC value from the prediction, not add as usual.
Line 113:		Line 111:

	1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28, 32, 36, 40, 44, 48, 52, 56, 64, 72, 80, 88, 96, 104, 112		1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28, 32, 36, 40, 44, 48, 52, 56, 64, 72, 80, 88, 96, 104, 112


	Provided quality is clipped to 99, also if it's less than 38 or odd then a nearest smaller value from default quality table is used instead.		Provided quality is clipped to 99, also if it's less than 38 or odd then a nearest smaller value from default quality table is used instead.

← Older revision		Revision as of 12:16, 5 January 2017
Line 1:		Line 1:
	* FOURCCs: SHQ0, SHQ1, ..., SHQ5, SHQ7, SHQ9		* FOURCCs: SHQ0, SHQ1, ..., SHQ5, SHQ7, SHQ9
	* Company: NewTek		* Company: NewTek (note: NewTek has provided support in understanding the format)

	This is a simple intermediate codec with different subsampling and alpha support. It is generally very similar to MPEG-2 intraframe. Several variants exist:		This is a simple intermediate codec with different subsampling and alpha support. It is generally very similar to MPEG-2 intraframe. Several variants exist:
Line 14:		Line 14:
	Frame is always coded as two fields, data is packed into 32-bit little-endian words and is read from LSB.		Frame is always coded as two fields, data is packed into 32-bit little-endian words and is read from LSB.

	First byte is quality, next three bytes form an offset to the second field. Quantizer is 100 - quality.		First byte is quality, next three bytes form an offset to the second field. (Exception: NDI can send a frame consisting of a single field, with the second field offset equal to 4, ie., exactly overlapping with the first field.) Quantizer is 100 - quality.

	=== Field format ===		=== Field format ===
Line 22:		Line 22:
	Blocks are 8x8 pixels, and macroblocks are 16x16 pixels (coded top-left, top-right, bottom-left, bottom-right). 4:4:4 is coded YYYY UV UV UV UV. 4:2:2 is coded YYYY UV UV. 4:2:0 is coded YYYY UV.		Blocks are 8x8 pixels, and macroblocks are 16x16 pixels (coded top-left, top-right, bottom-left, bottom-right). 4:4:4 is coded YYYY UV UV UV UV. 4:2:2 is coded YYYY UV UV. 4:2:0 is coded YYYY UV.

	Blocks are coded with static VLCs. DC coefficients are coded exactly as in MPEG-2 (same luma/chroma tables, same scheme for storing the coefficient and sign). DC prediction is taken from the previous block of the same coefficient, and restarts at 0 for each new macroblock row (not 128 as in MPEG-2). Curiously enough, one needs to _subtract_ the stored DC value from the prediction, not add as usual.		Blocks are coded with static VLCs. DC coefficients are coded exactly as in MPEG-2 (same luma/chroma tables, same scheme for storing the coefficient and sign). DC prediction is taken from the previous block of the same coefficient, and restarts at 1024 for each new macroblock row (not 128 as in MPEG-2). Curiously enough, one needs to _subtract_ the stored DC value from the prediction, not add as usual.

	AC coefficients are coded using the same scheme as MPEG-2 (run/level with the same zigzag pattern), and with a VLC that is very similar to MPEG-2's “Table One” for AC coefficients. (It is not identical; some codewords that are illegal in MPEG-2 are used in SpeedHQ, and a few others are moved around as a consequence.) In FFmpeg format, the codes are:		AC coefficients are coded using the same scheme as MPEG-2 (run/level with the same zigzag pattern), and with a VLC that is very similar to MPEG-2's “Table One” for AC coefficients. (It is not identical; some codewords that are illegal in MPEG-2 are used in SpeedHQ, and a few others are moved around as a consequence.) In FFmpeg format, the codes are (except that they would need to be bit-reversed due to INIT_VLC_LE demands):

	static const uint16_t speedhq_vlc[123][2] = {		static const uint16_t speedhq_vlc[123][2] = {
Line 121:		Line 121:
	27, 29, 35, 38, 46, 56, 69, 83		27, 29, 35, 38, 46, 56, 69, 83

	The DC quantizer is set to 16 no matter what; the other values are multiplied by (100 - quality). Each coefficient is multiplied with the corresponding quantization factor and then divided by 16 (no rounding)~~. Finally~~, ~~1024 is added to the DC coefficient, and then~~ the block goes to IDCT.		The DC quantizer is set to 16 no matter what; the other values are multiplied by (100 - quality). Each coefficient is multiplied with the corresponding quantization factor and then divided by 16 (no rounding), before the block goes to IDCT.

	As an optimization, DC-only blocks are special-cased; all pixels in the block get exactly the value (dc + ~~1032~~) >> 3.		As an optimization, DC-only blocks are special-cased; all pixels in the block get exactly the value (dc + 4) >> 3.

	Y'CbCr conversion uses BT.601 coefficients. Chroma positioning is center, as in MPEG-2.		Y'CbCr conversion uses BT.601 coefficients. Chroma positioning is center, as in MPEG-2.