Camera Video Performance

Video recording quality was one of the weaknesses of previous Huawei phones. The Shenzhen manufacturer only introduces OIS last year with the P8 and in devices before that we saw poor ISP performance as videos generally lacked detail. In terms of video encoding we see usage the Kirin 950’s encoder block IPs by Imagination Technologies.

Note: We have yet to confirm if video recording is affected by the camera focus issue and thus can’t differentiate between lack of detail caused by either the optical system or the ISP’s processing.


1080p30​ - Optical Image Stabilization

At 1080p the Mate 8 is able to offer better detail than past devices such as the Mate S. We actually see the video bitrate more than doubled as by default 1080p30 is now recorded at 23.7Mbps instead of the 10Mbps of past Huawei devices. This really helps overall image clarity.

The Mate 8’s new 3-axis OIS does a better job at keeping a still image, however Huawei hasn’t managed to get rid of the abrupt module repositioning and we thus still see jagged motions. Unfortunately Huawei still has a lot of work to do to catch up to OIS systems of other manufacturers such as from LG or Samsung.


1080p30​ - Optical + Electrical Image Stabilization

The camera application offers the option to enable EIS in the settings (“Stabilizer” option). I’m a bit disappointed here to see that the new ISP still struggles to maintain proper quality as it’s very visible that the resulting video is just a cropped and re-scaled frame out of a native 1080p stream from the camera sensor. This results in large loss of detail and my repeated recommendation to just not use this feature.


1080p60​ - Optical image stabilization

I was surprised to find 1080p60 among one of the recording modes as HiSilicon had briefed me telling that the encode capabilities of the Kirin 950 hadn’t evolved, but seemingly this is wrong as 60fps recording is very well present and working. I was surprised by the video’s bitrate as Huawei set a rather high 47MBps encode configuration for the mode. This results in a noticeable improvement in detail which is welcomed. It also seems that OIS is functioning at a higher sampling rate as we see much less jagged “travel” as it looks as if we’re dealing with increased finer movements of the module.

Selecting 1080p30 disables the option to use a “Beauty” mode which is popular with some users, and again 1080p60 disables the option to use EIS. This points out that HiSilicon’s video ISP architecture is DSP based and has limited resources available to it as it needs to disable features as video throughput increases. This might also have been one of the reasons why the vendor chose not to employ 4K media encoders as it might have still been bottlenecked by the ISP.

Sound recording continues to be very clear for the Mate 8 although for some reason the default volume was much too low making it very hard to listen to recorded videos both on desktop as well as the phone itself. One can hear that in the first ~1s of the video the audio is louder after which it seems some sort of too high dynamic range compression is applied. This actually represents a large usability issue that I hope gets resolved in future software updates.

NAND Performance

My unit of the Mate 8 came with a SanDisk SDW32G eMMC chipset. This is an eMMC 5.0 part running in HS400 data rate mode, meaning at frequency of 200MHz DDR at with a bus width of 8 bit enabling a maximum throughput of 400MB/s. The controller used is one of the 3 Synopsis DesignWare blocks on the Kirin 950, with the second controller being used for the SD card with help of an Arasan PHY IP, and the third one connecting the WiFi combo chipset.

We’ve noticed that Android 6.0 has broken our usual test setup of AndroBench 3.6 as the random I/O tests aren’t able to properly report their scores. As such while we’re looking for better alternatives (Other than AndroBench 4.0) I’m keeping it simple and just reporting the sequential read and write speeds for 3.6.

Internal NAND - Sequential Read

The Mate 8 managed 127MB/s sequential read which puts it at the lower end of last generation flagships. Unless I’m mistaken the phone comes unencrypted and Huawei also doesn’t offer the option to encrypt the phone as it’s missing from the settings menus. HiSilicon has confirmed to me that the Mate 8 has FDE enabled by default and that the performance listed represents the encrypted performance of the phone. 

Internal NAND - Sequential Write

Write speeds come in at 31.2 MB/s which is relatively good in comparison to other devices. Here we see the huge improvement over last year’s Mate 7 as it notoriously suffered from horrible NAND speeds as it used a eMMC dated back to 2012.

For the sake of completion, the AndroBench 4.0 numbers for the device was able to attain 127.55 and 48.68MB/s sequential read and writes and 17.32 and 6.27MB/s random read and writes.

WiFi Performance

WiFi connectivity and performance was sort of an absolute disaster for Huawei over the last year as every device we’ve reviewed sported horrible WiFi speeds or outright did not even support the 5GHz band. 

The Mate 8 finally improves the situation as we see the old Broadcom BCM4334 dropped in favour of a new BCM43455. We actually covered this piece last MWC as it was introduced by Broadcom. Being a 1x1 HT80 solution capable of 802.11ac on both 2.4 and 5GHz bands we should see speeds of up to 433Mbps. As mentioned earlier in the NAND section, the WiFi chipset is connected via SDIO so it’s likely that the Mate 8 isn’t as power efficient as PCIe implementations and may be one of the factors of why maximum battery life isn’t quite as high as I expected it to be.

WiFi Performance - UDP

On the downstream direction we’re indeed seeing speeds somewhat in line with the theoretical maximum as the Mate 8 reaches 314Mbps. What continues to baffle me though is that we’re again seeing a large discrepancy between downstream and upstream as I was only able to reach 126Mbps upload on the device. It seems Huawei again is using some kind of limiter or traffic shaper on this device. Again I’m not too sure why they’re doing this and if it has anything to do with power efficiency but it’s definitely an odd characteristic exclusive to Huawei.

On 2.4GHz the Mate 8 reaches 78.6Mbps downstream and 67Mbps upstream, also displaying >2x improvements over past devices. While we don’t yet have objective testing for WiFi reception, I also noticed connectivity range on the Mate 8 greatly improved over the Mate 7.

Camera Still Picture Performance Conclusion & End Remarks
Comments Locked

116 Comments

View All Comments

  • lilmoe - Tuesday, January 5, 2016 - link

    CCI (Cache Coherent Interconnect) is basically responsible for connecting and "shifting" load between CPU clusters (, GPU and various other compute blocks) in a big.LITTLE configuration based on compute load needs.

    For the rest, Google is your friend.
  • name99 - Tuesday, January 5, 2016 - link

    Andrei, do you always use the same compiler, version, and settings for the SPECInt2000 measurements?
    The reason I ask is if you compare these results to the A9 results
    http://www.anandtech.com/show/9686/the-apple-iphon...
    things are mostly as you'd expect except 300.twolf and (especially) 175.vpr
    The latter in particular is discrepant enough that the only thing that seems like it might have caused it is a substantial compiler optimization like a loop re-ordering.
  • Andrei Frumusanu - Tuesday, January 5, 2016 - link

    On Android we use the same binaries unless we specify some flag changes which happen over longer periods (Last change was in August). Generally we try to publish a given article with apples-to-apples scores.

    For iOS it's impossible to use the same compilers and we have to rely on Apple's LLVM. It's very possible that Apple's scores are higher due to better optimizations. I have in mind to try LLVM on Android (currently it's GCC) but it's something of a long-term project rather than something we can just switch to and even then it will never solve the optimization issue as Apple's LLVM toolchain has additions that we simply can't keep track of.
  • name99 - Tuesday, January 5, 2016 - link

    To add to my point, compare with
    http://www.anandtech.com/show/9330/exynos-7420-dee...

    Here the Exynos 7420 SPECInt2000 numbers are sometimes EXTREMELY different (like sometimes over a factor of 2, eg 175.vpr) from the Exynos 7420 A57 numbers you give in this article.

    Maybe it would be good form, going forward, to publish this information, just so we can all keep track. (And obviously it is interesting to see when LLVM results differ greatly from gcc results, or even when the LLVM results show a great jump.)
    Obviously one can't hope for PERFECT LLVM parity. Certainly Apple are keeping the back-ends of the compiler toolchain (Typhoon and Twister, maybe even the current Cyclone and Swift back-ends) secret; and given that they use a slightly different linker, there may be differences in exactly how, eg, they handle LTO. But one would expect mostly similarity between the Apple and Android LLVM, and rather more difference with gcc.

    My point is not some sort of "rah rah Apple"; it's more just a desire to understand. For example, IS it the case that gcc happens to have some sort of (presumably fairly recent) optimization that managed to double the 175.vpr result? (And if so, what's the nature of that optimization.)

    I think we'd all be curious to know, for example, whether you use LTO in building these SPECInt2000 binaries. And whether, if you use PGO, you get a substantial boost in performance.
  • Andrei Frumusanu - Wednesday, January 6, 2016 - link

    There were issues with the 7420 harness that caused us not to immediately catch validation failures and it treated the runtime as if the test were simply faster. SPEC is relatively complex so unfortunately such problems do happen.
  • RdVi - Tuesday, January 5, 2016 - link

    Nice improvements from Huawei. If the P9 can keep this up while being no larger than the P8, it might be my next phone.
  • SHartman1976 - Wednesday, January 6, 2016 - link

    No complaint about the power and volume buttons being on the same side? That seemed to vex you on the Nexus 6P a couple of weeks ago despite it being a recurring design choice.
  • Andrei Frumusanu - Wednesday, January 6, 2016 - link

    My complaint on the 6P wasn't them being on the same side, it was that the volume buttons were extremely low on the phone and positioned below the power button, an odd positioning that kept one pressing the volume buttons when holding or picking up the phone. The Mate 8 has a traditional layout which doesn't cause any issues.
  • raghwendra123 - Wednesday, January 6, 2016 - link

    When should we expect the iPad Pro review?
  • Piscupescu - Wednesday, January 6, 2016 - link

    Nice review. Keep up the good work.

Log in

Don't have an account? Sign up now