Rss

Java Video: Past the Point of Caring

I used to care about Java video (c.f., parts I, II, and III of an ONJava blog series about it). I don’t anymore.

It’s not just the shifting of my interest to the iPhone, it’s that Java’s powers that be have chosen their way, and it’s not something I think will work. No, change that: it won’t achieve any of the things that I care about. It may achieve the things they care about. Which, frankly, is demoing well at JavaOne.

At this year’s show, Sun announced they’d licensed some On2 codec, and showed off a “video cloud” demo of dozens of videos being played on panels being rotated about a 3D space.

People who don’t know better were impressed. Which is the point. What Sun needed to show was that it heard the concerns of Java developers about how badly the platform has lagged in multimedia support, and by showing a gee-whiz video tech demo, they mollified that crowd somewhat. Of course, this crowd of developers assumes it understands media because they all have iPods and have watched YouTube. it’s sort of like me presuming to be a security expert because I remember passwords and use login screens.

Problem is, as the problem always is with Java, Sun is talking to the customers they already have. Their solution is targeted to the developers already using Java. Were they talking to media application developers? Probably not, because their solution lacks credibility to anyone who actually works in the field.

Here, in a nutshell, is the problem. By choosing a non-standard video codec, they opt out of the economies and ecosystems that have developed around mainstream codecs like H.264 and VC-1. With the MPEG standards, for example, there is competition among encoders, as only decoding is standardized. Any product or process that produces a compliant bitstream is fair game. As a result, the bitrates needed to produce broadcast quality MPEG-2 dropped from 8 Mbps in the late 90’s to about 2-3 Mbps in the last few years. H.264 is expected to see the same evolution, driven by competition between encoders. With a single On2 encoder, Java Media Components won’t enjoy this kind of improvement. The no-brand codec also opts out of compressionist expertise.

And there’s also the question of whether the encoder is appropriate for multiple purposes, as H.264 has proven to be (albeit with so many optional features that the different profiles might well have been different codecs in another era). To my way of thinking, you generally need three functional styles of codecs, which often requires three totally different codecs:

  • One-to-many playback – cases where the content is encoded once, and played back many times. The encoding may be thought of as “asynchronous”, in that the encoding may require much more time, CPU power, compressionist expertise, etc., than the playback. Example: DVD.
  • One-to-one telephony – cases where encoder and player are more or less equals, needing a codec that can be encoded and decoded with the same resources (CPU power, time, etc.). Example: video conferencing
  • Production – cases where the content will be heavily edited and processed. Codec here needs to be scrubbable, be easy to effect and edit, not be subject to generation loss, etc.

In general, I don’t think you find one codec that does all of these things well, and the fact that you see H.264 used for both playback and videoconferencing may speak to its high level of configurability. Presumably, you’re not using B-frames for video conferencing, due to the compression-time expense and the introduction of latency.

So having said all this, the idea that one codec is going to take care of all Java Media needs is highly implausible, especially since it’s not H.264.

The other thing that’s a big gotcha with Java Media is that the HTML5 <video> tag is poised to utterly commoditize media playback anyways. Why endure the hassle of trying to get Java runtimes on end-user systems, or have your developers and designers master JavaFX, when legions of JavaScript-savvy Ajax developers are getting video support provided to them with an industry-standard tag? Even if <video> doesn’t end up with a de jure official codec, it’s highly likely that H.264 will fill that role, as browser makers can rely on QuickTime and Flash, among other libraries, to render it. And if not, the prospect of browser-sniffing and sending different <video> tags to different browsers may still be more appealing than trying to goad users into installing Java.

To the Java crowd, this looks like a perfectly reasonable way to bring modern media support for the platform. It won’t matter, and they probably won’t think to ask why.

Comments (2)

  1. Have you heard of Qt Jambi? It’s Trolltech’s Java bindings for the Qt toolkit (the cross-platform C++ toolkit for Windows, Mac and Linux). They have a multimedia framework called Phonon that by default uses whatever native infrastructure is available – DirectShow on Windows, QuickTime on Mac and GStreamer on Linux. For full-fledged Java applications it seems like the only option that will be supported five years from now. It only offers relatively simple stuff like playback and recording right now, but at least it’s something. Oh yeah, and Qt supposedly rivals Swing in terms of GUI-creation.

    Another interesting, albeit more hypothetical possibility, is being able to get Flash and Java to interoperate. Sony Ericsson is apparently working on it.

  2. […] is JavaFX and Sun’s typically bizarre choice of the On2 no-brand codec. I’ve bashed this before, and I assume that the end-of-the-day reason is that Sun just doesn’t have the money to […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.