Primeiro algumas especificações: meu computador é um HP EliteBook 8460p. Ele vem com uma webcam Chicony HP HD integrada.
Meu problema é que muitos aplicativos (bem, pelo menos Skype e guvcview) estão exibindo várias linhas para a mesma webcam; na verdade, se eu fizer isso ls -l /dev | grep video
, recebo o seguinte:
crw-rw---- 1 root video 29, 0 Apr 16 08:13 fb0
crw-rw---- 1 root video 243, 0 Apr 16 08:13 media0
crw-rw----+ 1 root video 81, 0 Apr 16 08:13 video0
crw-rw----+ 1 root video 81, 1 Apr 16 08:13 video1
Tenho 2 /dev/video[n]
com apenas uma webcam (integrada); O Skype funcionará corretamente com /dev/video0
, mas não com /dev/video1
. O mesmo para guvcview.
Se eu conectar outra webcam USB, por exemplo, uma da Logitech, recebo o seguinte dmesg
:
[21222.638802] usb 2-2: new high-speed USB device number 20 using xhci_hcd
[21222.970684] usb 2-2: New USB device found, idVendor=046d, idProduct=08c2, bcdDevice= 0.05
[21222.970755] usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[21222.972518] uvcvideo: Found UVC 1.00 device <unnamed> (046d:08c2)
[21226.044535] uvcvideo 2-2:1.0: Entity type for entity Extension 4 was not initialized!
[21226.044538] uvcvideo 2-2:1.0: Entity type for entity Extension 8 was not initialized!
[21226.044540] uvcvideo 2-2:1.0: Entity type for entity Extension 10 was not initialized!
[21226.044541] uvcvideo 2-2:1.0: Entity type for entity Extension 9 was not initialized!
[21226.044543] uvcvideo 2-2:1.0: Entity type for entity Extension 3 was not initialized!
[21226.044545] uvcvideo 2-2:1.0: Entity type for entity Processing 2 was not initialized!
[21226.044547] uvcvideo 2-2:1.0: Entity type for entity Camera 1 was not initialized!
[21226.044746] input: UVC Camera (046d:08c2) as /devices/pci0000:00/0000:00:1c.7/0000:25:00.0/usb2/2-2/2-2:1.0/input/input35
[21226.137559] usb 2-2: Warning! Unlikely big volume range (=3072), cval->res is probably wrong.
[21226.137569] usb 2-2: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1
E o seguinte com ls -l /dev/ | grep video
:
crw-rw---- 1 root video 29, 0 Apr 16 08:13 fb0
crw-rw---- 1 root video 243, 0 Apr 16 08:13 media0
crw-rw---- 1 root video 243, 1 Apr 16 14:06 media1
crw-rw----+ 1 root video 81, 0 Apr 16 08:13 video0
crw-rw----+ 1 root video 81, 1 Apr 16 08:13 video1
crw-rw----+ 1 root video 81, 2 Apr 16 14:06 video2
crw-rw----+ 1 root video 81, 3 Apr 16 14:06 video3
3 novas entradas: /dev/media1
, /dev/video2
e /dev/video3
.
Até encontrei uma webcam Sony (CEVCECM) que soma até 4 novos dispositivos. Os dmesg
registros:
[21927.665747] usb 2-2: new high-speed USB device number 23 using xhci_hcd
[21927.817330] usb 2-2: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice= 9.01
[21927.817339] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[21927.817343] usb 2-2: Product: USB2.0 Hub
[21927.824119] hub 2-2:1.0: USB hub found
[21927.824814] hub 2-2:1.0: 4 ports detected
[21928.113733] usb 2-2.4: new high-speed USB device number 24 using xhci_hcd
[21928.223184] usb 2-2.4: New USB device found, idVendor=054c, idProduct=097b, bcdDevice=21.12
[21928.223192] usb 2-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[21928.223197] usb 2-2.4: Product: CEVCECM
[21928.223201] usb 2-2.4: Manufacturer: Sony
[21928.223206] usb 2-2.4: SerialNumber: DHZD10412EUHK1
[21928.227506] uvcvideo: Found UVC 1.00 device CEVCECM (054c:097b)
[21928.242592] uvcvideo: Unable to create debugfs 2-24 directory.
[21928.242780] uvcvideo 2-2.4:1.0: Entity type for entity Extension 7 was not initialized!
[21928.242783] uvcvideo 2-2.4:1.0: Entity type for entity Extension 3 was not initialized!
[21928.242785] uvcvideo 2-2.4:1.0: Entity type for entity Processing 2 was not initialized!
[21928.242787] uvcvideo 2-2.4:1.0: Entity type for entity Camera 1 was not initialized!
[21928.242877] input: CEVCECM: CEVCECM as /devices/pci0000:00/0000:00:1c.7/0000:25:00.0/usb2/2-2/2-2.4/2-2.4:1.0/input/input38
E os arquivos de dispositivo resultantes com ls -l /dev | grep video
:
crw-rw---- 1 root video 29, 0 Apr 16 08:13 fb0
crw-rw---- 1 root video 243, 0 Apr 16 08:13 media0
crw-rw---- 1 root video 243, 1 Apr 16 14:18 media1
crw-rw----+ 1 root video 81, 0 Apr 16 08:13 video0
crw-rw----+ 1 root video 81, 1 Apr 16 08:13 video1
crw-rw----+ 1 root video 81, 2 Apr 16 14:18 video2
crw-rw----+ 1 root video 81, 3 Apr 16 14:18 video3
crw-rw----+ 1 root video 81, 4 Apr 16 14:18 video4
crw-rw----+ 1 root video 81, 5 Apr 16 14:18 video5
5 novas entradas: /dev/media1
e /dev/video2
para /dev/video5
.
Eu sinto que os arquivos corretos a serem usados são os /dev/media[n]
únicos, mas o Skype e o guvcview de alguma forma não conseguem fazê-lo e fazem fallback para o arquivo /dev/video[n]
.
Eu não tenho esse problema com o Webcamoid, por exemplo.
Se alguém tiver uma ideia, eu aceito. Enquanto isso vou continuar a investigação...
--- Editado em 14-05-2019 ---
Obteve algumas informações interessantes usando v4l2-ctl --device=/dev/video* --all
. Para a webcam Chicony HP HD, seus 2 arquivos de dispositivo têm recursos de dispositivo diferentes:
# Devices capabilities for /dev/video0
Video Capture
Streaming
Extended Pix Format
# Devices capabilities for /dev/video1
Metadata Capture
Streaming
Extended Pix Format
Obtenho resultados semelhantes para as webcams USB. Então, afinal, talvez o que o Skype e o guvcview não consigam fazer seja apenas listar os dispositivos de vídeo que suportam a Video Capture
capacidade do dispositivo.
O segundo dispositivo fornece metadados sobre os dados de vídeo do primeiro dispositivo. Os novos dispositivos foram introduzidos por este patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=088ead25524583e2200aa99111bea2f66a86545a
Mais informações sobre a interface de metadados V4L podem ser encontradas aqui:
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/dev-meta.html
Para dispositivos de classe de vídeo USB comuns, isso geralmente apenas fornece informações de carimbo de data e hora mais precisas . Para câmeras como a linha RealSense da Intel, forneça uma gama mais ampla de dados sobre como a imagem foi capturada .
Presumivelmente, esses dados foram divididos em um nó de dispositivo separado porque não podiam ser entregues facilmente no nó de dispositivo primário de maneira compatível. No entanto, é um pouco trabalhoso, pois (a) aplicativos que não se preocupam com esses metadados agora precisam filtrar os dispositivos extras e (b) aplicativos que se preocupam com os metadados precisam de uma maneira de unir os dois dispositivos .
Realmente irritante, mas acabou de encontrar uma solução: deixe o udev atribuir links simbólicos para nós de dispositivo apenas para as câmeras "reais", não para os metadados. Eles são idênticos (?) ao udev, ou seja,
udevadm info -n /dev/video0
é o "mesmo" queudevadm info -n /dev/video1
, mas eles obtêm um ATTR{index} diferente. Então, para minhas 2 câmeras, acabei com o seguinte/etc/udev/rules.d/99-cam.rules
:Depois disso é só usar
/dev/cams/camX
na sua aplicação ao invés do/dev/videoY