Finally got a few hours today to tidy up the GStreamer code I mentioned in Riven's YUNPM thread. Unlike Cero's earlier post, this has no Slick dependencies, and I've tidied up the way the preloader for native libs works, and added in a method to parse the video size before constructing the output window. As Cero had carefully tested this on lots of other systems, I hope I haven't broken anything!

You may ask, why post / write an alternative to YUNPM? Well, mainly because 95% of this code already existed! I also believe that GStreamer is a better option because it works 'in-process', handles all issues of sync itself (and better IMO), gives far more control and input possibilities if needed, and the actual code required to make this work is minimal in comparison.

GstLwjgl ships with embedded GStreamer libs for Win32 and Win64, meaning no system install of GStreamer is required. It's possible to do this for OSX too, but I need someone willing to test. It depends on the system libs on Linux, because I think this is the best approach, but embedding libs is also a possibility there.

The library pre-loading code is adapted from Processing, and it uses the native libs from their repo. Despite the license notice on their repo, these include some GPL plugins. It is possible to delete these plugins (as Cero has done) without recompiling anything, unlike the FFMPEG binary currently in YUNPM which is GPL and must be recompiled. I'm also going to look at getting it working with binaries from GStreamer.com which are all LGPL.

The lib is provided as a Zip file, with the same example movie as YUNPM for comparison. It responds to the same basic pause / resume / mute commands. It's a bit higher on CPU usage at the moment, as I haven't ported over any of the texture upload optimisations, and there are also some optimisations possible in the way the video buffers are handled. These can and will be improved over the next few weeks - I need them if nothing else!

@delt0r - this was mainly put together to demonstrate library bundling works fine on Windows, which is where most people have had issues. It could be done on Linux with little effort, but at the moment if you don't have a working system GStreamer then no it won't play. This works fine on Ubuntu / Mint ootb.

Why would you assume there is something wrong with my gstreamer instillation? It works fine from the command line.

Quote

Quote

Quote from: delt0r on 2 hours agoAs for "another solution". Yes it is. But dammit, a simple to play to texture or something is just not out there.

Er, that's exactly what that code is, as is Riven's FFMPEG code and as I believe Cero has for VLCJ too (though that's reliant on a GPL library). There's not been a shortage of code flying around this forum over the last few months that does this. It's just been a little hidden away!

As i said before... Code that works. Gstreamer in my experience is always like this. One thing works.. another doesn't something else crashs. Works on machine A, but machine B has not sound...etc

I have no special talents. I am only passionately curious.--Albert Einstein

@delt0r - because your default audio device seems to be misconfigured. Or it could be a missing codec throwing it I suppose. It's an argument in favour of lib bundling on Linux too (as Cero proposes). I've never had issues on Linux in years of use and a variety of distros / hardware - maybe just lucky!

Windows on the other hand has been problematic, hence doing lib bundling. The idea of tidying this code up a bit was to demonstrate that it's a valid Windows solution. Issues there I'd be more bothered about.

As i said before... Code that works. Gstreamer in my experience is always like this. One thing works.. another doesn't something else crashs. Works on machine A, but machine B has not sound...etc

Just makes no sense, no matter what process is using it, it should behave the same.And it will.

@GstLwjgl in general: Mainly because you have to build FFMPEG yourself without those codecs, for now I will definitely be more interested in GST. Would be a damn shame to ship a game and get a lawsuit.

from the command line i can play music files fine from gstreamer. So my sound is configured fine.

That's not really a good argument to say that it's all set up correctly! For a start does this actually work for you (using whatever your normal gst-launch command is)?

1

gst-launch-0.10 -vplaybin2uri=file:///path/to/sample_h264.mp4

It could easily be a codec issue - h264 could very well not be installed, and it's a terrible choice here really for many reasons, including it brings in GPL code. Maybe try a different type of video.

The error message you gave suggests your default GStreamer audio sink is set to a bluetooth device? (maybe check with gstreamer-properties) My current code is using the system default GStreamer audio sink. It would be simple enough to specify an alternative on failure, or even bring in the audio and play through OpenAL, JavaSound or whatever.

@Cero - If you're using theora I don't think it's possible to have GStreamer without it (it's in the base), therefore lack of ability to play h264 isn't necessarily a reason to bundle on Linux.

You copied large sections of my code, removed my license, replaced it with yours and claimed copyright.

Sorry, my bad, that wasn't intentional - the LwjglRenderer class should have Riven's name / licence on it too. As a quick proof of concept I wanted to make sure that it was using the same LWJGL setup as you (you did suggest I write a GStreamer backend originally, but unfortunately your API isn't particularly built for that). It's not exactly the important part of the code here though, and is fairly standard LWJGL setup, no? The actual movie player and pre-loader code doesn't include anything from YUNPM - that all pre-existed. My standard LGPL header was added at the last minute to make sure everyone knows the code ported from Processing is licensed that way.

I'm well aware of that and apologized for it. I'll put another source bundle up with the correct attributions when I get a chance. As I said, it was meant as a proof-of-concept and addition to the debate, nothing more nothing less.

How would a Mac user go about setting this up? Do I need to build gstreamer from source?

No. From the Processing repo at http://code.google.com/p/processing or I can send you them. The library preloader code will need tweaking slightly to work with them though - hopefully just a case of taking out the check for Windows and pointing it at the right directory.

The library preloader code will need tweaking slightly to work with them though - hopefully just a case of taking out the check for Windows and pointing it at the right directory.

Yeah and it should work the same with linux gst binaries, same unix structure and all

Does the linux version of processing bundle the gst binaries ? Cant find them with a quick look.(As a matter of fact, there is QTJava in "processing-1.5.1\modes\java\libraries\video\" the old quicktime thingy)

My idea would be to just burn a distro, which definitely doesnt have gst, boot from it and then try...

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

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

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

It was really extremely trivial but I didn't understand why a newbie was so afraid to have to use the GPL...

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