DarkDefender
commented
1 year ago I'll just list out the use cases for the other options than the "by device id" option.
By Bus Path
Here the device is mapped by looking at which bus adress it is connected via. This in practice means that you can map devices to specific USB port or even internal PCI-E slots.
Pros:
- For devices where the manufacture has not filled in the device ID correctly with a unique serial number, you can with this method still differentiate and use them at the same time even if their IDs are exactly the same
- For cases were redundancy is and quick hot swaps are a priority, mapping devices by their physical port allows users to quickly replace equipment without having to set them up again. For example for streaming on big conferences, the production crew could label USB ports with different labels for example "Stage camera" and "Audience camera". Then if the there are hardware problems, the production crew can simply plug in the equipment in the appropriate port and no extra configuration on the OBS side is needed for it to be picked up and mapped to the correct source.
Cons:
- The bus path names are not really human readable. So it is not easy to figure out which physical port the adress is supposed to represent.
- If you plug in an other type of web camera or capture device than what was connected before when hot swapping, there might still need to be manual adjustments as the source video resolution might change and of course specific device type settings will not be carried over.
By "Other" method
This is the current default on Linux and freeBSD. Even if this is not as useful for physical devices as the "By ID" or "By bus path" methods, there is still some cases where this is useful or needed. One of these is when using virtual v4l devices. These will not show up with the ID or Bus path method as they are nor real devices. For example if I create some virtual devices with https://github.com/umlaeute/v4l2loopback, they will not show up in any other mode than this one.
This is because the virtual devices only gets put in /sys/class/video4linux/ and /dev/ but not /dev/v4l/by-id/ and /dev/v4l/by-path/.
Pros:
- Every valid V4L device can be accessed with this method even if they don't have any ID or bus path.
Cons:
- The device file name is random (
/dev/video<number>) as the number is determined by the order which the kernel initialized the devices in. So you can not count of the video source of have the same device file name between hot plugs or computer reboots.
This sparked from a discussion about how the V4L2 plugin matches capture devices (https://github.com/obsproject/obs-studio/pull/9246). Matching devices by the bus / port might be interesting, but we need to consider this approach holistically, both for other platforms, and also for other device types. It's unclear how the UI would look like, if it's a global vs per device type vs per source, etc.
TODO: list use cases