Capture: How to solve "same name" issue with multiple cameras on linux?

#1

Hey there, first post :slight_smile:

I am trying to make available 2 PSEYE cameras on an Ubuntu linux machine. Unfortunately, they show up with the same name and using

  String[] cameras = Capture.list();

  for (int i = 0; i < numCams; ++i) {
    cams[i] = new Capture(this, camWidth, camHeight, cameras[i],  camFps);
    cams[i].start();
  }

does not yield in the right behaviour.
Looking at the sourcecode of the Capture constructor shows me that it only searches for the first occurrence of the name and returns that object.

AFICS a constructor that lets me directly access the object at the index of the list would solve the problem, however, I am not at all experienced in writing/adapting processing libraries.

Any help much appreciated, I am happy to test out possible solutions or even install/configure eclipse if someone could guide me through the necessary steps!

Btw, here is the corresponding issue:

1 Like
#2

Hi! Welcome to the forum :slight_smile:

In case you want to try building it, you could

git clone https://github.com/processing/processing-video.git

to download the source code to the current folder in your shell.

sudo apt install ant

if you don’t have ant yet. Finally

ant build

which should build the library as a jar binary. I don’t remember if you then have to copy the produced library (which might be in a sub folder) to the Processing libraries folder, replacing the existing one and then restart your sketch.

@neilcsmith Does Praxislive work around this issue somehow? Or does it use the Processing Video library as it is?

1 Like
#3

PraxisLIVE has its own video library built directly on top of the GStreamer bindings. It doesn’t have this problem because you can set any GStreamer elements you want as a source, but defaults to device indexes on Linux. It’s also more efficient (than v2 beta) as it passes video buffers directly from GStreamer to the texture upload.

This video support might make it back to Processing. In the meantime @LFSaw why not give Processing a whirl in PraxisLIVE instead?! :smile:

2 Likes
#4

Thanks for all the heads up!

I am not aware of PraxisLIVE yet, but, since I work with PS Eyes, I found a solution to my problem by the Java-port of the PS3EYEDriver project by diwi. This library also works on OSX (where the gstreamer-based implementation is creating a NULLpointer exception for even a single PS3Eye).

However, I could imagine that this seemingly “trivial to implement” feature for the Capture class might be worth looking into.

1 Like
#5

Thanks hamoid, when I am in need to adapt libraries again, I’ll give this a whirl. much appreciated!

#6

Small update on this in case people are trying to use PS3Eye on OSX 10.14: https://github.com/diwi/PS3Eye/issues/4

1 Like
#7

in case someone is interested here is what I used this info for:

Access webcams as simple light sensor arrays, values forwarded as OSC messages: https://github.com/tai-studio/light2osc

1 Like
#8

i am little bit confused about that error on that numbers,

short VENDOR_ID_hex  = 0x1415;
short VENDOR_ID  = 5141;
if ( VENDOR_ID_hex == VENDOR_ID ) println("SAME!");

can you check again?

#9

hmm… this is really weird… I did not really check the hex-codes (they are both the same…) but interestingly, changing something in the class file (the two lines) magically made the camera work…
This is literally the only thing I changed.

Now, changing it back (obviously) results in the code perfectly working… My java (jar/compile/*) knowledge is nearly non-existing, could it be that touching the code overwrites the .jar file (sitting somwhere in the package)?

#10

Will there be a video showing it in action? :slight_smile: