v4l library - decoding of Pixart JPEG frames

Hello Hans,

I found that the webcams containing a Pixart JPEG chip (PAC 73xx) generate strange JPEG frames: they contains 'ff ff ff xx' markers every 1024 or 512 bytes and there are eight unused bits at the end of each JPEG block (I saw also a 90 degrees rotation with the PAC 7302).

So, I added a new pixel format V4L2_PIX_FMT_PJPG for this encoding. It is generated by the pac7311 subdriver of gspca. May you add the code for decoding this format in the V4L library?

I could have done a patch by myself, but the tiny jpeg decoder is rather complex, and I could not find the right place to do the job. If it may help, I wrote a simple image viewer (http://moinejf.free.fr/siv.c) which takes a raw webcam image and displays it via gtk+. It contains the Pixart JPEG decoder and the two differences from normal JPEG are identified by 'pac7311'.

Cheers.

Ken ar c'hentañ |             ** Breizh ha Linux atav! **
Jef             |               http://moinejf.free.fr/


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

Hello Jean-Francois, Hans

I am the original developer who started the PAC7311 support for gspca V1.

xx = 01 -> 1024 Bytes
xx = 02 -> 512 Bytes
xx = 00 -> size of the following block is not defined

I don't know for what this markers should be good for. So, I suggest to just remove them in the driver.

End or Start? Depends where the end of the frame marker is defined! The Last Byte in the frame marker has the same bit pattern which you will find after each MCU. I call it MCU markers. So, throw the first MCU marker (last Byte in the frame header) away in the driver. While decoding the JPEG in the V4L library one have to throw away 8 Bit after each MCU.

Same thing I saw by analyzing usbsnoops from a PAC7302.

You should call it _SPJPG -> Special Pixart JPEG, just kidding :-)

Hans: Do you use tiny jpeg decoder in the v4l library?
I should have a version of tiny jpeg somewhere, where this special Pixart jpeg decoding is already implemented. But anyway it's simple, just skip 8 Bits after each MCU.

I really don't understand why Pixart added this stuff. Once I asked about more information about the stream, they just told me that they had develop their own JPEG coding and decoding and it is company confidential.

Hope this information helps.

Thomas

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

Hi Jean, Thomas,

Jean, good to see that you are working on the pixart 73xx support, I have a cam over here as well which didn't work at all, now with your fixes, it atleast generates proper frames (they used too be much too small). Unfortunately my cam still does not work, your siv.c does show something which seems to be decoded video data, but not as it should look like, from the looks of it we are close though.

I've made a single raw frame from my cam available here:
http://people.atrpms.net/~hdegoede/image.dat

If anyone can write code which can convert that to an image (might be unsharp) that would be great!

I've done a first attempt at making v4lconvert handle these pixart jpeg frames, patch attached. Warning this is a crude hack breaking regular jpeg support. This seems to work less well with my cam then the siv.c code, so we might need to make more changes either to v4lconvert, or maybe to the jpeg_put_header call in pac7311.c, talking about this call, since we are defining a custom format anyways, shouldn't we just omit the header and send the jpeg-ish pixart frame data to userspace as is?

Thomas, I would be very much interested in your tinyjpeg version with pixart support!

Jean, perhaps you can make some raw images from your cam available somewhere too?

Regards,

Hans

diff -r 566aac58b414 v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert-priv.h
@@ -43,6 +43,10 @@
 #define V4L2_PIX_FMT_PAC207 v4l2_fourcc('P','2','0','7')
 #endif
 
+#ifndef V4L2_PIX_FMT_PJPG
+#define V4L2_PIX_FMT_PJPG v4l2_fourcc('P', 'J', 'P', 'G')
+#endif
+
 #ifndef V4L2_PIX_FMT_SGBRG8
 #define V4L2_PIX_FMT_SGBRG8 v4l2_fourcc('G','B','R','G')
 #endif

diff -r 566aac58b414 v4l2-apps/lib/libv4l/libv4lconvert/tinyjpeg.c
@@ -60,6 +60,9 @@
 #define BLACK_Y 0
 #define BLACK_U 127
 #define BLACK_V 127
+
+#define DEBUG 1
+#define LOG2FILE 1
 
 #if DEBUG
 #if LOG2FILE

@@ -2112,6 +2115,7 @@
      for (x=0; x < priv->width; x+=xstride_by_mcu)
       {
 	decode_MCU(priv);
+	skip_nbits(priv->reservoir, priv->nbits_in_reservoir, priv->stream, 8);
 	convert_to_pixfmt(priv);
 	priv->plane[0] += bytes_per_mcu[0];
 	priv->plane[1] += bytes_per_mcu[1];

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

Hi Hans,

I forgot to give you the command:

	siv -p PJPG -f 480x640 -d image.dat

('-p PJPG' gives the encoding and '-f 480x640' because the image is turned to the left).

It is almost black and white with high contrast.

About the header, it seems that neither the previous (in pac7311.c), nor the standard jpeg header (in jpeg.h) give good results.

I am working with a french guy (Magic Banana, in Cc) who has a webcam with a 7302 sensor. I put an image extracted from a MS-win trace in my site:

	http://moinejf.free.fr/pac7302.dat

(I added a jpeg header).

Cheers

Ken ar c'hentañ |             ** Breizh ha Linux atav! **
Jef             |               http://moinejf.free.fr/


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