GstLwjgl - yet another media player

Shared Code
#1

You wait for ages, and then two turn up at once … ;D

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! :wink:

You may ask, why post / write an alternative to YUNPM? Well, mainly because 95% of this code already existed! :wink: 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! :slight_smile:

For want of a better place to put this for now, it’s up on Google Drive - https://docs.google.com/open?id=0B_q5nI7hdd_3NHk0TVBBcHBmSW8

#2

get the following and nothing happens when trying the gst-lwjgl.sh script
bt_audio_service_open: connect() failed: Connection refused (111)

I have no idea what that means. I am on slackware 64 and everything here works pretty well (youtube, mplayer etc) and sound seems to work with everything else.

#3

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

#4

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

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

#5

@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! :slight_smile:

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.

#6

Aha ! Definitely need to ship working linux libs…

Yea, you basically have to do everything to maximize your chances.

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.

#7

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

#8

then thats wasnt the problem
the codec thing of course could still be… just “music” doesnt say much
a normal installation of gst should include all

but yeah this is really a part where we would sacrifice control and it would be out of our hands - so bundling mac and linux libs will come

#9

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


gst-launch-0.10 -v playbin2 uri=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.

#10

My point is, if you rely on it being installed and properly - thats a risk.
And well if you sell something on Linux that uses gst, I really would want to include it.

OpenAL is cool of course; but if this MAY cause sync issues than something like that should be avoided

#11

Please do not disregard the opensource license I put in YUNPM.

#12

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

#13

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.

#14

My code is in GStreamerPlayer.java and LwjglRenderer.java

Whether you think it’s trivial doesn’t matter, you copied and altered it, which means it’s a derivative work.

#15

There is nothing in GStreamerPlayer that is copied from YUNPM.

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.

#16

I was looking for it too.

The only differences in the player I wrote and the new one are

synchronized (lock)

and the dirty boolean

#17

Yes, your name needs to be on there - another omission I’m aware of. Never do anything in a rush! :wink:

The other new code is around the preroll() and dimensions methods, to fix the issue you’d asked me about.

#18

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

#19

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.

You could also try a system install of GStreamer from here - http://docs.gstreamer.com/display/GstSDK/Installing+on+Mac+OS+X - but then you miss the benefits of bundling. Be interested to know if it actually works, mind! :wink:

I do plan on extracting the binaries from GStreamer.com and making whatever changes are needed to get the preloader to work with them.

#20

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…