Will gstreamer-java migrate to gstreamer 1.0? about gstreamer-java

[GoogleCodeExporter]

Hi, unfortunately I haven't had the chance to contribute to this project in a 
while, although I do still use it in some of the other projects I'm involved in 
(most notably [processing](http://processing.org/)). I started to look at this 
issue a few months ago, and one first basic steps to support gstreamer 1.0 
might be to update all the references to version strings hardcoded in 
gstreamer-java, for instance "glib-2.0.0" instead of "glib-2.0" (in 
GlibAPI.java). However this is just the easy part. The real problem is that the 
gstreamer API underwent several changes in the transition from 0.10 to 1.0, so 
these changes would need to be reflected in gstreamer-java. Not sure how 
difficult this would be, or if there is some sort of semi-automated way to 
compare the current class signatures in gstreamer-java with the updated API in 
gstreamer to get a sense of what should be updated.

It would be good to hear what the other maintainers of the project (@tshalif, 
@lfarkas) think about this issue. One nice thing about gstreamer-1.0 is that 
the the gstreamer project itself is releasing up-to-date binaries of the 1.x 
series for OSX and Windows. So it would be great to be able to use those:

http://gstreamer.freedesktop.org/data/pkg/windows/
http://gstreamer.freedesktop.org/data/pkg/osx/

Best,
Andres

Original comment by [email protected] on 22 Nov 2013 at 9:32

[GoogleCodeExporter]

Hi Andres,

Good to see your interest in this. I too would like to see this happen given 
Praxis LIVE's reliance on this library. There have been a few thread on this on 
the mailing list but they've all petered out. We need to galvanise action and 
get together some sort of roadmap for this, and I'm happy to help with that.

I posted this link a while ago on the mailing list - 
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/random/porting-to-1.0.
txt

I doubt it'll be easy (or even possible?) to write a version of GStreamer-Java 
that is compatible with both 0.10 and 1.0.  Therefore, I agree with Farkas 
Levente's comment on the mailing list last year that this should be used as an 
opportunity to rewrite the bindings, also given the improvements to JNA over 
the time this project has existed.

Two of his suggestions were -
* using gobject-introspect data
* using JNA direct mappings 

I would suggest adding -
* CallbackThreadInitializers (potentially more of a performance improvement 
than direct mapping, and the automatic detachment stuff I helped get in JNA 
3.5+ should make this easier).
* splitting out examples, Swing, SWT, etc. into separate sub-projects / 
downloads.
* possibly adding in a variation of your native library loader (I forked this 
to fix it playing nicely with other JNA libraries, and know a few people now 
using it)

I would also suggest we consider switching to GitHub, or at least some form of 
distributed version control.

Incidentally, there are up-to-date binaries of 0.10 released for all 3 
platforms at gstreamer.com - not a reason not to upgrade, but also showing that 
the 0.10 series isn't dead yet! :-) 

Best wishes,

Neil

Original comment by [email protected] on 23 Nov 2013 at 1:32

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hello Neil,

Thanks so much for your willingness to help. I think that if we coordinate 
efforts we can make this actually happen!

I agree with Levente's suggestions of using gobject-introspect data and JNA 
direct mappings. Maybe a way to get started could be to create a new repository 
(on github or any other distributed control system that everyone is ok with), 
and get the low-level elements wrapped and working from Java as the first goal. 
Once we manage to get this done, the rest of the elements could be added in a 
staged manner (maybe using sub-projects as you mentioned), depending on what is 
most needed, time availability, etc.

Cheers,
Andres

Original comment by [email protected] on 23 Nov 2013 at 4:57

[GoogleCodeExporter]

I think is time to think seriously shifting to GST >=1.0. In my case some major 
issues on decoding as been fixed into 1.0.
Otherwise a good project like this will become very quickly obsolete and I 
think a Gstreamer Java binding is still something useful.

I will be happy to help but I think a coordination is needed and probably even 
a mayor refactoring or branching.
Who created and maintained the project is great and I know that if this major 
issue has not been faced yet for sure there is a big reason behind.

Original comment by [email protected] on 7 Jan 2014 at 1:32

[GoogleCodeExporter]

Hello, besides the 1.0 support, a big priority for me would be to properly 
refactor/rewrite the code so it is easier to maintain and update in the future. 
Time constrains are always an issue for me, so it would probably be a good idea 
to spend some extra time at the beginning (which is now), planning carefully so 
we can come up with a good approach that is reasonably easy to maintain later. 

One obvious step towards that goal would be to have a clean modularization, 
something like:

org.gstreamer
  jna
    all utility classes needed to provide basic interfacing between gstreamer and java (not part of the API)
  glib
    GNative.java
    GOBject.java
    ...  
  core
    Gst.java
    GstBin.java
    GstBuffer.java
    ...

Right now, the current structure of gstreamer-java incorporates a fair amount 
of modularization, but at the same time there are several classes that is not 
entirely clear (at least to me) where they belong to (they are simply located 
inside the org.gstreamer package).

The core reference manual for gstreamer 1.0 
(https://developer.gnome.org/gstreamer/stable/) could be a good guide to move 
things around and remove deprecated classes.

However, there are several ways of going forward with this. One would be to 
start with the current code, branch it out and modify it until it builds. Neil 
also suggested me that we could use a tool like JNAerator and build from 
scratch on top of an automated mapping. I don't know if JNAerator could handle 
the entirety of gstreamer, by if we restrict ourselves only to the core classes 
then it is doable this way. The advantage of the automated mapping is that it 
will make easier to update the bindings when the underlying API changes. 

Original comment by [email protected] on 7 Jan 2014 at 5:12

[GoogleCodeExporter]

imho the only way is an automated class generation. but for this we need some 
basic class for glib and jna mapping. unfortunately afaik there is not any good 
java wrapper and generator even for glib (the current gnome-java doesn't seems 
to be a good candidate. so we've to write:
 1. a good java class generator from gobject-introspect data
 2. we need generated class for glib
 3. we need generated class for gstreamer
 4. and probably a lots of util/helper class
on the other hand 1. would have to generate a good java-style classes and not 
C-like classes which would be more easy from the c code...

Original comment by [email protected] on 8 Jan 2014 at 12:02

[GoogleCodeExporter]

and at the same time it'd be good java7 and jna > 3.5 support too.

Original comment by [email protected] on 8 Jan 2014 at 12:04

[GoogleCodeExporter]

> imho the only way is an automated class generation. but for this we need some 
basic class for glib and jna mapping ... 
> on the other hand 1.would have to generate a good java-style classes and not 
C-like classes which would be more easy from the c code...

Why?  To me that's step 2.  We should look at an automated mapping of the 
GStreamer headers to create a low-level library.  There would be minimal extra 
code in that library (perhaps, as suggested to Andres off-list a library loader 
to work with non-system installed GStreamer, and some tests).  That library 
would be coded in C-style - there would be *no* good Java-style classes in 
there.

Step 2 is a second library that depends on the first, and wraps it in Java 
niceties - ie. Java-style classes. This could be (partially) auto-generated 
from gobject-introspect data - doesn't gnome-java have some code we could fork 
to do that?  With some work this library could even be made API compatible with 
the existing one, except all JNA calls would be re-routed through the first.  
Functionality can be added iteratively, with people having to drop down to the 
low-level C-style when necessary.

This is similar to the approach I took in mapping JACK, though admittedly we're 
talking a much bigger level of complexity here!  Similar also to the 
nativelibs4java project.

> and at the same time it'd be good java7 and jna > 3.5 support too.

Don't we already have that in SVN head?!

JNAerator would support all this, and potentially direct mapping.  

Original comment by [email protected] on 8 Jan 2014 at 12:53

[GoogleCodeExporter]

I'm trying playing with JNAerator and yes it may solve lots of steps 
identified, but I'm already a little bit confused because of the amount of 
classes in packages.

And yes it seems that java7 and jna > 3.5 support it's in the svn HEAD

Original comment by [email protected] on 8 Jan 2014 at 1:12

[GoogleCodeExporter]

> I'm trying playing with JNAerator and yes it may solve lots of steps 
identified,
> but I'm already a little bit confused because of the amount of classes in 
packages.

That can be controlled by the various package switches on the command line or 
in the config file.  Ideally we should be looking to create a .jnaerator build 
file with all the relevant header includes and configuration set up.

> And yes it seems that java7 and jna > 3.5 support it's in the svn HEAD

Yes, and having done the boring work to get it in there, it's a pity there's 
not been a new download release agreed - one week to do that before Google Code 
stops supporting downloads!

A (final) 0.10 release would be good before concentrating effort on 1.0.

Original comment by [email protected] on 8 Jan 2014 at 1:23

[GoogleCodeExporter]

As per previous comment ...

Original comment by [email protected] on 8 Jan 2014 at 1:28

• Now blocked on: #138

[GoogleCodeExporter]

Well, since it's may big effort and I am willing to cooperate but probably I am 
not as expert as Neil is in JNA and Gstreamer Java, I would like to follow his 
previous and other of his suggestions before going on.
I think a good and agreed roadmap wolud be a perfect starting point, and I 
think project owners are the best for this, even if I know that all of you and 
me are always in a rush.
It's just for sake of avoiding misunderstanding.

Original comment by [email protected] on 8 Jan 2014 at 2:48

[GoogleCodeExporter]

It would be great if this happened, I suspect if a few guys kick this off, then 
people will help out once the conversation starts.

Shame to let such a good mapping API fall to the way side.

Original comment by [email protected] on 10 Jan 2014 at 10:39

[GoogleCodeExporter]

I think gstreamer-java really needs to move to support Gstreamer 1.2. 

We've been using it for a few years now but we are stuck on GStreamer 0.10 
because of gstreamer-java but really need to move to the latest versions.

As mentioned by [email protected] community should help out.  Im happy to to 
help out where I can.

Original comment by [email protected] on 15 Jan 2014 at 9:19

[GoogleCodeExporter]

So the consensus seems to write the next gstreamer-java from scratch using 
automated class generation, right? Besides JNAerator, is there any other option?

Original comment by [email protected] on 16 Jan 2014 at 4:46

[GoogleCodeExporter]

Assuming we stick with JNA, I don't know of an alternative to JNAerator. There 
are obviously various options to create pure JNI, such as Gluegen, HawtJNI, 
LWJGL's generators, etc.

Pure JNI would obviously have a few pros and many cons!

PS. Closed issue 138 as per Jan 8th's new downloads.

Original comment by [email protected] on 16 Jan 2014 at 5:02

[GoogleCodeExporter]

As I said before... Neil is (one of) the project owner. He (and owners in 
general) should be able to decide the roadmap, including big (or little) 
technology changes.

On the other side people should be reactive and proactive to contribute and 
code... It's too easy asking, complaining and waiting&seeing what happens. 
That's not how Open Source works, even if many people do think this way.

So what I can say is that I'm trying to understand better how to deal with 
JNAerator and GST C APIs even if I'm not expert on both of them.
I think GST is a great software for video processing and there is lack of this 
kind of binding on Java side.
Trying to update and maintain it is worthy according to me. And thinking about 
collaborating instead of just asking for, is even smarter.

Cheers
Sergio

Original comment by [email protected] on 17 Jan 2014 at 3:55

[GoogleCodeExporter]

> As I said before... Neil is (one of) the project owner. He (and owners in 
general) should be able to decide the roadmap, including big (or little) 
technology changes.

For avoidance of doubt, I'm not one of the project owners. I have limited 
project privileges for committing so that I could fix up support for JNA 3.5+

I have no more say over the roadmap than you do!

> On the other side people should be reactive and proactive to contribute and 
code... It's too easy asking, complaining and waiting&seeing what happens. 
That's not how Open Source works, even if many people do think this way.

Exactly! Why do you think I got commit privileges?  Because I wanted (needed) 
something to be fixed.  This is a much bigger job, and will need willing 
participants.

I would suggest that we move this discussion on the mailing list if no-one has 
objections?  Seems a bit abstract right now for the issue queue, though should 
report decisions back here.  Another reason would be that we might not want to 
do this development within the Google Code project - I'd like to see a move to 
a distributed version control, and probably not on Google Code which seems to 
be slowly dying (no more downloads!)

Original comment by [email protected] on 17 Jan 2014 at 7:32

[GoogleCodeExporter]

I'd rather have the discussion going on an issue tracker. In order to get 
things moving, I created a github repo 
(https://github.com/codeanticode/gstreamer-java-2) to start testing some ideas 
out. I set up a simple build script that runs jnaerator on gobject.h and gst.h, 
which actually does output some java files, but also some errors. I opened an 
issue about those specific errors 
(https://github.com/codeanticode/gstreamer-java-2/issues/1), that seem to have 
affected other people as well 
(https://github.com/ochafik/nativelibs4java/issues/132). Who is interested in 
becoming a contributor for this new repo? You can also fork it and do your own 
thing if you feel is better.

Original comment by [email protected] on 20 Jan 2014 at 3:47

[GoogleCodeExporter]

OK, fine with me, and great job for kicking off the activity!  Submitted a 
revised .jnaerator file to that issue, which at least starts to output usable 
stuff.  Guess we can continue specific discussions over there?  Any way to get 
GitHub issues to CC the mailing list though?

One other general thing.  There was talk on the mailing list a while ago about 
syncing version numbers IIRC.  GStreamer-Java-2 feels wrong, but I guess 
calling it 1.2 is going to cause a lot of confusion?!

Original comment by [email protected] on 20 Jan 2014 at 5:33