Thanks for your interest. Here you have the items in my TODO list for the core video library:
* Unify the various scripts I currently use (
here and
here) to build the GStreamer binaries for Windows and MacOSX. Ideally, I'd like to have some sort of (well documented) cross-compilation mechanism able to generate both sets of binaries from the same machine, and easy enough to use so we can regenerate the binaries quickly after new source packages of GStreamer are released.
* Clean-up the GStreamer plugins that are bundled with the video library from those that only support esoteric codecs and functionality that are not needed in Processing, and thus making the library smaller.
* In-depth testing of video capture on the three platforms (win/mac/lin), in order to identify and solve device detection issues, compatibility problems, etc.
* Implement missing calls and enhancing current the API (
crop,
start,
poster).
* Work out the issues with the jump() method, allowing (if possible) proper jump-to-frame functionality and solving issues like jump(time) working better when time is a multiple of 1/framerate. There is
a thread in this forum with some useful information about implementing jump-to-frame with GStreamer.
* Better error handling (showing descriptive warnings when there are no cameras available, or the selected framerate is not supported).
About OpenCV integration: given the fact that the current video library only deals with movie playback and video capture, I don't think we need to add OpenCV functionality to it. From my point of view, a separate CV library would be a better idea. You can use core video to hand-off the video frames to the OpenCV library, but no special API should be needed in the video library itself, for example take a look at how this is done with the old GSVideo and OpenCV libraries in
this example included with GSVideo. I think
JavaCV/
javacvPro could be good starting points for an eventual core CV library.
