hm even the windows version has no gstreamer stuff here
ah my bad, sorta, the processing 2 pre releases have it; and lol the windows version also includes mac
EDIT: well, it seems ALL version have mac and windows but none linux, depending on system install I guess
anyway mac should be easy
“processing-2.0a8\modes\java\libraries\video\library”
I just spent 10 minutes trying to find that out for you! 
For anyone else, just download any of the pre-releases and the natives should be in /modes/java/libraries/video/library/ or do as I did and do an svn checkout on the libraries section of the repo.
So that you can export a Processing app that works on all systems.
Ah yes I forgot
So these changes should make macosx possible: https://dl.dropbox.com/u/52666052/GStreamerLibrary.java
Get the macosx gst libs:
https://docs.google.com/file/d/0B9Nkz0-YWCIDcHRHMVQxTVhKMEU/edit
Just File -> Download to download the whole zip (using google drive for the first time :D)
and put the 2 folders where the windows libs are of course
Not quite! You’ll want to change
if (!Platform.isWindows()) {
Gst.init("GStreamer core video", new String[]{});
return;
}
to
if (!Platform.isWindows() && !Platform.isMac()) {
Gst.init("GStreamer core video", new String[]{});
return;
}
or it’ll never get to the code you’ve added. That’s there to ensure the system GStreamer is inited on Linux - can be removed if we bundle Linux libs too.
No need to add the isWindows(), etc. methods in to this file - system checking is already available through the static methods in Platform.
When someone did something similar with my source code several years ago, some people replied here that the code snippet was trivial and that I should not complain, etc…
ah yes. with that I’m positive mac will work without problems.
now about linux… how do we get those binaries… ?
I never claimed it was trivial, and the source has been updated with the relevant notices and I’ve already apologised for the error. It was an honest mistake not to include Riven’s name - the LWJGL setup code was deliberately copied for point of comparison (Riven had originally suggested writing a comparison GStreamer backend for YUNPM, but that was not really practical given the differences between the stream-based and callback-based libs underneath).
Incidentally (may interest you) from my perspective this is not so much about GStreamer vs FFMPEG / libav - it’s about some fundamental limitations in using outside processes. The JogAmp approach seems far less problematic to me (from browsing rather than testing so far).
I’ve had lots of code appropriated too, a couple of times on here - I understand it’s not a nice thing! I can’t comment in your specific case, not knowing what was used, but if others thought it was trivial it may have come under de minimis. (not suggesting this in regards to the above!)
Then, why don’t you try to port “our” stuff to LWJGL?
It was really extremely trivial but I didn’t understand why a newbie was so afraid to have to use the GPL…
I think that might be a better approach for what Riven’s trying to achieve. I don’t for a number of reasons -
- I need the added features that GStreamer provides over and alongside FFMPEG / libav. I also already have working code and know the GStreamer API a lot better.
- Despite what various naysayers around here say, I believe that it’s perfectly possible to ship GStreamer binaries and get stable results on all platforms (and that is demonstrated by lots of other projects out there, Java and non-Java)
- Ideally, any approach to making video playback easier shouldn’t be tied to a particular renderer. Despite the title of this thread, this approach is extremely easy to decouple from LWJGL. Praxis itself has both a software and LWJGL renderer (and I haven’t ruled out a switch to JOGL in future). I’m currently fixing up an alternative way of handling buffers from GStreamer to ensure that we don’t lose anything in performance with this approach (code above has an additional buffer copy, though I’ve emailed Cero an alternative that doesn’t and will post here as long as it seems stable).
Video below shows the (custom) software renderer in Praxis with GStreamer webcam input controlling GStreamer movie (576p) playback rotation - this approach is as easily adapted to Swing, Java2D, or anything else people want to use.
m-PhKAQdt28
Argh I meant to post it into this thread:
Im going to make a video tutorial showcase thingy some day.
Especially showing the high level usage in Libgdx and how easy it really is.
so I wrote a little Libgdx Showcase for this.
one thing I have learned: we never set the projection matrix, so I added
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluOrtho2D(0, Gdx.graphics.getWidth(), 0, Gdx.graphics.getHeight());
glTranslatef(Gdx.graphics.getWidth()/2, Gdx.graphics.getHeight()/2, 0.0f);
glScalef(1.0f, -1.0f, 1.0f);
glTranslatef(-Gdx.graphics.getWidth()/2, -Gdx.graphics.getHeight()/2, 0.0f);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glViewport(0, 0, Gdx.graphics.getWidth(), Gdx.graphics.getHeight());
otherwise we have this identity mode with -1f -> 1f instead of pixels
again, not an opengl expert.
which brings me to my next point: using the spritebatch before of after rendering the video doesnt seem to work and you end up seeing nothing
obviously they conflict and it could have various reasons and depends on how the spritebatch works exactly…
people may wanna have a video in the background and draw something on top, so we gotta fix that somehow
So it only works like this:
if (videoplayer != null)
{
if(!videoplayer.isDone())
{
videoplayer.updateAndRender(false);
}
else
{
videoplayer.destroy();
videoplayer = null;
}
}
else
{
spriteBatch.begin();
font.setColor(Color.WHITE);
font.draw(spriteBatch, "FPS: "+Gdx.graphics.getFramesPerSecond(), 12, 20);
spriteBatch.end();
}
We are rendering a quad for the video and then want to being a spritebatch… so it could have something to do that we have to flush to GPU first before rendering something else
might only need a minor fix, imo
There’s not an issue in the original code, but in how you’ve (not completely!) translated it to work with libGDX. I’m pretty sure the projection matrix is set correctly in LwjglRenderer, as it borrows the code for basic setup from YUNPM. You need to rewrite the GStreamerPlayer.updateAndRender() method to update a libGDX Texture instead, and then you can draw that the same as any other texture in your game.
Remember this was written as a proof-of-concept that can be adapted for other uses. GStreamerPlayer is not reusable as-is - it needs rewriting to suit whatever context you want to use the movie in. To make this more generic, that updateAndRender() method should be stripped out, and instead responsibility for rendering needs to be in the renderer and the GStreamerPlayer class should just call back into the renderer with the updated texture buffer.
Perhaps [icode]GStreamerPlayer.update(Renderer renderer);[/icode] which updates the buffer as required and calls back into renderer - [icode]Renderer.updateMovie(Buffer buffer, boolean isNewFrame, int width, int height);[/icode] ? That’s a quick and untried thought - not to be considered the definitive way to do it! 
Of course I know that. That would be the absolute best way.
I just haven’t tried it yet because I’m quite sure that because of my lacking knowledge I would do something that would slow everything down tremendously in the process.
There are pixmap and TextureData in libgdx, but I’m not really sure how to do this effectively
Even if there was something like new Texture(buffer) which I dont think there is, I would still doubt performance
You should be able to create an empty Texture (constructor with width, height, format?) and then update the texture using GLCommon.glTexSubImage() in the same / similar way. I’m doing something similar in the Praxis OpenGL pipeline, though I’d forgotten how much that code has now diverged from what’s in libGDX.
Actually I was just one line missing - texture binding, it now works fine with libgdx. Not as a libgdx texture but everything someone needs to play cutscenes. With the ability to render something above it.
Almost finished a nice showcase.
Here is another thought:
I have actually never used the 64bit libs. Reason is, although my machine is 64bit I use a 32bit JRE. I also package a 32bit private jre with my games because it works on both architectures.
Meaning I personally would never need those 64bit libs.
because I dont have a mac I could never test the Mac, but I’m kinda optimistic there, should work as expected
Now, I tested Linux yesterday. So first of all yes, most distributions and especially all the popular modern distributions come with GStreamer. Linux Mint and Ubuntu being prime targets.
So if its installed it works flawlessly.
I seem to have gathered all the libs for Linux32 and 64 - but it just didn’t seem to work. I removed gstreamer from my distro and tried to load from my libs.
But I kept getting strange errors with “cannot load gstbasevideo” for example; “cannot find file” although it shows me a path which is absolutely valid and the file does exist
Maybe it can be fixed, but the bottom line is Linux distros usually have it, a linux port of a game mine would usually anyway have a disclaimer like “works on linux, but no official support, ubuntu and mint distros recommended” so I would just add “gstreamer needs to be installed”, of course if I create on of these actual .deb packages you can actually define dependencies like gstreamer of course.