[Linux-uvc-devel] again Logitech QuickCam Pro for Notebooks 046d:0991
Hallo, I found in this list message Logitech QuickCam Pro for Notebooks 046d:0991 not working from Mon Jul 28 10:18:08 CEST 2008. So now i will ask about same problem. It seems some bugs was fixed, some new probably made. I have some random problem with this camera. Thirst of all cheese, some time it's work, some time i gat only black screen, after this camera do not work, so i need to replug it. With mplayer it working mostly normal but after cheese it will not work too. The video chat with empathy has same problem like cheese to. cheese and epmaty depend on gstreamer but this seems to work fine if i use: gst-launch v4l2src ! queue ! videorate ! video/x-raw-yuv,framerate=15/1 ! videoscale ! video/x-raw-yuv,width=640,height=480 ! ffmpegcolorspace ! videoscale ! ximagesink After cheese i get this demsg: [ 1296.135911] usbcore: registered new interface driver snd-usb-audio [ 1296.147366] uvcvideo: Found UVC 1.00 device unnamed (046d:0991) [ 1296.170101] input: UVC Camera (046d:0991) as /devices/pci:00/:00:1a.7/usb1/1-6/1-6:1.0/input/input15 [ 1296.170139] usbcore: registered new interface driver uvcvideo [ 1296.170142] USB Video Class driver (v0.1.0) [ 2235.420181] uvcvideo: Failed to query (135) UVC control 2 (unit 2) : -110 (exp. 2). [ 2235.721428] uvcvideo: Failed to query (135) UVC control 2 (unit 2) : -110 (exp. 2). [ 2242.560187] uvcvideo: Failed to query (135) UVC control 2 (unit 2) : -110 (exp. 2). [ 2242.860179] uvcvideo: Failed to query (135) UVC control 2 (unit 2) : -110 (exp. 2). [ 2266.230184] uvcvideo: Failed to set UVC probe control : -110 (exp. 26). [ 2271.350744] uvcvideo: Failed to set UVC probe control : -110 (exp. 26). [ 2289.660019] usb 1-6: USB disconnect, address 6 [ 2293.430078] usb 1-6: new high speed USB device using ehci_hcd and address 7 [ 2293.708270] usb 1-6: configuration #1 chosen from 1 choice The guestion is, is it kernel, gstreamer or empathy and cheese bug? ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] again Logitech QuickCam Pro for Notebooks 046d:0991
Actually i don't really care about chees or empathy do not work, but more. Haw they make camera freeze so hard that only plugoff will help? What control was used to do it? Alexey. Am Mittwoch, den 14.10.2009, 09:53 -0400 schrieb Andres Cimmarusti: I have the same problem with cheese and the same camera. I don't get any problems using lucview nor skype. Cheese version 2.22 was actually working fairly well for me (using Debian stable), but I couldn't record videos so I uninstalled it. I'll wait for a more polished bug-free cheese which will be available with squeeze. Andres On Wed, Oct 14, 2009 at 7:29 AM, Paulo Assis pj.as...@gmail.com wrote: Alexey, Since this only manifests itself after using cheese I would say it's a cheese problem. I also have the same problem with a sphereAF and cheese, sometimes it works fine, others the camera just crashes and I need to unplug it so that it will work again. Other apps work just fine with the camera. Best regards, Paulo 2009/10/14 Alexey Fisher bug-tr...@fisher-privat.net: Hallo, I found in this list message Logitech QuickCam Pro for Notebooks 046d:0991 not working from Mon Jul 28 10:18:08 CEST 2008. So now i will ask about same problem. It seems some bugs was fixed, some new probably made. I have some random problem with this camera. Thirst of all cheese, some time it's work, some time i gat only black screen, after this camera do not work, so i need to replug it. With mplayer it working mostly normal but after cheese it will not work too. The video chat with empathy has same problem like cheese to. cheese and epmaty depend on gstreamer but this seems to work fine if i use: gst-launch v4l2src ! queue ! videorate ! video/x-raw-yuv,framerate=15/1 ! videoscale ! video/x-raw-yuv,width=640,height=480 ! ffmpegcolorspace ! videoscale ! ximagesink After cheese i get this demsg: [ 1296.135911] usbcore: registered new interface driver snd-usb-audio [ 1296.147366] uvcvideo: Found UVC 1.00 device unnamed (046d:0991) [ 1296.170101] input: UVC Camera (046d:0991) as /devices/pci:00/:00:1a.7/usb1/1-6/1-6:1.0/input/input15 [ 1296.170139] usbcore: registered new interface driver uvcvideo [ 1296.170142] USB Video Class driver (v0.1.0) [ 2235.420181] uvcvideo: Failed to query (135) UVC control 2 (unit 2) : -110 (exp. 2). [ 2235.721428] uvcvideo: Failed to query (135) UVC control 2 (unit 2) : -110 (exp. 2). [ 2242.560187] uvcvideo: Failed to query (135) UVC control 2 (unit 2) : -110 (exp. 2). [ 2242.860179] uvcvideo: Failed to query (135) UVC control 2 (unit 2) : -110 (exp. 2). [ 2266.230184] uvcvideo: Failed to set UVC probe control : -110 (exp. 26). [ 2271.350744] uvcvideo: Failed to set UVC probe control : -110 (exp. 26). [ 2289.660019] usb 1-6: USB disconnect, address 6 [ 2293.430078] usb 1-6: new high speed USB device using ehci_hcd and address 7 [ 2293.708270] usb 1-6: configuration #1 chosen from 1 choice The guestion is, is it kernel, gstreamer or empathy and cheese bug? ___ 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] again Logitech QuickCam Pro for Notebooks 046d:0991
I did some simple dirty hack, it prevent webcam from being killed by
cheese. On other site it make cheese work too.
Like Paulo said, the camera is slow and it need more time to make
thirst start, some time it need 8 seconds on second start it need about
2 seconds. If we call STREAMOFF before we get EOF, the camera will die.
IMHO, the driver should decide if camera ready or not. The easiest way
is, to add SLOWSTART quirk. Correct way probobly will be to check if
camera ready or not.
Any ideas how to make it? Or any other ideas?
I know, cheese use some bruteforce way to get settings, but the bug in
cheese make the bug in uvcvideo easy to reproduce.
here is this hack:
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index f960e8e..fdc7007 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -794,7 +794,7 @@ static void uvc_uninit_video(struct uvc_streaming
*stream, int free_buffers)
{
struct urb *urb;
unsigned int i;
-
+ msleep(5000);
for (i = 0; i UVC_URBS; ++i) {
urb = stream-urb[i];
if (urb == NULL)
@@ -985,7 +985,7 @@ static int uvc_init_video(struct uvc_streaming
*stream, gfp_t gfp_flags)
return ret;
}
}
-
+ msleep(5000);
return 0;
}
Alexey,
Am Mittwoch, den 14.10.2009, 16:37 +0100 schrieb Paulo Assis:
Alexey,
I believe it has something to do with the camera initialization, both
the sphere and the pro9000 are based on the same chip and it takes it
several seconds to initialize, unlike other cameras.
Not sure how cheese handles this, although I guess very badly :D.
If I start some other software first, like guvcview, then cheese, it
will work OK since the camera initialization already happen, but if I
start cheese first, it can crash/lock the camera. The latest cheese
version from upcoming ubuntu karmic exhibits the same problems (even
worst than intrepid). In fact the last time I experience this, the
crash was so bad that alsa/pulse was also affected, it wouldn't start
the camera mic, making the entire system very slow.
Other cameras with fast initialization times work without problems.
Best regards,
Paulo
2009/10/14 Alexey Fisher bug-tr...@fisher-privat.net:
Actually i don't really care about chees or empathy do not work, but
more. Haw they make camera freeze so hard that only plugoff will help?
What control was used to do it?
Alexey.
Am Mittwoch, den 14.10.2009, 09:53 -0400 schrieb Andres Cimmarusti:
I have the same problem with cheese and the same camera. I don't get
any problems using lucview nor skype. Cheese version 2.22 was actually
working fairly well for me (using Debian stable), but I couldn't
record videos so I uninstalled it. I'll wait for a more polished
bug-free cheese which will be available with squeeze.
Andres
On Wed, Oct 14, 2009 at 7:29 AM, Paulo Assis pj.as...@gmail.com
wrote:
Alexey,
Since this only manifests itself after using cheese I would
say it's a
cheese problem.
I also have the same problem with a sphereAF and cheese,
sometimes it
works fine, others the camera just crashes and I need to
unplug it so
that it will work again.
Other apps work just fine with the camera.
Best regards,
Paulo
2009/10/14 Alexey Fisher bug-tr...@fisher-privat.net:
Hallo,
I found in this list message Logitech QuickCam Pro for
Notebooks
046d:0991 not working from Mon Jul 28 10:18:08 CEST 2008.
So now i will
ask about same problem. It seems some bugs was fixed, some
new probably
made.
I have some random problem with this camera. Thirst of all
cheese, some
time it's work, some time i gat only black screen, after
this camera do
not work, so i need to replug it. With mplayer it working
mostly normal
but after cheese it will not work too. The video chat with
empathy has
same problem like cheese to. cheese and epmaty depend on
gstreamer but
this seems to work fine if i use:
gst-launch v4l2src ! queue ! videorate !
video/x-raw-yuv,framerate=15/1 ! videoscale !
video/x-raw-yuv,width=640,height=480 ! ffmpegcolorspace !
videoscale !
ximagesink
After cheese i get this demsg:
[ 1296.135911] usbcore: registered new interface driver
snd-usb-audio
[ 1296.147366] uvcvideo: Found UVC 1.00 device unnamed
(046d:0991)
[ 1296.170101] input: UVC Camera (046d:0991)
as /devices/pci:00/:00:1a.7/usb1/1-6/1-6:1.0/input/input15
[ 1296.170139] usbcore: registered new interface driver
uvcvideo
[ 1296.170142] USB Video Class driver (v0.1.0
[Linux-uvc-devel] [new cam] 0408:1fc3 buildin webcam on fujisu lifebook a340
Hi, i helping my friend to install linux on his new laptop fujisu lifebook a340. It is cheap one (350€) but seems to work good with linux. But web cam has some issues, which i will discuss with you. It is uvc webcam (0408:1fc3 Quanta Computer, Inc.). For most frame sizes it aims to support 10, 15,25, 30 fps. In real life it stream only with 30fps, if i try to set 10fps, it will silently ignore it. The real problem - there is no exposure control and autoexposure do not working with 30fps too. So with normal light the image will be dark and noisy. With frame sizes 1280x960 and 1280x1024, it has max frame rate 9fps (aims to support 9 and 5 fps). Interesting thing is, autoexposure seems to work here. If i close the cam, frame rate will drop to ~4fps, and if i add extra light it will go to ~9fps. The image with this framerate is better than with 30fps. By tracing i also found uvcvideo: Dropping payload (out of sync). messages. So i added two quirks for this cam: UVC_QUIRK_STREAM_NO_FID for out of sync; UVC_QUIRK_RESTRICT_FRAME_RATE for dummy frame rates. Now my question: is it possible to pull/force some registers to test if auto exposure can work with 30fps too? If not, is it possible to notify user space about broken auto exposure? So user space apps can make right decision? PS: in attachment is quirks_patch, and lsusb. Regards, Alexey Bus 001 Device 003: ID 0408:1fc3 Quanta Computer, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x0408 Quanta Computer, Inc. idProduct 0x1fc3 bcdDevice 13.06 iManufacturer 1 QCM iProduct2 USB Webcam iSerial 3 SN001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 553 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 3 Video Interface Collection bFunctionProtocol 0 iFunction 4 USB Webcam Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass14 Video bInterfaceSubClass 1 Video Control bInterfaceProtocol 0 iInterface 4 USB Webcam VideoControl Interface Descriptor: bLength13 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdUVC 1.00 wTotalLength 51 dwClockFrequency 60.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 0x VideoControl Interface Descriptor: bLength11 bDescriptorType36 bDescriptorSubtype 5 (PROCESSING_UNIT) Warning: Descriptor too short bUnitID 2 bSourceID 1 wMaxMultiplier 0 bControlSize2 bmControls 0x053f Brightness Contrast Hue Saturation Sharpness Gamma Backlight Compensation Power Line Frequency iProcessing 0 bmVideoStandards 0x 9 None SECAM - 625/50 VideoControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 5 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 2 iTerminal 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None
Re: [Linux-uvc-devel] Cam 0402:5606 not working (any more)
can you please send ouput of this command uvcdynctrl -f what do you mean with refresh rate? if frame rate, do you mean it is too high? Please install gstreamer0.10-plugins-bad and try this command: gst-launch-0.10 -v v4l2src ! video/x-raw-yuv,width=640,height=480 ! ffmpegcolorspace ! fpsdisplaysink It will display frame rate on the screen, so tell what framreate do you get. Am Mittwoch, den 19.01.2011, 01:45 +0100 schrieb Benjamin Hill: Cam worked fine with all applications until a part-time dual istallation of Win XP. Since then i only get a quarter (upper left) of the Cam's view, with cheese i could set it to a unnatural resolution of 1280x1024 for showing me the whole view, but ignored by e.g. skype - and still a extremely dark picture probably only with b/w content and completely wrong refresh-rate. Already tried to reinstall XP for maybe being allowed to reset the cam's settings to get it to work again with the ubuntustudio 10.04, no success yet. I'd appreciate it if you could give some helping ideas. Regards, Benny Informations: Bus 001 Device 006: ID 0402:5606 ALi Corp. USB 2.0 Camera (XP: Bison Cam 1.3 MPx Driver, it's a built in). libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? v4l-conf: using X11 display :0.0 dga: version 2.0 mode: 1280x800, depth=24, bpp=32, bpl=28, base=unknown /dev/video1 [v4l2]: no overlay support $gstreamer-properties gstreamer-properties-Message: Skipping unavailable plugin 'artsdsink' gstreamer-properties-Message: Skipping unavailable plugin 'esdsink' gstreamer-properties-Message: Skipping unavailable plugin 'glimagesink' gstreamer-properties-Message: Skipping unavailable plugin 'sdlvideosink' gstreamer-properties-Message: Skipping unavailable plugin 'v4lmjpegsrc' gstreamer-properties-Message: Skipping unavailable plugin 'qcamsrc' gstreamer-properties-Message: Skipping unavailable plugin 'esdmon' ### v4l2 device info [/dev/video1] ### general info VIDIOC_QUERYCAP driver : uvcvideo card: USB2.0 Camera bus_info: usb-:00:1a.7-2 version : 0.1.0 capabilities: 0x401 [VIDEO_CAPTURE,STREAMING] standards inputs VIDIOC_ENUMINPUT(0) index : 0 name: Camera 1 type: CAMERA audioset: 0 tuner : 0 std : 0x0 [] status : 0x0 [] video capture VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE) index : 0 type: VIDEO_CAPTURE flags : 1 description : MJPEG pixelformat : 0x47504a4d [MJPG] VIDIOC_ENUM_FMT(1,VIDEO_CAPTURE) index : 1 type: VIDEO_CAPTURE flags : 0 description : YUV 4:2:2 (YUYV) pixelformat : 0x56595559 [YUYV] VIDIOC_G_FMT(VIDEO_CAPTURE) type: VIDEO_CAPTURE fmt.pix.width : 640 fmt.pix.height : 480 fmt.pix.pixelformat : 0x47504a4d [MJPG] fmt.pix.field : NONE fmt.pix.bytesperline: 0 fmt.pix.sizeimage : 2621440 fmt.pix.colorspace : unknown fmt.pix.priv: 0 controls VIDIOC_QUERYCTRL(BASE+0) id : 9963776 type: INTEGER name: Brightness minimum : 0 maximum : 100 step: 1 default_value : 50 flags : 0 VIDIOC_QUERYCTRL(BASE+1) id : 9963777 type: INTEGER name: Contrast minimum : 0 maximum : 6 step: 1 default_value : 4 flags : 0 VIDIOC_QUERYCTRL(BASE+2) id : 9963778 type: INTEGER name: Saturation minimum : 0 maximum : 8 step: 1 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(BASE+3) id : 9963779 type:
Re: [Linux-uvc-devel] Cam 0402:5606 not working (any more)
Ok, i thought you get images where 3/4 will be black and 1/4 is actual image. Now i see it looks more like zoom (like sw zoom on my logitech). Seems like your problem is the eeprom (sort of BIOS) of your webcam. It store Usb ID (0402:5606) and default settings. Normally it should be write protected, but if your changes made in windows appear in linux (after reboot and complete poweroff), then your windows app can overwrite eeprom. This is really horror scenario. I do not have any other reasonable explanation. Any other ideas? Am Mittwoch, den 19.01.2011, 13:43 +0100 schrieb Benjamin Hill: Hi again, the webcam probably is a cheap one (builtin), but - is working (actually) perfectly and directly after Driversetup under WinXP - lense is not blocked or broken - is limited configurable under windows --- where i deactivated the auto gamma/saturation/whatever for picture-enlightment and set it to max. value 100. --- And set the Frequency (not Framerate) Option from 60Hz to 50Hz for Europe. The result of the config-modifications in the BisoncamNG Windows-App is that the picture is now no more b/w but still a quarter view of unnatural coloured content and a framerate of ~2,4 fps. Independent of selected resolution. Is there maybe a possibility to reset the dominant windows-settings to the v4l-compatible or estimated settings? I think the provblem is caused by identifying oder threating the cam wrong or different Firmware-Config by WindowsXP compared to the earlier situation with the cam working in Linux perfectly. I've made 2 captures for you with the named config-modifications under XP Pro for coloured results under linux (640x480 and 320x240). By trying 1024x768 (working for cheese cam-preview) v4l2src0 can't negotiate format and advices to check filtered caps if any. Thank you. Best regards, Benny -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] GE Minicam Pro 98082 drivers for ubuntu
Hi, Am Donnerstag, den 20.01.2011, 19:13 +0530 schrieb Prashant Uday Manohar: Hi, I want to install GE Minicam Pro, Model no. 98082, ver.1 on my Dell vostro 1500 laptop. I am using Ubuntu 10.10 OS. I'll appreciate your help in this matter. Thank you. Prashant This project for UVC (USB Video Class) webcams. Unfortunately your webcam is not one of that. There was one project trying to provide a linux closed source driver for your cam: http://www.linux-projects.org/modules/news/ with some luck, you'll get your cam for 5€ or 7$ to work: http://www.linux-projects.org/downloads/sn9cxxx-unlimited.html So if you add some money, you can by some good UVC webcam. -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [new cam] 0408:1fc3 buildin webcam on fujisu lifebook a340
Am Dienstag, den 25.01.2011, 14:38 +0100 schrieb Laurent Pinchart:
Hi Alexey,
On Sunday 16 January 2011 09:57:53 Alexey Fisher wrote:
Hi,
i helping my friend to install linux on his new laptop fujisu lifebook
a340. It is cheap one (350€) but seems to work good with linux. But web
cam has some issues, which i will discuss with you.
It is uvc webcam (0408:1fc3 Quanta Computer, Inc.).
For most frame sizes it aims to support 10, 15,25, 30 fps. In real life it
stream only with 30fps, if i try to set 10fps, it will silently ignore it.
The real problem - there is no exposure control and autoexposure do not
working with 30fps too. So with normal light the image will be dark and
noisy.
With frame sizes 1280x960 and 1280x1024, it has max frame rate 9fps
(aims to support 9 and 5 fps). Interesting thing is, autoexposure seems
to work here. If i close the cam, frame rate will drop to ~4fps, and if
i add extra light it will go to ~9fps. The image with this framerate is
better than with 30fps.
By tracing i also found uvcvideo: Dropping payload (out of sync).
messages. So i added two quirks for this cam: UVC_QUIRK_STREAM_NO_FID
for out of sync;
Did UVC_QUIRK_STREAM_NO_FID make any difference ?
It remove all out of sync errors from trace. But i didn't noticed any
stability or quality difference.
UVC_QUIRK_RESTRICT_FRAME_RATE for dummy frame rates.
Now my question: is it possible to pull/force some registers to test if
auto exposure can work with 30fps too?
The camera doesn't report exposure/auto exposure controls in its descriptors.
You could hack the driver to make it think the camera supports those
controls.
You should then be able to set them from userspace to see if they make any
difference.
The easiest way would be to modify uvc_ctrl_init_device() in uvc_ctrl.c. Add
static const u8 camera_controls[3] = { 0x0e, 0x00, 0x00 };
at the beginning of the function, and replace
} else if (UVC_ENTITY_TYPE(entity) == UVC_ITT_CAMERA) {
bmControls = entity-camera.bmControls;
bControlSize = entity-camera.bControlSize;
}
with
} else if (UVC_ENTITY_TYPE(entity) == UVC_ITT_CAMERA) {
bmControls = camera_controls;
bControlSize = entity-camera.bControlSize;
}
This is not working. I did other hack, i just allowed only high
resolution. This is my last diff:
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_
index a1e9dfb..e771530 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -495,7 +495,9 @@ static int uvc_parse_format(struct uvc_device *dev,
1000/frame-dwDefaultFrameInterval,
(1/frame-dwDefaultFrameInterval)%10);
- format-nframes++;
+ if (get_unaligned_le16(buffer[5]) == 1280)
+ format-nframes++;
+
buflen -= buffer[0];
buffer += buffer[0];
}
@@ -1957,6 +1959,16 @@ MODULE_PARM_DESC(timeout, Streaming control requests
tim
* though they are compliant.
*/
static struct usb_device_id uvc_ids[] = {
+ /* (Quanta Computer, Inc.) Build in webcam found on Lifebook A530 */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x0408,
+ .idProduct= 0x1fc3,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_STREAM_NO_FID
+ | UVC_QUIRK_RESTRICT_FRAME_RATE },
/* Genius eFace 2025 */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
This i get before patch:
uvcdynctrl -f
Listing available frame formats for device video0:
Pixel format: YUYV (YUV 4:2:2 (YUYV); MIME type: video/x-raw-yuv)
Frame size: 640x480
Frame rates: 30, 25, 15, 10
Frame size: 352x288
Frame rates: 30, 25, 15, 10
Frame size: 320x240
Frame rates: 30, 25, 15, 10
Frame size: 176x144
Frame rates: 30, 25, 15, 10
Frame size: 160x120
Frame rates: 30, 25, 15, 10
Frame size: 1280x960
Frame rates: 9, 5
Frame size: 1280x1024
Frame rates: 9, 5
This is after patch:
Pixel format: YUYV (YUV 4:2:2 (YUYV); MIME type: video/x-raw-yuv)
Frame size: 1280x960
Frame rates: 9
Frame size: 1280x1024
Frame rates: 9
--
Regards,
Alexey
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Logitech C910 -- trying to run more than one.
Am Sonntag, den 20.02.2011, 15:57 -0500 schrieb Philip Gladstone: I attached two C910s to a small linux box, and ran into the 'Failed to submit URB' problem. When I look at the descriptors for this camera, I think I understand the problem. I'm capturing at 5 Mpixels and I'm trying two cameras. VideoStreaming Interface Descriptor: bLength38 bDescriptorType36 bDescriptorSubtype 7 (FRAME_MJPEG) bFrameIndex28 bmCapabilities 0x01 Still image supported wWidth 2592 wHeight 1944 dwMinBitRate403107840 dwMaxBitRate806215680 dwMaxVideoFrameBufferSize10077696 dwDefaultFrameInterval100 bFrameIntervalType 3 dwFrameInterval( 0) 100 dwFrameInterval( 1) 133 dwFrameInterval( 2) 200 The video frame size is set to 10Mb. This is surprisingly large as actual frames captured with MJPEG on this camera are typically 500kb or less. When I checked the descriptor for the uncompressed version of the same frame, it came back with the same value of dwMaxVideoFrameBufferSize (effectively 16 bits per pixel). The values for min/max bit rate are (correctly) calculated from the frame intervals and the buffer size. Typical JPEG compression gets down to 1 bit per pixel, and 2 bits is very unusual. What I want to know is what the impact would be of defining a new QUIRK that overrode the frame buffer size for compressed frames and calculated them at (say) 2 bits per pixel? Do other webcams get this right? Tyke a look to the attached patch. Do you mean some thing like this? -- Regards, Alexey diff --git a/drivers/media/video/uvc/uvc_driver.c b/drivers/media/video/uvc/uvc_driver.c index a1e9dfb..e3fd466 100644 --- a/drivers/media/video/uvc/uvc_driver.c +++ b/drivers/media/video/uvc/uvc_driver.c @@ -465,6 +465,13 @@ static int uvc_parse_format(struct uvc_device *dev, frame-dwMaxVideoFrameBufferSize = format-bpp * frame-wWidth * frame-wHeight / 8; + /* Compressed MJPG stream is also affected. Try to recalculate + * FrameBufferSize to 2bpp. + */ + if (format-flags UVC_FMT_FLAG_COMPRESSED) + frame-dwMaxVideoFrameBufferSize = 2 +* frame-wWidth * frame-wHeight / 8; + /* Some bogus devices report dwMinFrameInterval equal to * dwMaxFrameInterval and have dwFrameIntervalStep set to * zero. Setting all null intervals to 1 fixes the problem and ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Logitech C910 -- trying to run more than one.
Am Montag, den 21.02.2011, 08:46 +0100 schrieb Alexey Fisher: Am Sonntag, den 20.02.2011, 15:57 -0500 schrieb Philip Gladstone: I attached two C910s to a small linux box, and ran into the 'Failed to submit URB' problem. When I look at the descriptors for this camera, I think I understand the problem. I'm capturing at 5 Mpixels and I'm trying two cameras. VideoStreaming Interface Descriptor: bLength38 bDescriptorType36 bDescriptorSubtype 7 (FRAME_MJPEG) bFrameIndex28 bmCapabilities 0x01 Still image supported wWidth 2592 wHeight 1944 dwMinBitRate403107840 dwMaxBitRate806215680 dwMaxVideoFrameBufferSize10077696 dwDefaultFrameInterval100 bFrameIntervalType 3 dwFrameInterval( 0) 100 dwFrameInterval( 1) 133 dwFrameInterval( 2) 200 The video frame size is set to 10Mb. This is surprisingly large as actual frames captured with MJPEG on this camera are typically 500kb or less. When I checked the descriptor for the uncompressed version of the same frame, it came back with the same value of dwMaxVideoFrameBufferSize (effectively 16 bits per pixel). The values for min/max bit rate are (correctly) calculated from the frame intervals and the buffer size. Typical JPEG compression gets down to 1 bit per pixel, and 2 bits is very unusual. What I want to know is what the impact would be of defining a new QUIRK that overrode the frame buffer size for compressed frames and calculated them at (say) 2 bits per pixel? Do other webcams get this right? Ok, i did some test with my webcam (046d:0991 Logitech, Inc. QuickCam Pro for Notebooks). With normal conditions, get result with about 1bpp, but it depend on framerate and captured image. Jpeg is really bad with text, so i capteured moving text from command line on my display and i got max 4bpp. For my test i used this command: gst-launch -v v4l2src ! image/jpeg,width=320,height=240 ! identity ! decodebin2 ! autovideosink So it looks like we can recalculate buffer size for jpeg, but the question is - why? If the cam still provide uncoressed stream it will fail with big frame size, or it will fail with compressed but bigger frame size. The question is, is it possible to make driver calculate the bandwidth and recalculate it if second cam is inserted, and reduce possible frame size? I think not... Any solution for this problem? There is a mistake in previous patch, here is fixed one. Can you test it please? -- Regards, Alexey diff --git a/drivers/media/video/uvc/uvc_driver.c b/drivers/media/video/uvc/uvc_driver.c index a1e9dfb..53e0847 100644 --- a/drivers/media/video/uvc/uvc_driver.c +++ b/drivers/media/video/uvc/uvc_driver.c @@ -348,7 +348,7 @@ static int uvc_parse_format(struct uvc_device *dev, strlcpy(format-name, MJPEG, sizeof format-name); format-fcc = V4L2_PIX_FMT_MJPEG; format-flags = UVC_FMT_FLAG_COMPRESSED; - format-bpp = 0; + format-bpp = 4; ftype = UVC_VS_FRAME_MJPEG; break; @@ -461,10 +461,16 @@ static int uvc_parse_format(struct uvc_device *dev, * uncompressed formats this can be fixed by computing the * value from the frame size. */ - if (!(format-flags UVC_FMT_FLAG_COMPRESSED)) + if (!(format-flags UVC_FMT_FLAG_COMPRESSED) || +(format-type == UVC_VS_FORMAT_MJPEG)) frame-dwMaxVideoFrameBufferSize = format-bpp * frame-wWidth * frame-wHeight / 8; + printk(--- framesize %ix%i, buffsize %i, bpp %i\n, + frame-wWidth, frame-wHeight, + frame-dwMaxVideoFrameBufferSize, + format-bpp); + /* Some bogus devices report dwMinFrameInterval equal to * dwMaxFrameInterval and have dwFrameIntervalStep set to * zero. Setting all null intervals to 1 fixes the problem and ___ 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 disconnect event
in this log i see only the usb-host part. Can you please reload uvcvideo module with: rmmod uvcvideo modprobe uvcvideo trace=0xfff and attach the log again. on my logitech cam you can bring it to freeze if you starts the video and stop it before it actually starts. So may be your app send some command before other was finished. Am Dienstag, den 22.02.2011, 11:53 +1100 schrieb linux newbie: [ 515.22] hub 1-0:1.0: state 7 ports 2 chg evt 0004 [ 515.22] str8100-ehci str8100-ehci: GetStatus port 2 status 001009 POWER sig=se0 PEC CONNECT [ 515.22] hub 1-0:1.0: port 2 enable change, status 0501 [ 515.22] hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling... [ 515.22] hub 1-0:1.0: port 2, status 0501, change 0002, 480 Mb/s [ 515.22] usb 1-2: USB disconnect, address 2 [ 515.22] usb 1-2: unregistering device [ 515.22] usb 1-2: usb_disable_device nuking all URBs [ 515.22] str8100-ehci str8100-ehci: shutdown urb c3fbe000 ep1in-iso [ 515.22] str8100-ehci str8100-ehci: shutdown urb c3c4d000 ep1in-iso [ 515.22] str8100-ehci str8100-ehci: shutdown urb c3fbf800 ep1in-iso [ 515.22] str8100-ehci str8100-ehci: shutdown urb c3fbf000 ep1in-iso [ 515.22] str8100-ehci str8100-ehci: shutdown urb c3fbe800 ep1in-iso [ 515.26] usb 1-2: unlink qh16-0001/ffc02100 start 15 [1/0 us] [ 515.26] str8100-ehci str8100-ehci: shutdown urb c3c5b540 ep3in-intr [ 515.26] usb 1-2: unregistering interface 1-2:1.0 [ 515.27] usb 1-2:1.0: uevent [ 515.27] usb 1-2: unregistering interface 1-2:1.1 [ 515.27] usb 1-2:1.1: uevent [ 515.28] usb 1-2: unregistering interface 1-2:1.2 [ 515.28] usb 1-2:1.2: uevent [ 515.28] usb 1-2: unregistering interface 1-2:1.3 [ 515.28] usb 1-2:1.3: uevent [ 515.28] usb 1-2: uevent [ 515.34] str8100-ehci str8100-ehci: GetStatus port 2 status 001002 POWER sig=se0 CSC [ 515.34] hub 1-0:1.0: state 7 ports 2 chg evt 0004 On Wed, Feb 16, 2011 at 6:07 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi, On Wednesday 02 February 2011 01:07:41 linux newbie wrote: I developed one application that keeps on reading one frame of data from camera. If I connect MS Lifecam, I am getting USB disconnect event randomly. But this is not happening in Logitech versions of Camera. Has anyone came across this sort of issue? Is there any solution worth trying it? Kernel log ? -- Regards, Laurent Pinchart ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] [PATCH 2/3] Recalculate dwMaxVideoFrameBufferSize for MJPEG
Some webcams report wired dwMaxVideoFrameBufferSize size,
some times too big, some times too smole.
I tested two webcams:
046d:0809 Logitech, Inc. Webcam Pro 9000
046d:0991 Logitech, Inc. QuickCam Pro for Notebooks
with fallowing results.
The dwMaxVideoFrameBufferSize is not always the same. Reported
range is about betwene 4 and 10 bpp calculated with this formula:
bpp = (dwMaxVideoFrameBufferSize * 8) / (frame-wWidth * frame-wHeight)
I tested also a real comression on this cameras. Comression
with noremal conditions (video chat) was about 1 bpp.
Worst compression was by captureing moving text on monitore
(lots of light, high fps) is about 3bpp.
So we can calculate predictable buffer size in driver, insted of
getting some random numers from the cam.
Setting bpp to 4 for mjpeg should be safe.
Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net
---
drivers/media/video/uvc/uvc_driver.c |5 +++--
drivers/media/video/uvc/uvc_video.c |3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index e41285a..5a74de0 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -347,7 +347,7 @@ static int uvc_parse_format(struct uvc_device *dev,
strlcpy(format-name, MJPEG, sizeof format-name);
format-fcc = V4L2_PIX_FMT_MJPEG;
format-flags = UVC_FMT_FLAG_COMPRESSED;
- format-bpp = 0;
+ format-bpp = 4;
ftype = UVC_VS_FRAME_MJPEG;
break;
@@ -460,7 +460,8 @@ static int uvc_parse_format(struct uvc_device *dev,
* uncompressed formats this can be fixed by computing the
* value from the frame size.
*/
- if (!(format-flags UVC_FMT_FLAG_COMPRESSED))
+ if (!(format-flags UVC_FMT_FLAG_COMPRESSED) ||
+ (format-fcc == V4L2_PIX_FMT_MJPEG))
frame-dwMaxVideoFrameBufferSize = format-bpp
* frame-wWidth * frame-wHeight / 8;
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index 9a95a62..64bd1d6 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -114,7 +114,8 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
if (!(format-flags UVC_FMT_FLAG_COMPRESSED) ||
(ctrl-dwMaxVideoFrameSize == 0
- stream-dev-uvc_version 0x0110)) {
+ stream-dev-uvc_version 0x0110) ||
+(format-fcc == V4L2_PIX_FMT_MJPEG)) {
pr_debug(%s: rewrite dwMaxVideoFrameSize=%u to %u.,
__func__, ctrl-dwMaxVideoFrameSize,
frame-dwMaxVideoFrameBufferSize);
--
1.7.1
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] [PATCH 3/3] Make video fixup more robust
Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net
---
drivers/media/video/uvc/uvc_video.c | 59 ++-
1 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index 64bd1d6..5380189 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -92,10 +92,9 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
{
struct uvc_format *format;
struct uvc_frame *frame = NULL;
+ struct usb_host_endpoint *ep;
unsigned int i;
- pr_debug(%s, __func__);
-
if (ctrl-bFormatIndex = 0 ||
ctrl-bFormatIndex stream-nformats)
return;
@@ -112,6 +111,9 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
if (frame == NULL)
return;
+ pr_debug(%s: %s %ux%u, __func__,
+format-name, frame-wWidth, frame-wHeight);
+
if (!(format-flags UVC_FMT_FLAG_COMPRESSED) ||
(ctrl-dwMaxVideoFrameSize == 0
stream-dev-uvc_version 0x0110) ||
@@ -123,11 +125,13 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
frame-dwMaxVideoFrameBufferSize;
}
- if (!(format-flags UVC_FMT_FLAG_COMPRESSED)
+ if ((!(format-flags UVC_FMT_FLAG_COMPRESSED) ||
+ format-fcc == V4L2_PIX_FMT_MJPEG )
stream-dev-quirks UVC_QUIRK_FIX_BANDWIDTH
stream-intf-num_altsetting 1) {
u32 interval;
u32 bandwidth;
+ unsigned int best_psize = 3 * 1024;
interval = (ctrl-dwFrameInterval 10)
? ctrl-dwFrameInterval
@@ -139,13 +143,17 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
* high-speed devices) per second and add the UVC header size
* (assumed to be 12 bytes long).
*/
- bandwidth = frame-wWidth * frame-wHeight / 8 * format-bpp;
+ bandwidth = frame-dwMaxVideoFrameBufferSize;
+ //bandwidth = frame-wWidth * frame-wHeight / 8 * format-bpp;
bandwidth *= 1000 / interval + 1;
bandwidth /= 1000;
if (stream-dev-udev-speed == USB_SPEED_HIGH)
bandwidth /= 8;
bandwidth += 12;
+ /* add 20% more, in some cases it is still not enough */
+ bandwidth *= 1.2;
+
/* The bandwidth estimate is too low for many cameras. Don't use
* maximum packet sizes lower than 1024 bytes to try and work
* around the problem. According to measurements done on two
@@ -153,12 +161,39 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
* resolutions working while not preventing two simultaneous
* VGA streams at 15 fps.
*/
+ pr_debug(%s: calculated bandwidth: %u for %u(fps); (before
1024 workaround).,
+__func__, bandwidth, 1000/interval);
bandwidth = max_t(u32, bandwidth, 1024);
+ i = 0;
+ for (i = 0; i stream-intf-num_altsetting; ++i) {
+ struct usb_host_interface *alts;
+ struct usb_host_endpoint *ep;
+ unsigned int psize;
+
+ alts = stream-intf-altsetting[i];
+ ep = uvc_find_endpoint(alts,
+ stream-header.bEndpointAddress);
+ if (ep == NULL)
+ continue;
+
+ psize = le16_to_cpu(ep-desc.wMaxPacketSize);
+ psize = (psize 0x07ff) * (1 + ((psize 11) 3));
+ if ((psize = bandwidth psize = best_psize) ||
+ (i == stream-intf-num_altsetting - 1)) {
+ if (bandwidth psize)
+ pr_debug(%s: trying psize=%u even if
+bandwidth=%u, __func__,
+psize, bandwidth);
+ best_psize = psize;
+ break;
+ }
+ }
+
pr_debug(%s: rewrite dwMaxPayloadTransferSize=%u to %u.,
- __func__, ctrl-dwMaxPayloadTransferSize, bandwidth);
+ __func__, ctrl-dwMaxPayloadTransferSize, best_psize);
- ctrl-dwMaxPayloadTransferSize = bandwidth;
+ ctrl-dwMaxPayloadTransferSize = best_psize;
}
}
@@ -1099,11 +1134,19 @@ static int uvc_init_video(struct uvc_streaming *stream,
gfp_t gfp_flags)
/* Check if the bandwidth is high enough
[Linux-uvc-devel] [PATCH 1/3] Initial patch to use dynamic_debug system
it make possible use of fine tunable system.
We can set exact verbosity.
Use case:
this will enablle all message in module uvcvideo:
echo module uvcvideo +p /sys/kernel/debug/dynamic_debug/control
this will disable message of function uvc_v4l2_do_ioctl:
echo func uvc_v4l2_do_ioctl -p /sys/kernel/debug/dynamic_debug/control
Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net
---
drivers/media/video/uvc/uvc_queue.c |8 ++-
drivers/media/video/uvc/uvc_v4l2.c |2 +
drivers/media/video/uvc/uvc_video.c | 137 ---
3 files changed, 120 insertions(+), 27 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_queue.c
b/drivers/media/video/uvc/uvc_queue.c
index 36f3c58..19e6cba 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -137,6 +137,9 @@ int uvc_alloc_buffers(struct uvc_video_queue *queue,
unsigned int nbuffers,
void *mem = NULL;
int ret;
+ pr_debug(%s: nbuffers %u; buflength: %u, __func__,
+ nbuffers, buflength);
+
if (nbuffers UVC_MAX_VIDEO_BUFFERS)
nbuffers = UVC_MAX_VIDEO_BUFFERS;
@@ -347,8 +350,9 @@ int uvc_dequeue_buffer(struct uvc_video_queue *queue,
if ((ret = uvc_queue_waiton(buf, nonblocking)) 0)
goto done;
- uvc_trace(UVC_TRACE_CAPTURE, Dequeuing buffer %u (%u, %u bytes).\n,
- buf-buf.index, buf-state, buf-buf.bytesused);
+ pr_debug(%s: Dequeuing buffer %u (%u, %u/%u bytes)., __func__,
+ buf-buf.index, buf-state,
+ buf-buf.length, buf-buf.bytesused);
switch (buf-state) {
case UVC_BUF_STATE_ERROR:
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index fa89ebf..3ba2563 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -559,6 +559,8 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
struct uvc_streaming *stream = handle-stream;
long ret = 0;
+ pr_debug(%s: cmd: %u, __func__, cmd);
+
switch (cmd) {
/* Query capabilities */
case VIDIOC_QUERYCAP:
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index 43f955e..9a95a62 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -73,6 +73,8 @@ int uvc_query_ctrl(struct uvc_device *dev, __u8 query, __u8
unit,
{
int ret;
+ pr_debug(%s, __func__);
+
ret = __uvc_query_ctrl(dev, query, unit, intfnum, cs, data, size,
UVC_CTRL_CONTROL_TIMEOUT);
if (ret != size) {
@@ -92,6 +94,8 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
struct uvc_frame *frame = NULL;
unsigned int i;
+ pr_debug(%s, __func__);
+
if (ctrl-bFormatIndex = 0 ||
ctrl-bFormatIndex stream-nformats)
return;
@@ -110,9 +114,13 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
if (!(format-flags UVC_FMT_FLAG_COMPRESSED) ||
(ctrl-dwMaxVideoFrameSize == 0
- stream-dev-uvc_version 0x0110))
+ stream-dev-uvc_version 0x0110)) {
+ pr_debug(%s: rewrite dwMaxVideoFrameSize=%u to %u.,
+__func__, ctrl-dwMaxVideoFrameSize,
+ frame-dwMaxVideoFrameBufferSize);
ctrl-dwMaxVideoFrameSize =
frame-dwMaxVideoFrameBufferSize;
+ }
if (!(format-flags UVC_FMT_FLAG_COMPRESSED)
stream-dev-quirks UVC_QUIRK_FIX_BANDWIDTH
@@ -146,6 +154,9 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
*/
bandwidth = max_t(u32, bandwidth, 1024);
+ pr_debug(%s: rewrite dwMaxPayloadTransferSize=%u to %u.,
+ __func__, ctrl-dwMaxPayloadTransferSize, bandwidth);
+
ctrl-dwMaxPayloadTransferSize = bandwidth;
}
}
@@ -157,6 +168,8 @@ static int uvc_get_video_ctrl(struct uvc_streaming *stream,
__u16 size;
int ret;
+ pr_debug(%s, __func__);
+
size = stream-dev-uvc_version = 0x0110 ? 34 : 26;
if ((stream-dev-quirks UVC_QUIRK_PROBE_DEF)
query == UVC_GET_DEF)
@@ -233,6 +246,20 @@ static int uvc_get_video_ctrl(struct uvc_streaming *stream,
uvc_fixup_video_ctrl(stream, ctrl);
ret = 0;
+ pr_debug(%s: bmHint: %u; bFormatIndex: %u; bFrameIndex: %u;
+dwFrameInterval: %u; wKeyFrameRate: %u;
+wCompQuality: %u; wCompWindowSize: %u; wDelay: %u;
+dwMaxVideoFrameSize %u; dwMaxPayloadTransferSize: %u,
+ __func__, ctrl-bmHint,
+ ctrl-bFormatIndex,
+ ctrl-bFrameIndex,
+ ctrl-dwFrameInterval,
+ ctrl-wKeyFrameRate,
+ ctrl
[Linux-uvc-devel] [PATCH 0/0] description
Hi, i had some time to play with some webcams i had access to, and made some patches for it. Please take a look, if you think this is a good idea, i'll try to make them more clean. -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [PATCH 3/3] Make video fixup more robust
Am Sonntag, den 06.03.2011, 12:47 +0100 schrieb Laurent Pinchart:
Hi Alexey,
On Sunday 06 March 2011 11:57:15 Alexey Fisher wrote:
A description of how you're making it more robust would be nice.
Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net
---
drivers/media/video/uvc/uvc_video.c | 59
++- 1 files changed, 51 insertions(+), 8
deletions(-)
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c index 64bd1d6..5380189 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -92,10 +92,9 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream, {
struct uvc_format *format;
struct uvc_frame *frame = NULL;
+ struct usb_host_endpoint *ep;
unsigned int i;
- pr_debug(%s, __func__);
-
if (ctrl-bFormatIndex = 0 ||
ctrl-bFormatIndex stream-nformats)
return;
@@ -112,6 +111,9 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream, if (frame == NULL)
return;
+ pr_debug(%s: %s %ux%u, __func__,
+format-name, frame-wWidth, frame-wHeight);
+
if (!(format-flags UVC_FMT_FLAG_COMPRESSED) ||
(ctrl-dwMaxVideoFrameSize == 0
stream-dev-uvc_version 0x0110) ||
@@ -123,11 +125,13 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream, frame-dwMaxVideoFrameBufferSize;
}
- if (!(format-flags UVC_FMT_FLAG_COMPRESSED)
+ if ((!(format-flags UVC_FMT_FLAG_COMPRESSED) ||
+ format-fcc == V4L2_PIX_FMT_MJPEG )
stream-dev-quirks UVC_QUIRK_FIX_BANDWIDTH
stream-intf-num_altsetting 1) {
u32 interval;
u32 bandwidth;
+ unsigned int best_psize = 3 * 1024;
interval = (ctrl-dwFrameInterval 10)
? ctrl-dwFrameInterval
@@ -139,13 +143,17 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream, * high-speed devices) per second and add the UVC header size
* (assumed to be 12 bytes long).
*/
- bandwidth = frame-wWidth * frame-wHeight / 8 * format-bpp;
+ bandwidth = frame-dwMaxVideoFrameBufferSize;
+ //bandwidth = frame-wWidth * frame-wHeight / 8 * format-bpp;
Why ? The whole point of your patch set is to work around untrusted
dwMaxVideoFrameBufferSize values.
bandwidth *= 1000 / interval + 1;
bandwidth /= 1000;
if (stream-dev-udev-speed == USB_SPEED_HIGH)
bandwidth /= 8;
bandwidth += 12;
+ /* add 20% more, in some cases it is still not enough */
+ bandwidth *= 1.2;
+
That's not the kind of things I can accept with very very good arguments. I
don't want to break some cameras just to lower the size of the V4L2 buffers
allocated by the driver.
/* The bandwidth estimate is too low for many cameras. Don't use
* maximum packet sizes lower than 1024 bytes to try and work
* around the problem. According to measurements done on two
@@ -153,12 +161,39 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream, * resolutions working while not preventing two simultaneous
* VGA streams at 15 fps.
*/
+ pr_debug(%s: calculated bandwidth: %u for %u(fps); (before 1024
workaround)., + __func__, bandwidth,
1000/interval);
bandwidth = max_t(u32, bandwidth, 1024);
+ i = 0;
+ for (i = 0; i stream-intf-num_altsetting; ++i) {
+ struct usb_host_interface *alts;
+ struct usb_host_endpoint *ep;
+ unsigned int psize;
+
+ alts = stream-intf-altsetting[i];
+ ep = uvc_find_endpoint(alts,
+ stream-header.bEndpointAddress);
+ if (ep == NULL)
+ continue;
+
+ psize = le16_to_cpu(ep-desc.wMaxPacketSize);
+ psize = (psize 0x07ff) * (1 + ((psize 11) 3));
+ if ((psize = bandwidth psize = best_psize) ||
+ (i == stream-intf-num_altsetting - 1)) {
+ if (bandwidth psize)
+ pr_debug(%s: trying psize=%u even if
+bandwidth=%u, __func__,
+psize, bandwidth);
+ best_psize = psize;
+ break;
+ }
+ }
+
pr_debug(%s: rewrite dwMaxPayloadTransferSize=%u to %u.,
- __func__, ctrl-dwMaxPayloadTransferSize, bandwidth);
+ __func__, ctrl
Re: [Linux-uvc-devel] [PATCH 1/3] Initial patch to use dynamic_debug system
Hi,
i need your feedback about the dynamic_debug patch. For me it is most
important. It make digging in to uvc code easier, especially for
beginners like me.
Am Sonntag, den 06.03.2011, 11:57 +0100 schrieb Alexey Fisher:
it make possible use of fine tunable system.
We can set exact verbosity.
Use case:
this will enablle all message in module uvcvideo:
echo module uvcvideo +p /sys/kernel/debug/dynamic_debug/control
this will disable message of function uvc_v4l2_do_ioctl:
echo func uvc_v4l2_do_ioctl -p /sys/kernel/debug/dynamic_debug/control
Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net
---
drivers/media/video/uvc/uvc_queue.c |8 ++-
drivers/media/video/uvc/uvc_v4l2.c |2 +
drivers/media/video/uvc/uvc_video.c | 137
---
3 files changed, 120 insertions(+), 27 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_queue.c
b/drivers/media/video/uvc/uvc_queue.c
index 36f3c58..19e6cba 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -137,6 +137,9 @@ int uvc_alloc_buffers(struct uvc_video_queue *queue,
unsigned int nbuffers,
void *mem = NULL;
int ret;
+ pr_debug(%s: nbuffers %u; buflength: %u, __func__,
+ nbuffers, buflength);
+
if (nbuffers UVC_MAX_VIDEO_BUFFERS)
nbuffers = UVC_MAX_VIDEO_BUFFERS;
@@ -347,8 +350,9 @@ int uvc_dequeue_buffer(struct uvc_video_queue *queue,
if ((ret = uvc_queue_waiton(buf, nonblocking)) 0)
goto done;
- uvc_trace(UVC_TRACE_CAPTURE, Dequeuing buffer %u (%u, %u bytes).\n,
- buf-buf.index, buf-state, buf-buf.bytesused);
+ pr_debug(%s: Dequeuing buffer %u (%u, %u/%u bytes)., __func__,
+ buf-buf.index, buf-state,
+ buf-buf.length, buf-buf.bytesused);
switch (buf-state) {
case UVC_BUF_STATE_ERROR:
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index fa89ebf..3ba2563 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -559,6 +559,8 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
struct uvc_streaming *stream = handle-stream;
long ret = 0;
+ pr_debug(%s: cmd: %u, __func__, cmd);
+
switch (cmd) {
/* Query capabilities */
case VIDIOC_QUERYCAP:
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index 43f955e..9a95a62 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -73,6 +73,8 @@ int uvc_query_ctrl(struct uvc_device *dev, __u8 query, __u8
unit,
{
int ret;
+ pr_debug(%s, __func__);
+
ret = __uvc_query_ctrl(dev, query, unit, intfnum, cs, data, size,
UVC_CTRL_CONTROL_TIMEOUT);
if (ret != size) {
@@ -92,6 +94,8 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
struct uvc_frame *frame = NULL;
unsigned int i;
+ pr_debug(%s, __func__);
+
if (ctrl-bFormatIndex = 0 ||
ctrl-bFormatIndex stream-nformats)
return;
@@ -110,9 +114,13 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
if (!(format-flags UVC_FMT_FLAG_COMPRESSED) ||
(ctrl-dwMaxVideoFrameSize == 0
- stream-dev-uvc_version 0x0110))
+ stream-dev-uvc_version 0x0110)) {
+ pr_debug(%s: rewrite dwMaxVideoFrameSize=%u to %u.,
+ __func__, ctrl-dwMaxVideoFrameSize,
+ frame-dwMaxVideoFrameBufferSize);
ctrl-dwMaxVideoFrameSize =
frame-dwMaxVideoFrameBufferSize;
+ }
if (!(format-flags UVC_FMT_FLAG_COMPRESSED)
stream-dev-quirks UVC_QUIRK_FIX_BANDWIDTH
@@ -146,6 +154,9 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming
*stream,
*/
bandwidth = max_t(u32, bandwidth, 1024);
+ pr_debug(%s: rewrite dwMaxPayloadTransferSize=%u to %u.,
+ __func__, ctrl-dwMaxPayloadTransferSize, bandwidth);
+
ctrl-dwMaxPayloadTransferSize = bandwidth;
}
}
@@ -157,6 +168,8 @@ static int uvc_get_video_ctrl(struct uvc_streaming
*stream,
__u16 size;
int ret;
+ pr_debug(%s, __func__);
+
size = stream-dev-uvc_version = 0x0110 ? 34 : 26;
if ((stream-dev-quirks UVC_QUIRK_PROBE_DEF)
query == UVC_GET_DEF)
@@ -233,6 +246,20 @@ static int uvc_get_video_ctrl(struct uvc_streaming
*stream,
uvc_fixup_video_ctrl(stream, ctrl);
ret = 0;
+ pr_debug(%s: bmHint: %u; bFormatIndex: %u; bFrameIndex: %u;
+ dwFrameInterval: %u; wKeyFrameRate: %u;
+ wCompQuality: %u; wCompWindowSize: %u; wDelay: %u;
+ dwMaxVideoFrameSize %u
Re: [Linux-uvc-devel] Logitech C910 -- trying to run more than one.
Hi Philip,
i probably will not solve your problem but i wont to take a look on it.
Can you please apply attached debug patch and send me the log.
this patch was made on top of fd2b6dd22743f7c96f7c6e97d49ff5f4b422e741
Make sure you have CONFIG_DYNAMIC_DEBUG=y enabled. To start dynamic
debug you need do as root:
echo module uvcvideo +p /sys/kernel/debug/dynamic_debug/control
echo func uvc_video_decode_end -p
/sys/kernel/debug/dynamic_debug/control
echo func uvc_video_decode_start -p
/sys/kernel/debug/dynamic_debug/control
echo func uvc_video_decode_data -p
/sys/kernel/debug/dynamic_debug/control
echo func uvc_video_decode_isoc -p
/sys/kernel/debug/dynamic_debug/control
echo func uvc_video_complete -p
/sys/kernel/debug/dynamic_debug/control
echo func uvc_v4l2_do_ioctl -p
/sys/kernel/debug/dynamic_debug/control
and start video with this, it will make onlöy one shot:
gst-launch-0.10 -v v4l2src num-buffers=1 ! jpegdec ! ffmpegcolorspace !
autovideosink
Am Sonntag, den 06.03.2011, 17:30 -0500 schrieb Philip Gladstone:
It turned out that my kernel had an old uvcvideo module which didn't
have the right debug log messages, and so I'm in the process of
upgrading to a current kernel version. So far, I've managed to render my
machine unbootable [it is a little embedded linux box].
Philip
On 3/6/2011 6:14 AM, Laurent Pinchart wrote:
Hi Philip,
On Sunday 20 February 2011 21:57:24 Philip Gladstone wrote:
I attached two C910s to a small linux box, and ran into the 'Failed to
submit URB' problem.
When I look at the descriptors for this camera, I think I understand the
problem. I'm capturing at 5 Mpixels and I'm trying two cameras.
VideoStreaming Interface Descriptor:
bLength38
bDescriptorType36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex28
bmCapabilities 0x01
Still image supported
wWidth 2592
wHeight 1944
dwMinBitRate403107840
dwMaxBitRate806215680
dwMaxVideoFrameBufferSize10077696
dwDefaultFrameInterval100
bFrameIntervalType 3
dwFrameInterval( 0) 100
dwFrameInterval( 1) 133
dwFrameInterval( 2) 200
The video frame size is set to 10Mb. This is surprisingly large as
actual frames captured with MJPEG on this camera are typically 500kb or
less. When I checked the descriptor for the uncompressed version of the
same frame, it came back with the same value of dwMaxVideoFrameBufferSize
(effectively 16 bits per pixel). The values for min/max bit rate are
(correctly) calculated from the frame intervals and the buffer size.
The uvcvideo driver doesn't use the dwMaxVideoFrameBufferSize field to
compute
the required bandwidth but queries the device at runtime instead.
You can enable the UVC_TRACE_VIDEO trace flag to get the driver to print the
bandwidth requested by the device to the kernel log.
Typical JPEG compression gets down to 1 bit per pixel, and 2 bits is
very unusual.
What I want to know is what the impact would be of defining a new QUIRK
that overrode the frame buffer size for compressed frames and calculated
them at (say) 2 bits per pixel?
Do other webcams get this right?
You would be surprised by how many webcams get things wrong.
--
Regards,
Alexey
diff --git a/drivers/media/video/uvc/uvc_driver.c b/drivers/media/video/uvc/uvc_driver.c
index e41285a..f00a317 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -303,9 +303,9 @@ static int uvc_parse_format(struct uvc_device *dev,
case UVC_VS_FORMAT_FRAME_BASED:
n = buffer[2] == UVC_VS_FORMAT_UNCOMPRESSED ? 27 : 28;
if (buflen n) {
- uvc_trace(UVC_TRACE_DESCR, device %d videostreaming
- interface %d FORMAT error\n,
- dev-udev-devnum,
+ pr_debug(%s: device %d videostreaming
+ interface %d FORMAT error.,
+ __func__, dev-udev-devnum,
alts-desc.bInterfaceNumber);
return -EINVAL;
}
@@ -337,9 +337,9 @@ static int uvc_parse_format(struct uvc_device *dev,
case UVC_VS_FORMAT_MJPEG:
if (buflen 11) {
- uvc_trace(UVC_TRACE_DESCR, device %d videostreaming
- interface %d FORMAT error\n,
- dev-udev-devnum,
+ pr_debug(%s: device %d videostreaming
+ interface %d FORMAT error.,
+ __func__, dev-udev-devnum,
alts-desc.bInterfaceNumber);
return -EINVAL;
}
@@ -353,9 +353,9 @@ static int uvc_parse_format(struct uvc_device *dev,
case UVC_VS_FORMAT_DV:
if (buflen 9) {
- uvc_trace(UVC_TRACE_DESCR, device %d videostreaming
- interface %d
Re: [Linux-uvc-devel] Fixing bandwidth quirk ***just inquire
Compressed stream is not really predictable. Every camera can act differently, so my be it will brick more than fix. Do your camera need this quirk? Am Donnerstag, den 10.03.2011, 19:43 + schrieb modysama: modysama asmaa.elassal.student at pua.edu.eg writes: Fixing bandwidth quirk is only works for uncompressed stream the YUYV format, it doesn’t work for MJPG. Why??need explain, please ___ Linux-uvc-devel mailing list Linux-uvc-devel at 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 -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Fixing bandwidth quirk ***just inquire
Raw stream is simple, for example YUYV need 16 bits to describe one pixel. No extra action is done on this stream. Even if the camera lie about it setting, we can still calculate it our self. For example if you use YUYV 640x480 with 30 fps: 640×480×16=4915200 bit or 4915200/8=614400 byte so dwMaxVideoFrameSize=614400. Same value you will get if you check lsusb -vd : To calculate bandwidth uvc use framerate. This value deiced, can you or not use your webcam with some particular settings on your usb hub. Compressed stream can use different compression algorithms, most populas is jpeg. Compression depend on texture what your cam capture, and on the time it has for compression. For example if camera forced to push 30fps, it will choice speed against compression rate. With compressed stream we can't say for sure, how match bandwidth do we need. On cam's i tested it variate between 6% and 30% of uncompressed stream. If you provide wrong bandwidth to the cam, it will just freeze or send you black frame. So, manufacture should provide correct settings and they are different for each cam. Or we should add new quirk setting, what adjust compression ratio too. But before, we need some test cases, to find worts compression ratio, and add statistic collection to the driver. Am Freitag, den 11.03.2011, 00:35 +0200 schrieb Asmaa ElAssal: Yes, sir, but I use another one. I received that analysiz from someone on that site about that old webcam. I want to understand the problem of that previous cam Excuse me, Could you more explain Compressed stream is not really predictable and it's different of the uncompressed format. On Thu, Mar 10, 2011 at 11:59 PM, Alexey Fisher bug-tr...@fisher-privat.net wrote: Compressed stream is not really predictable. Every camera can act differently, so my be it will brick more than fix. Do your camera need this quirk? Am Donnerstag, den 10.03.2011, 19:43 + schrieb modysama: modysama asmaa.elassal.student at pua.edu.eg writes: Fixing bandwidth quirk is only works for uncompressed stream the YUYV format, it doesn’t work for MJPG. Why??need explain, please ___ Linux-uvc-devel mailing list Linux-uvc-devel at 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 -- Regards, Alexey -- Asmaa El-said Rashad Pharos University of Alex Computer Department 5th year ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Creative VF0700 Live! Cam Chat HD works everywhere, except highly distorted video in Skype
Am Sonntag, den 27.03.2011, 07:18 -0400 schrieb Benson Bear: I have a UVC web cam, the Creative Live! Cam Chat HD, and am trying to run it under Fedora 14's 2.6.35.11-83.fc14.i686.PAE kernel, using X.Org X Server 1.9.4, and the current intel driver for the on-chip integrated graphics of a core I3 processor. This camera works nicely in everything like cheese, camstream, camorama, xawtv and guvcview. It doesn't work in the one thing I want it for: Skype. I am pretty sure this is Skype's fault, exacerbated by its closed nature and the fact it has not had an upgrade for a long while. But I wonder if anyone has an idea whether this could be fixed or whether I should just return the camera for restocking fee and keep trying other ones. (I note that the V0700 doesn't appear to be officially supported, but since it works in everything else, Skype seems to be to blame). Here is the ID from lsusb: Bus 001 Device 009: ID 041e:4088 Creative Technology, Ltd What usb and uvcvideo report in /var/log/messages: [52201.794788] usb 1-1.5: Product: VF0700 Live! Cam Chat HD [52201.794793] usb 1-1.5: Manufacturer: Creative Technology Ltd. [52201.794797] usb 1-1.5: SerialNumber: 0L220009 [52201.799938] uvcvideo: Found UVC 1.00 device VF0700 Live! Cam Chat HD (041e:4088) I can include in subsequent messages more of v4l-info and lsusb details, but for now the most potentially useful observations seem to me to be the following: v4l-info seems to be saying that the camera has multiple possible video capture modes: video capture VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE) index : 0 type: VIDEO_CAPTURE flags : 0 description : YUV 4:2:2 (YUYV) pixelformat : 0x56595559 [YUYV] VIDIOC_ENUM_FMT(1,VIDEO_CAPTURE) index : 1 type: VIDEO_CAPTURE flags : 1 description : MJPEG pixelformat : 0x47504a4d [MJPG] VIDIOC_G_FMT(VIDEO_CAPTURE) type: VIDEO_CAPTURE fmt.pix.width : 320 fmt.pix.height : 240 fmt.pix.pixelformat : 0x56595559 [YUYV] fmt.pix.field : NONE fmt.pix.bytesperline: 640 fmt.pix.sizeimage : 153600 fmt.pix.colorspace : SRGB fmt.pix.priv: 0 Guvcview, it seems (I keep saying it seems because I don't really understand this) to allow us to see what the cameras streaming output looks like when interpreted in different ways. By default it chooses MJPG, but if I choose YUYV, it produces a distorted output that looks *very similar* to the distorted output produced by Skype. This leads me to believe that perhaps the only problem is that Skype is not interpreting the output of the camera correctly, and all that perhaps need be done is to force the camera to put out the kind of output Skype thinks it is getting. This does not seem to require any conversion anywhere since the camera appears to be capable of putting out the YUYV that I speculate Skype thinks it is getting. Does any expert think this is a possibility, and if so would it be hard to force the camera to just put out a selected one of its native modes? I assume the UVC interface already allows one to force a certain mode output but that Skype messes this up and the solution would have to be to set the default mode differently. Perhaps not as there is not option for any of this on the two v4l control panels I am aware of. (Other things tried to far, to no avail: setting Skype to various capture sizes and frame rates, thinking perhaps it was confused about thos, and also trying the fake video stream thing that is floating around from a view years ago. Haven't gotten too far with that as of yet.) please attach output of lsusb -vd 041e:4088 lsusb and please attach a dump of first frame luvcview -f yuv -s 320x240 -c (you will get file frame000.raw) Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Creative VF0700 Live! Cam Chat HD works everywhere, except highly distorted video in Skype
Am Dienstag, den 29.03.2011, 00:48 -0400 schrieb Benson Bear: On Mon, Mar 28, 2011 at 5:36 AM, Alexey Fisher bug-tr...@fisher-privat.net wrote: The reason can be... lost packets by usb controller... or may be camera send only this parts... or hmm... You seem to be suggesting some hardware problem or a defect with the camera? This seems very unlikely to me: recall the camera seems to works out of the box with cheese, camorama, xawtv, camstream, guvcview. Only with skype and in some cases with lucvview do I get this distorted pattern, which is the same sort of pattern subjectively that I get when I run the gstreamer pipeline without the conversion element in it. I also have now tested in in Windows 7 and it seems to work fine there out of the box as well. Can you please attach dmesg with trace, to enable trace you need: sudo rmmod uvcvideo sudo modprobe uvcvideo trace=0x Don't know quite what you mean? dmesg output during what? I attached the dmesg output when the camera is plugged in, followed by two runs of luvcview (the first two command lines below). I Except I edited out huge amounts of these lines throughout (which are very suggestive of a format mismatch as well): uvcvideo: Dropping payload (out of sync). Can you please also try different frame rates with yuv. Yes, before, per instruction, I used the default. But I now find that lucview gives nice looking results for any frame rate above 17. In other words, luvcview -f yuv -s 320x240 -d /dev/video1 -i 17 does not work, but luvcview -f yuv -s 320x240 -d /dev/video1 -i 18 luvcview -f yuv -s 320x240 -d /dev/video1 -i 19 etc all do work. Your webcam support(or claim) fallowing framerates 30, 25, 20, 15, 10, 5 (fps). If you set 17fps, luvcview will tell you, that this framerate is unsupported and fall back to 15fps; if you tray set 18 it will fallback to 20fps. Dropping payload (out of sync). mean - camera send more data als driver is expecting. The same tell this message Frame complete (overflow). Skype prefer to use 640x480 (in some situations 320x240) at 15fps uncompressed stream. This is the reason why you hit this bug. Cheese prefer to use biggest framerate - 30fps, compressed stream. this is the reason why cheese do not hit this bug. Driver should know the frame rate to check if some packets are lost or not. I assume your webcam just ignore framerate setting and push the maximum it can. Try to use UVC_QUIRK_RESTRICT_FRAME_RATE workaround: sudo rmmod uvcvideo sudo modprobe uvcvideo quirks=0x200 Regrads, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] [PATCH] Add support for Creative VF0700 Live! Cam Chat HD.
The camera requires the UVC_QUIRK_RESTRICT_FRAME_RATE quirk.
Reported-by: Benson Bear benson.b...@gmail.com
Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net
---
drivers/media/video/uvc/uvc_driver.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index 0baa464..f8a1579 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -1970,6 +1970,17 @@ MODULE_PARM_DESC(timeout, Streaming control requests
timeout);
* though they are compliant.
*/
static struct usb_device_id uvc_ids[] = {
+ /* Creative VF0700 Live! Cam Chat HD.
+* Produce more frames als commited,
+* so it partially overwrite buffer with new frame */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x041e,
+ .idProduct= 0x4088,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_RESTRICT_FRAME_RATE },
/* Genius eFace 2025 */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
--
1.7.4.1
___
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, Am Montag, den 28.03.2011, 20:26 +0400 schrieb Клиентский отдел \Кибернет\: Hi. I'm using zoneminder server to record events from usb uvcvideo web-cams. 3 same A4tech PK-836MJ works well with 352x288 yuyv streaming if I modify /sys/module/uvcvideo/parameters/quirks to 128. 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. total bandwith utilisation of my usb hub. There is no other root usb 2.0 hubs on my motherboard. I'm use 2.6.36-gentoo-r8 kernel. I explore /drivers/media/video/uvc. As I understand, the camera reports that it can much better resolutiont than 640x480x24bit with 30fps. Is it possible to manualy decrease bandwith of these cameras? Or maybe it is possible to patch uvc_video.c? can you please send more info about this cam. lsusb -v will be good start. 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. If you need more cams, you need reduce resolution and/or frame rate. Not all webcams support different frame rates. Regards, Alexey. ___ 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
Am Donnerstag, den 31.03.2011, 15:04 +0400 schrieb Клиентский отдел
\Кибернет\:
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.
I'm using asus AT5MN10-I with Atom-330 (dual-core). It has only 1 root
usb2.0 hub (4 embedded usb connectors) and 1 PCI slot with VIA VT6212L
chip - another usb 2.0 root hub with 5 additional usb connectors.
When I attempt to change streaming resolution of any camera in the hub
to 640x480 - other three cameras stop streaming with an error - no
space on left device. As I understood this error means that whole
bandwith of usb-bus related to the user utilised. 8 streaming cameras
with apache, ffmpeg, zoneminder and other processes itilizin less than
60% of my CPUs. How can I tweak uvcvideo driver or maybe usb-bus to
recalculate the bandwith of my cameras to start working with 640x480
resolution.
This worksation doesn't have X and other non-server environment. I'm
using p/s2 keyboard and ssh. There is no plans to use any other usb-type
devices, web-cams only.
Camera information from luvcview. Zoneminder can work with cameras only
when I use YUYV. When I attempt to change streaming to RGB3 - only one
camera streaming, 3 other stop responding. I think this happens bacause
quirk parametr belong only to YUYV stareaming.
uvcvideo recalculate all uncompressed pixel formats.
RGB3 consume more band width than YUYV.
RGB3 and BGR3 use 3 Bytes, also 24 bits.
640 * 480 * 24bit * 30fps / 8 = 26 MByte/s (max 2 cams)
YUYV - 16 bit
... = 17 MByte/s
YU12, YV12 - 12 bit
... = 13 MByte/s
YU12 or YV12 should be the best solution.
Theoretical calculations tells me that 4 cameras with 640x480 YUYV with
25-30fps can stream at the same time...
YOur calculation is over optemistic. In my previous email i told you
maximal 3.4 cams, the 0.4 do not count.
Sebastian pointed Don't forget that the 480Mbit/s is the theoretical
maximum speed. In real live it is less.
SDL information:
Video driver: x11
A window manager is available
Device information:
Device path: /dev/video0
{ pixelformat = 'YUYV', description = 'YUV 4:2:2 (YUYV)' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 352, height = 288 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 176, height = 144 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
{ pixelformat = 'RGB3', description = 'RGB3' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 352, height = 288 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 176, height = 144 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
{ pixelformat = 'BGR3', description = 'BGR3' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 352, height = 288 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 176, height = 144 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
{ pixelformat = 'YU12', description = 'YU12' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 352, height = 288 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 176, height = 144 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
{ pixelformat = 'YV12', description = 'YV12' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30,
{ discrete: width = 352, height = 288 }
Time interval between frame: 1/30,
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/30,
{ discrete: width = 176, height = 144 }
Time interval between frame: 1/30,
{ discrete: width = 160, height = 120 }
Time interval between frame: 1/30,
I do not need this information. I need result of lsusb -vd :,
- is the usb id of your webcam.
--
Regards,
Alexey
___
Linux-uvc-devel mailing list
Re: [Linux-uvc-devel] How to 'quirk' more than 3 same YUYV streaming web-cams
Hi,
ok, i see your webcam support only 30fps, so you can't reduce it. And it
has audio port. I hope, you do not captures sound it... it take some
bandwidth too. I do not see any chance to get more cams.
Am Donnerstag, den 31.03.2011, 17:08 +0400 schrieb Клиентский отдел
\Кибернет\:
31.03.2011 17:03, Alexey Fisher пишет:
lsusb -vd
Hi Alexey.
Here it is.
Bus 001 Device 009: ID 0ac8:c40a Z-Star Microelectronics Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x0ac8 Z-Star Microelectronics Corp.
idProduct 0xc40a
bcdDevice1.00
iManufacturer 1 A4 TECH
iProduct2 A4 TECH USB2.0 PC Camera J
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 593
bNumInterfaces 4
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 2 A4 TECH USB2.0 PC Camera J
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 2 A4 TECH USB2.0 PC Camera J
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 79
dwClockFrequency 24.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 0x00040a0e
Auto-Exposure Mode
Auto-Exposure Priority
Exposure Time (Absolute)
Zoom (Absolute)
PanTilt (Absolute)
Privacy
VideoControl Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 2
bSourceID 1
wMaxMultiplier 0
bControlSize2
bmControls 0x547f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
White Balance Temperature
Power Line Frequency
White Balance Temperature, Auto
Digital Multiplier
iProcessing 0
bmVideoStandards 0x 9
None
SECAM - 625/50
VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 2
iTerminal 0
VideoControl Interface Descriptor:
bLength28
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {5dc717a9-1941-da11-ae0e-000d56ac7b4c}
bNumControl14
bNrPins 1
baSourceID( 0) 1
bControlSize3
bmControls( 0) 0xf9
bmControls( 1) 0x1f
bmControls( 2) 0x80
iExtension 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
Re: [Linux-uvc-devel] Genius UVC webcam problem on ARM
Hallo, Firs of all, your raw stream is working because it use smaller frame size. Raw stream is 160x120, jpeg is 640x480. I'm sure if you will test same size for jpeg it will work too. Second, your cam provide correct data for raw stream (bitrate, urb size). But also provide same settings for jpeg. It mean even if jpeg consume lesser than raw, we do what webcam request us. The quirk=128 make recalculation only for raw stream. We still need quirk for jpeg stream. Am Mittwoch, den 13.04.2011, 17:13 +0200 schrieb Zdeněk Materna: Hello, output of lsusb and uvcvideo traces are attached. Output from lsusb is from PC, because lsusb on ARM kit doesn't support verbose parameter. Best regards, Zdenek Materna Dne 13. dubna 2011 9:46 Alexey Fisher bug-tr...@fisher-privat.net napsal(a): Hallo, On Di, 2011-04-12 at 19:52 +0200, Zdeněk Materna wrote: Sorry for another mail. It works with quirks 128 and uncompressed YUV format. Is there any way how to use compressed MJPEG? Should I try compile never uvcvideo driver? please attach the output of lsusb -vd : : - is the usb id number of your webcam and please attach complete trace of uvcvideo. You can enable it with: sudo rmmod uvcvideo sudo modprobe uvcvideo trace=0x -- Regards, Alexey ___ 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] [patch] gather compression statistic for MJPEG (and other formats)
Here is updated patch against newest git master tree.
On Mi, 2011-04-13 at 21:24 +0200, Alexey Fisher wrote:
This is patch catch the biggest frame size and calculate compression
ratio.
Usage:
modprobe statistic=1
start capture some thing. The best possability to catch biggest frame is
to record lots of moving text. Point your camera to monitore and open
terminal with dmesg or some thing :D
After stop, result will be in dmesg.
Testers are welcome.
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
--
Regards,
Alexey
diff --git a/drivers/media/video/uvc/uvc_driver.c b/drivers/media/video/uvc/uvc_driver.c
index 6459b8c..abe3057 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -47,6 +47,7 @@ unsigned int uvc_no_drop_param;
static unsigned int uvc_quirks_param = -1;
unsigned int uvc_trace_param;
unsigned int uvc_timeout_param = UVC_CTRL_STREAMING_TIMEOUT;
+unsigned int uvc_statistic_param;
/*
* Video formats
@@ -1954,6 +1955,8 @@ module_param_named(trace, uvc_trace_param, uint, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(trace, Trace level bitmask);
module_param_named(timeout, uvc_timeout_param, uint, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(timeout, Streaming control requests timeout);
+module_param_named(statistic, uvc_statistic_param, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(statistic, Gether framesize/compressions statistic);
/*
* Driver initialization and cleanup
diff --git a/drivers/media/video/uvc/uvc_queue.c b/drivers/media/video/uvc/uvc_queue.c
index f14581b..a588e68 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -348,8 +348,9 @@ int uvc_dequeue_buffer(struct uvc_video_queue *queue,
if ((ret = uvc_queue_waiton(buf, nonblocking)) 0)
goto done;
- uvc_trace(UVC_TRACE_CAPTURE, Dequeuing buffer %u (%u, %u bytes).\n,
- buf-buf.index, buf-state, buf-buf.bytesused);
+ uvc_trace(UVC_TRACE_CAPTURE, Dequeuing buffer %u (%u, %u/%u bytes).\n,
+ buf-buf.index, buf-state,
+ buf-buf.length, buf-buf.bytesused);
switch (buf-state) {
case UVC_BUF_STATE_ERROR:
@@ -371,6 +372,9 @@ int uvc_dequeue_buffer(struct uvc_video_queue *queue,
goto done;
}
+ if (buf-buf.bytesused queue-max_used_lengh)
+ queue-max_used_lengh = buf-buf.bytesused;
+
list_del(buf-stream);
__uvc_query_buffer(buf, v4l2_buf);
diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c
index fc766b9..992e90e 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -873,6 +873,43 @@ static void uvc_uninit_video(struct uvc_streaming *stream, int free_buffers)
if (free_buffers)
uvc_free_urb_buffers(stream);
+
+ if (stream-print_statistic) {
+ struct uvc_format *cur_format = stream-cur_format;
+ struct uvc_frame *cur_frame = stream-cur_frame;
+ struct uvc_streaming_control *ctrl = stream-ctrl;
+ unsigned int fps = 1000/ctrl-dwFrameInterval;
+ unsigned int bandwidth;
+
+ bandwidth = stream-queue.max_used_lengh;
+ bandwidth *= fps + 1;
+ bandwidth /= 1000;
+ if (stream-dev-udev-speed == USB_SPEED_HIGH)
+bandwidth /= 8;
+ bandwidth += 12;
+
+
+ pr_info(%s: Statistic for %s %ux%u@%u, __func__,
+ cur_format-name,
+ cur_frame-wWidth,
+ cur_frame-wHeight, fps);
+ pr_info(provided dwMaxVideoFrameBufferSize %u,
+ calculated bpp %u,
+ cur_frame-dwMaxVideoFrameBufferSize,
+ cur_frame-dwMaxVideoFrameBufferSize /
+ (cur_frame-wWidth * cur_frame-wHeight / 8));
+ pr_info(collected max_used_size %u, calculated bpp %d,
+ stream-queue.max_used_lengh,
+ stream-queue.max_used_lengh /
+ (cur_frame-wWidth * cur_frame-wHeight / 8));
+ pr_info(provided dwMaxPayloadTransferSize %u,
+ ctrl-dwMaxPayloadTransferSize);
+ pr_info(calculated dwMaxPayloadTransferSize %u,
+ bandwidth);
+
+ stream-queue.max_used_lengh = 0;
+ stream-print_statistic = 0;
+ }
}
/*
@@ -1071,6 +1108,9 @@ static int uvc_init_video(struct uvc_streaming *stream, gfp_t gfp_flags)
}
}
+ if (uvc_statistic_param)
+ stream-print_statistic = 1;
+
return 0;
}
diff --git a/drivers/media/video/uvc/uvcvideo.h b/drivers/media/video/uvc/uvcvideo.h
index 45f01e7..fb743f1 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -403,6 +403,9 @@ struct uvc_video_queue {
struct list_head mainqueue;
struct list_head irqqueue;
+
+ /* collect statistic */
+ unsigned int max_used_lengh;
};
struct uvc_video_chain {
@@ -462,6 +465,8 @@ struct uvc_streaming {
__u32 sequence;
__u8 last_fid;
+
+ unsigned int print_statistic;
};
enum uvc_device_state {
@@ -537,6 +542,7 @@ extern unsigned int uvc_clock_param;
extern
Re: [Linux-uvc-devel] [PATCH] Add support for Creative VF0700 Live! Cam Chat HD.
Hi Laurent, did you received this patch?
Am Dienstag, den 29.03.2011, 13:48 +0200 schrieb Alexey Fisher:
The camera requires the UVC_QUIRK_RESTRICT_FRAME_RATE quirk.
Reported-by: Benson Bear benson.b...@gmail.com
Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net
---
drivers/media/video/uvc/uvc_driver.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index 0baa464..f8a1579 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -1970,6 +1970,17 @@ MODULE_PARM_DESC(timeout, Streaming control requests
timeout);
* though they are compliant.
*/
static struct usb_device_id uvc_ids[] = {
+ /* Creative VF0700 Live! Cam Chat HD.
+ * Produce more frames als commited,
+ * so it partially overwrite buffer with new frame */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x041e,
+ .idProduct= 0x4088,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_RESTRICT_FRAME_RATE },
/* Genius eFace 2025 */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] [patch] jpeg compression hacks. Tester are welcome!!!
Hallo all,
here is patch (against current master git) to add two new quirks and
some more debug string to see what happening :D
The quirks are:
UVC_QUIRK_FIX_JPEG_BANDWIDTH 0x0040
/* to recalculate bandwidth needed for jpeg compressed stream */
UVC_QUIRK_DISABLE_URB_1024 0x0400
/* by default we use safe bandwith restriction, to less than 1024 *
* this quirk disables this restriction. So if you need URB less than
* 1024, use this quirk. It will work only with FIX*BANDWIDTH quirk. */
Also i added module option jpeg_comp to change calculation for
bandwith. Default is 4bpp, 1 is maximal compression, 16bpp is no
compression, just normal raw stream.
This patch also gather statistic about used buffers. It will report
biggest used buffer. You will need it to calculate best value for
jpeg_comp option.
Usage. Recalculate bandwidth for jpeg and disable 1024 restriction:
sudo rmmod uvcvideo sudo modprobe quirks=0x440
reduce calculated bandwith to minimum:
sudo rmmod uvcvideo sudo modprobe quirks=0x440 jpeg_comp=1
for more info enable trace=0x and seek for messages like:
...
[25495.869580] uvcvideo: Device requested 703 B/frame bandwidth.
[25495.869583] uvcvideo: Selecting alternate setting 5 (800 B/frame
bandwidth).
[25495.869758] uvcvideo: Allocated 5 URB buffers of 32x800 bytes each.
...
[25501.959475] uvcvideo: Biggest used buffer: 1382400/106438. Format:
MJPEG 960x720@15.
--
Regards,
Alexey
diff --git a/drivers/media/video/uvc/uvc_driver.c b/drivers/media/video/uvc/uvc_driver.c
index 6459b8c..7ab9e3d 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -47,6 +47,7 @@ unsigned int uvc_no_drop_param;
static unsigned int uvc_quirks_param = -1;
unsigned int uvc_trace_param;
unsigned int uvc_timeout_param = UVC_CTRL_STREAMING_TIMEOUT;
+unsigned int uvc_jpeg_comp_param;
/*
* Video formats
@@ -348,7 +349,10 @@ static int uvc_parse_format(struct uvc_device *dev,
strlcpy(format-name, MJPEG, sizeof format-name);
format-fcc = V4L2_PIX_FMT_MJPEG;
format-flags = UVC_FMT_FLAG_COMPRESSED;
- format-bpp = 0;
+ if ((uvc_jpeg_comp_param 0) ( 16 = uvc_jpeg_comp_param))
+ format-bpp = uvc_jpeg_comp_param;
+ else
+ format-bpp = 4;
ftype = UVC_VS_FRAME_MJPEG;
break;
@@ -1954,6 +1958,10 @@ module_param_named(trace, uvc_trace_param, uint, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(trace, Trace level bitmask);
module_param_named(timeout, uvc_timeout_param, uint, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(timeout, Streaming control requests timeout);
+module_param_named(jpeg_comp, uvc_jpeg_comp_param, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(jpeg_comp, Overvrite default compression value for jpeg.
+ This needed to recalculate bandwidth.
+ Max: 1; Min: 16(no compression); Default: 4);
/*
* Driver initialization and cleanup
diff --git a/drivers/media/video/uvc/uvc_queue.c b/drivers/media/video/uvc/uvc_queue.c
index f14581b..a588e68 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -348,8 +348,9 @@ int uvc_dequeue_buffer(struct uvc_video_queue *queue,
if ((ret = uvc_queue_waiton(buf, nonblocking)) 0)
goto done;
- uvc_trace(UVC_TRACE_CAPTURE, Dequeuing buffer %u (%u, %u bytes).\n,
- buf-buf.index, buf-state, buf-buf.bytesused);
+ uvc_trace(UVC_TRACE_CAPTURE, Dequeuing buffer %u (%u, %u/%u bytes).\n,
+ buf-buf.index, buf-state,
+ buf-buf.length, buf-buf.bytesused);
switch (buf-state) {
case UVC_BUF_STATE_ERROR:
@@ -371,6 +372,9 @@ int uvc_dequeue_buffer(struct uvc_video_queue *queue,
goto done;
}
+ if (buf-buf.bytesused queue-max_used_lengh)
+ queue-max_used_lengh = buf-buf.bytesused;
+
list_del(buf-stream);
__uvc_query_buffer(buf, v4l2_buf);
diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c
index fc766b9..e595dd4 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -119,8 +119,10 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
ctrl-dwMaxVideoFrameSize =
frame-dwMaxVideoFrameBufferSize;
- if (!(format-flags UVC_FMT_FLAG_COMPRESSED)
- stream-dev-quirks UVC_QUIRK_FIX_BANDWIDTH
+ if ((!(format-flags UVC_FMT_FLAG_COMPRESSED) ||
+ (format-fcc == V4L2_PIX_FMT_MJPEG))
+ (stream-dev-quirks UVC_QUIRK_FIX_BANDWIDTH ||
+ stream-dev-quirks UVC_QUIRK_FIX_JPEG_BANDWIDTH)
stream-intf-num_altsetting 1) {
u32 interval;
u32 bandwidth;
@@ -149,7 +151,11 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
* resolutions working while not preventing two simultaneous
* VGA streams at 15 fps.
*/
- bandwidth = max_t(u32, bandwidth, 1024);
+ if(!(stream-dev-quirks UVC_QUIRK_DISABLE_URB_1024))
+ bandwidth = max_t(u32, bandwidth, 1024);
+
+
Re: [Linux-uvc-devel] Genius UVC webcam problem on ARM
There is new patch. With this patch you can recalculate bandwith for jpeg stream. See my post in list and try it: [patch] jpeg compression hacks. Tester are welcome!!! -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Fixing bandwidth quirk ***just inquire
There is new patch. With this patch you can recalculate bandwith for jpeg stream. See my post in list and try it: [patch] jpeg compression hacks. Tester are welcome!!! On Fr, 2011-03-11 at 10:38 +, Paulo Assis wrote: Hi, 2011/3/11 Alexey Fisher bug-tr...@fisher-privat.net: Raw stream is simple, for example YUYV need 16 bits to describe one pixel. No extra action is done on this stream. Even if the camera lie about it setting, we can still calculate it our self. For example if you use YUYV 640x480 with 30 fps: 640×480×16=4915200 bit or 4915200/8=614400 byte so dwMaxVideoFrameSize=614400. Same value you will get if you check lsusb -vd : To calculate bandwidth uvc use framerate. This value deiced, can you or not use your webcam with some particular settings on your usb hub. Compressed stream can use different compression algorithms, most populas is jpeg. Compression depend on texture what your cam capture, and on the time it has for compression. For example if camera forced to push 30fps, it will choice speed against compression rate. actually it can also only send a part of the sensor image, just try any of the logitech HD models, when you pick a different frame rate (even for the same resolution) you will get a very different image (more or less zoomed), The compression ration seems more or less the same (at least the quantization tables don't seem to alter). With compressed stream we can't say for sure, how match bandwidth do we need. On cam's i tested it variate between 6% and 30% of uncompressed stream. If you provide wrong bandwidth to the cam, it will just freeze or send you black frame. Yes but you can decide on a maximum (say 40% :D) that is never reached, this is better than allocating 100% of the bandwidth and can be the difference between a working camera and a non working one. So, manufacture should provide correct settings and they are different for each cam. I totally agree with this, but unfortunately, this is not always the case, hence the need for the quirks. In fact the bandwidth settings should vary at least according to resolution, but what wee see in some cases is that manufactures just use the same value for every situation (laziness related maybe). Or we should add new quirk setting, what adjust compression ratio too. But before, we need some test cases, to find worts compression ratio, and add statistic collection to the driver. V4l2 has jpeg compression related ioctls, Laurent event created a patch for uvc, but for some reason it was never integrated, in fact I add support for it in guvcview, but as I remember although the cameras I tested seem to accepted it, it didn't really cause any change in the compression ratio, so I doubt very much it would cause any on the bandwidth settings. Regards, Paulo Am Freitag, den 11.03.2011, 00:35 +0200 schrieb Asmaa ElAssal: Yes, sir, but I use another one. I received that analysiz from someone on that site about that old webcam. I want to understand the problem of that previous cam Excuse me, Could you more explain Compressed stream is not really predictable and it's different of the uncompressed format. On Thu, Mar 10, 2011 at 11:59 PM, Alexey Fisher bug-tr...@fisher-privat.net wrote: Compressed stream is not really predictable. Every camera can act differently, so my be it will brick more than fix. Do your camera need this quirk? Am Donnerstag, den 10.03.2011, 19:43 + schrieb modysama: modysama asmaa.elassal.student at pua.edu.eg writes: Fixing bandwidth quirk is only works for uncompressed stream the YUYV format, it doesn’t work for MJPG. Why??need explain, please ___ Linux-uvc-devel mailing list Linux-uvc-devel at 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 -- Regards, Alexey -- Asmaa El-said Rashad Pharos University of Alex Computer Department 5th year ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [patch] gather compression statistic for MJPEG (and other formats)
On Fr, 2011-04-22 at 11:47 +0200, Laurent Pinchart wrote:
Hi Alexey,
On Thursday 14 April 2011 09:53:52 Alexey Fisher wrote:
Here is updated patch against newest git master tree.
On Mi, 2011-04-13 at 21:24 +0200, Alexey Fisher wrote:
This is patch catch the biggest frame size and calculate compression
ratio.
Usage:
modprobe statistic=1
start capture some thing. The best possability to catch biggest frame is
to record lots of moving text. Point your camera to monitore and open
terminal with dmesg or some thing :D
After stop, result will be in dmesg.
Testers are welcome.
Thanks for the patch. What do you use it for ?
For user who like to play with compressed stream. But i send already a
revoked version of it. I attach it again.
It add option for recalculating bandwidth.
--
Regards,
Alexey
diff --git a/drivers/media/video/uvc/uvc_driver.c b/drivers/media/video/uvc/uvc_driver.c
index 6459b8c..7ab9e3d 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -47,6 +47,7 @@ unsigned int uvc_no_drop_param;
static unsigned int uvc_quirks_param = -1;
unsigned int uvc_trace_param;
unsigned int uvc_timeout_param = UVC_CTRL_STREAMING_TIMEOUT;
+unsigned int uvc_jpeg_comp_param;
/*
* Video formats
@@ -348,7 +349,10 @@ static int uvc_parse_format(struct uvc_device *dev,
strlcpy(format-name, MJPEG, sizeof format-name);
format-fcc = V4L2_PIX_FMT_MJPEG;
format-flags = UVC_FMT_FLAG_COMPRESSED;
- format-bpp = 0;
+ if ((uvc_jpeg_comp_param 0) ( 16 = uvc_jpeg_comp_param))
+ format-bpp = uvc_jpeg_comp_param;
+ else
+ format-bpp = 4;
ftype = UVC_VS_FRAME_MJPEG;
break;
@@ -1954,6 +1958,10 @@ module_param_named(trace, uvc_trace_param, uint, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(trace, Trace level bitmask);
module_param_named(timeout, uvc_timeout_param, uint, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(timeout, Streaming control requests timeout);
+module_param_named(jpeg_comp, uvc_jpeg_comp_param, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(jpeg_comp, Overvrite default compression value for jpeg.
+ This needed to recalculate bandwidth.
+ Max: 1; Min: 16(no compression); Default: 4);
/*
* Driver initialization and cleanup
diff --git a/drivers/media/video/uvc/uvc_queue.c b/drivers/media/video/uvc/uvc_queue.c
index f14581b..a588e68 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -348,8 +348,9 @@ int uvc_dequeue_buffer(struct uvc_video_queue *queue,
if ((ret = uvc_queue_waiton(buf, nonblocking)) 0)
goto done;
- uvc_trace(UVC_TRACE_CAPTURE, Dequeuing buffer %u (%u, %u bytes).\n,
- buf-buf.index, buf-state, buf-buf.bytesused);
+ uvc_trace(UVC_TRACE_CAPTURE, Dequeuing buffer %u (%u, %u/%u bytes).\n,
+ buf-buf.index, buf-state,
+ buf-buf.length, buf-buf.bytesused);
switch (buf-state) {
case UVC_BUF_STATE_ERROR:
@@ -371,6 +372,9 @@ int uvc_dequeue_buffer(struct uvc_video_queue *queue,
goto done;
}
+ if (buf-buf.bytesused queue-max_used_lengh)
+ queue-max_used_lengh = buf-buf.bytesused;
+
list_del(buf-stream);
__uvc_query_buffer(buf, v4l2_buf);
diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c
index fc766b9..e595dd4 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -119,8 +119,10 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
ctrl-dwMaxVideoFrameSize =
frame-dwMaxVideoFrameBufferSize;
- if (!(format-flags UVC_FMT_FLAG_COMPRESSED)
- stream-dev-quirks UVC_QUIRK_FIX_BANDWIDTH
+ if ((!(format-flags UVC_FMT_FLAG_COMPRESSED) ||
+ (format-fcc == V4L2_PIX_FMT_MJPEG))
+ (stream-dev-quirks UVC_QUIRK_FIX_BANDWIDTH ||
+ stream-dev-quirks UVC_QUIRK_FIX_JPEG_BANDWIDTH)
stream-intf-num_altsetting 1) {
u32 interval;
u32 bandwidth;
@@ -149,7 +151,11 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
* resolutions working while not preventing two simultaneous
* VGA streams at 15 fps.
*/
- bandwidth = max_t(u32, bandwidth, 1024);
+ if(!(stream-dev-quirks UVC_QUIRK_DISABLE_URB_1024))
+ bandwidth = max_t(u32, bandwidth, 1024);
+
+ uvc_trace(UVC_TRACE_VIDEO, Revrite dwMaxPayloadTransferSize %u
+ to %u, ctrl-dwMaxPayloadTransferSize, bandwidth);
ctrl-dwMaxPayloadTransferSize = bandwidth;
}
@@ -238,6 +244,21 @@ static int uvc_get_video_ctrl(struct uvc_streaming *stream,
uvc_fixup_video_ctrl(stream, ctrl);
ret = 0;
+ uvc_trace(UVC_TRACE_VIDEO, %s: %s; bmHint: %u; bFormatIndex: %u;
+ bFrameIndex: %u; dwFrameInterval: %u; wKeyFrameRate: %u;
+ wCompQuality: %u; wCompWindowSize: %u; wDelay: %u;
+ dwMaxVideoFrameSize %u; dwMaxPayloadTransferSize: %u,
+ __func__, uvc_query_name(query), ctrl-bmHint
Re: [Linux-uvc-devel] [patch] jpeg compression hacks. Tester are welcome!!!
On Fr, 2011-04-15 at 19:39 +0200, Alexey Fisher wrote: Hallo all, here is patch (against current master git) to add two new quirks and some more debug string to see what happening :D The quirks are: UVC_QUIRK_FIX_JPEG_BANDWIDTH 0x0040 /* to recalculate bandwidth needed for jpeg compressed stream */ UVC_QUIRK_DISABLE_URB_1024 0x0400 /* by default we use safe bandwith restriction, to less than 1024 * * this quirk disables this restriction. So if you need URB less than * 1024, use this quirk. It will work only with FIX*BANDWIDTH quirk. */ Also i added module option jpeg_comp to change calculation for bandwith. Default is 4bpp, 1 is maximal compression, 16bpp is no compression, just normal raw stream. This patch also gather statistic about used buffers. It will report biggest used buffer. You will need it to calculate best value for jpeg_comp option. Usage. Recalculate bandwidth for jpeg and disable 1024 restriction: sudo rmmod uvcvideo sudo modprobe quirks=0x440 reduce calculated bandwith to minimum: sudo rmmod uvcvideo sudo modprobe quirks=0x440 jpeg_comp=1 for more info enable trace=0x and seek for messages like: ... [25495.869580] uvcvideo: Device requested 703 B/frame bandwidth. [25495.869583] uvcvideo: Selecting alternate setting 5 (800 B/frame bandwidth). [25495.869758] uvcvideo: Allocated 5 URB buffers of 32x800 bytes each. ... [25501.959475] uvcvideo: Biggest used buffer: 1382400/106438. Format: MJPEG 960x720@15. Lets continue the conversation hier :D it is the proper place for it. Hi Alexey, On Friday 15 April 2011 19:43:38 Alexey Fisher wrote: There is new patch. With this patch you can recalculate bandwith for jpeg stream. See my post in list and try it: [patch] jpeg compression hacks. Tester are welcome!!! Now I understand what your patch is for :-) One issue that you forgot to take into account is that, in addition to average bandwidth requirements, cameras also have peak bandwidth requirements. At low frame rates, an image could be transmitted with a lower bandwidth, but that would require buffering capabilities on the camera side to store the image and transmit it over a longer period of time. Most cameras have very little buffer memory, and thus require a high bandwidth even at low frame rates. Depending on the hardware MJPEG encoder, the average bandwidth for a frame will not match the peak bandwidth requirements. I thick you mean this part of code: - bandwidth = max_t(u32, bandwidth, 1024); + if(!(stream-dev-quirks UVC_QUIRK_DISABLE_URB_1024)) + bandwidth = max_t(u32, bandwidth, 1024); but i did it optional. User who has good cam can try to use unsafe option. May be i need to mark it highly dangerous, use on your own risk!!! :) -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] may be unsupported webcam
On Mo, 2011-06-06 at 21:41 -0400, Randy wrote: This webcam is in an HP G7-1070US laptop lsusb Bus 002 Device 007: ID 0461:4de7 Primax Electronics, Ltd please attach lsusb_dump file after you execute the command: sudo lsusb -vvd 0461:4de7 lsusb_dump Info from Windows7 HP Webcam-101 Hardware ID's USB\VID_0461PID_4DE7REV_0005MI_00 USB\VID_0461PID_4DE7MI_00 Compatible ID's USB\Class_0eSubClass_03Prot_00 USB\Class_0eSubClass_03 USB\Class_0e Power data Current power state: D3 Power capabilities: 0019 PDCAP_D0_SUPPORTED PDCAP_D3_SUPPORTED PDCAP_WAKE_FROM_D0_SUPPORTED Power state mappings: S0 - D0 S1 - D2 S2 - D2 S3 - D2 S4 - D2 S5 - D3 Driver files C:\Windows\system32\drivers\ksthunk.sys C:\Windows\system32\drivers\usbvideo.sys file version 6.1.7600.16385(win7_rtm.090713-1255) If there is any more I can do the get this cam up and working let me know Thanks -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
On Mo, 2011-06-06 at 17:31 -0700, Carl Michal wrote: Hello, I'm having some trouble with a Quanta integrated webcam. It identifies itself as: Laptop_Integrated_Webcam_2HDM, usbid: 0408:2fb1. This is built in to a Dell XPS-15 (L501X). The uvcvideo module works, but the video stutters and has some distortions, even at low resolutions and frame rates. With the Camera Output set to MJPG (in guvcview) Ignoring empty buffer ... messages occur with most glitches. If the output is set to YV12, the errors look like: VIDIOC_DQBUF - Unable to dequeue buffer : Input/output error Error grabbing image libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? With cheese, the video preview looks ok, but video capture is unusable - the video stutters badly at low resolution, and the capture hangs at high resolution (the program doesn't hang, but after a couple of frames no more get captured). It looks more like cheese bug. If video preview works fine then webcam do it too. Take a look at this bug: https://bugzilla.gnome.org/show_bug.cgi?id=564957 -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Logitech C910 -- trying to run more than one.
On Do, 2011-06-02 at 22:58 -0400, Philip Gladstone wrote: Sorry for the long delay in responding. I will try these changes. did you used this patch? http://www.mail-archive.com/linux-uvc-devel@lists.berlios.de/msg05724.html However, the scoop on the other various patches is as follows: in 2592x1944 mode, at 10fps, 4bpp for mjpg, the fix_jpeg_bandwidth makes things worse with 3476 B/frame rather than the device specified 3060 B/frame. It probably just filed, is it? There is a check, if dwMaxPayloadTransferSize is bigger than max possible it will just exit. Probably it will be good to make on sure recalculated is not bigger. At 2592x1944 mode at 5fps, 2bpp for mjpg, the fix_jpeg_bandwidth ends up at 1024 B/frame, which allows me to run the three cameras that I want. At 2592x1944 mode at 5fps, 4bpp for mjpg, the fix_jpeg_bandwidth ends up at 1984 B/frame, which allows me to run two cameras, but not the third. However, these numbers are funny. The frame size for 2592x1944x4bpp is 2.5 Megabytes or 20 Mbits. At 5fps, this is 100 Mbits/sec. There should be ample bandwidth to support three of these streams. To be honest, I don't understand the units of the B/frame. Can someone explain it to me? from the uvc source code: ... bandwidth = stream-ctrl.dwMaxPayloadTransferSize; ... uvc_trace(UVC_TRACE_VIDEO, Device requested %u B/frame bandwidth.\n, bandwidth); From this link: http://rember-english-word.googlecode.com/svn-history/r6/trunk/USB_Video_Class_1.0a.pdf dwMaxPayloadTransferSize: Specifies the maximum number of bytes that the device can transmit or receive in a single payload transfer. Philip On 07-Mar-11 5:53 AM, Alexey Fisher wrote: Hi Philip, i probably will not solve your problem but i wont to take a look on it. Can you please apply attached debug patch and send me the log. this patch was made on top of fd2b6dd22743f7c96f7c6e97d49ff5f4b422e741 Make sure you have CONFIG_DYNAMIC_DEBUG=y enabled. To start dynamic debug you need do as root: echo module uvcvideo +p /sys/kernel/debug/dynamic_debug/control echo func uvc_video_decode_end -p /sys/kernel/debug/dynamic_debug/control echo func uvc_video_decode_start -p /sys/kernel/debug/dynamic_debug/control echo func uvc_video_decode_data -p /sys/kernel/debug/dynamic_debug/control echo func uvc_video_decode_isoc -p /sys/kernel/debug/dynamic_debug/control echo func uvc_video_complete -p /sys/kernel/debug/dynamic_debug/control echo func uvc_v4l2_do_ioctl -p /sys/kernel/debug/dynamic_debug/control and start video with this, it will make onlöy one shot: gst-launch-0.10 -v v4l2src num-buffers=1 ! jpegdec ! ffmpegcolorspace ! autovideosink Am Sonntag, den 06.03.2011, 17:30 -0500 schrieb Philip Gladstone: It turned out that my kernel had an old uvcvideo module which didn't have the right debug log messages, and so I'm in the process of upgrading to a current kernel version. So far, I've managed to render my machine unbootable [it is a little embedded linux box]. Philip On 3/6/2011 6:14 AM, Laurent Pinchart wrote: Hi Philip, On Sunday 20 February 2011 21:57:24 Philip Gladstone wrote: I attached two C910s to a small linux box, and ran into the 'Failed to submit URB' problem. When I look at the descriptors for this camera, I think I understand the problem. I'm capturing at 5 Mpixels and I'm trying two cameras. VideoStreaming Interface Descriptor: bLength38 bDescriptorType36 bDescriptorSubtype 7 (FRAME_MJPEG) bFrameIndex28 bmCapabilities 0x01 Still image supported wWidth 2592 wHeight 1944 dwMinBitRate403107840 dwMaxBitRate806215680 dwMaxVideoFrameBufferSize10077696 dwDefaultFrameInterval100 bFrameIntervalType 3 dwFrameInterval( 0) 100 dwFrameInterval( 1) 133 dwFrameInterval( 2) 200 The video frame size is set to 10Mb. This is surprisingly large as actual frames captured with MJPEG on this camera are typically 500kb or less. When I checked the descriptor for the uncompressed version of the same frame, it came back with the same value of dwMaxVideoFrameBufferSize (effectively 16 bits per pixel). The values for min/max bit rate are (correctly) calculated from the frame intervals and the buffer size. The uvcvideo driver doesn't use the dwMaxVideoFrameBufferSize field to compute the required bandwidth but queries the device at runtime instead. You can enable the UVC_TRACE_VIDEO trace flag to get the driver to print the bandwidth requested
Re: [Linux-uvc-devel] Z-Star USB Digital Microscope
On So, 2011-06-12 at 10:08 +0800, hagar wrote: On 06/12/2011 06:03 AM, Paulo Assis wrote: Hi, 2011/6/11 hagarha...@iinet.net.au: I have a Z-Star USB Digital Microscope It is supposed to have the following specifications - ManID - 0ac8 DevID - 3610 Image - 1.3 MP Bus - USB 2.0 Mag - 20x - 400x - ( Manual - More like Focus ) Capture - Still Video Modes - 1600x1200, 1280x960, 800x600, 640x480, 352x288, 320x240, 160x120 There seems to be something wrong with the camera specs: 1600 x 1200 = 1.9 MP so I wouldn't trust these values that much. Sorry - Missed a bit - 1.3 MegaPixels (interpolated to 2M) Resolutions - 1600x1200, 1280x1024, 1280x960, 1024x768, 800x600, 640x480, 352x288, 320x240, 160x120 The first list was a summary - I missed the next one! Color - 32 bit Flicker - 50/60 Hz Frames - Max 30fps under 600 Lus brightness Shutter - 1 sec to 1/1000 sec Light - 8 led dimmable (Manual) (Software ??) Power - 5V DC from USB Now uvcvideo works but not fully uvcvideo only allows resolutions of - 640x480, 352x288, 320x240, 160x120 Does the camera only presents 1 pixel format (MJPG, YUYV,..) for streaming ? Available resolutions may vary depending on the image format you choose for streaming (if more than one choice present) and they can also change if you use a usb1 port instead of a usb2. I used a USB 2.0 port. And the uvcvideo driver will only return a max of 640x480 resolution. I dont know the camera lowlevel format. But I was trying to look at the driver code to see if there was any per-camera options.- I couldnt find any! This is usb(_universal_ serial buss) video class driver. Camera should tell the driver what it can. would a lsusb -v -d 0ac8:3610 help ? Yes! -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
On Sa, 2011-06-11 at 21:55 -0700, Carl Michal wrote: 2011/6/7 Alexey Fisher bug-tr...@fisher-privat.net: On Mo, 2011-06-06 at 17:31 -0700, Carl Michal wrote: Hello, I'm having some trouble with a Quanta integrated webcam. It identifies itself as: Laptop_Integrated_Webcam_2HDM, usbid: 0408:2fb1. This is built in to a Dell XPS-15 (L501X). The uvcvideo module works, but the video stutters and has some distortions, even at low resolutions and frame rates. With the Camera Output set to MJPG (in guvcview) Ignoring empty buffer ... messages occur with most glitches. I would say the camera is not returning the full frame (or maybe empty ones) for same reason. If the output is set to YV12, the errors look like: VIDIOC_DQBUF - Unable to dequeue buffer : Input/output error Error grabbing image libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? YV12 is a format returned by libv4l, and it's obtained by decompressing the MJPG stream, so in fact the camera is still in MJPG format like above. With cheese, the video preview looks ok, but video capture is unusable - the video stutters badly at low resolution, and the capture hangs at high resolution (the program doesn't hang, but after a couple of frames no more get captured). Probably the same situation as above (incomplete or empty frames) You should also increase uvc video verbosity and check dmesg for errors. From the looks of it I would say you are having some hardware sync issues, did you try all possible resolutions and frame rates ? Do these issues happen in all formats Regards, Paulo I've looked through the traces I've gotten with this webcam a little and noticed something that may help. The out of sync errors are always starts with a sequence like this: Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 1, bytes: 64684. Jun 11 21:41:59 uvcvideo: EOF in empty payload. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 1 (4, 64684 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 1. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 2, bytes: 64728. Jun 11 21:41:59 uvcvideo: EOF in empty payload. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 2 (4, 64728 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 2. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: Frame complete (FID bit toggled) buf: 3, bytes: 63504. Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 0, bytes: 1072. Jun 11 21:41:59 uvcvideo: EOF in empty payload. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 3 (4, 63504 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 3. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 0 (4, 1072 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 0. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: Dropping payload (out of sync). Jun 11 21:41:59 uvcvideo: Dropping payload (out of sync). I've added a couple of fields to the frame complete messages to indicate which buffer is marked as complete and how many bytes were delivered to it. Most frames are terminated with EOF, but occasionally an FID and EOF are found in the same packet. So two buffers are marked as completed, but the second one shouldn't be (I don't think). Any advice on where to look next? Try fid quirk: uvcvideo quirks=0x10 for more quirks see: grep QUIRK linux-2.6/drivers/media/video/uvc/uvcvideo.h UVC_QUIRK_STATUS_INTERVAL 0x0001 UVC_QUIRK_PROBE_MINMAX 0x0002 UVC_QUIRK_PROBE_EXTRAFIELDS 0x0004 UVC_QUIRK_BUILTIN_ISIGHT 0x0008 UVC_QUIRK_STREAM_NO_FID 0x0010 UVC_QUIRK_IGNORE_SELECTOR_UNIT 0x0020 UVC_QUIRK_FIX_BANDWIDTH 0x0080 UVC_QUIRK_PROBE_DEF 0x0100 UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200 -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Z-Star USB Digital Microscope
On So, 2011-06-12 at 13:51 +0800, hagar wrote: On 06/12/2011 01:40 PM, Alexey Fisher wrote: On So, 2011-06-12 at 10:08 +0800, hagar wrote: On 06/12/2011 06:03 AM, Paulo Assis wrote: Hi, 2011/6/11 hagarha...@iinet.net.au: I have a Z-Star USB Digital Microscope It is supposed to have the following specifications - ManID - 0ac8 DevID - 3610 Image - 1.3 MP Bus - USB 2.0 Mag - 20x - 400x - ( Manual - More like Focus ) Capture - Still Video Modes - 1600x1200, 1280x960, 800x600, 640x480, 352x288, 320x240, 160x120 There seems to be something wrong with the camera specs: 1600 x 1200 = 1.9 MP so I wouldn't trust these values that much. Sorry - Missed a bit - 1.3 MegaPixels (interpolated to 2M) Resolutions - 1600x1200, 1280x1024, 1280x960, 1024x768, 800x600, 640x480, 352x288, 320x240, 160x120 The first list was a summary - I missed the next one! Color - 32 bit Flicker - 50/60 Hz Frames - Max 30fps under 600 Lus brightness Shutter - 1 sec to 1/1000 sec Light - 8 led dimmable (Manual) (Software ??) Power - 5V DC from USB Now uvcvideo works but not fully uvcvideo only allows resolutions of - 640x480, 352x288, 320x240, 160x120 Does the camera only presents 1 pixel format (MJPG, YUYV,..) for streaming ? Available resolutions may vary depending on the image format you choose for streaming (if more than one choice present) and they can also change if you use a usb1 port instead of a usb2. I used a USB 2.0 port. And the uvcvideo driver will only return a max of 640x480 resolution. I dont know the camera lowlevel format. But I was trying to look at the driver code to see if there was any per-camera options.- I couldnt find any! This is usb(_universal_ serial buss) video class driver. Camera should tell the driver what it can. would a lsusb -v -d 0ac8:3610 help ? Yes! lsusb -v -d 0ac8:3610 Bad news. uvcvideo thins your cam has only 640x480, because your cam tells it has only 640x480. See this part of lsusb info: Bus 001 Device 013: ID 0ac8:3610 Z-Star Microelectronics Corp. Device Descriptor: 8- VideoStreaming Interface Descriptor: bLength26 bDescriptorType36 bDescriptorSubtype 3 (STILL_IMAGE_FRAME) bEndpointAddress0 bNumImageSizePatterns 5 wWidth( 0)640 wHeight( 0) 480 wWidth( 1)352 wHeight( 1) 288 wWidth( 2)320 wHeight( 2) 240 wWidth( 3)176 wHeight( 3) 144 wWidth( 4)160 wHeight( 4) 120 bNumCompressionPatterns 5 8- -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] test results and a patch for timestamps in UVC
Hi, please use uvc_trace(UVC_TRACE_DESCR, or pr_debug instead of printk. So you can enable verbosity only if you need. On Di, 2011-06-07 at 17:56 +0200, Yann Sionneau wrote: Hi again, here is as attached file a new patch that applies to linux 2.6.39 tree (linux-2.6.git, tag v2.6.39). This patch now prints at the end of each stream : (*) total number of PTS (taking into account each packet) (*) total number of SCR (*) total number of ERR (*) number of packets without PTS (nb_missing_pts) (*) number of packets without SCR (nb_missing_scr) It will print as well for each packet (beware, it will hugely flood your syslog) : (*) SCR (*) diff with previous packet's SCR (*) PTS (*) diff with previous packet's PTS Beware, to see the end of stream statistics, you have to scroll up a little bit, it will be somewhere in the end of the per-packet information flood. Some results inline in the e-mail. On 06/06/2011 11:22 PM, Yann Sionneau wrote: Le 06/06/11 19:42, Laurent Pinchart a écrit : Hi Yann, Thanks for the patch. On Friday 03 June 2011 15:48:59 Yann Sionneau wrote: Hi Laurent and the UVC list, Here is a patch [snip] You should take all UVC packets into account, not just the first one for each frame. Yes I don't know why in my head I thought only the first uvc packet would have a header for the frame with timestamps and such, but it makes no sense, each packet has its own header and the start of frame is just signaled by the toggling of the FID :) the important information are - do all frames have a PTS timestamp in their first packet ? It seems so yes, at least on the two webcams I tried with the patch. - do all non-empty packets for a frame have a PTS timestamp, and is it constant through the whole frame as it should be ? Let's modify the patch to count the PTS and SCR of all packets instead of only one per frame in order to sort this out ! I tested with the Logitech HD Pro C910, all packets have a PTS. PTS are indeed constant through the whole frame as it should be. - how many SCR timestamps do we have per frame ? are they constant through the whole frame or do they vary as they should ? Same here ! With the same webcam, all packets have a SCR. The SCR value does vary through each frame, as it should do. The difference between the previous SCR is usually the same, except at a regular interval where there is a jump in SCR values. for example, SCR - SCR_prev would be 7 times the same difference, and then it will change for just one time, and then go back to the old difference for 7 times etc. [snip] Thanks for your review and comments, will submit a new patch ASAP ! -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
Am Samstag, den 11.06.2011, 23:33 -0700 schrieb Carl Michal: On Sun, 12 Jun 2011, Alexey Fisher wrote: On Sa, 2011-06-11 at 21:55 -0700, Carl Michal wrote: 2011/6/7 Alexey Fisher bug-tr...@fisher-privat.net: On Mo, 2011-06-06 at 17:31 -0700, Carl Michal wrote: Hello, I'm having some trouble with a Quanta integrated webcam. It identifies itself as: Laptop_Integrated_Webcam_2HDM, usbid: 0408:2fb1. This is built in to a Dell XPS-15 (L501X). The uvcvideo module works, but the video stutters and has some distortions, even at low resolutions and frame rates. With the Camera Output set to MJPG (in guvcview) Ignoring empty buffer ... messages occur with most glitches. I would say the camera is not returning the full frame (or maybe empty ones) for same reason. If the output is set to YV12, the errors look like: VIDIOC_DQBUF - Unable to dequeue buffer : Input/output error Error grabbing image libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? YV12 is a format returned by libv4l, and it's obtained by decompressing the MJPG stream, so in fact the camera is still in MJPG format like above. With cheese, the video preview looks ok, but video capture is unusable - the video stutters badly at low resolution, and the capture hangs at high resolution (the program doesn't hang, but after a couple of frames no more get captured). Probably the same situation as above (incomplete or empty frames) You should also increase uvc video verbosity and check dmesg for errors. From the looks of it I would say you are having some hardware sync issues, did you try all possible resolutions and frame rates ? Do these issues happen in all formats Regards, Paulo I've looked through the traces I've gotten with this webcam a little and noticed something that may help. The out of sync errors are always starts with a sequence like this: Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 1, bytes: 64684. Jun 11 21:41:59 uvcvideo: EOF in empty payload. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 1 (4, 64684 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 1. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 2, bytes: 64728. Jun 11 21:41:59 uvcvideo: EOF in empty payload. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 2 (4, 64728 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 2. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: Frame complete (FID bit toggled) buf: 3, bytes: 63504. Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 0, bytes: 1072. Jun 11 21:41:59 uvcvideo: EOF in empty payload. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 3 (4, 63504 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 3. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 0 (4, 1072 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 0. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: Dropping payload (out of sync). Jun 11 21:41:59 uvcvideo: Dropping payload (out of sync). I've added a couple of fields to the frame complete messages to indicate which buffer is marked as complete and how many bytes were delivered to it. Most frames are terminated with EOF, but occasionally an FID and EOF are found in the same packet. So two buffers are marked as completed, but the second one shouldn't be (I don't think). Any advice on where to look next? Try fid quirk: uvcvideo quirks=0x10 for more quirks see: grep QUIRK linux-2.6/drivers/media/video/uvc/uvcvideo.h UVC_QUIRK_STATUS_INTERVAL 0x0001 UVC_QUIRK_PROBE_MINMAX 0x0002 UVC_QUIRK_PROBE_EXTRAFIELDS 0x0004 UVC_QUIRK_BUILTIN_ISIGHT 0x0008 UVC_QUIRK_STREAM_NO_FID 0x0010 UVC_QUIRK_IGNORE_SELECTOR_UNIT 0x0020 UVC_QUIRK_FIX_BANDWIDTH 0x0080 UVC_QUIRK_PROBE_DEF 0x0100 UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200 -- Regards, Alexey the fid quirk actually makes it quite a bit worse - many more out of sync errors. None of the other quirks (individually) solve the issue. I stuck in a crude hack to ignore the EOF that is found in the same packet as the fid toggle, and then the number of sync
Re: [Linux-uvc-devel] Z-Star USB Digital Microscope
On Mo, 2011-06-13 at 14:18 +0800, hagar wrote: On 06/12/2011 02:11 PM, Alexey Fisher wrote: On So, 2011-06-12 at 13:51 +0800, hagar wrote: On 06/12/2011 01:40 PM, Alexey Fisher wrote: On So, 2011-06-12 at 10:08 +0800, hagar wrote: On 06/12/2011 06:03 AM, Paulo Assis wrote: Hi, 2011/6/11 hagarha...@iinet.net.au: I have a Z-Star USB Digital Microscope It is supposed to have the following specifications - ManID - 0ac8 DevID - 3610 Image - 1.3 MP Bus - USB 2.0 Mag - 20x - 400x - ( Manual - More like Focus ) Capture - StillVideo Modes - 1600x1200, 1280x960, 800x600, 640x480, 352x288, 320x240, 160x120 There seems to be something wrong with the camera specs: 1600 x 1200 = 1.9 MP so I wouldn't trust these values that much. Sorry - Missed a bit - 1.3 MegaPixels (interpolated to 2M) Resolutions - 1600x1200, 1280x1024, 1280x960, 1024x768, 800x600, 640x480, 352x288, 320x240, 160x120 The first list was a summary - I missed the next one! Color - 32 bit Flicker - 50/60 Hz Frames - Max 30fps under 600 Lus brightness Shutter - 1 sec to 1/1000 sec Light - 8 led dimmable (Manual) (Software ??) Power - 5V DC from USB Now uvcvideo works but not fully uvcvideo only allows resolutions of - 640x480, 352x288, 320x240, 160x120 Does the camera only presents 1 pixel format (MJPG, YUYV,..) for streaming ? Available resolutions may vary depending on the image format you choose for streaming (if more than one choice present) and they can also change if you use a usb1 port instead of a usb2. I used a USB 2.0 port. And the uvcvideo driver will only return a max of 640x480 resolution. I dont know the camera lowlevel format. But I was trying to look at the driver code to see if there was any per-camera options.- I couldnt find any! This is usb(_universal_ serial buss) video class driver. Camera should tell the driver what it can. would a lsusb -v -d 0ac8:3610 help ? Yes! lsusb -v -d 0ac8:3610 Bad news. uvcvideo thins your cam has only 640x480, because your cam tells it has only 640x480. See this part of lsusb info: Bus 001 Device 013: ID 0ac8:3610 Z-Star Microelectronics Corp. Device Descriptor: 8- VideoStreaming Interface Descriptor: bLength26 bDescriptorType36 bDescriptorSubtype 3 (STILL_IMAGE_FRAME) bEndpointAddress0 bNumImageSizePatterns 5 wWidth( 0)640 wHeight( 0) 480 wWidth( 1)352 wHeight( 1) 288 wWidth( 2)320 wHeight( 2) 240 wWidth( 3)176 wHeight( 3) 144 wWidth( 4)160 wHeight( 4) 120 bNumCompressionPatterns 5 According to The WinXP driver ini file the camera is capable of - ( Would all the hex numbers be of use ? ) UVC FUNC_MODE HIGH SPEED RGB24 640x480, 160x120, 176x144, 320x240, 352x288, 800x600, 1024x768, 1280x960, 1280x1024, (?? 1600x1280, 2000x1600, 2560x2048 ?? ) UVC FUNC_MODE FULL SPEED RGB24 640x480, 160x120, 176x144, 320x240, 352x288 UVC FUNC_MODE YUY2 HIGH SPEED VIDEO 640x480, 160x120, 176x144, 320x240, 352x288, 800x600, 1024x768, 1280x960, 1280x1024, (?? 1600x1280, 2000x1600, 2560x2048 ?? ) UVC FUNC_MODE STILL PIN HIGH SPEED RGB24 640x480, 160x120, 176x144, 320x240, 352x288, 800x600, 1024x768, 1280x960, 1280x1024, (?? 1600x1280, 2000x1600, 2560x2048 ?? ) UVC FUNC_MODE STILL PIN FULL SPEED RGB24 640x480, 160x120, 176x144, 320x240, 352x288 Can you please check the driver (some.sys file) it use under win xp. The idea of UVC (usb video class) is zero config functionality. You plug some device and it just work. It is only possible if manufacture write all needed settings in the eeprom of the device (webcam,...). If you plug your device in MacOSX or Windows Vista/7, in any UVC ready OS, you will get same result - max resolution 640x480. If you need to install some thing to get more, then it is not UVC device, at least not 100%. Only good thing you can do for you and all others is to send this device back. Manufactures should learn to read and use uvc specification. -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
On So, 2011-06-12 at 21:05 -0700, Carl Michal wrote: On Sun, 12 Jun 2011, Alexey Fisher wrote: Am Samstag, den 11.06.2011, 23:33 -0700 schrieb Carl Michal: On Sun, 12 Jun 2011, Alexey Fisher wrote: On Sa, 2011-06-11 at 21:55 -0700, Carl Michal wrote: 2011/6/7 Alexey Fisher bug-tr...@fisher-privat.net: On Mo, 2011-06-06 at 17:31 -0700, Carl Michal wrote: Hello, I'm having some trouble with a Quanta integrated webcam. It identifies itself as: Laptop_Integrated_Webcam_2HDM, usbid: 0408:2fb1. This is built in to a Dell XPS-15 (L501X). The uvcvideo module works, but the video stutters and has some distortions, even at low resolutions and frame rates. With the Camera Output set to MJPG (in guvcview) Ignoring empty buffer ... messages occur with most glitches. I would say the camera is not returning the full frame (or maybe empty ones) for same reason. If the output is set to YV12, the errors look like: VIDIOC_DQBUF - Unable to dequeue buffer : Input/output error Error grabbing image libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? YV12 is a format returned by libv4l, and it's obtained by decompressing the MJPG stream, so in fact the camera is still in MJPG format like above. With cheese, the video preview looks ok, but video capture is unusable - the video stutters badly at low resolution, and the capture hangs at high resolution (the program doesn't hang, but after a couple of frames no more get captured). Probably the same situation as above (incomplete or empty frames) You should also increase uvc video verbosity and check dmesg for errors. From the looks of it I would say you are having some hardware sync issues, did you try all possible resolutions and frame rates ? Do these issues happen in all formats Regards, Paulo I've looked through the traces I've gotten with this webcam a little and noticed something that may help. The out of sync errors are always starts with a sequence like this: Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 1, bytes: 64684. Jun 11 21:41:59 uvcvideo: EOF in empty payload. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 1 (4, 64684 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 1. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 2, bytes: 64728. Jun 11 21:41:59 uvcvideo: EOF in empty payload. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 2 (4, 64728 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 2. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: Frame complete (FID bit toggled) buf: 3, bytes: 63504. Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 0, bytes: 1072. Jun 11 21:41:59 uvcvideo: EOF in empty payload. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 3 (4, 63504 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 3. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Jun 11 21:41:59 uvcvideo: Dequeuing buffer 0 (4, 1072 bytes). Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) Jun 11 21:41:59 uvcvideo: Queuing buffer 0. Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll Jun 11 21:41:59 uvcvideo: Dropping payload (out of sync). Jun 11 21:41:59 uvcvideo: Dropping payload (out of sync). I've added a couple of fields to the frame complete messages to indicate which buffer is marked as complete and how many bytes were delivered to it. Most frames are terminated with EOF, but occasionally an FID and EOF are found in the same packet. So two buffers are marked as completed, but the second one shouldn't be (I don't think). Any advice on where to look next? Try fid quirk: uvcvideo quirks=0x10 for more quirks see: grep QUIRK linux-2.6/drivers/media/video/uvc/uvcvideo.h UVC_QUIRK_STATUS_INTERVAL 0x0001 UVC_QUIRK_PROBE_MINMAX 0x0002 UVC_QUIRK_PROBE_EXTRAFIELDS 0x0004 UVC_QUIRK_BUILTIN_ISIGHT 0x0008 UVC_QUIRK_STREAM_NO_FID 0x0010 UVC_QUIRK_IGNORE_SELECTOR_UNIT 0x0020 UVC_QUIRK_FIX_BANDWIDTH 0x0080 UVC_QUIRK_PROBE_DEF 0x0100 UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200 -- Regards, Alexey the fid quirk actually makes it quite a bit worse - many more out of sync errors. None of the other quirks (individually) solve the issue. I stuck
Re: [Linux-uvc-devel] Quanta integrated webcam
Am Montag, den 13.06.2011, 22:48 -0700 schrieb Carl Michal:
Hi,
I think you nailed it. Every frame looks perfect now. The trace shows a
few
of these:
Jun 13 09:24:24 uvcvideo: Dropping payload (error bit set)
but I don't see corrupt frames any more in either MJPG or YUYV (at 640x480
anyway) - in MJPG all the frames have the right size.
There is a some weirdness with frame rates depending on the exposure
setting:
1) Exposure, auto gives 4 options: auto priority mode, manual mode, shutter
priority mode, and aperture priority mode. Auto and shutter don't seem to
be
settable (errors from guvcview when chosen). There is also an Exposure,
auto
priority checkbox.
Frame rates drop dramatically in manual mode (to 10-15fps from 30).
But I can't really complain at this point - the corrupt frames are gone.
Will that quirk be added to the driver (usb id is: 0408:2fb1)?
Thanks,
Hi,
it seems like I am much better off by fully disabling FID (with your
patch) than before. With the patch, YUYV frames are _always_ the right
size. There are still some problems:
1) corrupt frames - with part of the image missing or the image displaced.
Sometimes (but definitely not always) these occur at the same time as a
trace message saying the error bit is set.
2) sometimes the camera just won't start. when guvcview (or luvcview) is
started, no frames come back from the camera. There is a light next to
the camera that comes on to indicate it should be active, but no frames
arrive. There seems to be a fairly strong correlation with using luvcview
(which from the traces seems to use some different mechanism to get frames
from
the driver from guvcview. guvcview polls, luvcview doesn't). Sometimes
just restarting guvcview several times will work and the camera eventually
starts. Sometimes just changing resolution or frame rates succeeds in
starting the camera. I haven't found anything reproducible. I do not
think this is related to your patch, as it did happen once before your
patch was applied. Unloading and reloading the uvcvideo and ehci_hcd
modules does not consistently solve it. guvcview just lists:
Could not grab image (select timeout): Resource temporarily unavailable
and the trace shows guvcview polling, but nothing else going on.
I have tried adding the other quirks to the FID quirk, but haven't seen
any improvement with any others.
Thanks for you help -
Carl
Webcam returns error in the middle of some frame, theoretically we
should drop complete frame. But current uvcvideo just gather data and
assume the cam will resend previous parts to complete the frame.
Try attached patch additionally to my previous one.
--
Regards,
Alexey
diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c
index d0b59ca..0dd3d33 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -423,6 +423,8 @@ static int uvc_video_decode_start(struct uvc_streaming *stream,
if (data[1] UVC_STREAM_ERR) {
uvc_trace(UVC_TRACE_FRAME, Dropping payload (error bit
set).\n);
+ if (buf != NULL)
+ buf-error = 1;
return -ENODATA;
}
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam works intermittently - [18e3:9512] built-in in Hannspree SN12E2 netbook
Hi Tomas, all listed error come directly from usb driver. uvcvideo driver do not even have chance to talk with your cam. It should be some hardware issue. Try to check the cable. Am Montag, den 13.06.2011, 18:50 +0100 schrieb Tomas Conway: Sorry for the double post - forgot to include the attachment last time. Machine: Hannspree SN12E2 Webcam/mic ID: [18e3:9512], Fitipower Integrated Technology Inc Attachments *** lsusb - Output of 'lsusb -v -d 18e3:9512' Sometimes the webcam works on bootup (or a few mintues after), sometimes it works immediately after I run lsusb, mostly it doesn't work at all. Sometimes the laptop will be on for hours before the webcam spontaneouly works. Usually within a couple of hours of working it will spontaneously stop working. My fear is that there is hardware problem - is it possible to determine whether or not this is the case? Log example: [10415.476069] usb 2-4: new high speed USB device using ehci_hcd and address 7 [10415.596080] usb 2-4: device descriptor read/64, error 4 [10415.977255] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (18e3:9512) [10415.988171] input: USB 2.0 Camera as /devices/pci:00/:00:1d.7/usb2/2-4/2-4:1.0/input/input10 [10421.150795] usb 2-4: USB disconnect, address 7 [10421.160055] cannot submit datapipe for urb 0, error -19: no device [10421.356381] hub 2-0:1.0: unable to enumerate USB device on port 4 [10421.600054] usb 2-4: new high speed USB device using ehci_hcd and address 9 [10422.132066] usb 2-4: device not accepting address 9, error -71 [10422.244107] usb 2-4: new high speed USB device using ehci_hcd and address 10 [10422.521422] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (18e3:9512) [10422.532425] input: USB 2.0 Camera as /devices/pci:00/:00:1d.7/usb2/2-4/2-4:1.0/input/input11 [10444.081927] usb 2-4: USB disconnect, address 10 [10444.348099] usb 2-4: new high speed USB device using ehci_hcd and address 11 [10444.418602] ehci_hcd :00:1d.7: port 4 reset error -110 [10444.418619] hub 2-0:1.0: hub_port_status failed (err = -32) [10444.620081] hub 2-0:1.0: unable to enumerate USB device on port 4 [10444.876058] usb 7-2: new full speed USB device using uhci_hcd and address 2 [10444.940081] hub 7-0:1.0: unable to enumerate USB device on port 2 [10456.280046] usb 2-4: new high speed USB device using ehci_hcd and address 12 [10456.812039] usb 2-4: device not accepting address 12, error -71 [10456.924056] usb 2-4: new high s[10415.476069] usb 2-4: new high speed USB device using ehci_hcd and address 7 [10415.596080] usb 2-4: device descriptor read/64, error 4 [10415.977255] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (18e3:9512) [10415.988171] input: USB 2.0 Camera as /devices/pci:00/:00:1d.7/usb2/2-4/2-4:1.0/input/input10 [10421.150795] usb 2-4: USB disconnect, address 7 [10421.160055] cannot submit datapipe for urb 0, error -19: no device [10421.356381] hub 2-0:1.0: unable to enumerate USB device on port 4 [10421.600054] usb 2-4: new high speed USB device using ehci_hcd and address 9 [10422.132066] usb 2-4: device not accepting address 9, error -71 [10422.244107] usb 2-4: new high speed USB device using ehci_hcd and address 10 [10422.521422] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (18e3:9512) [10422.532425] input: USB 2.0 Camera as /devices/pci:00/:00:1d.7/usb2/2-4/2-4:1.0/input/input11 [10444.081927] usb 2-4: USB disconnect, address 10 [10444.348099] usb 2-4: new high speed USB device using ehci_hcd and address 11 [10444.418602] ehci_hcd :00:1d.7: port 4 reset error -110 [10444.418619] hub 2-0:1.0: hub_port_status failed (err = -32) [10444.620081] hub 2-0:1.0: unable to enumerate USB device on port 4 [10444.876058] usb 7-2: new full speed USB device using uhci_hcd and address 2 [10444.940081] hub 7-0:1.0: unable to enumerate USB device on port 2 [10456.280046] usb 2-4: new high speed USB device using ehci_hcd and address 12 [10456.812039] usb 2-4: device not accepting address 12, error -71 [10456.924056] usb 2-4: new high speed USB device using ehci_hcd and address 13 [10456.984412] hub 2-0:1.0: unable to enumerate USB device on port 4 [10457.228083] usb 2-4: new high speed USB device using ehci_hcd and address 14 [10457.296381] hub 2-0:1.0: unable to enumerate USB device on port 4 [10457.484269] hub 2-0:1.0: unable to enumerate USB device on port 4 [10457.728073] usb 2-4: new high speed USB device using ehci_hcd and address 16 [10457.796365] hub 2-0:1.0: unable to enumerate USB device on port 4 [10458.064094] usb 7-2: new full speed USB device using uhci_hcd and address 3 [10458.292116] usb 7-2: not running at top speed; connect to a high speed hub [10458.422485] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (18e3:9512) [10458.436312] input: USB 2.0 Camera as
Re: [Linux-uvc-devel] Frame Rate/Corruption C910, plus 4 others
Hi Mark,
can you please take a look to my discussion with Carl, subject Quanta
integrated webcam. There are soma patches, wich may solve your problem
as well.
Am Donnerstag, den 09.06.2011, 02:04 -0400 schrieb Mark Whitis:
Low frame rate problems have been seen with at least 5 UVC cameras on
multiple computers. It isn't low light, USB bandwidth, etc. In the
past, I have assumed the cameras were being dishonest about their
performance, now I am pretty sure it is the UVC driver's fault. On a
newer, faster, computer performance has even gone down on some cameras.
I just got a new Logitech C910 UVC webcam. This camera has a 5MP
(2592x1944) sensor and can do 1920x1080/30P, 720x1280/30P, and
640x480/60P. It works right out of the box with guvcview except for:
- The crippling frame rate problems described here
- uvcvideo doesn't support still picture capture (this is a real 5MP
bayer resolution webcam).
- Exposure mode can be set to Manual or Aperature Priority. Auto or
Shutter priority produce an error.
- Video in MJPG mode is badly corrupted when recording (any program) or
when
displayed in some programs.
Other than that, auto/manual exposure, digital zoom, digital pan/tilt
(zoom first), auto/manual focus, etc. seem to work. Sound not tested.
It does support still image.
However, streaming to disk or using a number of other applications fails
badly:
Tests were done on this camera, except where otherwise noted.
As we will see below, mplayer is the only one that admits to dropping 3/4
of the video frames at 60fps but the other programs (or the driver) are
doing it.
Because of the large number of video modes, less interesting modes have
been deleted and only 480P, 720P, 1080P, and full sensor resolution shown
in YUYV and MJPG:
Init. UVC Camera (046d:0821) (location: usb-:00:13.2-3)
{ pixelformat = 'YUYV', description = 'YUV 4:2:2 (YUYV)' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/30, 1/24, 1/20, 1/15, 1/10, 2/15,
1/5,
{ discrete: width = 1280, height = 720 }
Time interval between frame: 1/10, 2/15, 1/5,
{ discrete: width = 1920, height = 1080 }
Time interval between frame: 1/2,
{ discrete: width = 2592, height = 1944 }
Time interval between frame: 1/2,
{ pixelformat = 'MJPG', description = 'MJPEG' }
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/60, 1/30, 1/24, 1/20, 1/15, 1/10,
2/15, 1/5,
{ discrete: width = 1280, height = 720 }
Time interval between frame: 1/30, 1/24, 1/20, 1/15, 1/10, 2/15,
1/5,
{ discrete: width = 1920, height = 1080 }
Time interval between frame: 1/30, 1/24, 1/20, 1/15, 1/10, 2/15,
1/5,
{ discrete: width = 2592, height = 1944 }
Time interval between frame: 1/10, 2/15, 1/5,
{ pixelformat = 'RGB3', description = 'RGB3' }
...
{ pixelformat = 'BGR3', description = 'BGR3' }
...
vid:046d
pid:0821
driver:uvcvideo
Adding control for Pan (relative)
UVCIOC_CTRL_ADD - Error: File exists
checking format: 1196444237
VIDIOC_G_COMP:: Invalid argument
compression control not supported
fps is set to 1/30
drawing controls
fps is set to 1/30
guvcview gets max 12-14fps in any video mode down to 160x120.
Yes, I am using MJPG not YUYV. No the camera exposure should not be
knocking down the frame rate as this occurs even when pointed at a light.
No the CPU isn't overloaded; Phenom II 1060T X6 and none of the cores are
heavily loaded. No, I am not plugged into a 12Mbps port. No, the USB
bus isn't loaded (unplugged another webcam). luvcview does a little
better, getting 30fps at 160x120.But if you run guvcview as root, now
all of a sudden it can run 30fps up to 1920x1080. This continues when
you switch back to a normal user.Until it breaks. Which happened
when I tried to read full sensor resolution. After that, I was stuck at
=15fps in all modes as root and ordinary user. Removing both copies of
.guvcviewrc didn't help.Unpluging the camera doesn't fix it.
Unplugging the camera and rmmoding uvcvideo (which takes videodev with it)
and replugging the camera didn't fix it. Plugging into USB 3.0
superspeed port didn't help (not that the camera supports superspeed, just
trying to change the USB controller). shutdown -h now didn't fix it.
Sound is disabled.
At one point during the brief time that it was working as root, I got
58fps 640x480 and it did not slow down even when I lowered frame rate to
30fps. Don't know if it actually had anything to do with being root.
It did work just long enough to indicate that the camera can deliver on
its promised specifications.
It does appear guvcview frame rate display is somewhat unreliable. I get
different results if I turn it off and on, and they vary depending on how
long it was off, like the title bar only gets updated once. But on
different cameras
Re: [Linux-uvc-devel] Multiple webcams, error: uvcvideo: Failed to submit URB 0 (-28)
Hi Justin, this is probably bug in uvcvideo. Theoretically it should allow you to run only 2-3 cams independent of type. Am Donnerstag, den 09.06.2011, 09:56 -0400 schrieb Justin Piszcz: On Wed, 8 Jun 2011, Justin Piszcz wrote: Is there anyway around this? When using 5 different webcams, no problems. When using 4-5 webcams of the same type, only 2 of 5 work. [ 832.218440] uvcvideo: Failed to submit URB 0 (-28). I also tried with uvcvideo quirks=128. Why is this? Anyhow, I found a workaround: [ 1183.054874] uvcvideo: Probing generic UVC device 6 [ 1183.054908] uvcvideo: Found format MJPEG. [ 1183.054916] uvcvideo: - 160x120 (30.0 fps) [ 1183.054922] uvcvideo: - 176x144 (30.0 fps) [ 1183.054927] uvcvideo: - 320x240 (15.0 fps) [ 1183.054933] uvcvideo: - 352x288 (15.0 fps) [ 1183.054938] uvcvideo: - 640x480 (15.0 fps) [ 1183.054943] uvcvideo: - 800x600 (15.0 fps) [ 1183.054949] uvcvideo: - 960x720 (10.0 fps) [ 1183.054955] uvcvideo: Found format YUV 4:2:2 (YUYV). [ 1183.054961] uvcvideo: - 160x120 (30.0 fps) [ 1183.054966] uvcvideo: - 176x144 (30.0 fps) [ 1183.054972] uvcvideo: - 320x240 (15.0 fps) [ 1183.054978] uvcvideo: - 352x288 (15.0 fps) [ 1183.054984] uvcvideo: - 640x480 (15.0 fps) [ 1183.054989] uvcvideo: - 800x600 (15.0 fps) [ 1183.054994] uvcvideo: - 960x720 (10.0 fps) [ 1183.055000] uvcvideo: - 1600x1200 (5.0 fps) I can use MAX: 2 devices of the same type with YUV 4:2:2. I can use MAX: at least ?? more devices of the same type with MJPEG. Now I see some weird banding or video artifacts, digging further (w/MJPEG). Why is there a problem using 2 of the same device with YUV 4:2:2? CC'd motion-user@ list to see if there is a 'proper' way to support 2-3 web cams. So far I have 1 PCI-e USB card with 4 ports and the system motherboard itself and the motherboard headers, I am able to use 3 of the same camera, but beyond that it says Failed to submit URB 0 (-28). I would like to use YUV 4:2:2 (YUUV) 1600x1200 for all 4 cams, would this be possible? Right now I am able to use as many cameras as I want, as long as there are not more than ~2 of the same type: Bus 001 Device 003: ID 046d:0809 Logitech, Inc. Webcam Pro 9000 Bus 002 Device 004: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000 Bus 007 Device 002: ID 0471:0311 Philips (or NXP) PCVC740K ToUcam Pro [pwc] Bus 002 Device 005: ID 046d:08b2 Logitech, Inc. QuickCam Pro 4000 Bus 003 Device 004: ID 046d:08b2 Logitech, Inc. QuickCam Pro 4000 Bus 003 Device 005: ID 046d:0809 Logitech, Inc. Webcam Pro 9000 Thoughts? Justin. ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Multiple webcams, error: uvcvideo: Failed to submit URB 0 (-28)
On Di, 2011-06-14 at 05:34 -0400, Justin Piszcz wrote: On Tue, 14 Jun 2011, Alexey Fisher wrote: Hi Justin, this is probably bug in uvcvideo. Theoretically it should allow you to run only 2-3 cams independent of type. Hi, The other webcams used pwc or other modules, sorry for not detailing that in the first e-mail. So w/UVC, 2-3 cams max? No, it make decision according requested bandwidth. If 2 webcams request all available bandwidth, even if they do not use it, you will get only 2 cams to work. Other question is, if all your webcams use more als your usb can. It can produce some other errors. -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi, theoretically this should do it: gst-inspect-0.10 v4l2src ! video/x-h264 ! ffdec_h264 ! autovideosink but, if i'm correct, current kernel do not support h264. There was a patch for some time, but im not sure if Laurent applyed it. Am Mittwoch, den 15.06.2011, 16:01 +0200 schrieb Kofi Jedamzik: Hi, ... there is a new Logitech Webcam called B990 HD Webcam with device id 046d:0828 it has an integrated hardware based H264 baseline video encoder This cam is not listed. MJPEG seems to work but I want to get out the H264 stream. Is there anyone who could give me a hint how to do it? Here are som dumps which might be helpful... best regards Kofi #lsusb --verbose -d 046d:0828 (big output) -- http://pastebin.com/9WFgytwY #guvcview --device /dev/video0 --verbose (big output) -- http://pastebin.com/pqmUGYyn #modinfo uvcvideo filename: /lib/modules/2.6.38-8-generic/kernel/drivers/media/video/uvc/uvcvideo.ko version:v1.0.0 #tail /var/log/syslog [11588.664940] usb 1-6: USB disconnect, address 4 [11594.580043] usb 1-6: new high speed USB device using ehci_hcd and address 5 [11594.927759] uvcvideo: Unknown video format 34363248--0010-8000-00aa00389b71 [11594.927786] uvcvideo: Found UVC 1.00 device unnamed (046d:0828) [11595.024093] input: UVC Camera (046d:0828) as /devices/pci:00/:00:12.2/usb1/1-6/1-6:1.0/input/input8 -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi, Stephan Lachowsky has provided some patches for MPEG-TS and H264 support. https://lists.berlios.de/pipermail/linux-uvc-devel/2011-February/006287.html https://lists.berlios.de/pipermail/linux-uvc-devel/2011-February/006288.html I do not know the current status of this work. May be Laurent can tell some thing about it. Am Donnerstag, den 16.06.2011, 10:26 +0530 schrieb Ajay Bhargav: Hi, as far as i know stream based format are not yet supported in UVC driver. and UVC 1.1 specifications defines the H.264 payload specifications. I dont think they are implemented yet. I have a camera with me which outputs H.264 stream using MPEG2-TS container format. If you have any idea how to add support for MPEG2-TS please let me know. --Ajay - Original Message - From: Alexey Fisher bug-tr...@fisher-privat.net To: Kofi Jedamzik k...@jedamzik.net Cc: linux-uvc-devel@lists.berlios.de Sent: Wednesday, June 15, 2011 8:10:36 PM Subject: Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist Hi, theoretically this should do it: gst-inspect-0.10 v4l2src ! video/x-h264 ! ffdec_h264 ! autovideosink but, if i'm correct, current kernel do not support h264. There was a patch for some time, but im not sure if Laurent applyed it. Am Mittwoch, den 15.06.2011, 16:01 +0200 schrieb Kofi Jedamzik: Hi, ... there is a new Logitech Webcam called B990 HD Webcam with device id 046d:0828 it has an integrated hardware based H264 baseline video encoder This cam is not listed. MJPEG seems to work but I want to get out the H264 stream. Is there anyone who could give me a hint how to do it? Here are som dumps which might be helpful... best regards Kofi #lsusb --verbose -d 046d:0828 (big output) -- http://pastebin.com/9WFgytwY #guvcview --device /dev/video0 --verbose (big output) -- http://pastebin.com/pqmUGYyn #modinfo uvcvideo filename: /lib/modules/2.6.38-8-generic/kernel/drivers/media/video/uvc/uvcvideo.ko version:v1.0.0 #tail /var/log/syslog [11588.664940] usb 1-6: USB disconnect, address 4 [11594.580043] usb 1-6: new high speed USB device using ehci_hcd and address 5 [11594.927759] uvcvideo: Unknown video format 34363248--0010-8000-00aa00389b71 [11594.927786] uvcvideo: Found UVC 1.00 device unnamed (046d:0828) [11595.024093] input: UVC Camera (046d:0828) as /devices/pci:00/:00:12.2/usb1/1-6/1-6:1.0/input/input8 -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel -- This message has been scanned for viruses and dangerous content by Clean Mail Gateway, and is believed to be clean. * einfochips Business Disclaimer : This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. * -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
Am Donnerstag, den 16.06.2011, 11:31 -0700 schrieb Carl Michal: On Thu, 16 Jun 2011, Carl Michal wrote: On Wed, 15 Jun 2011, Alexey Fisher wrote: Am Dienstag, den 14.06.2011, 23:31 -0700 schrieb Carl Michal: On Tue, 14 Jun 2011, Alexey Fisher wrote: Am Montag, den 13.06.2011, 22:48 -0700 schrieb Carl Michal: Hi, I think you nailed it. Every frame looks perfect now. The trace shows a few of these: Jun 13 09:24:24 uvcvideo: Dropping payload (error bit set) but I don't see corrupt frames any more in either MJPG or YUYV (at 640x480 anyway) - in MJPG all the frames have the right size. There is a some weirdness with frame rates depending on the exposure setting: 1) Exposure, auto gives 4 options: auto priority mode, manual mode, shutter priority mode, and aperture priority mode. Auto and shutter don't seem to be settable (errors from guvcview when chosen). There is also an Exposure, auto priority checkbox. Frame rates drop dramatically in manual mode (to 10-15fps from 30). But I can't really complain at this point - the corrupt frames are gone. Will that quirk be added to the driver (usb id is: 0408:2fb1)? Thanks, Hi, it seems like I am much better off by fully disabling FID (with your patch) than before. With the patch, YUYV frames are _always_ the right size. There are still some problems: 1) corrupt frames - with part of the image missing or the image displaced. Sometimes (but definitely not always) these occur at the same time as a trace message saying the error bit is set. 2) sometimes the camera just won't start. when guvcview (or luvcview) is started, no frames come back from the camera. There is a light next to the camera that comes on to indicate it should be active, but no frames arrive. There seems to be a fairly strong correlation with using luvcview (which from the traces seems to use some different mechanism to get frames from the driver from guvcview. guvcview polls, luvcview doesn't). Sometimes just restarting guvcview several times will work and the camera eventually starts. Sometimes just changing resolution or frame rates succeeds in starting the camera. I haven't found anything reproducible. I do not think this is related to your patch, as it did happen once before your patch was applied. Unloading and reloading the uvcvideo and ehci_hcd modules does not consistently solve it. guvcview just lists: Could not grab image (select timeout): Resource temporarily unavailable and the trace shows guvcview polling, but nothing else going on. I have tried adding the other quirks to the FID quirk, but haven't seen any improvement with any others. Thanks for you help - Carl Webcam returns error in the middle of some frame, theoretically we should drop complete frame. But current uvcvideo just gather data and assume the cam will resend previous parts to complete the frame. Try attached patch additionally to my previous one. -- Regards, Alexey Hi, its very hard to say if this helps or not. There are still corrupt frames, and some seem to occur at about the same time as the error bit trace messages, but some don't show anything unusual in the traces that I've noticed yet. Since all the uncompressed frames were the right size (even ones where the error bit was set somewhere) those frames are at least complete. Is there some convenient way to capture just those frames with the error bit set? Thanks, Carl you can try this command: gst-launch-0.10 -v v4l2src ! video/x-raw-yuv,width=320 ! identity ! jpegenc ! multifilesink location=tmp-%05d.jpg it will produce for each frame one jpeg file. Watch out, it will produce lots of files. Attached patch is replacement for the last one. You do not need setting trace option, it will print all we need. -- Regards, Alexey Hi, we're learning a little here. If I set nodrop=1, I get lots of frames that are too short (gst complains that they are fewer bytes than expected) but those coincide with the status 0 test in uvc_video_decode_isoc - they do not correspond to those with the error bit set. The buf-error=1 in uvc_video_decode_start=1 is unnecessary - harmful even, since it means dropping frames that are in fact ok. I have captured some bad frames though - one
Re: [Linux-uvc-devel] Quanta integrated webcam
Am Dienstag, den 21.06.2011, 10:33 -0700 schrieb Carl Michal: Hi, I don't feel like I'm really near to solving this. The best I can say is that I think sometimes there may be a header missing. With the patch to fully disable FID, 640x480 and lower in YUV seem to work reasonably well. Nothing in MJPG is acceptable. I think this is because the driver does a much better job of dropping bad frames in YUV with the check for the correct frame length. I'm wondering if the camera is confused about its capabilities? It claims to be able to do 768x480, 1024x768, 1280x720, 1280x1024, and 1600x1200 uncompressed at 30fps (and no other frame rates). Lower resolutions have a reasonable selection of frame rates - eg 640x480 lists 30, 25, 20, 15, 10 and 5fps. For 1600x1200 the bit rate listed (by lsusb -v) is 92160, but isn't that way more the bus can do? This computer does have USB3 ports, but the camera is handled by ehci_hcd. Could this be part of the problem? this cam do many things in wrong/other way. the question is, do we can work around the bugs it has? There is a windows driver on dell website for this webcam, it use ms uvcvideo driver but it use also some driver wich looks like proxy between uvcvideo and the cam. Can you confirm that it works well without driver on videos 7/Vista (with native uvcvideo), if not it will be interesting to know what doing this extra driver: filters bad frames or filters the settings? -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
Am Freitag, den 24.06.2011, 20:08 +0200 schrieb Laurent Pinchart: Hi Alexey, On Tuesday 14 June 2011 09:39:47 Alexey Fisher wrote: Am Montag, den 13.06.2011, 22:48 -0700 schrieb Carl Michal: Hi, I think you nailed it. Every frame looks perfect now. The trace shows a few of these: Jun 13 09:24:24 uvcvideo: Dropping payload (error bit set) but I don't see corrupt frames any more in either MJPG or YUYV (at 640x480 anyway) - in MJPG all the frames have the right size. There is a some weirdness with frame rates depending on the exposure setting: 1) Exposure, auto gives 4 options: auto priority mode, manual mode, shutter priority mode, and aperture priority mode. Auto and shutter don't seem to be settable (errors from guvcview when chosen). There is also an Exposure, auto priority checkbox. Frame rates drop dramatically in manual mode (to 10-15fps from 30). But I can't really complain at this point - the corrupt frames are gone. Will that quirk be added to the driver (usb id is: 0408:2fb1)? Thanks, Hi, it seems like I am much better off by fully disabling FID (with your patch) than before. With the patch, YUYV frames are _always_ the right size. There are still some problems: 1) corrupt frames - with part of the image missing or the image displaced. Sometimes (but definitely not always) these occur at the same time as a trace message saying the error bit is set. 2) sometimes the camera just won't start. when guvcview (or luvcview) is started, no frames come back from the camera. There is a light next to the camera that comes on to indicate it should be active, but no frames arrive. There seems to be a fairly strong correlation with using luvcview (which from the traces seems to use some different mechanism to get frames from the driver from guvcview. guvcview polls, luvcview doesn't). Sometimes just restarting guvcview several times will work and the camera eventually starts. Sometimes just changing resolution or frame rates succeeds in starting the camera. I haven't found anything reproducible. I do not think this is related to your patch, as it did happen once before your patch was applied. Unloading and reloading the uvcvideo and ehci_hcd modules does not consistently solve it. guvcview just lists: Could not grab image (select timeout): Resource temporarily unavailable and the trace shows guvcview polling, but nothing else going on. I have tried adding the other quirks to the FID quirk, but haven't seen any improvement with any others. Thanks for you help - Carl Webcam returns error in the middle of some frame, theoretically we should drop complete frame. But current uvcvideo just gather data and assume the cam will resend previous parts to complete the frame. Try attached patch additionally to my previous one. What about not ignoring the data in addition to setting buf-error to 1 ? This won't solve corruptiong, but would avoid the image effect for uncompressed formats. My english (and c) are not my bet qualities. But currently i'm really not sure if i understand. Was it sarcasm? -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quanta integrated webcam
Am Freitag, den 24.06.2011, 20:31 +0200 schrieb Laurent Pinchart: Hi Alexey, On Friday 24 June 2011 20:25:03 Alexey Fisher wrote: Am Freitag, den 24.06.2011, 20:08 +0200 schrieb Laurent Pinchart: On Tuesday 14 June 2011 09:39:47 Alexey Fisher wrote: Am Montag, den 13.06.2011, 22:48 -0700 schrieb Carl Michal: Hi, I think you nailed it. Every frame looks perfect now. The trace shows a few of these: Jun 13 09:24:24 uvcvideo: Dropping payload (error bit set) but I don't see corrupt frames any more in either MJPG or YUYV (at 640x480 anyway) - in MJPG all the frames have the right size. There is a some weirdness with frame rates depending on the exposure setting: 1) Exposure, auto gives 4 options: auto priority mode, manual mode, shutter priority mode, and aperture priority mode. Auto and shutter don't seem to be settable (errors from guvcview when chosen). There is also an Exposure, auto priority checkbox. Frame rates drop dramatically in manual mode (to 10-15fps from 30). But I can't really complain at this point - the corrupt frames are gone. Will that quirk be added to the driver (usb id is: 0408:2fb1)? Thanks, Hi, it seems like I am much better off by fully disabling FID (with your patch) than before. With the patch, YUYV frames are _always_ the right size. There are still some problems: 1) corrupt frames - with part of the image missing or the image displaced. Sometimes (but definitely not always) these occur at the same time as a trace message saying the error bit is set. 2) sometimes the camera just won't start. when guvcview (or luvcview) is started, no frames come back from the camera. There is a light next to the camera that comes on to indicate it should be active, but no frames arrive. There seems to be a fairly strong correlation with using luvcview (which from the traces seems to use some different mechanism to get frames from the driver from guvcview. guvcview polls, luvcview doesn't). Sometimes just restarting guvcview several times will work and the camera eventually starts. Sometimes just changing resolution or frame rates succeeds in starting the camera. I haven't found anything reproducible. I do not think this is related to your patch, as it did happen once before your patch was applied. Unloading and reloading the uvcvideo and ehci_hcd modules does not consistently solve it. guvcview just lists: Could not grab image (select timeout): Resource temporarily unavailable and the trace shows guvcview polling, but nothing else going on. I have tried adding the other quirks to the FID quirk, but haven't seen any improvement with any others. Thanks for you help - Carl Webcam returns error in the middle of some frame, theoretically we should drop complete frame. But current uvcvideo just gather data and assume the cam will resend previous parts to complete the frame. Try attached patch additionally to my previous one. What about not ignoring the data in addition to setting buf-error to 1 ? This won't solve corruptiong, but would avoid the image effect for uncompressed formats. My english (and c) are not my bet qualities. But currently i'm really not sure if i understand. Was it sarcasm? Not at all :-) Ok, i thought you mean some thing like avoid the image effect = avoid the image If the error bit is set, the packet will be dropped. For uncompressed formats, dropping the data will shift part of the frame up/left and possibly mess the color ups. Instead of doing that, we could handle packets with the error bit set normally. The data will likely be corrupted, but that will just corrupt a small part of the frame, and won't shift the rest of the frame up/left. We should then also set buf-error to 1 as done in your patch, to tell applications that the V4L2 buffer contains errors. Also, you mean: - return -ENODATA; + if (buf != NULL) + buf-error = 1; } I'll try it on my netbook, it produce 200 packets with error bit set on every start. Will see how it will looks like. -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Logitech C270 mic problem
I have same problem with my Logitech Notebook Pro and on my friends webcam too, but i just do not have time to research it. I'd say, enabling video couse some delay in audio stream so pulseaudio hangs or some thing like this. Normally i have this with skype, not with google-talk, and it seems to depend on version of skype. On Mo, 2011-07-04 at 10:22 +0100, Paulo Assis wrote: Hi, your camera mic is supported by the snd-usb-audio alsa driver ( http://alsa.opensrc.org/Usb-audio ), this is a totally different driver and specification from uvcvideo (video only). Anyway is the problem related to skype only or do other apps like audacity, suffer from the same issues? Regards, Paulo 2011/7/3 George grinde...@gmail.com: Hello all, Here is a problem with a Logitech C270 webcam and its mic: Quite often when I 'm on Skype (or Google talk) doing a video call, the mic suddenly goes off, so the other side can't here me. I have to kill Skype from the command line, unplug the camera, plug it back in and then load Skype again. Sometimes I have to do this 2 or 3 times in a raw until the mic comes back again. This happens only when I 'm doing video calls. When this happens I see the following message when doing a dmesg: cannot set freq 24000 to ep 0x86 I also see similar messages when the Linux kernel is loading: cannot set freq 24000 to ep 0x86 cannot set freq 32000 to ep 0x86 cannot set freq 48000 to ep 0x86 I purchased this webcam 6 months ago (sorry for not mailing the list earlier) and I noticed this behaviour from the very beginning I started using it, so it's not something noticed with the latest Linux kernel. I 'm using Debian Unstable with the Liquorix kernel, but it's the same with the official Debian kernels as well. This has also been reported in Arch Linux. I hope that the above information can help you to debug the problem. Please do tell me if I can do anything more. Thank you in advance for any response. Best regards, George P. ___ 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 -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] WEBcam (UVC Microscope) not supported
On Fr, 2011-07-29 at 22:48 -0400, John Fancher wrote: The following USB webcam (microscope) is not recognised by the driver lsusb output: Bus 001 Device 002: ID 1871:01b0 Aveo Technology Corp. Please can you send verbose lsusb output. use: sudo lsusb -vd 1871:01b0 Also can you please send link to the product? I looking one for me too :) -- Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] WEBcam (UVC Microscope) not supported
On Sa, 2011-07-30 at 09:57 -0400, John Fancher wrote:
On 07/30/2011 04:13 AM, Alexey Fisher wrote:
On Fr, 2011-07-29 at 22:48 -0400, John Fancher wrote:
The following USB webcam (microscope) is not recognised by the driver
lsusb output:
Bus 001 Device 002: ID 1871:01b0 Aveo Technology Corp.
Please can you send verbose lsusb output. use:
sudo lsusb -vd 1871:01b0
Also can you please send link to the product? I looking one for me
too :)
lsusb verbose output:
Bus 001 Device 002: ID 1871:01b0 Aveo Technology Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x1871 Aveo Technology Corp.
idProduct 0x01b0
bcdDevice0.05
iManufacturer 1 AVEO Technology Corp.
iProduct2 AVEO Cheetah3 USB2.0 Device
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 105
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface 0
At this point it shoud say bInterfaceClass 14 Video, your is
bInterfaceClass 255 Vendor Specific Class. It mean it is not UVC
device, or it is uvc undercover ;)
To test it you should be able to compile kerner by your self. Take also
look in: linux-2.6/drivers/media/video/uvc/uvc_driver.c
Search for some thing like this:
/* Logitech Quickcam Fusion */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
.idVendor = 0x046d,
.idProduct= 0x08c1,
.bInterfaceClass = USB_CLASS_VENDOR_SPEC,
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0 },
and place your idVendor and idProduct.
BRK
also, the only link I have ever found for the product is to retailers.
It was found at toys r us but now is not shown on their website.
The company was Edu Science which was a part of Toys R US. It is a
handheld Microscope. I have the PDF of the user manual that I will try
to post to the list. I also have the driver for windows which says it
is a UVC Driver.
Thanks for the help
--
Regards,
Alexey
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Exposure setting problems with Creative Live! Cam Socialize HD
Am 31.07.2011 18:28, schrieb Laurent Pinchart: Hi Michael, On Saturday 30 July 2011 15:08:14 Michael Stapelberg wrote: Hi, I recently bought a Creative Live! Cam Socialize HD (ID 041e:4080) after verifying that it is a device supported by the uvcvideo driver. The device basically works, but to get 30 fps (at 640x480, but also with higher resolutions), I need to set the 'Exposure, Auto' setting to 1 (Manual Mode). Afterwards, I can set the 'Exposure (Absolute)' setting to one of the values 39, 78, 156, 312, 625, 1250, 2500, …. All other values lead to a heavily over-exposed picture. This effect was already mentioned on this list for a different cam [1]. I wonder what we can do about it, as the step size for this setting is reported as '1' while in reality it seems logarithmic – with the exception of the step 312 to 625. Those values are 2500 / 64, 32, 16, 8, 4, 2 and 1. There's unfortunately no way for the driver to know that other values will lead to bad results. I've seen bad firmware bugs, but this one is high on the list. So, I can live with changing the configuration after plugging in the cam, which I would automate with udev. However, I have noticed that I need to have an active video capture running, otherwise setting these values with uvcdynctrl has no effect. I tested it like this: 1) Plug in the camera, wait until the white LED (which indicates capturing) goes off. This takes about 5 seconds. 2) Use uvcdynctrl -s 'Exposure, Auto' 1 3) Verify the result with uvcdynctrl -g 'Exposure, Auto', which also returns 1 4) Use uvcdynctrl -s 'Exposure (Absolute)' 312, verify it 5) Use gst-launch v4l2src ! xvimagesink → The video is at 5 fps instead of 30 fps If I do it like this, it works: 1) Plug in the camera, wait until the white LED (which indicates capturing) goes off. This takes about 5 seconds. 2) Use gst-launch v4l2src ! xvimagesink, leave it open 3) Use uvcdynctrl -s 'Exposure, Auto' 1, verify it 4) Use uvcdynctrl -s 'Exposure (Absolute)' 312, verify it → The video works correctly That's weird. I'm wondering if the camera doesn't just reset all controls when the video stream is started. What happens in the second case if you stop the video stream and restart it ? Are exposure settings correct, or do they go back to bad values ? How about usbautosuspend? Will it store the settings if you disables usbautosuspend? Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Microdia Sonix id 0c45:6310
On 10.08.2011 15:11, Rafael Piazenski wrote: Hello people! First of all, thanks for your help! I have this webcam on my ubuntu 11.04 in a HP TX2500 (2540br). My webcam is recognized, but there is no /dev/video0 for it. Can you help me solve this issue? Thanks a lot! Rafael Piazenski Bus 002 Device 004: ID 0c45:6310 Microdia Sonix USB 2.0 Camera lsusb -d 0c45:6310 -v | grep 14 Video can't get device qualifier: Operation not permitted can't get debug descriptor: Operation not permitted cannot read device status, Operation not permitted (1) bFunctionClass 14 Video Please attach complete lsusb output. Use: sudo lsusb -vd 0c45:6310 lsusb Then reload uvc module with debug options: sudo rmmod uvcvideo sudo modpprobe uvcvideo trace=0xfff play some thing, for example: gst-launch-0.10 v4l2src num-buffers=3 ! autovideosink this will capture only 3 frames. And after this attach dmesg output as well. Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] error proofing mjpeg stream
Am 10.08.2011 19:20, schrieb Carl Michal: Hi Alexey, On Tue, 9 Aug 2011, Alexey Fisher wrote: Hall all, Laurent, Carl, i just was looking on how my webcam do mjpeg stream and created some visualisation patch. I got some interesting results (may be it can help you Carl with your webcam). The idea is as fallow, use jpeg bits for error corection. According to uvc documentation, webcam should set SOI (start of image) and EOI (end of image) magic. In some situations it is possible to use it if FID is brocken. I got fallowing result (N - mean header is ok, but no data is present; !SOI - mean new SOI without EOI; * - image data): [ 5132.944079] N As you can see, my webcam try to resent SOI lots of times and only last try is correct. For next example i added logic to send ENODATA on each packet with correct header but no data. Here is the result: Your camera sounds weirder than mine! One potential issue to make sure of if you want to throw away packets with valid headers but no data: my camera (Quanta integrated webcam: 0408:2fb1, sends EOF (usually) in an empty packet - I think you want to make sure that this is looked for before discarding the packet. This maybe what happens with your filter - I didn't look closely enough to see. My camera actually works more or less perfectly now with the patch I sent in earlier. My camera has several distinct problems: 1) In YUV mode the camera sometimes gives up on a frame part way through, when this happens it doesn't give an EOF, but toggles FID. The released driver checks the length of YUV frames if the frame is terminated with EOF but it doesn't if the frame is terminated with FID. So I check that uncompressed frames terminated with FID are the correct length. This is something that should probably be added globally. 2) In MJPG mode the camera sometimes toggles FID one or two packets early. Fortunately EOF is reliable in MJPG, so in MJPG I ignore FID fully (based on a patch you supplied). Sadly I need EOF for MJPG and need FID in YUV... 3) Sometimes payload packets get broken in chunks that are 1/3 or 2/3 their proper size. This is bad - since the later chunks don't have headers, and left uncorrected the raw image data gets interpreted by the driver as header - and all sorts of random things happen. It turns out to be not so difficult to reassemble these packets though, just based on lengths. I'll send you one more patch to visualize some info from header, may be we can filter some thing. 4) The camera sometimes doesn't start. This turns out to be a problem people have seen in windows too. Somebody finally figured out a work-around - if the camera doesn't start, you can just point it at a light and then it starts. The very strange thing about all of this is that none of these issues appear to be universal. Many people have complained of #4, but other linux users do not appear to have problems 1, 2, or 3. 5) The camera lies about the frame rates it can do in high resolution YUV. It says it can do 30fps at 1600x1200 (and 1280x720 and 1024x768) yuv - but that's way more bits than USB 2 can carry. I don't think this causes any real problems though - you just don't get the frame rate advertised. Carl We can do size check for yuv, but nothing for jpeg. Jpeg stream has really good chance to be more error proof, since jpeg has markers on the start and end of image. The idea is to use this jpeg markers instead of FID or EOF. In my patch this markers are not used, but displayed. SOI and EOI are jpeg marker for start and end of image. Since your webcam is so brocken, it is a good test case :) Can you please send me dmesg with output from my patch by capturing jpeg stream. ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] error proofing mjpeg stream
On 12.08.2011 08:24, Carl Michal wrote: On Thu, 11 Aug 2011, Alexey Fisher wrote: On 10.08.2011 21:19, Carl Michal wrote: Hi Alexey, On Wed, 10 Aug 2011, Alexey Fisher wrote: Am 10.08.2011 19:20, schrieb Carl Michal: Hi Alexey, On Tue, 9 Aug 2011, Alexey Fisher wrote: Hall all, Laurent, Carl, i just was looking on how my webcam do mjpeg stream and created some visualisation patch. I got some interesting results (may be it can help you Carl with your webcam). The idea is as fallow, use jpeg bits for error corection. According to uvc documentation, webcam should set SOI (start of image) and EOI (end of image) magic. In some situations it is possible to use it if FID is brocken. I got fallowing result (N - mean header is ok, but no data is present; !SOI - mean new SOI without EOI; * - image data): [ 5132.944079] N As you can see, my webcam try to resent SOI lots of times and only last try is correct. For next example i added logic to send ENODATA on each packet with correct header but no data. Here is the result: Your camera sounds weirder than mine! One potential issue to make sure of if you want to throw away packets with valid headers but no data: my camera (Quanta integrated webcam: 0408:2fb1, sends EOF (usually) in an empty packet - I think you want to make sure that this is looked for before discarding the packet. This maybe what happens with your filter - I didn't look closely enough to see. My camera actually works more or less perfectly now with the patch I sent in earlier. My camera has several distinct problems: 1) In YUV mode the camera sometimes gives up on a frame part way through, when this happens it doesn't give an EOF, but toggles FID. The released driver checks the length of YUV frames if the frame is terminated with EOF but it doesn't if the frame is terminated with FID. So I check that uncompressed frames terminated with FID are the correct length. This is something that should probably be added globally. 2) In MJPG mode the camera sometimes toggles FID one or two packets early. Fortunately EOF is reliable in MJPG, so in MJPG I ignore FID fully (based on a patch you supplied). Sadly I need EOF for MJPG and need FID in YUV... 3) Sometimes payload packets get broken in chunks that are 1/3 or 2/3 their proper size. This is bad - since the later chunks don't have headers, and left uncorrected the raw image data gets interpreted by the driver as header - and all sorts of random things happen. It turns out to be not so difficult to reassemble these packets though, just based on lengths. I'll send you one more patch to visualize some info from header, may be we can filter some thing. 4) The camera sometimes doesn't start. This turns out to be a problem people have seen in windows too. Somebody finally figured out a work-around - if the camera doesn't start, you can just point it at a light and then it starts. The very strange thing about all of this is that none of these issues appear to be universal. Many people have complained of #4, but other linux users do not appear to have problems 1, 2, or 3. 5) The camera lies about the frame rates it can do in high resolution YUV. It says it can do 30fps at 1600x1200 (and 1280x720 and 1024x768) yuv - but that's way more bits than USB 2 can carry. I don't think this causes any real problems though - you just don't get the frame rate advertised. Carl We can do size check for yuv, but nothing for jpeg. Jpeg stream has really good chance to be more error proof, since jpeg has markers on the start and end of image. The idea is to use this jpeg markers instead of FID or EOF. In my patch this markers are not used, but displayed. SOI and EOI are jpeg marker for start and end of image. Since your webcam is so brocken, it is a good test case :) Can you please send me dmesg with output from my patch by capturing jpeg stream. The length check I mention is for yuv: but the current driver only does that length check when it sees EOF - it doesn't do it if the frame is terminated by FID - so I added that check. I can try your patch (not now - dont have that computer here) but without the reconstruction I already do I can't imagine it helping - because without the reconstruction, the driver chops off some of the mjpg or yuv data interpreting it as header. Each time that happens, 12 bytes get chopped out of the middle of the frame, and random bits get interpreted as FID, EOF, ERROR etc... My guess is that if I apply your checks with my stream reconstruction it will find that every frame is fine. Without my stream reconstruction, there will still be corrupt frames because some image data will be interpreted as header. Just searching for SOI and EOI won't help because they will generally be there in the right place, but a few bytes from the middle of the stream get removed
Re: [Linux-uvc-devel] 05c8:0403 listed as supported but is not working
Hi, can you please attach output of: lsusb -vd 05c8:0403 lsusb also reload uvcvideo module with: sudo rmmod uvcvideo sudo modporbe uvcvideo trace=0xfff capture video until it brakes and attach dmesg to email as well, please send complete dmesg not just last part with error. You may gzip it. Regards, Alexey On 14.08.2011 10:20, overclocked wrote: Dear ladies and gentlemen. As I wrote before, the following webcam is NOT working on my HP 4720s laptop: 05c8:0403 Cheng Uei Precision Industry Co., Ltd (Foxlink). I have installed (today) last version of the uvc driver. (from git clone git://linuxtv.org/media_build.git). When I try to test it with 'guvcview' it works about 20 secons only. Then video freezes, webcam LED turns off. guvcview writes the following to console output: libv4l2: error dequeuing buf: No such device VIDIOC_DQBUF - Unable to dequeue buffer : No such device Error grabbing image libv4l2: error dequeuing buf: No such device VIDIOC_DQBUF - Unable to dequeue buffer : No such device Error grabbing image libv4l2: error dequeuing buf: No such device VIDIOC_DQBUF - Unable to dequeue buffer : No such device Error grabbing image libv4l2: error dequeuing buf: No such device VIDIOC_DQBUF - Unable to dequeue buffer : No such device Error grabbing image ... If I restart guvcview, it just shows same errors and black screen instead of video. BUT!!! If I restart the driver using: $ sudo modprobe -r uvcvideo $ sudo modprobe uvcvideo video in guvcview works again!!! (for about 20 seconds). So I think that it's definitely a problem with UVC driver. You have already answered me, that it works on HP Mini 5103 netbook. But if it works on your system, it does not always mean that it will work on others. Thank You in advance, Kind Regards, ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] 05c8:0403 listed as supported but is not working
Hi, i decoded your usbmon dump, here is how usually looks conversation between webcam and pc: 1) webcam send some data, and the it get response from the host, to confirm that data as recived, this is the confiramtion: 8800844a0c00 0.000106 S Zi:1:033:1 -115:?:? 32 512 = 0(-18:0:2688:0) 1(-18:2688:2688:0) 2(-18:5376:2688:0) 3(-18:8064:2688:0) 4(-18:10752:2688:0) 5(-18:13440:2688:0) 6(-18:16128:2688:0) 7(-18:18816:2688:0) 8(-18:21504:2688:0) 9(-18:24192:2688:0) 10(-18:26880:2688:0) 11(-18:29568:2688:0) 12(-18:32256:2688:0) 13(-18:34944:2688:0) 14(-18:37632:2688:0) 15(-18:40320:2688:0) 16(-18:43008:2688:0) 17(-18:45696:2688:0) 18(-18:48384:2688:0) 19(-18:51072:2688:0) 20(-18:53760:2688:0) 21(-18:56448:2688:0) 22(-18:59136:2688:0) 23(-18:61824:2688:0) 24(-18:64512:2688:0) 25(-18:67200:2688:0) 26(-18:69888:2688:0) 27(-18:72576:2688:0) 28(-18:75264:2688:0) 29(-18:77952:2688:0) 30(-18:80640:2688:0) 31(-18:83328:2688:0) a) 0(-18:0:2688:0) - 0 ist the packet number in usb buffer, -18 - Cross-device link; 0 - memory offset in usb buffer; 2688 - maxPacketSize 2) the data from web cam usually looks almost like this: 8800844a6800 0.003874 C Zi:1:033:1 0:?:? 32 22028 = 0(0:0:12:0) : -- same like before, every thing is ok 0c8c48d99c282e1ede288a03 -- uvc header, but no image data. (usually ok too) 1(0:2688:12:0) : 0c8c48d99c288125de288b03 2(0:5376:12:0) : 0c8c48d99c28d42cde288b03 3(0:8064:12:0) : 0c8c48d99c282734de288b03 4(0:10752:12:0) : 0c8c48d99c287a3bde288b03 5(0:13440:12:0) : 0c8c48d99c28cd42de288b03 6(0:16128:12:0) : 0c8c48d99c28204ade288b03 7(0:18816:12:0) : 0c8c48d99c287351de288b03 8(0:21504:12:0) : 0c8c48d99c28c658de288b03 9(-71:24192:0:0) --- this is first bad packet. -71 - EPROTO, Protocol error. At this stage no packet was or should be send by from pc to the cam. It's mean the error source should be inside of the cam. 10(-71:26880:0:0) 11(-71:29568:0:0) 12(-71:32256:0:0) 13(-71:34944:0:0) 14(-71:37632:0:0) 15(-71:40320:0:0) 16(-71:43008:0:0) 17(-71:45696:0:0) 18(-71:48384:0:0) 19(-71:51072:0:0) 20(-71:53760:0:0) 21(-71:56448:0:0) 22(-71:59136:0:0) 23(-71:61824:0:0) 24(-71:64512:0:0) 25(-71:67200:0:0) 26(-71:69888:0:0) 27(-71:72576:0:0) 28(-71:75264:0:0) 29(-71:77952:0:0) 30(-71:80640:0:0) 31(-71:83328:0:0) Before USB Protocol error your camera send about 640 packets without video data, but with uvc headers. I assume it filed at this stage. I do not see any reasons where uvcvideo driver made some error. I assume that this webcam is broken. On 14.08.2011 22:08, overclocked wrote: Hello, unfortunately, I have no possibility to check webcam on Windows (I have only Ubuntu 11.04 on my laptop and currently do not have a storage to backup all and install Windows to check it). I have used wireshark on Linux... There are 2 usb interfaces: usbmon1 and usbmon2 I have captured the usbmon1... See file attached. I also have captured usbdump. It's 120 Mb, so I have used depositfiles for it: http://depositfiles.com/files/ssee74mok Also I have noticed that after some time webcam disappears from lsusb... Thank You in advance, Kind Regards, Andrey. On 08/14/2011 06:12 PM, Alexey Fisher wrote: Hi, can you confirm, this webcam do work on windows with uvcvideo driver? If yes, can you capture usb traffic like it described here: http://lindi.iki.fi/lindi/usb/usbsnoop.txt As alternative you can use wireshark. Your webcam located on Bus 001 Device 017, some times you need to know it to capture usb dump. Also it will be good to have usb dump from linux, usbmon module should be loaded/compiled. To capture you need: cat /dev/usbmon1 usbdump use Ctrl+C to stop it. gzip usbdump Actually you can use wireshark on linux as well. if it really big use rapidshare or filesonic or some thing like this for upload. Am 14.08.2011 13:58, schrieb overclocked: Yes, thank you for the answer. See files in the attachment. ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] error proofing mjpeg stream
I continued to work on you usb dump for jpeg stream, here are some examples:
This is first frame:
0c8d41c4ce01e010ca042f04ffd8ff SOI
0c8d41c4ce015ca3ca042f04975271
This is end of first frame, start of second, and first issue.
0c8d41c4ce017b42ee044e046a1950
0c8c0f5fee041a67ee044e0496a246 FID togled, new uvc time, but actual EOI
is here.
0c8e0f5fee041a67ee044e04actual EOF
0c8c0f5fee04961ef0045004ffd8ff SOI
for now this will be corrupt.
Second frame, every thing is fine.
0c8c0f5fee04315014056f04c74b75 EOI
0c8e0f5fee04d07414057004
0c8d1f801405ea5016057104ffd8ff SOI
frame 3.; FID is togled, no EOF, no EOI...
last part of this packet is corrupt, frame 2. is corrupt.
0c8d1f80140509f039059004666e79
0c8c34a13a05a05e3c059204ffd8ff SOI
It will be ipossible to fix, EOF probably lost, but FID is correct.
frame 3 is ok, start of frame 4.
0c8c34a13a053d906005b20497335d EOI
0c8e34a13a05dcb46005b204 EOF
0c8d7a576205556c6205b404ffd8ff SOI
frame 4 is ok
0c8d7a57620592c28605d3040c8f4a EOI
0c8e4fe3860531e78605d404 EOF
0c8c4fe38605aa9e8805d504ffd8ff SOI
no end of frame 4, FID togled and frame 5 started.
0c8c4fe38605c93dac05f4042515c4
0c8d5f04ad0501d1ae05f604ffd8ff SOI
may be some parts was not included in dump, or 4 is really corrupt.
Can't do any thing here, except only to check for EOI and SOI
Every thing is ok, here.
0c8d5f04ad059c02d3051605bd8d13 EOI
0c8f5f04ad059c02d3051605
0c8c6f25d305b6ded4051805ffd8ff SOI
OK:
0c8c6f25d305f034f9053705dcf952 EOI
0c8e6f25d305f034f9053705 EOF
0c8d2967fa050b11fb053905ffd8ff SOI
Not ok
0c8d2967fa054a421e065805e0ee50 no EOI, no EOF
0c8c94671f06c01e21065a05ffd8ff SOI and FID
Again, Fid is toggled too early.
0c8d9f884506b2826b069b051b3bb9
0c8cafa96b0651a76b069b05adcde2 EOI and FID
0c8eafa96b0651a76b069b05 EOF
0c8cafa96b06aacc6d069d05ffd8ff SOI
In this case will happen fallowing scenario,
1. frame 9f884506 will have corrupted end. (like you describe)
2. will be created new buffer, but this will contain only end of prev
frame. this will be stoped by EOF, but since FID == last_fid, then we
will get out of sync error and this buffer will be probably lost as well.
Let us concentrate on errors we can handle,
1. we can sort of reconstruct fragmented frames. But I do not really
like my previous patch, enay way let us keep it for now.
2. we can ignore FID,EOF,last_fid=fid problem by setting it to -1,
but this may brake other brocken cams. should think about this. or
collect more usb dumps.
3. We should defenetly check if new buffer with MJPEG stream, start with
jpeg header. I think this is important.
jpeg header is defined by uvc specification, it is always on same place.
Buffer is defenetly corrupt if there is no jpeg header [SOI] on start.
If ther is no EOI, we can still reconstruct part of image.
On 19.08.2011 06:52, Carl Michal wrote:
Hi Alexey,
ok, if I take your patch, and add to it a check for frame length when
when the frame is terminated with FID (patch below), then YUV appears to
function well. I haven't looked at the patch closely enough to see if
it handles the case where a packet is split into 3 instead of just two.
Those are quite infrequent - so it is possible that none occurred in my
testing of your patch.
MJPG still has a couple of problems. There are some mildly corrupt
frames (just the bottom ~3% of the image) - I believe that's still from
frames where FID comes a packet or two early.
Also, there is still a problem with empty buffer's returned: either
guvcview or luvcview spits out:
Ignoring empty buffer ...
about 1 time /second. After four of those luvcview quits.
One last thing - there is minor typo in your patch leght should be length
Carl
Add frame length check to uncompressed frames terminated with FID:
--- uvc_video.c~2011-08-18 21:35:53.664881826 -0700
+++ uvc_video.c2011-08-18 21:41:51.712872852 -0700
@@ -627,10 +627,15 @@
do {
ret = uvc_video_decode_start(stream, buf, mem,
urb-iso_frame_desc[i].actual_length);
-if (ret == -EAGAIN)
-buf =
- uvc_queue_next_buffer(stream-queue,
-buf);
+if (ret == -EAGAIN){
+if (buf-buf.length != buf-buf.bytesused
+ !(stream-cur_format-flags
+ UVC_FMT_FLAG_COMPRESSED))
+buf-error = 1;
+
+buf = uvc_queue_next_buffer(stream-queue,
+buf);
+}
} while (ret == -EAGAIN);
if (ret 0)
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] uvc header question
Hi Laurent,
are there any reason why uvc_video_decode_start do not do precise header
size checks? Are there many cameras with broken header size too?
I send you patch on what i work now to catch streams with fragmented
packets.. what do you think about it? Will you apply some thing like this?
Regards,
Alexey.
diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c
index 8244167..6fd1986 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -371,6 +371,46 @@ int uvc_commit_video(struct uvc_streaming *stream,
#define UVC_STREAM_EOF (1 1)
#define UVC_STREAM_FID (1 0)
+static int uvc_video_jpeg_soi(const __u8 *data, int len)
+{
+ /* to check jpeg header we need minimum 2 bytes after header. */
+ if (data[0] + 2 len)
+ return 0;
+
+ if (data[data[0]] == 0xff data[data[0] + 1] == 0xd8) {
+ uvc_trace(UVC_TRACE_FRAME, jpeg_SOI signature found\n);
+ return 1;
+ } else
+ return 0;
+}
+
+static int uvc_video_jpeg_eoi(struct uvc_streaming *stream,
+ struct uvc_buffer *buf)
+{
+struct uvc_video_queue *queue = stream-queue;
+__u8 *mem, *mem_min;
+ int diff = 0;
+
+mem = queue-mem + buf-buf.m.offset + buf-buf.bytesused - 1;
+ mem_min = queue-mem + buf-buf.m.offset;
+
+ /* some times webcam can put some zeros after eoi signatur. */
+ while (*mem == 0) {
+ mem--;
+ diff++;
+ }
+
+ if (*(mem-1) == 0xff *mem == 0xd9) {
+ uvc_trace(UVC_TRACE_FRAME, jpeg_EOI signature found\n);
+ if (diff) {
+ uvc_trace(UVC_TRACE_FRAME, remove trash after EOI\n);
+ buf-buf.bytesused = buf-buf.bytesused - diff;
+ }
+ return 1;
+ } else
+ return 0;
+}
+
/* Video payload decoding is handled by uvc_video_decode_start(),
* uvc_video_decode_data() and uvc_video_decode_end().
*
@@ -409,16 +449,65 @@ int uvc_commit_video(struct uvc_streaming *stream,
static int uvc_video_decode_start(struct uvc_streaming *stream,
struct uvc_buffer *buf, const __u8 *data, int len)
{
- __u8 fid;
+ __u8 fid, calk, recover;
+ int size;
+ calk = 1;
+ recover = 0;
/* Sanity checks:
- * - packet must be at least 2 bytes long
- * - bHeaderLength value must be at least 2 bytes (see above)
- * - bHeaderLength value can't be larger than the packet size.
- */
- if (len 2 || data[0] 2 || data[0] len)
+ * - if too smal for minimal header then it is trash */
+ if (len UVC_HEADER_SIZE_MIN)
return -EINVAL;
+ /* lets do strict header check, it could be good filter, but can detect
+ * more bad but working uvc cams.
+ */
+ if (calk size != data[0]) {
+ /* calculate size of header, minimum is 2 byte */
+ size = UVC_HEADER_SIZE_MIN;
+ /* PTS should be 4 byte */
+ if (data[1] UVC_STREAM_PTS)
+ size += 4;
+ /* SCR should be 6 */
+ if (data[1] UVC_STREAM_SCR)
+ size += 6;
+ /* all together should be 12 byte */
+ if (size != data[0]) {
+ uvc_trace(UVC_TRACE_FRAME, Calculated header size
+do not match with reported:%i/%i (%i).
+Frame is corrupt or payload is fragmented.,
+size, data[0], len);
+ /* so we got some chunk of garbrage,
+ * It is against uvc specification.
+ * There are some webcams aim to be uvc but sent
+ * fragmented packets.
+ * I assume every thing more then 12 bytes can be
+ * video data. */
+ if (len UVC_HEADER_SIZE_MAX) {
+buf-error = 1;
+return 0;
+ } else
+return -EINVAL;
+ }
+ /* this is less strict check, in case PTS and/or SCR not set, but
+ * have max header leth (12) */
+ } else if (!calk
+ (data[0] UVC_HEADER_SIZE_MIN ||
+ data[0] UVC_HEADER_SIZE_MAX ||
+ data[0] len)) {
+ uvc_trace(UVC_TRACE_FRAME, Header or frame is corrupt.
+ Or payload is fragmented.);
+ if (len UVC_HEADER_SIZE_MAX) {
+ buf-error = 1;
+ return 0;
+ } else
+ return -EINVAL;
+ }
+
+ /* no need to process empty payload, exept it has EOF flag. */
+ if (data[0] == len !(data[1] UVC_STREAM_EOF))
+ return -ENODATA;
+
/* Skip payloads marked with the error bit (error frames). */
if (data[1] UVC_STREAM_ERR) {
uvc_trace(UVC_TRACE_FRAME, Dropping payload (error bit
@@ -453,6 +542,19 @@ static int uvc_video_decode_start(struct uvc_streaming *stream,
if (buf-state != UVC_BUF_STATE_ACTIVE) {
struct timespec ts;
+ if (stream-cur_format-fcc == V4L2_PIX_FMT_MJPEG) {
+ /* for mjpeg stream start new buffer only if we have
+ * valid SOI signature. */
+ if (uvc_video_jpeg_soi(data, len)) {
+stream-last_fid = -1;
+ } else {
+uvc_trace(UVC_TRACE_FRAME,
+ Dropping payload no
+ jpeg_SOI signature found. );
+return -ENODATA;
+ }
+ }
+
if (fid == stream-last_fid) {
uvc_trace(UVC_TRACE_FRAME, Dropping payload (out of
sync).\n);
@@ -493,6 +595,16 @@ static int uvc_video_decode_start(struct uvc_streaming *stream,
if (fid != stream-last_fid buf-buf.bytesused != 0) {
uvc_trace(UVC_TRACE_FRAME, Frame complete (FID bit
toggled).\n);
+ /* For mjpeg stream, if FID was togled but there is no SOI
+
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Am 26.08.2011 20:36, schrieb Robert Krakora: Hello, Were you ever able to get H.264 content from the Logitech B990? I was able to using Stephan's patches and a patch to the v4l2src GStreamer element. I have both audio and video. However, I have not figured out how to affect the encoding parameters that I believe are exposed by the XUs. If you are interested, I can make what I have available for you. Best Regards, Rob Krakora I'd really like to know, is it worth to do it. I mean what is the image quality? What kind of H.264 bitstream is created? What is the key frame frequency? Can you grub and send me some sample file? What actual use cases? If i understand correctly, it will be transcoded any way in case of videochat. To record myself i'd prefer software encoder, for better quality. ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Hi Robert, thank you for your response, even if it sound a bit like zombie commercial :) I took a look on the specification and feel like i need to put two bits of doubt concerning this webcam, just in case some one wont to by it. reference to: http://www.logitech.com/en-us/for-business/products/webcams-headsets/devices/b990-hd-webcam - Native 5MP HD sensor - High-definition video in 720p widescreen mode with recommended system - Color depth: 24-bit true color - Frame rate: Up to 30 frames per second streaming video in 720p and VGA mode Doubts: - 24-bit true color - i'm confused here, seems like we can access only 16-bit color over yuv. will it really do 24bit with h264? Even if it will cost more power?... i think it is not true - Even if it has 5MPixel sensor, seems like we have access only to 1MP. According to this http://pastebin.com/9WFgytwY the biggest resolution what it provide is 1280x720, in other words High-definition video in 720p. This is also maximal resolution what can be uncompressed provided with ~15fps over USB2.0 . But it give us actually only 10 fps. JPEG compressed stream seems to be more realistic, it can indeed do 30 fps at HD720p. I guess it will take about 30Mbit/S bandwidth. Now after it sounds more realistic... H264 can reduce it even more (no doubt). In case of hardware encoder, we should be able to dynamically control encoding process, reduce keyframe frequency and be able to force KF if needed to recover the stream, (i guess you currently trying to find it out). And if you use gstreamer then, thelepythy+gstreamer should be able to control it as well. It looks like lots of work and fun. Suddenly i do not have this toy to play with it. I hope it is really worth it. Regards, Alexey. On 27.08.2011 19:47, Robert Krakora wrote: Hi Alexey, As webcam sampling size increases (5MP in the case of the Logitech B990), encoding in the camera becomes important to conserve USB bandwidth, and if you want to transmit content over an Ethernet connection it is even more important. Also, software encoding eats up host processor CPU. We have Intel Atom based mediaports that employ NVidia hardware assisted decoding. The are all equipped with cameras and software encoding would consume a fair amount of the CPU. We push the encoded data around the network. If you have a mid-high end CPU, no problem, use a software encoder if you wish. Just remember though, that your USB host controller + hub aggregate bandwidth will be mostly consumed by the raw data of the camera. At some point we will probably see USB 3.0 webcams to handle raw data from cameras as sampling size increases. I can send you some samples, but as of today I cannot control the encoders parameters, so it is not the highest quality, but still looks really good. Best Regards, Rob Krakora On Sat, Aug 27, 2011 at 2:09 AM, Alexey Fisher bug-tr...@fisher-privat.netwrote: Am 26.08.2011 20:36, schrieb Robert Krakora: Hello, Were you ever able to get H.264 content from the Logitech B990? I was able to using Stephan's patches and a patch to the v4l2src GStreamer element. I have both audio and video. However, I have not figured out how to affect the encoding parameters that I believe are exposed by the XUs. If you are interested, I can make what I have available for you. Best Regards, Rob Krakora I'd really like to know, is it worth to do it. I mean what is the image quality? What kind of H.264 bitstream is created? What is the key frame frequency? Can you grub and send me some sample file? What actual use cases? If i understand correctly, it will be transcoded any way in case of videochat. To record myself i'd prefer software encoder, for better quality. ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] question about bayer sensors
Hallo all, i know some people here was working with bayer raw data. I just discovered this word for me, so i need some help to understand it correctly. Normal bayer based image sensor have separate pixel for each color. Usually it made in 4 pixel squares, 1 - blue, 1 - red, 2 - green. There are different ways to precess this data but most easiest one will get one image pixel out of 4 physical pixels. This also mean, if my (for example) webcam has physical sensor size of 2MP, the real, not interpolated image data is MP*0.25. 1600x1200 (claimed resolution(2MP)) /2 = 800x600 (real/perfect image resolution(0,5MP)) Is this correct? Regards, Alexey. ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Webcam with H264 encoder not in Devicelist
Am 31.08.2011 08:36, schrieb Pierre Gronlier: Hi, On Wed, Aug 31, 2011 at 1:07 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Max, On Saturday 27 August 2011 11:50:55 Max Lapshin wrote: By the way, have you seen document http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1_052811.zip ? There are some encoder setup options. That's the totally broken spec I don't want to support. Even if it allows Linux users to use Skype with hardware encoding camera ? I think the question like to do or not to do is not quiet correct here. If make this webcam work, will do help in some situations... then why not. But it looks like Laurent is only responsible for UVC module and he is right - it is not belong to uvc. But - there are some cam now, what use uvc and notuvc stuff. It will be interesting to use uvcvideo like a library and have some extension part. B990 is one of this. On other side, if logitech will make next month new cam with other H264 specification, it will be work for one cam only. Then automatically will come the question, who will maintain this code. One more question: do h264 part work out of the box with uvc driver on windows? Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] B990 H.264 Sample
Am 30.08.2011 19:25, schrieb rob.krak...@messagenetsystems.com: Subject:B990 H.264 Sample Message:Here is a sample H.264 capture from the B990 with none of the capture controls altered and, of course, none of the encoding parameters alters as I have not yet figured out how to alter them. I got your sample, currently i can decode only one frame if i use ffmpeg, do fluendo can play this file? Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] question about bayer sensors
Thank you for your response, i still have one more question. I found my webcam do some strange scale work. For example the image detalisation of 640x480 is equal to the image with 400x300 resolution. If i grab 800x600 and downscale it to 640x480 i get better result. Do you know how scale logic is done on webcams? Or probably where i can read about it? Am 29.08.2011 09:58, schrieb jean-philippe francois: 2011/8/29 Alexey Fisher bug-tr...@fisher-privat.net mailto:bug-tr...@fisher-privat.net Hallo all, i know some people here was working with bayer raw data. I just discovered this word for me, so i need some help to understand it correctly. Normal bayer based image sensor have separate pixel for each color. Usually it made in 4 pixel squares, 1 - blue, 1 - red, 2 - green. There are different ways to precess this data but most easiest one will get one image pixel out of 4 physical pixels. This also mean, if my (for example) webcam has physical sensor size of 2MP, the real, not interpolated image data is MP*0.25. 1600x1200 (claimed resolution(2MP)) /2 = 800x600 (real/perfect image resolution(0,5MP)) Is this correct? I don't think the word 'real' is useful here. If you treat pixel data as black and white data, you can see pixel size details. Of course this black and white image is polluted by the fact that for a given visible light quantity, a green pixel won't give you the same value as a blue pixel, and the resulting image will look like a mozaic. If you take 4 pixels to make a half-sized image, you will miss some details. Not doing interpolation does not mean your image is more perfect or more real. It is just a suboptimal usage of data at your disposal. Let's suppose you could have three monochrome sensor with the same resolution as your webcam each taking the exact same image. From this image, you can construct a subsampled image at half the resolution. With bayer data, smaller details than in the subsampled 'perfect' image are available, yet you can only have and approximation of the full resolution image. The better your interpolation, the closer you are from the 'perfect' image, for some definition of perfect. Regards, Alexey. _ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.__de mailto:Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/__mailman/listinfo/linux-uvc-__devel 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] question about bayer sensors
Am 29.08.2011 09:58, schrieb jean-philippe francois: 2011/8/29 Alexey Fisher bug-tr...@fisher-privat.net mailto:bug-tr...@fisher-privat.net Hallo all, i know some people here was working with bayer raw data. I just discovered this word for me, so i need some help to understand it correctly. Normal bayer based image sensor have separate pixel for each color. Usually it made in 4 pixel squares, 1 - blue, 1 - red, 2 - green. There are different ways to precess this data but most easiest one will get one image pixel out of 4 physical pixels. This also mean, if my (for example) webcam has physical sensor size of 2MP, the real, not interpolated image data is MP*0.25. 1600x1200 (claimed resolution(2MP)) /2 = 800x600 (real/perfect image resolution(0,5MP)) Is this correct? I don't think the word 'real' is useful here. If you treat pixel data as black and white data, you can see pixel size details. Of course this black and white image is polluted by the fact that for a given visible light quantity, a green pixel won't give you the same value as a blue pixel, and the resulting image will look like a mozaic. If you take 4 pixels to make a half-sized image, you will miss some details. Not doing interpolation does not mean your image is more perfect or more real. It is just a suboptimal usage of data at your disposal. Let's suppose you could have three monochrome sensor with the same resolution as your webcam each taking the exact same image. From this image, you can construct a subsampled image at half the resolution. With bayer data, smaller details than in the subsampled 'perfect' image are available, yet you can only have and approximation of the full resolution image. The better your interpolation, the closer you are from the 'perfect' image, for some definition of perfect. Just to confirm that i understood, (i hope) the method i described before called Pixel Doubling Interpolation - the worst what i can do we bayer data :). Bilinear Interpolation, Gradient Based Interpolation.. and more - are other methods ... ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] spca1528 device..libv4l2: error turning on stream: Timer expired issue
According to this post you have no luck: http://www.spinics.net/lists/linux-media/msg19737.html Bad news, the images are compressed by an unknown algorithm (unknown from Linux point of vue). The decompression function could be found in some part of the ms-win driver, but: - first, I have no time to search and disassemble this function, - then, I did have this problem with an other webcam (17a1:0118), and after searching for a long time, nobody could find the function, and the driver is in stand-by since 2 years, - eventually, is this legal? All I can do is to code the driver and let you or anyone find the decompression function... Best regards. Am 02.09.2011 19:59, schrieb mhenriqu...@terra.cl: Hi guys, Not sure if is the right place to ask since this device use a gspca driver and not sure if that driver is related to uvc or not, if not please point me to the right place... Recently I'm trying to make work a Sunplus crappy mini HD USB camera, lsusb list this info related to the device: Picture Transfer Protocol (PIMA 15470) Bus 001 Device 015: ID 04fc:1528 Sunplus Technology Co., Ltd idVendor 0x04fc Sunplus Technology Co., Ltd idProduct 0x1528 bcdDevice1.00 iManufacturer 1 Sunplus Co Ltd iProduct2 General Image Devic iSerial 0 ... Using the gspca-2.13.6 on my Fed12 (2.6.31.6-166.fc12.i686.PAE kernel), the device is listed as /dev/video1 and no error doing a dmesg...but trying to make it work, let say with xawtv, I get: This is xawtv-3.95, running on Linux/i686 (2.6.31.6-166.fc12.i686.PAE) xinerama 0: 1600x900+0+0 WARNING: No DGA direct video mode for this display. /dev/video1 [v4l2]: no overlay support v4l-conf had some trouble, trying to continue anyway Warning: Missing charsets in String to FontSet conversion Warning: Missing charsets in String to FontSet conversion libv4l2: error turning on stream: Timer expired ioctl: VIDIOC_STREAMON(int=1): Timer expired ioctl: VIDIOC_S_STD(std=0x0 []): Invalid argument v4l2: oops: select timeout ..or doing: xawtv -c /dev/video1 -nodga -novm -norandr -noxv -noxv-video I get: ioctl: VIDIOC_STREAMON(int=1): Timer expired ioctl: VIDIOC_S_STD(std=0x0 []): Invalid argument v4l2: oops: select timeout libv4l2: error turning on stream: Timer expired libv4l2: error reading: Invalid argument vlc, cheese, etc give me simillar Timeout related messages... I read some post about simillar devices (but ID 12 or 14) that successfully works with gspca, so it seems that this one is close to work but may be need a fix on some timeout or something simillar on the driver... Any clue of what can be done?..any sugestions or right place to ask?, do you need any other info to help to digg into the problem? Thanks a lot. Mauricio ___ 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] uvc header question
Am 31.08.2011 00:32, schrieb Laurent Pinchart: Hi Alexey, On Thursday 25 August 2011 09:44:10 Alexey Fisher wrote: Hi Laurent, are there any reason why uvc_video_decode_start do not do precise header size checks? Are there many cameras with broken header size too? How precise do you mean ? The driver currently doesn't use much of the header, so it just makes sure that the header size is smaller than or equal to the packet size, and that it's at least 2 bytes long. I send you patch on what i work now to catch streams with fragmented packets.. what do you think about it? Will you apply some thing like this? I'm not sure about that. Webcams that would require something like that are so broken that I'm tempted to consider them as not UVC-compliant. They should be returned to vendors with a loud complaint. Your patch might help, but the sad story is that it can't completely fix the streams. There's always a chance that fragmented packets that contains no header will start with data that looks like a header. You won't be able to find a buller-proof solution. You are right, the idea is not to show definitely broken frames. If there is some thing what we can't filter, is ok. we did our best. I just thinking about build in uvc compliance tester insight of the module. Some thing what users can use right in shop or at home before 14 day return guarantee. You enables compliance test and it print results in in dmesg. One of test should be header check, error/drop rate, and so on. ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Sweex WC061 HD Webcam Sliver
Hi, you do not need to send any webcams, (but if you will, i'll accept it :D) better attach output of lsusb -vd 177f:0060 , also enable trace for uvc module, reporoduce this error and attach the dmesg as well: sudo rmmod uvcvideo sudo modprobe uvcvideo trace=0xfff Am 05.09.2011 16:19, schrieb Michael Tandy: Hi Linux-uvc-devel! I have a Sweex WC061 UVC webcam [1] I'm looking to capture mjpeg video from; the camera reports it supports MJPEG, but I'm having trouble with it. According to VIDIOC_ENUM_FMT it supports YUV 4:2:2 (0x56595559, YUYV) and MJPEG (0x47504a4d MJPG) and according to the manufacturer's spec sheet [2] the camera supports MJPEG. When I use YUV capture the camera works OK, but when I use MJPEG the V4L2 video capture example program [3] reports a select timeout. If I set the select timeout to 30 seconds or so I get some MJPEG-like data from the camera, but nothing that seems to make sense; I get some JPEG headers, but no end-of-file marker, and what data is present doesn't properly decode as MJPEG. On the other hand I have a Microsoft Lifecam Cinema HD that streams MJPEG just fine so if there's an error on my end I'm not sure what it is. Can anyone advise me on what the problem might be, or is there anyone who would be able to diagnose the problem in exchange for a free webcam? Thanks, Michael Tandy [1] VID 0x177f, PID 0x0060 [2] http://www.sweex.com/en/assortiment/sound-vision/webcams/WC061/specificaties/ [3] http://v4l2spec.bytesex.org/spec/capture-example.html ___ 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] Sweex WC061 HD Webcam Sliver
Am 06.09.2011 12:53, schrieb Michael Tandy: [99317.553237] uvcvideo: uvc_v4l2_ioctl(VIDIOC_STREAMON) [99317.554747] uvcvideo: uvc_v4l2_poll [99333.472385] uvcvideo: Dropping payload (error bit set). [99333.472389] uvcvideo: Frame complete (EOF found). [99333.472391] uvcvideo: EOF in empty payload. [99333.472429] uvcvideo: uvc_v4l2_poll [99333.472438] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) [99333.472447] uvcvideo: Dequeuing buffer 0 (3, 2676 bytes). hmm... the camera notify us about with error bit set, but current driver will just drop it and mark the buffer as faulty. According to uvc specification v1.1 in 4.3.1.7 Stream Error Code Control we can/should check the error reason: --- The host software should send a GET_CUR request to this control to determine the error when one of the following events occurs: - The Error bit in the video or still image payload header is set by the device For scenarios where the host is transmitting video data to the device, the host can not use the Error bit in the payload header to detect a device error. Therefore, in order to determine when a streaming error occurs, the host must rely on either a Control Change interrupt from the device or a bulk endpoint stall. I'm suddenly not so good to implement ne things without testing and probing. May be Laurent can do this? Or i need access to the webcam. Regards, Alexey. ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] uvc header question
Hi Laurent, Am 06.09.2011 17:24, schrieb Laurent Pinchart: Hi Alexey, On Monday 05 September 2011 17:48:42 Alexey Fisher wrote: Am 31.08.2011 00:32, schrieb Laurent Pinchart: On Thursday 25 August 2011 09:44:10 Alexey Fisher wrote: Hi Laurent, are there any reason why uvc_video_decode_start do not do precise header size checks? Are there many cameras with broken header size too? How precise do you mean ? The driver currently doesn't use much of the header, so it just makes sure that the header size is smaller than or equal to the packet size, and that it's at least 2 bytes long. I send you patch on what i work now to catch streams with fragmented packets.. what do you think about it? Will you apply some thing like this? I'm not sure about that. Webcams that would require something like that are so broken that I'm tempted to consider them as not UVC-compliant. They should be returned to vendors with a loud complaint. Your patch might help, but the sad story is that it can't completely fix the streams. There's always a chance that fragmented packets that contains no header will start with data that looks like a header. You won't be able to find a buller-proof solution. You are right, the idea is not to show definitely broken frames. If there is some thing what we can't filter, is ok. we did our best. I understand. I'm not sure if this should be included in the mainline uvcvideo driver though. It makes the code more complex to support a couple of completely broken devices, and doesn't guarantee that those devices will work correctly. ok, i give up. I just thinking about build in uvc compliance tester insight of the module. Some thing what users can use right in shop or at home before 14 day return guarantee. You enables compliance test and it print results in in dmesg. One of test should be header check, error/drop rate, and so on. That's an interesting idea. It should probably come with a userspace stress test software as well. you mean luvcview or some thing other? ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] uvc header question
On 07.09.2011 10:05, Laurent Pinchart wrote: Hi Alexey, On Wednesday 07 September 2011 08:14:45 Alexey Fisher wrote: Am 06.09.2011 17:24, schrieb Laurent Pinchart: On Monday 05 September 2011 17:48:42 Alexey Fisher wrote: Am 31.08.2011 00:32, schrieb Laurent Pinchart: On Thursday 25 August 2011 09:44:10 Alexey Fisher wrote: Hi Laurent, are there any reason why uvc_video_decode_start do not do precise header size checks? Are there many cameras with broken header size too? How precise do you mean ? The driver currently doesn't use much of the header, so it just makes sure that the header size is smaller than or equal to the packet size, and that it's at least 2 bytes long. I send you patch on what i work now to catch streams with fragmented packets.. what do you think about it? Will you apply some thing like this? I'm not sure about that. Webcams that would require something like that are so broken that I'm tempted to consider them as not UVC-compliant. They should be returned to vendors with a loud complaint. Your patch might help, but the sad story is that it can't completely fix the streams. There's always a chance that fragmented packets that contains no header will start with data that looks like a header. You won't be able to find a buller-proof solution. You are right, the idea is not to show definitely broken frames. If there is some thing what we can't filter, is ok. we did our best. I understand. I'm not sure if this should be included in the mainline uvcvideo driver though. It makes the code more complex to support a couple of completely broken devices, and doesn't guarantee that those devices will work correctly. ok, i give up. I'm sorry about that. I definitely appreciate the work you've done on this, but as I said I don't think we should cripple the driver with complex code just to try to support a bit better a webcam that is completely broken anyway. I just thinking about build in uvc compliance tester insight of the module. Some thing what users can use right in shop or at home before 14 day return guarantee. You enables compliance test and it print results in in dmesg. One of test should be header check, error/drop rate, and so on. That's an interesting idea. It should probably come with a userspace stress test software as well. you mean luvcview or some thing other? I'm thinking about a new command line software that would get/set controls at high speed for instance, verify that all controls reported by the device are actually supported, start/stop streaming multiple times, ... Something that would stress the device and try to crash it (which is unfortunately often quite easy :-)). That's nice :) and on kernel should provide file with statistics. Some thing like: /sys/kernel/debug/uvcvideo/stats It should have - packet count - frame count - payloads with error bit - empthy payloads - overruns, and underruns (for row) - jpeg completation (SOI - EOI) Any thing else? ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Problem booting with kernel 3.0 and ASUS UVC webcams
Hi, to get the idea of what is wrong here, we need at least dmesg. If you can't provide dmesg, but you can compile kernel, do git bisect. There is lots of howtos in internet about git bisect: http://ivanz.com/2009/03/27/git-bisect-the-awesome-way-to-find-the-mr-bug-commit/ or read: man git-bisect if you have questions, ask :) Regards, Alexey Am 08.09.2011 07:31, schrieb Remco Rijnders: Hi all, I'm not sure if this is the appropiate place and if this is a known issue or not, but one of our users as well as I myself ran into an issue where the combination of the webcam in an ASUS notebook and recent kernels result in the system not booting. See the report at https://bugs.mageia.org/show_bug.cgi?id=2425 I was hoping to have a look into this myself and see if I can find more information on the changes that would have caused this, but the instructions on the webpage for using git currently do not work due to the unavailability of git.kernel.org. For what it's worth, kernel 2.6.38 worked without issues. Any pointers or ideas are appreciated. Kind regards, Remco Rijnders ___ 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] Problem booting with kernel 3.0 and ASUS UVC webcams
Am 08.09.2011 08:07, schrieb Remco Rijnders: On Thu, Sep 08, 2011 at 07:49:00AM +0200, Alexey wrote in 4e68574c.6020...@fisher-privat.net: Hi, to get the idea of what is wrong here, we need at least dmesg. If you can't provide dmesg, but you can compile kernel, do git bisect. Hi Alexey, I'll look into this further tonight when at home again. A quick question which a quick google search did not answer for me: Is it possible to save the dmesg log when the system fails to boot? That is, is there a way to make it survive a reboot into a working kernel configuration? Thanks and regards, You can use netconsole: http://www.tocpcs.com/howto-log-a-kernel-panic-it-can-be-done/ or attach usb-serial adapter and log the dmegs over serial on other computer For both his methods you need second computer. or boot in verbose mode, no splash screen or so, and make a photo of log from display. Here you will need only one computer. ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
[Linux-uvc-devel] [RFC PATCH] uvc debugfs interface, initial patch
Hi Laurent, Am 08.09.2011 10:32, schrieb Laurent Pinchart: Hi Alexey, On Wednesday 07 September 2011 10:46:41 Alexey Fisher wrote: On 07.09.2011 10:05, Laurent Pinchart wrote: On Wednesday 07 September 2011 08:14:45 Alexey Fisher wrote: Am 06.09.2011 17:24, schrieb Laurent Pinchart: On Monday 05 September 2011 17:48:42 Alexey Fisher wrote: Am 31.08.2011 00:32, schrieb Laurent Pinchart: On Thursday 25 August 2011 09:44:10 Alexey Fisher wrote: Hi Laurent, are there any reason why uvc_video_decode_start do not do precise header size checks? Are there many cameras with broken header size too? How precise do you mean ? The driver currently doesn't use much of the header, so it just makes sure that the header size is smaller than or equal to the packet size, and that it's at least 2 bytes long. I send you patch on what i work now to catch streams with fragmented packets.. what do you think about it? Will you apply some thing like this? I'm not sure about that. Webcams that would require something like that are so broken that I'm tempted to consider them as not UVC-compliant. They should be returned to vendors with a loud complaint. Your patch might help, but the sad story is that it can't completely fix the streams. There's always a chance that fragmented packets that contains no header will start with data that looks like a header. You won't be able to find a buller-proof solution. You are right, the idea is not to show definitely broken frames. If there is some thing what we can't filter, is ok. we did our best. I understand. I'm not sure if this should be included in the mainline uvcvideo driver though. It makes the code more complex to support a couple of completely broken devices, and doesn't guarantee that those devices will work correctly. ok, i give up. I'm sorry about that. I definitely appreciate the work you've done on this, but as I said I don't think we should cripple the driver with complex code just to try to support a bit better a webcam that is completely broken anyway. I just thinking about build in uvc compliance tester insight of the module. Some thing what users can use right in shop or at home before 14 day return guarantee. You enables compliance test and it print results in in dmesg. One of test should be header check, error/drop rate, and so on. That's an interesting idea. It should probably come with a userspace stress test software as well. you mean luvcview or some thing other? I'm thinking about a new command line software that would get/set controls at high speed for instance, verify that all controls reported by the device are actually supported, start/stop streaming multiple times, ... Something that would stress the device and try to crash it (which is unfortunately often quite easy :-)). That's nice :) and on kernel should provide file with statistics. Some thing like: /sys/kernel/debug/uvcvideo/stats It should have - packet count - frame count - payloads with error bit - empthy payloads - overruns, and underruns (for row) - jpeg completation (SOI - EOI) I don't think the driver should parse MJPEG data to extract markers. This can be done by the userspace application. Any thing else? The number of failed and total control requests would also be interesting. Statistics about the status endpoint would also be interesting, to verify that the device correctly sends control change events for instance (although those are not properly supported in the driver yet). this is initial patch for debugfs interface. I didn't implemented all requests, i think the size of this patch is any way too big now. Here is how it's working. After driver is loaded it create debugfs/usb/uvcvideo directory. If some device is attached it create device dir like this: 001.007_046d.0991 (first part is usb bus, second is usb id). In this directory it create file called stats. Here is the content of this file: usb id: 046d:0991, usb bus: 001:007 packet size: 944(6) state: idle -- show the state of device. capture or idle start time: 1316585466 - unix epoch time in seconds. capture time: 106 - capture time in seconds. format: YUV 4:2:2 (YUYV) resolution: 320x240 @ 30 decode_start: 846880 - this show how many payloads we started to decoding. bad_header: 0 -- haw many payloads was dropped, because of bad header uvc_empty: 604160 -- correct uvc payloads without video data uvc_stream_err: 0 -- count of payloads with err bit set sequence: 955 -- count of fid switches out_of_sync: 0 -- out of sync calls diff --git a/drivers/media/video/uvc/Makefile b/drivers/media/video/uvc/Makefile index 2071ca8..c26d12f 100644 --- a/drivers/media/video/uvc/Makefile +++ b/drivers/media/video/uvc/Makefile @@ -1,5 +1,5 @@ uvcvideo-objs := uvc_driver.o uvc_queue.o uvc_v4l2.o uvc_video.o uvc_ctrl.o \ - uvc_status.o uvc_isight.o + uvc_status.o uvc_isight.o uvc_debugfs.o ifeq ($(CONFIG_MEDIA_CONTROLLER),y) uvcvideo-objs += uvc_entity.o endif diff --git a/drivers
Re: [Linux-uvc-devel] uvcvideo: Failed to resubmit video URB (-27)
On 20.09.2011 22:34, Pitt, Jason N wrote: Hi- I have a ubuntu 11.04 machine that I'm trying to capture 12 usb webcam feeds on. The webcams are split over 3 pcie usb cards and the motherboards's usb controller. I'm encountering instability using both streamer and guvcview. I can get all 12 streams running but eventually one dies (in a minute or so) and then about 3 more die as well...leaving me with 7 or 8 stable streams. What is the limitation? The guvcview error is: Could not grab image (select timeout): Resource temporarily unavailable which is repeated repeatedly the streamer error is: v4l2: oops: select timeouts this usually only effects one or two cameras with both programs dmesg yields: [ 5330.048166] uvcvideo: Failed to resubmit video URB (-27). [ 5330.048174] uvcvideo: Failed to resubmit video URB (-27). [ 5330.048178] uvcvideo: Failed to resubmit video URB (-27). [ 5330.048183] uvcvideo: Failed to resubmit video URB (-27). [ 5330.048188] uvcvideo: Failed to resubmit video URB (-27). I only need to capture an image from every camera every 2.4 seconds, if someone can provide me a good work-around I'd appreciate it! Hi, usb controller or usb device is usually responsible URB errors. -27 is th error number. You can find it in include/asm-generic/errno-base.h 27 is EFBIG in this case, then in Documentation/usb/error-codes.txt you can find description of this error. -EFBIG Host controller driver can't schedule that many ISO frames. I currently do not know if usbcore itself do not allow so many ISO frames, or only one controller can't handle it. Are there any system in this error? I mean do cams day on one controller or only one per controller? Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Problem booting with kernel 3.0 and ASUS UVC webcams
On 20.09.2011 03:29, Remco Rijnders wrote: On Thu, Sep 08, 2011 at 08:53:19AM +0200, Alexey wrote in 4e68665f.3090...@fisher-privat.net: Am 08.09.2011 08:07, schrieb Remco Rijnders: On Thu, Sep 08, 2011 at 07:49:00AM +0200, Alexey wrote in 4e68574c.6020...@fisher-privat.net: Hi, to get the idea of what is wrong here, we need at least dmesg. If you can't provide dmesg, but you can compile kernel, do git bisect. You can use netconsole: http://www.tocpcs.com/howto-log-a-kernel-panic-it-can-be-done/ or attach usb-serial adapter and log the dmegs over serial on other computer For both his methods you need second computer. or boot in verbose mode, no splash screen or so, and make a photo of log from display. Here you will need only one computer. Hi, Apologies for the late revert. I've been busy with other things and spent too much time on trying to get netconsole working without luck. Anyways, using git bisect I came to the following result: [remmy@ketelbinkie uvcvideo]$ git bisect bad a96aa5342d575980e5b572cde88036f3a878ebee is the first bad commit commit a96aa5342d575980e5b572cde88036f3a878ebee Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Tue Jun 28 18:17:48 2011 -0300 [media] uvcvideo: Ignore entities for terminals with no supported format If a streaming interface has no supported format, the driver won't create a video device for the associated terminal. Fix an oops by ignoring that terminal when creating links between entities. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com :04 04 0296cc04d3923f1f93205ac6164802b514ad3162 b4753a4e36122dc9605bcb44caa4aa1328146d0d M drivers I'm not 100% sure that this is the proper commit as the kernel crashes at a later point (at the KDM login screen) than in my initial observation where it would not even complete booting. Furthermore, while doing the git bisect good thing, at the last point I had to do make CONFIG_DEBUG_SECTION_MISMATCH=y as the kernel would not compile without it anymore. That said, I notice that the kernel panic this kernel resulted in is very similar to that which gudvinr reported on the 11th, also with an ASUS system so I am beginning to see a pattern there. Some fuzzy screenshots: http://milkzilla.webconquest.com/~remmy/UVC/1.jpg http://milkzilla.webconquest.com/~remmy/UVC/2.jpg Please let me know if I can do anything further to help debug this. For now I have disabled the camera in the bios which allows me to
[Linux-uvc-devel] [PATCH] uvcvideo: fix UVC_ENTITY_TYPE check.
This patch fix small regression cousing crashe after device was detected. In case of buildin webcam it prevented laptop to boot. This regression was introduced by patch a96aa5342: uvcvideo: Ignore entities for terminals with no supported format Bug-reported-by: Remco Rijnders re...@webconquest.com Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net --- drivers/media/video/uvc/uvc_entity.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/uvc/uvc_entity.c b/drivers/media/video/uvc/uvc_entity.c index 48fea37..29e2399 100644 --- a/drivers/media/video/uvc/uvc_entity.c +++ b/drivers/media/video/uvc/uvc_entity.c @@ -49,7 +49,7 @@ static int uvc_mc_register_entity(struct uvc_video_chain *chain, if (remote == NULL) return -EINVAL; - source = (UVC_ENTITY_TYPE(remote) != UVC_TT_STREAMING) + source = (UVC_ENTITY_TYPE(remote) == UVC_TT_STREAMING) ? (remote-vdev ? remote-vdev-entity : NULL) : remote-subdev.entity; if (source == NULL) -- 1.7.5.4 ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [PATCH] uvcvideo: fix UVC_ENTITY_TYPE check.
Am 23.09.2011 10:19, schrieb Laurent Pinchart: Hi Alexey, On Friday 23 September 2011 07:51:24 Alexey Fisher wrote: This patch fix small regression cousing crashe after device was detected. In case of buildin webcam it prevented laptop to boot. This regression was introduced by patch a96aa5342: uvcvideo: Ignore entities for terminals with no supported format Thanks for the patch. I've already fixed the bug in my stable branch (http://git.linuxtv.org/pinchartl/uvcvideo.git/shortlog/refs/heads/uvcvideo- stable) and Mauro said he would pull that for v3.1. ouch :) can you please take a look on my debugfs patch. ___ 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
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. ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Please fix this bug of 5986:0203
Hi Daniele,
can you please apply this patch on top of current kernel git.
With this patch you can get access to some webcams infos without
spaming the sys log.
After you compiled kernel and rebooted, or reloaded uvcvideo module, you
can do this:
watch cat /sys/kernel/debug/usb/uvcvideo/001.007_046d.0808/stats
or just cat it, to monitore what's happening. Instead of
001.007_046d.0808 you need to set some thing different.
The field i interested in, is error bit or uvc_stream_err. Seems
like some cams depends on this bit, and current uvcvideo code do not use it.
If your cam hangs after it set err_bit than may be we can do some thing.
I plan to invest my time to err_bit handler right after uvc_debugfs
patch will go upstream.
Regards,
Alexey.
Am 16.10.2011 02:06, schrieb Daniele Coccato:
Hello,
there is a bug of 5986:0203 which causes the webcam to automatically
turn to red and black after some seconds since initialization.
This happens only on the FIRST initialization of the webcam, later
initializations will not cause this problem anymore, until reboot.
This bug exists since LONG time (more than 2 years) and it is pretty annoying.
Could any developer please fix it?
If any more info is needed, feel free to ask.
Thanks.
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
diff --git a/drivers/media/video/uvc/Makefile b/drivers/media/video/uvc/Makefile
index 2071ca8..c26d12f 100644
--- a/drivers/media/video/uvc/Makefile
+++ b/drivers/media/video/uvc/Makefile
@@ -1,5 +1,5 @@
uvcvideo-objs := uvc_driver.o uvc_queue.o uvc_v4l2.o uvc_video.o uvc_ctrl.o \
- uvc_status.o uvc_isight.o
+ uvc_status.o uvc_isight.o uvc_debugfs.o
ifeq ($(CONFIG_MEDIA_CONTROLLER),y)
uvcvideo-objs += uvc_entity.o
endif
diff --git a/drivers/media/video/uvc/uvc_debugfs.c b/drivers/media/video/uvc/uvc_debugfs.c
new file mode 100644
index 000..b0c2313
--- /dev/null
+++ b/drivers/media/video/uvc/uvc_debugfs.c
@@ -0,0 +1,213 @@
+
+#include linux/slab.h
+#include linux/debugfs.h
+#include linux/usb.h
+
+#include uvcvideo.h
+
+#define MAX_DIRNAME 18
+
+#define STAT_BUF_SIZE 1024
+
+struct snap {
+ int slen;
+ char str[STAT_BUF_SIZE];
+};
+
+/* we do not need really precise time, seconds are ok */
+void uvc_debugfs_gettimeofday(__kernel_time_t *time)
+{
+ struct timeval tv;
+
+ do_gettimeofday(tv);
+ *time = tv.tv_sec;
+}
+
+static int uvc_debugfs_stat_open(struct inode *inode, struct file *file)
+{
+ struct uvc_device *dev = inode-i_private;
+ struct usb_device *udev = dev-udev;
+ struct uvc_debugfs_stat *uvc_stat = dev-debugfs_stat;
+ struct snap *sp;
+
+ sp = kmalloc(sizeof(struct snap), GFP_KERNEL);
+
+ if (sp == NULL)
+ return -ENOMEM;
+
+ sp-slen = 0;
+
+ if (uvc_stat-current_state)
+ uvc_debugfs_gettimeofday(uvc_stat-last_time);
+
+ /* device descriptor */
+ sp-slen += snprintf(sp-str + sp-slen, STAT_BUF_SIZE - sp-slen,
+ usb id: %04x:%04x, usb bus: %03i:%03i\n,
+ le16_to_cpu(udev-descriptor.idVendor),
+ le16_to_cpu(udev-descriptor.idProduct),
+ udev-bus-busnum, udev-devnum);
+
+ /* capture state */
+ sp-slen += snprintf(sp-str + sp-slen, STAT_BUF_SIZE - sp-slen,
+ packet size: %d(%d)\n
+ state: %s\n,
+ uvc_stat-best_psize, uvc_stat-altsetting,
+ uvc_stat-current_state ? capture : idle);
+
+ sp-slen += snprintf(sp-str + sp-slen, STAT_BUF_SIZE - sp-slen,
+ start time: %ld\n
+ capture time: %ld\n
+ fist data: %ld\n
+ first error bit: %ld\n
+ first out of sync: %ld\n,
+ uvc_stat-start_time,
+ uvc_stat-last_time - uvc_stat-start_time,
+ uvc_stat-first_data,
+ uvc_stat-first_err_bit,
+ uvc_stat-first_oos);
+
+ /* last/current format decsriptor */
+ sp-slen += snprintf(sp-str + sp-slen, STAT_BUF_SIZE - sp-slen,
+ format: %s\n
+ resolution: %ux%u @ %u\n,
+ uvc_stat-format_name,
+ uvc_stat-width, uvc_stat-height,
+ uvc_stat-frame_interval ?
+ 1000/uvc_stat-frame_interval : 0);
+
+ sp-slen += snprintf(sp-str + sp-slen, STAT_BUF_SIZE - sp-slen,
+ decode_start: %u\n
+ bad_header: %u\n
+ uvc_empty: %u\n
+ uvc_stream_err: %u\n
+ sequence: %u\n
+ out_of_sync: %u\n,
+ uvc_stat-decode_start, uvc_stat-bad_header,
+ uvc_stat-uvc_empty,
+ uvc_stat-uvc_stream_err, uvc_stat-sequence,
+ uvc_stat-out_of_sync);
+
+ file-private_data = sp;
+ return 0;
+}
+
+/* nothing to change */
+static ssize_t uvc_debugfs_stat_read(struct file *file, char __user *buf,
+ size_t nbytes, loff_t *ppos)
+{
+ struct snap *sp = file-private_data;
+
+ return simple_read_from_buffer(buf, nbytes, ppos, sp-str, sp-slen);
+}
+
+/* nothing to change */
+static int uvc_debugfs_stat_release(struct inode *inode, struct file *file)
+{
+ struct snap *sp = file-private_data;
+ file-private_data = NULL;
+ kfree(sp);
+ return 0;
+}
+
+/* connect all funcs for debugfs */
+const struct file_operations uvc_debugfs_stat_fops = {
+ .owner =THIS_MODULE,
+ .open = uvc_debugfs_stat_open,
+ .llseek =
Re: [Linux-uvc-devel] 05c8:0403 listed as supported but is not working
Hi Andrey,
can you please apply this patch on top of current kernel git.
With this patch you can get access to some webcams infos without
spaming the sys log.
After you compiled kernel and rebooted, or reloaded uvcvideo module, you
can do this:
watch cat /sys/kernel/debug/usb/uvcvideo/001.007_046d.0808/stats
or just cat it, to monitore what's happening. Instead of
001.007_046d.0808 you need to set some thing different.
The field i interested in, is error bit or uvc_stream_err. Seems
like some cams depends on this bit, and current uvcvideo code do not use it.
If your cam hangs after it set err_bit than may be we can do some thing.
I plan to invest my time to err_bit handler right after uvc_debugfs
patch will go upstream.
It looks like you are software developer, you are kindly invited to help
if you like. We need it.
Regards,
Alexey.
Am 15.10.2011 22:41, schrieb overclocked:
Hello,
Now, after 3 months, I have checked my webcam (05c8:0403, which does not work
on Ubuntu 11.04 - video stops after several seconds) under Windows 7
(Enterprise Edition, Trial) and all is working perfectly. So now I'm sure that
it's not a hardware problem, or, at least it could be avoided.
Thank You in advance,
Kind Regards,
Andrey Sapegin.
15.08.2011, 00:08, overclockedovercloc...@yandex.ru:
Hello,
unfortunately, I have no possibility to check webcam on Windows (I have
only Ubuntu 11.04 on my laptop and currently do not have a storage to
backup all and install Windows to check it).
I have used wireshark on Linux...
There are 2 usb interfaces:
usbmon1 and usbmon2
I have captured the usbmon1... See file attached.
I also have captured usbdump.
It's 120 Mb, so I have used depositfiles for it:
http://depositfiles.com/files/ssee74mok
Also I have noticed that after some time webcam disappears from lsusb...
Thank You in advance,
Kind Regards,
Andrey.
On 08/14/2011 06:12 PM, Alexey Fisher wrote:
Hi,
can you confirm, this webcam do work on windows with uvcvideo driver?
If yes, can you capture usb traffic like it described here:
http://lindi.iki.fi/lindi/usb/usbsnoop.txt
As alternative you can use wireshark.
Your webcam located on Bus 001 Device 017, some times you need to know
it to capture usb dump.
Also it will be good to have usb dump from linux, usbmon module should
be loaded/compiled.
To capture you need:
cat /dev/usbmon1 usbdump
use Ctrl+C to stop it.
gzip usbdump
Actually you can use wireshark on linux as well.
if it really big use rapidshare or filesonic or some thing like this
for upload.
Am 14.08.2011 13:58, schrieb overclocked:
Yes, thank you for the answer.
See files in the attachment.
--
Andrey Sapegin,
PhD Student,
University of Leipzig,
Software Developer,
Unister GmbH,
+4915778339304,
and...@sapegin.org.
Promotionstudent,
Universitaet Leipzig,
Software Entwickler,
Unister GmbH,
+4915778339304,
and...@sapegin.org.
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
diff --git a/drivers/media/video/uvc/Makefile b/drivers/media/video/uvc/Makefile
index 2071ca8..c26d12f 100644
--- a/drivers/media/video/uvc/Makefile
+++ b/drivers/media/video/uvc/Makefile
@@ -1,5 +1,5 @@
uvcvideo-objs := uvc_driver.o uvc_queue.o uvc_v4l2.o uvc_video.o uvc_ctrl.o \
- uvc_status.o uvc_isight.o
+ uvc_status.o uvc_isight.o uvc_debugfs.o
ifeq ($(CONFIG_MEDIA_CONTROLLER),y)
uvcvideo-objs += uvc_entity.o
endif
diff --git a/drivers/media/video/uvc/uvc_debugfs.c b/drivers/media/video/uvc/uvc_debugfs.c
new file mode 100644
index 000..b0c2313
--- /dev/null
+++ b/drivers/media/video/uvc/uvc_debugfs.c
@@ -0,0 +1,213 @@
+
+#include linux/slab.h
+#include linux/debugfs.h
+#include linux/usb.h
+
+#include uvcvideo.h
+
+#define MAX_DIRNAME 18
+
+#define STAT_BUF_SIZE 1024
+
+struct snap {
+ int slen;
+ char str[STAT_BUF_SIZE];
+};
+
+/* we do not need really precise time, seconds are ok */
+void uvc_debugfs_gettimeofday(__kernel_time_t *time)
+{
+ struct timeval tv;
+
+ do_gettimeofday(tv);
+ *time = tv.tv_sec;
+}
+
+static int uvc_debugfs_stat_open(struct inode *inode, struct file *file)
+{
+ struct uvc_device *dev = inode-i_private;
+ struct usb_device *udev = dev-udev;
+ struct uvc_debugfs_stat *uvc_stat = dev-debugfs_stat;
+ struct snap *sp;
+
+ sp = kmalloc(sizeof(struct snap), GFP_KERNEL);
+
+ if (sp == NULL)
+ return -ENOMEM;
+
+ sp-slen = 0;
+
+ if (uvc_stat-current_state)
+ uvc_debugfs_gettimeofday(uvc_stat-last_time);
+
+ /* device descriptor */
+ sp-slen += snprintf(sp-str + sp-slen, STAT_BUF_SIZE - sp-slen,
+ usb id: %04x:%04x, usb bus: %03i:%03i\n,
+ le16_to_cpu(udev-descriptor.idVendor),
+ le16_to_cpu(udev-descriptor.idProduct),
+ udev-bus-busnum, udev-devnum);
+
+ /* capture state */
+ sp-slen += snprintf(sp-str + sp-slen, STAT_BUF_SIZE - sp-slen,
+ packet size: %d(%d)\n
+ state: %s\n,
+ uvc_stat-best_psize
Re: [Linux-uvc-devel] Is 064E:E285 supported?
Can you please attach the output of this command: lsusb -vd 064e:e285 lsusb_dump Am 21.10.2011 15:55, schrieb Arto Karila: Yes it is! I have been fighting for several days to get it to work with Ubuntu 11.10. I now downgraded to 11.04 and it just started working. I don't want to use Unity anyway - so 11.04 is fine for me. Sorry for spamming the list. Art ___ 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] Dual sensor, single controller, one USB Device
Am 28.10.2011 18:01, schrieb cheshirekow: On Sun, 2011-10-23 at 13:50 -0400, cheshirekow wrote: On 10/22/2011 03:16 AM, Alexey Fisher wrote: Can you please attach the output of this command: lsusb -vd 10f1:1a26 lsusb_dump Sure. The dump file is attached. Thanks! Has anyone by chance managed to take a look at this lsusb dump? To recap: the HP Slate has two integrated we cams: One forward facing for video calls, and one higher-resolution rear-facing for snapping photos. There appears to be a single controller for both cameras. In linux, lsusb only shows one webcam device. In windows, the device manager also shows only one device for the webcam. However, in windows applications that use the webcam (i.e. HP's webcam application, and in skype) I'm able to select which one to use as an option. In linux, there is only one video device, /dev/video0. There does not appear to be any control available from uvcdynctrl or within vlc to select which physical camera to use. I've tried setting the resolution in vlc when I use the open capture device menu item. I know that the forward facing camera is VGA so I tried specifying 640x480, but the result is that it shows the rear-camera stream at a low resolution, rather then showing the forward-camera stream. I'd appreciate any suggestions on how to get the forward-facing camera to work in linux (for skype/google video calls). Also, if it is clear that this facility is not available in UVC and that there is no way this is possilble, that would also be useful information. Thanks again Hi, suddenly i do not see any control to switch the sensor. I assume there can be two variants how it may work: 1. vendor specific extension unit for uvc 2. or usb mode switcher if both sensors have same capabilities, the 1. make sense. If not then second. Because this usb dump report settings only for one sensor. For 1. it will be probably possible to control it with libwebcam. For 2. it should be possible to control it with some kind of usb_modeswitch (i'm not up to date). To find what it is actually, there can be fallowing options: 1. sniff usb traffic 2. see if the windows driver has some advise for us 3. unscrew your laptop and find what control use your webcam. Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] (no subject)
Hi Josef, fallowing quirk are supported: #define UVC_QUIRK_STATUS_INTERVAL 0x0001 #define UVC_QUIRK_PROBE_MINMAX 0x0002 #define UVC_QUIRK_PROBE_EXTRAFIELDS 0x0004 #define UVC_QUIRK_BUILTIN_ISIGHT0x0008 #define UVC_QUIRK_STREAM_NO_FID 0x0010 #define UVC_QUIRK_IGNORE_SELECTOR_UNIT 0x0020 #define UVC_QUIRK_FIX_BANDWIDTH 0x0080 #define UVC_QUIRK_PROBE_DEF 0x0100 #define UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200 Assume your Dell webcam need UVC_QUIRK_PROBE_EXTRAFIELDS, and Logilink need UVC_QUIRK_PROBE_EXTRAFIELDS. If you wont to use only one quirk at time you should use only numbers from the list. Can you please confirm my assumption. Am 30.10.2011 19:12, schrieb Josef Burg: Hi, I have found 2 devices supported by uvcvideo in quirks mode, which are not currently on the list of supported devices: The first is an integrated Webcam in my Dell Vostro 3550 (1bcf:2809) which only works with quirks set to 4 (and up). The second one is an external wireless usb webcam from LogiLink (0416:a91a). This one only works with quirks set to 2. As far as i saw, you need the output of lsusb, so I attached it as two text files. Greetings, Josef ___ 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] Working with Logitech B990: Issues.
Am 03.11.2011 07:56, schrieb Alexey Rempel:
Am 03.11.2011 02:20, schrieb Kaz Kylheku:
Hey all,
I'm working with the B990 on an ARM-based embedded system based on
linux-2.6.27.47.
H.264 is coming out of the cam, but I don't see an SPS/PPS, and all the
frames are
P slices, e.g. like this and similar:
00 00 00 01 61 9a 00 38 37 e0 20 30 ...
Secondly, after some period of running, the USB controller throws up an
over-current error,
and then the device is not usable without a reboot. Maybe this big sucker
really draws too much current?
Interesting, i tested some different Logitech webcams. The standard
cams, which can do only yav and jpeg, suck ~170 mA in low qulity mode
(frame rate higer then 15fps). By frame rate lower or equal to 15fps,
they go to high quality mode, and suck ~200 mA. Do h264 encoder will
really add 300mA more?
Usually I am not able to two consecutive successful opens of the device.
By the way, I patched the driver to make the trace and quirks sysctl
parameters, since I have it compiled into the kernel.
Index: linux-2.6.27.47/drivers/media/video/uvc/uvc_driver.c
===
--- linux-2.6.27.47.orig/drivers/media/video/uvc/uvc_driver.c
+++ linux-2.6.27.47/drivers/media/video/uvc/uvc_driver.c
@@ -30,6 +30,7 @@
#include linux/usb.h
#include linux/videodev2.h
#include linux/vmalloc.h
+#include linux/sysctl.h
#include linux/wait.h
#include asm/atomic.h
@@ -39,6 +40,7 @@
#define DRIVER_AUTHOR Laurent Pinchart laurent.pinch...@skynet.be
#define DRIVER_DESC USB Video Class driver
+#define DRIVER_NAME uvcvideo
#ifndef DRIVER_VERSION
#define DRIVER_VERSION v0.1.0
#endif
@@ -1970,6 +1972,37 @@ struct uvc_driver uvc_driver = {
},
};
+static struct ctl_table uvc_sysctl_entries[] =
+{
+ {
+ .procname = trace,
+ .data = uvc_trace_param,
+ .maxlen = sizeof( int ),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = quirks,
+ .data = uvc_quirks_param,
+ .maxlen = sizeof( int ),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ { .ctl_name = 0 }
+};
+
+static struct ctl_table uvc_sysctl_root[] =
+{
+ {
+ .procname = uvc_video,
+ .mode = 0555,
+ .child = uvc_sysctl_entries,
+ },
+ { .ctl_name = 0 }
+};
+
+static struct ctl_table_header *uvc_sysctl_header;
+
static int __init uvc_init(void)
{
int result;
@@ -1981,14 +2014,22 @@ static int __init uvc_init(void)
uvc_ctrl_init();
+ uvc_sysctl_header = register_sysctl_table(uvc_sysctl_root);
+
result = usb_register(uvc_driver.driver);
+
if (result == 0)
- printk(KERN_INFO DRIVER_DESC ( DRIVER_VERSION )\n);
+ printk(KERN_INFO DRIVER_NAME : DRIVER_DESC ( DRIVER_VERSION
)\n);
+
+ if (uvc_sysctl_header == 0)
+ printk(KERN_ERR DRIVER_NAME : unable to register sysctl table\n);
+
return result;
}
static void __exit uvc_cleanup(void)
{
+ unregister_sysctl_table(uvc_sysctl_header);
usb_deregister(uvc_driver.driver);
}
___
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] [PATCH 1/2] uvcvideo: Add debugfs support
Am 03.11.2011 17:27, schrieb Laurent Pinchart: Create a debugfs entry per UVC stream. This will be used to export stream statistics. Signed-off-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com Ok, i see you made it in mind more fore online statistic. I wonted to make it more for postmortum trouble shooting. For example i added start time and time of first frame because some apps make problems if cam starting too slow. I also added time of first error_bit and so. (probably not in the patch i send you before) The question is, do you wont to make separate files for verbose report and for statistic? My idea is, if some body has some problem with the cam, instead of telling reload module with ...blabla... i can just tell: reproduce the error and send me content of /sys/debug...bla ... You know what i mean? For example we can add firs usb error we got and time stamp of it, to make it more computer forensic friendly :) So if you prefer to make separate files i give my SoB :) Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [PATCH 2/2] uvcvideo: Extract video stream statistics
Am 03.11.2011 17:27, schrieb Laurent Pinchart: Export the statistics through debugfs. Signed-off-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com Signed-off-by: Alexey Fisher bug-tr...@fisher-privat.net ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] [PATCH 1/2] uvcvideo: Add debugfs support
Am 04.11.2011 11:23, schrieb Laurent Pinchart: Hi Alexey, On Friday 04 November 2011 09:19:45 Alexey Fisher wrote: Am 03.11.2011 17:27, schrieb Laurent Pinchart: Create a debugfs entry per UVC stream. This will be used to export stream statistics. Signed-off-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com Ok, i see you made it in mind more fore online statistic. I wonted to make it more for postmortum trouble shooting. For example i added start time and time of first frame because some apps make problems if cam starting too slow. I also added time of first error_bit and so. (probably not in the patch i send you before) It's indeed not in the latest patch I've got. The question is, do you wont to make separate files for verbose report and for statistic? My idea is, if some body has some problem with the cam, instead of telling reload module with ...blabla... i can just tell: reproduce the error and send me content of /sys/debug...bla ... You know what i mean? For example we can add firs usb error we got and time stamp of it, to make it more computer forensic friendly :) That sounds like a good idea to me. The real question will then be to pick what information to report. Things like the selected alternate setting and the bandwidth requested by the camera are very important for instance. I'd like that to be exposed through a separate file, as that information isn't really statistics. Are you OK with such an approach ? OK :) ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Frame rate for Logitech QuickCam Pro for Notebooks
Am 08.11.2011 22:47, schrieb big...@wackywombats.com: Hi, I have a linux application that uses the Logitech QuickCam Pro for Notebooks (vendor/device id 0469:0991). I am using openCV to grab the frame and then display it. I get 15 frames/second wih this app. If I plug this same camera into a Windows box and run the same app, I get 30 frames/second. I'm trying to understand what is causing this difference in frame rates. Does anyone have any ideas on what could be going on? Thanks! Hi, Because this cam use exposure with auto priority. Disable it and you will get your noisy 30 fps. You can do it with: uvcdynctrl -s Exposure, Auto Priority 0 ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Z-star camera problem
Hi Vignesh, can you please attach output of: lsusb -vd 0acda:3430 lsusb_dump Am 10.11.2011 12:02, schrieb vignesh rajendran: Hi all I am in embedded linux and facing a problem with Z-star electronics camera having the id 0acda:3430. When testing with mplayer , I am getting following error, # mplayer tv:// -tv driver=v4l2:width=320:height=220:device=/dev/video0:noaudio -flip -vo fbdev2 -fs 30 MPlayer UNKNOWN-4.6.1 (C) 2000-2010 MPlayer Team Playing tv://. TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski olschew...@zpr.uni-koeln.de mailto:olschew...@zpr.uni-koeln.de comment: first try, more to come ;-) v4l2: your device driver does not support VIDIOC_G_STD ioctl, VIDIOC_G_PARM was used instead. Selected device: NAMUGA 1.3M Webcam Capabilities: video capture streaming supported norms: inputs: 0 = Camera 1; Current input: 0 Current format: YUYV v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument tv.c: norm_from_string(pal): Bogus norm parameter, setting default. v4l2: ioctl enum norm failed: Invalid argument Error: Cannot set norm! Selected input hasn't got a tuner! v4l2: ioctl set mute failed: Invalid argument v4l2: ioctl query control failed: Invalid argument v4l2: select timeout == Opening video decoder: [raw] RAW Uncompressed Video Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] [fbdev2] Can't put VSCREENINFO: Invalid argument [fbdev2] Can't put VSCREENINFO: Invalid argument Opening video filter: [flip] Movie-Aspect is undefined - no prescaling applied. [fbdev2] Can't put VSCREENINFO: Invalid argument [fbdev2] Can't put VSCREENINFO: Invalid argument [swscaler @ 0x21f77d0] BICUBIC scaler, from yuyv422 to rgb555le using C VO: [fbdev2] 320x240 = 320x240 BGR 15-bit [fs] Selected video codec: [rawyuy2] vfm: raw (RAW YUY2) == Audio: no sound Starting playback... v4l2: select timeout V: 0.0 1/ 1 ??% ??% ??,?% 0 0 $50 v4l2: select timeout V: 0.0 2/ 2 ??% ??% ??,?% 0 0 $50 v4l2: select timeout V: 0.0 3/ 3 ??% ??% ??,?% 0 0 $50 v4l2: select timeout MPlayer interrupted by signal 2 in module: video_read_frame V: 0.0 4/ 4 ??% ??% ??,?% 0 0 $50 v4l2: select timeout v4l2: ioctl set mute failed: Invalid argument v4l2: 0 frames successfully processed, 1 frames dropped. Exiting... (Quit) I am getting v4l2: select timeout repeatedly.I am using 3.0 kernel. And my another camera Namuga(0ac8:c335) is working fine Please help me out of this. -- Regards Vignesh Rajendran ___ 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] Suggestion for FAQ update
Hi Laurent, i think it is good time to update FAQ. And add notice about reading the FAQ before ask some thing on maeling list. My suggestion entry to FAQ: I have an UVC webcam but it is not working. What do you need to troubleshoot it? 1. Read How do I find out whether my camera is a UVC device or not? 2. Create usb dump file and attach it to email: lsusb -vd 046d:08cb lsusb_dump 3. Enable debug for uvcvideo module: sudo echo 0xfff /sys/module/uvcvideo/parameters/trace 4. reproduce the problem 5. attach dmesg to email dmesg dmesg PS: Please do not use HTML formatet mails. == Your suggestions? Regards, Alexey ___ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Z-star camera problem
Hi, it looks like you use not hi-speed (usb2.0) controller. If it work in full speed then you can get only ~10 Mbit/sec. with 320x240 it should be low frame rate or try 160x120. please send dmesg from you arm system. Enable debug for uvcvideo module: sudo echo 0xfff /sys/module/uvcvideo/parameters/trace reproduce the problem attach dmesg to email dmesg dmesg PS: Please do not use HTML formatet mails. Am 11.11.2011 07:34, schrieb vignesh rajendran: On Fri, Nov 11, 2011 at 6:25 AM, vignesh rajendran vickylinu...@gmail.com mailto:vickylinu...@gmail.com wrote: On Fri, Nov 11, 2011 at 5:19 AM, vignesh rajendran vickylinu...@gmail.com mailto:vickylinu...@gmail.com wrote: On Thu, Nov 10, 2011 at 11:59 AM, Alexey Fisher bug-tr...@fisher-privat.net mailto:bug-tr...@fisher-privat.net wrote: Hi Vignesh, can you please attach output of: lsusb -vd 0ac8:3430 lsusb_dump Hi Sorry.I changed the id.Z-star camera id is 0ac8:c335.And the lsusb log attached with this mail.The log with ubuntu 10.04 and it was working fine in ubuntu when tested with mplayer.But in arm , it is not working. Regards Vignesh Rajendran And this is the log with arm-board. Sorry again.I changed the log.This is the correct log. Am 10.11.2011 12:02, schrieb vignesh rajendran: Hi all I am in embedded linux and facing a problem with Z-star electronics camera having the id 0acda:3430. When testing with mplayer , I am getting following error, # mplayer tv:// -tv driver=v4l2:width=320:height=__220:device=/dev/video0:noaudio -flip -vo fbdev2 -fs 30 MPlayer UNKNOWN-4.6.1 (C) 2000-2010 MPlayer Team Playing tv://. TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski olschew...@zpr.uni-koeln.de mailto:olschew...@zpr.uni-koeln.de mailto:olschew...@zpr.uni-__koeln.de mailto:olschew...@zpr.uni-koeln.de comment: first try, more to come ;-) v4l2: your device driver does not support VIDIOC_G_STD ioctl, VIDIOC_G_PARM was used instead. Selected device: NAMUGA 1.3M Webcam Capabilities: video capture streaming supported norms: inputs: 0 = Camera 1; Current input: 0 Current format: YUYV v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument tv.c: norm_from_string(pal): Bogus norm parameter, setting default. v4l2: ioctl enum norm failed: Invalid argument Error: Cannot set norm! Selected input hasn't got a tuner! v4l2: ioctl set mute failed: Invalid argument v4l2: ioctl query control failed: Invalid argument v4l2: select timeout ==__==__== Opening video decoder: [raw] RAW Uncompressed Video Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] [fbdev2] Can't put VSCREENINFO: Invalid argument [fbdev2] Can't put VSCREENINFO: Invalid argument Opening video filter: [flip] Movie-Aspect is undefined - no prescaling applied. [fbdev2] Can't put VSCREENINFO: Invalid argument [fbdev2] Can't put VSCREENINFO: Invalid argument [swscaler @ 0x21f77d0] BICUBIC scaler, from yuyv422 to rgb555le using C VO: [fbdev2] 320x240 = 320x240 BGR 15-bit [fs] Selected video codec: [rawyuy2] vfm: raw (RAW YUY2) ==__==__== Audio: no sound Starting playback... v4l2: select timeout V: 0.0 1/ 1 ??% ??% ??,?% 0 0 $50 v4l2: select timeout V: 0.0 2/ 2 ??% ??% ??,?% 0 0 $50 v4l2: select timeout V: 0.0 3/ 3 ??% ??% ??,?% 0 0 $50 v4l2: select timeout MPlayer interrupted by signal 2 in module: video_read_frame V: 0.0 4/ 4 ??% ??% ??,?% 0 0 $50 v4l2: select timeout v4l2: ioctl set mute failed: Invalid argument v4l2: 0
