Hi All,
On 04/17/2009 12:50 AM, Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Thomas Kaiser wrote:
<snip>
Just how does it work to set the "Compression Balance size"? Is this
some kind of special command sequence? Are we able to set this to
whatever we want?
It looks like. One can set a value from 0x0 to 0xff in the
"Compression Balance size" register (reg 0x4a).
In the pac207 Linux driver, this register is set to 0xff to turn off
the compression. While we use compression 0x88 is set (I think the
same value like in Windoz). Hans did play with this register and found
out that the compression changes with different values.
I wonder how this relates to the mr97310a. There is no such register
present, that I can see.
Hans, may you explain a bit more what you found out?
(Yes, please.)
Quoting from linux/drivers/media/video/gspca/pac207.c
(easiest for me as it has been a while I looked at this):
/* An exposure value of 4 also works (3 does not) but then we need to lower
the compression balance setting when in 352x288 mode, otherwise the usb
bandwidth is not enough and packets get dropped resulting in corrupt
frames. The problem with this is that when the compression balance gets
lowered below 0x80, the pac207 starts using a different compression
algorithm for some lines, these lines get prefixed with a 0x2dd2 prefix
and currently we do not know how to decompress these lines, so for now
we use a minimum exposure value of 5 */
#define PAC207_EXPOSURE_MIN 5
#define PAC207_EXPOSURE_MAX 26
And from libv4l/libv4lconvert/pac207.c:
void v4lconvert_decode_pac207(const unsigned char *inp, unsigned char *outp,
int width, int height)
{
/* we should received a whole frame with header and EOL marker
in myframe->data and return a GBRG pattern in frame->tmpbuffer
remove the header then copy line by line EOL is set with 0x0f 0xf0 marker
or 0x1e 0xe1 for compressed line*/
unsigned short word;
int row;
/* iterate over all rows */
for (row = 0; row < height; row++) {
word = getShort(inp);
switch (word) {
case 0x0FF0:
memcpy(outp, inp + 2, width);
inp += (2 + width);
break;
case 0x1EE1:
inp += pac_decompress_row(inp, outp, width);
break;
case 0x2DD2: /* prefix for "stronger" compressed lines, currently the
kernel driver programs the cam so that we should not
get any of these */
default: /* corrupt frame */
/* FIXME add error reporting */
return;
}
outp += width;
}
So iow, the pac207 prefixes each row of a frame it sends out with 2 bytes,
indication the type of compression used, 0FF0 == no compression,
1ee1 == compression currently known in libv4l
But if you lower the compression balance register below 0x80, it will also
send out rows prefixed with 2DD2, and we (I) have no clue how to decompress
these. If we could find out how to handle these, that would be great, as we
then could lower the exposure time more when in full daylight, curing the
over exposure problems we have in full daylight.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
