To my knowledge, the best tool for the job is FFmpeg, an open source video tool. FFmpeg provides much of the underlying processing functionality for other popular video tools, such as Handbrake, Miro, and MPlayer. Since you compile FFmpeg from source code, it should run on any system with a C compiler, including my OS X box. Unfortunately, it’s not the most user-friendly software package in the world.

The developers recommend using the latest version from Git (which finally forced me to install Git, something I’d been meaning to do anyway). One how-to for FFmpeg on OS X docs suggest that I’d also need LAME in order to process audio. (The audio is irrelevant for my use case, so I didn’t bother with LAME.) But I couldn’t compile FFmpeg because, apparently, OS X doesn’t include GCC. To get GCC on OS X, the official Apple way, I needed XCODE from the Apple Developer Tools. To get those you have to sign up for an Apple Developer account. Welcome to Dependency Hell, now featuring bureaucracy!

Hours later, I’ve compiled FFmpeg. However, the videos I’m dealing with are raw H.264 video files from a Night Owl K-44500-C surveillance system. Also, I want to save them as H.264-encoded MP4 files. That means I needed additional H.264 support–or, at least, I thought I did–from the x264 project. And you need YASM to compile x264.

I was actually unable to compile YASM from the Git repository, although I was able to compile it following the instructions in this Handbrake for Mac OS X guide.

I recompiled FFmpeg with the –enable-libx264 and –enable-gpl switches:
./configure --enable-libx264 --enable-gpl
make
sudo make install

To select just the relevant portions of the video, I used the -ss (start/seek position) and -t (time/duration) flags, e.g.:
ffmpeg -f h264 -i input-video-file.264 -ss 180 -t 8 output-video-file.mp4

The above example takes 8 seconds of the input video starting at the 3-minute (180-second) mark.

However, when I played back the output, it played much too fast. The source videos included a timestamp, and about 4 seconds ticked by every for every second of video! It turned out that the source videos were recorded at 7 fps (frames per second). I added a flag to specify the framerate:
ffmpeg -f h264 -r:v 7 -i input-video-file.264 -ss 180 -t 8 output-video-file.mp4

After running this a few times for different 8 second segments, I needed to put the segments back together again. This is such a relatively common use-case that FFmpeg has instructions in their FAQ, How can I join video files?. The first method–concatenating MPEG-2 files–seemed like the easiest option. However, MPEG-2 doesn’t support the framerate (7 fps).

I tried the other suggested method of concatenating videos, using named pipes. This worked, although the BASH script was convoluted and very particular.

Another thing I wanted to add to the video was a separator–some static frames to divide each 8-second clip–and a title card. At first I created a JPEG and turned it into a 1-frame video, concatenated it with itself to create a 2-frame video, and then 4, 8, 16, etc. However, I discovered a much easier method of creating a video from a single image using the loop flag:
ffmpeg -f image2 -loop 1 -r:v 7 -i image.jpeg -pix_fmt yuv420p -an -t 2 image-movie.mpeg

(The pix_fmt flag was to set the correct color space, and the an flag ignores the audio channel.)

Now I had title cards, clip separators, and 8-second video clips that I could combine into a single video. But I needed to do this hundreds of times! I wrote a Python script to generate the appropriate BASH script based on the input filename. The BASH script would create the title cards and clip separators using ImageMagick, and then call the appropriate FFmpeg commands to create and concatenate the video.

The ImageMagick commands look like this:
convert -size 704x480 -background SteelBlue1 -fill black -font Helvetica -pointsize 72 -gravity center label:[Video Title] titlecard.jpg

Then I used the find command to run the Python script on all the video files:
find *.264 -maxdepth 1 -exec ./process.sh '{}' \; -print

Eureka! It worked. Almost perfectly.

Almost.

Some (but not all) of the output videos would produce solid gray frames after a certain time point. Reviewing the FFmpeg output for those files, there was an error:
[h264 @ 0x9460340] FMO not supported

FMO stands for Flexible Macroblock Ordering, and based on the response to a libavcodec issue from 2009, the FFmpeg developers don’t plan to support it (although one of the developers suggested that, if someone would like to create a software patch to enable FMO support, the community would welcome it).

I wrote to technical support for the camera system and asked if they had any suggestions. They replied that, although conversion to MPEG formats was not supported, they do provide a conversion utility to convert to AVI. I was able to successfully convert the AVIs to MP4s. An annoying extra step, but one that is only necessary in a subset of cases.

This solution took me several weeks to figure out, although it should save quite a bit of time in the long run.

Why wouldn’t you just upload your videos to YouTube and use their embedded player? That’s a pretty fair question, as I think YouTube provides:

• An excellent player that your users are already familiar with
• A variety of options to control the appearance (e.g. you can disable related videos)
• High-availability bandwidth

Of course there are several drawbacks:

• Limits on length and file size
• Critical infrastructure is no longer in your control
• Their logo appears on your site
• Progressive download only (no streaming)

Let’s take a look at both Flowplayer and JW Player:

Both players offer simple configuration options as well as numerous additional options for users who are able and willing to change a few config options or write a few lines of Javascript. Both include cross-browser Flash embedding scripts. Both support progressive download of FLVs and MP3s and a variety of streaming servers (I’ve been working with Wowza).

Flowplayer is pretty slick right from the start. The default skin is very attractive, and the Javascript is very easy to work with. However, I have run into few issues using Flowplayer:

• Breakneck release schedule (8 releases in the past 5 months–2.24-3.0.7–and 3.1 will be out soon)
• Unresolved errors with “filmstrips” (audio with still images)
• Inconsistent documentation and support
• No streaming for MP3s

You might think that a lot of new releases is a good thing, because new features are constantly being added. But a lot of the releases fix bugs that probably should never have made it to a release version, and even releases that only include new features require a lot of testing on my part to make sure that our old customizations still work and that everything is cross-platform and cross-browser compatible. Flowplayer’s frequent releases lead to serious upgrade fatigue.

The “filmstrip” issue probably doesn’t affect many users, most of whom are probably using strictly MP3s and FLVs. But I have occasionally had use to post a series of MP3s, each with its own accompanying JPEG. Although Flowplayer supports this by adding a JPEG followed by an MP3 in a playlist, if you use “rewind” to the previous clip it goes back to the MP3–but not the accompanying image.

Although the documentation has improved dramatically since I first started using it–config parameters now include lists of valid options or formats–their examples are occasionally buggy. I have a feeling this is in part due to their release schedule, which would require substantial testing of their various examples across browsers. Their forums seem to get a fair amount of use, and the developers are present to answer questions–but occasionally an important question goes completely unanswered. They do offer paid support, which presumably guarantees a response.

Also, one of the developers has a photo of a man without a shirt (presumably himself) for his forum icon. Mind you, there are several bare-chested photos of me online, but none that I use for professional purposes. He’s Finnish, so possibly they have a more relaxed sense of decorum!

MP3s automatically use progressive download instead of streaming (unless I didn’t set it up properly, which is always a possibility).

JW Player, on the other hand seems to be a more mature product. Their release schedule follows a (somewhat) more reasonable pace, and includes substantial detail about new features and bug fixes. I have had fewer errors and issues configuring JW Player than I had with Flowplayer. However, JW PLayer has a few drawbacks as well:

• Documentation information hard to locate
• Javascript not as slick
• Overall look not as polished

The JW Player site is sprawling and a bit unorganized. You’d expect to find a link somewhere labeled “documentation,” but if you wanted to find a list of supported config parameters you’ll need to go to Support–Developers’ Wiki. Their forums are organized into categories, but you can’t restrict a search to a specific category. (Both JW Player and Flowplayer could benefit from improved site searches, in my opinion.) Although the software behind the Flowplayer forums is superior, I’ve never had an unanswered question on the JW Player forums. (I don’t know if the responses have come from developers or other users, but it’s something to consider.)

While Flowplayer’s Javascript looks very much like jQuery (and works with jQuery), JW Player’s Javascript looks a little clumsy by comparison. I wrote wrapper functions for both to supply my most frequently used config parameters, so I never use their code directly. But it’s something to consider.

The JW Player controls do not look as good as Flowplayer’s. JW Player does offer a variety of different skins, as well as tutorials on customizing existing skin files or creating your own, but none of the existing skins look as good, to me, as the default Flowplayer controls (you can supply a custom Flowplayer controlbar as well). JW Player skins offer built-in playlist functionality, toggled on or off with a config parameter (which is convenient–Flowplayer requires a Javascript plugin), but it does not look as good as the Flowplayer playlist, nor is the look as easily modified.

Both are clearly good players, but at this point in time I am recommending JW Player over Flowplayer. Although Flowplayer’s look is more polished, JW Player seems the more reliable and mature product. Your experience with either of these players, or other Flash-based video players, is welcome.