Plusieurs / dev / vidéo pour un périphérique physique
D'abord quelques spécifications: mon ordinateur est un HP ELITEBOOK 8460P. Il est livré avec une webcam HP de chiconie intégrée HP HD.
Mon problème est que beaucoup d'applications (puits, au moins Skype et GUVCVIEW) présentent plusieurs lignes pour la même webcam; En effet, si je fais ls -l /dev | grep video, Je reçois ce qui suit:
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
J'en ai 2 /dev/video[n] avec une seule webcam (intégré); Skype fonctionnera correctement avec /dev/video0, mais pas avec /dev/video1. Idem pour GUVCVIEW.
Si je branche une autre webcam USB, par exemple un logitech One, je reçois ce qui suit avec 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
Et ce qui suit avec 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 nouvelles entrées: /dev/media1, /dev/video2 et /dev/video3.
J'ai même trouvé une webcam Sony (CEVCECM) qui ajoute jusqu'à 4 nouveaux appareils. Les journaux dmesg:
[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
Et les fichiers de périphérique résultants avec 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 nouvelles entrées: /dev/media1 et /dev/video2 à /dev/video5.
J'ai l'impression que les fichiers corrects à utiliser sont les /dev/media[n] Ceux, mais Skype et GuVCView ne manquent pas de le faire et de revenir à la section /dev/video[n].
Je n'ai pas ce problème avec webcamoid par exemple.
Si quelqu'un a une idée, je le prends. En attendant, je poursuivrai l'enquête ...
--- édité le 2019-05-14 ---
Obtenu des informations intéressantes en utilisant v4l2-ctl --device=/dev/video* --all. Pour la webcam HD de Chicony HP HD, ses 2 fichiers de périphérique ont des fonctionnalités de périphérique différentes:
# Devices capabilities for /dev/video0
Video Capture
Streaming
Extended Pix Format
# Devices capabilities for /dev/video1
Metadata Capture
Streaming
Extended Pix Format
Je reçois des résultats similaires pour les webcams USB. Ainsi, après tout, ce que Skype et GuVCView échouent à faire, c'est uniquement répertorier les périphériques vidéo prenant en charge le Video Capture Capacité de l'appareil.
Le deuxième appareil fournit des métadonnées sur les données vidéo du premier périphérique. Les nouveaux appareils ont été introduits par ce correctif:
Plus d'informations sur l'interface V4L MetaData peuvent être trouvées ici:
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/dev-meta.html
Pour la course des périphériques de la classe vidéo USB MILL, cela vous fournit principalement informations d'horodatage plus précises . Pour les caméras telles que la ligne RealSense d'Intel, fournir une gamme plus large de données sur la capture de l'image .
Vraisemblablement, ces données ont été divisées dans un nœud de périphérique séparé, car il ne pouvait pas être facilement livré sur le nœud de périphérique principal de manière compatible. C'est un peu douloureux, car (a) des applications qui ne se soucient pas de ces métadonnées doivent maintenant filtrer les périphériques supplémentaires, et (b) les applications qui se soucient des métadonnées ont besoin d'un moyen de lier les deux appareils ensemble .
Vraiment agaçant, mais vient de trouver une solution: Laissez Udev attribuer des symboles pour les nœuds de périphérique uniquement pour les cames "réelles", pas les métadonnées. Ils sont identiques (?) À udev, c'est-à-dire.
udevadm info -n /dev/video0 est le même que udevadm info -n /dev/video1, mais ils obtiennent un autre AlT {Index}. Donc, pour mes 2 cames, je me suis retrouvé avec le suivant /etc/udev/rules.d/99-cam.rules:
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="eb1a", ATTRS{idProduct}=="299f", ATTR{index}=="0", MODE="0664", GROUP="video", SYMLINK+="cams/cam1"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="1908", ATTRS{idProduct}=="2311", ATTR{index}=="0", MODE="0664", GROUP="video", SYMLINK+="cams/cam2"
Après cela, utilisez simplement /dev/cams/camX Dans votre application au lieu de la /dev/videoY