is video playback in java really as complicated as it seems?

Newbie & Debugging Questions
#1

Hey, I am looking to add a little bit of video playback (a video playing in the background of my menu), and the more I read as I google/search forums, the more impossible the task seems.

First there is JMF, quickly found out that that sux. then I stumbled across a couple of things, and then on to someone saying that they extracted JMC fromt he javafx, but that seems strangely difficult, and someone mentioned problems.

so if anyone knows any actually practical ways, that would be fantastic :). BTW, this is an applet if that matters.

Thanks,
h3ckboy

#2

This thread has some info: http://www.java-gaming.org/topics/vlcj-in-opengl-lwjgl/24846/view/topicseen.html.

#3

hey, thanks for the fast reply. A quick read and I just have one question, does it require signing? cuase I saw mention of it. I would prefer to find a way to do it without signing because I have actaully gone through a lot of trouble to avoid that.

#4

If neither bandwidth/filesize, CPU-usage and image-quality are a major concern… why not try MJPEG? :wink:

#5

And here I thought compression, performance and quality was a “pick two of three” thing of video compression…

#6

Yeah, I had that exact same thought… “pick one of three” seems really awful, but it’s trivial to implement, works everywhere and well, that’s basically it.

#7

Yes it often requires signing, maybe look at Curtado. Video playback often requires the use of native libraries :frowning: and you cannot use them without some permissions.

#8

MJPEG’s not a bad solution to begin with though it uses something like 10x the space of nicely compressed H264. You’ll also have to interleave your audio with it manually I think.
Xuggle works, but it’s large (5mb or so last time I looked?) and uses native code. Cortado I did at one point have working … a bit. But it was riddled with bugs, and almost no video I compressed would actually play back under it. This was about a year ago. It also needed quite extensive modification to get it to play back into OpenAL and OpenGL.

Cas :slight_smile:

#9

Last time I checked it was more like factor 2-3 than factor 10. So it’s not that bad… and you don’t have to sign anything.

I have no idea why I’m defending MJPEG :slight_smile:

#10

Heh :slight_smile: Well, it is arguably the simplest and easiest way to do it, especially if you’re talking about under a minute of 15fps low-res video footage and broadband downloading.

Cas :slight_smile:

#11

http://www.customink.com/designs/proofs/jnv0-000m-v4pa/front.jpg

#12

Well on decent computers, extracting each frame and drawing it on a BufferedImage shouldn’t be that slow :stuck_out_tongue:

#13

Inadequate. Needs more JPEG compression artifacts.

#14

@ra4king, yeah those were my thoughts exactly.

#15

for MJPEG, would something like this:
http://www.walking-productions.com/notslop/2010/04/20/motion-jpeg-in-flash-and-java/
be a good way to do it?

#16

I made a video player a while back using ffmpeg (link)
It wasnt the best didnt really spend much time on it. But it might be a good idea to look into ffmpeg command line tool.
you can feed any video compression type out to jpeg over a socket (aswell as .au for sun audio). And just have a server waiting to upload any images or audio data.
On stopping the video you can simply close the port, and ffmpeg will close.
you can also set a whole bunch of custom settings into the command line tool, also read the video information with the ffmpeg output.
It would also mean that it would automatically updated with any new release of ffmpeg.
The bottle neck is weather or not FFMPEG real time encoding is fast enough. That said, even if the computer isnt fast enough you can always change the export screensize, or framerate so that even the slowest computers can view something.

#17

yeah I made many threads about this, and eventually no have given up
we are doing cut-scenes, graphic novel style

list of problems:

  • almost all codes cannot be used due to licensing, gotta use something like theora
  • audio & video syncing
  • the code to playback
  • most video playback code has some license by itself. “if you want to distribute vlc, then your own code must be GPL, meaning you will need to offer your own game source code” (Mark Lee, VLCJ)
  • if you want to support all 3 major platforms, the video code should also work the same on every platform - seems almost impossible to achieve
  • you have to ship codecs and stuff, because you can obviously never expect the user to have something installed - again legal issues with that
  • linking problems and stuff
  • most video libs are for use in swing, not OpenGL (which makes it at least hard to port them, into your OpenGL game in a decent manner)

facts:

  • I personally know of no java game, which runs on all 3 platforms and has video playback (of course I might be wrong, but its definitely not common)
  • even Xuggler, which is quality-wise the best, has no player, and still syncing problems
  • jMonkeyEngine scrapped video playback

I would kill for BinkVideo-Java

In short: There is no practical way of implementing video into a java OpenGL, cross platform game today; at least none that is “known” or published

other threads by me on this problem:
Video Playback
VLCJ
gStreamer

#18

@Cero So, how did you get on with GStreamer in the end? I’ve worked with this in Praxis on Linux and some testing on Windows, and it seems to work well with a system installed GStreamer (from OSSBuild). You can also ship the library alongside your code too. GStreamer will be the default video library in the forthcoming version of Processing, and they have the Windows and Mac native libs packaged in their repository (http://code.google.com/p/processing/). It would seem to answer a lot of your list of problems - it’s LGPL for a start, and it is possible to get the data directly into an OpenGL texture. It’s obviously not a good solution for an applet, and it’s rather large, but for a desktop based game it should be usable. You can pare the size down by only including the minimal codecs you require (which obviously has to be something you can ship). With the Processing guys pushing it, it’s likely to get a lot of cross-platform focus on it as well, and extracting their work to pure Java shouldn’t be too difficult.

Best wishes, Neil

#19

Linking issues, I could never get it to run, always different errors.
One of my teams programmers tried too, and couldnt get it running aswell
out consensus was that if we developers can’t even get it working, how likely is it to run for all users without problems ?

[quote]You can With the Processing guys pushing it, it’s likely to get a lot of cross-platform focus on it
[/quote]
true that.

I just can’t do all the work leading up to a practical, cross platform, java OpenGL videoLib

#20

Clearly it’s important to you. I can’t help but wonder why you didn’t write a 10-liner mjpeg client.