Alternative ways to match devices

[GeorgesStavracas]

This sparked from a discussion about how the V4L2 plugin matches capture devices (obsproject/obs-studio#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

[DarkDefender]

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.

[DarkDefender]

Current issue with the UI

I think that the current pain point is that it is hard for a new user to realize what options are relevant as the current UI presents quite a few options at the same time with quite minimal amount of visual grouping:

I will suggest some potential solutions by looking at the UI from Blender. Note though that this is more as an example as we of course shouldn't copy this outright as we should come up with a solution that feels natural and is appropriate for the general OBS UI design language.

Radio Buttons

To break up the monotony of the drop down menu list. We could consider using radio buttons for the "Device Detection" setting. This would be at the top and also by it's different look perhaps signify that this is a more important option than then others:

Using more groups and make them collapse able

In Blender there are places where there are an overwhelming amount of options. There they usually use a lot grouping of settings that can be nested and collapse able:

Quick mock up

Collapsed view. This is what the user will see when the add create a brand new V4L source

Expanded view. If the user wants to get configure the more advanced options, they can expand the two extra sections: