Re: [Linux-uvc-devel] Philips SPZ2000/00 reprise - slightly OT
On 05/12/11 21:38, Michele wrote: I've made some tests on this camera and I've had some mixed results. [/snip] I've writtent this to warn other linux users tha this is a bad camera anyway and one mustn't be fooled by the Philips brand on it, has absolutely nothing to do with the company that made the BM7502 monitor and the VG8020 computer. This type of thing happens. Just on a loosely related note, PC World in UK sold throughout 2006 and 2007 a line of 3-4 laptops and several desktops computers branded as Philips. It turns out that the desktops were made by an Irish company called iQon and the laptops were actually rebranded Twinhead models. I've worked on several of these laptops and they weren't of bad quality actually. The really frustrating thing was that Philips offered zero support (although they were sold under their name), and the same went for the actual hardware manufacturers. The support was left to a subsidiary/partner company of PC World called The Tech Guys, and it was dreadful. The laptops specially had absolutely no hint of the real manufacturer anywhere on them. For the laptop I was working on - The Tech Guys even posted the wrong motherboard chipset drivers. It took me 16 hours of research in all to realise that the drivers were wrong and it wasn't me doing anything wrong, and to finally discover that Twinhead were selling in Australia an identical laptop under their own name. After that it was all plain sailing. Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quirk for mjpeg bandwidth
On 31/10/11 23:14, Sebastian Arcus wrote: I seem to recall some discussion about a hack/patch/quirk to get several of the newer HD cameras to work in mjpg mode on a single usb hub/bus. Does anybody know if this has made it into the uvc driver, and if yes, after which version. Just to clarify, I am after the patch which tries to overcome the cameras requesting too much bandwidth in mjpeg mode - not regular yuyv. I believe some of the original discussion referred to a Logitech C910. I need to run four MS Lifecam Studio's on the same usb root hub in 800x600 / 10fps mode - if possible. I believe there should be enough bandwidth - if I can just convince the cameras and the uvc driver to play together somehow. Many thanks in anticipation, Sebastian Bump. Anybody? It would be really nice if there was a quirk which just allowed the specification of a fixed bandwidth at user's choice, on loading the kernel module. Thus, one could find out through trial and error, by using different numbers, what bandwidth can be used with a certain camera model, at a certain resolution and fps - on mjpeg. I suspect this would break the standard, but there seems to be no other way to make an increasing number of really good quality HD cameras work on multiple camera setups - although the numbers indicate there should be enough bandwidth to make even 4 of them work at the same time, on same usb root hub, in mjpeg streaming mode. Any contributions much appreciated. Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] MS LifeCam Cinema and Studio have no usb bandwidth issue under Windows
On 02/11/11 17:38, Laurent Pinchart wrote: Hi Sebastian, On Friday 07 October 2011 14:00:03 Sebastian Arcus wrote: On 07/10/11 10:42, Alexey Fisher wrote: Am 07.10.2011 10:59, schrieb Sebastian Arcus: On 06/10/11 17:28, Alexey Fisher wrote: On 06.10.2011 18:16, Sebastian Arcus wrote: On 06/10/11 15:59, Alexey Fisher wrote: On 06.10.2011 14:32, Sebastian Arcus wrote: Hello list, The above two cameras, which have the well known usb bandwidth bug under Linux don't seem to display the same problems under Windows. I've tried them under Windows Vista and Windows 7 32bit. I've managed to display a LifeCam Studio and LifeCam Cinema at the same time through separate instances of VLC all the way to 1920x1080 for LifeCam Studio and 1280x720 for the LifeCam Cinema - which I believe are the maximum video resolutions for both cameras. I've forced VLC on 25fps - and the Cinema seems to do that. However, looking at the footage from the Studio at maximum resolution - it looks more like 5fps. However, what all the above means is that these cameras don't seem to suffer from the usb bandwidth bug under Windows. I've input mjpg under chroma settings for VLC - but I can't find a way to tell for sure if VLC is using the mjpeg stream from the camera, or raw. Can someone here help me push this further? Is there any way of debugging what is happening under Windows - so that maybe the Linux uvc driver can be modified to get these cameras to work properly? Probably usb sniffing will be most correct option, but currently i'll would not interpret usb dump. Other option is visual test: - Jpeg stream has lower quality, try it under linux and you will see the difference. - according to frame rate the webcam controller will change demosaicing algorithm. Simple alorithm produce pure qualithy, and image looks like up scaled image from smaller image. Logitech webcams use better algorithm before 15 fps and pure after 15 fps. - you can check frame rate by capturing some timer with milliseconds: http://tools.arantius.com/stopwatch Thank you Alexey. Looking at the quality of the footage - I would guess it is not mjpeg. However, it still means that the camera is not grabbing all the available usb bandwidth like it does under Linux - which is good news. Then try bandwidth quirk: sudo rmmod sudo modprobe uvcvideo quirks=0x80 But reduce frame rate, 1280x720 at 30 fps will take complete bindwidth, try 10fps if you wont to use two webcams. Anybody knows if I can use VLC or some other software under windows to view the mjpeg stream? I could then test how many cameras I can use at the same time under Windows with mjpeg. This should tell us if the Windows driver doesn't have any of the usb bandwidth problems which exist under Linux for these cameras. It is not a driver problem, the webcam tell how match it need, the driver will give it. If cam tell it need every thing we have, the driver will give it. It is defined behavior of UVC, if device is broken, there is nothing driver can do. I will not wonder if Microsoft will have quirks for devices it produce. For some time i send here some jpeg patches, you can test it on your own risk and force the bandwidth. But this patches will probably never go to upstream. Thanks Alexey. What I was suggesting is that, under Windows, the camera doesn't seem to suffer from this bug - as it is possible to run two of them at the same time. I don't know how this is accomplished, I don't know if the Windows driver makes use of special signalling to stop the camera from asking for all the available usb bandwidth. I was only thinking that if it would be possible to find out how the camera is convinced to not asked for full bandwidth under Windows - maybe that can be replicated in the uvc driver under Linux. I don't think Windows tells the camera to use less bandwidth. I obviously can't tell for sure what the Windows driver does, but I expected it to either - use heuristics to compute the amount of bandwidth a webcam really requires - have device-specific quirks (quite unlikely though, unless the webcam comes with its specific driver) - allow allocation of more than 80% of the USB bandwidth to periodic USB transfers If I'm not mistaken Linux recently got support for the third option, maybe this could help you. Details can be found on the linux-usb mailing list AFAIR. Another option would be to snoop USB transfers in Windows to find out how much bandwidth the webcam requests and how much bandwidth Windows allocates. Thanks for your reply Laurent. I will look for that modification you mentioned on the mailing list and see if I can get more then one camera working. Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quirk for mjpeg bandwidth
On 02/11/11 18:17, Philip Gladstone wrote: On 11/2/2011 12:19 PM, Andrew Burgess wrote: i looked at this for similar reasons as you a few months ago. as i recall, there was just one line to change to essentially disable the bandwidth limitations, just changing the calculated bandwidth to always be one (or something like that). my requirements changed and i never got as far as testing it with multiple cameras. if you can make this change and collect data about how well your system then works you might have a better chance to get some sort of sysfs control to disable bandwidth checks into mainstream. I have been running 3 Logitech C910s simultaneously capturing full resolution (5MP) video at the slowest rate (5 FPS) with one of the patch sets. It has been stable for me. Philip Hi Philip, Could I be a pain and ask for a link to the thread about the patch, or to the patch itself please. Thank you, Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] Quirk for mjpeg bandwidth
I seem to recall some discussion about a hack/patch/quirk to get several of the newer HD cameras to work in mjpg mode on a single usb hub/bus. Does anybody know if this has made it into the uvc driver, and if yes, after which version. Just to clarify, I am after the patch which tries to overcome the cameras requesting too much bandwidth in mjpeg mode - not regular yuyv. I believe some of the original discussion referred to a Logitech C910. I need to run four MS Lifecam Studio's on the same usb root hub in 800x600 / 10fps mode - if possible. I believe there should be enough bandwidth - if I can just convince the cameras and the uvc driver to play together somehow. Many thanks in anticipation, Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] Mark Microsoft LifeCam Studio as having the usb bandwidth bug
Hello all, Would it be possible to add the corresponding note next to the Microsoft LifeCam Studio in the supported devices list on the Linux uvc website (http://www.ideasonboard.org/uvc/), so that people will know that it has the same usb bandwidth bug as the Microsoft LifeCam Cinema, please. Thank you, Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] MS LifeCam Cinema and Studio have no usb bandwidth issue under Windows
On 06/10/11 17:28, Alexey Fisher wrote: On 06.10.2011 18:16, Sebastian Arcus wrote: On 06/10/11 15:59, Alexey Fisher wrote: On 06.10.2011 14:32, Sebastian Arcus wrote: Hello list, The above two cameras, which have the well known usb bandwidth bug under Linux don't seem to display the same problems under Windows. I've tried them under Windows Vista and Windows 7 32bit. I've managed to display a LifeCam Studio and LifeCam Cinema at the same time through separate instances of VLC all the way to 1920x1080 for LifeCam Studio and 1280x720 for the LifeCam Cinema - which I believe are the maximum video resolutions for both cameras. I've forced VLC on 25fps - and the Cinema seems to do that. However, looking at the footage from the Studio at maximum resolution - it looks more like 5fps. However, what all the above means is that these cameras don't seem to suffer from the usb bandwidth bug under Windows. I've input mjpg under chroma settings for VLC - but I can't find a way to tell for sure if VLC is using the mjpeg stream from the camera, or raw. Can someone here help me push this further? Is there any way of debugging what is happening under Windows - so that maybe the Linux uvc driver can be modified to get these cameras to work properly? Any suggestions much appreciated. Sebastian Hi Sebastian, Probably usb sniffing will be most correct option, but currently i'll would not interpret usb dump. Other option is visual test: - Jpeg stream has lower quality, try it under linux and you will see the difference. - according to frame rate the webcam controller will change demosaicing algorithm. Simple alorithm produce pure qualithy, and image looks like up scaled image from smaller image. Logitech webcams use better algorithm before 15 fps and pure after 15 fps. - you can check frame rate by capturing some timer with milliseconds: http://tools.arantius.com/stopwatch Thank you Alexey. Looking at the quality of the footage - I would guess it is not mjpeg. However, it still means that the camera is not grabbing all the available usb bandwidth like it does under Linux - which is good news. Sebastian Then try bandwidth quirk: sudo rmmod sudo modprobe uvcvideo quirks=0x80 But reduce frame rate, 1280x720 at 30 fps will take complete bindwidth, try 10fps if you wont to use two webcams. Thanks Alexey. Anybody knows if I can use VLC or some other software under windows to view the mjpeg stream? I could then test how many cameras I can use at the same time under Windows with mjpeg. This should tell us if the Windows driver doesn't have any of the usb bandwidth problems which exist under Linux for these cameras. Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] MS LifeCam Cinema and Studio have no usb bandwidth issue under Windows
On 07/10/11 10:42, Alexey Fisher wrote: Am 07.10.2011 10:59, schrieb Sebastian Arcus: On 06/10/11 17:28, Alexey Fisher wrote: On 06.10.2011 18:16, Sebastian Arcus wrote: On 06/10/11 15:59, Alexey Fisher wrote: On 06.10.2011 14:32, Sebastian Arcus wrote: Hello list, The above two cameras, which have the well known usb bandwidth bug under Linux don't seem to display the same problems under Windows. I've tried them under Windows Vista and Windows 7 32bit. I've managed to display a LifeCam Studio and LifeCam Cinema at the same time through separate instances of VLC all the way to 1920x1080 for LifeCam Studio and 1280x720 for the LifeCam Cinema - which I believe are the maximum video resolutions for both cameras. I've forced VLC on 25fps - and the Cinema seems to do that. However, looking at the footage from the Studio at maximum resolution - it looks more like 5fps. However, what all the above means is that these cameras don't seem to suffer from the usb bandwidth bug under Windows. I've input mjpg under chroma settings for VLC - but I can't find a way to tell for sure if VLC is using the mjpeg stream from the camera, or raw. Can someone here help me push this further? Is there any way of debugging what is happening under Windows - so that maybe the Linux uvc driver can be modified to get these cameras to work properly? Any suggestions much appreciated. Sebastian Hi Sebastian, Probably usb sniffing will be most correct option, but currently i'll would not interpret usb dump. Other option is visual test: - Jpeg stream has lower quality, try it under linux and you will see the difference. - according to frame rate the webcam controller will change demosaicing algorithm. Simple alorithm produce pure qualithy, and image looks like up scaled image from smaller image. Logitech webcams use better algorithm before 15 fps and pure after 15 fps. - you can check frame rate by capturing some timer with milliseconds: http://tools.arantius.com/stopwatch Thank you Alexey. Looking at the quality of the footage - I would guess it is not mjpeg. However, it still means that the camera is not grabbing all the available usb bandwidth like it does under Linux - which is good news. Sebastian Then try bandwidth quirk: sudo rmmod sudo modprobe uvcvideo quirks=0x80 But reduce frame rate, 1280x720 at 30 fps will take complete bindwidth, try 10fps if you wont to use two webcams. Thanks Alexey. Anybody knows if I can use VLC or some other software under windows to view the mjpeg stream? I could then test how many cameras I can use at the same time under Windows with mjpeg. This should tell us if the Windows driver doesn't have any of the usb bandwidth problems which exist under Linux for these cameras. Sebastian It is not a driver problem, the webcam tell how match it need, the driver will give it. If cam tell it need every thing we have, the driver will give it. It is defined behavior of UVC, if device is broken, there is nothing driver can do. I will not wonder if Microsoft will have quirks for devices it produce. For some time i send here some jpeg patches, you can test it on your own risk and force the bandwidth. But this patches will probably never go to upstream. Thanks Alexey. What I was suggesting is that, under Windows, the camera doesn't seem to suffer from this bug - as it is possible to run two of them at the same time. I don't know how this is accomplished, I don't know if the Windows driver makes use of special signalling to stop the camera from asking for all the available usb bandwidth. I was only thinking that if it would be possible to find out how the camera is convinced to not asked for full bandwidth under Windows - maybe that can be replicated in the uvc driver under Linux. However, I know almost nothing about the intricacies of the uvc standard and the corresponding Linux (or Windows) implementation - that is why I was asking if there is anyway to probe the uvc driver in Windows and find out more that way. Many thanks, Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] MS LifeCam Cinema and Studio have no usb bandwidth issue under Windows
Hello list, The above two cameras, which have the well known usb bandwidth bug under Linux don't seem to display the same problems under Windows. I've tried them under Windows Vista and Windows 7 32bit. I've managed to display a LifeCam Studio and LifeCam Cinema at the same time through separate instances of VLC all the way to 1920x1080 for LifeCam Studio and 1280x720 for the LifeCam Cinema - which I believe are the maximum video resolutions for both cameras. I've forced VLC on 25fps - and the Cinema seems to do that. However, looking at the footage from the Studio at maximum resolution - it looks more like 5fps. However, what all the above means is that these cameras don't seem to suffer from the usb bandwidth bug under Windows. I've input mjpg under chroma settings for VLC - but I can't find a way to tell for sure if VLC is using the mjpeg stream from the camera, or raw. Can someone here help me push this further? Is there any way of debugging what is happening under Windows - so that maybe the Linux uvc driver can be modified to get these cameras to work properly? Any suggestions much appreciated. Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] MS LifeCam Cinema and Studio have no usb bandwidth issue under Windows
On 06/10/11 15:59, Alexey Fisher wrote: On 06.10.2011 14:32, Sebastian Arcus wrote: Hello list, The above two cameras, which have the well known usb bandwidth bug under Linux don't seem to display the same problems under Windows. I've tried them under Windows Vista and Windows 7 32bit. I've managed to display a LifeCam Studio and LifeCam Cinema at the same time through separate instances of VLC all the way to 1920x1080 for LifeCam Studio and 1280x720 for the LifeCam Cinema - which I believe are the maximum video resolutions for both cameras. I've forced VLC on 25fps - and the Cinema seems to do that. However, looking at the footage from the Studio at maximum resolution - it looks more like 5fps. However, what all the above means is that these cameras don't seem to suffer from the usb bandwidth bug under Windows. I've input mjpg under chroma settings for VLC - but I can't find a way to tell for sure if VLC is using the mjpeg stream from the camera, or raw. Can someone here help me push this further? Is there any way of debugging what is happening under Windows - so that maybe the Linux uvc driver can be modified to get these cameras to work properly? Any suggestions much appreciated. Sebastian Hi Sebastian, Probably usb sniffing will be most correct option, but currently i'll would not interpret usb dump. Other option is visual test: - Jpeg stream has lower quality, try it under linux and you will see the difference. - according to frame rate the webcam controller will change demosaicing algorithm. Simple alorithm produce pure qualithy, and image looks like up scaled image from smaller image. Logitech webcams use better algorithm before 15 fps and pure after 15 fps. - you can check frame rate by capturing some timer with milliseconds: http://tools.arantius.com/stopwatch Thank you Alexey. Looking at the quality of the footage - I would guess it is not mjpeg. However, it still means that the camera is not grabbing all the available usb bandwidth like it does under Linux - which is good news. Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Microsoft LifeCam Studio and multiple webcam setups?
On 03/06/11 06:25, Duck Tayp wrote: I tried this with a Lifecam Studio and a Microsoft VX 6000 connected to the same USB hub and could view live video simultaneously from both. My impression of the Lifecam Studio: excellent video and audio quality (even in low light), and it just works (at least on the Ubuntu versions I've tried --- 10.10 and up). .de/mailman/listinfo/linux-uvc-devel /snip Just resurrecting this old thread which I've started a while ago. I am now the owner of 5 Microsoft LifeCam Studio webcams. Let me restate that - I am now the frustrated owner of 5 Microsoft LifeCam Studio webcams. The other reviews were right - the image quality of this webcam is absolutely excellent. However, I just can't get them working more then one at a time. I've just about managed to get one LifeCam Studio working together with an integrated laptop webcam. When I try to get two LifeCam Studio working together - I get the old no space left on device or device busy error message - depending on what software I'm using. I've tried VLC (with chroma=mjpeg and without it), 640x480 and 800x600 resolutions, and went all the way down to 1fps. I've tried mjpg_streamer. It all ends up the same. The newest kernel I've tried is 2.6.39. To me, it looks like this camera suffers from the same bug as Microsoft LifeCam Cinema. 1. Could anybody here having a LifeCam Studio (more then one would be even better) run again some tests and either confirm or disprove my findings. 2. Could someone suggest some thorough tests I could run - so that at least this camera gets marked on the list of supported devices as having a bug - like the LifeCam Cinema is flagged at the moment? It will at least save someone else buying a bucket load of them :-( Thank you for any suggestions. Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Microsoft LifeCam Studio and multiple webcam setups?
Thank you for the report. It seems that only the LifeCam Cinema had the usb bandwidth reservation bug then. Thanks again, Sebastian On 03/06/11 06:25, Duck Tayp wrote: I tried this with a Lifecam Studio and a Microsoft VX 6000 connected to the same USB hub and could view live video simultaneously from both. My impression of the Lifecam Studio: excellent video and audio quality (even in low light), and it just works (at least on the Ubuntu versions I've tried --- 10.10 and up). On 05/20/2011 07:46 AM, Sebastian Arcus wrote: I really liked the Microsoft LifeCam Cinema webcam - but it had a bug (feature?) which requested all usb bandwidth so no other webcam could be used alongside it on the same usb root hub. Could someone here who has the new Microsoft LifeCam Studio please test and confirm if this new model also suffers from the same feature. Just plug another webcam alongside the LifeCam studio, and if you come up with various messages alongside no space left on device on Linux, or similar in Windows - and you can't use both at the same time - it means it has the same problem as the LifeCam Cinema. Also - any general impressions of this webcam would be welcome. Thank you in advance, Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Footage of objects in motion recorded from webcam is blurry
Hi, On 04/29/2011 09:56 AM, Laurent Pinchart wrote: Hi, On Wednesday 27 April 2011 10:42:14 Paulo Assis wrote: 1. Would this be fairly specific to the Logitech QuickCam 9000, or is a more generic issue with webcam sensors? Neither, you just need to lower exposure time. 2. Are other webcams better in this respect? I don't think so, you can control exposure quite easily with this cam. 3. Can I use any of the UVC features to tweak the driver parameters in order to force sharper images of objects on the move? Yes, just set exposure mode to manual, and tweak exposure absolute, also remember to disable exposure, auto priority. You should also use the highest fps possible (30 fps I think) 4. Is this to do with the auto-focus of the camera, and can I turn it off or peg it in software at a certain value, to improve things? Yes, use uvcdynctrl (command line) or guvcview (gtk) (guvcview --control_only will let you use your program along side it) As far as I know, auto-focus for the Logitech QuickCam Pro 9000 is implemented in software in the Windows driver. The camera has a manual focus control only. You can tune it with any V4L2 application that supports controls, such as uvcdynctrl, guvcview, v4l2-ctl, yavta, ... I've had a look and it indeed there is a focus control. Considering that by default it is set on 0 (and it was set on 0 during operation), does this mean that it is on auto? Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] Footage of objects in motion recorded from webcam is blurry
This might not be entirely related to the UVC driver, but there seems to be a great pool of knowledge about webcams here, so I appreciate any feedback on this. I am using some Logitech QuickCam Pro 9000 cameras for a cctv project. Footage recorded by the camera of people/objects on the move is generally blurry. If the movement is slow, the footage is sharper - but as soon as they move a little faster (people walking about) - the footage is really quite blurry until they stop - and then it is sharp again. It is worse in low light, but it is still quite bad even in day light. My questions are: 1. Would this be fairly specific to the Logitech QuickCam 9000, or is a more generic issue with webcam sensors? 2. Are other webcams better in this respect? 3. Can I use any of the UVC features to tweak the driver parameters in order to force sharper images of objects on the move? 4. Is this to do with the auto-focus of the camera, and can I turn it off or peg it in software at a certain value, to improve things? Any hints on this are greatly appreciated. Thank you, Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Footage of objects in motion recorded from webcam is blurry
On 04/27/2011 09:42 AM, Paulo Assis wrote: Hi, 1. Would this be fairly specific to the Logitech QuickCam 9000, or is a more generic issue with webcam sensors? Neither, you just need to lower exposure time. 2. Are other webcams better in this respect? I don't think so, you can control exposure quite easily with this cam. 3. Can I use any of the UVC features to tweak the driver parameters in order to force sharper images of objects on the move? Yes, just set exposure mode to manual, and tweak exposure absolute, also remember to disable exposure, auto priority. You should also use the highest fps possible (30 fps I think) 4. Is this to do with the auto-focus of the camera, and can I turn it off or peg it in software at a certain value, to improve things? Yes, use uvcdynctrl (command line) or guvcview (gtk) (guvcview --control_only will let you use your program along side it) Thanks Paulo - that is very helpful. I'll try it out and see how it works. Sebastian Regards, Paulo ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] How to 'quirk' more than 3 same YUYV streaming web-cams
On 03/31/2011 12:04 PM, Клиентский отдел \Кибернет\ wrote: Thanks to all for your answers. Current disposition: Gentoo linux: 2.6.36-r8 (kernel uvcvideo driver). I'm testing 2.6.37.5-zen patched kernel (zen-kernel.org). It slightly reduce total cpu utilisation. But in embedded usb-bus and uvc drivers I found no changes. Yesterday I installed ZoneMinder 1.24.3 (trunk). I'm loading uvcvideo as module with quirks=128. This is allow me to use 4 webcams A4Tech PK-836MJ on each usb-root hub with 352x288 YUYV 30FPS streaming at the same time. Have you considered using the mjpeg stream with mjpg_streamer (if the cameras support it)? I am currently streaming 6 cameras on an Atom D550 (more powerful then the 330) - with a pci usb card - at 640x480 - but only 5fps (I think I can increase the fps without too much trouble). I am also transcoding to mp4 using ffmpeg on the same machine - and I have spare processor left - on average using about 50%-60%. Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] How to 'quirk' more than 3 same YUYV streaming web-cams
On 03/29/2011 10:26 PM, Paul Jurczak wrote: /snip You could always install another PCI or PCI-e USB card - which will give you another 4-5 USB ports - but more importantly, another USB root hub, separate from the one on the motherboard. That's what I did to run 6 webcams at 640x480 (but using mjpeg stream, not yuyv). That is, of course, if you are using some sort of desktop motherboard, with a spare PCI or PCI-e slot. /snip Modern PC motherboard chipsets have dual EHCI controllers, giving you two independent high speed USB buses. Intel started doing it in 2006 or so. I don't know about other cases, but I use an Intel D510MO motherboard for my project (with an Atom D510 dual core with hyperthreading) - and it shows only one Linux Foundation 2.0 root hub. Also my laptop with an Intel U2500 processor shows only one Linux Foundation 2.0 root hub. So it seems there are still motherboards with only one USB 2.0 root hub. Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] How to 'quirk' more than 3 same YUYV streaming web-cams
Hi, On 03/29/2011 01:59 PM, Alexey Fisher wrote: /snip But I unable to attach more webcams. These cams have no mjpeg. Could anybody help me to apply quirks or recalculate bandwith to use more webcams. As I understood no space on left device message depends on i assume it mean your hard drive. uvcvideo do not have this kind of message. I believe no space left on device means that there isn't enough usb bandwidth for all cameras at selected resolution and framerate. Nothing to do with the hard-drive. total bandwith utilisation of my usb hub. There is no other root usb 2.0 hubs on my motherboard. You could always install another PCI or PCI-e USB card - which will give you another 4-5 USB ports - but more importantly, another USB root hub, separate from the one on the motherboard. That's what I did to run 6 webcams at 640x480 (but using mjpeg stream, not yuyv). That is, of course, if you are using some sort of desktop motherboard, with a spare PCI or PCI-e slot. /snip USB 2.0 theoretically can handle 480 Mbit/s. RAW yuyv (depends on resolution and frame rate) will need say: 640x480 at 30fps (16bpp) = 140 Mbit/s . So, theoretically you can use 3,4 cams. DO not forget a real usb bandwidth and uvc overhead. Don't forget that the 480Mbit/s is the theoretical maximum speed. In real life, depending on the quality of the controller and cables, the real, achievable, speed can very well be lower. Sebastian ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Maximising iram throughput?
On 09/13/2010 12:06 AM, Andrew Leech wrote: Ah whoops, yep I really though I picked a different email to reply to thanks for the heads up, I can ask the right lot now! Andrew -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Monday, 13 September 2010 8:52 AM To: linux-uvc-devel@lists.berlios.de Cc: Andrew Leech Subject: Re: [Linux-uvc-devel] Maximising iram throughput? Hi Andrew, On Friday 10 September 2010 08:14:30 Andrew Leech wrote: Hi all, Just wondering if anyone's found some tricks to speed up iram data throughput, specifically with dma transfers. Are you sure you've sent this mail to the right mailing list ? Thanks Laurent. I was lost there for a moment. I was scratching my head thinking I was even further behind technology then I thought I was :-) Sebastian My application is basically sending data (real time video) from the external static ram interface over USB. The catch is the data buffer sizes of the external data and the usb data need to be quite different so I've had to set up a double buffering arrangement, where I'm using the DMA to copy from external port to a large rolling buffer space in iram, and then on a separate dma channel copying the (smaller) chunks of data from the large buffer to my usb buffer/structs. The usb packets needs a header on each one, so I can't just give the usb a pointer to a location in the main buffer because it obviously won't have the header. The system is technically working, but I'm running very low on memory bus bandwidth. The main issue is coming from latency in the external interface, I currently have it running with a MPMCStaticWaitRd0 of 1 and have a couple of errors in transmission. The errors are completely gone if I up the WaitRd to 2 but then the dma from buffer to usb is not keeping up. The external ram interface is in 16 bit mode, and the write buffers (in MPMCStaticConfig) are disabled, I'm using interface strictly read only and enabling them slowed it down more. Both dma channels are running in burst mode (16 byte chunks). Clocks are all at csp default settings again, so mpmc, dma, ebi all at 90Mhz, core at 180Mhz. I've tried SYS_REGS-eshctrl_sup4 = 0; to enable high speed performance mode on EBI, but that doesn't really seem to help much, not that I expected it to really. I've also tried enabling instruction and data caches at start of main: // Set virtual address of MMU table cp15_set_vmmu_addr((void *) ISROM_MMU_TTB_BASE); cp15_set_mmu(1); cp15_set_icache(1); cp15_set_dcache(1); But I didn't notice any difference in application speed, can anyone confirm whether this is the correct way to enable the buffers? Although I guess these are buffers for the cpu, so wouldn't affect the dma anyway. Basically I'd really like to speed up the iram - iram dma transfer to allow more bus bandwidth / time to devote to external ram - iram dma channel so I can slow the mpmc WaitRd down a touch and still kepp up with the video stream. -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Running multiple webcams on the same hub
Hi, I've posted the stuff below a while ago - but I've just discovered I was actually replying privately to the original poster by mistake. So a bit late, but I will post it again to the list - just in case anybody is interested. On 09/08/2010 03:04 PM, Martin wrote: OK, so the current linux UVC driver doesn't support still image capture. What is needed to implement that? Is it just a case of programming in the data structures, or is there a lot more needed for decoding/converting a captured image and interfacing? Will a new /dev device need creating dedicated to still image capture?... How much interest is there for that? (Presumably there will be some so as to utilise HD webcams to their full resolution...) Regards, Martin On 30/08/10 12:30, Martin wrote: On 27/08/10 15:14, Martin wrote: The problem: From reading around this list and elsewhere, it appears that you simply cannot run more than one webcam video stream per USB root hub. I have managed to get 4 cameras working, at 10fps and 640x480 on one usb 2.0 controller. The only way I managed to achieve this was by using mjpeg capable cameras - and forcing the stream in mjpeg format directly from the webcam - not in raw video. Also, according to my experiments - it looks like the compression rate varies from camera to camera (probably a characteristic of the internal chipset) - which will affect the usb bandwidth used. I have 4 different mjpeg capable webcam models - I could run some measurements. VLC is capable of requesting mjpeg stream. FFmpeg was capable - but the syntax changed. However, it looks like it is possible to set the camera in mjpeg mode using v4l2-ctl first - which would open up the possibility of using other capture software which is not capable of requesting an mjpeg stream - I think. One more thing - avoid Microsoft LifeCam Cinema HD - it requests a constant amount of bandwidth - regardless of resolution or compression used - so that is a no go. Unless you modify the v4l2/uvc driver - to ignore the bandwidth requests from camera. Hope the above helps a bit, Sebastian When enabled for video streaming, the webcam reserves the full isochronous bandwidth needed to stream data at the selected resolution and framerate, regardless... [...] *A possible solution* ? Instead, could the UVC driver 'simulate' a reduced framerate by instead using the STILL_IMAGE_FRAME mode of the webcam and grab for itself a set number of images per second? Or even only when polled by a read from the user application? On *nix, everything is a file... Could the uvc driver accept reading of /dev/videoX by the command cp so that still image data is copied, formatted for a jpg or png? Could the quirks setting be abused to set the image grab rate? Or some other neater method? That still looks to be the best solution. The webcam is supposed to support still image capture, but how do I do that?! Is there a nice little snippet of C code that I can compile to grab a still image to a jpg or png? [...] Further details: I'm trying to use two webcams simultaneously: iManufacturer 1 Sweex iProduct2 WC060 Series HD Webcam On separate hubs, they work fine. On the same hub, the second one to start shows the error: Error starting stream VIDIOC_STREAMON: No space left on device. I've only got the one root hub on the system I want to use for the two webcams! Their descriptors show: bFrameIntervalType 2 dwFrameInterval( 0) 200 dwFrameInterval( 1) 400 Can I tweak the UVC driver to preferentially choose the slower frame rate available? Aside: The MJPG format doesn't seem to work, nor are any compression settings visible... Given a few hints or a patch, I can hack the kernel module to test :-) This is running on Gentoo, kernel 2.6.34 using the in-kernel uvc module. Any comment/ideas welcomed. Regards, Martin From lsusb -v (excerpt): VideoStreaming Interface Descriptor: bLength34 bDescriptorType36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 9 bmCapabilities 0x00 Still image unsupported wWidth 1600 wHeight 1200 dwMinBitRate 768000 dwMaxBitRate196608000 dwMaxVideoFrameBufferSize 384 dwDefaultFrameInterval200 bFrameIntervalType 2 dwFrameInterval( 0) 200 dwFrameInterval( 1) 400 VideoStreaming Interface Descriptor: bLength42 bDescriptorType36 bDescriptorSubtype 3 (STILL_IMAGE_FRAME) bEndpointAddress
Re: [Linux-uvc-devel] [Fwd: Re: Problem with DFM 21AUC03-ML]
Thank you. I also found this site where there is a patched uvcvideo
driver for the camera I have. However it seems to be based on an older
version of uvcvideo and so I get some error when I try to insert the
uvcvideo module with the latest version of uvcvideo:
[441559.508487] uvcvideo: disagrees about version of symbol
v4l_compat_translate_ioctl
[441559.508497] uvcvideo: Unknown symbol v4l_compat_translate_ioctl
[441559.509189] uvcvideo: disagrees about version of symbol video_devdata
[441559.509192] uvcvideo: Unknown symbol video_devdata
[441559.510182] uvcvideo: disagrees about version of symbol
video_unregister_device
[441559.510186] uvcvideo: Unknown symbol video_unregister_device
[441559.510516] uvcvideo: disagrees about version of symbol video_device_alloc
[441559.510519] uvcvideo: Unknown symbol video_device_alloc
[441559.510744] uvcvideo: disagrees about version of symbol
video_register_device
[441559.510747] uvcvideo: Unknown symbol video_register_device
[441559.511368] uvcvideo: disagrees about version of symbol video_usercopy
[441559.511371] uvcvideo: Unknown symbol video_usercopy
[441559.511468] uvcvideo: disagrees about version of symbol video_device_release
[441559.511471] uvcvideo: Unknown symbol video_device_release
I will look in to it on a different computer that has no uvcvideo yet.
http://unicap-imaging.org/blog/index.php?/archives/22-Software-updates-for-The-Imaging-Source-CMOS-cameras.html
Thank you
Basti
2009/3/10 Paulo Assis pj.as...@gmail.com:
If the data is in bayer mode you could have a look at guvcview code
(colorspaces.c) there you will find conversion functions for bayer to
yuv, just apply the appropriate function for decoding in uvcGrab
function at v4l2uvc.c.
Best regards,
Paulo
Sebastian Scherer escreveu:
Hi,
I tried a raw dump with luvcview -c. The resulting file is 744x480
big. With the following commands I can decode the image properly in
matlab:
fid = fopen('frame000.raw');
A=fread(fid,357120,'uchar');
Ares = reshape(A,744,480);
imshow(demosaic(uint8(Ares),'grbg'))
Is there a way I could hack the driver to produce the same result?
This would be much more convient (and efficient) to use the data in
some vision code I am writing. I tried changing
.name = YUV 4:2:2 (YUYV),
.guid = UVC_GUID_FORMAT_YUY2,
.fcc = V4L2_PIX_FMT_YUYV,
the fcc to
V4L2_PIX_FMT_SBGGR8 but that caused a segfault with luvcview. Is
there a way I could force it to use bayer?
Thank you
Sebastian
2009/3/9 Sebastian Scherer smash0190s...@gmail.com:
Hi,
Thank you so much for your help!
How do I capture raw frames?
What would it take to get the single frame capture implemented?
Another strange thing is that the camera also supports 60 frames per
second and it does not show up as a format. Could this be related to
the 372 size?
This is the output from guvcview --verbose:
guvcview 1.0.2
video_device: /dev/video0
vid_sleep: 0
resolution: 372 x 480
windowsize: 480 x 700
vert pane: 578
spin behavior: 0
mode: uyvy
fps: 1/30
Display Fps: 0
bpp: 0
hwaccel: 1
grabmethod: 1
avi_format: 2
sound: 0
sound Device: 2
sound samp rate: 0
sound Channels: 0
Sound Block Size: 1 seconds
Sound Format: 80
Sound bit Rate: 160 Kbps
Pan Step: 2 degrees
Tilt Step: 2 degrees
Video Filter Flags: 0
image inc: 0
profile(default):/home/ulb/default.gpfl
language catalog= dir:/usr/share/locale type�ػrï�...@�gtk20
lang:en_US.UTF-8 cat:guvcview.mo
uyvy: setting format to 1498831189
video device: /dev/video0
/dev/video0 - device 1
Init. DFx 21AUC03 (location: usb-:00:1a.7-2)
{ pixelformat = 'YUYV', description = 'YUV 4:2:2 (YUYV)' }
{ discrete: width = 372, height = 480 }
    Time interval between frame: 1/30,
{ discrete: width = 320, height = 480 }
    Time interval between frame: 1/30,
{ pixelformat = 'UYVY', description = 'YUV 4:2:2 (UYVY)' }
{ discrete: width = 372, height = 480 }
    Time interval between frame: 1/30,
{ discrete: width = 320, height = 480 }
    Time interval between frame: 1/30,
checking format: 1498831189
vid:199e
pid:8202
driver:uvcvideo
Controls:
control[0]: 0x980913 Â Gain, 16:1:64, default 16
control[1]: 0x9a0901 Â Exposure, Auto, 0:1:3, default 6
control[2]: 0x9a0902 Â Exposure (Absolute), 1:1:2550, default 127
resolutions of 2º format=2
frame rates of 1º resolution=1
Def. Res: 0 Â numb. fps:1
--- device #0
[ Default Input, Default Output ]
Name           = /dev/dsp
Host API Â Â Â Â Â Â Â Â = OSS
Max inputs = 16, Max outputs = 16
Def. low input latency  =   0.012
Def. low output latency  =   0.012
Def. high input latency  =   0.046
Def. high output latency = Â Â 0.046
Def. sample rate     = 44100.00
--- device #1
Name           = HDA Intel: ALC260 Analog
Re: [Linux-uvc-devel] Problem with DFM 21AUC03-ML
Hi,
After looking a little more carefully it might be that the resolution
problem is related to de-bayering.
I uploaded a sample image captured from the video:
http://www.frc.ri.cmu.edu/~basti/01-20090306125232-17.jpg
Does anybody have any insight what the problem could be?
I downloaded the latest drivers and used them on Ubuntu 8.10 but the
problem persists.
Thank you
Sebastian
Hi,
I have a problem with this camera.
http://www.theimagingsource.com/en_US/products/oem-cameras/usb-cmos-color/dfm21auc03ml/
It shows a picture but I cannot set the frame size and resolution of
the camera. The camera supports
60 frames per second and a resolution of 744x480 YUV2. However I
always get 372x480 and the colors are wrong.
This is what dmesg reports:
[179400.340015] usb 6-1: new high speed USB device using ehci_hcd and address
3
[179400.777492] usb 6-1: configuration #1 chosen from 1 choice
[179400.90] uvcvideo: Found UVC 1.00 device DFx 21AUC03 (199e:8202)
[179401.306390] input: DFx 21AUC03 as
/devices/pci:00/:00:1a.7/usb6/6-1/6-1:1.0/input/input7
This is whalt lsusb reports:
Bus 006 Device 003: ID 199e:8202 The Imaging Source Europe GmbH
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x199e The Imaging Source Europe GmbH
idProduct 0x8202
bcdDevice8.13
iManufacturer 2 The Imaging Source Europe GmbH
iProduct1 DFx 21AUC03
iSerial 3 38800104
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 349
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 0
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 78
dwClockFrequency6.00MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength0
bControlSize 3
bmControls 0x001a
Auto-Exposure Mode
Exposure Time (Absolute)
Exposure Time (Relative)
VideoControl Interface Descriptor:
bLength12
bDescriptorType36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize3
bmControls 0x0200
Gain
iProcessing 0
bmVideoStandards 0x1a
NTSC - 525/60
SECAM - 625/50
NTSC - 625/50
VideoControl Interface Descriptor:
bLength26
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {2652215a-8932-5641-894a-5c557cdf9664}
bNumControl 4
bNrPins 1
baSourceID( 0) 3
bControlSize1
bmControls( 0) 0x1f
iExtension 0
VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 4
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1
Re: [Linux-uvc-devel] Problem with DFM 21AUC03-ML
Hi, Thank you for your replies. I tried guvcview with both formats but the output seems to be the same. It would be fine with me to manually correct the output. However I would really like to capture the full resolution images. How can I use capture still images? Also the 372 does not really make sense because this should not be a frame size that is supported by the camera. Maybe halving the size messes up the encoding? Thank you Sebastian 2009/3/9 Paulo Assis pj.as...@gmail.com: Sebastien, I've taken another look at luvcview output and it reports UYVY not YUYV, luvcview doesn't support this format I believe, you should try the latest version from guvcview (1.0.2), and see if outputs the frame correctly. Best regards, Paulo Sebastian Scherer escreveu: Hi, After looking a little more carefully it might be that the resolution problem is related to de-bayering. I uploaded a sample image captured from the video: http://www.frc.ri.cmu.edu/~basti/01-20090306125232-17.jpg Does anybody have any insight what the problem could be? I downloaded the latest drivers and used them on Ubuntu 8.10 but the problem persists. Thank you Sebastian Hi, I have a problem with this camera. http://www.theimagingsource.com/en_US/products/oem-cameras/usb-cmos-color/dfm21auc03ml/ It shows a picture but I cannot set the frame size and resolution of the camera. The camera supports 60 frames per second and a resolution of 744x480 YUV2. However I always get 372x480 and the colors are wrong. This is what dmesg reports: [179400.340015] usb 6-1: new high speed USB device using ehci_hcd and address 3 [179400.777492] usb 6-1: configuration #1 chosen from 1 choice [179400.90] uvcvideo: Found UVC 1.00 device DFx 21AUC03 (199e:8202) [179401.306390] input: DFx 21AUC03 as /devices/pci:00/:00:1a.7/usb6/6-1/6-1:1.0/input/input7 This is whalt lsusb reports: Bus 006 Device 003: ID 199e:8202 The Imaging Source Europe GmbH Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x199e The Imaging Source Europe GmbH idProduct 0x8202 bcdDevice 8.13 iManufacturer 2 The Imaging Source Europe GmbH iProduct 1 DFx 21AUC03 iSerial 3 38800104 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 349 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 3 Video Interface Collection bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 14 Video bInterfaceSubClass 1 Video Control bInterfaceProtocol 0 iInterface 0 VideoControl Interface Descriptor: bLength 13 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdUVC 1.00 wTotalLength 78 dwClockFrequency 6.00MHz bInCollection 1 baInterfaceNr( 0) 1 VideoControl Interface Descriptor: bLength 18 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Camera Sensor bAssocTerminal 0 iTerminal 0 wObjectiveFocalLengthMin 0 wObjectiveFocalLengthMax 0 wOcularFocalLength 0 bControlSize 3 bmControls 0x001a Auto-Exposure Mode Exposure Time (Absolute) Exposure Time (Relative) VideoControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 5 (PROCESSING_UNIT) Warning: Descriptor too short bUnitID 3 bSourceID 1 wMaxMultiplier 0 bControlSize 3 bmControls 0x0200 Gain iProcessing 0 bmVideoStandards 0x1a NTSC - 525/60 SECAM - 625/50 NTSC - 625/50 VideoControl Interface Descriptor: bLength 26
Re: [Linux-uvc-devel] [Fwd: Re: Problem with DFM 21AUC03-ML]
= ALSA Max inputs = 128, Max outputs = 128 Def. low input latency =0.043 Def. low output latency =0.043 Def. high input latency =0.046 Def. high output latency =0.046 Def. sample rate = 44100.00 --- device #10 Name = dmix Host API = ALSA Max inputs = 0, Max outputs = 2 Def. low input latency = -1.000 Def. low output latency =0.043 Def. high input latency = -1.000 Def. high output latency =0.043 Def. sample rate = 48000.00 -- SampleRate:0 Channels:0 Video driver: x11 A window manager is available 2009/3/9 Paulo Assis pj.as...@gmail.com: For the list (I keep pressing the reply button, and forget to change the address) Sebastian, Sebastian Scherer escreveu: Hi, Thank you for your replies. I tried guvcview with both formats but the output seems to be the same. It would be fine with me to manually correct the output. What is the console output from guvcview --verbose ? Setting an unsupported device format would only make guvcview drop back to the first supported device format. However I would really like to capture the full resolution images. How can I use capture still images? I don't think that's implemented in linux uvc. Also the 372 does not really make sense because this should not be a frame size that is supported by the camera. Maybe halving the size messes up the encoding? Thank you Your best bet is to grab a RAW frame and try to analyse it. I would say that the 372 pix line needs to be converted to 744, UYVY has 2 bytes per pixel, although you need 4 bytes to render 2 pixels, in this case it seems you are getting a format with 1 byte per pixel. Sebastian 2009/3/9 Paulo Assis pj.as...@gmail.com: Sebastien, I've taken another look at luvcview output and it reports UYVY not YUYV, luvcview doesn't support this format I believe, you should try the latest version from guvcview (1.0.2), and see if outputs the frame correctly. Best regards, Paulo Sebastian Scherer escreveu: Hi, After looking a little more carefully it might be that the resolution problem is related to de-bayering. I uploaded a sample image captured from the video: http://www.frc.ri.cmu.edu/~basti/01-20090306125232-17.jpg Does anybody have any insight what the problem could be? I downloaded the latest drivers and used them on Ubuntu 8.10 but the problem persists. Thank you Sebastian Hi, I have a problem with this camera. http://www.theimagingsource.com/en_US/products/oem-cameras/usb-cmos-color/dfm21auc03ml/ It shows a picture but I cannot set the frame size and resolution of the camera. The camera supports 60 frames per second and a resolution of 744x480 YUV2. However I always get 372x480 and the colors are wrong. This is what dmesg reports: [179400.340015] usb 6-1: new high speed USB device using ehci_hcd and address 3 [179400.777492] usb 6-1: configuration #1 chosen from 1 choice [179400.90] uvcvideo: Found UVC 1.00 device DFx 21AUC03 (199e:8202) [179401.306390] input: DFx 21AUC03 as /devices/pci:00/:00:1a.7/usb6/6-1/6-1:1.0/input/input7 This is whalt lsusb reports: Bus 006 Device 003: ID 199e:8202 The Imaging Source Europe GmbH Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x199e The Imaging Source Europe GmbH idProduct 0x8202 bcdDevice 8.13 iManufacturer 2 The Imaging Source Europe GmbH iProduct 1 DFx 21AUC03 iSerial 3 38800104 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 349 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 3 Video Interface Collection bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 14 Video bInterfaceSubClass 1 Video Control bInterfaceProtocol 0 iInterface 0 VideoControl Interface Descriptor: bLength 13 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdUVC 1.00
Re: [Linux-uvc-devel] [Fwd: Re: Problem with DFM 21AUC03-ML]
Hi,
I tried a raw dump with luvcview -c. The resulting file is 744x480
big. With the following commands I can decode the image properly in
matlab:
fid = fopen('frame000.raw');
A=fread(fid,357120,'uchar');
Ares = reshape(A,744,480);
imshow(demosaic(uint8(Ares),'grbg'))
Is there a way I could hack the driver to produce the same result?
This would be much more convient (and efficient) to use the data in
some vision code I am writing. I tried changing
.name = YUV 4:2:2 (YUYV),
.guid = UVC_GUID_FORMAT_YUY2,
.fcc= V4L2_PIX_FMT_YUYV,
the fcc to
V4L2_PIX_FMT_SBGGR8 but that caused a segfault with luvcview. Is
there a way I could force it to use bayer?
Thank you
Sebastian
2009/3/9 Sebastian Scherer smash0190s...@gmail.com:
Hi,
Thank you so much for your help!
How do I capture raw frames?
What would it take to get the single frame capture implemented?
Another strange thing is that the camera also supports 60 frames per
second and it does not show up as a format. Could this be related to
the 372 size?
This is the output from guvcview --verbose:
guvcview 1.0.2
video_device: /dev/video0
vid_sleep: 0
resolution: 372 x 480
windowsize: 480 x 700
vert pane: 578
spin behavior: 0
mode: uyvy
fps: 1/30
Display Fps: 0
bpp: 0
hwaccel: 1
grabmethod: 1
avi_format: 2
sound: 0
sound Device: 2
sound samp rate: 0
sound Channels: 0
Sound Block Size: 1 seconds
Sound Format: 80
Sound bit Rate: 160 Kbps
Pan Step: 2 degrees
Tilt Step: 2 degrees
Video Filter Flags: 0
image inc: 0
profile(default):/home/ulb/default.gpfl
language catalog= dir:/usr/share/locale type�ػr...@�gtk20
lang:en_US.UTF-8 cat:guvcview.mo
uyvy: setting format to 1498831189
video device: /dev/video0
/dev/video0 - device 1
Init. DFx 21AUC03 (location: usb-:00:1a.7-2)
{ pixelformat = 'YUYV', description = 'YUV 4:2:2 (YUYV)' }
{ discrete: width = 372, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 480 }
Time interval between frame: 1/30,
{ pixelformat = 'UYVY', description = 'YUV 4:2:2 (UYVY)' }
{ discrete: width = 372, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 480 }
Time interval between frame: 1/30,
checking format: 1498831189
vid:199e
pid:8202
driver:uvcvideo
Controls:
control[0]: 0x980913 Gain, 16:1:64, default 16
control[1]: 0x9a0901 Exposure, Auto, 0:1:3, default 6
control[2]: 0x9a0902 Exposure (Absolute), 1:1:2550, default 127
resolutions of 2º format=2
frame rates of 1º resolution=1
Def. Res: 0 numb. fps:1
--- device #0
[ Default Input, Default Output ]
Name = /dev/dsp
Host API = OSS
Max inputs = 16, Max outputs = 16
Def. low input latency = 0.012
Def. low output latency = 0.012
Def. high input latency = 0.046
Def. high output latency = 0.046
Def. sample rate = 44100.00
--- device #1
Name = HDA Intel: ALC260 Analog (hw:0,0)
Host API = ALSA
Max inputs = 2, Max outputs = 2
Def. low input latency = 0.012
Def. low output latency = 0.012
Def. high input latency = 0.046
Def. high output latency = 0.046
Def. sample rate = 44100.00
--- device #2
Name = HDA Intel: ALC260 Digital (hw:0,1)
Host API = ALSA
Max inputs = 0, Max outputs = 2
Def. low input latency = -1.000
Def. low output latency = 0.012
Def. high input latency = -1.000
Def. high output latency = 0.046
Def. sample rate = 44100.00
--- device #3
Name = front
Host API = ALSA
Max inputs = 0, Max outputs = 2
Def. low input latency = -1.000
Def. low output latency = 0.012
Def. high input latency = -1.000
Def. high output latency = 0.046
Def. sample rate = 44100.00
--- device #4
Name = surround40
Host API = ALSA
Max inputs = 0, Max outputs = 2
Def. low input latency = -1.000
Def. low output latency = 0.012
Def. high input latency = -1.000
Def. high output latency = 0.046
Def. sample rate = 44100.00
--- device #5
Name = surround51
Host API = ALSA
Max inputs = 0, Max outputs = 2
Def. low input latency = -1.000
Def. low output latency = 0.012
Def. high input latency = -1.000
Def. high output latency = 0.046
Def. sample rate = 44100.00
--- device #6
Name = surround71
Host API = ALSA
Max inputs = 0, Max outputs = 2
Def. low input latency = -1.000
Def. low output latency
[Linux-uvc-devel] Problem with DFM 21AUC03-ML
Hi,
I have a problem with this camera.
http://www.theimagingsource.com/en_US/products/oem-cameras/usb-cmos-color/dfm21auc03ml/
It shows a picture but I cannot set the frame size and resolution of
the camera. The camera supports
60 frames per second and a resolution of 744x480 YUV2. However I
always get 372x480 and the colors are wrong.
This is what dmesg reports:
[179400.340015] usb 6-1: new high speed USB device using ehci_hcd and address 3
[179400.777492] usb 6-1: configuration #1 chosen from 1 choice
[179400.90] uvcvideo: Found UVC 1.00 device DFx 21AUC03 (199e:8202)
[179401.306390] input: DFx 21AUC03 as
/devices/pci:00/:00:1a.7/usb6/6-1/6-1:1.0/input/input7
This is whalt lsusb reports:
Bus 006 Device 003: ID 199e:8202 The Imaging Source Europe GmbH
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x199e The Imaging Source Europe GmbH
idProduct 0x8202
bcdDevice8.13
iManufacturer 2 The Imaging Source Europe GmbH
iProduct1 DFx 21AUC03
iSerial 3 38800104
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 349
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 0
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 78
dwClockFrequency6.00MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength0
bControlSize 3
bmControls 0x001a
Auto-Exposure Mode
Exposure Time (Absolute)
Exposure Time (Relative)
VideoControl Interface Descriptor:
bLength12
bDescriptorType36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize3
bmControls 0x0200
Gain
iProcessing 0
bmVideoStandards 0x1a
NTSC - 525/60
SECAM - 625/50
NTSC - 625/50
VideoControl Interface Descriptor:
bLength26
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {2652215a-8932-5641-894a-5c557cdf9664}
bNumControl 4
bNrPins 1
baSourceID( 0) 3
bControlSize1
bmControls( 0) 0x1f
iExtension 0
VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 4
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber1
bAlternateSetting 0
bNumEndpoints 1
