Hello Pedro,

Thanks for your feedback about video playback in Processing. I think both JMCVideo and GSVideo are both good alternatives for replacing/complementing the default video library, and as you said both have their advantages and weaknesses.

I think that JMCVideo, by virtue of being based on JavaFX, can be more easily integrated and deployed with other Java apps and has better applet support, as well as OSX support out of the box.  So I think it is a great option in many scenarios, specially for video playback on OSX and from online applets.

GSVideo, on the other hand, inherits some of the amazing features of GStreamer (high performance, modularity, support of many codecs, video capture and movie creation functionality), but at the same time, some of its drawbacks (mostly its byzantine complexity). GStreamer has a slow development pace, and this has translated into GSVideo, although the project has moved forward steadily since I released the first version. The other problem is that almost everything has to be done by hand: compiling gstreamer from source on Linux, Windows and OSX (!), writing and maintaining the gstreamer-java bindings, etc. So it is a LOT of work. The good thing: the entire platform is open source, community developed and supported. In fact, other developers became involved in the cross-platform compilation of gstreamer as well as in the maintenance of the java bindings. So, further progress with GSVideo/GStreamer will speed-up more people become interested in the project (testing/debugging is of course very important, but submitting patches would also help enormously  )

Anyway, with regards to the more immediate limitations of GSVideo (exporting applications and proper OSX support), I'd say that those are the most relevant issues that need to be solved right now, and my goal is to release a version 0.6 that runs acceptably from the PDE and can generate valid exported apps on the three platforms . I just uploaded to sourceforge a 0.6 "pre" release that should solve the exported application problem on windows, although it still needs a manual step in order to copy the gstreamer dlls to the application folder. See the details here:

http://codeanticode.wordpress.com/2009/07/26/fresh-releases-of-gsvideo-and-glgraphics/

GStreamer support on OSX has never been very good, but it is possible to compile it using different methods (directly from the tarballs, with macports, etc). I'll try to generate new binaries using the build mechanism of OSSBuild:

http://code.google.com/p/ossbuild/

and we will see how things move on from there on the OSX front.

Hi Andres,

Downloaded the gsvideo 0.6-pre, compiled and used the hack you mentioned on your blog and.... IT WORKS! Amazing...

The only thing i encountered and that you said before (maybe you should state it on on your blog too) is that on windows this only works when using the full path/URI of the movie file... otherwise it's fine!

Thanks a million!
Pedro.

Hey Andres,

Well, since i'm retrieving full paths for the video files from a MySQL database, this actually isn't a problem to me. But, since the examples you packed with the library (loop, scratch, etc) work with movies within the 'data' folder, this could be problematic to inexperienced users who want an "out of the box" app export solution. In my experience you can use the dataPath() function but u still need to do a String.replaceAll() to change the '\' into '/' and copy the 'data' folder into the 'application.windows' folder.

Does this make sense?

Cheers,
Pedro.

Processing 1.0.6 now recursively copies subdirectories inside the library folder to the exported application folder. This, in particular, removes the need of manually copying the gstreamer folder.