Multiple /dev/video for One Physical Device – How to Manage

cameradevicesvideo

First some specs: my computer is an HP EliteBook 8460p. It comes with an integrated Chicony HP HD webcam.

My issue is that a lot of applications (well, at least Skype and guvcview) are displaying multiple lines for the same webcam; indeed, if I do ls -l /dev | grep video, I get the following:

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

I have 2 /dev/video[n] with only one (integrated) webcam; Skype will work properly with /dev/video0, but not with /dev/video1. Same for guvcview.

If I plug another USB webcam, for example a logitech one, I get the following with 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

And the following with 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 new entries: /dev/media1, /dev/video2 and /dev/video3.

I even found a Sony webcam (CEVCECM) that adds up to 4 new devices. The dmesg logs:

[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

And the resulting device files with 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 new entries: /dev/media1 and /dev/video2 to /dev/video5.

I feel like the correct files to use are the /dev/media[n] ones, but Skype and guvcview somehow fail to do so and fallback to the /dev/video[n].

I don't have this issue with Webcamoid for example.

If anyone has an idea, I take it. In the meantime I will continue the investigation…

— Edited the 2019-05-14 —

Got some interesting information using v4l2-ctl --device=/dev/video* --all. For the Chicony HP HD webcam, its 2 device files have different device capabilities:

# Devices capabilities for /dev/video0
Video Capture
Streaming
Extended Pix Format

# Devices capabilities for /dev/video1
Metadata Capture
Streaming
Extended Pix Format

I get similar results for the USB webcams. So after all, maybe what Skype and guvcview fail to do is to only list video devices that support the Video Capture device capability.

Best Answer

The second device provides metadata about the video data from the first device. The new devices were introduced by this patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=088ead25524583e2200aa99111bea2f66a86545a

More information on the V4L metadata interface can be found here:

https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/dev-meta.html

For run of the mill USB Video Class devices, this mostly just provides more accurate timestamp information. For cameras like Intel's RealSense line, provide a wider range of data about how the image was captured.

Presumably this data was split out into a separate device node because it couldn't easily be delivered on the primary device node in a compatible way. It's a bit of a pain though, since (a) applications that don't care about this metadata now need to filter out the extra devices, and (b) applications that do care about the metadata need a way to tie the two devices together.

Related Question