On 05/07/2010 09:10 AM, Laurent Pinchart wrote:
I'm attaching the patch in case anyone wants to play with this or
suggest ways to improve it.
Interesting approach, but definitely a hack. I'm not sure if it has a chance
to make it to the driver.
Most definitely a hack. I just included it because someone had
expressed interest in the solution. If there was a way to do it faster,
it might be a good thing to pursue but I can't think of a good way to
synchronize the frames in such a way to not lose a lot of each frame
(like you mentioned in your other response) after continuing urb
submission and waste a lot of transfer bandwidth.
One thing I had a problem with is that it seems some of the capture images
are corrupted. This patch was against 2.6.27.2. A little old I know but I'm
working on an embedded device.
2) I modified ehci-sched.c to not raise the ENOSPC error. That solution
actually lets me capture on all 8 cameras at 15 FPS. This has other
implications though and I'm not sure it is a very good solution. It
does tell me that perhaps the Linux ISO scheduler could perhaps use look
through. One major discrepancy is that bandwidth is allocated based on
the max packet size I think but for my compressed images (MJPG) each
frame is only a fraction of the max allocated bandwidth.
That might be the real culprit. Maybe the camera is simply requesting too much
bandwidth compared to its real requirements.
Can you check whether the video streaming interface has multiple alternate
settings ? If so, which one does the uvcvideo driver chose ? You can get the
information from the kernel log if you set the UVC_TRACE_VIDEO flag.
The camera is definitely selecting more bandwidth than it needs. The
size of each image does vary when I'm streaming MJPG images. It is
usually somewhere along the lines of 110-150K at maximum resolution
(1280x1024 for these cameras).
Perhaps this is the problem with these cameras:
Here is the information from the Uncompressed video format descriptor
for the 1280x1024 YUYV data:
dwMaxVideoFrameBufferSize 2621440
And here is the information returned from the MJPG descriptor for the
same sized compressed image:
dwMaxVideoFrameBufferSize 2621440
Logitech C500 by the way.
If the camera request an alternate setting that isn't the smallest, you might
try to experiment with hardcoding a lower bandwidth in uvc_video_init.
I think I actually tried that a while back when I first started playing
with this issue. If I recall, selecting a lower bandwidth interface
caused a mismatch between the information in each packets and the
placement of the frame headers in the UVC protocol. Result was it never
dequeued a buffer. I'm not sure that isn't worth investigating further
though. I may have done something wrong.
Thank for your analysis of this. Helps to have more than just my eyes
look over the issue.
In the mean time, I'm having quite good luck with my EHCI hack. I just
let all the ISO frames through and I get all the images from all 8
cameras back at 15 FPS. I may come back to this problem before I'm all
the way finished and see if there is a way to button this up cleaner but
temporarily the solution is working for me.
-Dennis
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
