A few weeks ago, the Processing project started the transition to the 2.0 branch with the release of the first alpha package. Today, the second alpha is out (2.0a2), and available from the downloads section in the Google code page of the project, for the Linux, Mac and Windows platforms. The most important changes for this alpha release consist in several improvements in the new video library, and better support for 64 bits within the Processing environment and in exported applications. Follow this link for more detailed release notes, and keep reading below for some additional information about the video library included in Processing 2.0.

GSVideo 0.9 is a significant release of this library because it introduces a new methodology to feed video frames directly into GLTexture objects from the GLGraphics library, which often results in a reduction of CPU usage of around 50%. The latest version of GLGraphics, 0.99, is required for this optimization to work.

A new stable release of the GSVideo library for Processing, 0.8, is available for the Linux, Mac OSX and Windows platforms. This version includes important fixes in memory and thread handling as well as new functionality for media playback and video capture. Follow this link to download the library packages, or keep reading for more details.

Samuel Audet, the author of JavaCV and other cool projects you can check out here, has been working on a port of JNA for Android. I haven’t tested it myself yet, but according to the wiki it has reached a functional state. This port would be very useful to simplify the access to native C libraries on the Android platform when coding with the Java SDK.

Currently, the most convenient way to generate GStreamer binaries for Mac is to use the MacPorts build system. It automatically handles dependencies and patches, and it is kept well up-to-date. However, the main disadvantage of MacPorts is that the resulting GStreamer libraries are meant to be placed inside a specific location in the disk, usually /opt/local, which makes difficult to bundle them into 3rd party applications and also requires separate installs to deploy GStreamer on the end user’s machine. The reason for this problem is that the compilation process in MacPorts hard-codes the absolute paths of the dependencies into the binaries and/or libraries. The methods and scripts described below allow one to modify the GStreamer binaries built with MacPorts so they contain only relative references to dependencies, thus facilitating the integration of GStreamer with 3rd party applications on Mac OSX. These scripts and accompanying documentation are already part of the OSSBuild distribution.