Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi Theodore It looks like I'll have to keep checking eBay for cheap USB v3 (HD) webcams periodically. Which somebody will need to support because they will probably not work out of the box with an OEM driver CD ;-) Ah yes, there is that aspect to think about before making a purchase :-). Actually, I think Linus will be pretty keen to rush support for USB v3 webcams into the kernel. Hopefully it won't take too long for a few cheapies to work in Linux. Some of the cheap cameras do work pretty well, actually. But as far as I know any resolution better than 640*480 seems to be pretty unusual. Lots of interpolated higher resolution meaning they have inflated the pictures, of course. But some of the 640x480 cameras do better than others. And also I should point out that if 4 fps is OK with you then some of the cameras do not even do compression. If you could get hold of an old SQ905 camera that will do 640x480 it runs on bulk transport and there is no compression of frame data at all. Also, what is interesting is that with all the cheap cameras they cut corners, of course. But the SQ905 cameras always seemed to me to tend to have better optics than a lot of the other cheap cams. Where they really cut down on features was with the controller chip. It will do practically nothing compared to some others. The SQ905 used to be advertised as the cheapest camera controller chip on the market, once upon a time. But the images one gets from those cameras sometimes are not half bad. Thanks for letting me know about that model. I think I'll be able to stay with my SN9C201 for now, especially since I've started using Motion's auto-brightness setting. It almost seemed like the sun was in the room with me last night :-). Also I should mention that if one wants to get better images out then it is best somehow to capture and save the raw data and process it later. This is true for any camera which either produces an uncompressed bitmap raw image, and also for any camera which does compression of said bitmap image before sending it down to the computer. Everything but JPEG, pretty much. Why is this? Because the image processing used with webcams must necessarily have speed as the number one priority, else the frame rate suffers severely. If one is not thus constrained, it is possible to do a much better job with that raw data. But remember that you can maximize image quality, or you can maximize frame rate. Choose one of the two. Yeah, I had a feeling that would be the case. The following is an extract from Motion's configuration file. If I want to maximise quality, which of these options do you think I should choose? As you can see, I've been using the default one (8) lately. # v4l2_palette allows to choose preferable palette to be use by motion # to capture from those supported by your videodevice. (default: 8) # E.g. if your videodevice supports both V4L2_PIX_FMT_SBGGR8 and # V4L2_PIX_FMT_MJPEG then motion will by default use V4L2_PIX_FMT_MJPEG. # Setting v4l2_palette to 1 forces motion to use V4L2_PIX_FMT_SBGGR8 # instead. # # Values : # V4L2_PIX_FMT_SN9C10X : 0 'S910' # V4L2_PIX_FMT_SBGGR8 : 1 'BA81' # V4L2_PIX_FMT_MJPEG : 2 'MJPEG' # V4L2_PIX_FMT_JPEG: 3 'JPEG' # V4L2_PIX_FMT_RGB24 : 4 'RGB3' # V4L2_PIX_FMT_UYVY: 5 'UYVY' # V4L2_PIX_FMT_YUYV: 6 'YUYV' # V4L2_PIX_FMT_YUV422P : 7 '422P' # V4L2_PIX_FMT_YUV420 : 8 'YU12' ; v4l2_palette 8 -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Wed, 7 Mar 2012 09:59:28 +1100 Xavion xavio...@gmail.com wrote: root@Desktop /etc/motion # tail /var/log/kernel.log Mar 6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC data error: [0] len=0, status=-18 ... Hmm, error -18 is EXDEV, which according to Documentation/usb/error-codes.txt is: -EXDEV ISO transfer only partially completed (only set in iso_frame_desc[n].status, not urb-status) I've seen those before, and I think we should simply ignore them rather then log an error for them. Jean-Francois, what do you think? I'll let you guys decide what to do about this, but remember that I'm here to help if you need more testing done. If you want my opinion, I'd be leaning towards trying to prevent any errors that appear regularly. Hi, It seems that the webcams handled by the driver sn9c20x work the same as the ones handled by sonixj. In this last driver, I adjust the JPEG compression to avoid the errors USB FIFO full, and I think that these errors also raise the URB error -18 with the sn9c20x. I will need some time to put a same code into the sn9c20x, then I'd be glad to have it tested. There was an other problem in the driver sonixj: the end of frame marker was not always at the right place. Xavion, as you have ms-windows, may you do some USB traces with this system? I need a capture sequence of about 15 seconds (not more) with big luminosity changes. This isn't even the proper SXGA resolution, which is supposed to be 1280x1024. The Sonix website claims that their SN9C201 webcam can provide up to a 1.3 MP (SXGA) video size! Do you happen to know of any inexpensive webcams that are capable of true SXGA in Linux? `-- lsusb | grep Cam Bus 001 Device 006: ID 0c45:627b Microdia PC Camera (SN9C201 + OV7660) The sensor ov7660 can do VGA only (640x480). Otherwise, I uploaded a new gspca test version (2.15.3) with the JPEG compression control (default 80%). May you try it? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi Theodore As to getting that kind of resolution out of a webcam, though, it would be a rather tough go due to the amount of data which has to pass over the wire even if it is compressed data. The frame rate would be pretty atrocious. Therefore, you are probably not going to see that kind of resolution in an inexpensive webcam, at least until USB 3 comes into common use. Thanks for offering your thoughts on this matter. It looks like I'll have to keep checking eBay for cheap USB v3 (HD) webcams periodically. For the record, I've only got Motion set to capture four frames per second at the moment. Perhaps for now if you want that kind of resolution and do not care about the frame rate very much, you would be better off to buy a slightly fancier camera and do something like using gphoto2 to take timed shots. I prefer the idea of captured motion to that of timed snapshots. The captured images and videos are automatically uploaded to my Dropbox account. As I'm only a 'free' user, I must limit the storage space that these files consume. -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi Jean-Francois It seems that the webcams handled by the driver sn9c20x work the same as the ones handled by sonixj. In this last driver, I adjust the JPEG compression to avoid the errors USB FIFO full, and I think that these errors also raise the URB error -18 with the sn9c20x. I will need some time to put a same code into the sn9c20x, then I'd be glad to have it tested. There was an other problem in the driver sonixj: the end of frame marker was not always at the right place. Xavion, as you have ms-windows, may you do some USB traces with this system? I need a capture sequence of about 15 seconds (not more) with big luminosity changes. I've never needed to capture USB data manually until now, so I'm not sure of which (free) Windows application I should use. I'm assuming that a software-only analyser would be good enough to provide the information you're wanting. I'm guessing that continuously blocking and unblocking the webcam's vision will suffice for big luminosity changes. Let me know if that's not going to cut it and I'll repeatedly toggle the switch for the ceiling light in my lounge-room (at night) instead. I just tried to get the data using three different USB packet sniffers. The unfortunate results on my 32-bit Windows XP laptop are listed below. BTW, what size should the log-file have been after capturing the fifteen seconds you're wanting? * BusDog: Couldn't find the webcam device * SniffUSB: The log file was 100+ MiB in size * SnoopyPro: Couldn't capture any packets The sensor ov7660 can do VGA only (640x480). Otherwise, I uploaded a new gspca test version (2.15.3) with the JPEG compression control (default 80%). May you try it? I've downloaded and tested GSPCA v2.15.3. I'm sorry to nitpick, but you still had 2.15.1 listed near the top of the gspca.h file. I'm also sorry to report that GSPCA v2.15.3 caused the following fatal errors with my SN9C201 webcam: `-- tail /var/log/kernel.log Mar 8 10:21:09 Desktop kernel: [13758.712077] usb 1-5.5: new high-speed USB device number 10 using ehci_hcd Mar 8 10:21:09 Desktop kernel: [13758.852838] Linux media interface: v0.10 Mar 8 10:21:09 Desktop kernel: [13758.857354] Linux video capture interface: v2.00 Mar 8 10:21:09 Desktop kernel: [13758.858018] gspca_main: v2.15.3 registered Mar 8 10:21:09 Desktop kernel: [13758.858357] gspca_main: gspca_sn9c20x-2.15.3 probing 0c45:627b Mar 8 10:21:09 Desktop kernel: [13758.886556] gspca_sn9c20x: OV7660 sensor detected Mar 8 10:21:09 Desktop kernel: [13758.886647] input: gspca_sn9c20x as /devices/pci:00/:00:1d.7/usb1/1-5/1-5.5/input/input16 Mar 8 10:21:09 Desktop kernel: [13758.886791] gspca_main: video0 created Mar 8 10:21:09 Desktop kernel: [13758.886823] usbcore: registered new interface driver gspca_sn9c20x Mar 8 10:22:04 Desktop kernel: [13813.347291] gspca_sn9c20x: Set 640x480 `-- tail /var/log/errors.log Mar 8 10:24:09 Desktop motion: [1] Error starting stream VIDIOC_STREAMON: Input/output error Mar 8 10:24:09 Desktop motion: [1] ioctl (VIDIOCGCAP): Inappropriate ioctl for device Mar 8 10:24:09 Desktop motion: [1] Could not fetch initial image from camera Mar 8 10:24:09 Desktop motion: [1] Motion continues using width and height from config file(s) Mar 8 10:24:10 Desktop motion: [1] Retrying until successful connection with camera Mar 8 10:24:10 Desktop motion: [1] Error requesting buffers 4 for memory map. VIDIOC_REQBUFS: Device or resource busy Mar 8 10:24:10 Desktop motion: [1] ioctl (VIDIOCGCAP): Inappropriate ioctl for device Mar 8 10:24:20 Desktop motion: [1] Retrying until successful connection with camera Mar 8 10:24:20 Desktop motion: [1] Error requesting buffers 4 for memory map. VIDIOC_REQBUFS: Device or resource busy Mar 8 10:24:20 Desktop motion: [1] ioctl (VIDIOCGCAP): Inappropriate ioctl for device -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Thu, 8 Mar 2012, Xavion wrote: Hi Theodore As to getting that kind of resolution out of a webcam, though, it would be a rather tough go due to the amount of data which has to pass over the wire even if it is compressed data. The frame rate would be pretty atrocious. Therefore, you are probably not going to see that kind of resolution in an inexpensive webcam, at least until USB 3 comes into common use. Thanks for offering your thoughts on this matter. You are welcome. It looks like I'll have to keep checking eBay for cheap USB v3 (HD) webcams periodically. Which somebody will need to support because they will probably not work out of the box with an OEM driver CD ;-) For the record, I've only got Motion set to capture four frames per second at the moment. Perhaps for now if you want that kind of resolution and do not care about the frame rate very much, you would be better off to buy a slightly fancier camera and do something like using gphoto2 to take timed shots. I prefer the idea of captured motion to that of timed snapshots. The captured images and videos are automatically uploaded to my Dropbox account. As I'm only a 'free' user, I must limit the storage space that these files consume. Some of the cheap cameras do work pretty well, actually. But as far as I know any resolution better than 640*480 seems to be pretty unusual. Lots of interpolated higher resolution meaning they have inflated the pictures, of course. But some of the 640x480 cameras do better than others. And also I should point out that if 4 fps is OK with you then some of the cameras do not even do compression. If you could get hold of an old SQ905 camera that will do 640x480 it runs on bulk transport and there is no compression of frame data at all. Also, what is interesting is that with all the cheap cameras they cut corners, of course. But the SQ905 cameras always seemed to me to tend to have better optics than a lot of the other cheap cams. Where they really cut down on features was with the controller chip. It will do practically nothing compared to some others. The SQ905 used to be advertised as the cheapest camera controller chip on the market, once upon a time. But the images one gets from those cameras sometimes are not half bad. Also I should mention that if one wants to get better images out then it is best somehow to capture and save the raw data and process it later. This is true for any camera which either produces an uncompressed bitmap raw image, and also for any camera which does compression of said bitmap image before sending it down to the computer. Everything but JPEG, pretty much. Why is this? Because the image processing used with webcams must necessarily have speed as the number one priority, else the frame rate suffers severely. If one is not thus constrained, it is possible to do a much better job with that raw data. But remember that you can maximize image quality, or you can maximize frame rate. Choose one of the two. Theodore Kilgore -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi, On 03/06/2012 01:44 AM, Xavion wrote: Hi Guys Thanks very much for the follow-up emails. Our time-zone differences prevented me from replying sooner. I'm guessing you guys are both in Europe, whereas I'm down and across in Australia. As I plan to use this webcam for home security, I would prefer to keep the JPEG quality at or above 90% if possible. This is because it'd be difficult enough to see a burglar's face clearly at 640x480 with lossless quality. The good news is that the nasty errors I was getting yesterday have magically disappeared overnight! That is likely because the scene you're pointing at (or the lighting conditions) have changed, not all pictures compress equally well with JPEG. If you point the camera at the same scene as when you were getting these errors (with similar, good, lighting conditions) you'll likely see those errors re-surface. All I'm seeing today (at 90% and 75% quality) is what look to be non-fatal errors, since Motion seems to work correctly. root@Desktop /etc/motion # tail /var/log/kernel.log Mar 6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:34:17 Desktop kernel: [ 7240.125172] gspca_main: ISOC data error: [1] len=0, status=-18 Mar 6 08:36:40 Desktop kernel: [ 7382.545241] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:36:40 Desktop kernel: [ 7382.545246] gspca_main: ISOC data error: [1] len=0, status=-18 Mar 6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480 Mar 6 08:40:12 Desktop kernel: [ 7594.685124] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:40:12 Desktop kernel: [ 7594.685129] gspca_main: ISOC data error: [1] len=0, status=-18 Mar 6 08:42:37 Desktop kernel: [ 7739.715758] gspca_sn9c20x: Set 640x480 Mar 6 08:46:06 Desktop kernel: [ 7948.598533] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:46:06 Desktop kernel: [ 7948.598538] gspca_main: ISOC data error: [1] len=0, status=-18 Hmm, error -18 is EXDEV, which according to Documentation/usb/error-codes.txt is: -EXDEV ISO transfer only partially completed (only set in iso_frame_desc[n].status, not urb-status) I've seen those before, and I think we should simply ignore them rather then log an error for them. Jean-Francois, what do you think? In fairness to Motion, the default JPEG quality listed in its configuration file is only 75%. I had upped this to 90% for clarity, but subsequently reverting to the default configuration file didn't stop these errors. That is a different JPG setting, that is the compression quality for the JPEG's motion saves to disk if it detects motion. We're are talking about the compression quality of the JPEG's going over the USB wire, which is controller by the driver, not by motion. They also remained after I increased the three vga_mode ratios to 6 / 8 or changed Line 2093 of sn9c20x.c to sd-quality = 75;. You mean the -18 error remain, right, that is expected, the ratios / sd-quality only fix the errors you were seeing previously. Entering either of the following commands before starting Motion didn't make any difference either. export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so The other thing I'm wondering about is how to force SXGA (1280x1024) mode to be used. I've set the 'width' and 'height' variables in the Motion configuration file correctly, but I still see the following kernel output: Mar 6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480 I should note that Motion defaults to V4L2_PIX_FMT_YUV420 in its configuration file, which is what I'd been using until now. From the look of the code in the sn9c20x.c file, I must use V4L2_PIX_FMT_SBGGR8 to get the 1280x1024 resolution. For sxga mode you will need to use libv4l, but I doubt if your camera supports it at all, most don't. What does dmesg say immediately after unplugging and replugging the camera? Regards, Hans -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi Hans The good news is that the nasty errors I was getting yesterday have magically disappeared overnight! That is likely because the scene you're pointing at (or the lighting conditions) have changed, not all pictures compress equally well with JPEG. If you point the camera at the same scene as when you were getting these errors (with similar, good, lighting conditions) you'll likely see those errors re-surface. At the time, I thought it was probably just because I hadn't rebooted my computer after installing GSPCA v2.15.1 the previous day. If those nastier errors resurface, I'll test whether they can be suppressed by making those changes to sn9c20x.c again. root@Desktop /etc/motion # tail /var/log/kernel.log Mar 6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC data error: [0] len=0, status=-18 ... Hmm, error -18 is EXDEV, which according to Documentation/usb/error-codes.txt is: -EXDEV ISO transfer only partially completed (only set in iso_frame_desc[n].status, not urb-status) I've seen those before, and I think we should simply ignore them rather then log an error for them. Jean-Francois, what do you think? I'll let you guys decide what to do about this, but remember that I'm here to help if you need more testing done. If you want my opinion, I'd be leaning towards trying to prevent any errors that appear regularly. In fairness to Motion, the default JPEG quality listed in its configuration file is only 75%. I had upped this to 90% for clarity, but subsequently reverting to the default configuration file didn't stop these errors. That is a different JPG setting, that is the compression quality for the JPEG's motion saves to disk if it detects motion. We're are talking about the compression quality of the JPEG's going over the USB wire, which is controller by the driver, not by motion. I thought that was probably the case, but I left open the possibility that Motion could've been telling GSPCA what JPEG setting to use for USB transfers. They also remained after I increased the three vga_mode ratios to 6 / 8 or changed Line 2093 of sn9c20x.c to sd-quality = 75;. You mean the -18 error remain, right, that is expected, the ratios / sd-quality only fix the errors you were seeing previously. Yes, I was only seeing the -18 error message yesterday. I knew that the vga_mode and sd-quality suggestions were intended for the other (nastier) errors. As I couldn't be sure that the -18 error wasn't somehow related, I decided to test those suggestions on it as well. Entering either of the following commands before starting Motion didn't make any difference either. export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so The other thing I'm wondering about is how to force SXGA (1280x1024) mode to be used. I've set the 'width' and 'height' variables in the Motion configuration file correctly, but I still see the following kernel output: Mar 6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480 I should note that Motion defaults to V4L2_PIX_FMT_YUV420 in its configuration file, which is what I'd been using until now. From the look of the code in the sn9c20x.c file, I must use V4L2_PIX_FMT_SBGGR8 to get the 1280x1024 resolution. For sxga mode you will need to use libv4l, but I doubt if your camera supports it at all, most don't. What does dmesg say immediately after unplugging and replugging the camera? The software I use to control my webcam in Windows can increase the snapshot zoom to what it calls 'SXGA'. Closer inspection reveals that it's actually just doubling the 640x480 image - via nearest-neighbour interpolation - to get a rather pixelated 1280x960. This isn't even the proper SXGA resolution, which is supposed to be 1280x1024. The Sonix website claims that their SN9C201 webcam can provide up to a 1.3 MP (SXGA) video size! Do you happen to know of any inexpensive webcams that are capable of true SXGA in Linux? `-- lsusb | grep Cam Bus 001 Device 006: ID 0c45:627b Microdia PC Camera (SN9C201 + OV7660) `-- dmesg ... [ 5155.396674] usb 5-5.5: USB disconnect, device number 5 [ 5155.396835] gspca_main: video0 disconnect [ 5155.440019] gspca_main: video0 released [ 5159.946302] usb 5-5.5: new high-speed USB device number 6 using ehci_hcd [ 5160.045863] gspca_main: sn9c20x-2.15.1 probing 0c45:627b [ 5160.071035] gspca_sn9c20x: OV7660 sensor detected [ 5160.071146] input: sn9c20x as /devices/pci:00/:00:1d.7/usb5/5-5/5-5.5/input/input8 [ 5160.071277] gspca_main: video0 created As mentioned above, I had already tried exporting LD_PRELOAD for both V4L v1 and v2 beforehand. Furthermore, the two V4L2_PIX_FMT_... Motion settings I've used both begin with V4L2. Let me know if there's anything else I should do to ensure that Motion is using V4L. -- To unsubscribe
Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Wed, 7 Mar 2012, Xavion wrote: Hi Hans The good news is that the nasty errors I was getting yesterday have magically disappeared overnight! That is likely because the scene you're pointing at (or the lighting conditions) have changed, not all pictures compress equally well with JPEG. If you point the camera at the same scene as when you were getting these errors (with similar, good, lighting conditions) you'll likely see those errors re-surface. At the time, I thought it was probably just because I hadn't rebooted my computer after installing GSPCA v2.15.1 the previous day. If those nastier errors resurface, I'll test whether they can be suppressed by making those changes to sn9c20x.c again. root@Desktop /etc/motion # tail /var/log/kernel.log Mar 6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC data error: [0] len=0, status=-18 ... Hmm, error -18 is EXDEV, which according to Documentation/usb/error-codes.txt is: -EXDEV ISO transfer only partially completed (only set in iso_frame_desc[n].status, not urb-status) I've seen those before, and I think we should simply ignore them rather then log an error for them. Jean-Francois, what do you think? I'll let you guys decide what to do about this, but remember that I'm here to help if you need more testing done. If you want my opinion, I'd be leaning towards trying to prevent any errors that appear regularly. In fairness to Motion, the default JPEG quality listed in its configuration file is only 75%. I had upped this to 90% for clarity, but subsequently reverting to the default configuration file didn't stop these errors. That is a different JPG setting, that is the compression quality for the JPEG's motion saves to disk if it detects motion. We're are talking about the compression quality of the JPEG's going over the USB wire, which is controller by the driver, not by motion. I thought that was probably the case, but I left open the possibility that Motion could've been telling GSPCA what JPEG setting to use for USB transfers. They also remained after I increased the three vga_mode ratios to 6 / 8 or changed Line 2093 of sn9c20x.c to sd-quality = 75;. You mean the -18 error remain, right, that is expected, the ratios / sd-quality only fix the errors you were seeing previously. Yes, I was only seeing the -18 error message yesterday. I knew that the vga_mode and sd-quality suggestions were intended for the other (nastier) errors. As I couldn't be sure that the -18 error wasn't somehow related, I decided to test those suggestions on it as well. Entering either of the following commands before starting Motion didn't make any difference either. export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so The other thing I'm wondering about is how to force SXGA (1280x1024) mode to be used. I've set the 'width' and 'height' variables in the Motion configuration file correctly, but I still see the following kernel output: Mar 6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480 I should note that Motion defaults to V4L2_PIX_FMT_YUV420 in its configuration file, which is what I'd been using until now. From the look of the code in the sn9c20x.c file, I must use V4L2_PIX_FMT_SBGGR8 to get the 1280x1024 resolution. For sxga mode you will need to use libv4l, but I doubt if your camera supports it at all, most don't. What does dmesg say immediately after unplugging and replugging the camera? The software I use to control my webcam in Windows can increase the snapshot zoom to what it calls 'SXGA'. Closer inspection reveals that it's actually just doubling the 640x480 image - via nearest-neighbour interpolation - to get a rather pixelated 1280x960. This kind of fudging is, unfortunately, very typical. Lots of cameras on the market have things like that written on the package. If there is any residual truth in what is written there at all, it says something like Interpolated XxY resolution which is a mealy-mouthed admission of that kind of resolution-inflation when you see it. But sometimes they just plain lie. This isn't even the proper SXGA resolution, which is supposed to be 1280x1024. The Sonix website claims that their SN9C201 webcam can provide up to a 1.3 MP (SXGA) video size! Too typical. Do you happen to know of any inexpensive webcams that are capable of true SXGA in Linux? Unfortunately, not. But I could not resist pointing out that the kind of hype that you have described is all too typical of the marketing for such merchandise. As to getting that kind of resolution out of a webcam, though, it would be a rather tough go due to the amount of data which has to pass over the wire even if it is compressed data. The frame rate would be pretty atrocious.
Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi, On 03/04/2012 10:58 PM, Xavion wrote: Hi Jean-Francois I can confirm that GSPCA v2.15.1 removes the bad pixels when I use Cheese or VLC. However, I'm sorry to report that the Motion problems unfortunately still remain. Is there something else I must do to overcome the below errors? I'm happy to keep testing newer GSPCA versions for you until we get this fixed. I guess that motion is using the JPG compressed frames rather then the i420 like special format these cameras also support, and it looks like we don't reserve enoug space to buffer these frames. To fix this we need to enlarge the size we reserve per frame in the sn9c20x driver, edit sn9c20x.c and search for vga_mode, in that table you will find a factor 4 / 8 (its in there 3 times), change all 3 occurences to 5 / 8 and try again, then 6 / 8, etc. Normally I would be suspicious about SOF / EOF detection when we need such a factor, but the timestamps in your log exactly match 30 fps, so that seems to be fine. And in my experience with the USB bandwidth stuff the sn9c20x does seem to compress less then other JPG cams, so it makes sense that it needs bigger buffers to store the frames too. Alternatively you can try if motion can be made to use a different format then JPG, by forcing it to use libv4l by starting it like this: LD_PRELOAD=/usr/lib/libv4l/v4l1-compat.so motion Note if you're on a rpm based 64 bit distro and motion is 64 bit too that should be: LD_PRELOAD=/usr/lib64/libv4l/v4l1-compat.so motion But that would just be working around the issue, it is better to fix the issue with using the JPG mode of the camera instead. Regards, Hans `-- tail /var/log/kernel.log Mar 5 08:25:52 Desktop kernel: [ 6673.781987] gspca_main: frame overflow 156309 155648 Mar 5 08:25:52 Desktop kernel: [ 6673.813992] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.849986] gspca_main: frame overflow 155693 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.881989] gspca_main: frame overflow 156021 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.917991] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.949993] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.985990] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6674.021981] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6674.053985] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6674.089989] gspca_main: frame overflow 156309 155648 `-- tail /var/log/errors.log Mar 5 08:24:16 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument Mar 5 08:24:16 Desktop motion: [1] Video device fatal error - Closing video device Mar 5 08:24:20 Desktop motion: [1] Retrying until successful connection with camera Mar 5 08:24:27 Desktop motion: [1] v4l2_next: VIDIOC_DQBUF: EIO (s-pframe 3): Input/output error Mar 5 08:24:27 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument Mar 5 08:24:27 Desktop motion: [1] Video device fatal error - Closing video device Mar 5 08:24:30 Desktop motion: [1] Retrying until successful connection with camera Mar 5 08:24:33 Desktop motion: [1] v4l2_next: VIDIOC_DQBUF: EIO (s-pframe 0): Input/output error Mar 5 08:24:33 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument Mar 5 08:24:33 Desktop motion: [1] Video device fatal error - Closing video device -- 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 -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Mon, 05 Mar 2012 09:33:18 +0100 Hans de Goede hdego...@redhat.com wrote: I guess that motion is using the JPG compressed frames rather then the i420 like special format these cameras also support, and it looks like we don't reserve enoug space to buffer these frames. To fix this we need to enlarge the size we reserve per frame in the sn9c20x driver, edit sn9c20x.c and search for vga_mode, in that table you will find a factor 4 / 8 (its in there 3 times), change all 3 occurences to 5 / 8 and try again, then 6 / 8, etc. Normally I would be suspicious about SOF / EOF detection when we need such a factor, but the timestamps in your log exactly match 30 fps, so that seems to be fine. And in my experience with the USB bandwidth stuff the sn9c20x does seem to compress less then other JPG cams, so it makes sense that it needs bigger buffers to store the frames too. Hi Hans, The JPEG compression quality of the sn9c20x is 95%. That's why the frames are so big. Then, if the quality is not settable, I wonder why to use the JPEG format. BTW, I wonder also about the SN9C20X_I420: this format asks for a buffer greater than the native image. So, as these webcams are USB 2.0, shouldn't it be simpler to have only Bayer in the driver? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi, On 03/05/2012 01:03 PM, Jean-Francois Moine wrote: On Mon, 05 Mar 2012 09:33:18 +0100 Hans de Goedehdego...@redhat.com wrote: I guess that motion is using the JPG compressed frames rather then the i420 like special format these cameras also support, and it looks like we don't reserve enoug space to buffer these frames. To fix this we need to enlarge the size we reserve per frame in the sn9c20x driver, edit sn9c20x.c and search for vga_mode, in that table you will find a factor 4 / 8 (its in there 3 times), change all 3 occurences to 5 / 8 and try again, then 6 / 8, etc. Normally I would be suspicious about SOF / EOF detection when we need such a factor, but the timestamps in your log exactly match 30 fps, so that seems to be fine. And in my experience with the USB bandwidth stuff the sn9c20x does seem to compress less then other JPG cams, so it makes sense that it needs bigger buffers to store the frames too. Hi Hans, The JPEG compression quality of the sn9c20x is 95%. That's why the frames are so big. Then, if the quality is not settable, I wonder why to use the JPEG format. I think the quality is settable, and we are just not setting it to a very useful value. I'm afraid I don't have time to work on this atm, but if you are willing to take a shot at this, then I can test (I've such a camera). I'll send you a private mail with info on how to set the compression ratio. BTW, I wonder also about the SN9C20X_I420: this format asks for a buffer greater than the native image. Yes, but then the data is ready to use, since most apps actuall want i420, where as raw bayer needs a lot of CPU intensive processing before we get useful data out of it. Regards, Hans -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Mon, 5 Mar 2012 08:58:30 +1100 Xavion xavio...@gmail.com wrote: I can confirm that GSPCA v2.15.1 removes the bad pixels when I use Cheese or VLC. However, I'm sorry to report that the Motion problems unfortunately still remain. Is there something else I must do to overcome the below errors? I'm happy to keep testing newer GSPCA versions for you until we get this fixed. Hi again, I looked at the driver again, and thanks to Hans, I found you could easily lower the JPEG compression quality and stop buffer overflow. At line 2093 of build/sn9c20x.c (gspca test), there is: sd-quality = 95; Changing '95' to '80' should be enough. I will add this parameter as a video control as soon as it will be standard. Then you could adjust it with an external program as v4l2ucp. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi Guys Thanks very much for the follow-up emails. Our time-zone differences prevented me from replying sooner. I'm guessing you guys are both in Europe, whereas I'm down and across in Australia. As I plan to use this webcam for home security, I would prefer to keep the JPEG quality at or above 90% if possible. This is because it'd be difficult enough to see a burglar's face clearly at 640x480 with lossless quality. The good news is that the nasty errors I was getting yesterday have magically disappeared overnight! All I'm seeing today (at 90% and 75% quality) is what look to be non-fatal errors, since Motion seems to work correctly. root@Desktop /etc/motion # tail /var/log/kernel.log Mar 6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:34:17 Desktop kernel: [ 7240.125172] gspca_main: ISOC data error: [1] len=0, status=-18 Mar 6 08:36:40 Desktop kernel: [ 7382.545241] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:36:40 Desktop kernel: [ 7382.545246] gspca_main: ISOC data error: [1] len=0, status=-18 Mar 6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480 Mar 6 08:40:12 Desktop kernel: [ 7594.685124] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:40:12 Desktop kernel: [ 7594.685129] gspca_main: ISOC data error: [1] len=0, status=-18 Mar 6 08:42:37 Desktop kernel: [ 7739.715758] gspca_sn9c20x: Set 640x480 Mar 6 08:46:06 Desktop kernel: [ 7948.598533] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:46:06 Desktop kernel: [ 7948.598538] gspca_main: ISOC data error: [1] len=0, status=-18 In fairness to Motion, the default JPEG quality listed in its configuration file is only 75%. I had upped this to 90% for clarity, but subsequently reverting to the default configuration file didn't stop these errors. They also remained after I increased the three vga_mode ratios to 6 / 8 or changed Line 2093 of sn9c20x.c to sd-quality = 75;. Entering either of the following commands before starting Motion didn't make any difference either. export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so The other thing I'm wondering about is how to force SXGA (1280x1024) mode to be used. I've set the 'width' and 'height' variables in the Motion configuration file correctly, but I still see the following kernel output: Mar 6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480 I should note that Motion defaults to V4L2_PIX_FMT_YUV420 in its configuration file, which is what I'd been using until now. From the look of the code in the sn9c20x.c file, I must use V4L2_PIX_FMT_SBGGR8 to get the 1280x1024 resolution. After making this change, I still saw Set 640x480 in the kernel output. How can the above errors be overcome and how can I force SXGA mode to be used by my applications? Thanks again for all of the assistance you've given me so far. -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi Jean-Francois I can confirm that GSPCA v2.15.1 removes the bad pixels when I use Cheese or VLC. However, I'm sorry to report that the Motion problems unfortunately still remain. Is there something else I must do to overcome the below errors? I'm happy to keep testing newer GSPCA versions for you until we get this fixed. `-- tail /var/log/kernel.log Mar 5 08:25:52 Desktop kernel: [ 6673.781987] gspca_main: frame overflow 156309 155648 Mar 5 08:25:52 Desktop kernel: [ 6673.813992] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.849986] gspca_main: frame overflow 155693 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.881989] gspca_main: frame overflow 156021 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.917991] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.949993] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.985990] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6674.021981] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6674.053985] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6674.089989] gspca_main: frame overflow 156309 155648 `-- tail /var/log/errors.log Mar 5 08:24:16 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument Mar 5 08:24:16 Desktop motion: [1] Video device fatal error - Closing video device Mar 5 08:24:20 Desktop motion: [1] Retrying until successful connection with camera Mar 5 08:24:27 Desktop motion: [1] v4l2_next: VIDIOC_DQBUF: EIO (s-pframe 3): Input/output error Mar 5 08:24:27 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument Mar 5 08:24:27 Desktop motion: [1] Video device fatal error - Closing video device Mar 5 08:24:30 Desktop motion: [1] Retrying until successful connection with camera Mar 5 08:24:33 Desktop motion: [1] v4l2_next: VIDIOC_DQBUF: EIO (s-pframe 0): Input/output error Mar 5 08:24:33 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument Mar 5 08:24:33 Desktop motion: [1] Video device fatal error - Closing video device -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi Hans Thanks for letting me know that this problem will be fixed in Linux v3.3. It could be several weeks before my distribution releases that kernel. Dropping back to Linux v3.1 isn't an option, as my NVIDIA driver requires Linux v3.2. Can the fix for this problem also be applied to Linux v3.2.x manually? If so, please email me the corresponding patch file and I'll test it here. -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Sun, 4 Mar 2012 11:25:19 +1100 Xavion xavio...@gmail.com wrote: Thanks for letting me know that this problem will be fixed in Linux v3.3. It could be several weeks before my distribution releases that kernel. Dropping back to Linux v3.1 isn't an option, as my NVIDIA driver requires Linux v3.2. Can the fix for this problem also be applied to Linux v3.2.x manually? If so, please email me the corresponding patch file and I'll test it here. Hi, You may take the gspca test version from my site: it is smaller. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi, On 03/03/2012 01:23 AM, Xavion wrote: My Microdia (SN9C201) webcam was working in Linux, but it has been failing lately. Take a look at the attached snapshot to see what I mean. It's like that all the time in Linux these days, but it works perfectly in Windows. Thanks for the picture that truely says more then a 1000 words (Dutch proverb), the problem is that the new bandwidth allocation code added to gspca in 3.2 does not allocate enough bandwidth for the sn9c20x. 3.3 has a fix for this. Regards, Hans -- 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
