Webcam ordering is not persistent in Linux

[JonnyHaystack]

It seems that in Linux, the numbering of the /dev/video (V4L) devices is used to determine which source should use which webcam. This should not be the case, as this numbering is not persistent and often changes depending on whether a device is plugged in before or after boot time.

Platform

Operating system and version: Arch Linux
OBS Studio version: 25.0.8 (official package from Arch repos)

Expected Behavior

If webcams are connected in a different order during different boots, OBS should still have the correct webcams selected in the scene sources.

Current Behavior

I have an internal webcam (in a laptop) and an external USB webcam, to provide two different camera angles. First, I booted with the external webcam disconnected, then plugged it in later. Then I set up some scenes in OBS involving both webcams. Then I rebooted, with the USB webcam still connected, and reopened OBS. My scenes that I had created were broken, because it had swapped the two webcams.

I then rebooted with the webcam disconnected, and then reconnected it and opened OBS. My scenes were now back to normal. This leads me to conclude that OBS is using the /dev/video* numbering of the webcams (or something like that) to determine which which source is linked to which webcam. This should not be the case, as this numbering changes often and there are already things like /dev/v4l/by-id/ for persistent naming of webcams e.g.:

❯ ll /dev/v4l/by-id/
total 0
drwxr-xr-x 2 root root 120 May 29 00:21 ./
drwxr-xr-x 4 root root  80 May 29 00:21 ../
lrwxrwxrwx 1 root root  12 May 29 00:21 usb-046d_0825_014C8D90-video-index0 -> ../../video0
lrwxrwxrwx 1 root root  12 May 29 00:21 usb-046d_0825_014C8D90-video-index1 -> ../../video1
lrwxrwxrwx 1 root root  12 May 29 00:21 usb-SunplusIT_Inc_Integrated_Camera-video-index0 -> ../../video2
lrwxrwxrwx 1 root root  12 May 29 00:21 usb-SunplusIT_Inc_Integrated_Camera-video-index1 -> ../../video3

This is the output of sudo v4l2-ctl --list devices if the USB webcam is disconnected during boot:

Integrated Camera: Integrated C (usb-0000:00:14.0-6):
	/dev/video0
	/dev/video1
        /dev/media0

UVC Camera (046d:0825) (usb-0000:00:14.0-2):
	/dev/video2
	/dev/video3
        /dev/media1

So the internal camera is at /dev/video0 and /dev/video1.

If the USB webcam is plugged in during boot, then the ordering is like so:

UVC Camera (046d:0825) (usb-0000:00:14.0-2):
	/dev/video0
	/dev/video1
        /dev/media0

Integrated Camera: Integrated C (usb-0000:00:14.0-6):
	/dev/video2
	/dev/video3
        /dev/media1

Steps to Reproduce

1. Have two webcams
2. Set up some OBS scenes using both webcams
3. Reboot with devices plugged in/unplugged in a way that causes the /dev/video* ordering to change
4. Open OBS and observe that the webcams have been swapped, thus ruining the scenes

[kkartaltepe]

Similar to #2936

Whenever someone fixes one we can probably use the same strategy for this. It would be nice to get device names in both cases for these paths since I think the id is maybe even worse than 0,1,2 readability wise. (easier here than dri devices I think).

Thanks for including the v4l2-ctl incantation to list devices.

[chepecarlos]

similar happens to me in linux mint 19.3

[darrelclute]

Found this looking for a solution to this as well. Manually updated the Scenes JSON configuration updating the device_id from the /dev/video# to /dev/v4l/by-id/unique-name path and started OBS. OBS properly utilized the correct camera by utilizing this symlink and did not change the device_id when updating properties inside of OBS after defining this, and worked after a reboot as well. This workaround does at least show that use of either the /dev/v4l/by-id or /dev/v4l/by-path symlinks will allow for a more persistent addressing of the cameras.

[tnt]

Would be nice if obs could use symlinks like the ones I am creating for my webcams with respective udev-rules like this:

SUBSYSTEM=="video4linux", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="085e", \
    ATTR{index}=="0", GROUP="video", SYMLINK+="video-logitech-brio"

This creates a symlink /dev/video-logitech-brio which could be used to prevent all the hassle.

By the way: on my system obs unfortunately shows 2 cameras for my Logitec cam one of which is completely disfunctional. This occurs because webcams appear in /dev/ as multiple devices, e.g. 4 for my Logitec of which only one is the actually usable device. The above mentioned udev method make sure that always the right one is used (the ATTR{index}=="0" is crucial for this).

[kkartaltepe]

You can edit your configuration manually to set the path to your video device to whatever you want as a workaround you can use right now. Generally there is just no good way to enumerate v4l2 devices on linux as far as im aware. The one that includes all exotic devices is what we already do.

[johnebgood]

Just switched my streaming computer to Linux from Windows, I have more than 6 UVC webcams that I use on stream and it has become a hassle as they all have different encoders and settings and when they switch randomly on the next boot all hell breaks loose. All of the cameras with the corresponding USB information are unique, even identical devices from the same vendor as shown in the screenshot. Could we use those same strings as used in the combo box to identify the cameras and assign them correctly? The configurations would break if a device switches ports but I think that also happens in Windows.

I'm willing to take up this challenge, going to start doing some research. In the interim I'll try the device path route.

[jarrard]

Yeah been dealing with this.
Also my two camera inputs reset after 4-5minutes for like 50ms... Turning off Autosuspend seemed to do nothing.
UPDATE: Well the resetting camera died, so perhaps that was my issue....

[johnebgood]

After 2 weeks of getting my udev rules figured out, and discovering the ATTRS{index}=="0" quirk, I can now manually edit my OBS scene JSON and change out my 6 cameras to use the udev symlinks. Only took about 20-30 hours of fiddling. I would like to reiterate what @tnt mentioned about the ATTRS{index}=="0", without this it will flip-flop between /dev/video0 & /dev/video1 for example. I wish I would have recognized this context when I first found this thread 2 weeks ago.

I have multiple cameras and devices from the same vendors, in the case of the Elgato CamLink4k's they have serial numbers which make it easier but for the OBSBOT Tiny's they don't, so you need to use the USB port as a filter. I found the easiest unique filter to be the devpath like this:
ATTRS{devpath}=="7.3"

This command will show the differences between two devices:
security_live@StreamBox01:~/$ diff <(udevadm info -a /dev/video2) <(udevadm info -a /dev/video4)

<   looking at device '/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7.3/1-7.3:1.0/video4linux/video2':
<     KERNEL=="video2"
---
>   looking at device '/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.1/1-8.1:1.0/video4linux/video4':
>     KERNEL=="video4"
<..snip..>
66,67c66,67
<     ATTRS{devpath}=="7.3"
---
>     ATTRS{devpath}=="8.1"

Example udev rules:

# Blackmagic ATEM Mini
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="1edb", ATTRS{idProduct}=="be49", ATTRS{serial}=="8cb25256e91f42df815239a7e8294ca8", ATTR{index}=="0", SYMLINK+="video_atem"

# OBSBOT Tiny 4k #1
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="3564", ATTRS{idProduct}=="fef4", ATTR{index}=="0", SYMLINK+="video_obsbot_tiny4k1"

# OBSBOT Tiny's
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="3564", ATTRS{idProduct}=="fef0", ATTRS{devpath}=="7.3", ATTR{index}=="0", SYMLINK+="video_obsbot_tiny1"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="3564", ATTRS{idProduct}=="fef0", ATTRS{devpath}=="8.1", ATTR{index}=="0", SYMLINK+="video_obsbot_tiny2"

# Camlink 4K's
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0fd9", ATTRS{idProduct}=="0066", ATTRS{serial}=="0003BCABFF000", ATTR{index}=="0", SYMLINK+="video_camlink4k1"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0fd9", ATTRS{idProduct}=="0066", ATTRS{serial}=="0005763C43000", ATTR{index}=="0", SYMLINK+="video_camlink4k2"

[Fenrirthviti]

Closing this in favor of obsproject/design#21 since this is effectively a feature request.