Auravision: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
(i emailed someone who worked at auravision. this was the reply i got.)
(aura / aur2 added to ffmpeg/mplayer, remove 'formats missing' cat)
 
(2 intermediate revisions by 2 users not shown)
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]]

Latest revision as of 11:12, 24 December 2009

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

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.

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:

 high nibble of byte 0 - Cr value
 low  nibble of byte 0 - Y0 value
 high nibble of byte 1 - Cb value
 low  nibble of byte 1 - Y1 value
 high nibble of byte 2 - Cr value
 low  nibble of byte 2 - Y2 value
 ...