Skip to contentSkip to conversation

v4l-utils: Add the JPEG Lite decoding function

PATCH In review Jean-Francois Moine 2 participants 2 messages Feb 15, 2011 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 v4l-utils: Add the JPEG Lite decoding function

Hi Hans,

I got the permission to relicense the JPEG Lite decoding to the LGPL.

If you want to test the nw80x driver, get the gspca tarball from my web page (2.12.12). I added your webcam which should directly work (p35u - chip nw801).

Best regards.

Signature · 2 lines
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
#1 lore raw

Hi,

Quoted 4 lines · Jean-Francois Moine

Hi Hans,

I got the permission to relicense the JPEG Lite decoding to the LGPL.

Ah, good, patch applied and pushed to git.

Quoted 3 lines

If you want to test the nw80x driver, get the gspca tarball from my web page (2.12.12). I added your webcam which should directly work (p35u - chip nw801).

I've tested it and it works :) I also tested the JPGL -> YUV path.

I did find 2 bugs, the "if (gspca_dev->curr_mode)" test in sd_start, needs to be inverted. In general it is a good idea to do a test on gspca_dev->width, rather then curr_mode IMHO, it is more readable and less error prone.

Talking about readability, I also found the

        if (sd->bridge == BRIDGE_NW800) {
		...
	} else {
		...
		if (sd->bridge == BRIDGE_NW802) {
			...
		} else {
			...
		}
	}

part in sd_init a bit hard to grok, can this be changed to a switch case on sd->bridge ?

The other bug was a divide by zero -> kernel panic, in do_autogain when sd->ae_res == 0, note this was when I was messing around with the driver a bit (before I found the issue with the inverted curr_mode check), but I think this could happen in real life to depending on register values and we should protect against this.

Regards,

Hans