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

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

Regards,

Hans

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

diff -r 2ce25c86c3a9 linux/drivers/media/video/gspca/pac207.c
@@ -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

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list