Render to Video

This is a little offtopic as it applies to Java3D, LWJGL, jME as well as JOGL, but…

Does anyone have any recommendations for rendering to video (DivX or Xvid)?

The basic mechanics are easy now we have Pbuffers (I have a directory full of TGA files for each frame now), but how to drive the codec?

I’m just about to dive into JMF, but have found a few disparaging comments about it on these boards - and aside from anything else, the docs are all 5 years or more old. A lot has changed in that time. I’ve checked out the JCP for it and that seems to have closed in Feb 2001.

Are there any other bindings for Java to (for ex) DirectShow? Can anyone recommend Quicktime for Java? Where else would be good to ask?

Thanks,
Dave

Do you consider using a native code?
Maybe VideoLAN or VirtuaDub projects give you able to render static bitmap images to video file.

As long as you don’t mind USING quicktime, QTJ isn’t horrible for the task. I can’t speak for DirectShow or anything…

The QT bindings for Java are, unfortunately, rather neglected by Apple, but I know it’s possible to GET video, as well as to CREATE a video using QTJ. It’s rather intricate to get pixel data (a project I have planned needs this, so I’ve looked into it somewhat), but I believe creating a NEW movie from pixel data is rather more straightforward. You have to specify information about the framerate of the video file, and create a new file, and feed it sets of pixel data for each frame.

I’m sure there’s a little more to it, but it’s all doable, as far as I’m aware.

–Scott

Do this in native code.

JMF = unfinished crud that will only cause you pain.
QT for Java = no support for DIVX or Xvid, probably ok for playback of some formats, but not as robust on Windows as DirectShow. Performance of Quicktime is poor, specially on Windows. The Quicktime APIs can be icky and aren’t friendly to multi-threaded programming.

DirectShow itself can be a royal pain even when coding to it with C/C++. A typical Microsoft API that doesn’t follow its own rules and is full of quirks. It is easy to do some things and a royal pain to get anything advanced to work like it should.

My company deals with encoding digital video and all the details that go with it. http://www.digital-rapids.com/ We do high-end stuff for broadcasters and studios
If you have a directory of TGAs our product will transcode them to many different formats efficiently. It can watch a folder and create the video as the TGAs appear in it from your rendering package or custom software. A high-level C API with Java native bindings is available for it, but it is probably overkill for what you need, and it isn’t cheap.

Thanks for the advice. JMF is indeed proving to be very cruddy. It’s a real shame that Java is not better supported in this regard - one of the very few areas where I’ve actually felt let down by the APIs.

Ho well, the native route it is going to have to be…

[quote=“DaveLloyd,post:5,topic:26543”]
My thoughts exactly… you can see that they have the beginning of what could be an excellent framework for media… but the quality is so low and various things remain unfinished. It could have been a cross-platform DirectShow done right. Which I think would be an awesome thing to have.
E.g.:

  • Playing audio files for background music in a game should have been a couple lines of coding to JMF. (Ogg seems to be the solution.)
  • Playing a video cut-scene in a game should have been a couple lines of JMF. (No good solution exists.)
  • Recording from a mic for realtime voice chat in a networked game should have been relatively easy with JMF.
  • Making a cross-platform clone of something like Windows Media Player or the Quicktime player should have been easy… what we have is that little JMF Studio toy that performs abysmally on the very few obsolete file formats that it is able to deal with.

Most of the media related APIs are lacking decent integration with java.nio which is basically perfect for things like streaming audio buffers.