also tried this:
buffer = rgb.duplicate();
no effect
Very possible, that error message is from the Processing code originally. It’s shown if the GStreamer registry returns false when you pass the path to scan. It’s meant to return true if the registry actually changed. If it’s all still working, could it be you’ve called load() twice?
That is exactly where I’d expect the issue to be - when OpenGL tries to access the memory.
What you ;D need is just to System.out all of that and check it’s what you think it is. That will tell you if the buffer is as big as you think it is.
Try reading the JavaDoc of that method! It doesn’t copy the values, it creates a new buffer that wraps the same contents. If the memory is cleared it will still go boom!
Having said that the stack trace looks like there’s a problem somewhere else. But if it’s really where it looks like, your Swing player should crash out too. Is the PlayBin setup exactly the same (except for the listener) between the Swing one that works and the OpenGL one?
I’m assuming you are using a recent version of JNA, right?
I wouldnt no where… also this issue would be on all machine, would it not ?
I have no idea about buffers, really.
See above - how would I copy it then ?
Works fine - here is the code: http://pastebin.com/rjiN38M9
Well, I am now… =P
no difference.
I have perhaps overestimated your Java experience. Take some time to learn about Buffers. You’ll come unstuck with GStreamer, LWJGL and lots of other things otherwise.
About these GStreamer factory problems, thats because you haven’t installed the gstreamer-plugin “fakesink” and “playbin”.
(I’m sorry you might have already fixed that problem… haven’t read the whole topic…)
Indeed. I don’t do low level stuff.
Well someone will be able to finish it.
Ya think! Maybe try reading the whole context before responding! 
Man… Sometimes men dont have time, okey? 
I’ll have a look if you upload something other than the .rar file. Won’t extract cleanly for me. Try a .zip at least.
If you don’t have time, don’t respond. Your response was incorrect for the first post, and irrelevant to the discussion below it!
[quote=“matheus23,post:31,topic:37308”]
._O?
I was exaggerating. It has bad compression =P
@Cero, just noticed your re-post - I ended up working off your pastebins instead. Hopefully these rewrites work for you - my dev machine is Linux, and I haven’t tested on Windows. Fingers crossed! ;D
I’ve moved a few things around, in particular I’ve moved all the OpenGL code below render(). I’m fairly sure this was the cause of at least one segfault. Also had to deal with a few other exceptions after cleaning that up. Also added in some stuff so it doesn’t trample all over Slick’s rendering - was writing over the font texture. Ideally, the video code would be in a SlickCallable safe block, but I couldn’t get this working correctly and ran out of time.
You’ll need to change the video dimensions and file name back, as I hadn’t got your archive file at the time. You’ll also need to re-enable the library loader (commented out for Linux) - I’d put it early in your main() too. Finally, you’ll have to change the package - I was using within an old existing Slick project of mine.
http://pastebin.java-gaming.org/54a6b7d341c – SlickApp
http://pastebin.java-gaming.org/54a6b8d341c – GStreamer_TestPlayer
There’s some extra buffer copying going on which we can get rid of if this works OK for you, although the performance seems fine here.
Best wishes, Neil
Works great.
So now we gotta iron out everything.
First of all, in VLC using Theora, it wasnt possible to get the length of the file, as I said, its a VLC bug.
Is it possible in GStreamer ?
This
System.out.println(playbin.getState());
System.out.println(playbin.isPlaying());
returns PLAYING & true even after the video has ended
So it it isn’t possible, I’m going to use the same fix as in VLC - when playing a video I pass the length in ms, which I already know, and then I can shut it down like this.
For cut scenes the game has obviously to know when its ended…
The thing on my laptop is still odd - but it did work
I’m going to check that out again
And then we have to include linux and mac binaries of course… Downloading the linux version of processing…
I think that’s correct behaviour, though you’d really need to go through the GStreamer API to be sure. The length is definitely picked up - the position element in Praxis works fine with your video, and that relies on duration.
Instead, try using
playbin.getBus().connect(new Bus.EOS() {
public void endOfStream(GstObject arg0) {
// mark your video as done here
}
});
There is also Bus.ERROR which you might want to add as well - this will get notified when (you guessed it! 
)
You should dispose of the playbin when you’re done (though possibly not from the EOS callback itself)
playbin.setState(org.gstreamer.State.NULL);
playbin.dispose();
I’ve no interest in shipping binaries for Linux (and neither does Processing). You’re on your own with that one if you want to go down that route. It shouldn’t be that difficult to adapt the library loader code, but most Linux users should have GStreamer installed already.
Mac I’ll be looking at as soon as I get a chance to test, and will post back here, as I will if I sort out a better buffer handoff mechanism. The rest is up to you now!
EDIT: The GStreamer-Java mailing list is also worth checking in with.
There was indeed a GStreamer preinstalled that was interfering, works as expected now.
Good to know, though it still shouldn’t happen. The pre loader should override a system install. I’ll do some more checking my end, and keep you up to date if anything changes.
After I deinstalled GStreamer, without restarting, I could see that it still tried to find plugins on the C drive where it was installed, and said “cannot find plugins there”
it worked - so it loaded the right plugins; but yeah, that overriding seems tough
Well if thats true, then there is no worry I guess.
If ubuntu for example comes with gstreamer… which, I mean, it comes with a working totem player, so yeah
Only Mac then.
hmm … looks like GStreamer has a default selection of paths it searches for plugins. Rather than adding the plugin path with the scan path later, it might be possible to pass it in to Gst.init as one of the String args.
ie. instead of new String[]{} have new String[]{"–gst-plugin-path=PATH"}
I haven’t tried this yet!
This won’t stop it loading from the system paths, but should put those plugins first - see more at http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstRegistry.html
It may be more trouble than it’s worth, though. As you found, it doesn’t fail.