macOS - ofVideoGrabber device order is inconsistent.

[ofTheo]

Experiencing this on macOS Sonoma 14.2.1 with an external webcam and built in FaceTime camera.
Every app launch I get the order inverted.

[notice ] Device: 0: FaceTime HD Camera
[notice ] Device: 1: Razer Kiyo X

[notice ] Device: 0: Razer Kiyo X
[notice ] Device: 1: FaceTime HD Camera

Curious if this is an issue for others or a bug unique to my setup.

[artificiel]

if I setDeviceID(0), the cam at index 0 is always 1st (builtin cam).

if I setDeviceID(1), the cam order gets inverted as you report. perhaps "blessing" a cam with setDeviceID() somehow pushes it up in an internal hierarchy, so it then becomes 0?

[ofTheo]

Thanks for confirming @artificiel - I'll try and root out the issue.

[artificiel]

not sure if it becomes more of a feature request but anyway: thinking about it, device order should probably not be considered deterministic from the OS's perspective (perhaps reboot lottery, driver interaction, or unplug-replug) so getDeviceIDByName(std::string device_name) should probably exist... or maybe even getDeviceIDBySubstring(std::string substring_to_match) to make things easier.

auto id = getDeviceIDBySubstring("FaceTime");
if (id >=0) {
  setDeviceID(id);
} else {
  ofLogNotice("ofVideoGrabber") << "desired device not found; trying first available");
  setDeviceID(0);
}

by SerialID could also be useful for multicam of the same model. of course that can be built from deviceList() but for simple, default behaviour, this is a good gain on the current interface:

setDeviceID(getDeviceIDBySubstring("FaceTime"));

or perhaps even all-in-ones setDeviceIDByName() / BySerial(), since (unless i'm mistaken) the device IDs are unreliable maybe should not leak out and be kept as an implementation detail (e.g. they can't be used to save a config or something).

setDeviceID* could also return bool so then possible:

if (!setDeviceIDBySubstring("FaceTime")) {
  ofLogWarning("ofVideoGrabber") << "desired device not found; trying first available");
  if (!setDeviceID(0)) {
    ofLogWarning("ofVideoGrabber") << "no available devices");
  }
}

[artificiel]

re-reading this and actually the correct non-leaky interface should not call setDeviceID(int) at all, and probably ID could disappear, so the last code block should be

if (!setDeviceBySubstring("FaceTime")) {
  ofLogWarning("ofVideoGrabber") << "desired device not found; trying first available");
  if (!setDeviceDefault()) { // <-- does not communicate "by id"
    ofLogWarning("ofVideoGrabber") << "no available devices");
  }
}

[artificiel]

also! (just brainstorming but this ties into <optional> ideas), instead of returning bool, the methods could return an optional<VideoDevice>, which provides a richer context for the end-user:

if (const auto openeddevice = setDeviceBySubstring("FaceTime")) {
  // the grabber is opened, and the user can make use of openeddevice->metadata
} else {
  ofLogWarning("ofVideoGrabber") << "desired device not found; trying first available");
  if (const auto defaultdevice = setDeviceDefault()) {
    // the grabber is opened, and the user can make use of defaultdevice->metadata
  } else {
    ofLogWarning("ofVideoGrabber") << "no available devices");
  }
}

this kind of pattern would be great to see in OF's future development as it makes it possible for the developer to handle disappointments (the hierarchy of unexpectedness that are not necessarily "errors") in a structured manner (instead of relying on "passive" log messages). also with this conditional pattern it is safer, as the scope of opendeddevice and default device is automatically valid, so you can't accidentally use it if nullopt (one of the key advantage over shared_ptr nullptr pattern: you are forced to unwrap the optional).

[edit]: to be clear you can also simply ignore the optional return, so for basic example usage, this works just like setDeviceID(0):

grabber.setDeviceDefault();
// yolo

it's up to you to decide how involved you want to get with the status processing.

[ofTheo]

@artificiel def open to these options going forward, but put in a fix for this issue in #8392
imperfect, but it stays consistent now and tested with all possible combinations.