H.264 in a Mobile World: Adios to the Main and High Profiles?

Now that mobile devices are such an important target for most producers, does it make sense to start encoding all H.264 footage using the Baseline profile? From the tests that I performed this week, encoding all footage using this profile might save encoding and storage resources with minimal loss in quality.

Gosh, it's hard to remember a time when we weren't using the H.264 codec, but I guess it's been since at least 2007, with many producers starting before then. When I first started working with H.264, I remember running comparisons, and finding files encoded using the Main and High profiles clearly superior to Baseline. So the general rule quickly became to encode using the High profile for computer playback, and the Baseline profile for mobile, a dichotomy that continues until today.

Recently, I worked with a client encoding SD video for web delivery. His application was continuing education, and in addition to adaptive streaming he was offering a single file for download and local playback on computers, tablets, mobile phones and other devices. He asked whether he should encode this file using the Baseline profile, which would maximize compatibility, or the High profile, which would optimize quality. 

This is important because while computers and many devices can play files encoded using the Main or High profile, many devices can't, including all pre-iPhone 4S Apple phones and iPod touches. For example, if you check Google's recommendations for Android devices here, you'll see that Google still recommends the Baseline profile, even for 720p video encoded at 2 mbps. And while Apple is very specific about which profiles their devices will play, most other vendors aren't, stating that their devices play H.264, but not specifying which profile. So the Baseline profile is clearly the safest approach. 

While the client could certainly produce two files using both profiles, this would cost him both encoding cycles and storage space.

Does the Main Profile Produce Higher Quality than Baseline?

So the obvious question was, did the High profile produce superior quality to the Baseline profile using his encoding parameters, which were 640x480x29.97@1 mbps. In theory, of course, the High profile should produce better quality because it uses more sophisticated encoding techniques than the Baseline profile, like B-frames and CABAC entropy coding.

To answer the client's question, I produced two files to these targets, one using the Baseline profile, the other the High profile. While Adobe Media Encoder doesn't let you manually control B-frame settings or entropy coding, when you choose the High profile, it enables CABAC and B-frames with an interval of two (and three reference frames. The quality was pretty much identical. 

So, I ran several tests using three encoding configurations parameters and three software encoders. If you want to skip the commentary and look at the files themselves, I've posted them all here. The bottom line was that I found a noticeable difference in only one sequence in four sets of tests, and that was at the most aggressive compression settings, 640x360x29.97 @ 240 kbps.

Here are some screenshots from the various tests; check out the files and see for yourself. The screens represent the most challenging frames in each test file, which is why there is some repetition. 

Adobe Media Encoder - 640x480x29.97 @ 500 kbps 

This was half the data rate used by the client, with a bits per pixel value of .54 (in contrast, CNN usually publishes at a bits per pixel value of .1 or higher). On these demanding frames, I could see no commercially relevant difference. Click each picture to view it in full resolution in another browser window, or click here to play the videos. 

BvMvHx500kbps_skate 2.png

BvMvHx500kbps_alex.png

Squeeze - 640x480x29.97 @ 500 kbps x264 codec

I wanted to make sure that the results weren't codec or encoder specific, so I tried encoding with Sorenson Squeeze using the x264 codec, with B-frames enabled (interval of three, with five reference frames), CABAC and otherwise tuning the preset for top quality. Same result; I saw very little difference between the files; nothing that would convince me that I needed to encode one set for computers using the High profile, and one for devices using Baseline. 

Squeeze_SD_pitan.png

 

Squeeze_SD_Skate2.png

AME - 1280x720x29.97 @ 800 kbps x264 codec

Back with the Adobe Media Encoder, I tested using my HD test file and standard HD encoding parameters. Here the bits per pixel value was a very low .029. Here, I saw very little difference between the Baseline, Main and High-encoded clips, and certainly no differences that would convince me to encode multiple files to serve different targets. 

AME_HD_Beth.png

AME_HD_Jenna.png

Carbon Coder - 640x360x29.97 @ 240 kbps 

This configuration is from an adaptive set that I helped configure for a major three-letter network, so it's live and in use today. While the bits-per-pixel value of .035 is higher than the 720p configuration above, it's actually a more aggressive configuration because H.264 works more efficiently at higher resolutions. When encoding with the High profile in Carbon Coder, I used a B-frame interval of three, five reference frames, CABAC and otherwise tuned the preset for maximum quality.

This is the only configuration where I saw any noticeable difference in quality, and only in one sequence. Check out the window to the dancer's right; that's where it's most obvious. 

Rhozet_Jenna.png

The Takeaway

So what to takeaway from all this? Some observations:

  • Your mileage certainly may vary based upon source footage, encoding configuration and encoding tool. 
  • However, before assuming that you need two different files encoded using different profiles to optimize quality for different target platforms, run your own tests, and see if there's a difference. 

Should you stop using the Main and High profiles altogether? That's a more interesting question that I'll consider after mulling over these results and perhaps running some additional tests. Clearly, the qualitative differences between the profiles is significantly less than it was when I first started working with H.264. Since files encoded using the Main and High profiles play in fewer places than Baseline encoded files, the lack of qualitative differentiation lessons the incentive to use those less-compatible profiles. 

Again, you can check out the files yourself here. If you disagree with my findings, I'd love to see the results of your tests that disprove these, complete with details about encoder and file configurations and such. I'd also love to see the encoded files. 


Comments (8)

SnoiD
Said this on 4-19-2012 At 11:24 am

Interesting reflexion.

 

First we can already see difference between 2 encoders with these photo :
http://www.streaminglearningcenter.com/images/BvMv...
http://www.streaminglearningcenter.com/images/Sque...

And inside those capture I can see differences between Main/High profile so i think you overacting a little when you say :

This was half the data rate used by the client, with a bits per pixel value of .54 (in contrast, CNN usually publishes at a bits per pixel value of .1 or higher). On these demanding frames, I could see no difference.

;)

The difference is short in term of quality but it's present, it justify to encode & storage 2 files ? .... the client choice :)

Said this on 4-19-2012 At 11:34 am
OK, there is a slight difference in the AME clips, good point, but I could see none in the Squeeze x264 clips. Plus, the client's clips were talking heads, with very little motion or detail, so should show even less of a difference.

I was very surprised to see such minor differences; given the mobile compatibility issues raised by files encoded using the Main/High profile. Be interesting to see if others report the same thing.

Thanks for weighing in.

Jan
SnoiD
Said this on 4-19-2012 At 04:38 pm

The difference I can see :

http://img11.hostingpics.net/pics/690159SqueezeSDS...

For me, not awesome but more clean.

Said this on 4-19-2012 At 07:30 pm

Yeah, agreed. Again, extremely high motion/high detail at half the bits per pixel of CNN, so it's a pretty aggressive use case. More importantly, not the kind of thing anyone would notice without side by side comparisons which viewers never have.

Thanks for having a look, though. Sure wish the difference was more noticeable.

:-)

 

 

andrei ka
Said this on 4-23-2012 At 09:45 am

- i though one of the *big* reasons to choose baseline by google/apple & likes was no royalties to pay (now & later) ;

-  guess in the south korea or in the metropolian areas in te US you can always pull 1Mbps via 3g, but i wish i could get real stats from some major european telco about bitrates ppl get on today's mobile networks (e.g. i'm from france), to see if it still closer to say, 500-600Kbps and if it's the case the best compression w/ higher profiles might be still desirable

Jan
Said this on 4-23-2012 At 10:03 am
Don't think there are any royalty implications; it's either H.264 or its not.

Have you seen http://www.akamai.com/stateoftheinternet/. Doesn't break out mobile but you may find it useful.

Thanks for writing in.

Jan
Said this on 7-21-2012 At 11:54 am
I dont think there will be a big effort to rucede the size of the file. Increased quality of video and audio will definitlely be the goal. If you see the sizes of hard disks and the type of bandwidths available the requieremnet for smaller file sizes might not be that much. People will be able to prob transmit huge files even to mobile phones. hence the reqmt of small file sizes might go off. It will be something like ur software companies talk of downloading gigabytesover the net and dont worry too much abt huge file sizes and installation space.References :
Said this on 6-8-2013 At 01:41 pm
Interesting.You mention Bluray, but can ditigal cinema projectors support 60 fps? What about home-market 3D TVs and their active shutter glasses?
Post a Comment
* Your Name:
* Your Email:
(not publicly displayed)
Reply Notification:
Approval Notification:
Website:
* Security Image:
Security Image Generate new
Copy the numbers and letters from the security image:
* Message: