[MEGOLDVA] két webkamera egyszerre

 ( face | 2011. június 10., péntek - 9:43 )

Sziasztok!

Két ugyan olyan webkamerát szeretnék használni egyszerre. Az issue a következő:
luvcview-val tesztelem, az egyik kamera megy rendesen, a másik elszáll a lenti hibaüzenettel.

libv4l2: error turning on stream: No space left on device
Unable to start capture: No space left on device
Error grabbing

A használt kamera: Trust 16530
Google azt mondta, hogy sávszélesség problémája lehet, de ha az egyik trust helyett egy másik webkamerát rakok be (jelen esetben egy logitech quickcam pro 9000), akkor megy mindkettő rendesen.

Találkoztatok már ilyennel?

root@debian:/tmp# uname -a
Linux debian 2.6.32-5-686 #1 SMP Wed May 18 07:08:50 UTC 2011 i686 GNU/Linux
root@debian:/tmp# lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 012: ID 145f:0167 Trust
Bus 001 Device 008: ID 145f:0167 Trust
Bus 001 Device 002: ID 13d3:5071 IMC Networks
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

lsusb -v -> http://rafb.info/yWYQA7e9U
lsmod -> http://rafb.info/yjEnAWU5u

plusz infó:
dmesg vége amikor bedugom a kamerát:

[81727.380278] usb 1-3: new high speed USB device using ehci_hcd and address 18
[81727.559129] usb 1-3: New USB device found, idVendor=145f, idProduct=0167
[81727.559152] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[81727.559169] usb 1-3: Product: Trust Webcam
[81727.559181] usb 1-3: Manufacturer: Salix Corp.
[81727.559625] usb 1-3: configuration #1 chosen from 1 choice
[81727.561939] uvcvideo: Found UVC 1.00 device Trust Webcam (145f:0167)
[81727.564689] input: Trust Webcam as /devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3:1.0/input/input24

A problémát végül az uvclinux kernel driver megpatchelésével oldottam meg úgy, hogy beállítottam egy fix bandwidth értéket, függetlenül attól, hogy mit igényel a kamera. Ezzel a módszerrel 3 webcam is tud párhuzamosan ~7-8 fps-sel menni 2048x1536-os felbontáson MJPEG-vel. Mivel nekem megfelelt ez a gány módszer is, így ennyiben hagytam.

Hint: érdemes megpróbálni az rmmod uvcvideo && modprobe uvcvideo quirks=128 trace=1024 parancsot ilyen gond esetén, ámbár ha jól tudom csak YUYV esetén működhet.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem lehet, hogy a Logitech MJPG-t streamel, a Trust pedig tömörítetlent? Ez magyarázat lehet a sávszélesség problémára.

Milyen felbontást használsz? Egyetlen USB2.0-ás vezérlőn át nekem nem ment át két tömörítetlen kamera 640x480-as kép mellett YUYV kódolással.

A Trustok is MJPG-t tolnak sajnos, pedig nem rossz az ötlet. Próbáltam már azt is, hogy direkt megadom, hogy MJPG legyen és a legkisebb supportált felbontáson csinálom, de úgy sem ment. (luvcview -d /dev/video1 -f MJPG -s 160x120)

Valami egyéb ötlet esetleg?

Megoldódott.

Mi volt a hiba, és mi lett a megoldás (okulásképpen)?

Sok kamera hibásan adja meg a számára lefoglalandó sávszélesség nagyságát, itt is ez volt a helyzet. (utánaolvasgatva egyébként egészen általános jelenség sajnos) Felbontástól és framerate-től függetlenül, mindig ugyan akkora sávot kért. Ha az uvcvideo-t trace-szel töltjük be, akkor a syslogban megmutatja, hogy mennyit igényel a kamera, így hamar ki lehet deríteni. Mivel elég nagyot kért, így már nem jutott hely másnak (gondolom yuyv melletti maxot kérhette)

A megoldás valójában tiszta gányolás lett. Letöltöttem az uvcvideo forráskódját, megkerestem azt a részt, ahol a kamera megmondja, hogy mekkora sávra van szüksége és simán átírtam egy kisebb fix értékre. (drivers/media/video/uvc/uvc_video.c uvc_init_video függvény eleje) Újrafordít, betölt, megy. Ez nyilván nem értelmes és általános megoldása a problémának, de nekem megfelelt.

A problémán hackelés nélkül a fentebb leírt módon a quriks=128 yuyv esetén segíthet (újraszámolja a felbontás és framerate függvényében a valós igényt). MJPEG esetén sajnos nem ennyire egyszerű a helyzet, mivel a tömörítés minőségének függvénye a valós sávszélesség használat, de dolgoznak ezen is már, majd meglátjuk mi lesz belőle.