Re: Some questions about mr97310 controls (continuing previous thread on mr97310a.c)

[Hans de Goede <hdegoede@redhat.com>]

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