Order Of Capture devices, And Capture.list()

Processing Libraries
1

I am currently trying to distinguish between 4 Capture devices (cameras) that are all identical, and so have the same readable name as far as OSX is concerned. If you use the system_profiler command, they all have identical identifier strings. This gives rise to two questions pertaining to Capture and its list() method that I’m hoping someone can answer:

  1. According to the source code at master, list() shouldn’t work on Mac OS, but it does. Where is this functionality coming from?

  2. When you have multiple Capture sources with the same name, Mac OS still mounts them under that shared name, yet Capture.list() gives you back devices with ID numbers (Cam, Cam #2, Cam #3, etc.) that are seemingly random. Where are those numbers coming from?

Given that these cameras are always plugged into the same USB ports, they should be able to be assigned consistent names/id numbers, but aren’t. Any insight would be much appreciated.

2

You will need to check the video library’s source code here. Here you can see how the list is built. I am assuming DeviceMonitor comes from import org.freedesktop.gstreamer.device. I did a quick search and I run into this code: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstDeviceMonitor.html

This is as far as I will go. This seems to go deep into dark territory.

When you print the camera list, do they follow a sequence at all? For instance, if you get 160 entries, do entries 0,40,80,120 correspond to a different camera but the same configuration aka. size and fps? With my limited experience working with multiple cameras, descriptors corresponding to the same device would be grouped together.

Kf

3

The source code on master is for the v2-beta release using GStreamer 1.x, not the v1 release using GStreamer 0.10 that you’re probably using. I’m not sure if this functionality is working on macOS in upstream GStreamer yet. GStreamer 0.10 uses a different mechanism and an API deprecated by Apple.

The best way to do what you want is probably using device indices anyway. I’m not sure if the Video library gives you access to that. Depending on exactly what you want to do, the other option is to use PraxisLIVE for this, which has more fully featured / better performing GStreamer integration, and supports device indices by default as well as arbitrary pipelines. You’ll still get full access to Processing.

You’d think that would be the case, but I’ve occasionally seen systems where it’s not. At a guess because of slight variations in how quickly the cameras register. It may be something you can tweak at the OS level.

4

Check out @nelicsmith’s comment - I think they have a better comprehension of what I’m asking.

5

When you say device indices, do you mean the indices in the return value of list(), or something else?

I’ve been looking into OS-level tweaks (specifically, renaming the devices so they don’t get assigned numbers), but they seem a lot more feasible for Windows than on OSX.

Thanks for the pointer to Praxis - probably too heavyweight for what we’re doing, unfortunately.

6

No, although they might line up. It’s a property of the underlying GStreamer capture element. It looks like the v2 beta of the Video library may fall back to this. Maybe try that and ignore list(). You may find avf over qtkit is better for you anyway.

It’s not heavyweight - it’s partly aimed at embedded use! Feel free to DM me if you want some pointers for your particular project. I’m biased, but I wrote it and maintain the Java GStreamer bindings as part of it, so if you want good GStreamer Processing integration … :smile: