How to Produce High-Quality H.264 Video Files
It's time for an H.264 tune-up. Lean how choose the right encoding tool and optimize H.264 encodes for ideal quality and device compatibility.
Learn more about the companies mentioned in this article in the Sourcebook:
H.264 is the only compression technology that plays on all computers, mobile devices, and OTT players. This makes producing high-quality H.264 files compatible with your target playback devices an essential skill. Helping you acquire and/ or polish this skill is the focus of this article.
We’ll start with the compatibility element, since if the file won’t play on your target devices, it really doesn’t matter how good the quality is. Then we’ll tackle the resolution, frame rate, and data rate of your encoded file, since if you get these wrong, fussing with the H.264 encoding parameters of your file also won’t matter. Then we’ll cover choosing the right encoding tool and H.264 codec and how to quickly tune x264 encoding parameters for an optimal quality file.
The most fundamental H.264-related encoding parameters are profiles and levels. Briefly, the profile controls which encoding algorithms and techniques are used when producing the encoded file. The Baseline profile produces a file that can be played back on devices with minimal CPU and memory, while the High profile uses the most advanced techniques and requires a more powerful playback platform. Most encoding tools provide a simple control for choosing the profile, such as that shown in Figure 1 (from Telestream Episode).
Figure 1. Choosing the profile in Telestream Episode
Profiles were established in the H.264 standard to allow device manufacturers to support H.264 playback with an inexpensive, power-efficient configuration, such as that used in the original video-capable iPods, which could only play H.264 video encoded using the Baseline profile. At the other end of the spectrum, computers manufactured in the last 5 or 6 years and all OTT devices can play video encoded using the High profile.
To enable even more precise targeting of playback capabilities, levels set maximums for parameters such as resolution and data rate within each profile. This is shown in Table 1, which shows the profiles and levels supported by all video-capable Apple devices. In the first column, you can see that the original iPod, through version 5g, could only play video encoded using the Baseline profile to Level 1.3, which meant 320x240 resolution at 30 fps at a maximum data rate of 768 kbps. In contrast, as with computers and OTT devices, the newest Apple devices can play pretty much any file you would care to throw at it.
Table 1. Playback capabilities of Apple devices
Looking at the second column from the left, if you want your video to play on version 4 or lower iPhones, you need to produce these streams using the Baseline profile at a maximum configuration of 640x480x30fps at 2.5Mbps. In fact, in Technical Note TN2224, Apple’s seminal reference on producing HTTP Live Streaming (HLS) adaptive files for iDevice delivery, Apple recommends encoding all 640x360 streams and smaller using the Baseline profile, with higher resolution files encoded using the Main and High profiles. Note that as part of the HLS specification, devices check the stream configuration before retrieving a file, so they won’t attempt to retrieve a file that they can’t play.
Unfortunately, the breadth of Android manufacturers makes consolidating playback capabilities into a table like Table 1 nearly impossible. Instead, Google guarantees that each Android device will play a 480x360x30fps file encoded at 500Kbps without the H.264 playback hardware acceleration that most devices supply. In other words, while most recent Android devices are capable of playing back files encoded using the Main and High profiles, Google can’t guarantee this. In fact, Google’s Supported Media Formats document states that 1280x720x 30fps video encoded at 2Mbps using the Baseline profile will not play on all Android devices.
For this reason, when producing a single file for Android delivery, most sources recommend encoding at the maximum supported configuration (480x360x30 fps @ 500Kbps, Baseline Profile). Since Android versions 3.0 and above support HLS playback, you can use the Apple schema presented in TN2224 to efficiently deliver to those Android devices as well. That is, so long as you encode at least one stream at 480x360x30fps at 500Kbps using the Baseline profile, you’ll have one stream for Android devices to play, and using the HLS protocols, the Android device will be able to retrieve any higher-quality file that it can play.
The bottom line? If producing a single file for mobile playback, you should use the Baseline profile to ensure universal playback. If producing an adaptive group of files for mobile playback, you should encode the lower-resolution files using the Baseline profile, and the recommendations Apple provides in TN2224 are a great place to start.
This raises a larger question: If you do produce files using the Baseline profile for mobile playback, should you also create files using High profile exclusively for computer and OTT playback to provide the highest possible quality? In my experience, the qualitative difference between files encoded using the High and Baseline profile is often less than you might think. For this reason, you should compare the quality of files encoded using the High and Baseline profiles to make sure the additional encoding cycles are worth the effort.
Configuring Your Files
Once you’ve ensured compatibility, it’s time to shift your focus to quality. The most critical element here is the configuration of your video file(s); specifically the resolution, frame rate, and data rate. Get these wrong and your file will look awful, even if all other encoding options are perfect.
By way of background, as with all streaming-video codecs, H.264 is a lossy codec, which means the more you compress the video file, the more quality you lose. How do you ensure that you don’t over-compress your video? By monitoring a metric called bits per pixel.
Briefly, bits per pixel is the amount of data applied to each pixel in the file. The formula is the per-second data rate, divided by the number of pixels per second, which you compute by multiplying the width times the resolution times the frame rate (data rate/width x height x frame rate). For example, suppose you encoded a 640x360x30 fps file at 800Kbps. The bits per pixel would be 0.116, calculated by dividing 800,000/(640x360x360), or 800,000/6,912,000. Alternately, you could just load the file into MediaInfo, and let the free, cross-platform tool compute the bits per pixel for you (Figure 2), as well as provide a bunch of other meaningful encoding details.
Figure 2. Choosing the profile in Telestream Episode
At 640x360x30 fps, most producers use a data rate of around 700Kbps to 1Mbps, which delivers a bits-per-pixel value of between 0.1 and 0.15. At the upper end of the scale, ESPN encodes its high-motion sports content at 1.4Mbps, or 0.203 bits per pixel. If your video is blocky, pixelated, and full of artifacts, and you’re encoding at a bits-per-pixel value of 0.1 or below, raise your data rate to bring quality into line. If your bits-per-pixel value exceeds 0.2, there’s a good chance you could produce visually similar results at a much lower data rate, saving bandwidth costs and enabling delivery to mobile devices. Try encoding at a lower data rate and see.
Because codecs are more efficient at higher resolutions, the bits-per-pixel value necessary to maintain equivalent quality drops as frame sizes increase. For example, in their 720p stream, ESPN encodes at 2.8Mbps, or 0.102 bits per pixel, about half the bits-per-pixel value used for 640x360 files. The mathematical representation of this increased efficiency is quantified in the Power of .75 rule, which involves fractional exponents and is beyond my ability to verbally explain. You can read more on this.
For the purposes of this article, just understand that as resolutions increase, the bits-per-pixel value required to deliver equivalent quality drops. As a guide, consider the data in Table 2, from my book Producing Streaming Video for Multiple Screen Delivery, which shows data rates at the resolutions and bits-per-pixel values shown, all at 29.97 fps. The red squares suggest the appropriate data rate for each resolution, which as you can see, drops in bits-per-pixel value as resolutions increase. Again, if your data rates are much lower than those shown and the quality doesn’t cut it, boost the data rate until quality is sufficient. If your data rates are much higher, experiment with lower data rates to see if you can produce a lower-data rate stream that looks the same but is more efficient and cost-effective.
Table 2. Recommended data rates at various video configurations
Choose the Right Encoding Tool
Once you get the profile and configuration right, it’s time to start honing in on H.264-specific parameters. The sheer number of streaming professionals using Final Cut Pro X (FCPX) guarantees that quite a few producers are encoding with FCPX’s companion product, Apple’s Compressor. Though Compressor itself is capable, the stock Apple H.264 codec included in the product is very subpar.
By way of background, H.264 is a standard, so unlike proprietary codecs such as On2’s VP6 or Microsoft’s Windows Media Video codecs, multiple parties can create their own codecs. As you’ll see, MainConcept, a German subsidiary of Rovi Corp. (formerly Macrovision), has produced an H.264 codec used in many premium encoding tools, while the open-source x264 codec is also widely supported. Apple created one of the first H.264 codecs, which was competitive in its day. However, since then, other developers have optimized their H.264 codecs, while Apple, presumably focusing on more profitable segments, let its codec languish, and its quality is now uncompetitive.
Or, What I Learned During My HEVC Presentation at Streaming Media West
A look behind H.264, the world's most popular video codec, including encoding parameters and royalty concerns
Today's video encoders are mostly similar and mostly good, said Robert Reinhardt at Streaming Media East. Still, there are a few features to seek out.
The news is good for content owners and not so good for encoding/decoding vendors, but gives everyone a feel for how the issue will play out.
FFmpeg might be a free download, but there's still a cost that goes with it. Robert Reinhardt explains why this encoder isn't right for every company.
Reaching viewers on desktops, notebooks, phones, tablets, and set-top boxes all starts with the same step: Encoding video into H.264.