mobile encoding android v2 7

8/4/2019 Mobile Encoding Android v2 7

1/42

Mobile Encoding Guidelines or Android

Powered DevicesAddendum o Video Encoding Cookbook and Profle Guidelinesor the Adobe Flash PlatormBy Maxim Levkov, Adobe Systems Inc.

Addendum B

PreaceMobile devices are quickly becoming a popular mehod o viewing media conen. This rapid growh

underscores he need or encoding guidelines o ensure ha he conen is opimized or reach and playback

perormance. I is no enough o simply deploy a single video player SWF wih muli-birae conen and expec

a smooh playback experience on devices. For example, accommodaions mus be made or realiies such as

diering device capabiliies, gesure ineracions, screen orienaion, and nework connecion speeds.

There are number o mobile plaorms on he marke oday, bu his documen will ocus speciically on Android

powered devices. Tha being said, many o he general guidelines presened apply o oher plaorms as well. The

coninued evoluion o Flash Player and he availabiliy o increasingly powerul devices pushes video playback o

he op o he lis o mos desired eaures on mobile neworks oday and well ino he uure.

This documen is an addendum o he broader Video Encoding Cookbook and Proile Guidelines or the Adobe

Flash Platorm whie paper. I would be beneicial o reer o ha documen, as well as he Best Practices or

Mobile Device Video Player Optimization addendum also published separaely.

Due o he wide variey o devices in he markeplace, here are wo suggesed approaches o encoding or

mobile delivery. One approach is o arge individual classes o mobile devices, opimizing encoding seings

dierenly or each. The second approach is o service each o he diverse mobile phone devices hrough

universally applicable encoding seings. Each o hese approaches has advanages and disadvanages.

Wih he irs approach, each o he devices unique capabiliies can be aken ino consideraion and speciically

encoded or, hus opimizing he viewing experience and percepual qualiy. This approach is advanageous

when he players logic is se up o eed his speciically encoded conen o ha speciic series o phone

devices, or he aim is o service only an audience wih a cerain ype o device, or even or local playback on

device (e.g. download-o-own). The disadvanage o his approach is is limied reach, mainly due o diering

echnical capabiliies o devices and opimizaion o encoded conen o reach only a speciic device. For

example, a mobile device ha is able o play back video encoded or H.264 Main Proile a Level 3.1 (e.g. high

end class) will no play eicienly or even be recognized on a mobile device ha is able o only suppor H.264Baseline Proile a Level 3.1 (e.g. medium end class), or a device ha is able o suppor only H.264 Baseline

Proile a Level 2.1 (e.g. low end class).

Hence, in he second approach, which akes a more universal syle owards encoding, conen is encoded using

he lowes common se o parameers. The advanage o his approach is o course is broad cusomer reach.

The disadvanage is ha is does no uilize each devices unique capabiliies and maximum playback qualiy.

This ranslaes o reduced picure rame size and percepual qualiy or all viewers bu he lowes-powered

devices. For example, i he group o phone devices includes high end (e.g. H.264 Main Proile a Level 3.1

suppor), medium (e.g. H.264 Baseline Proile a Level 3.1 suppor), and low end (e.g. H.264 Baseline Proile a

Level 2.1 suppor), hen he conen would be encoded using he low end H.264 Baseline Proile a Level 2.1,

since i is suppored by all o he argeed devices.

Addendum

able o Contents

1: Preace

2: Assumpions

2: Video and Audio

Feaures in Flash

or Mobile

3: Device DisplayDiversiy

4: Nework Connecion

Speed

5: Encoding

Consideraions

14: Video Encoding

Consideraions

17: Encoding Varians

23: Deailed AAC/AVC,

Audio Video Setings

42: Conclusion


2/42

2Mobile Encoding Guidelines or Android Powered Devices Whie Paper

Some examples o hese classes o devices* are oulined in Table 1.

Class Descripion

High End Moorola Droid X/Droid 2, HTC Evo, HTC Droid Incredible

Medium End Google Nexus One, Moorola BACKFLIP

Low End Moorola Droid 1, Moorola CHARM

*Tese devices are not exclusive representatives o their respective class o devices, and are presented or illustration purposes only.

able 1

Sample Android powered devices and heir classes.

AssumpionsTechnical sa using his documen should be skilled in he video coding echnology ield.

Qualiy conrol ools, viewing and lisening condiions are esed and calibraed as described in Video Encoding

Cookbook and Proile Guidelines or the Adobe Flash Platorm, using he recommended es paerns and

equipmen.

Coded conen is desined or appropriae compaible soware and/or hardware decoders.

Coding soware and hardware in use is uncioning as saed.

Coding soware and hardware suppors a leas some o he ollowing coding elemens menioned hroughou

his documen

Image Formas

Sizes 128x96 o 1920x1088

Frame Raes 23.976, 24, 25, 29.97, 30, 50, 59.94, 60ps or racion hereo

Aspec Raio 1.33, 1.78, 1.78 AN, 1.85, 2.35, including Leerbox and Pillarbox varians

Color Space YUV 16 -235, Color Marix 601 or 709

Video Sampling Srucure 4:2:0

H.264 Codec Parameer Se

Coding Proiles Baseline, Main

Coding Levels 1 hrough 3.2

A leas one o he ollowing muxing

ormas

F4V, MP4, MOV, 3GGP

A leas one o he ollowing audio

coding ormas

AAC LC, HEAAC v1, HEAAC v2

Video and Audio Feaures in Flash or MobileFlash Player provides acceleraion eaures ha aid in high-qualiy media playback on mobile devices.

Hardware Decoding of AudioHardware audio decoding uses he mobile devices hardware o accelerae audio decoding. Wihou hardwaredecoding, audio decoding is an inensive process ha involves complex parsing and decompression operaions

requiring high CPU cycles and power consumpion.

Hardware decoding provides equivalen uncionaliy o soware decoding in Flash Player wih acceleraed

AAC audio decoding (Main, LC, HE/SBR proiles), and provides he ollowing eaures:

High-qualityaudioplaybackexperience.

OverallreductioninCPUusage,freeingupCPUcyclesforotheroperations,whichinturnimprovesperfor-

mance and batery lie.


3/42


Transparenttotheuser.Ifahardwaredriverisnotavailableortheaudiocodecformatisnotsupportedbythe

device hardware, Flash Player will all back o sofware decoding.

Hardware Decoding of VideoFlash Player 10.1 inroduced hardware-based H.264 video decoding o deliver smooh, high-qualiy video wih

minimal overhead across suppored mobile devices and PCs.

Hardware acceleraed rendering, GPU composiion, and video hardware decoding combine o deliver high

qualiy mulimedia experiences on mobile devices wih suppored hardware. Beneis include:

OoadtasksfromtheCPUtohardware,improvingvideoplaybackperformance,reducingsystemresourceuilizaion, and preserving batery lie.

Deliversmooth,high-denitionvideowithminimaloverheadacrossdevices.

UsenoCPUresourcesforvideoscaling.Audioandvideocanbedecodedpurelyinhardware.

Preservebaerylife.

Device Display DiversiyEarlier, in hepreace, device classiicaion is menioned as a means o ideniying or grouping devices and he

associaed expecaions or H.264 playback perormance or hese devices. I is useul o segmen devices in

his way no only or encoding purposes, bu also or argeing display characerisics.

The ollowing able highlighs some examples o devices and heir classes.

Phone Device ClassDisplayResoluion

AspecRaio

ScreenSize

PixelDensiy

Frequency CPU

Widh x Heigh pixel/inch Mhz

Moorola Droid X High

End

854 x 480 1.78:1

(16:9)

4.3" 228.3 1000 TI OMAP3630

Moorola Droid 2 High

End

854 x 480 1.78:1

(16:9)

3.7" 264.7 1000 TI OMAP3620

Moorola Droid Pro High

End

480 x 320 1.5:1

(15:10)

3.1 185.5 1000 TI OMAP3620

HTC Evo High

End

800 x 480 1.67:1

(15:9)

4.3" 217.4 1000 Qualcomm

SnapdragonQSD8650

HTC Droid

Incredible

High

End

800 x 480 1.67:1

(15:9)

3.7" 252.1 1000 Qualcomm

Snapdragon

QSD8650

S ams ung G alaxy S High

End

800x480 1.67:1

(15:9)

4.0 235.1 1000 Samsung-Inrisiy

S5PC110

Google Nexus One Medium

End

800 x 480 1.67:1

(15:9)

3.7" 252.1 998 Qualcomm

Snapdragon

QSD8250

HTC G2 Medium

End

800 x 480 3.7 252.1 800 Qualcomm

MSM7230

Moorola B ack lip MediumEnd

480 x 320 1.5:1(15:10)

3.1" 185.5 528 QualcommMSM7200A

Moorola Droid 1 Low End 800 x 480 1.67:1

(15:9)

3.7" 266.7 600 TI OMAP3430

Moorola Charm Low End 320 x 240 1.33:1

(4:3)

2.6" 143.1 600 TI OMAP3410

able 2

Examples o device classes.


4/42


Alhough all o he devices in he previous able are able o display H.264 encoded video, and hey even exhibi

some display similariies across dieren classes, each device sill has unique combinaion o speciicaions

such as screen size and pixel densiy. These similariies and dierences make encoding conen or mobile

delivery diicul. Wha is opimally encoded or High End class display and processing capabiliies (e.g. HTC

Evo, Moorola Droid X, ec. a 800x480, 854x480) may no display on all Medium End class devices (e.g.

Moorola Backlip a 480x320), and also on Low End class display and processing capabiliies devices (e.g.

Moorola Charm a 320x240). For medium and low end class devices, he processor will be axed when rying

o display conen encoded a higher resoluions. For devices wih higher display resoluion, down-scaling can

cause processing issues and scaling up he lower resoluion conen resuls in a noiceably lower qualiy image.

Taking a closer look a he display resoluions o he classiied devices provides clear guidelines or encoding

conen ha plays well across devices.

Figure 1 depics he device resoluion, rom Table 2, in 1 o 1 pixel relaionship.

854

800

480 320

480

MOTOROLA DROID/DROID2/DROID X

320

240

GOOGLE NEXUS ONE

HTC Evo

HTC Droid Incredible

MOTOROLA BACKFLIP

MOTOROLA CHARM

Figure 1

Device resoluion rom able 2, in 1:1 pixel relaionship.

Wha makes he resoluion o he display i he size o he display is he areal densiy o pixels wihin given

physical display size in pixel per inch raio. Alhough his pixel densiy is no somehing ha can be conrolled by

he user or encoder, he picure size and picure aspec raio o he encoded video is in he conrol o he encoder.

Nework Connecion SpeedAnoher crucial elemen in high qualiy playback on mobile devices is he end users connecion speed. For

example, encoded conen ha is inended or delivery over broadband connecions will no work eicienly

over 3G neworks due o heir lower bandwidh capabiliies. The end user connecion ha you decide o arge

will guide your encoding seings. Working wihin he boundaries o available nework bandwidh or heargeed audience, while allowing or abou 10-20% headroom or nework lucuaions, is ypically a good

guideline o use as a saring poin or opimal video playback. For example, i you deermined hrough various

means ha he end users are only able o receive 500kbps o bandwidh, encoding or bandwidh o 800kbps

will no yield a good playback experience. Alhough, 800kbps can sill be delivered i using progressive

delivery, bu playback will suer i he video daa isn being received as enough, or when he devices buer

is ull. So, while considering delivery o end user wih 500kbps connecion speed, encoding exacly a a birae

o 500kbps will no provide a good experience eiher, as nework condiions end o be unpredicable. This is

where he reducion o encoded daa payload by 10-20% will play ino eec. For 500kbps, i will be 400

450kbps eecive oal birae (i.e. audio and video combined).


5/42


The ollowing able provides ypical speed esimaes o various neworks, giving you a saring poin or

argeing bandwidh values.

EDGE Peak biraes o up o 1Mbi/s and ypic al birae s o 400kbi /s c an be expec ed .

3G Typical curren average download speed is beween 600 Kbi/s 1.4 Mbi/s.

4G Typical curren average download speed is beween 3 Mbi/s 6 Mbi/s.

HSPA+ Peak daa raes up o 56 Mbi/s in he downl ink in heory (up o 28 Mbi/s in exis ing services)

and up o 22 Mbi/s in he uplink.

WiFi Peak daa raes up o 300 Mbi/s bi-direcionally.

Source: Wikipedia.org. For general reerence only; actual rates may vary by network provider.

able 3

Speed esimaes o various neworks.

Encoding ConsideraionsFor more deailed explanaion on how o prepare your conen or highes qualiy playback, reer o Video

Encoding Cookbook and Proile Guidelines or the Adobe Flash Platorm, available or download a

hp://www.evensadobe.com/cookbook .

The ollowing en guidelines should be ollowed when encoding conen inended or mobile devices:

1. Keep he conen in progressive oupu mode. Deinerlace whenever possible. Use Moion Compensaed

deinerlacing or bes resuls. I no possible, use Moion Adapive deinerlacing insead.

2. Usecontentthatwasdeliberatelyshotforsmallerscreensforbestuserexperienceanddelity.Ifnot

possible,scalewithmulti-taplters(10tapsormore).ehigherthetapthegreaterthesamplingarea(itis

presumedthatthelterissophisticatedenoughtoextractthenecessaryinformationtoresampleabeer

newimage).Highqualityscalingltersutilizeahighersamplingareafromsurroundingpixels(10ormore)

and,thus,areabletoderivehigherqualityoutput.Lowerqualityscalinglters(2-4taps)createmediocre

results,withimagesoenbeingsoandblurry.Lowerlterresultsmaybeacceptableforplaybackonthe

larger screen sizes o deskop compuers, bu will resul in very poor picure qualiy on he smaller screen

sizesofmobiledevices.Lowerendltersarefasterthanhigherendltersduetheirsmallersamplingarea.

Wheneverpossibleandifavailable,usehighqualityscalinglters.

3. Mainain he aspec raio o he original video.

4. Keep he rame size in muliples o 16 o avoid unnecessary perormance degradaion or CPU consumpion.

I no possible, resor only o muliples o 8, no 4.

5. Ifthetranscoder/encodersupportstwopasscoding,useit.Typicallyatranscoder/encoderwillusetherst

passtoindexcomplexscenesandusethesecondpassforactualencoding.isprocessprovidesthebest

predicabiliy or he coder and, consequenially, beter oupu resuls. Depending on he complexiy o he

video, he percepual video qualiy resuls rom single pass o wo pass encoding can vary as much as

1030 percen, a valuable gain given he scarciy o birae resources.

6. Calibrae your Qualiy Assurance monioring equipmen or accurae represenaion o he oupu. (For

more inormaion on calibraion and qualiy measuremen, reer o he Video Encoding Cookbook andProfle Guidelines or the Adobe Flash Platorm whie paper.)

7. I he H.264 encoder suppors look_ahead logic, use i. Speciy a lames or greaer, i coder permis.

8. Do no use conen encoded a a larger rame size and hen scale i down in he player. Creae separae

versions a he designaed rame sizes a encoding or creaion ime. I higher rame size conen is used, he

device will atemp o scale i down, consuming excess CPU resources as much as 40% in some cases.

isslowsperformanceofthedevice,reducesbaerylife,anddegradestheoverallplaybackexperience.
http://www.eventsadobe.com/cookbookhttp://www.eventsadobe.com/cookbook


6/42


9. Do no use muliple slices mode in H.264. Insead, use 0 slices or 1 slice, or disable i all ogeher. I slices

are presen in he video, he decoder will atemp o reproduce hem while consuming unnecessary CPU

resources.

10.Ifyoursourceisinterlacedanditneedstobescaled,deinterlacerstthenscalesecond.

SourceFor bes possible resuls, make sure ha your source maerial is he highes qualiy available. I is srongly

suggesed ha he original uncompressed source media ile be used as an encoding source. Alhough his

uncompressed media occupies considerably more disk space han a compressed (lossy) orma, he encoding

resuls are subsanially beer in qualiy han rom a compressed source ile regardless o he level ormehod o compression. Because subsequen conversions will always exponenially decrease he sound and

image qualiy, saring rom a prisine and uncompromised video and audio ile will ensure he bes oupu or

he inal version.

Once you have a source o work wih, properly ormaing i or mobile delivery is as imporan as he qualiy o

he source isel. This process involves resizing he original o a smaller rame size and compressing he video

wih mobile-riendly H.264 seings.

Picture Frame SizesEarlier, he secion or Device Display Diversitydeailed he impac rame sizes can have on perormance o

various classes o mobile devices. The highes display size or Android powered devices is 854x480 a 1.78:1

aspec raio. The curren highes display size on non-Android powered phone devices is 960x540 pixels (no

including ables).

When encoding or mobile devices i is imporan o minimize he impac on he processor by respecing he

codecs opimal macroblock division o 16x16 pixels, while mainaining source picure aspec raio.

Addiionally, i is imporan o ensure ha he picure alls wihin he maximum display size o he argeed

device or group o devices.

Mos mobile devices allow displaying conen eiher in landscape (horizonal) viewing mode or in porrai

(verical) viewing mode.

854

480

800

9

16

854

480

800

9

16

HORIZONTAL VERTICAL

Figure 2

Horizonal and verical screen sizes. Tis di splay exibiliy creaes a echnical challenge in rendering he experience in verical and horizonal

posiioning modes.


7/42


Horizontal (Landscape) Screen PositioningI he maximum horizonal display sizes o your argeed devices are 854x480 and 800x480 here are wo

possible soluions or encoding opimal conen wih various picure aspec raios.

768

432

854

480

800

9

16

Figure 3

Opimal 16:9 aspec raio conversion or screen heigh o 480 pixels.

The rame size choice or his example, depiced in Figure 3, would be 768x432 because i is an exac 16x16

macroblock division and 1.777 (e.g. 16:9) aspec raio. I also is wihin he boundaries o he lowes resoluion

(800x480) o he wo (854x480 and 800x480).

Soluion one encodes he video wih exac 16x16 macroblock division and exac maching aspec raio (e.g.

16:9, 1.777:1) o he highes display size (e.g. 854x480) o he arges. The video is hen scaled to fit the

display, edge-o-edge, by he phone and player via ull screen mode or he 854x480 size; and or he lower

size o 800x480 he video is scaled o mach he widh o he player wih he remaining heigh dierence being

illed wih black bars on he op and boom (leerbox).


8/42


768

432

854

480

800

9

16

Figure 4

Scaling o 768x432 encoded picure size o f 854x480 display size in f o screen mode, while mainaining 16:9 original picure aspec raio. Tepicure is scaled by 11.198% rom original picure size.

768

432

854

480

800

9

16

OUTSIDE OF 800 X 480 RESOLUTION DISPLAY BOUNDARIES, FOR PRESENTATION ONLY

LETTERBOXBLACK

BARS

450

Figure 5

Scaling o picure encoded a 768x432 sized o f 800x480 display size. Acual fted picure size i s 800x450 a 16:9 original picure aspec raio, heremaining area o 30 pixels (480-450) is flled wih black bars, hereore orming a leterbox. Te picure is scaled by 4.167% rom he original picure

size (black bars excluded).

Soluion wo, like soluion one, encodes he video wih exac 16x16 macroblock division and exac maching

aspec raio (e.g. 16:9, 1.777:1) o he highes display size (e.g. 854x480) o he arges. The video is hen

displayed in naive source resoluion wih pillar and leerbox black bars illing he balance o he screen

resoluion or eiher 854x480 or 800x480 size.


9/42


768

432

9

16

854

480

800

PILLARBOX BLACK SIDE PANELS

LETTERBOXBLACKBARS

Figure 6Naive resoluion o picure encoded a 768x432 encapsulaed by he pillarbox black side panels and leterbox black bars wihou any scaling.

The presenaion eec o his ype is reerred o as a posage-samp in exreme cases when he picure is

reduced by nearly hal o he screen and black bars occupy abou hree quarers o he screen, bu no in he

case depiced in Figure 5. Alhough, in his case i avoids scaling and reains minimal impac on he processing,

usually i is no very appealing o he viewer. Try o resor o his ype o presenaion only in cases where you

are concerned abou he processing impac o scaling up. Noice ha scaling up has less impac on he

processing perormance versus scaling down, due o he use o an addiive scheme in scaling up mode and a

deducive scheme in scaling down mode.

Vertical (Portrait) Screen PositioningWhen he viewer posiions he device in such a way ha i riggers verical rendering o he screen, he video is

scaled and ormaed o play back horizonally wihin he heigh and widh boundaries o he screen. Since

verical posiioning o he screen (as shown in Figure 2) signiicanly reduces available space or viewing he

acive video window, here are hree possible approaches:

Simplyscaletheexistingvideototthemaximumwidthandheighttotwithintheboundariesofthedevice,

bu a he cos o even more reduced objecs in he video.

Requestthepre-encodedvideothattswithintheboundariesofthescreen

Fitthevideotothescreendimensionswithoutapplyingscaling.

In mos cases verical posiioning o he screen will creae a perec case or use o video wih 4:3 picure

aspec raio and muli-birae delivery.

Scenario one uses horizonally rendered video or verically riggered posiioning on he screen wih scalingdown o verical boundaries o he device, as depiced in he ollowing picogram. However, his approach

reduces he objecs on already small screen o even smaller picure wih reducing he objecs urher, hus

making hem harder o see. Addiionally, such scaling process pushes he perormance on he device o

subopimal sae because i requires he use o unnecessary CPU resource or scaling ha video. Also, he same

amoun o bis is piped down he nework pipeline unnecessarily. For example, he video encoded or horizonal

display a 16:9 picure aspec raio, and sized o i wihin he boundaries o he devices screen resoluion, such

as 768x432 is encoded or 854x480 screen size, i will render a scaled 480 in widh and corresponding heigh o

480x854 screen size in verical posiion, or abou 480x270 (a widh x heigh) video resoluion.


10/42


16:9

768

432

854

480

800

9

16

16:9

854

480

800

9

16

HORIZONTAL VERTICAL

270

480

Figure 7

Fiting 16:9 aspec raio video in verical screen posiion rom horizonal posiion.

Scenario wo uses pre-encoded sreams o i he verical posiioned screen whenever he device is roaed o

he verical orienaion. This approach is more complex han he irs scenario, because i requires player logic

o accommodae he dieren device posiion rendering whenever i is urned rom horizonal o verical sae

and vice versa. However, his scenario provides opimizaion on display o he video, reduced bi consumpion

due o reduced naive video resoluion requiremens. This case also calls or use o 4:3 picure aspec raio

insead o 16:9, because i covers larger viewable area. For example, i video is encoded or horizonal display

a 16:9 picure aspec raio, and sized o i wihin he boundaries o he devices screen resoluion, such as

768x432 (16:9) is encoded or 854x432 screen size, i will render a 480x360 (4:3) rom a separae sream a

reques o a player o i he verical posiion o 480x854 screen size.


11/42


16:9

768

432

854

480

800

9

16

4:3

854

480

800

9

16

HORIZONTAL VERTICAL

360

480

Figure 8

Fiting 4:3 aspec raio video in verical scr een posiion rom 16:9 horizonal posiion.

Scenario hree is very similar o scenario wo wih one excepion i does no scale video o i he screen, bu

raher keeps i in is naively encoded resoluion.

Example Video Sizes for Horizontal and Vertical OrientationsThe ollowing ables provide example picure sizes and corresponding perormance or an example device

display wih he ollowing speciicaions:

Horizontalorientation:Maximumscreensizeof854x480(16:9aspectratio)

Verticalorientation:Maximumscreensizeof480x854(9:16aspectratio)


12/42


Verical Screen Orienaion (Porrai)

Picure Size (Widh x Heigh) Picure Aspec Raio Divisibiliy Perormance

32 x 24 4:3 8x8 Good

64 x 48 4:3 16x16 Bes

97 x 72 4:3 8x8 Good

128 x 96 4:3 16x16 Bes

160 x 120 4:3 8x8 Good

192 x 144 4:3 8x8 Good

224 x 168 4:3 8x8 Good

256 x 192 4:3 16x16 Bes

288 x 256 4:3 8x8 Good

320 x 240 4:3 16x16 Bes

352 x 264 4:3 8x8 Good

384 x 288 4:3 16x16 Bes

416 x 312 4:3 8x8 Good

448 x 336 4:3 16x16 Bes

480 x 360 4:3 8x8 Good

128 x 72 16:9 16x16 Bes

256 x 144 16:9 16x16 Bes

384 x 216 16:9 16x16 Bes

144x256 9:16 16x16 Bes

216x384 9:16 8x8 Good

288x512 9:16 16x16 Bes

360x640 9:16 8x8 Good

432x768 9:16 16x16 Bes

able 4

Video sizes or verical orienaion.


13/42


Horizonal Screen Orienaion (Landscape)

Picure Size (Widh x Heigh) Picure Aspec Raio Divisibiliy Perormance

32 x 24 4:3 8x8 Good

64 x 48 4:3 16x16 Bes

97 x 72 4:3 8x8 Good

128 x 96 4:3 16x16 Bes

160 x 120 4:3 8x8 Good

192 x 144 4:3 8x8 Good

224 x 168 4:3 8x8 Good

256 x 192 4:3 16x16 Bes

288 x 256 4:3 8x8 Good

320 x 240 4:3 16x16 Bes

352 x 264 4:3 8x8 Good

384 x 288 4:3 16x16 Bes

416 x 312 4:3 8x8 Good

448 x 336 4:3 16x16 Bes

480 x 360 4:3 8x8 Good

512 x 384 4:3 16x16 Bes

544 x 408 4:3 8x8 Good

576 x 432 4:3 16x16 Bes

608 x 456 4:3 8x8 Good

640 x 480 4:3 16x16 Bes

672 x 504 4:3 8x8 Good

704 x 528 4:3 16x16 Bes

736 x 552 4:3 8x8 Good

768 x 576 4:3 16x16 Bes

128 x 72 16:9 16x16 Bes

256 x 144 16:9 16x16 Bes

384 x 216 16:9 16x16 Bes

512 x 288 16:9 16x16 Bes

640 x 360 16:9 16x16 Bes

768 x 432 16:9 16x16 Bes

able 5

Video sizes or horizonal orienaion.


14/42


Video Encoding ConsideraionsEncoding video or delivery o he ever-increasing variey o devices quickly becomes a complex ask. Applying

classiicaions o groups o devices can help simpliy his process. This can be done by argeing proile and

level seings, and assigning High, Medium and Low End classiicaions o devices.

Profile and Level SettingsWih all he elemens ha go ino encoding he opimal video, H.264 Proile and Level seings or he argeed

device are wo key elemens ha are oen overlooked.

Level Max macroblocks Max video bi rae (VCL) Examples or high resoluion @ rame rae

per second per rame B P, X P, MP (kbi /s) HiP (kbi /s) (max sored rames)

1 1,485 99 64 80 [email protected] (8)

[email protected] (4)

1b 1,485 99 128 160 [email protected] (8)


1.1 3,000 396 192 240 [email protected] (9)



1.2 6,000 396 384 480 [email protected] (7)


1.3 11,880 396 768 960 [email protected] (7)[email protected] (6)

2 11,880 396 2,000 2,500 [email protected] (7)


2.1 19,800 792 4,000 5,000 [email protected] (7)


2.2 20,250 1,620 4,000 5,000 [email protected](10)




3 40,500 1,620 10,000 12,500 [email protected] (12)


[email protected] (6)[email protected] (5)

3.1 108,000 3,600 14,000 17,500 [email protected] (13)



3.2 216,000 5,120 20,000 25,000 1,[email protected] (5)

1,280_1,[email protected] (4)

able 6

able excerp rom Wikipedia.com (htp://en.wikipedia.org/wiki/H.264/MPEG-4_AVC) on limis correlaed o H.264 profle and level.

High End vs. Medium and Low End

Classiicaion o devices as High, Medium, and Low End is mainly aimed a raing heir perormance capabiliiesor decoding video, wihin he mobile device marke.

Low and Medium End devices, unlike he High End, have lower video processing resources and hereore

encoding seings ha arge hese devices should be adjused accordingly. Consrains are mainly physical and

limied o memory capaciy o sore video rames, CPU processing requency (ypically associaed wih speed),

and wheher or no a separae video and graphics processing uni is insalled. Flash Player does no pu any

resricions on he playback on he a paricular device, and echnically, you can play back your video aimed or

he High End class o devices wih more processing capabiliies, bu your playback perormance will suer.

Unlike deskop playback, mobile video playback requires he need or device classiicaions so ha he

encoding is opimized o bes service hese arges.
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVChttp://en.wikipedia.org/wiki/H.264/MPEG-4_AVC


15/42


Low and Medium End devices are bes serviced by Baseline Proile wih range o Level 2.0 o 3.1 wih up o wo

reerence rames on average.

High End devices, on he oher hand, oer higher processing speed, higher screen resoluion and pixel densiy,

and access o higher nework speeds. While hese aspecs o er a myriad o possibiliies or users, he video

encoding or argeing hese devices is also more advanced. O course, he video ha is encoded or he Low

and Medium End device range will sill play back eicienly on High End devices, he inverse is no rue when

video is encoded or High End devices and played back on Low and Medium End devices.

High End devices are able o playback High and Main proile encoded video a Levels up o 3.2 wih B-rame

suppor or added encoding eiciency. However, despie such advances and expanded video processinguncionaliy on High End mobile devices, he need o opimize or argeed devices capabiliies sill exiss,

even a he High End device level.

UniversalWheher he encoding is aimed or he Low, Medium, or High End class o devices, he need o service various

classes o devices individually may limi overall reach. When he need o reach wide span o devices exiss, he

approach could ake one o wo pahs one ha is simplisic and second one ha is more complex.

For he simplisic approach, he encoding is argeed using he lowes common proile and level (e.g. Baseline

a Level 2.1, or Baseline a Level 3.0), respecive o he proile and level resricions. This provides a relaively

simple approach o he encoding and player developmen and provides playback compaibiliy or many

devices in he arge range, however, i does no ake advanage o he poenial or higher qualiy and birae

on High End devices.

For second approach is more complex. The encoding is argeed or all devices in range wih opimizaion or

each class o devices wih speciic proiles and levels, along wih ample player heurisics wih comprehensive

deecion logic. This approach may include a se o videos encoded or he Low End class wih Baseline proile

a Level 2.1, Medium End class wih Baseline proile a level 3.0, and High End class wih Main proile a Level

3.2. The player logic would be able o eecively deec he devices capabiliies and eed he appropriae video

o ha device. This approach is more complex o develop, bu i oers he bes possible playback on he wides

range o devices. Also, his approach may include suppor or all back o a universal, low qualiy video ha can

be played back on all devices, such as described in approach one.

Audio Encoding ConsiderationsSince video daa consumes he majoriy o alloed bandwidh and mus conorm o he decoding capabiliy o

he device, audio encoding is ypically relegaed o secondary prioriy. This guide mainly ocuses on he

Advanced Audio Coding (AAC) codec, even hough oher audio codecs and coding modes are available. When

bandwidh and processing power is limied on arge devices, choosing he righ AAC coding mode will give

your viewers he bes possible audio playback experience.

The AAC codec has evolved since is incepion and is now suppored by many devices hrough embedded

hardware or naively via soware in he operaing sysem (e.g. Android OS). Flash Player akes advanage o

hese OS soware and hardware capabiliies. However, no all devices have suicien resources o decode all

o he variaions o AAC coding modes. For insance, a device ha would be able o decode AAC-LC (low

complexiy) coding would no necessarily be able o decode HE-AAC v2 SBR +PS coding (see Table 4 or

acronym descripions), because i requires more processing resources despie i being a leas wice as eicien

in coding as AAC-LC.

Jus because here is hardware acceleraion or decoding H.264 video, does no necessarily mean ha hardware

decoding o audio will be as eicien as video decoding. Depending on he complexiy o your conen and

desired audio ideliy in playback on he device, you migh wan o selecively choose he desired birae vs.

coding mode (see Table 7 or an overview o suggesed encoding seings or various ypes o audio conen).


16/42


Narraion Mixed Music

Sampling Rae 22.5kHz 44.1kHz 44.1kHz

Birae 48 128 160

Codec AAC LC AAC LC AAC LC

able 7

Suggesed encoding setings or various audio conen ypes.

For example, i your audio rack is a narraive wih no complex scenes (e.g. overlapping sounds, explosions,ec.) and overall audio/video birae is limied o 500kbis per second, i would be advisable o reduce he

sampling rae o 22.5kHz a a birae o 48kbis per second using AAC LC coding mode, leaving 452kbis or

video. I your audio rack is a mix o di eren ypes o audio scenes, hen a sampling rae o 44.1kHz a a birae o

128kbis per second using AAC LC coding mode would be beer, leaving 372kbis or video. I your audio rack

consiss o music, and he overall audio/video birae is limied o 500kbis per second, a sampling rae o 44.1kHz

a birae o 160kbis per second using AAC LC coding mode would be advisable, leaving 340kbis or video.

Choosing AAC LC will provide adequae playback perormance and compaibiliy across many devices.

However, as you may have noiced, i does no always provide an opimal balance beween video and audio

daa wihin he overall birae. In he case o relaively small birae arges, video suers immensely due o he

diminishing birae allocaed or i in relaion ha allocaed o audio.

As you deermine your se o biraes or muli-birae delivery, variaions in audio biraes and sampling raeswill play a criical role in he smoohness o swiching beween sreams as condiions change. For he bes

birae swiching perormance o audio, he audio sampling rae should be he same in all birae segmens,

because he decoder will no need o use processing cycles o adjus o he change.

Conversely, choosing High Eiciency AAC coding will urher enhance your users audio experience wih

reduced audio birae requiremens, and will allow you o allocae more remaining bis or video. Choosing

HE-AAC v2 (SBR) wih 64kbis per second or 48kbis per second will help saisy your birae requiremen

while allowing you o reain higher sampling rae han AAC-LC will need or he low bandwidh arge.

However, choosing HE-AAC v2 SBR+PS may require more processing cycles on he end user device, unless

here is a hardware suppor or i. In his case, he soware will use processing cycles, inhibiing synchronous

perormance while aking cycles needed or video decoding. So choose his mode sparingly. Typically, he

audible qualiy o HE-AACv2 (SBR) a 64kbis per second would be equal o he audible qualiy o AAC-LC a

128kbis per second.

See hp://en.wikipedia.org/wiki/HEAAC or any speciic reerences o he HE-AAC audio sandard.

CODEC BITRATE

AAC LC 48 56 64 80 96 112 128 160

HE-AAC v1 (SBR) 40 48 56 64 80 96 112 128

HE-AAC v2 (SBR) 40 48 56 64 80 96 112 128

HE-AAC v2 (SBR + PS) 40 48

Te acronyms used in this table are:

AAC Advanced Audio Coding

AAC-LC Advanced Audio Coding Low Complexity

HE-AAC v1 High Efciency Advanced Audio Coding version 1HE-AAC v2 (SBR High Efciency Advanced Audio Coding version 2 (Spectral Band Replication)

HE-AAC v2 (SBR + PS) High Efciency Advanced Audio Coding (Spectral Band Replication + Parametric Stereo)

able 8

Commonly used audio biraes wih A AC/HE-AAC encoding.
http://en.wikipedia.org/wiki/HEAAChttp://en.wikipedia.org/wiki/HEAAC


17/42


Typical Audio Frequencies (in samples per second)

8,000 Hz or 8kHz

11,000 Hz or 11kHz

16,000 Hz or 16kHz

22,500 Hz or 22.5khz

24,000 Hz or 24kHz

32,000 Hz or 32kHz

44,100 Hz or 44.1kHz

48,100 Hz or 48kHz

able 9

Commonly used audio requencies.

TestingOnce you have deermined all o he necessary elemens or your inal oupu o mobile devices i is suggesed

ha you inspec your selecion wih argeed devices beore releasing i or general use and even beore

developing player logic. Playing sreams, one a a ime, using progressive or sreaming delivery o make sure

ha you are seeing he desired oupu will ensure he playabiliy o your media on he arge device. This sep

will reduce roubleshooing ime laer, when you begin o ransiion o muli-birae encoding and delivery.

The aricle Beginners guide o deploying video on mobile devices wih Flash by Jens Loeler ( hp://www.

adobe.com/devne/devices/aricles/deploy_video_mobile.hml ) provides guidelines or developing and

deploying basic players or mobile devices. Also reer o he Best Practices or Mobile Device Video Player

Optimization addendum or addiional guidelines and recommendaions.

Encoding VariansEarlier in he guidelines, various operaing saes or mobile devices were ideniied. The ollowing igure

(Figure 9) shows how suppored device operaing saes and argeed perormance can dicae encoding

parameers. When you creae ses o asses opimized or cerain operaing and perormance saes, he

conen mus graceully saisy various oher operaing condiions o ensure he bes playback experience or

he end user.

Device operaional sae ypically reers o one o wo modes: landscape mode, where he device is posiioned

horizonally; and porrai mode, where he device is posiioned verically.

There are wo ways o display a video in landscape mode: ull screen and in-page:

Full screen Videollsthescreenentirely.Fullscreenmodecaneitherbescaledupfromasmallersize

video(throughforcedfullscreenmodeinplayer)oritcanbeapredenedsizethatissimplyencodedtot

thefulldimensionsofthedevicescreen.isseparatelyencodedstreamwouldbedeliveredwheneverfull

screen mode is requesed.

In-page viewVideodoesnotlltheentirescreen,sometimesremainingwithinthebrowser.Whileinhori -

zonal orienaion he video can be displayed in he in-page sae where i simply remains wihin he

boundaries o he browser, unscaled. Using in-page view is coningen upon he naure o he oher elemens

ha need o be displayed, and upon he perormance sae characerisics o he device.

Anoher operaing sae o he device is porrai mode. In his verical orienaion, here are hree ways o

display a video:

Pseudo-full screenVideoisedtole,right,andtopedgeofthescreen,orleandrightedgeofthe

screen

In-page Video is displayed wihin he boundaries o he web browsers page, un-scaled

Full screenVideoisscaledtolltheentirescreen,edgetoedgeonallsides.
http://www.adobe.com/devnet/devices/articles/deploy_video_mobile.htmlhttp://www.adobe.com/devnet/devices/articles/deploy_video_mobile.htmlhttp://www.adobe.com/devnet/devices/articles/deploy_video_mobile.htmlhttp://www.adobe.com/devnet/devices/articles/deploy_video_mobile.html


18/42


PORTRAIT MODELANDSCAPE MODE

DEVICE OPERATING STATE

FULL SCREENIN-PAGE

PSEUDO

FULL

SCREEN

IN-PAGE

PERFORMANCE STATE

ENCODING VARIANTS

AVAILABLE BANDWIDTHNETWORK CONDITIONDEVICE PERFORMANCE

FULL

SCREEN

Figure 9

Various video playback saes ha dicae encoding varian requiremens or devices.

To summarize, he ive viewing saes o devices include:

1. Landscape in-page2. Landscape ull screen

3. Porrai in-page

4. Porrai pseudo ull screen

5. Porrai ull screen

The perormance saes depiced in Figure 9 consis o hree elemens ha ypically deermine operaing

saes. These elemens are device perormance, nework condiions, and availabiliy o bandwidh. Added o

he operaing sae, he perormance sae helps o esablish he number o rendiions needed o graceully

reac o changes in device perormance, nework condiions, and available bandwidh. Delivering an opimal

viewing experience or devices requires speciic coding varians and ses o encoded iles.

Device perormance is a key acor in deermining opimal H.264 encoding seings.

Nework condiions are anoher acor. Changes in nework condiions deermine he number o rendiions

needed and heir birae proximiy rom each oher. Video picure size can also be a variable when preparing

muli-birae conen.

Availabiliy o bandwidh is a acor ha is closely relaed o nework condiions, bu relaes more o he

maximum bandwidh available or video delivery on he device in any given momen (e.g while user is

muliasking). The maximum bandwidh measuremen helps o esablish he minimum and maximum birae

boundaries or he encoder o adhere o.


19/42


Given he above consideraions, he ollowing varians have been developed. These varians can be used as-is

or modiied o i your speciic needs.

Varians 1 hrough 5 limis he bandwidh use below 1000 Kbis/s, whereas varians 6 9 limis he op

bandwidh cap a above 1000 Kbis/s hrough 2500 Kbis/s.

Each o he ollowing varians highlighs he recommended connecion ype and device class. Noe ha

varians 1 hrough 5 arge various ranges o devices and connecions, so long as hey are able o consume

ewer han 1000 Kbis per second o bandwidh hrough available neworks.

Varian 6 inroduces biraes above 1000 Kbis/s or devices in low, medium, and high classes o devices. Thelower limi in his varian is moved o 250 Kbis per second.

Varian 7 mainly arges devices in medium and high classes and are able o consume 600 Kbis/s on he

boom o he birae range and 1864 Kbis/s a he op o he birae range.

Varian 8 combines a boom birae range o 80 Kbis/s hrough a op birae range o 2500 Kbis/s or low,

medium, and high device classes. Varian 9 arges he high end class o devices wih a low birae range o 400

Kbis/s and high birae range o 1900 Kbis/s.

Varians 1 hrough 8 are based on Baseline proile, wih levels ranging rom 2.1 o 3.1. Varian 9 is based on

Main proile.

Varian 1

Mobile (Android)

Conn. Type EDGE, 3G, 4G, WiFi

Device Class LOW, MEDIUM, HIGH

16x9

Sream # Picure Size V A AV

H.264 HEAACv2

EDGE 1 128x72 56 24 80

EDGE 2 128x72 86 64 150

3G 3 256x144 186 64 250

3G 4 512x288 336 64 400

3G 5 512x288 536 64 600

4G, WiFi 6 640x360 736 64 800

Varian 2

Mobile (Android)



16x9

Sream # Picure Size V A AVH.264 HEAACv2

EDGE 1 128x72 56 24 80

EDGE 2 128x72 86 64 150

3G, 4G 3 256x144 186 64 250

3G, 4G 4 256x144 336 64 400

3G, 4G 5 512x288 536 64 600

WiFi 6 512x288 736 64 800


20/42


Varian 3

Mobile (Android)

Conn. Type 3G, 4G, WiFi


16x9


H.264 HEAACv2

3G 1 256x144 202 48 250

3G 2 256x144 302 48 350

4G 3 256x144 402 48 450

4G 4 512x288 602 48 650

WiFi 5 512x288 702 48 850

WiFi 6 512x288 902 48 950

Varian 4

Mobile (Android)



16x9


H.264 HEAACv2

3G 1 256x144 202 48 250

3G 2 512x288 302 48 350

4G 3 512x288 402 48 450

4G 4 512x288 602 48 650

WiFi 5 512x288 702 48 850

WiFi 6 512x288 902 48 950

Varian 5

Mobile (Android)



16x9


H.264 HEAACv2

EDGE 1 (LOW) 128x72 56 24 80

EDGE 2 (LOW) 128x72 86 64 150

EDGE 3 (LOW) 256x144 186 64 250

3G 4 (MED) 512x288 336 64 400

3G 5 (MED) 512x288 536 64 600

4G, WIFI 6 (HIGH) 512x288 736 64 800


21/42


Varian 6

Mobile (Android)



16x9


H.264 HEAACv2

3G 1 (LOW) 256x144 202 48 250

3G 2 (LOW) 256x144 352 48 400

4G 3 (MED) 512x288 552 48 600

4G 4 (MED) 512x288 752 48 800

WIFI 5 (HIGH) 512x288 952 48 1000

WIFI 6 (HIGH) 512x288 1252 48 1300

Varian 7

Mobile (Android)


Device Class MEDIUM, HIGH

16x9


H.264 HEAACv2

3G, 4G 1 512x288 536 64 600

4G, WIFI 2 512x288 836 64 900

4G, WIFI 3 512x288 1000 64 1064

4G, WIFI 4 512x288 1200 64 1264

4G, WIFI 5 512x288 1500 64 1564

4G, WIFI 6 512x288 1800 64 1864


22/42


Varian 8

Mobile (Android)

Conn. Type EDGE, 3G, 4G, WIFI


16x9


H.264 HEAACv2

EDGE 1 128x72 56 24 80

EDGE 2 128x72 86 48 150

EDGE 3 256x144 202 48 250

EDGE 4 256x144 352 48 400

3G, 4G 5 512x288 552 48 600

3G, 4G 6 512x288 736 48 800

4G, WIFI 7 512x288 936 64 1000

4G, WIFI 8 512x288 1236 64 1300

4G, WIFI 9 512x288 1536 64 1600

4G, WIFI 10 512x288 1836 64 1864

4G, WIFI 11 512x288 2136 64 2200

4G, WIFI 12 512x288 2436 64 2500

Varian 9

Mobile (Android)


Device Class HIGH

16x9

Sream # Picure Size V A AVH.264 HEAACv2

3G 1 256x144 336 64 400

3G, 4G 2 512x288 536 64 600

4G, WIFI 3 512x288 836 64 900

4G, WIFI 4 512x288 936 64 1000

4G, WIFI 5 768x432 1136 64 1300

4G, WIFI 6 768x432 1536 64 1600

4G, WIFI 7 768x432 1836 64 1900


23/42

Mobile Encoding Guidelines or Android Powered Devices Whie Paper

Deailed AAC/AVC, Audio Video SetingsThe ollowing key deines he abbreviaions ound in he chars or Varians 1 9.

VIDEO AUDIO

Abbreviaion Meaning Abbreviaion Meaning

SaS Same as Source SR (kHz) Sample Rae (in Kiloherz)

FR Frame Rae (in Frames per Second) BpS Bis per Sample

GT GOP Type HEAAC v2 High Eiciency Advanced Audio Coding version 2

KI/GOP Size Keyrame Inerval/GOP Size SBR Specral Band Replicaion

ST Scan Type PS Parameric Sereo

P Progressive Scan Type # Ch Number o Channels

CA ECM (Conex Adapive) Enhropy Coding Mode

Pr@Lv H.264 Proile and Level

IDR Frq. Insananous Decode Reresh Frequency

(I-rame picure requency)

SS Search Shape

w P Weighed P-picure mode

w B Weighed B-picure mode

8x8 Trsm. 8x8 Transorm

DBLK Deblocking Filer On

ME Moion Esimaion Subpixel Mode

Re Frms. Reerence Frames

#B Frm. Number o B-rames

PM Player Mode

FS Full Screen

IP In-page (e.g. regular mode)

SR Search Range

B FDM B Frame Direc Mode (predicion mode)

T Temporal

[email protected] High Proile a Level 4.2

[email protected] Main Proile a Level 4.2

CBR/2pass Eiher 2 pass in Consan Birae Mode or Capped Variable

Birae Mode


24/42


Variant 1

Use Case:

FixedScreenSizes

FixedPageSizes

VariableBitrates

Varian 1: VIDEO

Mulibirae (Mobile) Mobile (Android) Conainer MPEG-4 Sysem (MPEG-4 Par 12 & 14 Complian)

Conn. Type: EDGE, 3G, 4G, WiFi Device Class: LOW, MEDIUM, HIGH

Device Posiioning: Landscape (Horizonal) Picure Aspec Raio: 16:9 Pixel: 1:1

VIDEO Basic Birae H.264 Advanced

Stream # PM Picture Size FR S Bitrate Mode CODEC CA ECM Pr@Lv #B Frm. B FDM GOP Size GOP IDR IDR Frq. Re Frms. SS SR wt P wt B 8x8 rsm. DBLK ME Slice

1 IP 128x72 SaS P 56 CBR/2pass H.264 CAVLC [email protected] 0 F Fixed, SaS x 2 Closed 1 2 8x8 64 Yes No No Yes 1/4 Pel 1





6 FS 640x360 SaS P 736 CBR/2pass H.264 CAVLC [email protected] 0 F Fixed, SaS x 2 Closed 1 4 8x8 64 Yes No No Yes 1/4 Pel 1

Device Posiioning: Porrai (Verical) Picure Aspec Raio: 16:9 Pixel: 1:1



1 IP 128x72 SaS P 56 CBR/2pass H.264 CAVLC [email protected] 0 T Fixed, SaS x 2 Closed 1 2 8x8 64 Yes No No Yes 1/4 Pel 1



4 FS 480x270 SaS P 336 CBR/2pass H.264 CAVLC [email protected] 0 T Fixed, SaS x 2 Closed 1 4 8x8 64 Yes No No Yes 1/4 Pel 1



Device Posiioning: Landscape (Horizonal) and Porrai (Verical) Picure Aspec Raio: 4:3 Pixel: 1:1










25/42


Varian 1: AUDIO Varian 1: AUDIO + VIDEO

Combined Birae

Stream # Encode Mode (SBR) (PS) Bitrate SR (kHz) BpS # Ch A-Stream # + V-Stream #

1 HEAAC v.2 Yes No 24 32 16 2/0 (L,R) 1 80 1

2 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 2 150 2

3 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 3 250 3

4 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 4 400 4

5 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 5 600 5

6 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 6 800 6


26/42


Variant 2

Use Case:

FixedScreenSizes

FixedPageSizes

VariableBitrates

Varian 2: VIDEO





















Device Posiioning: Landscape (Horizonal) and Porrai (Verical) Picure Aspec Raio: 4:3 Pixel: 1:1










27/42



Combined Birae


1 HEAAC v.2 Yes No 24 32 16 2/0 (L,R) 1 80 1

2 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 2 150 2

3 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 3 250 3

4 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 4 400 4

5 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 5 600 5

6 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 6 800 6


28/42


Variant 3

Use Case:

FixedScreenSizes

FixedPageSizes

VariableBitrates

Varian 3: VIDEO


Conn. Type: 3G, 4G, WiFi Device Class: LOW, MEDIUM, HIGH



















Device Posiioning: Landscape (Horizonal) and Por rai (Verical) Picure Aspec Raio: 4:3 (mached o 16:9 picure heigh) Pixel: 1:1










29/42



Combined Birae


1 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 1 250 1

2 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 2 350 2

3 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 3 450 3

4 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 4 650 4

5 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 5 750 5

6 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 6 950 6


30/42


Variant 4

Use Case:

FixedScreenSizes

FixedPageSizes

VariableBitrates

Varian 4: VIDEO































31/42



Combined Birae


1 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 1 250 1

2 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 2 350 2

3 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 3 450 3

4 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 4 650 4

5 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 5 750 5

6 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 6 950 6


32/42


Variant 5

Use Case:

FixedScreenSizes

FixedPageSizes

VariableBitrates

Varian 5: VIDEO































33/42



Combined Birae


1 HEAAC v.2 Yes No 24 32 16 2/0 (L,R) 1 80 1

2 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 2 150 2

3 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 3 250 3

4 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 4 400 4

5 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 5 600 5

6 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 6 800 6


34/42


Variant 6

Use Case:

FixedScreenSizes

FixedPageSizes

VariableBitrates

Varian 6: VIDEO































35/42



Combined Birae


1 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 1 250 1

2 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 2 400 2

3 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 3 600 3

4 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 4 800 4

5 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 5 1000 5

6 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 6 1300 6


36/42


Variant 7

Use Case:

FixedScreenSizes

FixedPageSizes

VariableBitrates

Varian 7: VIDEO


Conn. Type: 3G, 4G, WiFi Device Class: MEDIUM, HIGH





























37/42



Combined Birae


1 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 1 600 1

2 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 2 900 2

3 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 3 1000 3

4 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 4 1300 4

5 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 5 1600 5

6 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 6 1900 6


38/42


Variant 8

Use Case:

FixedScreenSizes

FixedPageSizes

VariableBitrates

Varian 8: VIDEO




















Stream # PM Picture Size FR S Bitrate Mode CODEC CA ECM Pr@Lv #B Frm. B FDM GOP Size GOP IDR IDR Frq. Re Frms. SS SR wt P wt B 8x8 rsm. DBLK ME Slice1 IP 128x72 SaS P 56 CBR/2pass H.264 CAVLC [email protected] 0 F Fixed, SaS x 2 Closed 1 2 8x8 64 Yes No No Yes 1/4 Pel 1













39/42


Varian 8: VIDEO



















Combined Birae


1 HEAAC v.2 Yes No 24 32 16 2/0 (L,R) 1 80 1

2 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 2 150 2

3 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 3 250 3

4 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 4 400 4

5 HEAAC v.2 Yes No 48 44.1 16 2/0 (L,R) 5 600 5

6 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 6 800 6

7 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 7 1000 7

8 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 8 1300 8

9 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 9 1600 9

10 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 10 1900 10

11 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 11 2200 11

12 HEAAC v.2 Yes No 64 44.1 16 2/0 (L,R) 12 2500 12


40/42


Variant 9

Use Case:

FixedScreenSizes

FixedPageSizes

VariableBitrates

Varian 9: VIDEO


Conn. Type: 3G, 4G, WiFi Device Class: HIGH




1 IP 512x288 SaS P 336 CBR/2pass H.264 CABAC [email protected] 2 F Fixed, SaS x 2 Closed 1 4 8x8 64 Yes No No Yes 1/4 Pel 1

2 IP 512x288 SaS P 536 CBR/2pass H.264 CABAC [email protected] 2 F Fixed, SaS x 2 Closed 1 4 8x8 64 Yes No No Yes 1/4 Pel 1

3 IP 512x288 SaS P 836 CBR/2pass H.264 CABAC [email protected] 2 F Fixed,

mobile encoding android v2 7

Documents