There are three ways of transferring video to the iPad: the physical cable, Wi-Fi and 3G. 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?
Starting with resolution, if you're producing for double-duty viewing on both the iPad and general-purpose computers, 720p (1280 × 720) is a good choice. 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, consider at least three other options: two high resolution and one low resolution.
Remember that the iPad's screen is 1024 × 768. When playing 720p video, the iPad scales it down to 1024 × 576 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 1024 × 576, which has 36 percent fewer pixels than 720p. This 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 960 × 540, which is the resolution that iTunes uses if you choose a video and click Advanced > Create iPad or AppleTV version.
The third option is 640 × 360, which came into the picture courtesy of an e-mail I received from a buddy who went to the 2010 NAB Show. A few days earlier, I had asked his advice about encoding for the iPad. While at NAB, he met with Apple's technical marketing manager, Mac OS X - QuickTime, who pointed him to a new technical note that he just published on encoding content for distribution to the iPhone and iPad. He said the iPad scaler is so good that sending content at higher res than 640 × 360 just isn't worth the bandwidth. In addition to saving space and download time, a 640 × 360 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.
Grading the options
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, 960 × 540 was used by about 10 percent of the videos that I checked. I found no videos produced at 1024 × 576; this is not shocking since the iPad is so new, but clearly not a mandate. There were a several videos produced at 640 × 360, 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. This is definitely not the most sophisticated of tests, but the results were illuminating.
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, as you can see in Figure 2 on page 52.
Create iPad or Apple TV version.
Select figure to enlarge."/>
As expected, the biggest difference is between the 640 × 360 video and the other two. If your videos contain significant fine detail, you need to encode at one of the two HD resolutions. The 1024 × 576 version is slightly more crisp than the 960 × 540 — again expected because the larger version is displayed at its native resolution, while the 960 × 540 version is scaled slightly. The iPad's scaling capabilities may be awesome, but scaling always degrades quality to some degree.
So, 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 1024 × 576, though the more conventional path is 960 × 540.
If your source video is a talking head or similar footage with very little detail, you might try producing at 640 × 360 and comparing that quality to either of the HD encoding resolutions; you'll be surprised at how little difference you'll notice, you'll cut your encoding and administrative load, and you'll save download time and disc space for your viewers. On the other hand, if there is a lot of text or other fine detail, it's going to look pretty mangled if you encode at 640 × 360 and display at 1024 × 576 display on the iPad.
Continue on next page
Other encoding parameters
Because Apple iTunes encoded the 960 × 540 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.
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 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 3627kb/s, which is almost certainly higher than you need. At 960 × 540, I would start at 2500kb/s, which should produce very high-quality video, and only increase the data rate if quality is subpar. Since 1024 × 576 is about 14 percent larger than 960 × 540, I would start at 2.8Mb/s.
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.
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, and 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 per every three 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.
For audio, iTunes produced stereo audio using the Advanced Audio Codec (AAC) Low Complexity (LC) profile, with a data rate of 128kb/s 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 640 × 360 option, I would start at around 1.4Mb/s, 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.
Jan Ozer is owner of Doceo Publishing and a contributor to Broadcast Engineering's sister website, Digital Content Producer.
