Created attachment 135120 [details]
Binding sources

Created attachment 135123 [details]
Script for compiling the bindings

Also i would like to say that anyone could help with this and the hope to oficially integrate this as a part of GStreamer.

Is this different from http://code.google.com/p/gstreamer-java/ ? Those bindings are AFAIK the "official" Java bindings

The bindings from http://code.google.com/p/gstreamer-java/ are JNA based, while the ones i have released are JNI based.

The problem with JNA is its low performance. So the solution is to make a new ones, probably based in JNI.

Mines are not perfect but work and have a high performance compared with the JNA version.

Also wtay have suggested the possibility to collaborate with http://java-gnome.sourceforge.net/ bindings and code the GStreamer part. java-gnome bindings have gobject, glib part, something necessary in GStreamer bindings. So the basic part is done in that project.

Did you contact the developers of the other bindings? IMHO the best would be to have a single, official Java binding and the code.google.com one's are this from my understanding. According to your explanation it would make sense for them to switch from a JNA to a JNI implementation though... what's their opinion on this?

Getting gstreamer bindings into java-gnome OTOH is a good idea but IMHO this should go in line with the code.google.com bindings, which should then disappear. There's nothing worse than multiple, incompatible bindings that all have their users...

Hi guys, I'm one of the current developers/maintainers of gstreamer-java. I replied to Miguel's announcement on the gstreamer-java forum, so for now I'll just repeat what I wrote over there, and see how these threads develop over time. In what follows I'll be presenting my own
position, which might not necessarily coincide with the opinions of
the other two developers of gstreamer-java, Farkas Levente's
and Tal Shalif. Just as a side note, the original creator of
gstreamer-java, Wayne Meissner, is not longer involved in the project. 

In general terms, I think it is a great thing to have multiple open
source solutions for a given problem, so 1) then users can choose the
solution that fits better their needs and 2) solutions with
complementary strengths can be combined to create better ones.

But I also agree that in the particular context of library bindings, having
alternative bindings is not ideal, unless each binding caters to a
very specific usage or application that cannot be covered by the
others. I doubt that this would be the case for JNA vs JNI-based
gstreamer-java bindings, plus having two separate groups of developers
working on two different sets of bindings will probably be somewhat
wasteful in terms of developer resources. But we certainly need to
start a discussion in this regard.

I think that your project comes out in quite the right time: we are
close to release version 1.2 of gstreamer-java (which is basically a
maintenance release of 1.0 plus a few additions). I'd say that at this
point gstreamer-java is quite stable and it does its job well, as Miguel
pointed out in the gstreamer-java forum. This is why a couple of weeks ago I started thinking, "well, so what would be a good long term plan for the project and what major changes would be needed for a future 2.0 release". Given the
existence of Miguel's bindings, a port to JNI might be the major change
prompting for a 2.0 release. Until this major release is ready, JNA-
based gstreamer-java 1.x will continue to serve as the "unofficial"
official gstreamer bindings for java.

This is a big change that would affect the gstreamer-java project
in a big way, so in order to reach the best decision we need to compare the alternatives carefully. I haven't tried the JNI
bindings yet, but my impression is that at this point their main
advantage is improved performance, while gstreamer-java is
more complete in terms of features. To start off, I'd like to see more
quantitative measurements of the performance gains of the JNI
bindings, under different circumstances. I imagine that using JNI
might speed up elementary operations quite substantially, but how does
this translate into more complex operations that could have their
bottlenecks somewhere else and not in the glue code? Different
scenarios would include: running a typical movie playback pipeline,
video capture under Linux/Windows/OSX, rtsp streaming, etc.

And then, which are the gstreamer features Miguel has implemented already
in his bindings, and which are still missing? Once the JNI bindings
are completed, would they be capable of offering the same
functionality of gstreamer-java, or there are things that cannot be
achieved with JNI? And we (the gstreamer-java people) should answer the reverse question as well.

Ok, these are my thoughts at the time. I'm looking forward to hear
from all of you guys. 

I can't say much more to this as I'm not familar with Java bindings in general but one thing that should be noted is that the JNI bindings have a C-like API: Gst.Pipeline = Gst.Pipeline.gst_pipeline_new() or similar.

So there's a lot of more work to do here I'd say. But merging this into the gstreamer-java bindings if it's really faster for a 2.0 release sounds great to me.

I think that the best solution is what suggested wtay, using java-gnome as base because it now integrates GLib and add GStreamer binding to this. About merging my binding i think that callbacks cannot be so easily merged, also there is the problem of varargs functions like gst_caps_new_simple that have no binding. Other simple functions are not in the binding because i don't need them.

Maybe java-gnome solution takes more time, but because now gstreamer-java (JNA based) is stable there is no need to hurry up, and in the end resources will not be wasted coding something that will go to trash.

Just two more points to consider in this discussion:

1) a potential port of gstreamer-java to JNI should preserve the Java API it has right now.

2) JNA 3.1.0 (released a few days ago) includes a new direct mapping mode that seems to improve performance substantially (under certain circumstances):

https://jna.dev.java.net/#direct

I don't know yet the effect of this mode in gstreamer-java. I have included JNA 3.1.0 in the latest development version of gstreamer-java (available on the google-code svn repo) but haven't had time to run performance tests.

my little comment is that in most case the speed is not concern in case of gstreamer-java and clear more java friendly interface.
in case of java we just would like to use the native gstreamer functionality.
we'd like to start pipeline, add element, connect element etc. in most cases the speed ss not a problem and we'd not like to do cpu intensive processing in java in all other case jna based interface is good enough.
we do all cpu intensive processing in native C element and all other control done in java and it's working like a charm even in case of video.
that's just my 2c.

Is there anything still to be done here? Any progress, something? Or can this bug be closed? :)

I will not do anymore of this bindings at the moment .

In my opinion if in the future I want to use JNI with GStreamer I will try to add the bindings in project java-gnome.

we use JNA in gstreamer-java and it's works perfectly for us so we do not even plan to use JNI. if anybody else make another bingings that's another questions...

I agree, a set of JNI bindings for gstreamer would be a separate project from gstreamer-java, which is JNA-based.

Ok, so let's close this bug for now. Doesn't seem very useful to have it open

Having JNI based java bindings would be awesome for the gstreamer on android project. There is now a working NDK installation described at
http://gstreamer.freedesktop.org/wiki/GstreamerAndroid_InstallInstructions
(you don't need to root your phone). For developers it is mostly useful, if you have jni bindings.

Is there any new discussion on the gstreamer-java side?

I'm not aware of anyone currently working on JNI bindings for gstreamer.

On the JNA front, there has been some activity going on lately:

http://code.google.com/p/javacv/wiki/JNAOnAndroid
https://github.com/twall/jna/issues/23

The person who originally wrote the Android port of JNA, Samuel Audet, is now using his own c-java bindings:

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

which apparently allow him to use OpenCV on Android:

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