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:

[christephan1]

@GeorgesStavracas Any update? If you have concerns on "By Bus Path", why don't you accept the "By Device ID" first? Current obs-studio behavior ("Other" in the proposed PR) is useless on Linux when you have multiple cameras. Either "By Path" or "By ID" will fix obsproject/obs-studio#3003 .

[DarkDefender]

@christephan1 the issue is that you can not exclude "Other" as there are certain cameras or v4l plugins that do not support anything else (like virtual cameras and loopback devices).

So the issue here is not really technical as supporting all three ways is not hard.
The issue is how to present this to the end user in a nice way so that they are not overwhelmed by options that they most likely do not need to change. In this design task we are trying to figure out how to present the options in a nice and understandable way.

At least that is what I got out of the discussions on Discord we had a year ago.
Note that this also crops up a lot during Blender development, so I think it is valid to try to figure out how we want to solve an UI/usability issue before we merge it into OBS proper.

Otherwise it is very easy to get maintainability issues that we have in certain parts of Blender where settings where just added and made it very hard to untangle and make nice after the fact.

The issue with "merge now, fix later" is that the "fix later" usually not happens. Either because the contributor that said they would fix it doesn't have time or even disappears after the new functionality has been merged. So I do understand that the OBS project has halted this until something as been agreed upon.

[DarkDefender]

Seems like there are actually v4l devices that only has "by path" and "other" as well:
obsproject/obs-studio#6493 (comment)

(I'm just trying to keep information like this easily available in here so it is easy to get an overview)

[christephan1]

Got it. All my video capture devices provide stable unique ID so "By-ID" works for me.
And the issue is not so important for end-users now because Ubuntu/Debian already adopted obsproject/obs-studio#6493

And the situation became complicated now because of #6493 is adopted in major distributions. And thus any decisions made here should back-compatible with settings in #6493 if possible. Otherwise, it will break users again.

The issue is reported in 2020, first patch (#3437) provided in same year, then a solid patch (#6493) is provided in 2022. It is easy to say we need to consider other platforms, but forgot the fact this it is a showstopper in live production usage under Linux. A small fix could save lots of lives, but it is 2024 now and we are still no progress here.

[amazingfate]

And the situation became complicated now because of #6493 is adopted in major distributions. And thus any decisions made here should back-compatible with settings in #6493 if possible. Otherwise, it will break users again.

I have created a pull request to debian to delete that patch: https://salsa.debian.org/multimedia-team/obs-studio/-/merge_requests/9