You’re probably better off keeping it as a separate file, but packing it into a Jar file also shouldn’t be problematic at all though; they’re essentially just compressed archives anyway. The size of a file shouldn’t matter.
@kovacsdev
I reuploaded everything here: https://docs.google.com/uc?id=0B7dHrGvdQHFbbmgwWmJWS2xwT0k&export=download
Contains libs for linux, mac and windows, code and 2 video files that I use to test. I use this to convert them: https://sourceforge.net/projects/theoraconverter/
But hey it uses old gstreamer and libs, will be changed in like 2 weeks.
Thanks a lot! What do you think, can it made Gradle compatible for easier building and deploying?
Not by me. Never used gradle x)
IIRC Gradle can use Maven repositories? At least the gstreamer-java library (for GStreamer 0.10) is available via Maven, although that doesn’t answer the native libraries, native library loader or Cero’s OpenGL code. gst1-java-core (GStreamer 1.x) isn’t yet available via Maven repositories, but hopefully will be soon. That native library loader should go up on GitHub too - it’s been adapted through so many projects ? -> Processing -> Praxis LIVE -> Cero’s. At some point I’ll set up a repository for it at https://github.com/gstreamer-java/
@Riven - I understand that you’re still getting the bulk of the advantage of GPU decoding (in the same way we do currently given we don’t yet have texture sharing), but it’s still an inefficiency that can’t be worked around in that scenario, and I’m less sure on the overhead - something tells me an outdated PC may be the worst way to measure it! 
I did, incidentally, suggest the OP try YUNPM, as it’s going to be far simpler to get started. However, I also think it’s worth being aware of the limitations up front - if you know you’re going to hit them it’s better than having to start again from scratch.
eg. It does actually look like you implemented seeking already. However, it’s implemented by destroying the FFMPEG process and starting again. Something tells me that’s going to struggle to meet @Cero’s need for seamless looping? Likewise, while I realise you implemented frame-skipping, I still maintain the opinion you might struggle with sync at times because you’ve got no easy way to drop frames from the head of the process.
I mean playing a video file as an animation or background or similar, in loops, is very common
endless title screen animations and menus among others
I see, but maybe can you give me some guidelines, how to make sure its compatibility with new GDX version or how to build it with right method?
Current code should be tested with latest gdx, dont use config.useGL30, other than that works fine.
There is no reason why gdx would ever break it somehow. Of course I am using the lwjgl backend directly here, can be changed…
I really dont know jack about building and tomcats n shit. I just export my projects in eclipse with its function to a jar (only code) and thats it.
I see, but after generating a fresh project and started composing things as I normally do it in core project and also keep eyes on assets folder, there are some dependencies unable to resolve. It seems that some libs aren’t imported into libs. Maybe?
Sorry again for noob questions about this topic!
I’m not sure 
Be more specific on what is missing 
I appreciate the contribution here.
Sorry… So after copying Java files from src to core, into 2 separated packages, I see, that com.badlogic.gdx.backends.lwjgl.* and org.gstreamer.* cannot be resolved. Content and video is under android/assets and vlib_gst folder’s content in lib. I think these are first steps.
in libs you find 2 jars, import them.
you also need lwjgl libgdx backend because thats what I use on desktop, I guess you use a different one if you dont have that ?
and vlib_gst is supposed to be on the root of the project, but can be changed if you change the loading call System.setProperty(“gstreamer.dir”, “vlib_gst”);
We were the whole time on this thread talking about desktop solutions… not android, if thats what you are doing
Yes, it was clear from use of lwjgl, but if libGDX why only desktop solution? 
I am not interested in mobile games, as such I dont develop them.
Libgdx is a great framework and API, the mobile port is not why I use it.
You either make a desktop game or a mobile game, otherwise its shovelware in 99% of cases.
if you need video playback on android, android has its own video playback API already at the ready which you can use. Tho I am really not sure about using cutscenes in a mobile game… @attention span
Like @Cero I’m not personally interested in Android as a platform. However, there is a GStreamer build for Android, and JNA should also work, so in theory you should be able to get it to work with a bit of effort.
https://gstreamer.freedesktop.org/download/
There is also a tutorial for using GStreamer on Android via NDK, but then you have to write a bit of C code too - http://docs.gstreamer.com/display/GstSDK/Android+tutorials