There’s nothing like waking up in the morning and realizing that your chief marketing tool is probably driving away more clients than it’s attracting.
I both love, and hate, Quicktime. Flash is the universally accepted method of viewing video on the web but it doesn’t seem to be an easy or cost-effective tool for those of us who want to manage our own showreel web sites. I own On2’s FlixPro, and while it seems to be one of the simpler solutions out there it is still horribly difficult to get the same quality out of Flash video that I can easily get out of Quicktime. Newer tools, such as Adobe’s Media Encoder, do a very nice job because of their recent addition of H.264 as an encoding option, but there’s still the issue of constructing or adding a player to the video file after the encoding process. Frankly I just can’t be bothered to learn how to do all that. Encoding video is not my primary career.
Quicktime has always been super easy to use. In the old days I spent $30 on Quicktime Pro and used that to compress my video to manageable sizes. Encoding with Quicktime 6 Pro was easy, and H.263 offered fairly good compression at fairly small file sizes.
And then the H.264 codec showed up. It compressed smaller, prettier and cleaner than anything that came before it. It completely changed the face of video on the web. But… there was one near fatal bug.
This article by PVC’s Chris Meyer explains the problems that a lot of us have suffered through for the last three years. While H.264 is about the best codec out there for compressing web video, and while it is super easy to use when outputting from Final Cut Pro via Compressor, the gamma is ALWAYS boosted, making clips look both milky and desaturated. And that doesn’t bode well for business, as almost nobody wants a physical showreel anymore. They want instant gratification via my web site.
The only reasonable explanation that I’ve heard for this boost in gamma is that Apple assumes that your display is set up for a gamma of 1.8 and is trying to help you out by encoding video with that gamma setting locked in. This website has an interesting explanation about why that is. The digital video and Windows worlds are both locked in to a gamma of 2.2, and that’s currently how the vast majority of computer displays are set up.
The culprit is a tag hidden inside Quicktime that tells Quicktime Player to display H.264 video with a gamma of 1.8. There is no known way to access and change this tag. There are a couple of applications that claim to be able to strip this tag from an existing Quicktime file, but none of them worked for me.
I asked a web-savvy friend if he had a solution and he suggested that I encode my video with a Compressor gamma filter setting of 1.22, with the intent of counteracting the gamma boost by making the video darker. This appeared to work, and I was quite happy for several months, until it was pointed out to me that my video clips looked way too dark when viewed in Firefox. Safari and Omniweb (my current browser of choice) see H.264 encoded video with the boosted gamma, so my Compressor-darkened material looks fine; Firefox somehow bypasses the gamma tag and sees the video clips as they really are: too dark. I’m told this is also the case when H.264 Quicktimes are viewed in Windows, a platform which (I’m told) has a quite a few customers.
The best solution I found was to use X.264, an open source version of H.264, although this solution also had its issues. We’ll cover those on the next page, but first, let’s take a closer look at the problem. The following image is from a spec spot I shot on the RED ONE for Nintendo’s Wii:
Here’s a dark frame that I’ve used as a reference for my encoding tests. This is how this image should look on the web. Watch what happens to the background detail in the next few images.
In the Compressor-exported version the gamma is lifted, desaturating the color and making everything a bit brighter. What’s interesting is that I had to capture this still via screen capture using Apple’s Grab utility, because when I exported the frame as a still from within Quicktime the gamma on the still was correct! Apparently the boosted gamma tag does not follow a still image the way it does a Quicktime movie.
This image was corrected using the gamma filter in Compressor, set at 1.22, darkening the gamma-boosted image to emulate a gamma of 2.2. It looks almost like the original (top) image, and certainly looks a little better than the image with the boosted 1.8 gamma.
Here’s the same darkened image viewed in Firefox. The background is almost completely gone. Crushing the blacks has over-saturated the colors. What looks fine in Safari and Omniweb looks awful in the world’s most popular browser.
This is the X.264 encoded image, viewed in Firefox. It’s a considerable improvement.
So, for several months now, my web site has looked appallingly dark to anyone who viewed it using either Quicktime for Windows or Firefox, a browser that recently overtook Internet Explorer for world market share.
Needless to say I spent a lot of time over the last few days frantically trying to find a solution. Chris Meyer’s article held part of the answer and the rest I had to find out for myself. Read on, that you might spare yourself the pain that I experienced…
My first, and biggest, problem was figuring out how to export my video out of Final Cut Pro without seeing boosted gamma. In his article Chris Meyer recommends using X.264, an open source implementation of the H.264 codec that doesn’t play games with that hidden Quicktime gamma tag. I tried it out, exporting video out of Final Cut Pro via File>Export>Quicktime Conversion, and also through a preset I created in Compressor–and both showed the awful 1.8 gamma shift. Was X.264 really the answer? Was Compressor the real problem?
I exported a clip in ProRes and discovered that, when brought back into Final Cut Pro, the clip looked fine, but when viewed outside of Final Cut Pro in Quicktime Player it showed the same gamma problem. I needed an intermediate codec that retained as much image detail as possible but did not display a gamma shift. A bit of Google searching showed that others had wrestled with this issue and had settled on the Animation codec and the Photo-JPEG codec. Both retained proper gamma when exported from Final Cut Pro, which meant that further processing through X.264 via Quicktime Pro should maintain proper gamma.
And it did. Clips exported via the Animation and Photo-JPEG codecs held the proper gamma and retained more than enough detail to be re-compressed for the web. But that wasn’t the end of the story. (When it comes to post there’s always more to learn, isn’t there?)
The Animation codec is supposed to be very, very good: it’s considered a “lossless” codec, which means it will yield very large file sizes but at very high quality. As none of the projects I put on my web site are longer than 60 seconds, intermediate file size wasn’t a problem. (The largest intermediate file was 1.23 gigs for a 58 second clip.) I did have some problems with exported DVCProHD footage showing lots of jagged edges on diagonal lines, but changing the output codec to Photo-JPEG from Animation solved that problem.
The final step, encoding via X.264, was a little tricky. Read on…
The X.264 codec is known to be a little buggy. I like to encode the videos on my web site as 720×405 Quicktimes, as this seems to be a nice size for both viewing and for keeping file sizes down. I came to the 720×405 size by starting with the standard def video spec 720×480 and dividing the width (720) by 1.78 (or 16/9). The result is 404.49, and for quite a while I’ve been happily plugging 720×405 into Compressor and getting excellent results.
These stills are from some regional spots I shot a couple of years ago for Kaiser Permanente:
This is how the original 720×480 video frame looked when exported from Final Cut Pro. NTSC uses non-square pixels, so when this video clip is shown on an NTSC monitor the pixels will be stretched horizontally to an aspect ratio of 1.21:1 to yield a 16:9 frame.
Computer displays utilize square pixels for better resolution, so in order to make a non-square pixel NTSC image look proper on a computer we have to do a bit of resizing. This image was squeezed vertically to yield a proper 16:9 image at 720×405, although it could easily have been stretched the other direction to yield 853×480.
Unfortunately my 720×405 settings caused the X.264 encoder to crash. It worked fine at 720×480, and I encoded a 4:3 file at 640×480 without difficulty, so what was the problem? There had to be something about the 720×405 aspect ratio that X.264 didn’t like. But what could that be? I pulled out my calculator and, once again, divided 16 by 9, and divided that into 720. The answer was still 404.49. But: I’d been rounding up to 405; what if I rounded down to 404?
It worked perfectly. It seems that the X.264 encoder only works on video that it considers to be precisely 16:9 or 4:3, and if your calculations give you a frame size in one dimension that can be rounded up or rounded down to the nearest pixel then one value will probably work while the other won’t.
The last step was de-interlacing my NTSC footage. Compressor did a bang-up job of that, but the unwanted gamma shift Compressor added ruled it out. I didn’t quite trust X.264’s de-interlace option, so I dug around in my collection of FCP filters until I came across G Smart De-Interlace, part of Graeme Nattress’s File Effects plugin package. It worked like a charm.
Here’s a frame from some standard def footage that shows clear interlaced artifacts (horizontal lines) around the gentleman’s outline, particularly around his shirt and on his forehead.. On a TV set this kind of motion artifact isn’t an issue, but it’s very clear on computer playback.
This is the same frame cleaned up using the G Smart Interlace plugin in Final Cut Pro. It does an excellent job.
Perhaps someday Apple will deign to fix this “feature” of Quicktime, but don’t hold your breath. Meanwhile, this workaround is a little bit of a pain but it does work–and Quicktime H264, as a showreel format, is well worth it.
I’m on to Adobe Encore now. Encore will allow me to lay out a showreel DVD and then also export it as a fully functional Flash file that emulates a physical DVD, menus and all. More on that when it happens.