Test camera support in v2.0 of the video library

[codeanticode]

Camera capture is an important use of the video library, so to it need to work as smoothly as possible across Windows, Mac, and Linux. The numerous issues related to capture are evidence of this:

#106
#105
#102
#93
#89
#77
#76
#72
#68
#65

Just to mention the most recent ones.

Due to the great variety of capture devices, and the differences in hardware support between Mac, Linux and Windows, it will not feasible to support them all. A useful idea to consider is the GSPipeline class form the old GSVideo library, that allowed to enter a custom gstreamer pipeline that the library then would use as the video source in Processing. Without reintroducing a pipeline class into the video library, a possibility could be to allow the existing Capture class to take a pipeline string as input, in addition to a regular device name, so it would then use that as the video source. The advantage of this approach is that it will enable users with more specific capture hardware to try to set its parameters using a custom gstreamer pipeline, without the need of new API in the library.

[neilcsmith-net]

@codeanticode how about a mix of approaches? PraxisLIVE covers this with the code here - https://github.com/praxis-live/praxis/blob/master/praxis.video.gstreamer/src/org/praxislive/video/gstreamer/configuration/GStreamerSettings.java#L39

When configuring a capture device the user can pass in an empty string which results in use of autovideosrc, an int as a String which will be looked up using the above default pipelines (but those are overridable via Settings, basically system properties) or a partial pipeline. This means that someone could write a sketch that uses multiple cameras and it'll work fairly well on any machine, and if someone wants to change what camera 1 is they can do, without any recompilation. Using the device names is really problematic!

[codeanticode]

A simple approach to support specialized capture hardware through custom pipelines, without adding new classes or API to the library:

import processing.video.*;

Capture cam;

void setup() {
  size(640, 480);
  cam = new Capture(this, 640, 480, "pipeline:videotestsrc");
  cam.start();  
}

void draw() {
  if (cam.available() == true) {
    cam.read();
  }
  image(cam, 0, 0, width, height);
}

Available for testing in beta4, but not finalized yet.

@neilcsmith-net the old bindings had Pipeline.launch() that parsed the entire pipeline description, that seems to be gone in gst1. Is there any equivalent or one has to parse the string manually, create the elements one by one, etc? That's what I'm doing right now, but I'd need to handle element properties, caps, etc, right?

[neilcsmith-net]

@codeanticode moved to Gst class - parseLaunch, etc. to better match upstream naming and semantics (eg. if only one element it's not wrapped in a pipeline as per upstream - this broke in the old library - now you'll have to check and cast).

[codeanticode]

Thanks, I will update the code to use parseLaunch.

[neilcsmith-net]

@codeanticode (for info) was just about it open an issue related to this based on current forum thread at https://discourse.processing.org/t/processing-video-library-gives-v4l2src-error/18441 but someone reminded me this existed.

[codeanticode]

The pipeline parse functionality has been implemented, which should help to support specialized capture hardware.