List: linux-video
Subject: Winnov hardware compression
From: Bill Dirks <bdirks () micron ! com>
Date: 1999-10-21 19:57:39
[Download message RAW]
Here are some more details about Winnov hardware compression. I haven't
made it available to applications yet, but I'm working on it. Maybe in a
few days. At least this gives some understanding of how it works.
Bill.
Winnov WAVI Hardware Compression
As Applied in the Linux Drivers
WAVI is the chip designed by Winnov that the Videum series
products are based on.
WAVI captures data from the video decoder chip and stores
it in the on-board SRAM in one of the several video data
formats that it can do.
The Linux driver uses five video data format modes of the
WAVI when capturing in its compressed mode: DH7, DH6, DH5,
DH4, and YCQ.
DH7, DH6, DH5, and DH4 are the Delta-Huffman variable-
length compressed formats. These formats compress YUV 4:2:2
data using variable-length codes.
The uncompressed 4:2:2 data is 8 bits per component, and
stores two pixel values using two Y values, one U value
and one V value. The Ys and U/Vs alternate like this:
Y-U-Y-V-Y-U-Y-V-Y-U-Y-V--.... Without compression, the
data requires 16 bits per pixel.
The compressed format turns each one of those components
into a variable-length code. The process is as follows:
1. The data values are truncated to 7 (DH7), 6 (DH6), 5
(DH5) or 4 (DH4) bits by discarding the low-order bits.
2. The result is compared with the previous value of the
component, and the delta is computed by subtracting the
previous value (delta = value - previous_value). A Y value
is compared with the previous Y value, a U value is
compared with the previous U value, and V with previous V.
The very first Y, U and V of a video field image is
compared with zero.
3. If the delta is a positive value greater than 7, or a
negative value less than -7, then the delta is discarded,
and the absolute (truncated) value of the component is
stored, prefixed by 8 1-bits. Otherwise the delta is
converted to a variable-length code by the following table.
CODE DELTA
MSB.........LSB
001111111 +7
00111111 +6
0011111 +5
001111 +4
00111 +3
0011 +2
001 +1
0 0
101 -1
1011 -2
10111 -3
101111 -4
1011111 -5
10111111 -6
101111111 -7
xxxx11111111 X DH4 absolute value, not a delta
xxxxx11111111 X DH5 absolute value, not a delta
xxxxxx11111111 X DH6 absolute value, not a delta
xxxxxxx11111111 X DH7 absolute value, not a delta
Successive codes are assembled into longer words from LSB to
MSB. For example, the code sequence (+3), (-2), (-4), (0)
becomes 16 bits like this:
MSB LSB
0 101111 1011 00111
(0) (-4) (-2) (+3)
So you read the codes from LSB to MSB. You could call it a
little-endian system.
The decompression algorithm should be obvious. If the next
8 bits are all 1's then it is an absolute code. Get the
value from the bits following the 8 1's. Otherwise it is
a delta code. Convert the code to a delta value and add it
to the previous value. Fill in the LSBs of each output
value with 0's to make it 8 bits.
This compression scheme is lossy. The loss occurs at the
first step where the data are truncated. The variable-length
encoding and decoding is lossless. This scheme preserves
spacial resolution (there is no blurring effect) because it
encodes each pixel individually. It's a good choice for
capturing raw video disk to save space while preserving
quality.
The best case compression rate is when all the deltas are
zero which results in 2 bits per pixel. Typical is more
like 4 to 7 bits per pixel. It depends on the dimensions of
the image (bigger images get better compression because
adjacent pixels are more similar) and on the content of
the image.
Bad compression cases can cause the compressed data to grow
quite large if there are a lot of absolute codes. An example
is the "snow" you get with bad TV reception. If the image
data grows too big for the SRAM, then it becomes impossible
to capture images. To deal with that, the driver has a worst
case fall-back mode. When the image can't be captured in
compressed mode, the driver captures it in YCQ at half the
vertical resolution.
YCQ is a quantized YUV 4:1:1 format. Each 32 bits of data
contains four pixels: four 5-bit Y values, one 6-bit U
value and one 6-bit V value. That results in 8 bits per
pixel. Reducing the vertical resolution by half gives an
effective 4 bits per pixel, with some loss of spacial
resolution. The driver will only capture images that are
guaranteed to fit in SRAM at 4 bits per pixel.
Each 32-bit word of YCQ data is formatted like this:
MSB LSB
VVVVVVdddddcccccUUUUUUbbbbbaaaaa
Where a, b, c, and d are the Y values, and U and V are
the U and V values.
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.