Social Links
  • Real World Video Compression
    Real World Video Compression
    by Andy Beach
Powered by Squarespace
« Details on iPhone 4 video | Main | What Video Codec does iPhone's FaceTime use? »
Monday
Jun142010

Encoding for the iPad pt 1

Before I get started, I'd like to give ArtBeats a big shout out and a thanks for providing me with the clips I used to test these settings.  Normally I drop their logo into the clips i'm encoding, but sense I didn't want that effecting my tests, I left it off for this round.  I encourage you to check out ArtBeats for all your stock footage needs.

I've now had an iPad for a few weeks, so i've had a chance to play a variety of videos back on it. It truly is a pleasure to watch video on and I could see that being especially popular on long road trips with the kids (or as I'll likely use it, watching movies in bed).   I've seen some guidelines for encoding for the iPad already (most recently from Ken Stone's site), but I wanted to tackle the problem myself to see what settings I felt worked best. I had a couple of goals with my testing:

1) Best General Settings for iPad - I wanted to figure out for myself what I thought the best encoding guidelines for the iPad should be.

2) How effective are advanced settings? Do the advanced settings for H.264 (that you can access through the x264 plugin and apps like HandBrake) improve the quality and not ruin the battery life (often time tools that improve the quality do it at a processor sacrifice).

3) Does HD source differ from SD source? I'm assuming HD might require slightly different settings than SD, but I want to see if that bears out.

Methodology


So with these goals in mind, I set out to encode a variety of resolutions and data rates from one of my test clips. I chose the hardest clip I had, as I figured if it looked even remotely decent with it, then it wold look great for anything else. In addition to my settings, I did encodes using both QuickTime 7 and QuickTime X's default settings for the iPhone and AppleTV as I figured both are getting used by people to encode for the iPad. I've pulled PNG frames from each encode for comparison and posted to Flickr (check the original images for true comparisons) and below is a table outlining the resolutions and data rates of each encode I tried.

Resolutions

I focused my tests around three primary resolutions - 960x540, 854x480, and 640x360. The iPad's screen resolution is 1024 x 768, so i could have thrown in a 1024 x 576 (the appropriate resolution for wide screen content at the iPads full width) however i figured this would be overkill plus its a bit of an oddball size, so i stuck with resolutions i'm familiar with. 540p is common as a "nearly" HD option that became quite popular when the Apple TV came out (this is the resolution it plays back for 30fps content). 360p is the cropped standard definition widescreen option and 480p is a nice in between option.

Data Rates

To choose data rates, I started with the 540p resolution and targets what i thought was a pretty high data rate (3.25 Mbps or 3250 Kbps) then reduced it by approximately 1/3 to get a lower end comparison. To determine the appropriate data rate for each additional resolution I divided my total picture pixel count by the data rate, then multiplied this value by the total pixel count of the other resolutions. Make sense? Well, here's quick excel formula to help explain it:

 

ExcelMatch.jpg

 

Why did I bother doing this?  I wanted to make sure I was devoting about the same amount of kilobits per second to the video at each resolution - in other words, i didnt want to have one resolution have too little or too much, because then it would be harder to tell how it was doing in comparison to the others.  Of course, I just used this as a rough guideline - I then rounded and reduced the rates where i thought appropriate - this was just to give me a range for each resolution that seemed an appropriate starting point.

For each resolution I was trying out, I also chose the auto setting in the QuickTime Export panel to see how much data the encoder thought was needed to do the clip justice — now I knew this would be a high number (like I said, this is an aggressive clip), but I wanted a sense of how much lower I was setting it.

 

EncodeTable.jpg

 

Results

After watching all the clips, I more or less settled on 480p at 1900kbps as the setting i thought did the best job of balancing quality.  Sure, I could throw more bits at it per second, but the quality/file size trade off seemed to really settle right about here. And while I liked the way the 360p clips looked,  I thought with this content, the 480p held up just slightly better.  Next, I encoded a range of HD clips to this setting just to see how it held up to a variety of types of video content (screenshots here).  With the exception of a few super high motion clips, it held up fine.  I used the same settings I outlined in my recent post (more or less) for the recent x264 post, but here's a link to the screens in case you need reminding.  If you want to try these out for yourself, hop over to MyComet's website to get the latest x264 QuickTime plugin, follow my instructions here for how to set up, then use these settings:

 

But Wait, There's More!

But all of this really only answers question number one for me - I still wasn't sure if the advanced settings really made that big a difference, or if SD and HD content deserved separate settings.  So, I have more testing to do - tune in later this week for comparisons of HD and SD content encoded with these settings, plus some side by side comparisons to the default H.264 encoder (as well as some more conversation about the default settings from both QuickTime 7 and QuickTime X).

EmailEmail Article to Friend

Reader Comments (3)

Very interesting stuff here. Honestly all of this encoding stuff has been over my head but I've already learned a lot from this blog. By the way, I found this blog after you appeared on a Pixelcorps episode. Cheers!

June 14, 2010 | Unregistered CommenterMichael

Thanks for giving us some insight into your workflow and thought process. It's always helpful to watch a pro think through an issue! Looking forward to the second part.

June 24, 2010 | Unregistered CommenterKirby

Actually, 1024x576 is NOT an oddball size for non-NTSC users. If you take standard widescreen PAL and convert to square pixels it's exactly... 1024x576!

So if you're in a PAL area, shoot SD in progressive for perfect 1:1 pixel mapping.

I just hope the next iPad will be 1280x720....

September 15, 2010 | Unregistered CommenterMatt Davis

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>