20110601 Android FlashPlayer10.2 and 10.3 Xoom

8/4/2019 20110601 Android FlashPlayer10.2 and 10.3 Xoom

http://slidepdf.com/reader/full/20110601-android-flashplayer102-and-103-xoom 1/15

The Right Fit?

Video Playback Performance on Android Handset andTablet Devices Using Adobe Flash Player 10.2 and 10.3

A Transitions in Technology White Paper

Timothy Siglin

Co-Founder

Transitions, Inc.

1 June 2011



The Right Fit? Video Playback Performance on Android Handset and

Tablet Devices Using Adobe Flash Player 10.2 and 10.3

Executive Summary

The rise of the Android operating system—more smartphones sold in the US and North American

markets over the past six months are powered by Android OS than any other mobile operating

system—has been both a blessing and a curse.

The upside is that the open-source Android OS is highly extensible, allowing service providers and

end users alike the chance to fork the operating system for a variety of benefits. Extensibility is also

the curse: consistent user experiences for media consumption tends to suffer, most noticeably if

built-in applications and services are used. As such, this extensibility—and limited ability to play a

number of types of video content via the built-in applications or services—places the burden of

finding a universal media player plug-in or trusted application on the end user.

Does a universal media player solution for Android exist? We took on the challenge of looking at

Adobe Flash Player, to gauge whether it fills the role of universal media consumption experience

equally well or better than multiple built-in Android applications and services?

Our testing builds on our initial report on six Android handsets using Adobe Flash Player 10.1. Now

our tests use Flash Player 10.2 (FP 10.2) on five Android handsets, as well as FP 10.2 and FP 10.3

on Motorola Android-powered Xoom tablet (using Android OS versions 3.0.1 and 3.1, respectively).

Our current testing finds that FP 10.2 on handsets and 10.3 on the Xoom:

• Provide a more consistent media consumption than Android's built-in apps and services.

• Plays content at better frame rates than built-in apps and services, with minimal battery impact,

yielding significant frames-per-second performance gains.

• Generate performance gains with the proper combination of Android OS and Adobe Flash Player.

• Plays content that some Android devices could not play unless a Flash Player plug-in is present.

In addition, we found dual-core-equipped devices with robust graphics processor units (GPUs) will

perform significantly better—with much lower overall battery impact—than standard handsets.

Finally, we were impressed by Motorola’s Atrix, a handset offering stellar performance, albeit with a

tendency to warm up quickly when the GPU was heavily utilized. The Motorola Xoom also gets

high marks, generating large performance improvements when using FP 10.3 and Android OS 3.1.

The Right Fit? Video Playback Performance on Android Using Adobe Flash Player 10.2 / 10.3 Transitions, Inc. 2

http://workflowed.blogspot.com/2011/02/flash-player-101-for-android.html





Introduction

The Android operating system (OS) is now the leading smartphone OS in the United States. Within

the three months between our initial report on Android-Flash Player performance and now, Android

smartphone market share in the US has risen several percentage points. Boasting a 36% market

share in the first quarter of 2011, Android smartphone sales now surpass those of Apple’s iOS and

Research in Motion (RIM) in the United States—and continues to gain ground in the global market.

Part of this popularity can be attributed to the openness of the Android OS, which can be modified

to allow for customization, unlike operating systems from leading competitors. The recent advent

of dual-core processor handsets and discrete graphics processors (GPUs) also helps, bringing the

Android platform into its own for gaming and media consumption. From the dual-core Motorola

Xoom tablet to the more recent Atrix handset, which sports a discrete GPU, the Android platform

has devices to compete directly with iOS and RIM devices.

Still, with the variety of handset choices on the market today—hundreds of devices from dozens of

mobile service providers and carriers—there is a sense of fragmentation that threatens to impact

both the Android OS platform’s growth and the general user’s consistency of media experience.

From different versions of the operating system—Froyo, Gingerbread and Honeycomb are just a

few of the popular code names for recent Android OS updates—to a difference in the types of

content that a stock Android-based device can play, there is a great deal of fragmentation even in

the simplest levels of consistent media consumption across a variety of devices.

Some reports compare only the specifications of the devices, but we took a different approach

building on the previous report that compared Adobe Flash Player on Android devices to the

general consensus surrounding Apple’s claims of Flash Player impact on memory and power

consumption. This report focuses on the consistency of experience within the browser, using the

Adobe Flash Player plug-in.

As many Android users know, Adobe Systems, Inc., makes both the Flash Player plug-in and Flash

creation tools such as Creative Suite, Flash Builder and Flash Professional, advocating Flash Player

as a way for users to gain a consistent media experience on many Android devices.

In addition, the Adobe AIR integrated run-time and software development kit (SDK) work with these

same Flash creation tools, enabling developers to create stand-alone application packages for

televisions, mobile devices (Android, BlackBerry Tablet OS, and iOS) and desktop computing

(Linux, Macintosh, Windows).










The Challenge

A rapidly growing part of the smartphone marketplace, applications offer convenience as they can

used for web and large dataset access without the need for the mobile browser.

But do they offer performance gains? We compared whether built-in Android applications and

services give individual Android devices the ability to forego the Flash Player plug-in.

To do so, we built on our recent testing of six Android handsets but modified that methodology to

test a crop of new handsets and tablets, some of which include dual-core processors and GPUs.

As before, we asked Adobe for publicly available data pertinent to their internal test results on Flash

Player 10.2 (release 157.51), the most recent publicly available build publicly available at the time of

our testing in late April and early May.

We then chose, with Adobe's assistance, devices which had Flash Player plug-in compatibility,

settling on six Android devices for five days of testing.

Initial results show that Adobe Flash Player 10.2 provided a more consistent media consumption

experience than did Android's built-in applications and services. Adobe Flash Player played

content at as good or better frame rates than the built-in applications and services, across all of

the tested devices, within basic resource allocations.

We were surprised to find, in some instances, that an Android device without a Flash Player plug-in

could not play chosen content. We found that RTSP-based video playback and other standards-

based media delivery on some Android test devices could not be played with built-in applications

and services, despite the requirement for the base Android OS to be able to play this content.

Along the way, we wanted to cross-check assumptions from the first phase of testing—mainly that

Flash Player appears to provide a performance benefit that outweighs the battery impact on any

given handset or tablet—by using at least one device from the previous test phase.

Why compatibility? Without getting too much into the HTML 5 / Flash debate—my opinions can

be found in a variety of magazine and online articles over the past three years—the bigger issue at

hand for the fragmented Android handset and tablet markets is a consistency of experience. This is

one of the key selling points of the iOS devices.

While it's true that handset manufacturers build handsets to the customized specifications of

distinct wireless service providers—to the extent that the four buttons on a classic Android device

have been moved around, eliminated and even expanded upon—it's not necessarily a given that all

versions of the same dot release Android operating system behave the same way. Google has

recently moved to reign in over-forking of Android OS that has been occurring, while at the same

time attempting to balance the issue of service-provider and end-user freedom of expression.




Fragmentation of handset, operating system and service provider services begs for a consistency

of media delivery experience across all platforms. This is an area that Adobe can potentially offer

solutions, assuming that content is accurately delivered the same way across a variety of devices.

A secondary issue faces service providers and content owners as the mobile tablet market grows:

how to cost-effectively move from one-screen service to an equivalent all-screen service model, in

a time when over-the-top media increases bandwidth demand curves beyond projected levels.

Why all the fuss? Mobile is the next frontier. The overall market is growing, with almost 430 million

handsets sold worldwide in the first three months of 2011. That’s a 19% increase from Q1 2010.

Smartphone shipments in the same three-month period grew 85% year over year, accounting for

101 million units per quarter according to Gartner. To put those numbers into perspective, as did

research firm IDC, smartphone shipments in 2010 outpaced PC shipments for the first time, with

PC growth only progressing at 3% for the fourth quarter of 2010, on shipments of 92 million units.

It’s also worth noting how fast Flash Player penetration grew: comScore notes that 33% of US

smartphone sales are based on Android OS. The vast majority of those devices support the Flash

Player plug-in and a number of those devices also support Adobe AIR.

By the end of 2010, Android-based handset shipments surpassed the number of shipping iPhones

devices. To compare, Apple’s iPhone only holds 25.2% of US smartphone market share. In other

words, Flash-equipped smartphones now outnumber iOS handsets, allowing Adobe to dominate

the media-delivery experience, if Flash Player and AIR solutions offer a consistent user experience.

One other area where compatibility is key is a build-once, distribute-to-many development model.While it is possible to use various integrated development environments (IDEs) to build for a variety

of platforms, the goal of most developers is to use a single IDE and minimize the need to tweak for

every device. While our testing was underway, Adobe released the Creative Suite 5.5 collection—

including Flash Builder 4.5—to further address this issue.

Why different versions of Flash Player and the Android OS? As noted in executive summary,

there are so many versions of the Android OS—including multiple forks and tweaks—that an end

user can be stymied by the choices for device, operating system version and applications. To cut

through that issue, to best gauge performance consistency, we opted for two major versions of the

Android OS (2.3 and 3.0/3.1) as well as two versions of the Adobe Flash Player (10.2 and 10.3,

with 10.3 only targeting Android OS 3.1 on the Xoom device).

This approach allowed us to determine whether performance continues to improve, and whether

they benefit broadcasters and users demand for premium and rights-protected video content.


http://www.comscore.com/Press_Events/Press_Releases/2011/4/comScore_Reports_February_2011_U.S._Mobile_Subscriber_Market_Share


http://www.bgr.com/2011/05/19/36-of-global-smartphone-purchasers-chose-android-in-q1-of-2011/









Methodology

Speaking of test methodologies, this report’s methodology builds on previous testing methodology.

In those tests, we gauged video, rendering and immersive websites against several Android

phones with Flash Player 10.1 and we will do similar testing with Flash Player 10.2 in this phase.

What’s New? This test phase adds video streamed from a dedicated, on-site streaming server, to

control and monitor implications around delivery of RTMP and RTP/RTSP protocol-based content.

Adobe-provided plug-ins. Adobe provided two Flash Player plug-ins, one for 10.2 (r157.51) and

one for 10.3 (r185.22) which are identical to the publicly available Flash Player builds, except for

the fact our build was instrumented to gather key test data. Instrumentation actually works slightly

against performance, since data gathering requires a small amount of overhead processing, but

the information gathered was well worth the small performance hit.

Devices (handset). We used several phones from our initial test phase, updating any firmware

and plug-ins to their most current versions, as well as several new phones.

Model OEM Processor Tested OS Version Browser (Webkit) YouTube

Atrix Motorola Nvidia Tegra 2 @ 1 GHz 2.2.1 2.2.2 2.1.6

Droid 2 Motorola TI OMAP3620-1000 @ 1GHz 2.2 2.2 1.6.21

Droid X Motorola TI OMAP3630 @ 1GHz 2.2.1 2.2.1 1.6.21

Nexus S Samsung Cortex A8 Hummingbird @ 1GHz 2.3.3 2.3.3 2.1.6

Galaxy S Samsung Cortex A8 Hummingbird @ 1GHz 2.3.2 2.3.2 2.0.26

Xoom Motorola Nvidia Tegra 2 @ 1 GHz 3.0.1 3.0.1-109065 3.0.15

Devices (tablet). We added one Android tablet, the Motorola Xoom, testing two combinations of

Android OS and Adobe Flash Player:

Model OEM Processor OS Version Flash Player Version Browser (Webkit) YouTube

Xoom Motorola Nvidia Tegra 2 @ 1 GHz 3.0.1 10.2.157.51 3.0.1-109065 3.0.15

Xoom Motorola Nvidia Tegra 2 @ 1 GHz 3.1 10.3.185.22 3.1-124251 3.1.1

We also baselined one other device—Research In Motion’s PlayBook—but found it requires some

additional tweaks to extract test data (along with a firmware update to address outstanding issues).

Test Sets. In a desire to replicate the typical mobile video experience, plus test a number of devices for performance and battery impact, we chose four test sets. Each was designed to gauge

performance, battery impact or a combination of the two.

Baseline site. Initial tests compared a one-SWF page and no-SWF page for power consumption

baselines. The negligible difference (less than five minutes, on average, across an average battery

life of more than three hours) meant we dropped the single-SWF for this phase of testing, retaining

the no-SWF page (www.google.com or www.google.co.[TLD] for those outside the US).


http://www.google.co/

http://www.google.co/

http://www.google.com/




Rendering. Focusing on performance, this test set measures frames per second (FPS) for similar

Flash and HTML animation tests. The test is the same one run in the first phase, although we

expanded to testing dual-core handsets and tablets, to see if the dual-core or more robust

graphics processor units (GPUs) would increase performance while minimizing battery impact.

We used a few animations that Adobe uses for internal testing, rendering a pair of scenes—bothwith and without image blur— to gauge performance impact on each device’s processor.

We used a publicly available animation test as well, created by Australian web developer Cameron

Adams, to tests several animation approaches including Canvas, Flash and HTML / JavaScript

performance, and then ran the latter two tests as battery impact tests as well, to see whether

HTML rendering had any less impact on battery life than in-browser Flash animation rendering.

The animation tests can be found at the following URLs:

• Flash (www.themaninblue.com/experiment/AnimationBenchmark/flash)

• HTML/JavaScript (www.themaninblue.com/experiment/AnimationBenchmark/html)

Video. In the original phase of testing, we tested the difference between in-browser playback

performance and the built-in YouTube application. Based on the fact that both Flash Player (via its

hardware profile) and the YouTube app can access the same hardware to aid in video decoding,

we assumed both would have similar battery impact / performance differences.

In our initial testing, we saw minimal difference between in-browser and stand-alone application

performance, but felt there were gaps missing in terms of the way we tested. For this phase, then,

we added both the "desktop" equivalent of YouTube video playback as well as a streaming server.

In the new methodology, we first replicate the YouTube mobile testing we'd done before, and then

chose to force playback of YouTube in a "desktop" mode where video playback is more robust.

While most mobile handset user wouldn’t consume content this way, with enough high-resolution

handsets on the market, we felt testing desktop versions of popular clips made sense.

For YouTube testing, we used the same 72-minute video clip of a 4 February 20111 White House

press briefing. It was encoded with the most modern techniques and consists mainly of shots of

the President’s press secretary briefing reporters at the White House, with simple cuts between

each of two cameras. For a variety of reasons, the Nexus S test device in this phase of testing had

similar issues to the Nexus S we used in the first phase of testing, even though these were two

different Nexus S units. Since the Nexus S had difficulty playing back a test clip that worked on allother devices, we measured the Nexus S YouTube experience with a White House press briefing

clip from 4 February 2010—the same clip we used to test the Nexus S in the first round of testing.

To address the ever-changing nature of video players, and modifications to video-centric websites,

we also plan to perform a self-contained streaming server-based test of RTMP and RTP/RTSP

content. Using a streaming server provides true average frame rates for video performance, while

also allowing readers to replicate the testbed to verify published results.


http://www.themaninblue.com/experiment/AnimationBenchmark/html

http://www.themaninblue.com/experiment/AnimationBenchmark/flash









We also did RTMP and RTSP delivery tests, using Flash Player for RTMP and the native Video app

(an underlying player on most Android devices, not to be confused with the YouTube app) for RTSP

streaming playback.

The file chosen for this testing was the publicly available Sita Sings the Blues by Nina Paley, which

is distributed under a Creative Commons license. We chose both the 480p and 720p versions, forhandset and tablet devices, respectively, and then used Wowza Media Server 2.2.4 to push out

RTSP and RTMP content in two separate tests.

Why choose a higher-resolution video to stream? The answer is partly due to our test environment

being Wi-Fi centric and partly due to the fact that we wanted to tax all the devices with content

that would require a heavy amount of processing (CPU or GPU) to decode, in order to determine

which devices could withstand the heat, so to speak.

Testing Environment Attempting to minimize single points of failure, and to eliminate potential hardware or connectivity

issues, we tested phones in two locations. Each location had a different form of connectivity (DSL

versus cable modem) but had an identical access point (Linksys WAP610N). The unit was placed

approximately 20 feet from test location and also passed through at least one wall or floor.

We set the WAP610N to 2.4 Ghz "Wireless G only" and connected it directly to a multi-port router.

Channel selection for the access point depended on the channel setting for the other WiFi signals

present at either test location. The WAP610N was set at a higher output power and at least five

channels away from any other access point, to avoid a scenario during testing where handsets

would lock on to another, stronger signal. In both cases, we were able to set the WAP610N to

channel 6, or 2.437 GHz, since signals were present at either channel 1 or channel 11.

Why 802.11g instead of 802.11n? G-only versus N- or mixed-signal output has these benefits:

1. G is a common denominator to all phones tested, including the original Motorola Droid

2. G draws less power than the standard 802.11 n chipsets. Devices using low-power 802.11n

chips have less-consistent signal strength unless all devices are within 20 feet of access point.

3. G is in a frequency range that is slightly more crowded than N. We wanted at least one other

competing WiFi connection, which is harder to find with N near our test locations.

4. The connections to the Internet are lower than 10 mbps, meaning that there is no difference

between G and N in terms of load times or download speeds.

The access point was set to broadcast our SSID on an ad-hoc, open (non-encrypted) network.

For devices that had both mobile data (eg, AT&T or Verizon) and Wi-Fi capability, we turned off

mobile data connectivity to avoid any potential issues with mobile network signal strength.




Prepping Handsets. To separate Flash performance and battery impact from other resource

drains, we prepped all handsets with these six steps:

1. Set handsets to factory default, erasing previous browser caches or applications that might

lurk in the background to steal power or memory resources. An easy step on most phones.

2. Limited connectivity to WiFi only. On some devices, we had to manually turn off the mobilenetwork after restoring to factory default. Turned off GPS (location services and GPS).

3. Set screen brightness to halfway point and disabled auto-brightness, so that we didn't face

issues with testing at any time of the day or in varying ambient lighting conditions

4. Set screen timeout to 30 minutes; some handsets don’t have "never timeout" but others do.

5. Turned off overall vibration, but left haptic feedback on for gaming tests.

6. Downloaded and tested Flash Player 10.2 build mentioned above.

These above settings offer accurate WiFi-enabled playback / performance and battery impact info,

without additional processes or chipsets potentially shortening battery life during our test cycles.

Test Outcomes

So what were the outcomes of each test? To best determine battery impact, consider results from

each device, rather than pitting devices against one another. For performance, compared devices.

Baseline site. The tests we ran on a basic, non-Flash site (www.google.com) was designed to

benchmark battery impact for the rest of our testing. We found an average of 46% difference

between the baseline site and a basic HTML animation (TheManInBlue’s Animation Benchmark):

BATTERY IMPACT Baseline (Google) Animation (HTML) Difference (min) Difference (%)

Atrix

Droid 2

Droid X

Galaxy S

Nexus S

Xoom (3.1)

9:03 4:33 4:30 49.72%

11:26 4:05 7:21 64.29%

9:37 4:20 5:17 54.94%

5:37 3:06 2:31 44.81%

4:17 2:35 1:42 39.69%

8:52 6:14 2:38 29.70%

One primary take-away from this test: using even a simple HTML animation can significantly impact

battery life on many of the devices, consuming close to 50% of an average battery’s charge. Also,the Xoom exhibits the lowest difference between static and animations, a trend seen throughout.

Graphics Rendering. We use TheManInBlue's Animation Benchmark to gauge performance and

battery impact—the Animation (HTML) noted above is one of these benchmarks—and compared

Flash and HTML performance results between devices. Outcomes were similar to those from the

initial test, in that Flash animations reached average frames-per-second (FPS) rates of more than

4x those of HTML animation, as noted on the table below:







ANIMATION PERFORMANCE HTML Flash Difference (%)

Atrix

Droid 2

Droid X

Galaxy S

Nexus S

Xoom (3.0.1)

Xoom (3.1)

9.49 64.1 675%

6.15 22.42 365%

6.25 22.87 365%

6.12 26.41 432%

7.41 21.04 284%

6.92 28.87 417%

7.05 29.72 422%

Note that the Atrix outperformed every other device, including the X oom tablet, for an impressive

64.1 frames per second on the Flash animation, versus 9.49 frames per second for HMTL / Java.

For the impressive 3-7x performance gains, the average battery impact difference between HTML

animations and Flash animation was an average of 15% to HTML’s favor.

BATTERY IMPACT Animation (HTML) Animation (Flash) Difference (min) Difference (%)

Atrix

Droid 2

Droid X

Galaxy S

Nexus S

Xoom (3.1)

4:33 3:35 0:58 21.25%

4:05 3:25 0:40 16.33%

4:20 3:42 0:38 14.62%

3:06 2:25 0:41 22.04%

2:35 2:30 0:05 3.23%

6:14 6:29 0:15 3.86%

The narrow range of the Nexus S and Motorola Xoom are impressive, but even the Atrix, with a

whopping 675% performance gain, only saw a 21% drop in battery performance. The question

remains, however, as to the choice of battery savings versus sluggish frame rates, as some usersare more concerned about battery than they are about a quality media consumption experience.

Video. For these tests, we primarily used two H.264 video clips, with two alternates:

• 2/4/11: White House Press Briefing (http://www.youtube.com/watch?v=9yiVgXVFChU for

mobile, http://s.ytimg.com/yt/swfbin/watch_as3-vfl60kLQ6.swf for desktop) plus alternate older

clip for Nexus S at http://s.ytimg.com/yt/swfbin/watch_as3-vfl9DouAr.swf )

• Sita Sings the Blues (used with local server, but clips available at www.sitasingstheblues.com)

plus alternate RTSP file available at rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov)

The first video clip was a 72 minute press briefing, held on 4 February 2011, that was encoded

with the most modern techniques. It consists mainly of shots of the President’s press secretary

briefing reporters at the White House, with simple cuts between each of two cameras.

The second clip is the publicly available film Sita Sings the Blues by Nina Paley, which is distributed

under a Creative Commons license. We chose both the 480p and 720p versions, for handset and

tablet devices, respectively. The clip is 81 minutes long.


http://www.sitasingstheblues.com/

http://s.ytimg.com/yt/swfbin/watch_as3-vfl9DouAr.swf

http://www.youtube.com/watch?v=9yiVgXVFChU

http://rtsp//184.72.239.149/vod/mp4:BigBuckBunny_175k.mov

http://rtsp//184.72.239.149/vod/mp4:BigBuckBunny_175k.mov





http://s.ytimg.com/yt/swfbin/watch_as3-vfl60kLQ6.swf

http://s.ytimg.com/yt/swfbin/watch_as3-vfl60kLQ6.swf





Performance. Some playback issues have to do with encoding, while another part is the the

network itself, including network congestion. A third reason is hardware acceleration.

Without hardware acceleration, it’s difficult to even play today’s standard-definition clips, let alone

the high-definition content that most of the new tablets—and even a limited number of handsets—

are geared toward playing.

In our tests, pattern emerged: content delivered in RTMP (the Flash Player "native" protocol) was at

a higher frame rate than content delivered by RTSP but not higher than H.264, the YouTube

"desktop" version of content delivery.

None of the delivery solutions were perfect, by any means. Content played back as RTMP, RTSP

and even HTTP dropped some number of frames for every clip played. That’s to be expected in a

mobile environment, and our test clips were intentionally robust enough to tax the devices, but

several devices just couldn’t muster the performance necessary to play back content

Playback was consistently 2-3 frames per second slower than the original content, when devices

played back RTMP-based delivery of the Sita clip, which was encoded at 23.98 (or 24) frames per

second. On the YouTube press briefing clip, originally encoded at 29.97 frames per second, a few

devices met or exceeded that frame rate for decoding.

Three devices—the Droid 2, Nexus S and Motorola Xoom—failed to meet the full-motion decoding

mark, falling off by numerous frames. As noted in the following table, the Nexus S fell off by six

frames per second for the Sita clip, while the Motorola Xoom fell off three frames per second for

both Sita and the press briefing. Our baseline device, the Droid 2, fell off almost ten frames per

second for Sita.

Xoom’s inability to achieve 100% content playback framerates may be a firmware issue. Xoom’s

initial firmware update is expected to be replaced soon which may, in turn, offer performance

enhancements available within Flash Player 10.2 but not utilized by Xoom’s initial firmware.

HARDWARE

ACCELERATION

Target FPS

(Decode)

Actual FPS

(Decode)

Percentage

of Target

Hardware

Accelerate

Atrix

Droid 2

Droid X

Galaxy S

Nexus S

Xoom (3.0.1)

Xoom (3.1)

23.98 24.11 101% Y

23.98 13.36 56% N

23.98 13.68 57% N

23.98 24.04 100% Y

23.98 18.43 77% N

23.98 21.61 90% N

23.98 23.98 100% Y

The Atrix, Galaxy S and Xoom (the latter using Android OS 3.1) nailed the target frame rate.




It’s easy to see from the preceding table that software-only decodes have a noticeably lower frame

rate, averaging 21 frames per second versus 24 frames per second of hardware assisted playback.

For software-only decoding, video playback is noticeably less fluid but has slightly better battery

life. Yet Xoom, using hardware decoding had only a 10% battery impact difference.

Other devices, such as Droid2 and Nexus S, had 45-50% battery impacts over their testing cycles,

indicating hardware-assisted playback may not directly impact battery life in any meaningful way.

Compatibility. We found not all video content would play on each device, at least until we used

the Flash Player, which displayed the same content across all devices.

For instance, on the Nexus S, we found that the built-in video player would not play RTSP content,

nor could we get that device to play the mobile version of the 4 February 2011 White House Press

Briefing clip either in the built-in YouTube app or the web browser. By contrast, when playing the

“desktop” version of the clip—using Flash Player—the Nexus S played the file with no issues.

In addition, the Sita RTSP clip also wouldn't play on the Droid 2 and Droid X. Once we loaded up

Flash Player and used RTMP to stream the Sita clip to each of these devices, however, every single

device could play back the Sita clip. Our perception is that the issue was not with the streaming

server or clip itself, since RTSP served from the Sita clip played fine on at least half the devices;

rather it appears the issue lies with the native RTSP video player service within Android.

Battery impact. Was there a correlation between a high decoding frame rate and low battery life?

Not exactly. RTSP exhibited the lowest battery of any protocol served from our video server. Only

half of the devices could play our test RTSP file: Atrix, Galaxy S and Xoom. It’s worth noting thatdevices that could not play the Sita file via RTSP—Droid 2, Droid X and Nexus S—also did not

have hardware acceleration for the later RTMP file test. Is there a correlation between Flash Player’s

use of hardware acceleration and an ability to play the majority of RTSP-delivered content?

RTMP, with hardware acceleration, exhibited the best decoded frame rate but had a shorter battery

life. In many instances it was only 15-20 minutes of battery life difference from the RTSP clip.

The following chart shows battery impact for both RTSP and RTMP, as a percentage of the

baseline video clip’s complete cycle from fully charged to fully depleted.

BATTERY IMPACT

BY PROTOCOL

YouTube Mobile

(No Flash)

RTMP

(Flash)

RTSP

(No Flash)

Atrix ATT

Galaxy S

Xoom (3.1)

6:08 75% 85%

6:47 53% 61%

8:21 93% 96%




Next Steps

As mentioned in the first few pages, there’s an upcoming version of Creative Suite (version 5.5)

with several new Flash capabilities, which should allow use to create a more optimized but code

identical version of a large data-set application, to measure extreme memory differences.

We also plan, in a future test, to gauge battery impact of H.264 hardware decoder acceleration

versus software-only decoding for Flash 8 Video (VP6), as well as a comparison of H.264 to WebM

(VP8, a more recent version of the codec used if Flash 8 Video). The test would be carried out with

the exact same content, much as we did the RTMP versus RTSP testing with the Sita clip. We can

also use a series of clips from last summer’s professional encoding / transcoding comparison tests.

Another area to explore is CPU / GPU hardware-assisted transcoding for content to be uploaded

to online video platforms (such as Vimeo or YouTube) in terms of time savings and battery impact.

Conclusion

When it comes to video, Flash Player provided a very consistent user experience. RTMP content

played in-browser took advantage of GPU and hardware acceleration, with limited battery impact.

On the device side, the Motorola Atrix phone rocks—and burns—as it was by far the smoothest

when it came to video playback, animation rendering and game play. Atrix posted animation render

results that were well over twice that of its closest competition, the Xoom. The outcome is a result

of the combined dual-core CPU and a robust GPU—plus years of Motorola handset engineering.

Battery life on the Atrix was also quite good, as noted in the Test Outcomes section. The device’sonly downside was the heat it generated: Atrix became hot to the touch within twenty minutes of

starting animations and video playback, and too hot to hold after thirty minutes of gaming.

Xoom was our first foray into tablet devices; while the initial Android OS 3.0.1 / Flash Player 10.2

didn’t impress us, the update to Android OS 3.1 / Flash Player 10.3 turned in impressive results.

The Nexus S continued to be our problem child in this round of testing, as it was in the initial round.

As such, it is a good example of why Adobe Flash Player and Adobe AIR, at least for the near

future, will be used to generate a consistent media consumption experience.

Just as it did in the initial test round, the current testing shows the Nexus S couldn’t play some

YouTube content as well an inability to play most RTSP content with the built-in video player. We

couldn’t get Nexus S to play the mobile version of our test YouTube clip in either the built-in

YouTube app or the web browser, but we could get it to play content via Flash Player, showing just

how consistent Flash Player was able to perform in a role as universal media player technology

across every single Android device we tested.


http://workflowed.blogspot.com/2010/12/2010-best-workflows.html





Appendix

Baseline and Animation Benchmarks (Battery Impact)

WEBSITE DEVICE CHARGE

No Flash (Google.com) Atrix 9:03

Particle animation tests (HTML) Atrix 4:33

Particle animation tests (Flash) Atrix 3:35

No Flash (Google.com) Droid 2 11:26

Particle animation tests (HTML) Droid 2 4:05

Particle animation tests (Flash) Droid 2 3:25

No Flash (Google.com) Droid X 9:37

Particle animation tests (HTML) Droid X 4:20

Particle animation tests (Flash) Droid X 3:42

No Flash (Google.com) Galaxy S 5:37

Particle animation tests (HTML) Galaxy S 3:06

Particle animation tests (Flash) Galaxy S 2:25

No Flash (Google.com) Nexus S 4:17

Particle animation tests (HTML) Nexus S 2:35

Particle animation tests (Flash) Nexus S 2:30

No Flash (Google.com) Xoom (3.1) 8:52

Particle animation tests (HTML) Xoom (3.1) 6:14

Particle animation tests (Flash) Xoom (3.1) 6:29




Attributions

Android is a trademark of Google Inc., with trademark use subject to Google Permissions. The Android Robot

is a work created and shared by Google and used according to terms described in the Creative Commons 3.0

Attribution License. Adobe Flash Player 10.2 / 10.3 is a trademark of Adobe Systems, Inc. and the Motorola

and Samsung logos are trademarks of each company, respectively. Cameron Adams is creator of Animation

Particle Tests found at www.themaninblue.com. All phone names are registered trademarks of their respective

original equipment manufacturer (OEM) and/or the service providers who engaged the OEM to manufacture a

provider-specific handset.

About the Author

Tim Siglin is a co-founder of Transitions, Inc., holds an MBA with emphasis in entrepreneurship, and serves as

a contributing editor for a variety of tech publications. Siglin has been involved with visual communications for

over fifteen years, including market analysis, implementation and product launches. His key focus is digital

media entrepreneurship, and he has served in executive roles in marketing, strategy and technology. In the

past, he also provided research and consulting services to several Big 5 consulting firms as well as internal

skunk works projects for several Fortune 10 and numerous Fortune 500 clients.

About the Company

Transitions, Inc., is a technology and business development firm with extensive experience in technology de-

sign and go-to-market strategy consulting. Transitions specializing in assistance to businesses seeking to

identify “transition points” that hinder growth or a return to profitability.

Repeat customers account for more than 80% of all on-going business, but Transitions also takes on select

project challenges assisting startups, distressed and expanding small businesses. Based in Tennessee, Transi-

tions’ business strategy and marketing consulting clients include companies in Silicon Valley, Boston, London,

Milan, Mumbai, New York and Switzerland. Ongoing Transitions’ projects include established businesses and

startups in the digital media, financial services and global marketing industries.

© 2011 Transitions, Inc.

http://www.themaninblue.com/

http://www.themaninblue.com/

http://creativecommons.org/licenses/by/3.0/




http://code.google.com/policies.html

http://code.google.com/policies.html

http://www.google.com/permissions/index.html

http://www.google.com/permissions/index.html

20110601 Android FlashPlayer10.2 and 10.3 Xoom

Documents