Obs-studio: 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.