Encoding for the Apple iPad, Part 1

Figure 1. A 720p video played on an Apple iPad is scaled down to 1024x576 with letterboxes on top and bottom.

If the Apple iPad had a tattoo, it would read, "Born to consume content." Love it or hate it, if you're a video producer on any platform, someone soon will be asking you to get your (and probably their) content onto the iPad. So that's what I'll cover over the next two issues of Final Cut Pro Insider. In this issue, I'll look at producing videos for uploading to iTunes or for personal consumption on your iPad. Next time, I'll discuss strategies for delivering via 3G and Wi-Fi. Let's jump in.

There are three ways of transferring video to the iPad: the physical cable, Wi-Fi, and 3G, with the last unavailable until early May. If high-quality video is your goal, the best scenario is transferring the video to the iPad via direct cable, since bandwidth restrictions don't apply. This would be the case if you''re encoding your own demo materials for a pitch meeting or encoding HD content for upload to iTunes. In these instances, I'll assume that the video is targeted for full-screen playback on the iPad, as opposed to video in a window. That being the case, what encoding parameters should you use to produce your video?

Well, starting with resolution, if you're producing for double-duty viewing on both the iPad and general-purpose computers, 720p (1280x720) is a good choice, since it plays well on the iPad and is the overwhelming choice of producers distributing HD TV shows on iTunes. On the other hand, if you''re primarily producing podcasts for mobile viewing, you should consider at least three other options: two high resolution and one low resolution.

To understand why, remember that the iPad's screen is 1024x768. When playing 720p video, the iPad scales it down to 1024x576 and displays black bars on the top and bottom, so any horizontal pixels beyond the 1024 are essentially a waste. This is shown in Figure 1, a 720p podcast from the hit show Glee.

So the first option is encoding your videos at 1024x576, which has 36 percent fewer pixels than 720p, which should translate to identical quality at 64 percent of the file size, and 64 percent of the download time for files downloaded from iTunes. The second option is 960x540, which is the resolution that iTunes uses if you choose a video and click Advanced > Create iPad or AppleTV version.

The third option is 640x360, which came into the picture courtesy of an email I received from a buddy who went to NAB this year. A few days earlier, I had asked his advice about encoding for the iPad. Here's a message he sent from Vegas.

"We had a good meeting with some Apple folks today, including the technical marketing manager, Mac OS X - QuickTime. He pointed me to a new technical note that he just published on encoding content for distribution the iPhone and iPad.

"I remembered that you were looking for some recommendations here, and apparently he has done a lot of testing to come up with these best practices. He said the iPad scaler is so good that sending content at higher res than 640x360 just isn''t worth the bandwidth."

In addition to saving space and download time, a 640x360 video will also play in the iPhone and iPod touch, as well as many older iPods, as long as you encode using the Baseline profile. So this idea has some nice appeal.

Figure 2. Video encoded at 1024x576, 960x540, and 640x360, then played on the iPad.

So what resolution makes the most sense? My first thought was to check iTunes and see what resolution most producers were using. I quickly saw that while 720p predominated, 960x540 was used by about 10 percent of the videos that I checked. I found no videos produced at 1024x576; not shocking since the iPad is so new, but clearly not a mandate. There were a gazillion videos produced at 640x360, though obviously none were the HD section that I was checking.

Next I decided to run some visual tests: first with a general-purpose test video, and second with a news video that included scanned newspaper text. Specifically, starting with the same source video, I produced three iPad versions at the three resolutions, encoding at a data rate sufficient to ensure the lack of encoding artifacts in all of them. Then I played the videos back on the iPad, paused the video on the same frame, and shot a picture of the video with a digital camera. Definitely not the most sophisticated of tests, but the results were illuminating.

Related Links

A Coming War Over Web Video? You could hear the jeers the instant Apple introduced its iPad last week. It was a common refrain: "No Flash support? What's the point?"... The Future of Web Video, Part 1 I admit that the nexus is a bit tenuous, but if you're an Apple Final Cut Pro producer, you're undoubtedly producing for the Web. Over the past few months, you've been hearing that Flash is going away, H.264 is going away, and soon you'll have to produce all your video in an open-source video codec... Adobe Creative Suite 5 First Look Today, Adobe revealed Creative Suite 5 (CS5). Like many members of the press, I've been working with beta software for about three months, and I am very familiar with the additions to Premiere Pro, OnLocation, Media Encoder, and a couple of ancillary programs...

With the first video, I found that the Apple marketing manager was right: The lower-resolution video scaled to full-screen playback was almost indistinguishable from the high-resolution video. On the other hand, the newspaper text was a different story (har, har), as you can see in Figure 2.

As you would expect, you see the biggest difference is between the 640x360 video and the other two. Clearly, if your videos contain significant fine detail, you need to encode at one of the two HD resolutions. If you click the photo and view it at full resolution, you'll see that the 1024x576 version is slightly more crisp than the 960x540—again expected, because the larger version is displayed at its native resolution, while the 960x540 version is scaled slightly. The iPad's scaling capabilities may be awesome, but scaling always degrades quality to some degree.

To summarize, if you're producing for joint playback on the iPad and computer, encode at 720p. Going forward, when I'm producing podcasts or video bound for playback on the iPad, I'll produce at 1024x576, though the more conventional path is 960x540, and I wouldn't blame you for choosing that route.

If your source video is talking head or similar footage with very little detail, you might try producing at 640x360 and comparing that quality to either of the HD encoding resolutions; you'll be surprised how little difference you'll notice, and you'll cut your encoding and administrative load and save download time and disc space for your viewers. On the other hand, if there's lots of text or other fine detail, it's going to look pretty mangled if you encode at 640x360 and display at 1024x576 display on the iPad.

Table 1. Producing podcasts for iPad viewing.

That's the resolution; what about the rest of the encoding parameters? Well, since Apple iTunes encoded the 960x540 file specifically for the iPad, that's the best indicator of what Apple thinks are the ideal iPad encoding parameters, so let's start there. Note that I collect all encoding options in Table 1, so don't feel that you need to take notes along the way.

I should also say that all encoding tools present these parameters in a slightly different way, and some present some parameters and not others. If you're familiar with your encoding tool, you should be able to figure things out.

Figure 3. The file iTunes rendered when I clicked Advanced > Create iPad or Apple TV version.

To identify the parameters used by Apple, I analyzed the iTunes-created file in MediaInfo, a free video-analysis utility, and show the money screen in Figure 3. First up is the Profile and Level, which should be the Main Profile at no higher than Level 3.1. The Advanced Video Codec is another name for the prescribed H.264; no problem there.

The next option is format settings, context-adaptive binary arithmetic coding (CABAC). It's no surprise that iTunes didn't enable CABAC entropy encoding, since it's not an option on any Apple encoding tool, but I use CABAC encoding for all my H.264 encodes that aren't bound for the iPod (which uses the Baseline profile that doesn't offer CABAC entropy encoding). During the course of my testing, I loaded CABAC encoded test files on the iPad, and they loaded and played with no problem.

In theory, CABAC delivers about 15 percent higher quality than the alternative, context-adaptive variable-length coding (CAVLC), but at these high data rates, you probably wouldn't notice the difference. If you're a conformist, go with CABAC off (or choose the CAVLC option); if you're seeking the very best quality at the selected file size, enable CABAC.

MediaInfo also shows that iTunes encoded with variable-bit-rate (VBR) encoding rather than constant-bit-rate (CBR), which makes sense for a file transferred via cable rather than via wireless. If you're encoding for iTunes or your own use, use VBR.

Next up is the video data rate of 3,627kbps, which is almost certainly higher than you need. At 960x540, I would start at 2,500kbps, which should produce very high-quality video, and only increase the data rate if quality is sub-par. Since 1024x576, which is about 14 percent larger than 960x540, I would start at 2.8Mbps.

I'll note for the record that iTunes didn't change the frame rate of my test file to 24fps; it left it at 29.97fps. For this type of encode, I would always use the native frame rate of the video.

Figure 4. A frame-rate graph from Inlet Technologies Semaphore.

The frame-rate graph from Inlet Technologies Semaphore shown in Figure 4 illustrates the VBR encoding discussed above. It shows lower data rates during the start of this test clip, which begins with 30 seconds of low-motion talking head footage, then higher data rates for the higher-motion content that follows. The graph also reveals that key frames, which are those red vertical lines beneath the time scale, are spaced about one every 3 seconds (or every 90 frames in this 29.97fps video). The irregular keyframes are those inserted at scene changes, a technique that improves overall quality. To enable this in your encoding tool, make sure that the "Insert keyframe at scene change" option, or "Natural" keyframe option, is checked or otherwise enabled.

Paging through the file in Semaphore revealed that Apple inserts one B frame between P and I frames, so set your B frame interval to 1, with two reference frames, a parameter revealed in both MediaInfo and Semaphore.

Related Links

Encoding for the Apple iPad, Part 2 Last time out, I detailed how to produce videos transferred to the Apple iPad via cable, whether directly in your office or uploaded via iTunes. This time, I'll discuss how to encode files for delivering via Wi-Fi or 3G...

For audio, iTunes produced stereo audio using the Advanced Audio Codec (AAC) Low Complexity (LC) profile, with a data rate of 128kbps and a sampling rate of 44.1kHz. Most encoding tools don't let you choose between VBR and CBR for audio, but if they do, note that iTunes used CBR.

If you chose the 640x360 option, I would start at around 1.4Mbps, which should produce pristine quality. Use the Baseline profile if you want the file to run on other devices like the iPhone and iPod Touch, which takes CABAC and B-frames out of the picture because they're not supported under the Baseline profile. Otherwise, follow the recommendations in the table.

The third column shows the collective stats from the 720p files that I downloaded from iTunes for your reference. Note that I couldn't load any of the files into Semaphore, probably because they were encoded with the Apple digital-rights-management technology. Note also that MediaInfo reported that all the TV shows were produced using the High Profile, but I'm guessing that this relates to the DRM as well.

As a final thought, after producing your files, test, test, and then test again. It's a new platform for all of us, and we're bound to collectively make some mistakes.

That's it for this episode; I'll be back in a couple of weeks to discuss producing for Wi-Fi and 3G delivery.