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).

Then, why don't you try to port "our" stuff to LWJGL?

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).

I went into /usr/lib and copied everything that seemed useful, and later compared it with our mac and win folders of gstreamer and deleted everything that seemed unrelated... a lot of courseif in /usr/lib there was just a gstreamer folder with everything in there, it wouldnt be a problem, but its kinda like system32 on winAnyway I'm pretty sure I have a linux32 folder for gstreamer now, which should work and may only contain more unnecessary stuff.Me personally, I will delete everything but the theora and vorbis decoders later in real usage anyway because of license issues

Haven't had the chance to test it out though yet.Does anybody know which linux distro has a live-cd version, java installed, but no gstreamer ?well propably not =D

going to get just some linux distro, deinstall gstreamer and install java...

otherwise we have this identity mode with -1f -> 1f instead of pixelsagain, 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 nothingobviously 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

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 elsemight 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.

to update a libGDX Texture instead, and then you can draw that the same as any other texture in your game.

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

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org