Video: Finally High Profile H.264

Section by Brian Klug

There are a few things different with video capture on the iPhone 5 thanks to improvements to both the ISP inside Apple’s A6 SoC, and also software UI changes. First off, because the iPhone 5 display is now 16:9, there’s no cropped view by default or aspect-correct view with letterboxing for video capture. Instead the iPhone 5 video capture window takes an iPad-like approach with transparent UI elements for preview and shooting video.

What’s new is the ability to take still images at 1920x1080 while recording video by tapping a still image capture button that appears while recording. This is a feature we’ve seen onboard a ton of other smartphones and works the same way here. Note that you can’t magically get a wider field of view or the whole CMOS area while shooting video, it’s essentially dumping one frame from video capture as a JPEG instead of into an H.264 container.


In addition the iPhone 5’s tweaked Sony CMOS still uses a smaller center region for video capture. The difference in field of view is pretty big, but nothing that users haven’t already dealt with in the past.

The iPhone 5 brings two main things to video capture. The first is improved electronic image stabilization tweaks and improvements to ISP. The difference is visible but not too dramatic unless you know what you’re looking for. I would wager most users won’t notice a huge step forward from the 4S but if you’re using an iPhone 4 this will be a marked improvement.

The other improvement is video encoding. The iPhone 5 now shoots rear facing 1080p30 video at 17 Mbps H.264 high profile with CABAC. This is a huge step in encoding from the relatively absurd 22–24 Mbps baseline H.264 that the iPhone 4S would shoot at 1080p30. The result is vastly more quality per bit on the iPhone 5, for a big reduction in storage space per minute of video. I did some digging around and found that the A6 uses an Imagination Technologies PowerVR VXE380 for encoding and VXD390 for decoding, which is what I thought was in the previous SoC as well but perhaps wasn’t clocked high enough for encode at high profile. This brings the iPhone 5’s encoder on paper up to match what I see other smartphones running their 1080p video at as well (17 Mbps high profile).

On the front facing camera Apple is shooting 720p30 at 11 Mbps H.264 baseline, as opposed to the VGA at 3.5 Mbps that the 4S shot. Interestingly enough both front and rear shooting modes still are just mono audio, 64 kbps AAC. I would’ve liked to see stereo here since almost all the competition is shooting stereo, and it’d put those 3 microphones to use.


To get a feel for video quality, I stuck my iPhone 4S and iPhone 5 in my dual camera bracket with pistol grip and made a series of three videos. I then combined them and put them side by side for ease of comparison. I’ve uploaded the result to YouTube, but you can also grab the original videos (548 MB zip) if you’d like from the site directly without the transcode.

Overall the most dramatic improvement is the front facing camera, which is obviously night and day. Better image stabilization is noticeable while I’m walking around being intentionally shaky, but nothing hugely dramatic. The main rear facing video improvement seems to be an increase in sharpness (watch the power lines and wires in the native resolution version) and slightly wider field of view. That’s to say nothing of the fact that this quality comes at a bitrate that’s lower than the previous version but with better encode settings.

Camera Stills: Improved Low Light Cellular Connectivity: LTE with MDM9615
Comments Locked

276 Comments

View All Comments

  • themossie - Tuesday, October 16, 2012 - link

    The manufacturer's charger uses a set of pull-up resistors connected between the various USB lines, to indicate that the phone can pull maximum current. Unfortunately, every manufacturer (and sometimes different phones) use different resistances.

    See http://electronics.stackexchange.com/questions/144... for a brief writeup.

    For what it's worth, I've only had this problem with iDevices and the HP Touchpad. I own circa-2011+ HTC, Motorola and Samsung phones, and they all work fine with every charger. My Droid 2 Global was my primary work phone until a few months ago, and works great with every charger. Not sure why your wife is having problems there.
  • crankerchick - Tuesday, October 16, 2012 - link

    "The non-LTE phones see a sharp drop in battery life. At least at 28nm the slower air interfaces simply have to remain active (and drawing power) for longer, which results in measurably worse battery life. Again, the thing to be careful of here is there's usually a correlation between network speed and how aggressive you use the device. With a workload that scaled with network speed you might see closer numbers between 3G and 4G LTE."

    Perhaps you all could devise a test for this? Something like, change your LTE and 3G tests, where you decrease the time between page loads for the LTE test, to simulate doing more browsing since the pages load faster? One data point on this, with a reasonably selected change in page load duration, would be very helpful now that we have this very interesting dynamic clearly visible.

    That said, as always, I appreciate the reviews presented here. Always thorough with lots of information to chew on beyond specs and "user opinion on user experience."

    Just wish the reviews didn't take so long, but they are always worth it in the end.
  • TofDriver - Tuesday, October 16, 2012 - link

    Thanks for this awesome article. Gigantic work, we'll worth the wait.
    I've learnt so much.
    Would still appreciate it as an ebook, even after the web reading!
    Seems like you're perfectionists who love to push limits... To me it does resonate with the team who designed the reviewed product.
  • name99 - Tuesday, October 16, 2012 - link

    "Another potential explanation is that the 3-wide front end allowed for better utilization of the existing two ALUs, although it's also unlikely that we see better than perfect scaling simply due to the addition of an extra decoder."

    Remember the standard numbers. On this type of integer code:
    1/6 instructions are branch
    1/6 instructions are store
    1/3 instructions are load
    1/3 instructions are ALU
    This means the usual first throttling point i cache access, if you can only do one load/store cycle.
    If you limit your cache to one op/cycle, it's generally not worth going beyond 2-wide --- too often you're waiting on the cache.
    Once you widen your cache (usually, at this stage, by allowing simultaneous read and write per cycle) three-wide makes sense.
    Each cycle now (on ideal and some sort of "average" idealized code) you can now do some sort of combination of half a branch, 1.5 load/stores, and 1 ALU. Meaning that 2 ALUs (as long as they are not overloaded and also handling some aspect of the load/store) is enough for now.
    [Of course things never work out quite this ideal --- you have burstiness in operation types, not to mention delays. But the compiler should try to schedule instructions to get this sort of average, and likewise the re-order queues will do what they can to shuffle things to this sort of average. 2ALUs helps with the bursts, 3ALUs is overkill.]

    So I would say the primary important change made to go to three-wide in a way that is not a waste of time was to convert the L1 cache to dual-ported, supporting simultaneous load & store per cycle.
  • jiffylube1024 - Tuesday, October 16, 2012 - link

    I have to commend the Anandtech team for the great review! It was a long wait, but well worth it. The info on anodizing, the "Swift" CPU @ 1.3 GHz, camera performance, etc. was worth waiting for. This article, in my eyes, is a culmination of the Anandtech team's knowledge in the tech industry - deconstructing A6 to figure out what it's made of, discussing Apple's manufacturing capabilities, etc. Very informative and well written!

    I am always amazed at how many complaints (and petty platform wars) get exposed on the comment board. I certainly appreciate them when an article is poorly written, contains false information or outright lies, but with an article like this, the comments section seems shy of the effusive praise it deserves!
    ------

    On a slight tangent, I've enjoyed the first 8 Anandtech podcasts as well, and I have to say that I look forward to more non-iPhone related disucssion on future podcasts. The information was much appreciated, but for a tech site as broad as Anandtech, the first 8 podcasts have been VERY iPhone heavy in their content! Keep up the good work.
  • jamyryals - Thursday, October 18, 2012 - link

    I think you're right, it has been iPhone heavy, but the start of the podcast kind of lined up with the launch/review process. Let's be honest, it is a huge selling high quality device and it's treated as such. I have a feeling Brian and Anand will have a lot to say about all of the impending Nexii/WP8 when they come out this quarter.
  • krumme - Tuesday, October 16, 2012 - link

    Good to see reviewers apreciation of low light capabilities for the BSI sensor, reflecting real world usage. Oposite to a lot of uninformed stupid reviews on the net.

    Its exactly the same practical difference between s2 and s3 cameras. Big difference for real usage.

    All the mpix race must stop now. 8M is way to much for the quality anyway.
  • Zanegray - Tuesday, October 16, 2012 - link

    I love the level of analysis and attention to detail. Keep it up!
  • mrdude - Tuesday, October 16, 2012 - link

    Wow, what an article. Really fantastic read. The lengths you guys have gone to in this review is stunning, frankly. Well done. Although I'm no Apple fanatic, I must say that this is one of the better articles I've read on AT :)
  • Dennis Travis - Tuesday, October 16, 2012 - link

    Totally outstanding review. You guys covered everything. Thanks so much!

Log in

Don't have an account? Sign up now