You can compile ffmpeg yourself to include as many or as few (even one) codecs as you like. Besides you’ll probably want to do that just to reduce its size as by default it includes the whole kitchen sink.
ah yes, so its basically the same just that its all compiled into one big binary.
Old is better? On that basis I’ll stick with Java 1.1 for now then! 
Not sure if you meant ‘their’ as in Theora and VP8, because both are still open to the question of patent legality (bloody software patents). Personally, I’d pick the better quality one and stop worrying about it!
hmm, that’s a big negative for ffmpeg in my opinion then. I use Java so I don’t have to worry about doing cross-compilation on every target platform! That’s a big win for the options with a dynamically loaded plugin architecture - delete unnecessary codecs, done!
Shipping licensed codecs is not stealing!
(and please define stealing, in the next 8 replies)
what about javafx for video playback?
https://blogs.oracle.com/javafx/entry/mpeg_4_multimedia_support_in
Is there a few select formats and codecs that’ll work, and will it be easy to plug in new ones/home brew?
The Theora & Vorbis Combo is absolutely great and legal to use.
And sure you COULD write own codecs… like you could write your own OS D=
Well, who knows? It’s nice to experiment, and sometimes new formats and codecs comes along. It would be nice to get support, even if Riven is no maintaining the library. This is just playback, right? No editing or processing?
Wonder what that uses … oh, GStreamer! ;D
Having said that, relying on a paid-for h264 codec on Linux - like that’s going to work! Hopefully they will support other codecs (discussion on WebM in comments) - it will when it’s open-sourced that’s for sure.
A lot of those format wars actually rage in the sky far above our heads. Most codecs can compress data in such a ways as to be of very high quality, it’s the bitrates that matter - and the bitrates seriously do not matter at all for games. It’s all about streaming formats, because for these massive behemoths that serve 10,000,000 videos a day, conserving 10% more bandwidth is a serious, serious consideration.
For the rest of us though… the simplest, no-license-required format is all we need. Who cares if the video data is 20mb instead of 10mb.
Cas 
@princec - generally agree with you on all that - in fact, for my own usage I almost always use MJPEG, because that also allows for seamless skipping and easy change of playback rate, etc. (irrelevant to what most people around here want to do). However, your statement maybe contradicts your earlier point about the quality of h264 - I mentioned VP8 because it’s the most similar (theoretically) unencumbered codec.
It’s working. May I recommend enabling V-sync? This amount of stuttering is even too much for me.
I did find that mjpeg took absolutely masses of CPU to decode though (not to mention that it uses an awful lot more space than MPEG). In fact I knocked up an MJPEG video player a couple of years in plain old Java inside an hour but it basically is no good space wise or performance wise - still got an eye on bandwidth, and still got other uses than just plain old cutscenes, and still looking at relatively old and underpowered systems.
Cas
I am impressed! ffmpeg.exe takes barely 5% CPU (around 25% on one of 4 cores), while Java switches between 0% and 1%. The total is the same or even slightly under what Media Player Classic uses for me. GPU load is at just 6-7%.
Oh, that was for a 1080p H264 video!
I get one of these, under Windows.
Exception in thread "main" java.lang.UnsupportedClassVersionError: net/indiespot
/media/VideoPlaybackTest : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: net.indiespot.media.VideoPlaybackTest. Program w
ill exit.
@princec - I wasn’t suggesting MJPEG as the right codec to use for most cases, just agreeing with your point that the concerns of online streaming codecs are not necessarily relevant. Where MJPEG is useful is when you need a codec that is all I-frames - animating back and forth (video scratching) through a video file could have some interesting uses in a game methinks.
@theagentd - wonder if you fancy having a look at Cero’s code above and see how it compares? I believe some of the texture writing stuff came from you (for VLCJ) originally. Would be even better to update it to the same pixel upload method as Riven is now using. I don’t have a Windows dev box, though will have a look on Linux.
Well, just did a test of YUNPM vs the GStreamer code Cero posted, but on Linux. Used a longer video of same resolution for both.
0.7.3 - 4x the CPU usage of GStreamer - as expected given the extra encoding / decoding.
0.7.5 - identical performance.
0.7.7 - YUNPM slightly ahead.
I made one change to the code Cero posted - an obvious optimization to only update the texture when there’s a new frame. Other than that there’s a range of optimizations that could be made (eg. the conversion to RGB32 is unnecessary) as well as the optimizations that went into YUNPM 0.7.7. Should try without Slick too, not sure what overhead that might be having - this was just a quick test! Given the bulk of the CPU time is in the codec, and they’re both using the same one, then not really a surprise that they’re now comparable - answering my own earlier question, in-process and out-of-process doesn’t seem to make a lot of difference (whereas the MJPEG encoding definitely did!).
I’ll tidy up the GStreamer bundling code at some point soon. Main reason to use it would be if you want the added features of GStreamer I guess (position, speed controls; online streaming; webcam input, etc. etc.).
Compare what to what?
As per my last post, but on Windows. I was under the impression that the code Cero had to work with VLC, and I hacked around to function with GStreamer for him, was originally written by you?