Producing H.264 Files on the Mac, Part 1
In celebration of MPEG-LA extending the royalty-free policy for H.264 video delivered without charge over the Internet, I thought I would devote the next few columns on producing H.264 video. Following the theme from the last few editions, I'll look at the quality produced by Apple Compressor, the free and easy alternative, and then compare it to other alternatives both free and available for fee.
In this column, I'll look at Compressor and x264, detailing the settings that I used and comparing the quality. I'll also check compatibility with my iPad and iPod, and post files that you can download yourself for performing compatibility checks or simply comparing the quality.
Next time out, I'll look at Sorenson Media Squeeze and Telestream Episode Encoder, if I can wangle an advance look at Episode 6, which will debut the MainConcept H.264 encoder in a Telestream product. If Telestream can't supply the beta, I'll substitute in HandBrake.
This series of reviews will debut a new test video, composed of clips from stock footage company Artbeats and from independent producer Connie Simmons of SimmonsArt, from her award-wining PBS series Landscapes through Time with David Dunlop. My old test tape was composed of DV, HDV, and AVCHD footage, and the footage was often shot under less than ideal conditions. I wanted to step up the quality of my starting point, and I thank both Artbeats and Simmons for supplying their high-quality clips. Since some of the source clips lacked audio, I filled in the blanks with a track from the always handy SmartSound collection.
To test the codecs, I produced a total of four test files: 640x360 and 720p for streaming, and the same resoutions for the iPod and iPad. I produced the 640x360 file at 750kbps video/32kbps audio, which are roughly the paramters used by CNN (which uses 733kbps video/62kbps mono audio). I produced the 720p at 1500kbps video and 128kbps audio, which is aggressive (YouTube publishes its 720p stream at 2Mbps) but not unheard of. To create my test files, I prescaled and pre-deinterlaced the source clips in Apple Final Cut Pro/Compressor, outputting both 640x360 and 720p test files so that no scaling would take place during encoding. I produced all compressed files in Compressor.
I produced the clips for the iPod using presets available in Compressor and the x264Encoder. I created my own presets for the iPad using both codecs, following the parameters laid out in Encoding for the iPad, Part 1.
More on the individual encoding parameters used when I discuss each encoding tool.
Apple developed the codec incorporated into Compressor (and when you encode with QuickTime Pro). Encoding controls are simple, though a bit obtuse. For example, you choose between the Main and Baseline profiles via the Frame Reordering checkbox; Main is checked, Baseline is not, and you can't producing using the High Profile. You choose between variable-bit-rate (VBR) encoding and constant-bit-rate (CBR) encoding via the Optimized for list box: Download for VBR, Streaming for CBR. Once you click Restrict to and insert a data rate, the Quality slider becomes inactive but doesn't gray out, which can be confusing.
All that said, once you know the parameters, you know them, and repeated operation is simple. I produced the 640x360 file using the encoding parameters shown above, substituting in 1500kbps for the 720p file.
By way of background, the x264 codec is an open-source codec written by multiple developers. According to an annual H.264 codec comparison produced by the University of Moscow, x264 is the highest-quality H.264 codec, though the MainConcept codec used by most encoding tools other than Compressor was only "slightly" behind x264. There are multiple open-source encoding tools based upon the x264 codec; most are command line-oriented and challenging to use. In contrast, the x264Encoder is accessed from the QuickTime interface, which makes it very easy to use.
For those who care about such things, I checked with MPEG-LA, who administers all H.264 related patents, and using the x264Encoder in this manner is completely legal and doesn't give rise to any encoder-related royalty obligation. There is no royalty on H.264-encoded video available free on the Internet, but if you're producing pay-per-view or subscription content, using the x264Encoder doesn't obviate the H.264 royalties that apply to such paid content.
You can download the x264Encoder here. Once it's installed, open Compressor's and QuickTime's Standard Video Compression Settings dialog, and choose X264Encoder in the Compression type list box, then click the Options button the lower left to access its configuration options.
Configuring the x264Encoder can be as complicated as you want it to be, with four screens of highly technical H.264 controls that you could spend hours attempting to optimize. Or you can take the coward's way out, which is what I did, and choose a preset for your encoding. To do this, click the Load preset option on the lower left of the libavcodec settings dialog.
Basically, you have two preset options: you can choose the Use Component default preset radio button, and choose one of these four presets, with the "Default" being the fast encode/fair quality option, and "Tuned" being the slow/best quality option. I took this route when I tested the iPod preset.
Or you can choose the Use Library native preset/tune radio button, choose a preset and make minor adjustments, which was the option I choose for iPad and desktop playback. Though there are 10 x264 presets (very fast, fast, very slow, placebo, etc), the notes to the encoder tell you to use either Slow, Medium or Fast, and I used Slow with minimal fine tuning, primarily to ensure that my iPad preset didn't use the High profile, and didn't exceed Level 3.1, as per Apple's specs.
The encoder release notes do a credible job detailing the functions served by the various parameters, but if you decide to freelance and start experimenting, better budget lots of time for learning the ropes and use cases.
Files created in Compressor ran fine on both my iPad and iPod Nano, and happily, the files produced with the x264Encoder ran fine as well. This isn't the gimme you'd anticipate; if you're producing files for playback on devices or integration into other environments like the QuickTime Streaming Server, x264 compatibility should be a significant concern until proven to be a nonissue.
Here's the background. I ran my first tests with x264 in March 2010, and was impressed with the quality, though several comments to the article indicated compatibility issues with the x264 codec, including with the QuickTime Streaming Server, QuickTime Broadcaster in JustinTV and some others. If you're looking to integrate x264 into different distribution channels, like JusinTV, be sure to test all the way through before cutting over to x264.
You can download all the files that I produced for these tests here, and try loading them on your own devices and systems. Let me know if you run into any problems. For more help on producing files for the iPod with the x264Encoder, check out the article here.
I'm guessing that most of you probably don't follow mixed martial arts, but perhaps you were aware of a bout this week between former heavyweight boxing champ James Toney and former UFC heavyweight/light heavyweight champion Randy Couture. For those who weren't, Couture beat Toney like a toy drum, winning in less than 4 minutes without working up a sweat, a complete domination.
Here, the x264 vs Apple comparison was kind of like that, but not quite as close. In every test at every resolution and data rate, x264 completely dominated. Starting with the lower-resolution comparisons, during talking head sequences, the differences were minor. (In all screens, the top clip was encoded with the x264 Encoder, the bottom with the Apple codec. You can view additional comparison images at all data rates here).
Add some motion to the sequences, and like the Couture/Toney battle, things quickly got ugly.
Scenes with motion caused by slow transitions were also significantly more degraded when encoded with the Apple codec.
In the 720p clip, I originally encoded at 800kbps, which was the data rate that I used for my former 720p test clip. The new test clip proved much harder to compress, completely befuddling the Apple codec, though x264 hung in. You can see that in the relatively low-motion clip in Figure 8.
In part, these results prompted me to boost the data rate for the 720p test clip to 1500kbps, where x264 continued to dominate, though the difference was usually less striking. Still, on some clips, the Apple codec sometimes fell apart completely, as you can see in the steak clip in Figure 9.
Figure 10 shows another high motion example.
Let me be clear on this point: The Apple codec can deliver great-quality video, if you have the data rate budget to spare. For example, at the 1.5Mbps data rate, the bits per pixel per frame of these test files were around .05. At the 2Mbps YouTube configuration, it's .07, still very efficient (as a rule of thumb, any value below .1 to .12 is efficient). In contrast, the iPhone 4 video distributed from Apple's website was 848x480 resolution at 24fps, but a whopping 2.581Mbps for a bits per pixel per frame of .26. Sure the video looks great, but how many viewers can play it in realtime?
With video compression, less is always more. If you can deliver the same quality with x264 at 60 percent the data rate of the Apple codec, that equals more viewers who can watch the video in realtime, 40 percent less bandwidth costs, or for videos uploaded to iTunes, 40 percent more video on the viewer's iPhone, iPad, or iPod. Basically, if you're producing video with Compressor, you should download the x264Encoder, test it throughout your distribution channel, and if no compatibility or other issues arise, strongly consider encoding with x264.
That's it for now; back in a couple of weeks with two additional Mac-based encoders.