Had to change html encodings like & quot to actual quotes and so on.
Also import sun.nio.ch.DirectBuffer; doesnt seem to work anymore in java7, but in the code it is only used for system outs, which is why I commented them out.
Now I’m getting:
java.lang.IllegalArgumentException: No such Gstreamer factory: fakesink
at org.gstreamer.ElementFactory.makeRawElement(ElementFactory.java:219)
at org.gstreamer.ElementFactory.make(ElementFactory.java:211)
at org.gstreamer.elements.RGBDataSink.<init>(RGBDataSink.java:58)
at main.OpenGLMediaPlayer.<init>(OpenGLMediaPlayer.java:32)
RGBDataSink videosink = new RGBDataSink("OpenGLMediaPlayer", this);
hmm … never seen that one. Are you using a system-wide installed version of GStreamer for now?
If I remember rightly, you’re on Linux Mint? Try these from the command line.
gst-launch-0.10 videotestsrc ! xvimagesink
and
gst-launch-0.10 videotestsrc ! fakesink
The first one’s to check you see something, the second shouldn’t show you anything, but shouldn’t error either. If both run OK, then it’s a GStreamer-Java or JNA problem.
Have you tried with Java 6? What version of JNA are you using? The one from the GStreamer-Java page is actually quite old and might have issues with Java 7.
I’m only on Linux If I need to, development is usually on windows.
Tried to do it, like with VLC, making a vlib folder and using jna to point at it, but indeed VLC has another parameter I used to explicitly tell it to look for everything there, which isn’t here.
C:\Program Files\OSSBuild\GStreamer\v0.10.6\bin>gst-launch videotestsrc ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
^C
C:\Program Files\OSSBuild\GStreamer\v0.10.6\bin>gst-launch.exe videotestsrc ! xvimagesink
0:00:00.140625000 2928 00342770 ERROR GST_PIPELINE grammar.tab.c:19
75:_gst_parse_yyparse: no element "xvimagesink"
WARNING: erroneous pipeline: no element "xvimagesink"
Now that I have installed that OSSbuild for windows, I get
0:00:00.000000000 3756 00394490 ERROR GST_REGISTRY gstregistrybinary.c:557:gst_registry_binary_read_cache: Binary registry type not recognized (invalid magic) for file at C:\Documents and Settings\Me\.gstreamer-0.10\registry.i686.bin
Exception in thread "main" java.lang.IllegalArgumentException: No such Gstreamer factory: fakesink
yeah there is some code in GSVideo about on how to link it correctly…
OK. Well, xvimagesink won’t work there! Not sure what the Windows equivalent is. But it looks like GStreamer is working OK.
I assume you’ve set jna.library.path? Is there a /usr/lib equivalent (sorry, my Windows days are rusty) where you can install GStreamer and JNA will find it - temporary measure to get it working for now. Also, take a look at the library loading mechanism in GSVideo - that deals with loading GStreamer from somewhere other than a system installed path.
About time someone did this! Sods law that they start maintaining some decent cross-platform installers after I finally got around to fiddling with the library loader code from Processing / GSVideo. :
Anyway, if anyone is interested in shipping the GStreamer libs themselves, I forked the GSVideo code here. It uses the GStreamer binaries from here.
Although it has a GPL header at the moment, it can go back to LGPL if anyone wants it. However, you’ll also need to remove the GPL plugins from Processing’s GStreamer binaries to ship like that. You’ll also need to replace the InstalledFileLocator (from NetBeans platform) line with the folder containing the binaries. At some point I’ll update this to work with the libs directly from www.gstreamer.com.
In related news, the next release of Praxis (in a week or so) will have the ability to load GStreamer from a plugin on Windows. It will also have a component for live-coding GLSL image filters (LWJGL pipeline with some code based on libgdx). Currently having fun altering webcam streams on the fly! ;D
So I’ve been trying GStreamer again with the help of nsigma.
But I’m getting a JVM crash.
Here is the whole project: https://dl.dropbox.com/u/52666052/GStreamerMid2012.7z
80mb because of all the dlls, and the video file; but its fast dropbox download ~ 2mb/s
only works on windows, because only those gstreamer natives are included.
run SlickApp with -Djava.library.path=lib
pressing F starts the video
ah forget the screenshot, this happended before with vlc
its because I change the “first” texture somehow and, since the font uses textures, being angelcode font, thats what you see there
Don’t call Display.sync, Slick will do that for you with container.setTargetFrameRate(60)
You should render in the render() method and update in the update() method
Did you flip your buffer before giving it to OpenGL? or has gstreamer already done that?
Is the returned data RGBA, or is it RGB? RGBDataSink seems to imply no alpha component exists, yet you are telling OpenGL to look for an alpha component when you give it the int buffer.
Depending on the size and format you are giving, you may want to do this in init() to be safe.
[quote][internalFormat] doesn’t have to match the raw data you supply [in format]; for example if you have RGBA data but don’t care about alpha, you could specify (components = 3) and the GL would strip off the alpha channel and store just RGB.
[/quote]
I suppose I shouldn’t expect glTexSubImage2D to do the same, or to maintain the internal format specified in glTexImage2D.
Hey, finally close to getting somewhere with this!
A few things. Firstly, can you try this code - http://code.google.com/p/gstreamer-java/wiki/VideoPlayerTutorial. Add my library preloader code at the beginning of main() and swap out the deprecated PlayBin for PlayBin2. Let’s check that this isn’t an issue with anything in GStreamer crapping out with your setup / video. If that works OK, then it’s in your OpenGL code.
That should be OK, but worth trying it out to be sure.
The buffer data passed to the RGB sink is 32-bit RGB data. We do have a slight issue that it is ARGB not RGBA (more of that in a sec). The alpha channel is almost certainly 0 too, so don’t use blending!
This is one of my primary suspects. GStreamer (or VLC for that matter) doesn’t expect you to be accessing the buffer after the callback has returned. You’re getting away with this with VLC, but it might be causing issues in GStreamer. Can you try creating a second IntBuffer to pass to the texture, synchronizing between update() and rgbFrame(), and copying from the GStreamer buffer to the other one in rgbFrame().
That’s not ideal, and there are better ways we can look at buffer management to get rid of the copying stage, but it should let us know if that’s the issue.
Me too! This just doesn’t work on my setup.
I think my universe just imploded - Riven’s wrong about something!
If we end up looking at an alternative to RGBDataSink then we should be able to get GStreamer to provide RGBA data anyway.
Slight OT - The library preloader code that Cero is playing with is from Praxis (forked from Processing). Latest version of Praxis has the ability to pass video (files and webcams) through a live-codeable and controllable (8 slider GUI) GLSL filter, if anyone fancies a play!
Yeah yeah, this works perfectly and is included in the project.
Some things dont have to pointed at, like Davedes did, because this is a copy of the working VLCJ player theagentd helped me with.
So the RGBA and RGB stuff, as well as the null texture at first, are things that he did, and worked for VLC.
The problem can only be where vlc and gstreamer buffer stuff is different.
I dont think its threads.
It really really seems like a buffer overrun.
swapping some rgba to rgb and stuff didnt help.
however on my laptop here, I also cannot load any plugins
[quote]Cannot load GStreamer plugins from D:\EclipseJava\GStreamerMid2012\vlib\windows32\plugins
[/quote]
The relative path is the same as on other pcs of course, the path is completely valid and stuff, so I dont know
When I use the Java2DTest, the plugins aren’t load as well, but everything works fine. So maybe its not an issue - then why do we have them ? =D
I could explain it, but I dont think its a threading issue.
It is very very likely a buffer issue.
I guess theagentd can solve it.
Unimportant stuff:
We use Slick a lot, and like to only use the render method(like in libgdx), we dont use delta timing, and well, NOW that Display.sync() has been fixed it might be ok, but before we liked to write our own gameloop inside slick, because of stuttering issues - hard to get right.
Of course this all has nothing to do with the issue at hand anyway.
OK, though you will probably have an issue with the fact that the data is ARGB not RGBA. That just means the colour will be wrong - deal with that later!
Very possibly, but why are you so sure it’s not a threading issue? GStreamer might free the memory backing that buffer before you get a chance to upload it to the texture, which will likely crash the VM. Try the double buffered suggestion I made to check.
Also, try outputting the state of the buffer just before you upload to the texture (if you haven’t tried that already) and see what its size, etc. is.
The relative path is the same as on other pcs of course, the path is completely valid and stuff, so I dont know
When I use the Java2DTest, the plugins aren’t load as well, but everything works fine. So maybe its not an issue - then why do we have them ? =D
[/quote]
Are both systems 32bit? Wondering if some files got mixed up - either at your end or mine.
It shouldn’t work without plugins. Could it be finding a system install of GStreamer on that laptop? It really shouldn’t matter, though.
Does Praxis work on that laptop? Could at least track it down to whether it’s a change you’ve made or not.
Well the working systems are 64bit hardware wise, however java is 32 bit, as well as eclipse.
I checked it with if (Platform.is64Bit())
and like I said, its 32 bit - so I load the 32bit everywhere, however it doesnt “find” the plugins on my laptop
like I said the path is totally fine - it says "cannot find "… if I copy this exact into my file browser - its there, no problem… do maybe that error message is wrong and the problem is something else actually
I didn’t install any OSS builds, but if any media player brought it along, its possible.
because only the repeated call of glTexSubImage2D makes it crash, everything else works.
Not into buffers… how do I do this ? I see capacity, position, limit… what do you need ?
