Ogg-xasperated part two

I'm sure there are others working through the same saga (or is it s-ogg-a?) with regards to prepping video to play natively in HTML 5. This post contains some additional thoughts that some readers (and googlers) may find useful in developing a workflow around OGG Theora video for Macs. For any readers of mine that have no interest in technical video issues, (most of you) I'll have to ask you to bear with me and ignore this post, as I promise more interesting reading in the future.

Each week, I need to be able to convert two parts of a church worship service into Ogg theora. Each part is about 30-45 minutes long. I'd like a higher quality audio encode for the portion of the service that contains music. For the sermon portion, which is mostly speaking, I am willing to sacrifice some visual quality and sound encoding for smaller files and better use of bandwidth. I'm used to these files in Quicktime H.264, and file sizes typically range from 120 meg to about 180 meg. Encoding time is a consideration, since the computer we use has a lot to do between Sunday and Tuesday, which is when I try to have the files ready online.

I didn't mention in my last post one other option that I was almost happy with - if I encoded my files using compressor into basic MPEG1s set to the highest quality I could set, then ran those through Simple Theora Encoder, it created decent-looking video through batch processing very quickly. Unfortunately, I wanted the ultimate quality a little better and the filesize to be about half of its final result. Still, it would work in a pinch.
.
Since my last post, I've toyed with two additional workflow possibilities - I found the options in compressor to create custom settings using quicktime extensions, which allows you to encode OGG theora in a batch if you have the Xiph.org quicktime components. Unfortunately, this method insists on a quicktime container format, which won't work for HTML5 playback in firefox. I'm told there's a command line trick using FFMpeg, but reading about it makes my eyes glaze over, so I had to find another solution.

I also found a plugin for firefox called Firefogg which looks extremely promising. If you go to the firefogg website , it'll give you options to choose a file, choose some settings, and encode the file locally on your computer using the plugin. This has the added bonus of not tying up my video editing software while it encodes. Unfortunately it does not allow me to choose a file on my Mac, so I can't get my foot in the door to test it out. I guess I'll have to save that one for my PC videos.

So that brought me back to exporting using Quicktime conversion in Final Cut. I started with the default settings (Keyframe every 64 frames and "best" on frames per second) and scaled back the quality to "low", kicked on optimize, and sharpen on low. While the final video wasn't bad, it was about twice the file size I expected and took 30 minutes to encode a 3-minute video. This 10:1 ratio on encoding times was not going to work on my schedule.

Over my series of tests, I discovered that the "Optimize" checkbox seemed to do little for the quality other than increase encode time significantly. Meanwhile the "lowest" quality was far too pixelated, although the file size was well under what I'd hoped. Meanwhile, if I set more keyframes, it didn't add much to the file size, and lower frames per second helped keep it small as well.

I hit the sweet spot at 20 frames per second, keyframing every 15 with the quality slider set to "low" and optimize off. File sizes where what I expected from my H.264 encoding, and my encoding time ratio was closer to 2:1 (about an hour to encode a 30 minute video). For the size and the processing time, the quality was far better than I'd expected. I adjusted the settings to 15 fps for the sermon, started it encoding, and called it a day. I'd been looking at this too long, and my problem was solved.

Later, I checked my twitter stream and found out that Google had announced a new video format called WebM, which is unencumbered by licenses and backed by Mozilla and Opera. The goal is that it could work for HTML5, which could potentially make encoding in Ogg a moot point. *sigh* Why is it that just when I figure out the best way to do something, it changes? I guess that's what I get for aiming at a moving target. ;)