rapport de stage pfe mpeg dash

7/24/2019 Rapport de Stage PFE MPEG DASH

1/75

Rf : AU : 2012-2013

Universit de

Sousse

Ecole Nationale dIngnieurs deSousse

Mmoire de Projet de Find'tudes

Prsent en vue de lobtention du diplmed

Ingnieur en Gnie Informatique Applique

Soutenu Devant le jury

Soutenu le 29/06/2013 devant les jurys

Prsident : Monsieur BEN ARBIA AnisRapporteur: Madame SADDI NajlaEncadreur :Monsieur KHAYATI Naoufel,ENISoEncadreur :Monsieur JERBI Aymen, TELNETEncadreur :Monsieur BEN GHAZI Lassaad, TELNET

@OUSSAMA2013

Option : Ingnieriedes

Systmes distribusRalisation Dun

Android MPEG DASH Player

Ralis par :

Hadj Ali Oussama

Option : Ingnierie des Systmes Distribus


2/75


Page 1

Rsum

Au cours des dernires annes, lInternet est devenu un canal important pour la

distribution des donnes multimdias principalement via le protocole HTTP. Plusieurs

protocoles de streaming intelligents se sont bass sur le protocole HTTP pour aboutir un

streaming fluide et de qualit optimale. Parmi ces protocoles il y a le dernier et la nouvelle

norme internationale MPEG DASH.

La socit tunisienne TELNET, en tant que socit innovatrice et leader technologique, a bien

estim le potentiel de ce protocole de streaming et elle a dcid de concevoir une application

Android permettant la lecture de contenu multimdia diffus via le protocole MPEG DASH

Lapplication doit permettre le streaming de vidos par ce protocole dans un systme Android

ainsi que le dploiement dun algorithme de dcision contrlant la qualit de diffusion au

cours de Streamingpermettant dobtenir la meilleure qualit possible.

Mots-cls: Streaming, MPEG DASH, Android, multimdia, HTTP, Adaptivit, Qualit


3/75


Page 2

Abstract

In recent years, the Internet has become an important channel for the distribution of

multimedia data primarily via HTTP. Several intelligent streaming protocols were based on

the HTTP protocol to achieve a fluid streaming and optimal quality. One of these protocols is

the last and the new international standard MPEG DASH.

The Tunisian company TELNET, as an innovator and technology leader realized the potential

of the streaming protocol and decided to design an Android application for playing

multimedia content broadcast via MPEG DASH protocol

The application must allow streaming of videos using this protocol in an Android system as

well as the deployment of a decision algorithm controlling broadcast quality during streaming

to obtain the best possible quality.

Keywords: Streaming MPEG DASH, Adaptivity, multimedia, HTTP, Quality


4/75


Page 3

.HTTP

HTTP

MPEG DASH .

.

.

.

.

:

,,,,


5/75


Page 4

Remerciements

Nous souhaitons que cette page du prsent document puisse exprimer tous nos sincres

sentiments de reconnaissance et de remerciements que nous adressons tous ceux qui ont

contribu ou aid, de prs ou de loin, raliser ce travail.

Nous tenons exprimer toute notre immense gratitude Mr. JERBI Aymen et Mr. BEN

GHAZI Lassaad, nos minents encadreurs la respectable socit TELNET, pour leur dispo-

nibilit, leurs directives et leurs prcieux conseils qu'ils nous ont prodigus.

Nous saisissons cette occasion pour remercier vivement notre encadreur monsieurKHAYATI Naoufel, matre assistant lEcole Nationale dIngnieurs de Sousse ENISO, pour

son soutien continu, ses remarques pertinentes, ses conseils constructifs et inpuisables quil

nous a fournis et surtout la motivation soutenue quil nous a inculqus tout au long de la p-

riode de ltude du projet pour amener bon port ce travail.

Nous exprimons notre profonde reconnaissance tout le staff administratif et tout le corps

enseignant de l ENISO pour la qualit de la formation qu'ils nous ont donne durant les

trois annes d'tudes.

Nous souhaitons aussi adresser nos sincres salutations nos collgues et amis qui nontjamais hsit nous encourager et nous apporter leurs infinis soutiens.

Enfin et avec plein de respect, nous tenons prsenter les plus forts remerciements tous les

membres du jury qui ont bien voulu accepter dvaluer notre modeste travail.


6/75


Page 5

Table des matiresIntroduction Gnrale ............................................................................................................................ 10

Chapitre 1 : Prsentation et contexte du projet ..................................................................................... 13

1.1 Prsentation de lorganisme daccueil................................................................................. 13

1.2. Contexte du projet et Objectifs ........................................................................................... 16

1.2.1 Problmatique ............................................................................................................... 16

1.2.2 Objectifs ....................................................................................................................... 18

Chapitre 2 : Etat de lart du Streaming................................................................................................. 20

2.1 Streaming traditionnel ......................................................................................................... 20

2.1.1 Real-Time Transport Protocol (RTP) ........................................................................... 20

2.1.2 Real-Time Streaming Protocol (RTSP) ........................................................................ 21

2.2 Le Streaming progressif ..................................................................................................... 21

2.3 Le streaming adaptatif ......................................................................................................... 21

2.3.1 Transcodage .................................................................................................................. 22

2.3.2 Encodage volutif ......................................................................................................... 22

2.3.3 Commutation de contenu (Stream switching) .............................................................. 23

2.4 Streaming adaptatif bas sur HTTP ..................................................................................... 24

2.4.1 Le HTTP Live Streaming (HLS) dApple.................................................................... 25

2.4.2 Le Microsoft's Live Smooth Streaming (LSS) ............................................................. 26

2.4.3 Le HTTP Dynamic Streaming dAdobe....................................................................... 26

Chapitre 3 : Le protocole MPEG DASH : prsentation et tude de lexistant..................................... 27

3.1 Spcifications du protocole MPEG-DASH ......................................................................... 27

3.1.1 Prsentation du protocole ............................................................................................ 27

3.1.2 Chronologie de dveloppement .................................................................................... 27

3.1.3 Mcanisme de fonctionnement ..................................................................................... 28

3.1.4 Avantages du protocole MPEG DASH ........................................................................ 31

3.2 Etude de lexistant............................................................................................................... 31

3.2.1 Helix DNA Client ......................................................................................................... 32

3.2.2 La librairie Libdash ..................................................................................................... 32

3.2.3 Gstreamer : DASHbin et le plugin gstdashdemux ........................................................ 32

Chapitre 4 Analyse et spcification des besoins ................................................................................... 34

4.1 Besoins en Architecture ....................................................................................................... 34

4.2 Expression des besoins ........................................................................................................ 35

4.2.1 Besoins Fonctionnels .................................................................................................... 35

4.2.2 Besoins non fonctionnels .............................................................................................. 354.3 Diagramme des cas dutilisation......................................................................................... 35


7/75


Page 6

4.3.1 Identification des acteurs .............................................................................................. 35

4.3.2 Liste des cas dutilisation............................................................................................. 35

4.3.3 Modlisation ................................................................................................................. 36

4.4 Description des cas dutilisation.......................................................................................... 37

4.5 Diagramme de squences .................................................................................................... 38

Chapitre 5 La phase Conception du Android MPEG DASH Player .................................................... 40

5.1 Architecture globale du systme ......................................................................................... 40

5.2 Conception dtaille ............................................................................................................ 42

5.2.1 Architecture physique ................................................................................................... 42

5.2.2 Architecture Logique .................................................................................................... 43

5.2.3 Diagrammes de classes ................................................................................................. 44

Chapitre 6 Ralisation de lapplication Android MPEG DASH Player................................................ 47

6.1 Environnement de travail .................................................................................................... 47

6.1.1 Environnement matriel ............................................................................................... 47

6.1.2 Environnement Logiciel ............................................................................................... 48

6.2 Dmarche de ralisation de lAndroid MPEG DASH Player.............................................. 49

6.2.1 Compilation de la librairie Libdash pour lenvironnement Android ICS de la carte TI

AM335x................................................................................................................................. 49

6.2.2 Ralisation de la partie Dash Streaming Control.......................................................... 51

6.2.3 La logique dadaptation: Algorithme de dcision pour le choix de la qualit destreaming ............................................................................................................................... 51

6.2.4 Phase de dcodage ........................................................................................................ 54

6.2.5 Ralisation de la couche accs aux flux ...................................................................... 54

6.2.6 Phase de visualisation ................................................................................................... 55

6.3 Tests et rsultats exprimentaux .......................................................................................... 56

Conclusion gnrale .............................................................................................................................. 62

Bibliographie ......................................................................................................................................... 64

Glossaire ................................................................................................................................................ 65

Annexe A : Structure dun fichier MPD................................................................................................ 66

Annexe B : Architecture du systme dexploitation Android.............................................................. 69

Annexe C:Procdure de mise en place de lenvironnement Android sur la carte TI AM335xevm ...... 73


8/75


Page 7

Liste des tableaux

Tableau 1 Description du cas d'utilisation Arrter le streaming............................................................ 37

Tableau 2 Description du cas d'utilisation Passer en mode dadaptation automatique......................... 37

Tableau 3 Description du cas d'utilisation Visualiser une vido en mode plein cran.......................... 37

Tableau 4 Description du cas d'utilisation Passer une suprieure/infrieure rsolution vido........... 38

Tableau 5 Caractristiques de l'environnement de travail..................................................................... 47

Tableau 6 Caractristiques de la Carte TI AM335x evm...................................................................... 48

Tableau 7 Emulation de l'algorithme de dcision.................................................................................. 60Tableau 8 Analyse de la structure d'un fichier MPD............................................................................. 68

Tableau 9 Les noyaux linux utiliss par Android.................................................................................. 72


9/75


Page 8

Liste des figures

Figure 1 Trafic Internet envisag pour les prochaines annes tri par types des terminaux [Net1]...... 10

Figure 2 Estimation du type de trafic internet des Smartphones trie par type d'activit [Net1].......... 11

Figure 3 Logo de TELNET [Net 2]....................................................................................................... 13

Figure 4 Organigramme de TELNET.................................................................................................... 15

Figure 5 Schma simplifi du streaming adaptatif [Net3]..................................................................... 17

Figure 6 Les ventes mondiales de Smartphones tries par systme dexploitation............................... 17

Figure 7 Approche du transcodage pour le streaming adaptatif [Net3]................................................. 22

Figure 8 Approche de l'encodage volutif............................................................................................. 23

Figure 9 Approche du Stream switching pour le streaming adaptatif [Net3]........................................ 23Figure 10 Exemple illustrant la commutation de Stream dans le temps................................................ 24

Figure 11 Communication client-serveur dans le cadre d'un streaming adaptatif................................. 25

Figure 12 Chronologie du dveloppement du standard MPEG DASH................................................. 27

Figure 13 Schma d'illustration du contenu d'un fichier MPD.............................................................. 29

Figure 14 Exemple d'un fichier MPD.................................................................................................... 29

Figure 15 Communication client-serveur dans le cadre du protocole MPEG-DASH........................... 30

Figure 16 Illustration du changement de la qualit des segments tlchargs selon la variation de la

bande passante....................................................................................................................................... 31

Figure 17 Architecture d'un systme de streaming MPEG-DASH....................................................... 34

Figure 18 Diagramme de cas d'utilisation global.................................................................................. 36

Figure 19 Diagramme de squence d'un scnario d'utilisation du MPEG DASH Player...................... 39

Figure 20 Architecture globale du systme de streaming en utilisant Libdash[Net5]........................... 41

Figure 21 Diagramme de dploiement du systme............................................................................... 42

Figure 22 Modlisation de l'architecture logique du Android MPEG-DASH Player........................... 43

Figure 23 Diagramme de classe du DASH Streaming Control............................................................. 44

Figure 24 Diagramme de classes du Android Media Player................................................................. 46

Figure 25 Carte d'essai TI AM335x evm [Net7]................................................................................... 48

Figure 26 Modlisation de la dmarche adopte pour la ralisation du Android MPEG DASH Player49

Figure 27 Couche librairies de l'architecture du systme Android gnr............................................ 50Figure 28 Modlisation de la structure du buffer de lecture.................................................................. 53

Figure 29 Ecran d'attente....................................................................................................................... 56

Figure 30 Fentre principale de l'application Android MPEG-DASH Player....................................... 56

Figure 31 Vido en cours de lecture avec playlist couverte.................................................................. 57

Figure 32 Illustrations des diffrentes fonctionnalits disponibles pour le contrle manuel de la

qualit.................................................................................................................................................... 57

Figure 33 Illustration du changement de la qualit d'image automatique............................................. 58

Figure 34 Illustration de passage d'une vido une autre dans la playlist............................................ 59

Figure 35 Structure d'un fichier MPD................................................................................................... 66

Figure 36 Architecture du systme d'exploitation Android................................................................... 69Figure 37 La couche Application de l'architecture du SE Android....................................................... 69
http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152249http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152249http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152252http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152252http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152253http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152253http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152256http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152256http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152257http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152257http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152267http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152267http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152271http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152271http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152273http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152273http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152278http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152278http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152278http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152273http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152271http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152267http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152257http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152256http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152253http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152252http://c/Users/oussama064/Documents/Rapport_Stage_Pfe%20v2..1.docx%23_Toc359152249


10/75


Page 9

Figure 38 La couche Framework de l'architecture du SE Android....................................................... 70

Figure 39 La couche des Librairies de l'architecture du SE Android.................................................... 70

Figure 40 La couche Android Runtime de l'architecture du SE Android.............................................. 71


11/75


Page 10

Introduction Gnrale

Aujourdhui, le streaming est une technologie trs populaire par laquelle le contenu

multimdia est dlivr en continu partir d'un serveur de streaming des utilisateurs finaux.

Les mthodes de diffusion sont en amlioration continue afin de se conformer aux

capacits du rseau et aux scnarios d'utilisation qui sont htrognes. Ainsi la cration de

techniques qui fournissent automatiquement la meilleure qualit possible aux consommateurs

est devenue un objectif capital et un enjeu important.

Des tudes rcentes ont montr la croissance en nombre et surtout la diversit de

dispositifs d'utilisateur final. Ces dernires annes, les Smartphones sont devenus

immensment populaires. En effet ils ont t considrablement amliors dune anne

lautre, pour offrir des services Internet utilisant des connexions sans fil et large bande. Les

Smartphones prsentent aussi des fonctionnalits similaires aux ordinateurs modernes, ils sontquips de systmes d'exploitation plus sophistiqus que ceux des tlphones cellulaires

ordinaires. Les Smartphones permettent ainsi l'installation d'applications tierces.

La figure 1 illustre les prvisions pour les prochaines annes en termes de trafic rseau, ce

qui annonce une prochaine augmentation considrable du trafic mobile (estim reprsenter

les 26,6% du trafic total du rseau en 2015 et 67.5% du trafic en 2017).

Figure 1 Trafic Internet envisag pour les prochaines annes tri par types des terminaux [Net1]

Les donnes vido sont clairement devenues le principal type de contenu transfr par les

applications mobiles. Comme le montre la figure 2, le trafic vido va crotre de faon

exponentielle dans les prochaines annes.


12/75


Page 11

Figure 2 Estimation du type de trafic internet des Smartphones trie par type d'activit [Net1]

Avec la croissance du trafic de transfert de mdia via Smartphones et laugmentation

continue des capacits des rseaux internet, plusieurs fournisseurs de contenu multimdia sont

entrs en concurrence afin de crer la technique de streaming permettant dobtenir la

meilleure qualit de streaming possible, cest dans ce cadre quest apparu la notion destreaming adaptatif et dynamique. Le dernier en date de ces protocoles est le protocole

MPEG DASH. Ce protocole a le potentiel de devenir la norme dominante de diffusion de

mdia dominante pour les prochaines annes.

Cest dans ce cadre que se situe le sujet de notre projet de fin dtudes en vue dobtenir le

diplme dingnieur en informatique applique. Ce stage a t effectu pour une dure de

quatre mois et demie au sein de la socit TELNET.

Ce projet de fin dtudes a comme objectif principal la ralisation dun lecteur de contenu

multimdia pour le systme dexploitation mobile Android supportant le protocole MPEGDASH.

Tout au long de ce document qui sarticule autour de six chapitres, nous exposerons les

diffrentes tudes et tches ralises durant ce stage. Le premier chapitre sera consacr la

prsentation du contexte gnral et de la problmatique de notre projet.

Dans le deuxime chapitre, nous prsenterons une bauche dtude sur ltat de lart du

processus de streaming ainsi que lvolution qua connu ce processus.

Dans le troisime chapitre, les diffrentes caractristiques du protocole MPEG DASH

ainsi que les solutions disponibles sur le march et supportant ce protocole seront dtailles.

Dans le quatrime chapitre, nous prsenterons les tudes faites lors de la phase consacre


13/75


Page 12

lanalyse et la spcification des besoins. Le cinquime chapitre contiendra la description des

diffrentes tapes de conception de la solution propose.

Enfin, le dernier chapitre exposera la dmarche adopte dans la phase de ralisation ainsi que

les rsultats obtenus sa fin.

Le prsent rapport se terminera par une conclusion qui talera le bilan de ce stage tout en

prcisant les perspectives suscites par notre travail ainsi que les amliorations qui peuvent lui

tre apportes.


14/75


Page 13

Chapitre 1 :Prsentation et contexte du projet

Introduction

Dans ce chapitre, on prsentera en premier lieu la socit TELNET, lorganisme qui a bien

voulu nous accueillir en mettant notre disposition les moyens ncessaires au bon

droulement de ce stage.

La deuxime partie de ce chapitre sera consacre la prsentation de la problmatique qui

a pouss la socit TELNET proposer le sujet de projet de fin dtude expos dans le

prsent document.

La dernire partie de ce chapitre comportera une numration des diffrents objectifs fixs

pour le sujet du stage ainsi que la dmarche adopte pour la ralisation de ces objectifs.

1.1 Prsentation de lorganisme daccueil

Figure 3 Logo de TELNET [Net 2]

TELNET HOLDING(le logo de TELNET est reprsent dans la figure 3) est un groupe com-

pos de plusieurs filiales, bas sur linnovation et les hautes technologies.

Depuis sa cration en 1994, TELNET a ralis de nombreux projets et a cumul une grande

exprience et un savoir-faire unique dans ses diffrents domaines d'activits.

Le groupe est rput pour son savoir-faire, sa stabilit, son sens de l'thique et la valeur de

ses actionnaires.

Le 18 fvrier 2011, le conseil d'administration de la Bourse de Tunis a donn son accord pour

l'admission de TELNET Holding son march principal. Cette orientation stratgique a ga-

ranti et garantira dans le futur la bonne gouvernance du groupe, sa prennit et l'adhsion de

tous les collaborateurs au projet de faire de Telnet Holding une rfrence technologique au

niveau international.

Le groupe TELNET a pour vocation dtre une socit dingnieriecratrice de produits et de

solutions de haute technologie travers des partenariats forts avec des constructeurs et des

organismes internationaux de renom. Dans ce cadre le groupe Telnet a conclu dimportants

accords tels que :

Le premier accord est sign en 2006 avec le groupe SAFRAN (groupe aronautique

franais) et il consiste en une coopration industrielle entre les deux parties dans les

domaines de laronautique, de la scurit et des cartes puces.


15/75


Page 14

Deux ans aprs ce premier accord, les deux groupes Altran (groupe Franais) et TEL-NET leaders dans lingnierie ont sign un contrat de joint-venture permettant la

naissance de la socit Altran Telnet Corporation.

TELNET a sign des accords avec les groupes TEUCHOS, SAFRAN Aerospace Indiaet DASSAULT SYSTEMES.

Dans un souci de mieux se rapprocher de ses clients en Europe, le groupe TELNET a opt

pour un mode opratoire selon le modle Front office (France) / Back office (Tunisie).

1.1.1. Savoir-faire du groupe TELNET

La socit TELNET a obtenu une premire certification ISO 9001 version 2000 pour la

conception, le dveloppement et lintgration de produits logiciels dans le domaine des tech-

nologies de linformation.

Elle a obtenu une deuxime certification en 2006 et devient ainsi la premire entreprise

informatique en Tunisie, en Afrique et dans le monde Arabe ayant rejoint le cercle rduit des

entreprises informatiques adoptant le rfrentiel CMMI niveau 5 dans le monde.

Le centre de dveloppement de TELNET est le seul au niveau rgional tre certifi

CMMI niveau 5 et ISO 9001 version 2008. Ainsi, le groupe assure la scurit, la confidentia-

lit et la proprit intellectuelle de ses prestations.

Depuis 2010, TELNET est devenue membre de lIEEE " Institue of Electrical and ElectronicsEngineers".

Elle a aussi sign un accord de collaboration avec le Commissariat lEnergie atomique et aux Energies Alternatives (CEA).

1.1.2. Domaines dactivit de TELNETLe groupe TELNET vise tre parmi les premiers du monde dans linnovation et dans la

technologie et ce en essayant dtre un acteur de rfrence sur le plan national et international.

TELNET uvre dans les secteurs des:

Tlcommunications

Multimdia

Transport

Automobile

Dfense et Avionique Scurit

Montique et carte puce

Electronique

Industrie

Ingnierie Mcanique.

Systmes dinformation

Lvolution considrable de lentreprise et limportance quelle accorde au concept qualit,

lui ont permis de diversifier ses activits et dinnover dans diffrents domaines. Ces domaines

reprsentent des activits importantes et pour leur bonne gestion, Telnet leur a consacr des

dpartements.


16/75


Page 15

1.1.3. Organigramme de TELNETLes dpartements sont organiss de la manire prsente dans la figure 4

1.1.4. Aperu sur les missions de certains dpartements

a-Dpartement Systmes Electroniques : Ce dpartement est responsable de la conceptionet du design des systmes lectroniques qui seront par la suite tests et valids.

Ce dpartement comprend trois services:

Le service de lautomobile : o se ralise le dveloppement embarqu (tel que

celui des calculateurs moteurs), le test et la validation des travaux raliss ain-

si que le dveloppement des systmes de diagnostic automobile.

Le service de lautomatisation du design lectronique.

Le service de la CAO (Conception Assiste par Ordinateur) qui assure la con-

ception et le design lectronique.

b-Dpartement Rseaux et Tlcoms : La mission fondamentale de ce dpartement est deraliser les fonctions suivantes :

fournir des solutions dinterconnexion informatique et de tlcommunicationspour la mise

en place des rseaux dentreprises (LAN/WAN).raliser des projets en sous-traitance pour le compte de constructeurs Tlcoms.

actualiser les technologies de linformation.

maintenir techniquement la gestion et lexploitation des rseaux des entreprises.

c- Dpartement Etudes Logicielles : La mission de ce dpartement est la conception et ledveloppement de produits logiciels dans divers domaines dactivits savoir: les tlcom-

munications, les terminaux, la scurit et la dfense et les systmes spcifiques.

Ces activits sont assures grce la contribution de principaux services :

- Le service des technologies de linformation : au seinduquel se ralise le dveloppe-

ment pour la scurit et la dfense et les systmes spcifiques.

-

Le service des tlcoms et des terminaux : o seffectue le dveloppement des log i-ciels embarqus (commutateurs, routeurs, compteurs lectroniques).

Dpartement tudesLogicielles

Dpartement SystmesElectroniques

Dpartement Rseaux etTlcoms

Direction Marketing &Tlcom

Direction GnraleDirection Administrative etfinancire

Conseil Dadministration

Tlcom Multimdia IndustrieAutomobil

e

Montique& carte

puce

Dfense &Avionique

Systmedinformation

Scurit

Figure 4 Organigramme de TELNET


17/75


Page 16

Nous avons eu loccasion de raliser notreprojet de fin dtude au sein de ce dpartementet plus prcisment au sein de lquipe Multimdia.

Activit de lquipe Multimdia

Lquipe multimdia opredans le domaine grand public tels que les crans LCD/ DLP,

les dcodeurs IP, les rcepteurs et les imprimantes photo et dans le domaine bilatral avec les

oprateurs particuliers par les encodeurs CBR/VBR, les multiplexeurs, les modulateurs ou

encore les serveurs vido.

1.2. Contexte du projet et Objectifs

1.2.1 Problmatique

L'immense varit de dispositifs d'utilisateurs finaux oprant sous rseaux mobiles

htrognes a conduit un dfi intressant: produire une technique d'adaptation dynamique et

automatise entre producteurs et consommateurs, pour offrir la meilleure qualit possible de

contenu. Plusieurs contraintes sont prsentes dans le processus de diffusion de contenu ou

streaming, telles que les fluctuations des bandes passantes de rseau ou des propres capacits

du client. Par exemple, les dispositifs d'utilisateurs finaux peuvent tre limits par la

rsolution d'affichage, par le dbit binaire (bit rate), ou par les formats de mdias pris en

charge.

La figure 5 ci-dessous illustre l'adaptation pour des clients similaires qui connaissentdiffrentes limitations dans le rseau de communication, et donc diffrente quantit de

donnes transmises par unit de temps ces diffrents clients.

Dans ce contexte, le streaming adaptatif reprsente une famille de techniques qui abordent

le problme de la diffrence dans les donnes fournies des clients diffrents. Par le biais du

contenu multimdia en couches et les mcanismes d'adaptation, les utilisateurs finaux peuvent

percevoir le niveau le plus appropri de qualit en tenant de leurs contraintes actuelles.

Les techniques adaptatives les plus populaires seront prsentes dans le prochain chapitre.


18/75


Page 17

Figure 5 Schma simplifi du streaming adaptatif [Net3]

Plusieurs systmes d'exploitation (SE) ont t dvelopps pour les Smartphones Android

(voir dtails lAnnexe B) est un SE mobile open source dvelopp par Google.

Des statistiques rcentes [Net4] ont montr quAndroidest le systme d'exploitation mobile

prdominant dans le march (56.9% au niveau mondial), suivi par iOS d'Apple (22.5%),

Symbian (8.5%) et Windows Mobile (1.9%).

Les prcdentes statistiques sont reprsentes dans la figure 6.

Figure 6 Les ventes mondiales de Smartphones tries par systme dexploitation

Les ventes mondiales de smartphones

classs par systme d'exploitation en

Mai 2013

Android

56,9%

Symbian 8,5

%

Autre 10,2 %

Windows

phone 1,9%

iOS 22,5 %

Les ventes mondiales de smartphones

classs par systme d'exploitation en

Mai 2011

Android 36%

Symbian

27,4%Autre 3,3%

Windows

Phone 3,6 %iOs 16,8%

RIM 12,9%

Le systme dexploitation Androidest devenu largement dominant dumarch des Smartphones


19/75


Page 18

A l'heure actuelle, il existe peu de services de streaming adaptatif pour Android de Google.

Les protocoles de streaming supports par la plateforme Android actuellement sont les

suivants:

- RTSP (RTP, SDP)

-

Le Streaming progressif bas sur les protocoles HTTP/HTTPS

- HTTP/HTTPS live streaming (support du protocole ajout partir de la version

Android 3.0)

Malgr le fait que Apple Inc ait publi et mis en uvre un protocole connu sous le nom

HTTP Live streaming (HLS), dj soutenu dans les tlphones mobiles d'Apple, et que ce

protocole Apple HLS est en train de devenir une norme Groupe du travail de l'Internet

Engineering Task Force (IETF), d'autres parties, comme le Moving Picture Experts Group

ISO / IEC (MPEG), ont propos une nouvelle norme vers novembre 2012 pour le streaming

adaptatif via HTTP,cette norme est appele streaming adaptatif dynamique sur HTTP(DASH).

Dans le cadre des recherches pour lamlioration des fonctionnalits de la plateforme

Android et vu le nombre limit de protocoles de streaming supports nativement par cette

plateforme et vu lavnement de plusieurs nouveaux protocoles de streaming volus,

lquipeMultimdia de la socit TELNET a propos pour tude et ralisation le sujet intitul

Android MPEG DASH Player visant raliser une solution complte supportant le

nouveau protocole de streaming de MPEG sur Android.

1.2.2 Objecti fsLquipe Multimdiade TELNET a dfini les objectifs suivants pour le prsent projet de fin

dtudes:

Modification du Framework Android pour ajouter le support du protocole MPEG

DASH

Ralisation d'un Android Mdia Player exploitant le protocole MPEG DASH

Pour atteindre ces objectifs, les tches suivantes sont prconises dans ce projet:

Ajout du support du protocole MPEG DASH ce qui conduit une tude approfondie

des capacits de lAndroid Media Framework (Stagefright).

Dfinition des formats de mdias et protocoles de streaming qui sont nativement

supports par Stagefright.

La phase de ralisation de lAndroidMdia Player ncessite :

- La dfinition de plusieurs paramtres analyser lors de l'valuation. Cette valuation

concernera notamment l'efficacit, la performance, les retards, et l'utilisation de la

bande passante. Ces paramtres doivent tre dfinis facilement et clairement afin de

pouvoir comparer efficacement les mcanismes d'adaptation.


20/75


Page 19

-

La proposition et l'valuation des diffrents mcanismes d'adaptation du ct du client

et qui sont capables de converger vers le dbit binaire maximal durable. Ces

mcanismes prcisent la logique de l'application du client, fournissant une utilisation

efficace du dbit disponible sur le rseau.

-

Des diffrentes procdures seront examines afin d'optimiser l'utilisation de la bandepassante disponible et tudier les inconvnients potentiels.

Conclusion

Dans ce chapitre nous avons commenc par exposer le progrs atteint dans le domaine du

streaming de contenu multimdia et ceci en numrant et en dtaillant les principaux

protocoles de streaming existants.

En analysant ces protocoles, nous avons pu constater limportance et la prdominance du

streaming de contenu mdia sur le march tout en remarquant notamment le nombre limit deprotocoles de streaming accessibles via Android. Ainsi, nous pouvons justifier amplement

lintrt et lutilit de la ralisation de lapplication Android MPEG DASH Player sujet de

notreprojet de fin dtudes.

Ce qui constitue une source dune solide motivation pour pouvoir apporter une contribution

personnelle dans le systme dexploitation Android.

Dans le chapitre suivant, nousprsenterons ltat de lart du streaming.


21/75


Page 20

Chapitre 2 :Etat de lart du Streaming

Introduction

Notre sujet se propose dajouter le support dun nouveau protocole de streaming la

plateforme Android. Nous estimons quil est trs utile dlaborer une tude thorique

exhaustive couvrant les diffrentes techniques de streaming disponibles sur le march. Cette

tude nous permet de mieux situer le projet dans son contexte.

Il existe actuellement trois mthodes principales pour livrer le streaming multimdia: le

streaming traditionnel, le streaming progressif et le streaming adaptatif

On prsentera en premier lieu ltat de lart de streaming en numrant les diffrents types

de protocoles de streaming disponibles actuellement sur le march tout en signalant les

avantages et les inconvnients de chacun de ces protocoles

2.1 Streaming traditionnelLe streaming traditionnel ncessite un protocole mode connect ( statefull ) qui tablit

une session entre le prestataire et le client. Dans cette technique, les mdias sont envoys

sous la forme de paquets. Le protocole de transport en temps rel (RTP) avec le Real-Time

Streaming Protocol (RTSP) sont frquemment utiliss pour mettre en place un tel service.

2.1.1 Real-Time Tr ansport Protocol (RTP)Le Real-Time Transport Protocol (RTP) dcrit un systme de paquets qui fournit des flux

vido et audio sur des rseaux IP. Il a t dvelopp par le groupe de transport audio vido de

travail de l'IETF en 1996.

Le RTP est un protocole bout--bout, temps rel pour les services de rseau unicast ou

multicast. Aussi, le RTP fonctionne sur UDP qui est adapt pour la distribution multicast,

alors que tous les protocoles qui sont construits au-dessus de TCP ne peuvent tre unicast.

Pour cette raison RTP est largement utilis pour la distribution de mdias dans le cas de

l'Internet Protocol Television (IPTV). Un service de multimdia RTP est gnralement utilis

en conjonction avec RTSP, avec l'audio et la vido transmise en flux RTP distincts.

La spcification RTP dcrit deux sous-protocoles qui sont le protocole de transfert de

donnes (RTP donnes) et le protocole RTP Control (RTCP).

RTP est utilis pour transfrer des donnes multimdia en utilisant diffrents codecs avec

horodatage et des numros de squence. Ces horodateurs et les numros de squence

permettent au rcepteur de dtecter la perte de paquets et d'effectuer si ncessaire

rorganisation et synchronisation des flux multimdia, entre autres activits.

En option RTP peut tre utilis avec un protocole de description de session ou un protocole

de signalisation telle que H.323, le Media Gateway Control Protocol (MEGACO), le contrled'appel Skinny Protocol (SCCP), ou le Session Initiation Protocol (SIP).


22/75


Page 21

RTP ne fournit pas un mcanisme pour assurer la livraison en temps opportun et ne garantit

ni la qualit du service ni la livraison l'ordre des paquets. En outre, il n'y a pas de contrle de

flux fourni par le protocole lui-mme, le contrle de flux et l'vitement d'encombrement sont

plutt sont mettre en uvre par la couche application l'application utilisant ce protocole.

2.1.2 Real-Time Streaming Protocol (RTSP)

Le Real-Time Streaming Protocol (RTSP) est un protocole de contrle de session qui

fournit un cadre extensible pour contrler la transmission de donnes en temps rel. Il a t

dvelopp par le contrle de la session multimdia multipartisme groupe (MMUSIC) de

l'IETF de travail en 1998. RTSP est utile pour tablir et commander des sessions de mdia

entre des points d'extrmit (end points), mais il n'est pas responsable de la transmission de

donnes de mdia. En effet, le RTSP s'appuie sur des mcanismes de prestation bass sur

RTP.

En contraste avec HTTP, RTSP est un protocole en mode connect (statefull) : le client et le

serveur peuvent mettre des requtes. Ces requtes peuvent tre effectues de trois faons

diffrentes: (1) les connexions persistantes utilises pour plusieurs (requte / rponse)

transactions, (2) une connexion par transaction ou (3) pas de connexion.

Certaines implmentations RTSP populaires sont QuickTime Streaming Server d'Apple

(QSS) (galement sa version open source, Darwin Streaming Server d'Apple (DSS)) et

HelixUniversal Server de RealNetworks.

2.2 Le Streaming progressifLe Streaming progressif est une technique populaire et largement utilis sur Internet

permettant de transfrer des donnes entre le serveur et le client. Le Streaming progressif

peut gnralement tre ralis en utilisant un serveur HTTP rgulier. Le principe de streaming

progressif est que les utilisateurs demandent du contenu multimdia qui est tlcharg

progressivement dans un tampon local. Ds qu'il y aura suffisamment de donnes les mdias

commencent jouer par contre si le taux de lecture dpasse la vitesse de tlchargement, la

lecture est retarde jusqu' ce que plus de donnes soient tlcharges.

Le tlchargement progressif a quelques inconvnients:

Un gaspillage de bande passante si l'utilisateur dcide d'arrter de regarder le contenu

vido, puisque les donnes ont t transfres et tamponnes et ne seront pas joues.

Pas d'adaptation du dbit binaire, car tous les clients sont considrs gaux en termes

de bande passante disponible.

Pas de support pour les sources mdiatiques en direct(le live streaming).

2.3 Le streaming adaptatifLe streaming adaptatif est une technique qui dtecte la bande passante disponible de

l'utilisateur et la capacit du processeur afin d'ajuster la qualit de la vido qui est fourni

l'utilisateur et d'offrir la meilleure qualit possible qui peut tre dlivre cet utilisateur dans

sa situation actuelle (sa bande passante actuelle). Cette technique de streaming ncessite quele codeur (lencodeur) fournisse une vido des dbits multiples (ou plusieurs encodeurs


23/75


Page 22

peuvent tre utiliss). En consquence, les utilisateurs auront la meilleure qualit de streaming

qui leur est possible.

Les techniques d'adaptation du dbit binaire de la source vido largeur de bande variable

peuvent tre classes en trois catgories:

Transcodage (section 2.3.1)

Encodage volutif (section 2.3.2)

Commutation de flux (section 2.3.3)

2.3.1 Transcodage

Au moyen de transcodage il est possible de convertir le contenu vido brut la vole (sans

arrt) ct serveur. Un schma du principe de cette technique est reprsent dans la figure 7.

Le principal avantage de cette approche est la granularit fine qui peut tre obtenue, puisque

les mdias diffuser peuvent tre transcods suivant la bande passante disponible de

l'utilisateur.

Cependant, il y a quelques inconvnients graves qui mritent dtre souligns. Tout

d'abord, le cot lev de transcodage est le rsultat de l'adaptation du contenu vido brut

plusieurs fois pour plusieurs demandes ayant des qualits diffrentes. Par ailleurs et pour des

raisons dexigences de calcul d'un systme de transcodage en temps rel, le processus de

codage doit tre effectu dans des serveurs appropris afin d'tre dploy dans les CDN

(Content Delivery Network).

2.3.2 Encodage voluti f

Utilisant un standard de CODEC volutif comme H.264/MPEG-4 AVC, la rsolution

d'image et la vitesse de dfilement peuvent tre adaptes sans avoir encoder de nouveau le

contenu vido brut. Cette approche tend rduire la charge de traitement, mais elle est

limite un ensemble de formats de CODEC volutives. Un schma de principe de cettetechnique est reprsent dans la figure 8.

Contrleur

TranscodeurContenu BrutStreamingAdaptatif

Paramtres dencodage+

Figure 7 Approche du transcodage pour le streaming adaptatif [Net3]


24/75


Page 23

Nanmoins, le dploiement sur CDNs est compliqu dans cette dmarche vue la ncessit

de recourir des serveurs spcialiss pour mettre en uvre la logique d'adaptation.

2.3.3 Commutation de contenu (Stream switching)

La mthode de commutation de contenu encode le contenu vido brut plusieurs diffrents

dbits croissants, gnrant N versions d'un mme contenu, dites niveaux vido .

Comme le montre la figure 9, un algorithme doit choisir dynamiquement le niveau vido qui

correspond la bande passante disponible de l'utilisateur.

Lorsque des changements dans cette bande passante se produisent, l'algorithme passe

simplement des niveaux diffrents pour assurer une lecture continue.

Figure 9 Approche du Stream switching pour le streaming adaptatif [Net3]

Contenu Brut Encodeur volutif Vido volutive

Paramtres dencodageContrleur

StreamingAdaptatif

Figure 8 Approche de l'encodage volutif


25/75


Page 24

L'objectif principal de cette mthode est de minimiser les cots de traitement, puisque aucun

autre traitement n'est ncessaire une fois tous les niveaux vido ont t gnrs. En outre,

cette approche ne ncessite pas lutilisation dun format de codec spcifique, on dit que cette

mthode est totalement agnostique de CODEC.

En revanche, les besoins de stockage et de transmission doivent tre pris en compte car le

mme contenu vido est encod N fois (mais diffrents dbits). Le seul inconvnient de

cette approche est la granularit grossire car il y a seulement un ensemble discret de niveaux.

La figure 10 illustre lapproche de commutation dans le temps, en supposant que tous les

segments ont la mme dure et que les oprations de commutation sont effectues aprs que

chaque segment a t totalement jou (non partiellement).

Figure 10 Exemple illustrant la commutation de Stream dans le temps

2.4 Streaming adaptatif bas sur HTTPRcemment, une nouvelle solution pour le streaming adaptatif a t conue, base sur la

technique de commutation de flux (Stream switching). Il s'agit d'une mthode hybride qui

utilise HTTP comme protocole de livraison au lieu de dfinir un nouveau protocole.

Les sources vido et audio sont dcoupes en segments courts de la mme longueur

(typiquement de quelques secondes).En option, les segments peuvent tre coups le long d'un

Groupe de vido d'images, ainsi chaque segment dbute avec une image cl, ce qui signifie

que les segments n'ont pas de dpendances pass / futur entre eux. Enfin, tous les segments

sont encods dans le format souhait et hbergs sur un serveur HTTP.

Les clients demandent les segments squentiellement et les tlchargent en utilisant le

tlchargement progressif du protocole HTTP. Les segments sont lus dans l'ordre et comme

ils sont contigus, la lecture globale rsultante est lisse et toute la logique d'adaptation est

commande par le client. Cela signifie que le client calcule le temps aller chercher chaque

segment afin de passer un dbit binaire suprieur ou infrieur.

Un exemple de base est reprsent sur la figure 11, o le dispositif de requte-rponse


26/75


Page 25

reprsente la logique de commutation applique sur le ct client. Les flches paisses

correspondent la transmission d'un segment de donnes.

Pourquoi HTTP?

Le protocole HTTP est largement utilis dans l'Internet comme un protocole de livraison.

Aussi, HTTP est largement utilis par les web services afin dviter les problmes de NAT et

de pare-feu. En outre sachant que HTTP utilise le protocole TCP comme protocole de

transport, il peut ainsi assurer une livraison de flux d'octets fiable avec de nombreux

mcanismes d'vitement d'encombrement.

De plus les services bass sur HTTP peuvent utiliser les serveurs HTTP existants et les

infrastructures de CDN existants.

2.4.1 Le HTTP Live Streaming (HLS) dApple

En mai 2009, Apple a publi un protocole Streaming de Media bas sur HTTP

communication (Apple HLS) pour transmettre des flux borns et sans limite de donnes

multimdias.Apple HLS est bas sur la technologie de Streaming Media Network Emblaze

qui a t publi en 1998.Selon cette spcification, un flux global est dcompos en une

succession de petits tlchargements de fichiers bass sur HTTP, o les utilisateurs peuvent

slectionner des flux alternatifs encods des dbits diffrents. Et comme les clients HLS

utilisent des requtes de type HTTP aux fichiers tlcharger. Cette mthode fonctionne

travers les pare-feu et serveurs proxy (contrairement aux protocoles UDP tels que RTP qui

ncessitent des ports ouverts dans le pare-feu ou ncessitent l'utilisation d'une passerelle de

GET :Manifest

Envoie dufichier Manifest

GET :segment 1:level 1

Adaptation

GET :segment i:level k

200 OK

200 OK

200 OK

Envoie segment 1avec la qualit 1

Envoie segment iavec la qualit k

Lance lalecture

FichierManifestAnalys

Demandesegment iavec la

ualit k

Figure 11 Communication client-serveur dans le cadre d'un streaming adaptatif


27/75


Page 26

couche application).

Initialement, les utilisateurs tlchargent une playlist M3U tendu qui contient plusieurs

Uniform Resource Identifiers (URI) correspondant des fichiers multimdia, o chaquefichier doit tre une continuation du flux cod (sauf si c'est le premier ou il y a une tiquette

de discontinuit qui signifie que le flux global est illimit). Il est noter que le http Live Streaming dApple supporte seulement le format de conteneur

MPEG2-TS

2.4.2 Le Microsoft' s Li ve Smooth Streaming (LSS)

Smooth Streaming est une extension IIS-Internet Information Services) Media Services qui

permet le streaming adaptatif de supports multimdia aux clients via le protocole HTTP.

Microsoft a dmontr avec succs la livraison de vido HD 1080p la fois en direct et la

demande avec Smooth Streaming pour les clients Silverlight.

IIS Smooth Streaming utilise le format MPEG-4 comme format de stockage. Le principe deLSS est la dcomposition et ensuite le stockage dun mdia sous la forme de plusieurs

fragments contigus appels chunk. Ces fragments sont dcrits laide dun fichier manifest

(fichier XML) qui contient la description du mdia diffuser ainsi que les diffrentes qualits

disponibles et ladresse des diffrents chunks tlcharger progressivement.

La communication client-serveur dans le cadre de streaming LSS se limite quatre

oprations : Manifest Request: Le client demande tlcharger le fichier Manifest. Manifest Response: Le serveur envoi le fichier Manifest au client. Fragment Request : Le client demande de tlcharger un chunk travers son URI. Fragment Response : Le serveur envoi au client le fragment requis.

2.4.3Le HTTP Dynamic Streaming dAdobe

Le HTTP dynamique streaming d'Adobe (HDS) est une approche qui permet la diffusion

la demande et en direct et qui supporte les protocoles HTTP et Real Time Messaging Protocol

(RTMP). Il utilise diffrentes spcifications de format pour les fichiers multimdias (Flash

Video ou F4V) et les manifestes (Flash Media manifeste ou F4M). Pour dployer la solution

d'Adobe, il est ncessaire de mettre en place un Flash Media Streaming Server, qui est un

produit propritaire et commercial. En outre, les utilisateurs sont obligs dinstaller le Flash

Player d'Adobe.

Conclusion

Dans ce chapitre, nous avons commenc par prsenter lvolution qua connu le processus

de streaming. A cet effet, les diffrentes techniques de streaming ainsi que leurs avantages et

inconvnients ont ts dtaills.

Dans le chapitre suivant, le protocole de streaming dont lajout du support la plateforme

Android est lobjectif essentielde notre projet, sera prsent.


28/75


Page 27

Chapitre 3 :Le protocole MPEG DASH : prsentation et tude de lexistant

Introduction

Afin de russir la phase de conception et de dveloppement, nous avons jug quil est utile

de procder une tude prliminaire sur le protocole MPEG DASH et sur lexistence et

disponibilit de solutions supportant le protocole MPEG DASH sur la plateforme Android.

Pour illustrer la dmarche adopte pour cette tude, nous avons consacr la premire partie

de chapitre pour exposer la spcification du protocole MPEG DASH ainsi que les diffrents

apports et avantages de ce nouveau protocole par rapport aux autres protocoles de streaming

existants (ces protocoles ont t prsents dans le deuxime chapitre du prsent rapport).

La deuxime partie de ce chapitre sera consacre la prsentation de lunique solution

supportant MPEG DASH existante sur Android dans le march.

La dernire partie de ce chapitre comportera une numration et spcification des

diffrentes solutions envisageables pour pouvoir raliser notre propre solution de streaming

adaptatif dynamique sur Android exploitant le protocole MPEG DASH.

3.1 Spcifications du protocole MPEG-DASH

3.1.1 Prsentation du protocole

MPEG DASH : Cest un nouveau standard (ISO/IEC 23009-1) de diffusion sur internet qui

devrait arriver prochainement dans le march. Un peu comme la solution de Microsoft, LiveSmooth Streaming, ou lquivalent chez Adobe ou Apple, le MPEG DASH permet de faire du

streaming dynamique (Dash = Dynamic Adaptive Streaming over HTTP) en adaptant le flux

vido en fonction du dbit internet disponible.

Le flux vido pourra tre adapt tout au long de la lecture de la vido, et donc samliorer ou

baisser en qualit, en suivant la connexion internet et lintensit de son dbit.

Lavantage dun standard comme le MPEG DASH est linteroprabilit entre plateformes.

On peut ainsi imaginer un flux vido unique compatible pour Smartphones, PC/Mac/Linux ou

mme TV. Il suffira que le logiciel de lecture soit compatible.

Ce standard a t approuv par 24 socits, dont notamment Microsoft, Apple, Adobe, Netflix

ou encore Qualcomm

3.1.2 Chronologie de dveloppement

Juillet 2009 Avril 2010 Janvier 2011 Novembre 2011

Phasedexploration

Phase deralisation

Phase denormalisation

Figure 12 Chronologie du dveloppement du standard MPEG DASH


29/75


Page 28

La technologie MPEG-DASH a t dveloppe par le groupe MPEG (groupe spcialis dans

le dveloppement denormes internationalespour le traitement et le codage signaux audio

et/ou vido).

Les travaux sur le protocole MPEG DASH ont dbut en Juillet 2009.Ces travaux sont passs

par trois phases principales (les 3 phases sont reprsentes par le chronogramme de la figure12) :

Phase dexploration: cette phase a dbut en juillet 2009 avec les workshops MMT(Modeling Multi-commodity Trade) de MPEG.

Phase de ralisation : cette phase a commenc en Avril 2010, elle a dur sept mois :

consistant notamment en des procdures dappel doffre et validations lors du

MPEG CONSENSUS.

Phase de normalisation :cette phase a commenc en janvier 2011.En effet, il a t

jug opportun de rendre le protocole MPEG DASH un projet de norme

internationale. Ce qui a t ralis avec succs en Novembre 2011.

En avril 2012, la norme MPEG-DASH a t publi sous la rfrence ISO / IEC 23009-1:2012.

3.1.3 Mcanisme de foncti onnement

MPEG-DASH introduit le concept de prsentation de mdias (MPD) qui est un ensemble

structur de contenu vido / audio :

Une prsentation multimdia constitue d'une squence d'une ou plusieurs priodes qui sont

conscutives et qui ne se chevauchent pas.

Chaque priode comprend une ou plusieurs reprsentations du mme contenu multimdia et

a un temps de dmarrage qui lui est attribu par rapport au dbut de la prsentation des

mdias.Chaque reprsentation spcifie un profil de qualit vido constitu de plusieurs paramtres

tels que la bande passante, l'encodage et la rsolution. Aussi une reprsentation contient un ou

plusieurs segments, reprsents et localiss par leurs Universal Resource Locator (URL).

Les segments contiennent des fragments du contenu vido rel.

Un Media Prsentation Description (MPD) est un schma de fichier bas sur XML (voir

figure 14) qui contient toute la structure d'une prsentation multimdia expose ci-dessous

(figure 13).
http://fr.wikipedia.org/wiki/Normes_et_standards_industrielshttp://fr.wikipedia.org/wiki/Normes_et_standards_industriels


30/75


Page 29

Figure 13 Schma d'illustration du contenu d'un fichier MPD

Figure 14 Exemple d'un fichier MPD

Le protocole MPEG DASH spcifie la syntaxe et la smantique du MPD, le format desegments, et le protocole de livraison (HTTP). Heureusement, il permet des configurations


31/75


Page 30

flexibles pour mettre en uvre diffrents types de services de streaming. Les paramtres

suivants peuvent tre slectionns de manire flexible: la taille et la dure des segments, le

nombre de reprsentations et le profil de chaque reprsentation (dbit binaire, CODEC,

format conteneur, etc.)

En ce qui concerne le comportement du client, il peut dcider dune manire flexible quand

et comment tlcharger des segments et choisir une reprsentation approprie.La figure 15 illustre la communication entre serveur et client dans un service de streaming

MPEG DASH. D'abord le client rcupre le fichier MPD et par la suite il demande

successivement les segments des mdias. Dans chaque priode, un niveau de reprsentation

est choisi, en fonction des temps de rcupration et d'autres paramtres dtermins par le

client.

Figure 15 Communication client-serveur dans le cadre du protocole MPEG-DASH

La figure 16 ci-aprs illustre les changements de qualit de segments tlchargs le longdune priode, changements en fonction de la variation de la bande passante disponible.


32/75


Page 31

Figure 16 Illustration du changement de la qualit des segments tlchargs selon la variation de la bandepassante

3.1.4 Avantages du protocole MPEG DASH

DASH fournit des formats efficaces et de bonne qualit pour un streaming

Aussi, Il permet :

-

la rutilisation (lutilisation) des technologies existantes. En effet, il na pas de

spcifications uniques et qui lui sont propres telles que celles de de codec conteneurs

ou de DRM (Digital Rights Management), ce qui constitue un avantage indniable parrapport aux autres technologies de streaming adaptatif comme le HLS(il ne prend en

charge que le MPEG2-ts) ou MS Smooth streaming(il ne supporte que le MPEG 4).

- le dploiement sur des simples serveurs web (il ny a pas dobligation recourir des

serveurs spcifiques) Le principale apport de lMPEG DASH cest quil fournit une

qualit de streaming de haut niveau et irrprochable : cest une rvolution dans le

domaine de vido streaming. En effet, il ny a plus de coupure lors de streaming et la

qualit de limage varie et peut atteindre de trs grandes rsolutions selon lavariation

de la bande passante

- dallger la charge sur le serveur car le serveur fournit les fichiers MPD au client avec

des diffrentes prsentations (redondance de donnes avec des qualits diffrentes)

-

le dploiement flexible, en effet il permet le Live streaming et le streaming surdemande (onDemand streaming).

- linsertion de publicit pendant le streaming.

3.2 Etude de lexistant

Actuellement les solutions qui implmentent le protocole MPEG DASH sur Android sont

peu nombreuses.

Le seul client existant jusquaujourdhui est le Helix DNA Client qui est une solution payante

et incomplte. Les autres solutions existantes sont soit des librairies soit des plugins offrant la

capacit de supporter le protocole MPEG DASH (Libdash et gstdashdemux).


33/75


Page 32

3.2.1 Heli x DNA Client

Helix DNA Client pour Android fournit un HLS, MPEG-DASH, Verimatrix DRM et

Microsoft PlayReady DRM Player pour les versions Android 2.2 et ultrieures. Ce client

supporte les codecs H.264 et AAC codecs avec le soutien Bit Rate Adaptive (H.264 / AAC).

Helix SDK est fourni comme une bibliothque qui est incluse au sein des applications

Android Java.

Le client Helix DNA contient le support pour les formats et protocoles suivants:

Formats audio: AAC, RealAudio.

Formats vido: conteneur H.264 et RealVideo format de fichier 3GP et

RealVideo.

Protocoles: HLS (Version 4), MPEG-DASH (ISO BMFF MP4).

3.2.2 La li brair ie L ibdash

Libdash est une API (Application Programmable interface) crite en C + + qui fournit une

interface oriente objet (OO) la norme MPEG-DASH.

Avantages dutilisation de la librairie Libdash

-

Multiplateforme (environnement de de dveloppement)-

Implmente La totalit des spcifications du protocole MPEG DASH

- Mozilla Firefox a ajout le support du protocole MPEG DASH en utilisant

WebM. WebM[Net9] est un format multimdia ouvert principalement destin

un usage sur le web et concurrent direct du format H.264.Il se base sur la

librairie Libdash[Net13].

-

Cette librairie est open source et en volution permanente

- Candidate pour tre la libraire officielle de support du protocole MPEG

DASH[Net14].

I nconvnients dutilisation de la librairie Libdash

Absence dalgorithme dadaptation. Un algorithme dadaptationest un algorithme qui permetde se dplacer dun segment un autre selon lavariation de la bande passante. En effet cet

algorithme reste une charge dvelopper pour chaque client de la librairie.

3.2.3 Gstreamer : DASHbin et le plugin gstdashdemux

GStreamer est une bibliothque logicielle de manipulation de sons et d'images (appele

aussi Framework multimdia) crite en langage C, initialement dveloppe pour proposer une

solution capable de concurrencer QuickTime et DirectShow sur GNU/Linux.

Sa premire version publique date du 31 octobre 1999. GStreamer se base sur une architecture

modulaire compose d'un cur (GStreamer) et de plugins (Base, Good,Ugly, Bad). Pour


34/75


Page 33

faciliter les usages commerciaux de GStreamer, Fluendo et Collabora ont uvrensemble la

cration d'un SDK multiplateforme (Linux, Windows et MacOS X).

Pour ajouter le support du protocole MPEG DASH Gstreamer, il existe dj deux solutions

DASHBinet gstdashdemux.DASHBinest un nouvel lment qui sajoute au plug-in gst-plugins-bad afin de lui ajouter lestrois entits suivantes:

mpdcommon: une librairie qui aide lire et grer le fichier MPD.

mpdparse: un plug-in responsable du (XML parsing) analyse des fichiers MPD.

dashbin:client ou Player.

gstdashdemuxest un plug-in qui permet le streaming vido selon le protocole MPEG DASH.Le plugin est dvelopp par une quipe de dveloppeur dOrange et dont le code source ainsi

que les instructions dinstallation sont disponibles .

Avantages de lutilisation de Gstreamer

Gstreamer est un outil puissant qui permet la construction de lecteurs multimdias

pour la plupart des formats de fichiers multimdias.

Le dveloppent de plugin pour Gstreamer est trs bien document sur le site officiel

de Gstreamer.

Comme cest un systme qui estbas sur lutilisation plug-in. Le recours des

plugins dj publis et tests, permet linsertion de plusieurs fonctionnalits comme

lajout de sous-titre, Multiscreen

I nconvnient de lutilisation de GstreamerCette solution semble ne pas tre adopte pour le moment, en effet nos investigations nont

pas abou0ti trouver un feedback ce sujet ce qui nencourage pas adopter cette mthode.

ConclusionDans ce chapitre nous avons commenc par la dfinition et la spcification du nouveau

protocole de streaming MPEG DASH Ensuite on a fait une numration des solutions

possibles pour la mise en place dun client Android supportant le protocole MPEG DASH

En analysant les avantages et les inconvnients de chaque solution, nous avons opt pour celle

qui consiste utiliser la librairie Libdash. Cette librairie se distingue notamment par sa bonne

adaptation et elle est la solution la plus adopte et la plus mature.

Dans le chapitre suivant nous allons entamer ltape danalyse et spcification des besoins de

notre systme.


35/75


Page 34

Chapitre 4Analyse et spcification des besoins

IntroductionLanalyse des besoins est une tape fondamentale la conduite russie de tout projet. En

effet, la description dtaille des besoins implicites et explicites dun systme informatique

permet une meilleure comprhension de ce systme et de ses fonctionnalits.

Ce chapitre prsentera les mthodologies utilises pour la spcification des besoins

fonctionnels ainsi que les besoins non fonctionnels.

4.1 Besoins en Architecture

Le systme doit se conformer larchitecture globale du protocole MPEG DASH qui

comprend ncessairement deux lments

Serveur MPEG DASH qui contient les mdias diffuser sous forme de plusieurs

segments contigus et ayant un fichier de description selon le format MPD.

Client DASH qui est le consommateur de service de streaming provenant du

serveur MPEG DASH.

Figure 17 Architecture d'un systme de streaming MPEG-DASH

Dans le cadre de notre projet la tche sera essentiellement la ralisation de lapplication

cliente (Smartphone de lafigure 17).


36/75


Page 35

4.2 Expression des besoins

Avant de raliser le diagramme de cas dutilisation il est ncessaire de dterminer et de

classer les diffrents besoins de notre systme selon leurs natures.

4.2.1 Besoins Fonctionnels

Lapplication cliente doit assurer les fonctionnalits suivantes :

Support du protocole MPEG DASH (faire des modifications au niveau de

larchitecture Android afin dajouter le support du protocole)

Tlchargement du fichier MPD de description du mdia diffuser

Tlchargement des diffrents segments du mdia

Passage manuel dune qualit une autrelors de la visualisation dun flux

Gestion intelligente de la qualit de la vido selon un algorithme de dcision

4.2.2 Besoins non fonctionnels

Il y a lieu duvrer pour assurer un maximum de:

Ergonomie de la prsentation : Un aspect trs important pour le succs dune

application mobile ou desktop est laspect prsentation.

Robustesse de lapplication: elle doit fonctionner dans toutes les circonstances.

Ininterruption du streaming : Fluidit de lapplication pas de blocage ni

dinterruption.

Adaptation lenvironnement daccueilLapplication doit se conformer aux capacits

de lenvironnement daccueil (capacit en bande passante et CPU etc).

4.3 Diagramme des cas dutilisation

Pour pouvoir raliser le diagramme de cas dutilisation de notre systme, nous avons jug

quil est ncessaire didentifier les diffrents acteurs qui vont interagir avec ce systme.Tous les cas dutilisation pourront tre dtermins en dtectant et analysant toutes les

interactions survenues entre les diffrents acteurs et le systme.

4.3.1 Identi fi cation des acteur s

Dans le cadre de notre application, on nauraquun seul type dacteurs qui est lutilisateur

de Smartphone qui pourra ainsi bnficier des diffrentes fonctionnalits de notre application.

4.3.2 L iste des cas dutilisation

En analysant linteraction qui pourrait avoir lieu entre lutilisateur dun Smartphone et notre

application on peut prvoir les cas dutilisation suivants:


37/75


Page 36

Grer le Streaming : - Lancer, Arrter et redmarrer la lecture de contenu multimdia.

- Passage en Mode plein cran.

Grer la qualit de streaming : augmenter /diminuer la rsolution daffichage.

Parcourir la liste des vidos disponibles.

4.3.3 Modlisation

Pour pouvoir modliser notre systme nous avons opt pour le langage UML (Unified

Modeling Language). Cest un langage universel de modlisation trs employ dans les

diffrentes tudes de modlisations des systmes informatiques.

Ainsi, nous avons opt pour cet outil afin de modliser les besoins fonctionnels exigs par

notre systme. Il est prciser que ce choix est justifi par le fait que le langage UML facilite

normment la comprhension des reprsentations complexes et quil se distingue par sa

souplesse.

Notre diagramme des cas dutilisation va dcrire de manire textuelle avec la notation dulangage UML tous les cas dutilisationprcits. Ainsi, on pourra mettre en vidence toutes

les relations fonctionnelles entre les diffrents acteurs et notre systme tudi. Ce que chaque

acteur attend du systme sera ainsi modlis laide de ce diagramme.

Figure 18 Diagramme de cas d'utilisation global


38/75


Page 37

4.4 Description des cas dutilisation

Une fois la modlisation des diffrents cas dutilisation termine, commence la phase de

description des cas dutilisation. Le premier cas dutilisation expos lors de la section 4.3.3 est

Lancer le Streaming , ce cas dutilisation a pour but de visualiser une vidoprslectionne, pour raliser ce cas, lutilisateur doit obligatoirement choisir en avance une

vido parmi la liste des vido disponibles.

Les tableaux suivants nous permettent de mieux cerner les autres cas dutilisation modliss

par le diagramme global reprsent dans la figure 18.

Cas dutilisation

Titre Arrter le streaming

But Arrter la visualisation dune vido

quelconque en cours de lecture

Rsum Lutilisateur choisit darrter le streaming dela vido en cours de lecture

Acteurs Utilisateur du Smartphone

Pr conditions Une vido en cours de lecture

Besoin dIHM Bouton permettant larrt du streaming

Exigences non fonctionnellesTableau 1 Description du cas d'utilisation Arrter le streaming

Cas dutilisation

Titre Passer en mode dadaptation automatique

But Obtenir la meilleure qualit daffichage dune

faon automatiqueRsum Lutilisateur choisit loption dadaptation

automatique


Pr conditions Mode dadaptation manuel en cours

Besoin dIHM Menu de slection du mode dadaptation

Exigences non fonctionnelles Le passage doit se faire instantanmentTableau 2 Description du cas d'utilisation Passer en mode dadaptation automatique

Cas dutilisation

Titre Visualiser une vido en mode plein cran

But Visualiser une vido en mode plein cran

Rsum Lutilisateur choisit loption de visualisation

en mode plein cran


Pr conditions une vido en cours de lecture

Besoin dIHM Bouton permettant le passage en mode plein

cran

Exigences non fonctionnelles Assurer la continuit du streaming lors du

redimensionnement de la vido

Tableau 3 Description du cas d'utilisation Visualiser une vido en mode plein cran


39/75


Page 38

Cas dutilisation

Titre Passer une suprieure/infrieure rsolution

vido

But Obtenir une qualit meilleure /infrieur de la

vido

Rsum Lutilisateur choisit un instant donn depasser une qualit meilleure/infrieure


Pr conditions Vido en cours de streaming un niveau de

qualit affich sur lcran

Besoin dIHM 2 boutons pour permettre le passage dautre

niveau de qualit ainsi quun champ pour

afficher le niveau de rsolution actuel

Exigences non fonctionnelles Assurer la continuit du streaming lors du

changement de la qualit daffichage

Tableau 4 Description du cas d'utilisation Passer une suprieure/infrieure rsolution vido

4.5 Diagramme de squences

Aprs avoir spcifi et dcrit les diffrents cas dutilisation de notre systme, il est

ncessaire dillustrer le droulement de ces cas en ayant recours aux diagrammes de

squence.

Ce type de diagramme permet de reprsenter toutes les interactions survenues sous forme

dintercommunications entre les diffrents composants du systme. Ces intercommunications

sont concrtises par lenvoi des messages sous forme dappels de mthodes selon lordre

chronologique.

Pour mieux illustrer le droulement des diffrents cas dutilisation, on va modliser ci-

aprs (figure 19), comme exemple, un scnario. Dans ce scnario, lutilisateur lance le

streaming, puis aprs quelques minutes de lecture du mdia, choisit de passer en mode

dadaptation manuel afin de pouvoir finalement amliorer la qualit daffichage

manuellement.


40/75


Page 39

Figure 19 Diagramme de squence d'un scnario d'utilisation du MPEG DASH Player

Conclusion

Dans ce chapitre nous avons commenc par dterminer les diffrents besoins fonctionnels etnon fonctionnels que doit garantir notre systme, puis nous avons identifi et dtaill les

principaux cas dutilisations usuels travers les diagrammes des cas dutilisation et un

diagramme de squence.

Dans le chapitre suivant nous allons entamer ltape de conception de notre projet.


41/75


Page 40

Chapitre 5

La phase Conception du Android MPEG DASH Player

Introduction

Nous passons dans ce chapitre la conception de notre projet. Une mthode d'analyse et

de conception a pour objectif de formaliser les tapes indispensables du dveloppement d'un

systme afin de rendre ce dveloppement plus fidle aux besoins du client. A cet effet, Nous

prsentons dans un premier temps une tude conceptuelle comportant larchitecture de

lapplicationafin den extraire les diffrents modules qui composent notre systme. Ensuite,

nous passons une conception dtaille travers laquelle nous prsentons les diagrammes de

classes relatifs aux diffrents modules de lapplication.

5.1 Architecture globale du systme

L'architecture gnrale du streaming selon le protocole MPEG-DASH en utilisant la

librairie Libdash est reprsente dans la figure 20. Dans cette figure, les parties de couleur

orange reprsentent les parties standardises (spcifies par le protocole MPEG DASH).

La livraison du MPD, les heuristiques de contrle et le lecteur multimdia lui-mme, sont

reprsents en bleu sur la figure 20. Ces pices ne sont pas standardises et permettent la

diffrenciation des solutions de l'industrie en raison de la performance ou des caractristiquesdiffrentes qui peuvent tre intgres ce niveau.

Libdash est galement reprsent en bleu et encapsule l'analyse MPD et une partie HTTP, qui

sera gr par la bibliothque. Par consquent, la bibliothque fournit des interfaces pour le

contrle en continu de DASH et de Media Player pour accder au fichier MPD et aux

segments des mdias tlchargeables.

L'ordre de tlchargement de ces segments des mdias ne sera pas pris en charge par la

bibliothque il est laiss sous la matrise du Dash Streaming Control.

Dans un dploiement typique, un serveur de DASH fournit des segments dans plusieurs dbits

et des rsolutions diffrentes. Le client reoit tout d'abord le fichier MPD.

Libdash qui fournit une interface oriente objet pour analyser et manipuler le fichier

MPD et par suite acqurir les informations contenues dans ce fichier telles que les relations

temporelles correspondantes aux diffrentes qualits des segments. Sur la base de ces

informations, le client peut tlcharger des segments des mdias individuels travers Libdash

n'importe quel point dans le temps. Par consquent diffrentes conditions de bande passante

peuvent tre manipules par le passage un niveau de qualit correspondant aux limites des

segments afin de fournir une exprience Smooth Streaming.

Cette adaptation ne fait pas partie de Libdash et la norme MPEG-DASH sera laisse

l'application qui utilise Libdash et plus prcisment la partie de contrle du streaming (Dash

Streaming Control).


42/75


Page 41

Figure 20 Architecture globale du systme de streaming en utilisant Libdash[Net5]

La partie serveur dans le cadre de notre projet sera le serveur Dataset de luniversit ITEC

de Katlenburg.

Ainsi les composants dans le cadre de la prsente tude que nous avons raliss et non

fournis par la librairie Libdash sont la partie Dash Streaming Control et le Media Player

(figure 20).Aprs la phase de compilation de la librairie Libdash pour Android, la tche tait de

raliser le Dash Streaming Control que nous avons intitul Dash Player.

Dash Player exploite lAPI fournie par la librairie Libdash pour raliser le contrle sur la

qualit et lordre de tlchargement des segments aprs analyse du fichier MPD.


43/75


Page 42

5.2 Conception dtaille

Aprs avoir expos larchitecture globale de notre systme, nous prsentons dans cette

section une tude dtaille de la conception de notre systme.

5.2.1 Archi tecture physique

Pour commencer, nous exposerons le diagramme de dploiement du systme (figure 21).

Ce diagramme est une vue physique qui a pour but de dcrire la rpartition des diffrents

composants du systme.

Figure 21 Diagramme de dploiement du systme

Daprs le diagramme de la figure 21, nous pouvons conclure que larchitecture matrielle

de notre systme se compose principalement de deux nuds. Lepremier nud est le serveur

web de luniversit de Katlenburg ITEC qui joue le rle de fournisseur de contenu.

Le deuxime nud de notre systme est le terminal Android client qui joue le rle de

rcepteur dans notre systme. Il est noter que la communication entre ces deux nudsse fait

via le protocole HTTP.


44/75


Page 43

5.2.2 Ar chi tecture Logique

Produire un flux/fournir une API

Donnes chang

Demander/accepter un flux

Utiliser

La figure 22permet de modliser larchitecture logiqueglobale de notre systme. En effet,

cette figure permet de visualiser lacheminement des flux de donnes et linteraction entre les

diffrentes entits logiques de lAndroid MPEG DASH Player.

Les diffrentes entits logiques modlises dans la figure 22 sont :

La librairie Libdash

Le Dash Streaming Control

La Couche daccs auxflux.

Media Player

Media Player

Couche daccs aux flux

Dash Streaming Control : DashPlayer

Libdash

API de manipulation dufichier MPD

Librairies dedcodage

Librairiesgraphiques

Flux Audio & vido brut

Figure 22 Modlisation de l'architecture logique du Android MPEG-DASH Player


45/75


Page 44

Aprs avoir expos larchitecture logique globale de notre systme nous passons la

conception dtaille de chacun de ses composants.

5.2.3 Diagrammes de classesa-Diagramme de classes du Dash Player

On commence par le diagramme declasses de la partie Dash Streaming Control (Dash

Player).

Figure 23 Diagramme de classe du DASH Streaming Control

Comme on le remarque dans la figure 23, llment principal de lapplication Dash Player

est le DashReceiver. En effet, cette classe possde comme attributs des instances des

lments MPD, DashManager, MediaObjectBuffer et AdaptationLogic.

Le rle de chacun de ces attributs est :


46/75


Page 45

Le MPD est la classe responsable de modliser et grer toutes les oprations sur un

fichier MPD.

Le Dash Manager assure lappel de lanalyseur de fichier XML de la librairie

Libdash. Cet analyseur va tre dploy pour analyser lautre attribut du

DashReceiver, le MPD.

Le MediaObjectBuffer reprsente dans notre systme le buffer de lecture de flux

multimdia brut. Juste aprs lanalyse du fichier MPD, le buffer commence se

remplir par les segments en cours de tlchargement.

LAdaptationLogic a la charge deffectuer le choix des segments tlcharger.

Il est signaler que la mthode Notify() du MediaObjectBuffer est la mthode

responsable du calcul du taux de chargement du buffer de lecture. Cette mthode sera utile

lors de la mise en place de lalgorithme dadaptation de notre application.

b-Diagramme de classes du Android M edia Player

Dans la deuxime partie de la conception dtaille des diffrents composants de notre

systme, nous allons exposer le diagramme de classes de lapplication Android Media Player.

Daprs la figure 24, on voit que lentit principale de notre Android Media Player est le

PlayerUI. Cest une classe java qui hrite de la classe FragmentActivity(FragmenActivity est

une classe qui hrite de android.app.Activity et qui rajoute dautre mthodes comme

getSupportFragmentManager() et getFragmentManager() [Net8]). Le PlayerUI possde

comme attribut une instance de la classe PlayerControl. Cette dernire classe se charge desappels des fonctions natives (C++) assurant le lancement du streaming et du dcodage. La

classe PlayerControl construit aussi une instance de lentit PlayerView. Cette dernire entit

est la classe responsable de la construction de la surface ncessaire la visualisation de la

vido.


47/75

Android M