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

[Hans de Goede <j.w.r.degoede@hhs.nl>]

[-- 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