Open GoogleCodeExporter opened 8 years ago
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 andres.c...@gmail.com
on 22 Nov 2013 at 9:32
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 neilcsmi...@googlemail.com
on 23 Nov 2013 at 1:32
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 andres.c...@gmail.com
on 23 Nov 2013 at 4:57
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 sw360...@gmail.com
on 7 Jan 2014 at 1:32
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 andres.c...@gmail.com
on 7 Jan 2014 at 5:12
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 lfar...@lfarkas.org
on 8 Jan 2014 at 12:02
and at the same time it'd be good java7 and jna > 3.5 support too.
Original comment by lfar...@lfarkas.org
on 8 Jan 2014 at 12:04
> 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 neilcsmi...@googlemail.com
on 8 Jan 2014 at 12:53
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 sw360...@gmail.com
on 8 Jan 2014 at 1:12
> 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 neilcsmi...@googlemail.com
on 8 Jan 2014 at 1:23
As per previous comment ...
Original comment by neilcsmi...@googlemail.com
on 8 Jan 2014 at 1:28
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 sw360...@gmail.com
on 8 Jan 2014 at 2:48
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 ch...@crazyfool.org
on 10 Jan 2014 at 10:39
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 chris@carzyfool.org community should help out. Im happy to to
help out where I can.
Original comment by harrison...@gmail.com
on 15 Jan 2014 at 9:19
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 andres.c...@gmail.com
on 16 Jan 2014 at 4:46
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 neilcsmi...@googlemail.com
on 16 Jan 2014 at 5:02
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 sw360...@gmail.com
on 17 Jan 2014 at 3:55
> 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 neilcsmi...@googlemail.com
on 17 Jan 2014 at 7:32
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 andres.c...@gmail.com
on 20 Jan 2014 at 3:47
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 neilcsmi...@googlemail.com
on 20 Jan 2014 at 5:33
Original issue reported on code.google.com by
angellui...@gmail.com
on 19 Nov 2013 at 10:07