Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Friday 17 April 2009 12:50:51 Theodore Kilgore wrote: On Thu, 16 Apr 2009, Kyle Guinn wrote: On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote: On Thu, 16 Apr 2009, Kyle Guinn wrote: I've been looking through the frame headers sent by the MR97310A (the Aiptek PenCam VGA+, 08ca:0111). Here are my observations. FF FF 00 FF 96 6x x0 xx xx xx xx xx In binary that looks something like this: 10010110 011001aa a101 All of the values look to be MSbit first. A looks like a 3-bit frame sequence number that seems to start with 1 and increments for each frame. Hmmm. This I never noticed. What you are saying is that the two bytes 6x and x0 are variable? You are sure about that? What I have previously experienced is that the first is always 64 with these cameras, and the second one indicates the absence of compression (in which case it is 0, which of course only arises for still cameras), or if there is data compression then it is not zero. I have never seen this byte to change during a session with a camera. Here is a little table of what I have previously witnessed, and perhaps you can suggest what to do in order to see this is not happening: Camera that byte compression solved, or not streaming Aiptek 00 no N/A no Aiptek 50 yes yes both the Sakar cam 00 no N/A no ditto 50 yes yes both Argus QuikClix 20 yes no doesn't work Argus DC1620 50 yes yes doesn't work CIF cameras00 no N/A no ditto 50 yes yes no ditto d0 yes no yes Other strange facts are -- that the Sakar camera, the Argus QuikClix, and the DC1620 all share the same USB ID of 0x93a:0x010f and yet only one of them will stream with the existing driver. The other two go through the motions, but the isoc packets do not actually get sent, so there is no image coming out. I do not understand the reason for this; I have been trying to figure it out and it is rather weird. I should add that, yes, those two cameras were said to be capable of streaming when I bought them. Could it be a problem of age? I don't expect that, but maybe. -- the CIF cameras all share the USB id of 0x93a:0x010e (I bought several of them) and they all are using a different compression algorithm while streaming from what they use if running as still cameras in compressed mode. This leads to the question whether it is possible to set the compression algorithm during the initialization sequence, so that the camera also uses the 0x50 mode while streaming, because we already know how to use that mode. But I have never seen the 0x64 0xX0 bytes used to count the frames. Could you tell me how to repeat that? It certainly would knock down the validity of the above table wouldn't it? I've modified libv4l to print out the 12-byte header before it skips over it. Good idea, and an obvious one. Why did I not think of that? Then when I fire up mplayer it prints out each header as each frame is received. The framerate is only about 5 fps so there isn't a ton of data to parse through. When I point the camera into a light I get this (at 640x480): ... ff ff 00 ff 96 64 d0 c1 5c c6 00 00 ff ff 00 ff 96 65 50 c1 5c c6 00 00 ff ff 00 ff 96 65 d0 c1 5c c6 00 00 ff ff 00 ff 96 66 50 c1 5c c6 00 00 ff ff 00 ff 96 66 d0 c1 5c c6 00 00 ff ff 00 ff 96 67 50 c1 5c c6 00 00 ff ff 00 ff 96 67 d0 c1 5c c6 00 00 ff ff 00 ff 96 64 50 c1 5c c6 00 00 ff ff 00 ff 96 64 d0 c1 5c c6 00 00 ff ff 00 ff 96 65 50 c1 5c c6 00 00 ... Which camera is this? Is it the Aiptek Pencam VGA+? If so, then I can try it, too, because I also have one of them. Yes, that's the one. Try your others if you can and let me know what happens. Only those 3 bits change, and it looks like a counter to me. Take a look at the gspca-mars (MR97113A?) subdriver. I think it tries to accommodate the frame sequence number when looking for the SOF. No, I don't see that, sorry. What I see is that it looks for the SOF, which is declared in pac_common.h to be the well-known FF FF 00 FF 96 and no more bytes after that. I'm talking about this code from gspca/mars.c. Look in sd_pkt_scan(). if (data[0 + p] == 0xff data[1 + p] == 0xff data[2 + p] == 0x00 data[3 + p] == 0xff data[4 + p] == 0x96) { if (data[5 + p] == 0x64 || data[5 + p] == 0x65 || data[5 + p] == 0x66 || data[5 + p] == 0x67) { -Kyle -- To unsubscribe from
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote: On Thu, 16 Apr 2009, Kyle Guinn wrote: On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote: Hello Theodore kilg...@banach.math.auburn.edu wrote: Also, after the byte indicator for the compression algorithm there are some more bytes, and these almost definitely contain information which could be valuable while doing image processing on the output. If they are already kept and passed out of the module over to libv4lconvert, then it would be very easy to do something with those bytes if it is ever figured out precisely what they mean. But if it is not done now it would have to be done then and would cause even more trouble. I sent it already in private mail to you. Here is the observation I made for the PAC207 SOF some years ago: From usb snoop. FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (center) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (edge) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Thomas I've been looking through the frame headers sent by the MR97310A (the Aiptek PenCam VGA+, 08ca:0111). Here are my observations. FF FF 00 FF 96 6x x0 xx xx xx xx xx In binary that looks something like this: 10010110 011001aa a101 All of the values look to be MSbit first. A looks like a 3-bit frame sequence number that seems to start with 1 and increments for each frame. Hmmm. This I never noticed. What you are saying is that the two bytes 6x and x0 are variable? You are sure about that? What I have previously experienced is that the first is always 64 with these cameras, and the second one indicates the absence of compression (in which case it is 0, which of course only arises for still cameras), or if there is data compression then it is not zero. I have never seen this byte to change during a session with a camera. Here is a little table of what I have previously witnessed, and perhaps you can suggest what to do in order to see this is not happening: Camerathat byte compression solved, or not streaming Aiptek00 no N/A no Aiptek50 yes yes both the Sakar cam 00 no N/A no ditto 50 yes yes both Argus QuikClix20 yes no doesn't work Argus DC1620 50 yes yes doesn't work CIF cameras 00 no N/A no ditto 50 yes yes no ditto d0 yes no yes Other strange facts are -- that the Sakar camera, the Argus QuikClix, and the DC1620 all share the same USB ID of 0x93a:0x010f and yet only one of them will stream with the existing driver. The other two go through the motions, but the isoc packets do not actually get sent, so there is no image coming out. I do not understand the reason for this; I have been trying to figure it out and it is rather weird. I should add that, yes, those two cameras were said to be capable of streaming when I bought them. Could it be a problem of age? I don't expect that, but maybe. -- the CIF cameras all share the USB id of 0x93a:0x010e (I bought several of them) and they all are using a different compression algorithm while streaming from what they use if running as still cameras in compressed mode. This leads to the question whether it is possible to set the compression algorithm during the initialization sequence, so that the camera also uses the 0x50 mode while streaming, because we already know how to use that mode. But I have never seen the 0x64 0xX0 bytes used to count the frames. Could you tell me how to repeat that? It certainly would knock down the validity of the above table wouldn't it? I've modified libv4l to print out the 12-byte header before it skips over it. Then when I fire up mplayer it prints out each header as each frame is received. The framerate is only about 5 fps so there isn't a ton of data to parse through. When I point the camera into a light I
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote: Hello Theodore kilg...@banach.math.auburn.edu wrote: Also, after the byte indicator for the compression algorithm there are some more bytes, and these almost definitely contain information which could be valuable while doing image processing on the output. If they are already kept and passed out of the module over to libv4lconvert, then it would be very easy to do something with those bytes if it is ever figured out precisely what they mean. But if it is not done now it would have to be done then and would cause even more trouble. I sent it already in private mail to you. Here is the observation I made for the PAC207 SOF some years ago: From usb snoop. FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (center) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (edge) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Thomas I've been looking through the frame headers sent by the MR97310A (the Aiptek PenCam VGA+, 08ca:0111). Here are my observations. FF FF 00 FF 96 6x x0 xx xx xx xx xx In binary that looks something like this: 10010110 011001aa a101 All of the values look to be MSbit first. A looks like a 3-bit frame sequence number that seems to start with 1 and increments for each frame. B, C, and D might be brightness and contrast; minimum and maximum values for these vary with the image size. For 640x480, 320x240, and 160x120: dark scene (all black): B: near 0 C: 0x000 D: 0xC60 bright scene (all white): B: usually 0xC15C C: 0xC60 D: 0x000 For 352x288 and 176x144: dark scene (all black): B: near 0 C: 0x000 D: 0xB5B bright scene (all white): B: usually 0xB0FE C: 0xB53 D: 0x007 B increases with increasing brightness. C increases with more white pixels and D increases with more black pixels. A gray image has C and D near zero, while a high-contrast image (half black, half white) has C and D around 0x600 or so. The sum of C and D is not a constant. I don't know how brightness and contrast are handled in V4L. Hopefully someone can put this to use. -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Thursday 05 March 2009 14:58:54 kilg...@banach.math.auburn.edu wrote: Well, here is the code in the function. I don't see. So can you explain? Perhaps I am dense. { struct sd *sd = (struct sd *) gspca_dev; int i; /* Search for the SOF marker (fixed part) in the header */ for (i = 0; i len; i++) { if (m[i] == pac_sof_marker[sd-sof_read]) { sd-sof_read++; if (sd-sof_read == sizeof(pac_sof_marker)) { PDEBUG(D_FRAM, SOF found, bytes to analyze: %u. Frame starts at byte #%u, len, i + 1); sd-sof_read = 0; return m + i + 1; } } else { sd-sof_read = 0; } } return NULL; } We send a chunk of data to this function, as pointed to by m. It could be the entire transfer buffer or only a part of it, but that doesn't matter. If the chunk of data ends with FF FF 00 then sd-sof_read will be set to 3 when the function exits. On the next call it picks up where it left off and looks for byte 4 of the SOF. Way back when, I said to copy sd-sof_read bytes from pac_sof_marker if you want the portion of the SOF that was in the previous transfer. There's no need to buffer 4 bytes from the previous transfer because the SOF is _constant_. So, if it's constant, why do we need to copy it to userspace at all? If we do, then every frame buffer begins with a constant, useless FF FF 00 FF 96. The reassurance doesn't matter because the frame _must_ have started with FF FF 00 FF 96 to get there in the first place. I agree with Hans that it isn't necessary, and by not sending it to userspace we simplify the kernel driver. But what if it's not constant? Maybe the SOF is 4 bytes and the 5th byte is some useful data that, 99.9% of the time, is set to 96? This is the only reason I see for keeping the SOF. -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] for the file gspca/mr97310a.c
On Thursday 05 March 2009 20:34:27 kilg...@banach.math.auburn.edu wrote: Signed-off-by: Theodore Kilgore kilg...@auburn.edu -- --- mr97310a.c.old2009-02-23 23:59:07.0 -0600 +++ mr97310a.c2009-03-05 19:14:13.0 -0600 @@ -29,9 +29,7 @@ MODULE_LICENSE(GPL); /* specific webcam descriptor */ struct sd { struct gspca_dev gspca_dev; /* !! must be the first item */ - u8 sof_read; - u8 header_read; }; /* V4L2 controls supported by the driver */ @@ -100,12 +98,9 @@ static int sd_init(struct gspca_dev *gsp static int sd_start(struct gspca_dev *gspca_dev) { - struct sd *sd = (struct sd *) gspca_dev; __u8 *data = gspca_dev-usb_buf; int err_code; - sd-sof_read = 0; - Good catch, I didn't realize this was kzalloc'd. /* Note: register descriptions guessed from MR97113A driver */ data[0] = 0x01; @@ -285,40 +280,29 @@ static void sd_pkt_scan(struct gspca_dev __u8 *data, /* isoc packet */ int len) /* iso packet length */ { - struct sd *sd = (struct sd *) gspca_dev; unsigned char *sof; sof = pac_find_sof(gspca_dev, data, len); if (sof) { int n; - + int marker_len = sizeof pac_sof_marker; The value doesn't change; there's no need to use a variable for this. /* finish decoding current frame */ n = sof - data; - if (n sizeof pac_sof_marker) - n -= sizeof pac_sof_marker; + if (n marker_len) + n -= marker_len; else n = 0; frame = gspca_frame_add(gspca_dev, LAST_PACKET, frame, data, n); - sd-header_read = 0; - gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0); - len -= sof - data; + /* Start next frame. */ + gspca_frame_add(gspca_dev, FIRST_PACKET, frame, + pac_sof_marker, marker_len); + len -= n; + len -= marker_len; + if (len 0) + len = 0; len -= sof - data; is a shorter way to find the remaining length. data = sof; } - if (sd-header_read 7) { - int needed; - - /* skip the rest of the header */ - needed = 7 - sd-header_read; - if (len = needed) { - sd-header_read += len; - return; - } - data += needed; - len -= needed; - sd-header_read = 7; - } - gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len); } @@ -337,6 +321,7 @@ static const struct sd_desc sd_desc = { /* -- module initialisation -- */ static const __devinitdata struct usb_device_id device_table[] = { {USB_DEVICE(0x08ca, 0x0111)}, + {USB_DEVICE(0x093a, 0x010f)}, This change is unrelated; maybe it should be in a different patch? Don't forget to update Documentation/video4linux/gspca.txt with the new camera. -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Wednesday 04 March 2009 02:39:11 Hans de Goede wrote: Which also makes me wonder about the same change for the mr97310a, is that cam already supported in a released kernel ? If not we MUST make sure we get this change in before 2.6.29 final, if it is I'm afraid we cannot make these changes. In that case if we ever need to header data we need to define a new PIXFMT for mr97310a with the header data, and deprecate the old one. I don't believe the driver has made it to any kernel yet. Even if it has, the user would need to have an unreleased version of libv4l. I think this change would inconvenience me and Theodore at most. Let's change it now. -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu wrote: On Wed, 4 Mar 2009, Kyle Guinn wrote: On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote: contents of file mr97310a.patch follow, for gspca/mr97310a.c --- mr97310a.c.old 2009-02-23 23:59:07.0 -0600 +++ mr97310a.c.new 2009-03-03 17:19:06.0 -0600 @@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev data, n); sd-header_read = 0; gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0); - len -= sof - data; - data = sof; - } - if (sd-header_read 7) { - int needed; - - /* skip the rest of the header */ - needed = 7 - sd-header_read; - if (len = needed) { - sd-header_read += len; - return; - } - data += needed; - len -= needed; - sd-header_read = 7; + /* keep the header, including sof marker, for coming frame */ + len -= n; + data = sof - sizeof pac_sof_marker;; } gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len); A few notes: 1. There is an extra semicolon on that last added line. Oops. My bifocals. 2. sd-header_read no longer seems necessary. This is very likely true. 3. If the SOF marker is split over two transfers then everything falls apart. Are you sure about that? Simple example: One transfer ends with FF FF 00 and the next begins with FF 96 64. pac_find_sof() returns a pointer to 64, n is set to 0, len stays the same, data now points at 3 bytes _before_ the transfer buffer, and we will most likely get undefined behavior when trying to copy the data out of the transfer buffer. Not only that, but the FF FF 00 portion of the SOF won't get copied to the frame buffer. Since we know what the SOF looks like, we don't need to worry about losing the FF FF 00 portion -- just copy sd-sof_read bytes from pac_sof_marker. Unfortunately my brain is fried right now and I can't come up with a working example. I don't know if the camera will allow that to happen, but it's better to be safe. Agreed. Note that this was a RFC. So if it is agreed that something needs to be done, probably things should be put into a more formal patch structure. Also I have a question of my own while thinking about this. It relates not to the module but to the decompression code. What do we have over there? Well, void v4lconvert_decode_mr97310a(const unsigned char *inp, unsigned char *outp, int width, int height) and then in my patch it does /* remove the header */ inp += 12; Perhaps this is not good, and what ought to be done instead is to pass off the inp to an internal variable, and then increase it, instead. Possibly an even better alternative exists. The easiest way, I think, would be to take the two previous lines back out again, but instead go back to the function static inline unsigned char get_byte(const unsigned char *inp, unsigned int bitpos) { const unsigned char *addr; addr = inp + (bitpos 3); return (addr[0] (bitpos 7)) | (addr[1] (8 - (bitpos 7))); } and put the 12-byte shift into the line which computes addr, like this: addr = inp + 12 + (bitpos 3); Let's not overcomplicate things. I think inp += 12 with a comment is fine for now since we haven't completely reverse engineered the header yet. Use one function to parse through the header, then use a different one to handle the frame decompression. The header parser will call the correct decompressor function with the correct offset into the frame buffer. or if one really wants to get fancy about it then give a #define MR97310a_HEADERSIZE 12 at the top of the file and then one could say addr = inp + (bitpos 3) + MR97310a_HEADERSIZE; I don't think we know this for sure yet. Maybe the header length is variable and is specified along with the compression code? As I said, if doing any of these then one would leave strictly alone the decoding function and any of its contents. I am not sure if messing with the start of the inp variable is a good idea. Frankly, I do not know enough details to be certain. But on second look my instincts are against screwing with something like that. The thing that worries me is that what exactly happens to those 12 bytes. Do they disappear down a black hole, or what? For, in the end they will have to be deallocated somewhere. And what then? The alternative which I give above would do what is needed and also does not mess with the start location of inp. inp is a local variable, so changing it inside the decompressor function will have no affect
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote: Hans, Jean-Francois, and Kyle, The proposed patches are not very long, so I will give each of them, with my comments after each, to explain why I believe that these changes are a good idea. First, the patch to libv4lconvert is short and sweet: contents of file mr97310av4l.patch follow -- --- mr97310a.c.old2009-03-01 15:37:38.0 -0600 +++ mr97310a.c.new2009-02-18 22:39:48.0 -0600 @@ -102,6 +102,9 @@ void v4lconvert_decode_mr97310a(const un if (!decoder_initialized) init_mr97310a_decoder(); + /* remove the header */ + inp += 12; + bitpos = 0; /* main decoding loop */ - here ends the v4lconvert patch -- The reason I want to do this should be obvious. It is to preserve the entire header of each frame over in the gspca driver, and to throw it away over here. The SOF marker FF FF 00 FF 96 is also kept. The reason why all of this should be kept is that it makes it possible to look at a raw output and to know if it is exactly aligned or not. Furthermore, the next byte after the 96 is a code for the compression algorithm used, and the bytes after that in the header might be useful in the future for better image processing. In other words, these headers contain information which might be useful in the future and they should not be jettisoned in the kernel module. No complaints here. I copied off of the pac207 driver, thinking that one compression format == one pixel format and that all mr97310a cameras use the same compression. I was hesitant to say that the mr97310a pixel format can correspond to multiple compression formats, especially since I only have one such camera and I don't know if it's preferred to use multiple pixel formats for this reason. From what I understand, sending the frame header to userspace solves at least two problems (if indeed the compression is specified in the header): * One frame may be compressed and the next frame isn't, or the next frame uses a different compression. * Two cameras with the same vendor/product ID use different compression formats. Distinguishing the two cameras in the kernel driver could be messy. Just a random thought, but maybe the pac207 driver can benefit from such a change as well? -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MR97310A and other image formats
On Tuesday 17 February 2009 13:09:28 Jean-Francois Moine wrote: Hi Kyle, Looking at the v4l library from Hans de Goede, I did not find the decoding of the MR97310A images. May you send him a patch for that? Yes, I sent this to him some time ago. Take a look here: http://linuxtv.org/hg/~hgoede/v4l-dvb/rev/a647c2dfa989 -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v2] gspca: Add MR97310A driver
On Friday 16 January 2009 02:47:31 Jean-Francois Moine wrote: On Thu, 15 Jan 2009 22:36:49 -0600 Kyle Guinn ely...@gmail.com wrote: This patch adds support for USB webcams based on the MR97310A chip. It was tested with an Aiptek PenCam VGA+ webcam. Hi Kyle, I added your driver to my repository. I just found a little bug. At line 250/251 data[8] = 0x01; err_code = reg_w(gspca_dev, 10); you set 9 values and you output 10 values. Good catch. Yes, that should be 9. Also that data[8] should be set to 0x00. I must have been asleep at the keyboard :) I'll send a patch. BTW, as many of these USB control messages are constant, you should better use static data or a table format (byte count, values)*. I'll look into this. Those may not all be costants, I believe the camera supports gamma adjustment and autoexposure and maybe some other controls. I plan on gathering some traces to figure that out next week. Regards, -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Add Mars-Semi MR97310A format
On Thursday 15 January 2009 05:49:46 Jean-Francois Moine wrote: On Wed, 14 Jan 2009 20:59:34 -0600 Kyle Guinn ely...@gmail.com wrote: Add a pixel format for the Mars-Semi MR97310A webcam controller. The MR97310A is a dual-mode webcam controller that provides compressed BGGR Bayer frames. The decompression algorithm for still images is the same as for video, and is currently implemented in libgphoto2. Hi Kyle, What is the difference of this pixel format from the other Bayer ones? This is a standard BGGR Bayer format which is compressed using a vendor-specific compression algorithm, much like V4L2_PIX_FMT_PAC207. I don't believe the compression algorithm matches any of the other pixel formats. The first two pixels in the first two rows are stored as raw 8-bit values (the top-left BGGR square), but the rest is Huffman compressed. Take a look at precalc_table() and mars_decompress() in libgphoto2/camlibs/mars/mars.c for all of the details. If you recognize this as an existing pixel format, please let me know. Also, did you ask Hans de Goede to add the decoding to the v4l library? That is next on my TODO list. I have a patch ready to send, but I first want to make sure there are no problems with adding this pixel format. Regards, -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html