IBM had a decoder for the "base" MPEG-4 codec (which preceded H.264, and is in some ways a tweaked H.263) working in Java back in 2003.
http://www.alphaworks.ibm.com/tech/tk4mpeg4 I don't doubt for a second that H.264 decoding, at least for the simpler profiles that are in widespread use today, would be doable with modern JVMs on desktop-class hardware. Whether it's worth anyone's time is another matter, and may account for why it hasn't already been done. Still, this might be one place where Java's embrace of true primitives is a big win, because as Christian said, it would involve a lot of byte arrays and bit-shifting, lots of simple arithmetic performed en masse and frequently… exactly the sort of thing where you wouldn't want to unbox a million Integers into ints every second. In other words, I think you could write a practical, performant H.264 decoder in Java, but not in Ruby, Python, or the other scripting languages that don't embrace register-size types (int, long, float, double, etc.). I would note something else, however. Having now spent a few years on other platforms, one thing I would be strongly inclined to do in any serious attempt to do media in Java again -- aside from reiterating that doing media in Java at all is a really bad idea that has never really panned out (but let's not get into that now) -- might benefit from being designed for use with the real-time Java spec (JSR-1). I've been doing a lot of work lately in the low-level Audio Units of the OSX/iOS Core Audio framework, where the processing of audio occurs on real-time threads that have hard deadlines to move buffers through the system. Since the whole nature of the digital media processing engines is delivering audio buffers and video frames at predictable times, this might be a really appropriate use of JSR-1. Also, if Java never got a vector processing library (like OSX/iOS' Accelerate.framework), maybe someone should start a JSR for that. When you're applying the same operation to big buffers, it only makes sense to employ CPU-level support for that, if you can. Hope I haven't drifted too far off the topic. FWIW, I do a lot of C now. It is really fast. And I screw up the pointers at least three times a day. Java's value proposition was always about making that pointer pain go away, at a price. --Chris On Sep 29, 5:06 am, Ricky Clarkson <[email protected]> wrote: > That's fair enough. Personally I'd love it if someone would port > H.264 decoding (and MPEG-4, and less importantly, AVI creation) to > Java, then the app I work on could drop its ffmpeg dependency like the > ton of bricks it is. > > If any of you can compile ffmpeg to Java bytecode via lljvm-gcc or > similar I'd love to know. > > I wonder whether Reinier's Lombok can 'fix' Java's signed bytes in some way. > > On Wed, Sep 29, 2010 at 10:01 AM, Christian Catchpole > > > > > > > > <[email protected]> wrote: > > because i'd probably be working with only a few (large) byte arrays. i > > would be frustrated by the lack of ability to convert integer types > > without shifting and & 0xff. don't get me wrong, i know the JVM rocks > > but some hard core math like video codecs needs to break out of Java's > > type system. I'm not worries about GC and such things because my > > understanding of codecs is they preallocate their buffers and work in > > those. And C++ might be useful here where pointer arithmetic and type > > casting is going to be helpful. > > > I'm happy to be proven wrong however. :) > > > On Sep 29, 6:51 pm, Ricky Clarkson <[email protected]> wrote: > >> Why wouldn't you want to write a H.264 codec in Java? > > >> On Wed, Sep 29, 2010 at 9:37 AM, Christian Catchpole > > >> <[email protected]> wrote: > >> > it is probably slightly an apple vs oranges question because of the > >> > kinds of apps you would write in each. while we know Java can cut it > >> > on the desktop, it often doesn't roll that way. A good C++ programmer > >> > might be able to do amazing things but only because they are being a > >> > human compiler and need to be aware of how everything is working on > >> > the metal. So the same argument could be made for C vs assembler. > >> > This isn't meant to insult C++ developers (I was one for years and > >> > still tinker). > > >> > Java is "cheating" in that it gives you stuff for free, but also frees > >> > you up to think about the problem, not the implementation. Which > >> > should be the goal of any higher level language. > > >> > I wouldn't want to write any kinds of server side / business apps in C+ > >> > + (unless it was doing something very specific). You have to go out > >> > of your way to bring down a Java server. > > >> > I wouldn't want to write a h.264 codec in Java. > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "The Java Posse" group. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]. > >> > For more options, visit this group > >> > athttp://groups.google.com/group/javaposse?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
