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

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

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.

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

Heh 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

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

@ra4king, yeah those were my thoughts exactly.

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.

@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

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

We need someone to write a multithreaded, standard compliant H264 decoder in pure Java. Any volunteers?

WebM / VP8 might be a better choice in that regard.  There seem to be a couple of attempts at pure-Java decoders out there (and I mean attempts from what I've seen so far!  )

On the GStreamer linking thing - I installed the Windows OSSBuild version and it all just worked first time with Praxis, though I haven't given it a huge amount of testing yet.  Have you actually tried with Processing to see if their bundling of the native libs works?

My FFMPEG player can  run any codec that ffmpeg supports. You can simple compile FFMPEG on any platform that you want to run the player on.

There are ways to get around licensing issues with FFMPEG, even if that means requiring a simple external installer not packaged with your program.

I have had a chat with a lawyer on the licensing thing. First off outside the US and the odd other country that has software patents using a software version of something like H.264 is, to the letter of the law, is possibly ok. That is right, even then the lawyer would claim its ok if you are making money. The the only thing that is free with H.264 is streaming over the web, the encoder and decoders need a license if you ask MPEG-LA. 

As for quality and space, well its no secrete that MJPEG sux on this front, but if you don't have a lot of cut scenes it may be a good option.

But don't buy the H264 is the best by far crap. I was on the doom forums and i pointed out that at the kind of bit rates I care about (high quality) MEPG2, H264 and Theora are about the same for 99.9% of the people out there. The answers i got is we need to use really low and unrealistic bit rates so we can tell what is better! IMO that is crazy talk. 

Theora does not have hardware decoding but recent versions do 1080p on my old machine with less that 30% of one core.

So the best option IMO is a JNI to the standard Theora playback libs with playback via lwjgl to solve or mitigate sync issues. Perhaps some thought as to how to get the data out.. ie perhaps decode directly to texture, and use GLSL for colour space changes, since this is often the bottle neck. Then basically use a build stack like lwjgl uses. Some work, but the lest work IMO... 

I have a GLSL codec of my own which in tests didn't do so bad, but i doubt i will finish it on a human time scale

I say lwjgl because everything java2d is *not* easy to sync if at all. To sync you going to need to framedrop sometimes which looks horrible on PC monitors where you really need to run a native frame rates or have a very consistent pull down. Now lets consider java sound? Hell no, just use openal. Java2d is just not animation friendly.

BTW you should always sync to sound rather than a clock if possible. Perhaps not so important with short clips, but for long ones, the pc timers are not accurate, so sync with what we humans notice... sound out of sync with video.