Hello,
I have found the following patch in the matter:
https://sourceforge.net/p/linux-uvc/mailman/attachment/56F905A0.80807%40numberfour.eu/1/
It exposes a kernel module parameter for adjusting required bandwidth.
It has a typo inside, but after fixing this patch I have been able to
run 5 pcs. of MS HD-5000cameras at 640****@15FPS simultenaously.
I have also found a bunch of compressed files here:
https://sourceforge.net/p/linux-uvc/mailman/message/34748762/
These changes does the similar approach (kernel parameter), but the
compression ratio also modifiable through an unused private V4L2 parameter.
I am unsure why the maintainer ignored this thread, but attaching
tar/gzipped folders are not the clearest way to indicate that you would
like to submit a kernel patch...
Also I do not think that either approach is acceptible from the
perspective of an end user.
The private parameter method would require the userspace apps to have
knowledge of the underlying hardware type which is not a common case.
Supporting this feature would require the modification of existing
userspace apps.
Adjusting the kernel module parameter is definietly a better approach,
but still problematic from the end users side. Power users will be able
to deal with it, but it is still brings up questions: what if the user
selects some higher resultion and higher FPS than it should, etc.
I would propose the following:
- Find the least JPG compressable image type. (Some hints could be found
here:
http://dsp.stackexchange.com/questions/2010/what-is-the-least-jpg-compressible-pattern-camera-shooting-piece-of-cloth-sca)
- Create a tool which is able to display this image on the screen while
logging the the frame sizes for all supported resolutions.*
- Create a lookup table which would include the max frame size for each
problematic camera (specified by PID:VID) for each supported resolution.
I know it would require create a LUT patch for each camera, which could
be cumbersome, but I think that is the way to go. Patches went
That's my 50 cents, please leave some feedback to finally get around
this issue and mainline a fix which would be the best from end user
perspective.
Best regards,
Miklos Marton
* I have already started to implement this with Qt, but the priority of this issue decreased on my TODO list after I got my cams rolling.
Stuart FIXED the problem, but none of the linux-uvc-devel high priests would take 30min to fold his fixes into the
source tree. Stuart is being too modest when he says he made a proposal. It was a full fledged FIX.
How many more times do new and random people have to ask for this fix before it gets folded in? I think it is bordering
on a disgrace.
Post by stuartHi Miklos,
I did quite a bit of work on this at the start of 2016 to make
modifications to the UVC driver but got no response from a UVC developer
on this mailing list when I proposed the changes. If you manage to
locate a developer then I can probably help you with this.
My post is the second lowest entry on this thread. It seems that most
people want to up-vote the post that says you can't do it.
http://superuser.com/questions/431759/using-multiple-usb-webcams-in-linux/1018342#1018342
Stuart.
Post by Miklos MartonHello all,
I am trying to use multiple Microsoft HD-5000 cameras in MJPEG mode
simultenaously. (Using the mjpg-streamer)
No space left on device
I have tried the 128 quirk, but it dit not helped.
Some people had solved this issue by opening the second camera later,
but it did solved the problem.
I have increased the trace parameter and the relevant dmesg output is
http://pastebin.com/nr82RbTE
Device requested 3072 B/frame bandwidth.
Just like in YUV mode (tried with SVV).
Is there any workaround or patch for this problem?
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Linux-uvc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linux-uvc-devel
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Linux-uvc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linux-uvc-devel