Month: March 2006

Make a DVD with ffmpeg

For a project we have going at Oasis Digital, we have explored various libraries for creating video DVDs from computer-generated content until program/script control. There are quite a few ways to do this; one that is appealing for a command-line junkie is the combination of ffmpeg, dvdauthor, and mkisofs. It took considerable research to figure out what commands to string together for a simple scenario:

  • you have some video in AVI format (for example, an MJPEG AVI from a DV video camera)
  • you have some background music in mp3 format
  • you want a simple one-title one-chapter DVD with that video and audio

There are plenty of sites with long and complex sets of commands to accomplish these things. But for this simplest case, the essential commands are:

ffmpeg -y -i video.avi -i audio.mp3 -target ntsc-dvd -aspect 4:3 dvd.mpg

mkdir DVD

dvdauthor -x file.xml # there is a way to avoid the file by putting a few more options here

mkisofs -dvd-video -o dvd.iso DVD

Of course, there is considerable other work involved in wiring up a full solution, but that is more project specific. I hope these example commands shorten the research time for the next fellow who needs to do this core processing.

Ruby OpenGL, Kororaa Xgl

Last night at StlRuby.org the question came up of how to contruct GUIs with Ruby. I mentioned that I think there is a lot to be gained by using the high performance graphics hardware APIs, which are mostly used for games, in business applications. This of course is not all that remarkable, since Java Swing has used DirectX for drawing for the last several years, and Windows “Vista” will use it for most of Windows itself. I’ll discuss this idea more in a later post; I’m investigating it here for a couple of Oasis Digital projects. On my list of tools to experiment with is Ruby + OpenGL; there is a RubyGarden page about it and another page here, unfortunately in Japanese. I found a ruby-talk post which indicates that it works quite well.

John McClenning pointed out Kororaa Xgl, a project which modified an X server to draw with the OpenGL API; there is a LiveCD of the Kororaa Linux distribution for trying this out. I’m downloading it now the torrent. Novell is also a sponsor of this effort.

(A plug: uTorrent is the best BitTorrent client I’ve seen so far: it is small, clean, featureful, usable, robust, ad-free, and free.)

Email2Face, a good idea

Jonathan Goodyear‘s ASPSOFT just announced Email2Face, a public database mapping email addresses to photos.  This strikes me as a good and useful idea.  If it gets some traction, it would be nice to have an email client plugin to automatically retrieve them.

http://www.email2face.com/

What I would really like to see is something with a similar results, but rather than be a project from one company, instead be open, scalable, and RESTful; perhaps some mapping from email address to web site containing information about the owner of the address.  For example, agree that for aaa@bbb.com, information will be a http://bbb.com/email/aaa/ and from there have links to specific kinds of information, such as… a face photo.

Rhino and Web Start

We discovered today that by default, Rhino (the Mozilla project’s Java-based JavaScript interpreter) does not work inside of a Web-Start-launched application; it fails with a permission error due to loading of dynamically created classes. After a few minutes of furious searching, it seems that there are surprisingly few mentions of this issue, which affects lots of other tools when used under Web Start; it makes be wonder how many projects are using Web Start.

A solution was forthcoming from Heng Yuan, who described it in detail in a Rhino Bugzilla entry, and provides a solution/workaround as part of his CookXml JavaScript Extension. Mercifully, you need only two classes from that package (which has a BSD-like license). These two classes depend on no other files therein; I’ve posted those for easy download:

CookXmlRhinoWebStart.zip

The lines needed to invoke them look like this:

// org.mozilla.javascript.Context

context.setOptimizationLevel(-1);

ProxyJavaAdapter.init(context, scope, true);

Hints at Win32 Deprecation

I just read today (wow, where have I been?) about the issue with Win32 binaries under the (delayed) Vista version of Windows – most notably, that Win32 binaries will need to be signed, otherwise they will provide a, er, “downlevel” user experience. A proposed workaround is to code to another runtime environment (.NET, Java, Ruby, you name it) so that getting the actual Win32 binary signed is someone else’s problem.

This reminded me of comments I made a few years ago, closer to the dawn of .NET: that if .NET works out well, native binaries will end up deprecated, supported for a long time but in the same way that we can still run an ancient DOS “.com” binary on Windows XP… i.e. not really as first-class citizens. At the time I got rather negative feedback to such a comment, but now the Vista feature above seems like the first step in that direction.

Update: As far as I know, this feature did not make it in to Vista – unsigned EXEs are still OK.

To Wrap, or Not To Wrap (Jemmy)

Yesterday I mentioned a talk by Mike Feathers about API design.  One of the topic of API wrapping, which we do frequently here at Oasis Digital, for a variety of reasons.

By coincidence, today the question came up of whether we should wrap the API of Jemmy, a Swing GUI testing tool.  Our natural inclination is to wrap.  But there are oppossing forces as well.  Here’s where I ended up:

  • The Jemmy API is large, and thus tedious to wrap.  (Which might be a good reason to wrap it…)
  • We haven’t used Jemmy much yet, so we don’t have any real idea what subset of its API we will use.
  • We haven’t done much GUI test automation yet, so we have little reason to think we know much about API design for that.
  • There are developers “out there” who know how to use Jemmy. Perhaps we will hire one, and benefit from them already knowing how it works.
  • Thus, we should start out using Jemmy as-is.
  • Once we have a moderate body of code (enough to understand out use, but not so much that revamping it would be burdensome), review this decision and decide whether to wrap it.