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.

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

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.

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.

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

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

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

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.

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.

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

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

I don't know whether you translated 'syncs fine' to 'plays fine', but those are two very different things

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.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

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.

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.

There is a shortage of code flying around that works on just the 5 machines i test on. What is the point if you can't deploy easily?

Even apps that use gstreamer have a huge list of "you need to do this with your local gstreamer for xxx to work" for more than half the faq. Its not like i haven't tried these things. They mostly just don't work consistently. And claiming that "they can"... well i don't care if they won't even work on 5 very similar machines i test on. Claiming PEBKAC is not winning points either (yes i was told that when gst seg faulted on one of my machines).

mplayer works consistently, which is based on ffmpeg. ffmepg works well too. So static binary's with pipes seems like a great idea.

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

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.

Don't pay too much attention to what I'm saying, I literally have no idea what I'm talking about That might sound like sarcasm, but it's true. I didn't do any field research, didn't even google for existing solutions, just wrote some code.

When I browse through the (j)gstreamer code, it feels like it's rather lowlevel, introducing many new concepts - like a bus that is somehow crucial to whatever it is crucial to*. If there is anything I learned from dumping my code/projects on JGO, is that the amount of code to get it to work should be less than 10 easy to grasp lines or it will be discarded.

I spent I don't know how long at Sony trying to get all these solutions to work. In the end Gstreamer is effectively an amateurish effort when compared to ffmpeg which is the granddaddy of video tools. Likewise VLC is similarly ramshackle.

At the end of the day Java only needs support for about 2 formats to be useful to 99.999% of any of us in here - Theora and MPEG2. Whichever one of these monoliths does those two perfectly correctly wins.

Odd. The first result in google for 'gstreamer' is gstreamer.net, which looks... pretty old school.

As of late the .com domain is all new and now the way to go, unfortunately the old page still exists.

I have always said Bink would be killer - at least the principle...

Just a short question: Technically, by law, you are not allowed to bundle a media file with a licensed codec right ? so even bundling a mp3 isnt allowed just like that. Theora and Vorbis are free which is why I use them. I love H.264/MPEG-4 AVC but I'm not entirely sure... is it open and ok to use ? maybe the decoders are licensed ? I assumed only Theora&Vorbis were truly open n stuff.

I will release a package like this with the GStreamer stuff we came up with.@nsigma I have only Win32 & 64 on hand... I know you posted the mac binaries which are part of praxis, but in case of linux, I never added those yet as I said.

@delt0r The stuff we, mainly nsigma wrote is very reliable and stable. We package gStreamer and it never failed on any machine or desynced. The worst I could ever do is tearing on really weak machines...

I have asked... properly asked. at least for H264 you require a license to encode/ to decode and on the transport layer. So yes if you include H264 files and a decoder, you need to pay for both.

That is what you have to agree to when you get a license for the patents.

I don't know why so much fuss is made over H264. Once you have bitrates that don't look like total crap, it does not perform any better than even mpeg2 (or theora). Sure it hides crap better at low bitrates, but then whats the point of HD if my effective resolution is more like half that? Encoding at a lower resolution with higher quality works better IMO and hides the artifacts better when scaling up anyhow.

I intend to use theora.

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

This puppy played 2k just fine, and with my changes its going to be able to play 1080p on pretty low end hardware

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.

Not to mention that you don't get JPEG compression artifacts. >_> I'm waiting for this until I try it.

Hm I beg to differ about H264 quality. Bit for bit it blows any other format into the weeds, pretty much, at any significant quality level. But that's in the digital video archiving / editing world, where I came from.In a game? Who cares. MPEG2 is good enough; Theora is just yummier because it's unencumbered.

In the end Gstreamer is effectively an amateurish effort when compared to ffmpeg which is the granddaddy of video tools.

That's comparing apples and oranges (not to mention GStreamer and VLC's use of FFMPEG underneath). Interested (genuinely) in why you consider it amateurish, and when you last looked at it. There's been a lot of work and investment in it more recently, and it's gaining a lot of traction - a few years ago I may have agreed with you.

When I browse through the (j)gstreamer code, it feels like it's rather lowlevel, introducing many new concepts - like a bus ...

The bus, element and pipeline terminology does make sense if you need to look into the low level stuff, but for just "getting things done" there's a number of higher-level constructs that automatically set things up - you basically just need to use PlayBin2

@delt0r The stuff we, mainly nsigma wrote is very reliable and stable. We package gStreamer and it never failed on any machine or desynced. The worst I could ever do is tearing on really weak machines...

btw - while thanks for the credit, most of this code (the bit that links in local GStreamer libs) is ported from Processing code by Andres Colubri - I just made it work outside Processing, and fixed a couple of bugs. The actual write to texture could be improved a lot - I just did enough fixes to what Cero had - but it works.

WebM/VP8 are relatively young even compared to Theora and their legality is still questionable. I admit it's been 2 years since I looked at gstreamer so I expect things have moved on since then; but then, ffmpeg was already working perfectly back then too.

Attempts to use PBOs, and rolls back to normal texture updates when PBOs are slower (performance degradation reported by kappa)(video starts with 5 frames doing texture updates, then switches to PBO for the next 5 frames, then picks the fastest)

So yes if you include H264 files and a decoder, you need to pay for both.

So in this case, even if we dont use H264 files but Theora with "YUNPM", we still could not bundle it legally for free with our game, because it includes a H264 decoder.If its possible to seperate those parts, it would work out. With VLC and GStreamer we have all these dlls and can delete them one by one, depending on license and requirement.

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