Producing H.264 Video
For this reason, I recommend using B-frames when the profile supports it. As shown in Figure 6, from Telestream Episode Pro, typical B-frame-related parameters include the number of B-frames and number of reference frames. The number of B-frames is the number of B-frames in sequence between I- and P-frames. So at a setting of 3, the frame sequence would be IBBBPBBBPBBB ... and so on until the next I-frame.
The number of reference frames is the number of frames searched for interframe redundancies. Here you balance encoding time against the potential for quality improvement, since searching for these redundancies takes time. In most videos, redundancies occur most frequently in the frames immediately surrounding the frame being encoded, so reference frame values higher than three to five typically provide little additional quality. Figure 6 shows the settings I use and recommend for most encodings, a B-frame setting of 3 with three reference frames.
Search Parameters
Episode Pro and Squeeze also let you balance encoding time against quality: Episode Pro with an encoding speed versus quality slider with values that range from 10 to 100, and Squeeze with a Fast, Medium and Best list box. The Episode Pro help file has a good explanation of what's going on here, so let's quote:
Encoding speed vs. quality. The H.264 encoder has a wide range of encoding methods to use, which may result in a
very time consuming encoding process.
"The Encoding speed vs. quality setting determines the complexity of the encoding by switching on or off different tools. Encoding speed vs. quality can be set between 10 and 100; 10 represents the fastest speed, with most of the advanced features turned off, 100 represents the most advanced coding mode, yielding the best quality, but also taking a considerably longer time. In general, values over 50 yield very small improvements in visible image quality."
In terms of variations in encoding time and quality, your mileage will vary based upon content and target encoding parameters. With Episode Pro, I've seen very little difference in either encoding time or quality at the extremes of the encoding speed or quality slider. Still, I typically set the slider at 100 since my encoding volume is low. If you're a high-volume shop, run your own comparatives and see if the quality and encoding time varies significantly. With Squeeze, I always use the Best setting, which takes about 25% longer than Fast, but it produces noticeably better quality.
Slices
The final H.264 encoding parameter that I'll address is slices, which is available in both Squeeze and Episode Pro. This parameter divides each frame into slices and assigns a different CPU to each slice, speeding encoding on multiple processor systems. The only downside is that slices can't refer to each other during encoding, so if a bouncing ball moves from one slice to another during the course of the video, the encoder won't pick this up as a redundancy. Again, since I'm
a low volume shop, I always set slices at the minimum value, but your results may vary.
These are the H.264 basics; now let's touch on encoding for devices and computers.
Producing for Devices
If you're producing for devices, job No. 1 is to check the manufacturer specs and make sure your encoding parameters don't exceed them. If you use a template supplied by your encoding tool, you should compare the values against
the manufacturer's specs. I'm sure that most templates will conform, but it is your file.
After encoding, test your file on the target device or, if applicable, a range of devices. About 2 years ago, I downloaded 50 files from iTunes and tried to load them on my iPod nano. Six wouldn't load, with mistakes ranging from wrong profile to exceeding the recommended data rate and resolution to one producer using the Sorenson Video 3 codec, which won't play on the iPod. Mistakes happen, but all these would have been caught had the producer simply tried to load the file onto the target device.
When producing for devices, remember that you have to adjust your encoding parameters to match your delivery scheme as well as the playback specs of your target. For example, while the iPad can play a 720p file encoded at up to 14Mbps, delivering that file via cellular or even Wi-Fi might be a touch impractical. That's why most producers streaming to the iPad configure their videos in the 640x360 range, with data rates well under 1Mbps.
When producing for mobile devices, using an adaptive strategy is critical to satisfying customers connecting via different technologies and speeds. Here, Apple has both a technology advantage, with HTTP Live Streaming designed specifically for its family of devices and a documentation advantage, with a tech note available at http://developer.apple.com/iphone/library/technotes/tn2010/tn2224.html# detailing suggested configurations for iPads and iPhones. For an introduction to HTTP Live Streaming, try this article: http://digital contentproducer.com/videoencodvd/revfeat/streaming_iphone_1117/index2.html, or Google "Jan Ozer" and "HTTP Live Streaming."
Producing for Computers
If you're producing for computers, beyond the configuration options discussed previously, choosing the resolution and data rate of your files is the most important consideration. If you're producing a single file, SD configurations of H.264 (640x480 or 640x360) play well on computers as old as my HP Workstation xw4100, which I got in 2003 and which has a 3GHz Pentium 4 CPU with Hyper-Threading Technology.
Jump to 720p, however, and the required CPU playback horsepower increases significantly, running the risk of frames dropping during playback. As a very general rule of thumb, if you're producing at 720p, the minimum target platform that can play these files at or below 50% CPU utilisation are Core 2 Duo-based computers.
Again, the best way to serve a range of target viewers with varying CPU and connection speeds is by offering multiple files, preferably via an adaptive streaming technology such as Adaptive Streaming or Dynamic Streaming, since Apple's HTTP Live Streaming is pretty much limited to Apple devices. If this isn't in the cards, consider the movie trailer strategy, where you offer multiple files and let the viewer decide which to watch. That way, if the video stops during playback, the viewer blames his computer or internet connection, not your encoding strategy.