The ASUS ZenFone 2 Review
by Brandon Chester on May 26, 2015 8:00 AM ESTVideo Performance
The other side of a phone's camera quality is how it performs when taking video. I've actually noticed an increased number of people taking videos now that the warm weather of summer has returned to Canada. Taking videos is also arguably a more intensive test of camera quality than taking still photos. A device's image signal processor needs to do post-processing in a much shorter time interval, and on devices where OIS is supported there's no way to use it to enable long exposure times as the frame rate of the video needs to be fixed high enough to keep the illusion of motion intact.
The ZenFone 2 has 3 different video settings, although the first one is 480p and not really worth discussing. The other two are the 720p30 and 1080p30 modes. While one may be tempted to just use the highest resolution mode, the caveat with 1080p30 recording is that there's no form of electronic video stabilization. ASUS also has a setting for choosing between quality and performance when recording. I assume that the performance setting is reducing frame drops at the expense of bitrate, but I didn't notice any difference in smoothness between the two modes so I recorded all the test footage using the quality setting.
The first video test is a video taken from a relatively stationary position. This gives an idea of what video quality is like without the effects of hand shake and so the device's ISP is really what will determine whether a device does well or not. I've taking recordings in both the 720p30 mode with digital stablization, and the 1080p30 mode without the EIS.
In this test the 1080p mode is the clear winner. The impact of EIS when recording at 720p is minimal, and the 720p footage is so blurry that it almost looks like upscaled 480p footage. The ZenFone 2 encodes 720p footage at 8Mbps using the H.264 Baseline profile. 1080p footage is encoded at 15Mbps and also uses H.264 Baseline. Unfortunately, even the 1080p footage isn't very impressive. There's just a general lack of sharpness throughout the entire frame.
The next test makes things more interesting by adding a significant amount of camera movement. This is where the use of EIS in the 720p mode will come into play, while the 1080p mode will most certainly have a higher degree of shakiness.
In this test it's clear that the 720p is much more stable than the 1080p footage overall. However, there are numerous instances where the the camera moves too far from its original position and the video drops frames as it settles on a new position. There's also a significant amount of high frequency shaking which makes the entire video look like it's wobbling back and forth very quickly. Both of these issues are very similar to what you see with video that is stablized using OIS, which is strange because the ZenFone 2's camera doesn't have OIS.
Unfortunately, the 720p video is again very blurry. The 1080p video is better, but is also not near as good as the output from other smartphones. It doesn't appear that there's any degree of EIS being used to stabilize the 1080p footage either. Both modes suffer from some noticeable processing issues, including halos where branches of trees are in front of the sky.
At this point it's becoming fairly evident to me that the ISP is being used in the ZenFone 2 is very far behind the competition. It would be nice if ISPs in mobile were less opaque so we had a better idea of what goes on at that stage in the pipeline. Whatever the cause may be, the ZenFone 2's video output is fairly uninspiring. If you do need to take a video with it I would still use the 1080p mode despite the shakiness, as the 720p mode is just far too blurry.
Facebook
Twitter
RSS
147 Comments
View All Comments
der - Tuesday, May 26, 2015 - link
Sweet review mates. Y'all the best!Daniel Egger - Tuesday, May 26, 2015 - link
Two things:1) The x86 problems are very real; about any serious Android application contains native code for performance reasons, the rest are very non-demanding gimmicks or simple games. There're still plenty of application which do not even attempt to run on x86 which can be easily seen by e.g. checking the F-Droid repository with the app. And of those which do run quite a few simply don't work correctly; I've found quite a few of those in the Humble Bundles. My suspicion is that the developers do compile them for x86 but do not really test them on that platform...
2) Those Silvermont cores do have decent performance but I've yet to see a single implementation where battery life doesn't suck. One discovery I've made is that those devices are very reluctant to go into deep sleep, even with some tweaking they'll usually stay on the lowest possible frequency most of the time. Could be that the software is not quite ready to properly handle those Intel cores or they simply suck...
MikhailT - Tuesday, May 26, 2015 - link
Both are software issues. Google doesn't have any incentives to stick with ARM only, they'd want to work with Intel to fix these issues.At my work, we had an issue where our app would crash on Intel devices, it took us a few weeks to figure out that it was a low-level bug in Android. We filed a bug report but no news if Google or Intel will fix it. We managed to work around it but it was difficult and took a lot of time.
The latest rumors is that Android M is supposed to work on the battery issues. Hopefully, that includes optimization for Intel SoCs.
kpb321 - Tuesday, May 26, 2015 - link
I was surprised that the review seemed to skip this entirely. It is certainly an issue when dealing with x86 android phones. Theoretically any app that doesn't include NDK "should" work fine on x86. My experience with Android phones/tablets was that I don't ever recall installing a single app that had NDK in the permissions list so it didn't seem like it was very common to me. On the other hand I've never actually had an intel tablet to actually see how good or bad it was.Brandon Chester - Tuesday, May 26, 2015 - link
I also reviewed the Venue 8, and like I said in both this review and that review, I have never found a single app that doesn't work because the SoC is x86. A lot of people like to say that there are lots of apps that have issues, but they never seem to name any so there's no way for me to actually confirm that. If people do know of some problematic apps please let me know via email or Twitter so I can take a look.Muyoso - Tuesday, May 26, 2015 - link
An app called Photo direct that I use for work crashes instantly when launched.rocketbuddha - Wednesday, May 27, 2015 - link
I bought a Dell Venue 8 with KitKathttp://www.bestbuy.com/site/dell-venue-8-8-intel-a...
and found that it was the POS.
Dunno if it was 1GB RAM that came with it, but it was hanging even while opening tabs in chrome/stock browser.
With Lollipop, Google officially has both a ARM as well as x86 version it tests and releases. Pre-lollipop it was Intel who customized Android to work with its Atom processors.
Maleficum - Saturday, May 30, 2015 - link
Brandon, you'd be really surprised to know that most apps in the top charts are using NDK.Google claims that 85% apps are written in Java. I'm not saying it's a lie, but it is far from realistic since most apps in the top charts - apps most people use most of their time - are NDK based.
Even more surprising would be the fact that roughly half of these apps contain ARM binaries only, thus forced to run via binary translation that results in a performance reduction of roughly 70% while the power consupmtion doubles.
In that sense, your article is misleading IMHO, simply repeating Google's claims.
http://www.theregister.co.uk/2014/05/02/arm_test_r...
I think it's clear why so many apps are NDK based: Java isn't simply the right language for computationally intensive apps, and primitive apps written in Java cannot make it into the top charts.
And app developers aren't interested much in supporting x86 natively considering the tiny market share. No one can blame them for neglecting x86.
That's the reason why I'd never buy nor recommend x86 Android phones, and Intel having difficulties getting foothold in mobile segment.
I think it would be worth an investigation and probably a separate article.
Thunderc8 - Saturday, May 30, 2015 - link
I have installed all known apps and then some and all working perfect and super fast. If what you say is true then Intel CPU is a beast since it looses so much performance and at the same time is so Damn fast.coolied - Wednesday, May 27, 2015 - link
NDK wouldn't be in the permissions list, it simply means the app was coded in C++ and not JAVA. Unfortunately, most apps you would WANT to run and run WELL are written in C++ aka most 3D games.