Bug 473878 - Low framerate with uvcvideo device
Summary: Low framerate with uvcvideo device
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 10
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-12-01 09:07 UTC by James
Modified: 2008-12-29 18:19 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-12-29 18:19:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Output from lsusb -v -d 0402:5606 (18.80 KB, text/plain)
2008-12-03 23:48 UTC, James
no flags Details
libv4l log from using cheese (81.75 KB, text/plain)
2008-12-11 00:09 UTC, James
no flags Details

Description James 2008-12-01 09:07:06 UTC
Description of problem:
The framerate on my UVC webcam is very slow (around 1-2 frames/second). Using cheese also takes up a lot of CPU time. One some previous kernels, it would start out smooth and then decay to the jerky motion I get now.

Version-Release number of selected component (if applicable):
kernel-2.6.27.7-132.fc10.x86_64

How reproducible:
Always.
  
Actual results:
Jerky video, 1-2 frames/second. Lots of CPU time used.

Expected results:
Smooth video.

Relevant bits of dmesg:

uvcvideo: Found UVC 1.00 device USB2.0 Camera (0402:5606)
uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
input: USB2.0 Camera as /devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2:1.0/input/input11
usb 1-2: New USB device found, idVendor=0402, idProduct=5606
usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-2: Product: USB2.0 Camera
uvcvideo: device USB2.0 Camera requested null bandwidth, defaulting to lowest.

Comment 1 Hans de Goede 2008-12-03 12:18:42 UTC
I think this is the culprit:
uvcvideo: device USB2.0 Camera requested null bandwidth, defaulting to lowest.

I've forwarded this report to the author and maintainer of the uvcvideo driver. I will let you know when he gets back to me.

Comment 2 Hans de Goede 2008-12-03 23:38:04 UTC
Can you please in a terminal run:

/sbin/lsusb -v -d 0402:5606 > log

And then attach the resulting log file (called log) to this bugreport?

Thanks!

Comment 3 James 2008-12-03 23:48:51 UTC
Created attachment 325610 [details]
Output from lsusb -v -d 0402:5606

Comment 4 Hans de Goede 2008-12-08 15:55:13 UTC
Thanks for the lsusb output. Unfortunately that didn't help in tracking this down.

Can you please do *all* of the following and report back the results / attach the generated log files (Yes we're groping in the dark here, hopefully one of these will give us a clue where to look).

0) Make sure you've got the latest libv4l / cheese:
yum install libv4l cheese

1) Can you run top while watching the cam and see where all the CPU time is going?
Thanks!

2) While running top can you please press "shift + m" to sort by memory and see if
any process is consuming lots of memory (and growing).

3) Can you please run cheese with the cam from a terminal like this:
LIBV4L2_LOG_FILENAME=/tmp/log cheese

And then after viewing video for a couple of seconds, try changing the resolution in the preferences menu, and then after a couple of seconds more, quit.

And last, but not least, attach /tmp/log here.

Comment 5 James 2008-12-11 00:09:03 UTC
[james@rhapsody ~]$ rpm -q cheese libv4l
cheese-2.24.2-1.fc10.x86_64
libv4l-0.5.7-1.fc10.x86_64

No process is taking up an excessive amount of CPU time or memory. cheese seems to run at around 15% CPU (processor clocked down to 800 MHz). It takes a few seconds for cheese to open the camera, and shortly afterwards there's a burst of high processor load which dies down after a few seconds.

cheese.log attached. Started out at 640x480, changed down to 320x240.

Comment 6 James 2008-12-11 00:09:34 UTC
Created attachment 326561 [details]
libv4l log from using cheese

Comment 7 Hans de Goede 2008-12-11 07:33:47 UTC
Hmm, which kernel version are you using? Can you please try with the -134 kernel which has recently been released as an update?

Comment 8 James 2008-12-29 14:34:45 UTC
Sorry for the delay in getting back to you. I've been seeing inconsistent results on this one. I'm currently using kernel-2.6.27.10-167.fc10.x86_64. Now, I think the framerate has *something* to do with the ambient lighting. I found at work, for example, with fluorescent lighting, the picture ran smoothly at all resolutions (even 1280x1024). Same at home right now with plenty of ambient daylight. But I think it's when there's less light around (mostly incandescent bulbs), the picture gets jerky.

Comment 9 James 2008-12-29 14:37:18 UTC
Further to the above: I guess it's possible that this *is* the intended behaviour of this web-cam. (Nevertheless, the "null bandwidth" messages remain.)

Comment 10 Hans de Goede 2008-12-29 18:19:32 UTC
(In reply to comment #8)
> Sorry for the delay in getting back to you. I've been seeing inconsistent
> results on this one. I'm currently using kernel-2.6.27.10-167.fc10.x86_64. Now,
> I think the framerate has *something* to do with the ambient lighting. I found
> at work, for example, with fluorescent lighting, the picture ran smoothly at
> all resolutions (even 1280x1024). Same at home right now with plenty of ambient
> daylight. But I think it's when there's less light around (mostly incandescent
> bulbs), the picture gets jerky.

Ah, yes that is normal, digital (web) cams are like analog cams, they expose there light sensitive cells to light for a certain amount of time for each frame. The so called exposure time. If the lighting conditions become less light this exposure time needs to become bigger (there isa  huge factor between artificial light only and daylight). It is quite normal for cams with cheaper sensors to need exposre times of up to 250 ms or even more to get a picture which is not much too dark in low light conditions (artificial light only, even if bright for the human eye, is such a low light condition). Since it then needs 250 ms to sense one frame, it can not do above 4 fps. So this is not a uvcvideo bug, closing.


Note You need to log in before you can comment on or make changes to this bug.