Auravision - Revision history

Compn: aura / aur2 added to ffmpeg/mplayer, remove 'formats missing' cat

2009-12-24T18:12:48Z

aura / aur2 added to ffmpeg/mplayer, remove 'formats missing' cat

← Older revision		Revision as of 11:12, 24 December 2009
Line 20:		Line 20:

	[[Category:Video Codecs]]		[[Category:Video Codecs]]
	~~[[Category:Formats missing in FFmpeg]]~~
	~~[[Category:Formats missing in MPlayer]]~~

Compn at 13:22, 8 March 2009

2009-03-08T13:22:10Z

← Older revision		Revision as of 06:22, 8 March 2009
Line 21:		Line 21:
	[[Category:Video Codecs]]		[[Category:Video Codecs]]
	[[Category:Formats missing in FFmpeg]]		[[Category:Formats missing in FFmpeg]]
			[[Category:Formats missing in MPlayer]]

Kostya: Meh, too easy

2009-01-14T20:53:06Z

Meh, too easy

← Older revision		Revision as of 13:53, 14 January 2009
Line 7:		Line 7:
	According to various codec lists, AURA is a [[YUV 4:1:1]] codec while AUR2 is [[YUV 4:2:2]]. The payload of an AURA frame begins with the 6 ASCII bytes 'YUV411'.		According to various codec lists, AURA is a [[YUV 4:1:1]] codec while AUR2 is [[YUV 4:2:2]]. The payload of an AURA frame begins with the 6 ASCII bytes 'YUV411'.

	~~Note from former~~ Auravision ~~Employee (but not aura/aur2 codec developer)~~: ~~Aura codec~~ is ~~not compression one (i.e. mpeg), but rather color space conversion~~.		Auravision employs the same packing scheme as [[Creative YUV]] with the only difference: bytes 16-31 are Y predictor values and bytes 32-47 are predictor values for both U and V. Actual data is packed identically.

	~~== Hypothesis ==~~		Auravision2 uses the same predictor value table at bytes 16-31 for all planes but packed pixel data still starts at byte 48. It's packed in the following order:
	-~~-[[User:Multimedia Mike\|Multimedia Mike]] 02~~:~~42, 10 December 2008 (EST)~~

	~~Any given AURA sample contains frames~~ of ~~a constant size. For 160x120 files, the frames are each 14448 bytes. For 240x180 files, the frames are each 32448 bytes. In YUV 4:1:1 data, a 4x4 block consisting~~ of ~~16 pixels assigns a Y sample to each pixel while all 16 pixels share a U and a V sample. If each sample is 1~~ byte~~, the size~~ of ~~a raw YUV 4:~~1~~:1 frame is (width * height * 18) / 16. This formula does not reconcile with AURA frames.~~		high nibble of byte 0 - Cr value
			low nibble of byte 0 - Y0 value
	~~However, if each~~ of ~~the Y samples is only coded with 5 bits, the observed frame sizes come close, with 48 extra bytes. Indeed, the frames do appear to begin with a 48~~-~~byte header. So the size of the frame is calculated as~~		high nibble of byte 1 - Cb value
			low nibble of byte 1 - Y1 value
	~~p = width * height~~		high nibble of byte 2 - Cr value
	~~48 + (p * 5/8) + (p/16) * 2~~		low nibble of byte 2 - Y2 value
			...
	~~Testing this hypothesis might require trying several different bit reading methods.~~

	~~== Hypothesis~~ 2 ==
	--~~[[User:Kostya\|Kostya]] 06:07, 10 December 2008 (EST)~~
	~~<pre>~~
	~~first 16 bytes - some rubbish~~
	~~next 16 bytes - quantization table for luma~~
	~~next 16 bytes - quantization table for chroma~~
	~~</pre>~~
	~~the rest is packed into nibbles somehow with actual~~ value ~~obtained via table~~

	~~== Hypothesis 3 ==~~
	~~--[[User:Multimedia Mike\|Multimedia Mike]] 14:17, 10 December 2008 (EST)~~

	I move to strike my earlier hypothesis (though I'm amazed that the numbers worked out). I was confusing [[YUV 4:1:1]] with [[YUV 4:1:0]]. YUV 4:1:1 carries as much chroma information as [[YUV 4:2:2]], just in a different orientation. ~~Thus, there are 1/4 as many chroma samples as luma samples, rather than 1/16~~.

	~~I support Kostya's hypothesis~~. ~~The revised size calculation would be:~~

	~~p = width * height~~
	~~48 (bytes) +~~
	~~( p (luma samples) * 4 (bits/luma sample) / 8 (bits/byte) ) +~~
	~~( p/4 (chroma samples/chroma plane) * 4 (bits/chroma sample) / 8 (bits/byte) ) * 2 (chroma planes)~~

	~~Which reduces to:~~

	~~total bytes/frame = 48 + (3 * p / 4)~~

	[[Category:Video Codecs]]		[[Category:Video Codecs]]
	[[Category:~~Undiscovered Video Codecs~~]]		[[Category:Formats missing in FFmpeg]]

Compn: i emailed someone who worked at auravision. this was the reply i got.

2009-01-13T00:59:41Z

i emailed someone who worked at auravision. this was the reply i got.

← Older revision		Revision as of 17:59, 12 January 2009
Line 6:		Line 6:

	According to various codec lists, AURA is a [[YUV 4:1:1]] codec while AUR2 is [[YUV 4:2:2]]. The payload of an AURA frame begins with the 6 ASCII bytes 'YUV411'.		According to various codec lists, AURA is a [[YUV 4:1:1]] codec while AUR2 is [[YUV 4:2:2]]. The payload of an AURA frame begins with the 6 ASCII bytes 'YUV411'.

			Note from former Auravision Employee (but not aura/aur2 codec developer): Aura codec is not compression one (i.e. mpeg), but rather color space conversion.

	== Hypothesis ==		== Hypothesis ==

Compn: AUR2 sample file courtesy of anonymous on moviecodec.com forums

2009-01-13T00:55:30Z

AUR2 sample file courtesy of anonymous on moviecodec.com forums

← Older revision		Revision as of 17:55, 12 January 2009
Line 3:		Line 3:
	* Samples:		* Samples:
	** AURA: http://samples.mplayerhq.hu/V-codecs/AURA/		** AURA: http://samples.mplayerhq.hu/V-codecs/AURA/
			** AUR2: http://samples.mplayerhq.hu/V-codecs/AUR2/

	According to various codec lists, AURA is a [[YUV 4:1:1]] codec while AUR2 is [[YUV 4:2:2]]. The payload of an AURA frame begins with the 6 ASCII bytes 'YUV411'.		According to various codec lists, AURA is a [[YUV 4:1:1]] codec while AUR2 is [[YUV 4:2:2]]. The payload of an AURA frame begins with the 6 ASCII bytes 'YUV411'.

Multimedia Mike: Kostya's hypothesis is more plausible

2008-12-10T19:17:10Z

Kostya's hypothesis is more plausible

@@ Line 26: / Line 26: @@
 </pre>
 the rest is packed into nibbles somehow with actual value obtained via table
 [[Category:Video Codecs]]
 [[Category:Undiscovered Video Codecs]]

Compn: /* Hypothesis 2 */

2008-12-10T14:34:35Z

Hypothesis 2

← Older revision		Revision as of 07:34, 10 December 2008
Line 20:		Line 20:
	== Hypothesis 2 ==		== Hypothesis 2 ==
	--[[User:Kostya\|Kostya]] 06:07, 10 December 2008 (EST)		--[[User:Kostya\|Kostya]] 06:07, 10 December 2008 (EST)
			<pre>
	first 16 bytes - some rubbish		first 16 bytes - some rubbish
	next 16 bytes - quantization table for luma		next 16 bytes - quantization table for luma
	next 16 bytes - quantization table for chroma		next 16 bytes - quantization table for chroma
			</pre>
	the rest is packed into nibbles somehow with actual value obtained via table		the rest is packed into nibbles somehow with actual value obtained via table

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

Kostya at 11:07, 10 December 2008

2008-12-10T11:07:52Z

← Older revision		Revision as of 04:07, 10 December 2008
Line 17:		Line 17:

	Testing this hypothesis might require trying several different bit reading methods.		Testing this hypothesis might require trying several different bit reading methods.

			== Hypothesis 2 ==
			--[[User:Kostya\|Kostya]] 06:07, 10 December 2008 (EST)

			first 16 bytes - some rubbish
			next 16 bytes - quantization table for luma
			next 16 bytes - quantization table for chroma

			the rest is packed into nibbles somehow with actual value obtained via table

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

Multimedia Mike: colon

2008-12-10T08:02:31Z

colon

← Older revision		Revision as of 01:02, 10 December 2008
Line 1:		Line 1:
	* FourCCs: AURA, AUR2		* FourCCs: AURA, AUR2
	* Company Auravision		* Company: Auravision
	* Samples:		* Samples:
	** AURA: http://samples.mplayerhq.hu/V-codecs/AURA/		** AURA: http://samples.mplayerhq.hu/V-codecs/AURA/

Multimedia Mike: /* Hypothesis */ better variables

2008-12-10T07:52:12Z

Hypothesis: better variables

← Older revision		Revision as of 00:52, 10 December 2008
Line 9:		Line 9:
	--[[User:Multimedia Mike\|Multimedia Mike]] 02:42, 10 December 2008 (EST)		--[[User:Multimedia Mike\|Multimedia Mike]] 02:42, 10 December 2008 (EST)

	Any given AURA sample contains frames of a constant size. For 160x120 files, the frames are each 14448 bytes. For 240x180 files, the frames are each 32448 bytes. In YUV 4:1:1 data, a 4x4 block consisting of 16 pixels assigns a Y sample to each pixel while all 16 pixels share a U and a V sample. If each sample is 1 byte, the size of a raw YUV 4:1:1 frame is (X * Y * 18) / 16. This formula does not reconcile with AURA frames.		Any given AURA sample contains frames of a constant size. For 160x120 files, the frames are each 14448 bytes. For 240x180 files, the frames are each 32448 bytes. In YUV 4:1:1 data, a 4x4 block consisting of 16 pixels assigns a Y sample to each pixel while all 16 pixels share a U and a V sample. If each sample is 1 byte, the size of a raw YUV 4:1:1 frame is (width * height * 18) / 16. This formula does not reconcile with AURA frames.

	However, if each of the Y samples is only coded with 5 bits, the observed frame sizes come close, with 48 extra bytes. Indeed, the frames do appear to begin with a 48-byte header. So the size of the frame is calculated as		However, if each of the Y samples is only coded with 5 bits, the observed frame sizes come close, with 48 extra bytes. Indeed, the frames do appear to begin with a 48-byte header. So the size of the frame is calculated as

	p = X * Y		p = width * height
	48 + (p * 5/8) + (p/16) * 2		48 + (p * 5/8) + (p/16) * 2