PATCH: gspca-pac207-fix-daylight-frame-decode-errors.patch

PATCH: gspca-pac207-fix-daylight-frame-decode-errors.patch

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

Hi,

This patch fixes the frame decoding errors seen when using the pac207 in full
daylight.

The problem is that in full daylight, the exposure time was set so low, that
in 352x288 mode the usb bandwidth is not enough and packets get dropped
resulting in corrupt frames. This patch worksaround this issue by increasing
the minimum allowed exposure time, reducing the max framerate and thus the max
needed bandwidth.

The proper fix for this would be to lower the compression balance setting when
in 352x288 mode. 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

Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>

Regards,

Hans

[-- Attachment #2: gspca-pac207-fix-daylight-frame-decode-errors.patch --]
[-- Type: text/plain, Size: 2110 bytes --]

This patch fixes the frame decoding errors seen when using the pac207 in full
daylight.

The problem is that in full daylight, the exposure time was set so low, that
in 352x288 mode the usb bandwidth is not enough and packets get dropped
resulting in corrupt frames. This patch worksaround this issue by increasing
the minimum allowed exposure time, reducing the max framerate and thus the max
needed bandwidth.

The proper fix for this would be to lower the compression balance setting when
in 352x288 mode. 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

Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>

diff -r 2ce25c86c3a9 linux/drivers/media/video/gspca/pac207.c
--- a/linux/drivers/media/video/gspca/pac207.c	Fri Jul 04 10:56:40 2008 +0200
+++ b/linux/drivers/media/video/gspca/pac207.c	Fri Jul 04 12:51:09 2008 +0200
@@ -40,9 +40,17 @@
 #define PAC207_BRIGHTNESS_MAX		255
 #define PAC207_BRIGHTNESS_DEFAULT	4 /* power on default: 4 */
 
-#define PAC207_EXPOSURE_MIN		4
+/* 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
-#define PAC207_EXPOSURE_DEFAULT		4 /* power on default: 3 ?? */
+#define PAC207_EXPOSURE_DEFAULT		5 /* power on default: 3 ?? */
 #define PAC207_EXPOSURE_KNEE		11 /* 4 = 30 fps, 11 = 8, 15 = 6 */
 
 #define PAC207_GAIN_MIN			0

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: PATCH: gspca-pac207-fix-daylight-frame-decode-errors.patch

[Thomas Kaiser]

Hans de Goede wrote:
> The proper fix for this would be to lower the compression balance 
> setting when
> in 352x288 mode. 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
Hello Hans

Can you post some frames with a lower compression balance, please? Then 
other people can take a look at the decoding ;-)

Thomas

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: PATCH: gspca-pac207-fix-daylight-frame-decode-errors.patch

[Hans de Goede]

Thomas Kaiser wrote:
> Hans de Goede wrote:
>> The proper fix for this would be to lower the compression balance 
>> setting when
>> in 352x288 mode. 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
> Hello Hans
> 
> Can you post some frames with a lower compression balance, please? Then 
> other people can take a look at the decoding ;-)
> 

Done, if you go here:
http://people.atrpms.net/~hdegoede/

You will see about 20 imgXX.raw's, which are pac207 compressed bayer images, 
including lines starting with the 0x2dd2 prefix.

When decoded they should show a hand (mine) at the top of the screen holding a 
lucky lucky comic in front of the cam.

Note this is not me being shy, but I needed a high contrast image which was 
hard to compress to trigger the bug :)

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list