As far as I know, IBM's implementation does not allow access down to the frame (I need to identify i-frames and p-frames, for instance).
On Thu, Sep 30, 2010 at 2:09 PM, Chris Adamson <[email protected]> wrote: > 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. > > -- 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.
