YUNPM - a Java Media Player

Shared Code
#21

Simply not true! Try reading the end of Cero’s thread I linked to earlier with a solution for packaging that works just fine.

GStreamer used to be a bit flaky to use / install on Windows and OSX, but there’s been a real push in this direction recently too - see http://www.gstreamer.com/. I still prefer the local packaging option for anything but Linux though.

All the extra things you’re looking to do I’m already doing with GStreamer. For a simple use case I can see the benefit of Riven’s code, but for doing more I don’t see the point in rewriting what GStreamer already provides, but in Java!

#22

I would agree, but custom formats don’t solve anything really. Also i should be clear that this is not for user files, its for my prepackaged and encoded to be nice with my player files. I don’t want to have a gp movie player. Just something that is easy to have prepacked and that will work.

Currently i will be encoding to theora and using ffmpeg, or a theora decoder. These can be statically linked binary’s and avoid dependency hell.

last time i tried jgstreamer I just got a bunch of segfaults and was told its my system that is at fault. That is not the kind of support i want to provide.

#23

@nsigma
You linked to thread that backs up my point with gstreamer. You can’t do that for everyones install when i comes to release. That is where i have never had a good time with gstreamer. Sure you can get it too work. Eventually. But never generally.

#24

Did you read to the end??? Cero’s got this working fine (as he mentioned earlier in this thread). You can package the libs as part of your installer, and it just works! It’s no different to Riven’s solution in that regard.

@Cero, any chance you could post the code you’re now using somewhere (my code is currently a little too tied to Praxis’ architecture)? It would be good to get that code in a more generalized state, possibly using Riven’s API as he suggested earlier, then we could do a serious comparison. I should have some free time next week I can look at it.

#25

Just to get everybody informed on this one, delt0r is writing a YUV streamer, as opposed to a MJPEG streamer.

For those who don’t know what YUV is: it’s basically ‘raw’ encoded RGB - every pixel takes the same number of bytes. Most movies use YUV as their colorspace, so decoding to this format is always in the decoding process, hence this ‘transcoding’ doesn’t take any performance.

This YUV data is piped to Java, which either decodes YUV to RGB on the CPU or on the GPU. In the end, there will be barely any overhead to the streaming of video, apart form the piping process, which would allow for playback of high resolution video on low end hardware.

#26

For the same reason your library limits a developer from being able to pause, resume, set volume, etc.

If the goal is simply to play videos, it doesn’t matter what format the videos are in, as long as it is reasonably sized. Some portable, straight C code for playback would be great. There is a reason Bink is so successful. Transcoding videos hasn’t hindered it. Of course, designing a video format and a decoder is not trivial. Possibly limiting to an existing simple, reasonably easy to decode format would be acceptable.

#27

I’d like to emphasize that this should not be a competition (although that’s not always a bad thing). At the moment I’d regard ‘private code that works’ not quite useful for the community, so I look forward to open sourcing Cero’s solution.

#28

Riven - thanks for creating and releasing this code. It’s nice to have more options and it’s nice that you’ve gone out of your way to fill a gap.

#29

I always assumed that the reason Bink was so successful is that it created a standard - it could have been any codec, but by limiting yourself to one, there is only 1 codec to ship to the customer.

Yes, I know that ‘contradicts’ what I said earlier, and might undermine my ‘YUNPM’ project, but well, I didn’t quite start this project because I need it myself, I just (think I) saw a need, and I came up with this simple solution, that is now being refined in the performance area.

If it won’t be used, because all JGOers would use Bink, that’s perfectly fine. In the meantime I enjoy tinkering with it and enjoy the process (releasing, feedback, updating, cooperation, etc).

#30

Up and coming:

  • Pause, resume, stop
  • Altering volume
  • Reducing overhead by switching from (M)JPEG to (M)YUV (credits: delt0r)
  • Making it easier to integrate inside a game
#31

Absolutely! Sorry, I didn’t mean it to come across like that actually.

Sure, though I guess it’s stuck somewhere in the middle at the moment. Praxis is out there and open-source, but as it’s NetBeans platform based there were a few changes needed to make it work outside the platform, as well as get it to talk to Cero’s Slick code as opposed to Praxis’ renderer (which is a fork of libGDX).

Anyway, the library preloader code that allows shipping the binaries (I’m using the ones from Processing) is linked to here - http://www.java-gaming.org/topics/gstreamer-in-lwjgl/24852/msg/233945/view.html#msg233945. (header should be LGPL here not GPL - will change ASAP).

And the corrected code from Cero is in the pastebins here - http://www.java-gaming.org/topics/gstreamer-in-lwjgl/24852/msg/236439/view.html#msg236439

Obviously, all that needs tidying up to be of more general use! :slight_smile:

NB. All that code obviously currently assumes LWJGL, Slick, GStreamer-Java and JNA are in the classpath.

#32

I imagine it is that, plus it is easy to use and runs everywhere. If all you want to do is play some video, that pretty much covers it.

The problem with Bink is that it isn’t free. $8,500 USD isn’t even close to free. Apparently ffmpeg can do Bink. It’d be dirty to use Bink anyway, it was just an example of a successful, single codec playback library. No one on JGO is using Bink and it isn’t a viable option for pretty much anyone here except Markus (who isn’t seen here anymore anyway).

I’m not knocking your work, I was just thinking that possibly the problem could be simplified. It is great you have video working! Certainly having something working is far more useful than conjecture. :slight_smile:

#33

@nsigma
On one machine… Example gstreamer command line works on machine a, not on machine b. That happens all the time! I don’t trust gstreamer because about once a year I try to use it and still flaky. Now add that windows and mac support has been poor…

If it works, great. But i won’t hold my breath. Also i didn’t notice if you are syncing sound properly?

As for “another solution”. Yes it is. But dammit, a simple to play to texture or something is just not out there. I try and go through all these libs/bindings once or more a year. They mostly sux. They mostly can be make to work on one machine. But deploy? Yea Right.

This one is the first one that has worked on all 3 machines at home, and the 2 at work without any issues at all.

#34

Yes, I agree, though with emphasis on “has been”.

I’m not in Praxis (for reasons unrelated to GStreamer), but the code I fixed up for Cero plays sound fine.

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!

I’ve deliberately chosen to fork the library loading code from Processing and use their version of the native libs too, because quite frankly that’s going to have a huge userbase testing it!

Anyway, this bit of discussion might be better off on the other (GStreamer) thread. I didn’t post here to spam Riven’s thread - I’m interested in the pros and cons of the two approaches.

#35

A quick trip to the gstreamer website shows no demo app, and that they don’t provide windows binaries. I don’t know about anyone else but for me that shows a project that’s either very immature or doesn’t care about people using it. Either way, I’m going to go elsewhere.

#36

I don’t know whether you translated ‘syncs fine’ to ‘plays fine’, but those are two very different things :slight_smile:

It wouldn’t be the first media player that goes out of sync, after your framerate drops for a second, or the audio buffer is drained. The syncing problem is not something you’d dump on a developer that focuses on getting things done – seeing how many here struggle with a steady game loop.

#37
  • a post to subscribe this awesome thread *
#38

How about www.gstreamer.com - big download button! :wink:

No, they’re not! ‘plays fine’ in my book means ‘syncs fine’ and sounds correct (undistorted, right pitch, etc.)

GStreamer is not a media player - it’s a media library. Syncing is one of its major points. I’ve never noticed an issue with sync, personally. In a way it’s doing all the sync stuff on top of FFMPEG that you’re doing.

#39

Just click [ notify ] in the dark blue bar at the top of the thread. :persecutioncomplex:

#40

@Riven
No, I want it to appear on my “Show new replies to your posts.”