Rapport de Stage PFE MPEG DASH [PDF]

Zitiervorschau

Réf :

AU : 2012-2013

Université de Sousse Ecole Nationale d’Ingénieurs de Sousse

Mémoire de Projet de Fin d'Études Présenté en vue de l’obtention du diplôme d’

Ingénieur en Génie Informatique Appliquée Option : Ingénierie des Systèmes Distribués Option : Ingénierie des Réalisation D’un Systèmes distribués Android MPEG DASH Player

Réalisé par : Hadj Ali Oussama

Soutenu Devant le jury

Soutenu le 29/06/2013 devant les jurys

Président : Monsieur BEN ARBIA Anis Rapporteur: Madame SADDI Najla Encadreur : Monsieur KHAYATI Naoufel,ENISo Encadreur : Monsieur JERBI Aymen, TELNET Encadreur : Monsieur BEN GHAZI Lassaad, TELNET

@OUSSAMA2013

Android MPEG DASH Player

Résumé

Au cours des dernières années, l’Internet est devenu un canal important pour la distribution des données multimédias principalement via le protocole HTTP. Plusieurs protocoles de streaming intelligents se sont basés 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 société tunisienne TELNET, en tant que société innovatrice et leader technologique, a bien estimé le potentiel de ce protocole de streaming et elle a décidé de concevoir une application Android permettant la lecture de contenu multimédia diffusé via le protocole MPEG DASH L’application doit permettre le streaming de vidéos par ce protocole dans un système Android ainsi que le déploiement d’un algorithme de décision contrôlant la qualité de diffusion au cours de Streaming permettant d’obtenir la meilleure qualité possible. Mots-clés: Streaming, MPEG DASH, Android, multimédia, HTTP, Adaptivité, Qualité

Page 1

Android MPEG DASH Player

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

Page 2

‫‪Android MPEG DASH Player‬‬

‫ملخص‬ ‫خالل السنوات األخيرة ‪،‬أصبحت شبكة اإلنترنت أهم وسيلة لتوزيع البيانات متعددة الوسائط في المقام األول عبر‬ ‫البروتوكول » ‪.«HTTP‬‬ ‫استندت عدة بروتوكوالت ذكية على البروتوكول » ‪ «HTTP‬لتحقيق تدفق سلس ومتواصل مع ضمان جودة عالية‬ ‫في نوعية عرض ا لبيانات من بينها نذكر البروتوكول مبق داش » ‪.«MPEG DASH‬‬ ‫أدركت المؤسسة التونسية تلنات بصفتها مؤسسة رائدة في مجاالت التكنولوجيا و االبتكار و البحث العلمي االضافات‬ ‫الهامة و المستقبل الزاهر الستعمال البروتوكول مبق داش ‪.‬فقررت انتاج و تطوير تطبيق يمكن من استعمال مبق داش لبث‬ ‫البيانات‪.‬‬ ‫التطبيق المزمع انجازه يمكن من مشاهدة سلسة و متواصلة ألشرطة فيديو متدفقة عبر البروتوكول مبق داش على أجهزة‬ ‫الهواتف الذكية ذات نظام تشغيل أندرويد‪.‬‬ ‫هذا التطبيق يحتوى على خوارزمية تمكن من الحصول على أفضل جودة ممكنة للبث‪.‬‬ ‫مفاتيح ‪ :‬أندرويد ‪ ,‬تدفق‪ ,‬جودة ‪,‬الوسائط المتعددة ‪,‬مبق داش‬

‫‪Page 3‬‬

Android MPEG DASH Player

Remerciements

Nous souhaitons que cette page du présent document puisse exprimer tous nos sincères sentiments de reconnaissance et de remerciements que nous adressons à tous ceux qui ont contribué ou aidé, de près ou de loin, à réaliser ce travail. Nous tenons à exprimer toute notre immense gratitude à Mr. JERBI Aymen et Mr. BEN GHAZI Lassaad, nos éminents encadreurs à la respectable société TELNET, pour leur disponibilité, leurs directives et leurs précieux conseils qu'ils nous ont prodigués.

Nous saisissons cette occasion pour remercier vivement notre encadreur monsieur KHAYATI Naoufel, maître assistant à l’Ecole Nationale d’Ingénieurs de Sousse ENISO, pour son soutien continu, ses remarques pertinentes, ses conseils constructifs et inépuisables qu’il nous a fournis et surtout la motivation soutenue qu’il nous a inculqués tout au long de la période de l’étude 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 donnée durant les trois années d'études. Nous souhaitons aussi adresser nos sincères salutations à nos collègues et amis qui n’ont jamais hésité à nous encourager et à nous apporter leurs infinis soutiens. Enfin et avec plein de respect, nous tenons à présenter les plus forts remerciements à tous les membres du jury qui ont bien voulu accepter d’évaluer notre modeste travail.

Page 4

Android MPEG DASH Player Table des matières Introduction Générale ............................................................................................................................ 10 Chapitre 1 : Présentation et contexte du projet ..................................................................................... 13 1.1 Présentation de l’organisme d’accueil ................................................................................. 13 1.2. Contexte du projet et Objectifs ........................................................................................... 16 1.2.1 Problématique ............................................................................................................... 16 1.2.2 Objectifs ....................................................................................................................... 18 Chapitre 2 : Etat de l’art 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) d’Apple .................................................................... 25 2.4.2 Le Microsoft's Live Smooth Streaming (LSS) ............................................................. 26 2.4.3 Le HTTP Dynamic Streaming d’Adobe ....................................................................... 26 Chapitre 3 : Le protocole MPEG DASH : présentation et étude de l’existant ..................................... 27 3.1 Spécifications du protocole MPEG-DASH ......................................................................... 27 3.1.1 Présentation du protocole ............................................................................................ 27 3.1.2 Chronologie de développement .................................................................................... 27 3.1.3 Mécanisme de fonctionnement ..................................................................................... 28 3.1.4 Avantages du protocole MPEG DASH ........................................................................ 31 3.2 Etude de l’existant ............................................................................................................... 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 spécification 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 .............................................................................................. 35 4.3 Diagramme des cas d’utilisation ......................................................................................... 35 Page 5

Android MPEG DASH Player 4.3.1 Identification des acteurs .............................................................................................. 35 4.3.2 Liste des cas d’utilisation ............................................................................................. 35 4.3.3 Modélisation ................................................................................................................. 36 4.4 Description des cas d’utilisation .......................................................................................... 37 4.5 Diagramme de séquences .................................................................................................... 38 Chapitre 5 La phase Conception du Android MPEG DASH Player .................................................... 40 5.1 Architecture globale du système ......................................................................................... 40 5.2 Conception détaillée ............................................................................................................ 42 5.2.1 Architecture physique................................................................................................... 42 5.2.2 Architecture Logique .................................................................................................... 43 5.2.3 Diagrammes de classes ................................................................................................. 44 Chapitre 6 Réalisation de l’application Android MPEG DASH Player ................................................ 47 6.1 Environnement de travail .................................................................................................... 47 6.1.1 Environnement matériel ............................................................................................... 47 6.1.2 Environnement Logiciel ............................................................................................... 48 6.2 Démarche de réalisation de l’Android MPEG DASH Player .............................................. 49 6.2.1 Compilation de la librairie Libdash pour l’environnement Android ICS de la carte TI AM335x................................................................................................................................. 49 6.2.2 Réalisation de la partie Dash Streaming Control.......................................................... 51 6.2.3 La logique d’adaptation : Algorithme de décision pour le choix de la qualité de streaming ............................................................................................................................... 51 6.2.4 Phase de décodage ........................................................................................................ 54 6.2.5 Réalisation de la couche accès aux flux ...................................................................... 54 6.2.6 Phase de visualisation ................................................................................................... 55 6.3 Tests et résultats expérimentaux .......................................................................................... 56 Conclusion générale .............................................................................................................................. 62 Bibliographie ......................................................................................................................................... 64 Glossaire ................................................................................................................................................ 65 Annexe A : Structure d’un fichier MPD................................................................................................ 66 Annexe B : Architecture du système d’exploitation Android .............................................................. 69 Annexe C:Procédure de mise en place de l’environnement Android sur la carte TI AM335xevm ...... 73

Page 6

Android MPEG DASH Player

Liste des tableaux

Tableau 1 Description du cas d'utilisation Arrêter le streaming ............................................................ 37 Tableau 2 Description du cas d'utilisation Passer en mode d’adaptation automatique ......................... 37 Tableau 3 Description du cas d'utilisation Visualiser une vidéo en mode plein écran .......................... 37 Tableau 4 Description du cas d'utilisation Passer à une supérieure/inférieure résolution vidéo ........... 38 Tableau 5 Caractéristiques de l'environnement de travail ..................................................................... 47 Tableau 6 Caractéristiques de la Carte TI AM335x evm ...................................................................... 48 Tableau 7 Emulation de l'algorithme de décision.................................................................................. 60 Tableau 8 Analyse de la structure d'un fichier MPD ............................................................................. 68 Tableau 9 Les noyaux linux utilisés par Android .................................................................................. 72

Page 7

Android MPEG DASH Player

Liste des figures Figure 1 Trafic Internet envisagé pour les prochaines années trié par types des terminaux [Net1] ...... 10 Figure 2 Estimation du type de trafic internet des Smartphones triée par type d'activité [Net1] .......... 11 Figure 3 Logo de TELNET [Net 2] ....................................................................................................... 13 Figure 4 Organigramme de TELNET.................................................................................................... 15 Figure 5 Schéma simplifié du streaming adaptatif [Net3] ..................................................................... 17 Figure 6 Les ventes mondiales de Smartphones triées par système d’exploitation ............................... 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] ........................................ 23 Figure 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 développement du standard MPEG DASH ................................................. 27 Figure 13 Schéma 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 téléchargés selon la variation de la bande passante ....................................................................................................................................... 31 Figure 17 Architecture d'un système de streaming MPEG-DASH ....................................................... 34 Figure 18 Diagramme de cas d'utilisation global .................................................................................. 36 Figure 19 Diagramme de séquence d'un scénario d'utilisation du MPEG DASH Player ...................... 39 Figure 20 Architecture globale du système de streaming en utilisant Libdash[Net5] ........................... 41 Figure 21 Diagramme de déploiement du système ............................................................................... 42 Figure 22 Modélisation 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 Modélisation de la démarche adoptée pour la réalisation du Android MPEG DASH Player 49 Figure 27 Couche librairies de l'architecture du système Android généré ............................................ 50 Figure 28 Modélisation de la structure du buffer de lecture.................................................................. 53 Figure 29 Ecran d'attente ....................................................................................................................... 56 Figure 30 Fenêtre principale de l'application Android MPEG-DASH Player....................................... 56 Figure 31 Vidéo en cours de lecture avec playlist couverte .................................................................. 57 Figure 32 Illustrations des différentes fonctionnalités disponibles pour le contrôle manuel de la qualité .................................................................................................................................................... 57 Figure 33 Illustration du changement de la qualité d'image automatique ............................................. 58 Figure 34 Illustration de passage d'une vidéo à une autre dans la playlist ............................................ 59 Figure 35 Structure d'un fichier MPD ................................................................................................... 66 Figure 36 Architecture du système d'exploitation Android ................................................................... 69 Figure 37 La couche Application de l'architecture du SE Android ....................................................... 69 Page 8

Android MPEG DASH Player 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

Page 9

Android MPEG DASH Player Introduction Générale Aujourd’hui, le streaming est une technologie très populaire par laquelle le contenu multimédia est délivré en continu à partir d'un serveur de streaming à des utilisateurs finaux. Les méthodes de diffusion sont en amélioration continue afin de se conformer aux capacités du réseau et aux scénarios d'utilisation qui sont hétérogènes. Ainsi la création de techniques qui fournissent automatiquement la meilleure qualité possible aux consommateurs est devenue un objectif capital et un enjeu important. Des études récentes ont montré la croissance en nombre et surtout la diversité de dispositifs d'utilisateur final. Ces dernières années, les Smartphones sont devenus immensément populaires. En effet ils ont été considérablement améliorés d’une année à l’autre, pour offrir des services Internet utilisant des connexions sans fil et à large bande. Les Smartphones présentent aussi des fonctionnalités similaires aux ordinateurs modernes, ils sont équipés de systèmes d'exploitation plus sophistiqués que ceux des téléphones cellulaires ordinaires. Les Smartphones permettent ainsi l'installation d'applications tierces. La figure 1 illustre les prévisions pour les prochaines années en termes de trafic réseau, ce qui annonce une prochaine augmentation considérable du trafic mobile (estimé à représenter les 26,6% du trafic total du réseau en 2015 et 67.5% du trafic en 2017).

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

Les données vidéo sont clairement devenues le principal type de contenu transféré par les applications mobiles. Comme le montre la figure 2, le trafic vidéo va croître de façon exponentielle dans les prochaines années.

Page 10

Android MPEG DASH Player

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

Avec la croissance du trafic de transfert de média via Smartphones et l’augmentation continue des capacités des réseaux internet, plusieurs fournisseurs de contenu multimédia sont entrés en concurrence afin de créer la technique de streaming permettant d’obtenir la meilleure qualité de streaming possible, c’est dans ce cadre qu’est apparu la notion de streaming 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 média dominante pour les prochaines années. C’est dans ce cadre que se situe le sujet de notre projet de fin d’études en vue d’obtenir le diplôme d’ingénieur en informatique appliquée. Ce stage a été effectué pour une durée de quatre mois et demie au sein de la société TELNET. Ce projet de fin d’études a comme objectif principal la réalisation d’un lecteur de contenu multimédia pour le système d’exploitation mobile Android supportant le protocole MPEG DASH. Tout au long de ce document qui s’articule autour de six chapitres, nous exposerons les différentes études et tâches réalisées durant ce stage. Le premier chapitre sera consacré à la présentation du contexte général et de la problématique de notre projet. Dans le deuxième chapitre, nous présenterons une ébauche d’étude sur l’état de l’art du processus de streaming ainsi que l’évolution qu’a connu ce processus. Dans le troisième chapitre, les différentes caractéristiques du protocole MPEG DASH ainsi que les solutions disponibles sur le marché et supportant ce protocole seront détaillées. Dans le quatrième chapitre, nous présenterons les études faites lors de la phase consacrée à Page 11

Android MPEG DASH Player l’analyse et la spécification des besoins. Le cinquième chapitre contiendra la description des différentes étapes de conception de la solution proposée. Enfin, le dernier chapitre exposera la démarche adoptée dans la phase de réalisation ainsi que les résultats obtenus à sa fin. Le présent rapport se terminera par une conclusion qui étalera le bilan de ce stage tout en précisant les perspectives suscitées par notre travail ainsi que les améliorations qui peuvent lui être apportées.

Page 12

Android MPEG DASH Player Chapitre 1 : Présentation et contexte du projet Introduction Dans ce chapitre, on présentera en premier lieu la société TELNET, l’organisme qui a bien voulu nous accueillir en mettant à notre disposition les moyens nécessaires au bon déroulement de ce stage. La deuxième partie de ce chapitre sera consacrée à la présentation de la problématique qui a poussé la société TELNET à proposer le sujet de projet de fin d’étude exposé dans le présent document. La dernière partie de ce chapitre comportera une énumération des différents objectifs fixés pour le sujet du stage ainsi que la démarche adoptée pour la réalisation de ces objectifs.

1.1 Présentation de l’organisme d’accueil

Figure 3 Logo de TELNET [Net 2]

TELNET HOLDING(le logo de TELNET est représenté dans la figure 3) est un groupe composé de plusieurs filiales, basé sur l’innovation et les hautes technologies. Depuis sa création en 1994, TELNET a réalisé de nombreux projets et a cumulé une grande expérience et un savoir-faire unique dans ses différents domaines d'activités. Le groupe est réputé pour son savoir-faire, sa stabilité, son sens de l'éthique et la valeur de ses actionnaires. Le 18 février 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 stratégique a garanti et garantira dans le futur la bonne gouvernance du groupe, sa pérennité et l'adhésion de tous les collaborateurs au projet de faire de Telnet Holding une référence technologique au niveau international. Le groupe TELNET a pour vocation d’être une société d’ingénierie créatrice 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 d’importants accords tels que : 

Le premier accord est signé en 2006 avec le groupe SAFRAN (groupe aéronautique français) et il consiste en une coopération industrielle entre les deux parties dans les domaines de l’aéronautique, de la sécurité et des cartes à puces.

Page 13

Android MPEG DASH Player  

Deux ans après ce premier accord, les deux groupes Altran (groupe Français) et TELNET leaders dans l’ingénierie ont signé un contrat de joint-venture permettant la naissance de la société Altran Telnet Corporation. TELNET a signé des accords avec les groupes TEUCHOS, SAFRAN Aerospace India et DASSAULT SYSTEMES.

Dans un souci de mieux se rapprocher de ses clients en Europe, le groupe TELNET a opté pour un mode opératoire selon le modèle Front office (France) / Back office (Tunisie). 1.1.1. Savoir-faire du groupe TELNET La société TELNET a obtenu une première certification ISO 9001 version 2000 pour la conception, le développement et l’intégration de produits logiciels dans le domaine des technologies de l’information. Elle a obtenu une deuxième certification en 2006 et devient ainsi la première entreprise informatique en Tunisie, en Afrique et dans le monde Arabe ayant rejoint le cercle réduit des entreprises informatiques adoptant le référentiel CMMI niveau 5 dans le monde. Le centre de développement de TELNET est le seul au niveau régional à être certifié CMMI niveau 5 et ISO 9001 version 2008. Ainsi, le groupe assure la sécurité, la confidentialité et la propriété intellectuelle de ses prestations. Depuis 2010, TELNET est devenue membre de l’IEEE " Institue of Electrical and Electronics Engineers". Elle a aussi signé un accord de collaboration avec le Commissariat à l’Energie atomique et aux Energies Alternatives (CEA). 1.1.2. Domaines d’activité de TELNET Le groupe TELNET vise à être parmi les premiers du monde dans l’innovation et dans la technologie et ce en essayant d’être un acteur de référence sur le plan national et international. TELNET œuvre dans les secteurs des :  Télécommunications  Multimédia  Transport  Automobile  Défense et Avionique  Sécurité  Monétique et carte à puce  Electronique  Industrie  Ingénierie Mécanique.  Systèmes d’information L’évolution considérable de l’entreprise et l’importance qu’elle accorde au concept qualité, lui ont permis de diversifier ses activités et d’innover dans différents domaines. Ces domaines représentent des activités importantes et pour leur bonne gestion, Telnet leur a consacré des départements.

Page 14

Android MPEG DASH Player 1.1.3. Organigramme de TELNET Les départements sont organisés de la manière présentée dans la figure 4 Conseil D’administration

Direction Administrative et financière

Direction Générale

Département Systèmes Electroniques

Département Études Logicielles

Télécom

Multimédia

Industrie

Automobil e

Monétique & carte à puce

Direction Marketing & Télécom

Département Réseaux et Télécoms

Défense & Avionique

Système d’information

Figure 4 Organigramme de TELNET

1.1.4. Aperçu sur les missions de certains départements a- Département Systèmes Electroniques : Ce département est responsable de la conception et du design des systèmes électroniques qui seront par la suite testés et validés. Ce département comprend trois services:  Le service de l’automobile : où se réalise le développement embarqué (tel que celui des calculateurs moteurs), le test et la validation des travaux réalisés ainsi que le développement des systèmes de diagnostic automobile.  Le service de l’automatisation du design électronique.  Le service de la CAO (Conception Assistée par Ordinateur) qui assure la conception et le design électronique. b- Département Réseaux et Télécoms : La mission fondamentale de ce département est de réaliser les fonctions suivantes : – fournir des solutions d’interconnexion informatique et de télécommunications pour la mise en place des réseaux d’entreprises (LAN/WAN). – réaliser des projets en sous-traitance pour le compte de constructeurs Télécoms. – actualiser les technologies de l’information. – maintenir techniquement la gestion et l’exploitation des réseaux des entreprises. c- Département Etudes Logicielles : La mission de ce département est la conception et le développement de produits logiciels dans divers domaines d’activités à savoir : les télécommunications, les terminaux, la sécurité et la défense et les systèmes spécifiques. Ces activités sont assurées grâce à la contribution de principaux services : - Le service des technologies de l’information : au sein duquel se réalise le développement pour la sécurité et la défense et les systèmes spécifiques. - Le service des télécoms et des terminaux : où s’effectue le développement des logiciels embarqués (commutateurs, routeurs, compteurs électroniques). Page 15

Sécurité

Android MPEG DASH Player Nous avons eu l’occasion de réaliser notre projet de fin d’étude au sein de ce département et plus précisément au sein de l’équipe Multimédia. Activité de l’équipe Multimédia L’équipe multimédia opère dans le domaine grand public tels que les écrans LCD/ DLP, les décodeurs IP, les récepteurs et les imprimantes photo et dans le domaine bilatéral avec les opérateurs particuliers par les encodeurs CBR/VBR, les multiplexeurs, les modulateurs ou encore les serveurs vidéo.

1.2. Contexte du projet et Objectifs 1.2.1 Problématique L'immense variété de dispositifs d'utilisateurs finaux opérant sous réseaux mobiles hétérogènes a conduit à un défi intéressant: produire une technique d'adaptation dynamique et automatisée entre producteurs et consommateurs, pour offrir la meilleure qualité possible de contenu. Plusieurs contraintes sont présentes dans le processus de diffusion de contenu ou streaming, telles que les fluctuations des bandes passantes de réseau ou des propres capacités du client. Par exemple, les dispositifs d'utilisateurs finaux peuvent être limités par la résolution d'affichage, par le débit binaire (bit rate), ou par les formats de médias pris en charge. La figure 5 ci-dessous illustre l'adaptation pour des clients similaires qui connaissent différentes limitations dans le réseau de communication, et donc différente quantité de données transmises par unité de temps à ces différents clients. Dans ce contexte, le streaming adaptatif représente une famille de techniques qui abordent le problème de la différence dans les données fournies à des clients différents. Par le biais du contenu multimédia en couches et les mécanismes 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 présentées dans le prochain chapitre.

Page 16

Android MPEG DASH Player

Figure 5 Schéma simplifié du streaming adaptatif [Net3]

Plusieurs systèmes d'exploitation (SE) ont été développés pour les Smartphones Android (voir détails à l’Annexe B) est un SE mobile open source développé par Google. Des statistiques récentes [Net4] ont montré qu’Android est le système d'exploitation mobile prédominant dans le marché (56.9% au niveau mondial), suivi par iOS d'Apple (22.5%), Symbian (8.5%) et Windows Mobile (1.9%). Les précédentes statistiques sont représentées dans la figure 6. Les ventes mondiales de smartphones classés par système 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 classés par système d'exploitation en Mai 2011

Android 36% Symbian 27,4% Autre 3,3% Windows Phone 3,6 % iOs 16,8% RIM 12,9%

Le système d’exploitation Android est devenu largement dominant du marché des Smartphones Figure 6 Les ventes mondiales de Smartphones triées par système d’exploitation

Page 17

Android MPEG DASH Player A l'heure actuelle, il existe peu de services de streaming adaptatif pour Android de Google. Les protocoles de streaming supportés 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), déjà soutenu dans les téléphones 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 appelée streaming adaptatif dynamique sur HTTP (DASH). Dans le cadre des recherches pour l’amélioration des fonctionnalités de la plateforme Android et vu le nombre limité de protocoles de streaming supportés nativement par cette plateforme et vu l’avènement de plusieurs nouveaux protocoles de streaming évolués, l’équipe Multimédia de la société TELNET a proposé pour étude et réalisation le sujet intitulé « Android MPEG DASH Player » visant à réaliser une solution complète supportant le nouveau protocole de streaming de MPEG sur Android.

1.2.2 Objectifs L’équipe Multimédia de TELNET a défini les objectifs suivants pour le présent projet de fin d’études :  

Modification du Framework Android pour ajouter le support du protocole MPEG DASH Réalisation d'un Android Média Player exploitant le protocole MPEG DASH

Pour atteindre ces objectifs, les tâches suivantes sont préconisées dans ce projet:  

Ajout du support du protocole MPEG DASH ce qui conduit à une étude approfondie des capacités de l’Android Media Framework (Stagefright). Définition des formats de médias et protocoles de streaming qui sont nativement supportés par Stagefright.

La phase de réalisation de l’Android Média Player nécessite : -

La définition de plusieurs paramètres à analyser lors de l'évaluation. Cette évaluation concernera notamment l'efficacité, la performance, les retards, et l'utilisation de la bande passante. Ces paramètres doivent être définis facilement et clairement afin de pouvoir comparer efficacement les mécanismes d'adaptation. Page 18

Android MPEG DASH Player -

-

La proposition et l'évaluation des différents mécanismes d'adaptation du côté du client et qui sont capables de converger vers le débit binaire maximal durable. Ces mécanismes précisent la logique de l'application du client, fournissant une utilisation efficace du débit disponible sur le réseau. Des différentes procédures seront examinées afin d'optimiser l'utilisation de la bande passante disponible et étudier les inconvénients potentiels.

Conclusion Dans ce chapitre nous avons commencé par exposer le progrès atteint dans le domaine du streaming de contenu multimédia et ceci en énumérant et en détaillant les principaux protocoles de streaming existants. En analysant ces protocoles, nous avons pu constater l’importance et la prédominance du streaming de contenu média sur le marché tout en remarquant notamment le nombre limité de protocoles de streaming accessibles via Android. Ainsi, nous pouvons justifier amplement l’intérêt et l’utilité de la réalisation de l’application « Android MPEG DASH Player » sujet de notre projet de fin d’études. Ce qui constitue une source d’une solide motivation pour pouvoir apporter une contribution personnelle dans le système d’exploitation Android. Dans le chapitre suivant, nous présenterons l’état de l’art du streaming.

Page 19

Android MPEG DASH Player Chapitre 2 : Etat de l’art du Streaming Introduction Notre sujet se propose d’ajouter le support d’un nouveau protocole de streaming à la plateforme Android. Nous estimons qu’il est très utile d’élaborer une étude théorique exhaustive couvrant les différentes techniques de streaming disponibles sur le marché. Cette étude nous permet de mieux situer le projet dans son contexte. Il existe actuellement trois méthodes principales pour livrer le streaming multimédia: le streaming traditionnel, le streaming progressif et le streaming adaptatif On présentera en premier lieu l’état de l’art de streaming en énumérant les différents types de protocoles de streaming disponibles actuellement sur le marché tout en signalant les avantages et les inconvénients de chacun de ces protocoles

2.1 Streaming traditionnel Le streaming traditionnel nécessite un protocole mode connecté (« statefull ») qui établit une session entre le prestataire et le client. Dans cette technique, les médias sont envoyés sous la forme de paquets. Le protocole de transport en temps réel (RTP) avec le Real-Time Streaming Protocol (RTSP) sont fréquemment utilisés pour mettre en place un tel service.

2.1.1 Real-Time Transport Protocol (RTP) Le Real-Time Transport Protocol (RTP) décrit un système de paquets qui fournit des flux vidéo et audio sur des réseaux IP. Il a été développé par le groupe de transport audio vidéo de travail de l'IETF en 1996. Le RTP est un protocole bout-à-bout, temps réel pour les services de réseau 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 médias dans le cas de l'Internet Protocol Television (IPTV). Un service de multimédia RTP est généralement utilisé en conjonction avec RTSP, avec l'audio et la vidéo transmise en flux RTP distincts. La spécification RTP décrit deux sous-protocoles qui sont le protocole de transfert de données (RTP données) et le protocole RTP Control (RTCP). RTP est utilisé pour transférer des données multimédia en utilisant différents codecs avec horodatage et des numéros de séquence. Ces horodateurs et les numéros de séquence permettent au récepteur de détecter la perte de paquets et d'effectuer si nécessaire réorganisation et synchronisation des flux multimédia, entre autres activités. 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 contrôle d'appel Skinny Protocol (SCCP), ou le Session Initiation Protocol (SIP). Page 20

Android MPEG DASH Player RTP ne fournit pas un mécanisme 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 contrôle de flux fourni par le protocole lui-même, le contrôle de flux et l'évitement d'encombrement sont plutôt 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 contrôle de session qui fournit un cadre extensible pour contrôler la transmission de données en temps réel. Il a été développé par le contrôle de la session multimédia multipartisme groupe (MMUSIC) de l'IETF de travail en 1998. RTSP est utile pour établir et commander des sessions de média entre des points d'extrémité (end points), mais il n'est pas responsable de la transmission de données de média. En effet, le RTSP s'appuie sur des mécanismes de prestation basés sur RTP. En contraste avec HTTP, RTSP est un protocole en mode connecté (statefull) : le client et le serveur peuvent émettre des requêtes. Ces requêtes peuvent être effectuées de trois façons différentes: (1) les connexions persistantes utilisées pour plusieurs (requête / réponse) transactions, (2) une connexion par transaction ou (3) pas de connexion. Certaines implémentations 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 progressif Le Streaming progressif est une technique populaire et largement utilisé sur Internet permettant de transférer des données entre le serveur et le client. Le Streaming progressif peut généralement être réalisé en utilisant un serveur HTTP régulier. Le principe de streaming progressif est que les utilisateurs demandent du contenu multimédia qui est téléchargé progressivement dans un tampon local. Dès qu'il y aura suffisamment de données les médias commencent à jouer par contre si le taux de lecture dépasse la vitesse de téléchargement, la lecture est retardée jusqu'à ce que plus de données soient téléchargées. Le téléchargement progressif a quelques inconvénients:   

Un gaspillage de bande passante si l'utilisateur décide d'arrêter de regarder le contenu vidéo, puisque les données ont été transférées et tamponnées et ne seront pas jouées. Pas d'adaptation du débit binaire, car tous les clients sont considérés égaux en termes de bande passante disponible. Pas de support pour les sources médiatiques en direct(le live streaming).

2.3 Le streaming adaptatif Le streaming adaptatif est une technique qui détecte la bande passante disponible de l'utilisateur et la capacité du processeur afin d'ajuster la qualité de la vidéo qui est fourni à l'utilisateur et d'offrir la meilleure qualité possible qui peut être délivrée à cet utilisateur dans sa situation actuelle (sa bande passante actuelle). Cette technique de streaming nécessite que le codeur (l’encodeur) fournisse une vidéo à des débits multiples (ou plusieurs encodeurs Page 21

Android MPEG DASH Player peuvent être utilisés). En conséquence, les utilisateurs auront la meilleure qualité de streaming qui leur est possible. Les techniques d'adaptation du débit binaire de la source vidéo à largeur de bande variable peuvent être classées en trois catégories:   

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 vidéo brut à la volée (sans arrêt) côté serveur. Un schéma du principe de cette technique est représenté dans la figure 7. Le principal avantage de cette approche est la granularité fine qui peut être obtenue, puisque les médias à diffuser peuvent être transcodés suivant la bande passante disponible de l'utilisateur.

+

Contrôleur

Transcodeur

Contenu Brut

Paramètres d’encodage

Streaming Adaptatif

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

Cependant, il y a quelques inconvénients graves qui méritent d’être soulignés. Tout d'abord, le coût élevé de transcodage est le résultat de l'adaptation du contenu vidéo brut plusieurs fois pour plusieurs demandes ayant des qualités différentes. Par ailleurs et pour des raisons d’exigences de calcul d'un système de transcodage en temps réel, le processus de codage doit être effectué dans des serveurs appropriés afin d'être déployé dans les CDN (Content Delivery Network).

2.3.2 Encodage évolutif Utilisant un standard de CODEC évolutif comme H.264/MPEG-4 AVC, la résolution d'image et la vitesse de défilement peuvent être adaptées sans avoir à encoder de nouveau le contenu vidéo brut. Cette approche tend à réduire la charge de traitement, mais elle est limitée à un ensemble de formats de CODEC évolutives. Un schéma de principe de cette technique est représenté dans la figure 8. Page 22

Android MPEG DASH Player

Contrôleur

Encodeur évolutif

+

Contenu Brut

Paramètres d’encodage

Vidéo évolutive

Streaming Adaptatif

Figure 8 Approche de l'encodage évolutif

Néanmoins, le déploiement sur CDNs est compliqué dans cette démarche vue la nécessité de recourir à des serveurs spécialisés pour mettre en œuvre la logique d'adaptation.

2.3.3 Commutation de contenu (Stream switching) La méthode de commutation de contenu encode le contenu vidéo brut à plusieurs différents débits croissants, générant N versions d'un même contenu, dites « niveaux vidéo ». Comme le montre la figure 9, un algorithme doit choisir dynamiquement le niveau vidéo qui correspond à la bande passante disponible de l'utilisateur. Lorsque des changements dans cette bande passante se produisent, l'algorithme passe simplement à des niveaux différents pour assurer une lecture continue.

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

Page 23

Android MPEG DASH Player L'objectif principal de cette méthode est de minimiser les coûts de traitement, puisque aucun autre traitement n'est nécessaire une fois tous les niveaux vidéo ont été générés. En outre, cette approche ne nécessite pas l’utilisation d’un format de codec spécifique, on dit que cette méthode est totalement agnostique de CODEC. En revanche, les besoins de stockage et de transmission doivent être pris en compte car le même contenu vidéo est encodé N fois (mais à différents débits). Le seul inconvénient de cette approche est la granularité grossière car il y a seulement un ensemble discret de niveaux. La figure 10 illustre l’approche de commutation dans le temps, en supposant que tous les segments ont la même durée et que les opérations de commutation sont effectuées après 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 HTTP Récemment, une nouvelle solution pour le streaming adaptatif a été conçue, basée sur la technique de commutation de flux (Stream switching). Il s'agit d'une méthode hybride qui utilise HTTP comme protocole de livraison au lieu de définir un nouveau protocole. Les sources vidéo et audio sont découpées en segments courts de la même longueur (typiquement de quelques secondes).En option, les segments peuvent être coupés le long d'un Groupe de vidéo d'images, ainsi chaque segment débute avec une image clé, ce qui signifie que les segments n'ont pas de dépendances passé / futur entre eux. Enfin, tous les segments sont encodés dans le format souhaité et hébergés sur un serveur HTTP. Les clients demandent les segments séquentiellement et les téléchargent en utilisant le téléchargement progressif du protocole HTTP. Les segments sont lus dans l'ordre et comme ils sont contigus, la lecture globale résultante est lisse et toute la logique d'adaptation est commandée par le client. Cela signifie que le client calcule le temps à aller chercher chaque segment afin de passer à un débit binaire supérieur ou inférieur. Un exemple de base est représenté sur la figure 11, où le dispositif de requête-réponse Page 24

Android MPEG DASH Player représente la logique de commutation appliquée sur le côté client. Les flèches épaisses correspondent à la transmission d'un segment de données.

GET :Manifest

Lance la lecture

200 OK

Fichier Manifest Analysé

Envoie du fichier Manifest

GET :segment 1:level 1

Adaptation

200 OK

Envoie segment 1 avec la qualité 1

GET :segment i:level k Demande segment i avec la qualité k

200 OK

Envoie segment i avec la qualité k

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

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 d’éviter les problèmes 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 mécanismes d'évitement d'encombrement. De plus les services basés sur HTTP peuvent utiliser les serveurs HTTP existants et les infrastructures de CDN existants.

2.4.1 Le HTTP Live Streaming (HLS) d’Apple En mai 2009, Apple a publié un protocole Streaming de Media basé sur HTTP communication (Apple HLS) pour transmettre des flux bornés et sans limite de données multimédias. Apple HLS est basé sur la technologie de Streaming Media Network Emblaze qui a été publié en 1998. Selon cette spécification, un flux global est décomposé en une succession de petits téléchargements de fichiers basés sur HTTP, où les utilisateurs peuvent sélectionner des flux alternatifs encodés à des débits différents. Et comme les clients HLS utilisent des requêtes de type HTTP aux fichiers à télécharger. Cette méthode fonctionne à travers les pare-feu et serveurs proxy (contrairement aux protocoles UDP tels que RTP qui nécessitent des ports ouverts dans le pare-feu ou nécessitent l'utilisation d'une passerelle de Page 25

Android MPEG DASH Player couche application). Initialement, les utilisateurs téléchargent une playlist M3U étendu qui contient plusieurs Uniform Resource Identifiers (URI) correspondant à des fichiers multimédia, où chaque fichier 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 d’Apple supporte seulement le format de conteneur MPEG2-TS

2.4.2 Le Microsoft's Live Smooth Streaming (LSS) Smooth Streaming est une extension IIS-Internet Information Services) Media Services qui permet le streaming adaptatif de supports multimédia aux clients via le protocole HTTP. Microsoft a démontré avec succès la livraison de vidéo 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 de LSS est la décomposition et ensuite le stockage d’un média sous la forme de plusieurs fragments contigus appelés chunk. Ces fragments sont décrits à l’aide d’un fichier manifest (fichier XML) qui contient la description du média à diffuser ainsi que les différentes qualités disponibles et l’adresse des différents chunks à télécharger progressivement. La communication client-serveur dans le cadre de streaming LSS se limite à quatre opérations :  Manifest Request: Le client demande à télécharger le fichier Manifest.  Manifest Response: Le serveur envoi le fichier Manifest au client.  Fragment Request : Le client demande de télécharger un chunk à travers son URI.  Fragment Response : Le serveur envoi au client le fragment requis.

2.4.3 Le HTTP Dynamic Streaming d’Adobe 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 différentes spécifications de format pour les fichiers multimédias (Flash Video ou F4V) et les manifestes (Flash Media manifeste ou F4M). Pour déployer la solution d'Adobe, il est nécessaire de mettre en place un Flash Media Streaming Server, qui est un produit propriétaire et commercial. En outre, les utilisateurs sont obligés d’installer le Flash Player d'Adobe. Conclusion Dans ce chapitre, nous avons commencé par présenter l’évolution qu’a connu le processus de streaming. A cet effet, les différentes techniques de streaming ainsi que leurs avantages et inconvénients ont étés détaillés. Dans le chapitre suivant, le protocole de streaming dont l’ajout du support à la plateforme Android est l’objectif essentiel de notre projet, sera présenté.

Page 26

Android MPEG DASH Player Chapitre 3 : Le protocole MPEG DASH : présentation et étude de l’existant

Introduction Afin de réussir la phase de conception et de développement, nous avons jugé qu’il est utile de procéder à une étude préliminaire sur le protocole MPEG DASH et sur l’existence et disponibilité de solutions supportant le protocole MPEG DASH sur la plateforme Android. Pour illustrer la démarche adoptée pour cette étude, nous avons consacré la première partie de chapitre pour exposer la spécification du protocole MPEG DASH ainsi que les différents apports et avantages de ce nouveau protocole par rapport aux autres protocoles de streaming existants (ces protocoles ont été présentés dans le deuxième chapitre du présent rapport). La deuxième partie de ce chapitre sera consacrée à la présentation de l’unique solution supportant MPEG DASH existante sur Android dans le marché. La dernière partie de ce chapitre comportera une énumération et spécification des différentes solutions envisageables pour pouvoir réaliser notre propre solution de streaming adaptatif dynamique sur Android exploitant le protocole MPEG DASH.

3.1 Spécifications du protocole MPEG-DASH 3.1.1 Présentation du protocole MPEG DASH : C’est 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, Live Smooth Streaming, ou l’équivalent chez Adobe ou Apple, le MPEG DASH permet de faire du streaming dynamique (Dash = Dynamic Adaptive Streaming over HTTP) en adaptant le flux vidéo en fonction du débit internet disponible. Le flux vidéo pourra être adapté tout au long de la lecture de la vidéo, et donc s’améliorer ou baisser en qualité, en suivant la connexion internet et l’intensité de son débit. L’avantage d’un standard comme le MPEG DASH est l’interopérabilité entre plateformes. On peut ainsi imaginer un flux vidéo unique compatible pour Smartphones, PC/Mac/Linux ou même TV. Il suffira que le logiciel de lecture soit compatible. Ce standard a été approuvé par 24 sociétés, dont notamment Microsoft, Apple, Adobe, Netflix ou encore Qualcomm…

3.1.2 Chronologie de développement Phase d’exploration

Juillet 2009

Phase de réalisation

Avril 2010

Phase de normalisation

Janvier 2011

Novembre 2011

Figure 12 Chronologie du développement du standard MPEG DASH

Page 27

Android MPEG DASH Player La technologie MPEG-DASH a été développée par le groupe MPEG (groupe spécialisé dans le développement de normes internationales pour le traitement et le codage signaux audio et/ou vidéo). Les travaux sur le protocole MPEG DASH ont débuté en Juillet 2009.Ces travaux sont passés par trois phases principales (les 3 phases sont représentées par le chronogramme de la figure 12) :  Phase d’exploration : cette phase a débuté en juillet 2009 avec les workshops MMT (Modeling Multi-commodity Trade) de MPEG.  Phase de réalisation : cette phase a commencé en Avril 2010, elle a duré sept mois : consistant notamment en des procédures d’appel d’offre 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é réalisé avec succès en Novembre 2011. En avril 2012, la norme MPEG-DASH a été publié sous la référence ISO / IEC 23009-1:2012.

3.1.3 Mécanisme de fonctionnement MPEG-DASH introduit le concept de présentation de médias (MPD) qui est un ensemble structuré de contenu vidéo / audio : Une présentation multimédia constituée d'une séquence d'une ou plusieurs périodes qui sont consécutives et qui ne se chevauchent pas. Chaque période comprend une ou plusieurs représentations du même contenu multimédia et a un temps de démarrage qui lui est attribué par rapport au début de la présentation des médias. Chaque représentation spécifie un profil de qualité vidéo constitué de plusieurs paramètres tels que la bande passante, l'encodage et la résolution. Aussi une représentation contient un ou plusieurs segments, représentés et localisés par leurs Universal Resource Locator (URL). Les segments contiennent des fragments du contenu vidéo réel. Un Media Présentation Description (MPD) est un schéma de fichier basé sur XML (voir figure 14) qui contient toute la structure d'une présentation multimédia exposée ci-dessous (figure 13).

Page 28

Android MPEG DASH Player

Figure 13 Schéma d'illustration du contenu d'un fichier MPD

Figure 14 Exemple d'un fichier MPD

Le protocole MPEG DASH spécifie la syntaxe et la sémantique du MPD, le format de segments, et le protocole de livraison (HTTP). Heureusement, il permet des configurations Page 29

Android MPEG DASH Player flexibles pour mettre en œuvre différents types de services de streaming. Les paramètres suivants peuvent être sélectionnés de manière flexible: la taille et la durée des segments, le nombre de représentations et le profil de chaque représentation (débit binaire, CODEC, format conteneur, etc.) En ce qui concerne le comportement du client, il peut décider d’une manière flexible quand et comment télécharger des segments et choisir une représentation appropriée. La figure 15 illustre la communication entre serveur et client dans un service de streaming MPEG DASH. D'abord le client récupère le fichier MPD et par la suite il demande successivement les segments des médias. Dans chaque période, un niveau de représentation est choisi, en fonction des temps de récupération et d'autres paramètres déterminés par le client.

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

La figure 16 ci-après illustre les changements de qualité de segments téléchargés le long d’une période, changements en fonction de la variation de la bande passante disponible.

Page 30

Android MPEG DASH Player

Figure 16 Illustration du changement de la qualité des segments téléchargés selon la variation de la bande passante

3.1.4 Avantages du protocole MPEG DASH DASH fournit des formats efficaces et de bonne qualité pour un streaming Aussi, Il permet : - la réutilisation (l’utilisation) des technologies existantes. En effet, il n’a pas de spécifications uniques et qui lui sont propres telles que celles de de codec conteneurs ou de DRM (Digital Rights Management), ce qui constitue un avantage indéniable par rapport 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 déploiement sur des simples serveurs web (il n’y a pas d’obligation à recourir à des serveurs spécifiques) Le principale apport de l’MPEG DASH c’est qu’il fournit une qualité de streaming de haut niveau et irréprochable : c’est une révolution dans le domaine de vidéo streaming. En effet, il n’y a plus de coupure lors de streaming et la qualité de l’image varie et peut atteindre de très grandes résolutions selon la variation de la bande passante - d’alléger la charge sur le serveur car le serveur fournit les fichiers MPD au client avec des différentes présentations (redondance de données avec des qualités différentes) - le déploiement flexible, en effet il permet le Live streaming et le streaming sur demande (onDemand streaming). - l’insertion de publicité pendant le streaming.

3.2 Etude de l’existant Actuellement les solutions qui implémentent le protocole MPEG DASH sur Android sont peu nombreuses. Le seul client existant jusqu’aujourd’hui est le Helix DNA Client qui est une solution payante et incomplète. Les autres solutions existantes sont soit des librairies soit des plugins offrant la capacité de supporter le protocole MPEG DASH (Libdash et gstdashdemux). Page 31

Android MPEG DASH Player

3.2.1 Helix 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 ultérieures. 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 bibliothèque 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 vidéo: conteneur H.264 et RealVideo format de fichier 3GP et RealVideo. Protocoles: HLS (Version 4), MPEG-DASH (ISO BMFF MP4).

3.2.2 La librairie Libdash Libdash est une API (Application Programmable interface) écrite en C + + qui fournit une interface orientée objet (OO) à la norme MPEG-DASH. Avantages d’utilisation de la librairie Libdash -

-

Multiplateforme (environnement de de développement) Implémente La totalité des spécifications du protocole MPEG DASH Mozilla Firefox a ajouté le support du protocole MPEG DASH en utilisant WebM. WebM[Net9] est un format multimédia 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].

Inconvénients d’utilisation de la librairie Libdash Absence d’algorithme d’adaptation. Un algorithme d’adaptation est un algorithme qui permet de se déplacer d’un segment à un autre selon la variation de la bande passante. En effet cet algorithme reste une charge à développer pour chaque client de la librairie.

3.2.3 Gstreamer : DASHbin et le plugin gstdashdemux GStreamer est une bibliothèque logicielle de manipulation de sons et d'images (appelée aussi Framework multimédia) écrite en langage C, initialement développée pour proposer une solution capable de concurrencer QuickTime et DirectShow sur GNU/Linux. Sa première version publique date du 31 octobre 1999. GStreamer se base sur une architecture modulaire composée d'un cœur (GStreamer) et de plugins (Base, Good,Ugly, Bad). Pour Page 32

Android MPEG DASH Player faciliter les usages commerciaux de GStreamer, Fluendo et Collabora ont œuvré ensemble à la création d'un SDK multiplateforme (Linux, Windows et MacOS X). Pour ajouter le support du protocole MPEG DASH à Gstreamer, il existe déjà deux solutions DASHBin et gstdashdemux. DASHBin est un nouvel élément qui s’ajoute au plug-in gst-plugins-bad afin de lui ajouter les trois entités suivantes:  mpdcommon: une librairie qui aide à lire et à gérer le fichier MPD.  mpdparse: un plug-in responsable du (XML parsing) analyse des fichiers MPD.  dashbin:client ou Player. gstdashdemux est un plug-in qui permet le streaming vidéo selon le protocole MPEG DASH. Le plugin est développé par une équipe de développeur d’Orange et dont le code source ainsi que les instructions d’installation sont disponibles . Avantages de l’utilisation de Gstreamer  Gstreamer est un outil puissant qui permet la construction de lecteurs multimédias pour la plupart des formats de fichiers multimédias.  Le développent de plugin pour Gstreamer est très bien documenté sur le site officiel de Gstreamer.  Comme c’est un système qui est basé sur l’utilisation plug-in. Le recours à des plugins déjà publiés et testés, permet l’insertion de plusieurs fonctionnalités comme l’ajout de sous-titre, Multiscreen … Inconvénient de l’utilisation de Gstreamer Cette solution semble ne pas être adoptée pour le moment, en effet nos investigations n’ont pas abou0ti à trouver un feedback à ce sujet ce qui n’encourage pas à adopter cette méthode. Conclusion Dans ce chapitre nous avons commencé par la définition et la spécification du nouveau protocole de streaming MPEG DASH Ensuite on a fait une énumération des solutions possibles pour la mise en place d’un client Android supportant le protocole MPEG DASH En analysant les avantages et les inconvénients 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 adoptée et la plus mature. Dans le chapitre suivant nous allons entamer l’étape d’analyse et spécification des besoins de notre système.

Page 33

Android MPEG DASH Player Chapitre 4 Analyse et spécification des besoins Introduction L’analyse des besoins est une étape fondamentale à la conduite réussie de tout projet. En effet, la description détaillée des besoins implicites et explicites d’un système informatique permet une meilleure compréhension de ce système et de ses fonctionnalités. Ce chapitre présentera les méthodologies utilisées pour la spécification des besoins fonctionnels ainsi que les besoins non fonctionnels.

4.1 Besoins en Architecture Le système doit se conformer à l’architecture globale du protocole MPEG DASH qui comprend nécessairement deux éléments  

Serveur MPEG DASH qui contient les médias à 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 système de streaming MPEG-DASH

Dans le cadre de notre projet la tâche sera essentiellement la réalisation de l’application cliente (Smartphone de la figure 17). Page 34

Android MPEG DASH Player 4.2 Expression des besoins Avant de réaliser le diagramme de cas d’utilisation il est nécessaire de déterminer et de classer les différents besoins de notre système selon leurs natures.

4.2.1 Besoins Fonctionnels L’application cliente doit assurer les fonctionnalités suivantes :  Support du protocole MPEG DASH (faire des modifications au niveau de l’architecture Android afin d’ajouter le support du protocole) 

Téléchargement du fichier MPD de description du média à diffuser



Téléchargement des différents segments du média



Passage manuel d’une qualité à une autre lors de la visualisation d‘un flux



Gestion intelligente de la qualité de la vidéo selon un algorithme de décision

4.2.2 Besoins non fonctionnels Il y a lieu d’œuvrer pour assurer un maximum de :    

Ergonomie de la présentation : Un aspect très important pour le succès d’une application mobile ou desktop est l’aspect présentation. Robustesse de l’application : elle doit fonctionner dans toutes les circonstances. Ininterruption du streaming : Fluidité de l’application pas de blocage ni d’interruption. Adaptation à l’environnement d’accueil L’application doit se conformer aux capacités de l’environnement d’accueil (capacité en bande passante et CPU etc…).

4.3 Diagramme des cas d’utilisation Pour pouvoir réaliser le diagramme de cas d’utilisation de notre système, nous avons jugé qu’il est nécessaire d’identifier les différents acteurs qui vont interagir avec ce système. Tous les cas d’utilisation pourront être déterminés en détectant et analysant toutes les interactions survenues entre les différents acteurs et le système.

4.3.1 Identification des acteurs Dans le cadre de notre application, on n’aura qu’un seul type d’acteurs qui est l’utilisateur de Smartphone qui pourra ainsi bénéficier des différentes fonctionnalités de notre application.

4.3.2 Liste des cas d’utilisation En analysant l’interaction qui pourrait avoir lieu entre l’utilisateur d’un Smartphone et notre application on peut prévoir les cas d’utilisation suivants : Page 35

Android MPEG DASH Player  Gérer le Streaming : - Lancer, Arrêter et redémarrer la lecture de contenu multimédia.

- Passage en Mode plein écran.  Gérer la qualité de streaming : augmenter /diminuer la résolution d’affichage. Parcourir la liste des vidéos disponibles.

4.3.3 Modélisation Pour pouvoir modéliser notre système nous avons opté pour le langage UML (Unified Modeling Language). C’est un langage universel de modélisation très employé dans les différentes études de modélisations des systèmes informatiques. Ainsi, nous avons opté pour cet outil afin de modéliser les besoins fonctionnels exigés par notre système. Il est à préciser que ce choix est justifié par le fait que le langage UML facilite énormément la compréhension des représentations complexes et qu’il se distingue par sa souplesse. Notre diagramme des cas d’utilisation va décrire de manière textuelle avec la notation du langage UML tous les cas d’utilisation précités. Ainsi, on pourra mettre en évidence toutes les relations fonctionnelles entre les différents acteurs et notre système étudié. Ce que chaque acteur attend du système sera ainsi modélisé à l’aide de ce diagramme.

Figure 18 Diagramme de cas d'utilisation global

Page 36

Android MPEG DASH Player 4.4 Description des cas d’utilisation Une fois la modélisation des différents cas d’utilisation terminée, commence la phase de description des cas d’utilisation. Le premier cas d’utilisation exposé lors de la section 4.3.3 est « Lancer le Streaming », ce cas d’utilisation a pour but de visualiser une vidéo présélectionnée, pour réaliser ce cas, l’utilisateur doit obligatoirement choisir en avance une vidéo parmi la liste des vidéo disponibles. Les tableaux suivants nous permettent de mieux cerner les autres cas d’utilisation modélisés par le diagramme global représenté dans la figure 18. Cas d’utilisation Titre But Résumé Acteurs Pré conditions Besoin d’IHM Exigences non fonctionnelles

« Arrêter le streaming » Arrêter la visualisation d’une vidéo quelconque en cours de lecture L’utilisateur choisit d’arrêter le streaming de la vidéo en cours de lecture Utilisateur du Smartphone Une vidéo en cours de lecture Bouton permettant l’arrêt du streaming

Tableau 1 Description du cas d'utilisation Arrêter le streaming

Cas d’utilisation Titre But Résumé Acteurs Pré conditions Besoin d’IHM Exigences non fonctionnelles

« Passer en mode d’adaptation automatique » Obtenir la meilleure qualité d’affichage d’une façon automatique L’utilisateur choisit l’option d’adaptation automatique Utilisateur du Smartphone Mode d’adaptation manuel en cours Menu de sélection du mode d’adaptation Le passage doit se faire instantanément

Tableau 2 Description du cas d'utilisation Passer en mode d’adaptation automatique

Cas d’utilisation Titre But Résumé Acteurs Pré conditions Besoin d’IHM Exigences non fonctionnelles

« Visualiser une vidéo en mode plein écran » Visualiser une vidéo en mode plein écran L’utilisateur choisit l’option de visualisation en mode plein écran Utilisateur du Smartphone une vidéo en cours de lecture Bouton permettant le passage en mode plein écran Assurer la continuité du streaming lors du redimensionnement de la vidéo

Tableau 3 Description du cas d'utilisation Visualiser une vidéo en mode plein écran

Page 37

Android MPEG DASH Player Cas d’utilisation Titre But Résumé Acteurs Pré conditions Besoin d’IHM

Exigences non fonctionnelles

« Passer à une supérieure/inférieure résolution vidéo » Obtenir une qualité meilleure /inférieur de la vidéo L’utilisateur choisit à un instant donné de passer à une qualité meilleure/inférieure Utilisateur du Smartphone Vidéo en cours de streaming à un niveau de qualité affiché sur l’écran 2 boutons pour permettre le passage à d’autre niveau de qualité ainsi qu’un champ pour afficher le niveau de résolution actuel Assurer la continuité du streaming lors du changement de la qualité d’affichage

Tableau 4 Description du cas d'utilisation Passer à une supérieure/inférieure résolution vidéo

4.5 Diagramme de séquences Après avoir spécifié et décrit les différents cas d’utilisation de notre système, il est nécessaire d’illustrer le déroulement de ces cas en ayant recours aux diagrammes de séquence. Ce type de diagramme permet de représenter toutes les interactions survenues sous forme d’intercommunications entre les différents composants du système. Ces intercommunications sont concrétisées par l’envoi des messages sous forme d’appels de méthodes selon l’ordre chronologique. Pour mieux illustrer le déroulement des différents cas d’utilisation, on va modéliser ciaprès (figure 19), comme exemple, un scénario. Dans ce scénario, l’utilisateur lance le streaming, puis après quelques minutes de lecture du média, choisit de passer en mode d’adaptation manuel afin de pouvoir finalement améliorer la qualité d’affichage manuellement.

Page 38

Android MPEG DASH Player

Figure 19 Diagramme de séquence d'un scénario d'utilisation du MPEG DASH Player

Conclusion Dans ce chapitre nous avons commencé par déterminer les différents besoins fonctionnels et non fonctionnels que doit garantir notre système, puis nous avons identifié et détaillé les principaux cas d’utilisations usuels à travers les diagrammes des cas d’utilisation et un diagramme de séquence. Dans le chapitre suivant nous allons entamer l’étape de conception de notre projet.

Page 39

Android MPEG DASH Player

Chapitre 5 La phase Conception du Android MPEG DASH Player Introduction Nous passons dans ce chapitre à la conception de notre projet. Une méthode d'analyse et de conception a pour objectif de formaliser les étapes indispensables du développement d'un système afin de rendre ce développement plus fidèle aux besoins du client. A cet effet, Nous présentons dans un premier temps une étude conceptuelle comportant l’architecture de l’application afin d’en extraire les différents modules qui composent notre système. Ensuite, nous passons à une conception détaillée à travers laquelle nous présentons les diagrammes de classes relatifs aux différents modules de l’application.

5.1 Architecture globale du système L'architecture générale du streaming selon le protocole MPEG-DASH en utilisant la librairie Libdash est représentée dans la figure 20. Dans cette figure, les parties de couleur orange représentent les parties standardisées (spécifiées par le protocole MPEG DASH). La livraison du MPD, les heuristiques de contrôle et le lecteur multimédia lui-même, sont représentés en bleu sur la figure 20. Ces pièces ne sont pas standardisées et permettent la différenciation des solutions de l'industrie en raison de la performance ou des caractéristiques différentes qui peuvent être intégrées à ce niveau. Libdash est également représenté en bleu et encapsule l'analyse MPD et une partie HTTP, qui sera géré par la bibliothèque. Par conséquent, la bibliothèque fournit des interfaces pour le contrôle en continu de DASH et de Media Player pour accéder au fichier MPD et aux segments des médias téléchargeables. L'ordre de téléchargement de ces segments des médias ne sera pas pris en charge par la bibliothèque il est laissé sous la maîtrise du Dash Streaming Control. Dans un déploiement typique, un serveur de DASH fournit des segments dans plusieurs débits et des résolutions différentes. Le client reçoit tout d'abord le fichier MPD. Libdash qui fournit une interface orientée objet pour analyser et manipuler le fichier MPD et par suite acquérir les informations contenues dans ce fichier telles que les relations temporelles correspondantes aux différentes qualités des segments. Sur la base de ces informations, le client peut télécharger des segments des médias individuels à travers Libdash à n'importe quel point dans le temps. Par conséquent différentes conditions de bande passante peuvent être manipulées par le passage à un niveau de qualité correspondant aux limites des segments afin de fournir une expérience Smooth Streaming. Cette adaptation ne fait pas partie de Libdash et la norme MPEG-DASH sera laissée à l'application qui utilise Libdash et plus précisément à la partie de contrôle du streaming (Dash Streaming Control).

Page 40

Android MPEG DASH Player

Figure 20 Architecture globale du système de streaming en utilisant Libdash[Net5]

La partie serveur dans le cadre de notre projet sera le serveur Dataset de l’université ITEC de Katlenburg. Ainsi les composants dans le cadre de la présente étude que nous avons réalisés et non fournis par la librairie Libdash sont la partie Dash Streaming Control et le Media Player (figure 20). Après la phase de compilation de la librairie Libdash pour Android, la tâche était de réaliser le Dash Streaming Control que nous avons intitulé Dash Player. Dash Player exploite l’API fournie par la librairie Libdash pour réaliser le contrôle sur la qualité et l’ordre de téléchargement des segments après analyse du fichier MPD.

Page 41

Android MPEG DASH Player 5.2 Conception détaillée Après avoir exposé l’architecture globale de notre système, nous présentons dans cette section une étude détaillée de la conception de notre système.

5.2.1 Architecture physique Pour commencer, nous exposerons le diagramme de déploiement du système (figure 21). Ce diagramme est une vue physique qui a pour but de décrire la répartition des différents composants du système.

Figure 21 Diagramme de déploiement du système

D’après le diagramme de la figure 21, nous pouvons conclure que l’architecture matérielle de notre système se compose principalement de deux nœuds. Le premier nœud est le serveur web de l’université de Katlenburg ITEC qui joue le rôle de fournisseur de contenu. Le deuxième nœud de notre système est le terminal Android client qui joue le rôle de récepteur dans notre système. Il est à noter que la communication entre ces deux nœuds se fait via le protocole HTTP.

Page 42

Android MPEG DASH Player 5.2.2 Architecture Logique

Media Player

Couche d’accès aux flux

Librairies de décodage

Librairies graphiques

Flux Audio & vidéo brut

Dash Streaming Control : Dash Player

API de manipulation du fichier MPD Produire un flux/fournir une API Données échangé Demander/accepter un flux

Libdash

Utiliser Figure 22 Modélisation de l'architecture logique du Android MPEG-DASH Player

La figure 22 permet de modéliser l’architecture logique globale de notre système. En effet, cette figure permet de visualiser l’acheminement des flux de données et l’interaction entre les différentes entités logiques de l’Android MPEG DASH Player. Les différentes entités logiques modélisées dans la figure 22 sont :    

La librairie Libdash Le Dash Streaming Control La Couche d’accès aux flux. Media Player Page 43

Android MPEG DASH Player Après avoir exposé l’architecture logique globale de notre système nous passons à la conception détaillée de chacun de ses composants.

5.2.3 Diagrammes de classes a-Diagramme de classes du Dash Player

On commence par le diagramme de classes 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, l’élément principal de l’application Dash Player est le DashReceiver. En effet, cette classe possède comme attributs des instances des éléments MPD, DashManager, MediaObjectBuffer et AdaptationLogic. Le rôle de chacun de ces attributs est :

Page 44

Android MPEG DASH Player 

Le MPD est la classe responsable de modéliser et gérer toutes les opérations sur un fichier MPD.



Le Dash Manager assure l’appel de l’analyseur de fichier XML de la librairie Libdash. Cet analyseur va être déployé pour analyser l’autre attribut du DashReceiver, le MPD.



Le MediaObjectBuffer représente dans notre système le buffer de lecture de flux multimédia brut. Juste après l’analyse du fichier MPD, le buffer commence à se remplir par les segments en cours de téléchargement.



L’AdaptationLogic a la charge d’effectuer le choix des segments à télécharger.

Il est à signaler que la méthode « Notify() » du « MediaObjectBuffer » est la méthode responsable du calcul du taux de chargement du buffer de lecture. Cette méthode sera utile lors de la mise en place de l’algorithme d’adaptation de notre application. b-Diagramme de classes du « Android Media Player »

Dans la deuxième partie de la conception détaillée des différents composants de notre système, nous allons exposer le diagramme de classes de l’application Android Media Player. D’après la figure 24, on voit que l’entité principale de notre Android Media Player est le PlayerUI. C’est une classe java qui hérite de la classe FragmentActivity (FragmenActivity est une classe qui hérite de android.app.Activity et qui rajoute d’autre méthodes comme getSupportFragmentManager() et getFragmentManager() [Net8]). Le PlayerUI possède comme attribut une instance de la classe PlayerControl. Cette dernière classe se charge des appels des fonctions natives (C++) assurant le lancement du streaming et du décodage. La classe PlayerControl construit aussi une instance de l’entité PlayerView. Cette dernière entité est la classe responsable de la construction de la surface nécessaire à la visualisation de la vidéo.

Page 45

Android MPEG DASH Player

Figure 24 Diagramme de classes du Android Media Player

Conclusion Dans ce chapitre, nous avons exposé la partie conceptuelle de notre projet. Cette partie conceptuelle a débuté par une architecture globale de notre système. Cette architecture a été détaillée en ayant recours au langage de modélisation unifié (UML) et en particulier aux diagrammes de classes et de déploiements. Dans le chapitre suivant, nous allons mettre en application cette étude avec tous ses détails afin de pouvoir la concrétiser. Page 46

Android MPEG DASH Player

Chapitre 6 Réalisation de l’application Android MPEG DASH Player Introduction Après avoir achevé l'étape de la spécification des besoins ainsi que la conception de l'application, nous consacrons ce chapitre à l'exposé du travail réalisé. Nous commençons par une description brève de l'environnement de développement (logiciel et matériel). Les étapes d’implémentation de notre solution seront détaillées au fur à mesure selon l’ordre chronologique de leur réalisation. Quelques imprimes écran seront présentées et donneront une idée sur le résultat final de notre travail ainsi que les différentes fonctionnalités offertes par notre application. Enfin les différentes difficultés rencontrées lors de cette phase seront récapitulées. Avant de commencer de décrire les différentes étapes de la réalisation de l’application Android MPEG DASH, il y a lieu de présenter une description sommaire de l’environnement de travail.

6.1 Environnement de travail En ce qui concerne l’environnement de travail, il est constitué de deux parties : un environnement matériel et un autre logiciel qui seront détaillés ci-après.

6.1.1 Environnement matériel Tout au long du présent stage les principaux travaux ont été effectués à l’aide d’un ordinateur portable de la marque Dell Inspiron ayant les caractéristiques suivantes : Modèle Système d’exploitation Processeur RAM Disque dur Carte graphique

Dell Inspiron N5010 Ubuntu 10.04 32 bits Intel i5 430M (2.67 GHz/3MB Cache) 4GB DDR3 500 GB SATA ATI Mobility Radeon HD 5470 1024 Mo dédiés

Tableau 5 Caractéristiques de l'environnement de travail

Pour réaliser les tests de validation, la société d’accueil Telnet a mis à notre disposition la carte TI AM335x evm (figure 25) qui est une carte de développement conçue par la société Texas Instruments.

Page 47

Android MPEG DASH Player

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

Les principales Caractéristiques techniques de la carte TI am335xevm sont : Processeur Ram Système d’exploitation supportés Alimentation Connectivité Affichage Ports

AM335 A8 ARM Microprocessor 512MB DDR2 Linux EZ SDK Android Gestionnaire d’alimentation TPS65910 WiFi/BT) via WL1271 Ecran tactile LCD 7 pouces UART (4) WiFi/BT (1) SD/MMC (2) USB2.0 OTG/HOST (1/1) Audio in/out JTAG CAN (2) 10/100 Ethernet

Tableau 6 Caractéristiques de la Carte TI AM335x evm

6.1.2 Environnement Logiciel La première étape lors de la réalisation de notre application MPEG DASH Player consistait en l’ajout du support du protocole MPEG DASH à la plateforme Android. L’architecture d’Android est organisée en 5 couches (voir Annexe B) dont une couche « Librairies » composée d’un ensemble de bibliothèques C / C++ utilisées par les autres composants du système Android. Ces librairies natives sont open source et permettent de guider le dispositif Android dans le traitement des différents types de données. Par exemple, la lecture et l'enregistrement de divers formats audio et vidéo sont guidés par la bibliothèque de Media Framework.

Page 48

Android MPEG DASH Player Parmi les deux solutions présentées lors du troisième chapitre, nous avons opté pour la solution de compiler la librairie Libdash pour l’environnement Android. Ainsi, c’est dans la couche « Librairies » d’Android que nous allons intégrer Libdash.

6.2 Démarche de réalisation de l’Android MPEG DASH Player Pour réaliser notre DASH Player, nous avons opté pour la démarche représentée par la figure 26 : Compilation de la librairie Libdash

Réalisation de la partie Dash Streaming Control

Elaboration de la Logique d’adaptation

Visualisation du flux

Réalisation de la couche accès aux flux

Décodage de flux

Figure 26 Modélisation de la démarche adoptée pour la réalisation du Android MPEG DASH Player

6.2.1 Compilation de la librairie Libdash pour l’environnement Android ICS de la carte TI AM335x Après analyse de l’architecture Android (voire Annexe C), on peut constater que les librairies natives (C/C++) sont intégrées uniquement au niveau de la couche Librairies et sachant que notre librairie Libdash est une librairie C++, on peut conclure qu’elle ne peut être intégrée que seulement au niveau de la couche librairies. Le type de compilation qu’on a réalisé pour la librairie Libdash est appelé compilation croisée. Il fait référence au processus de compilation de source en utilisant des chaînes de compilation capables de traduire un code source en code objet. Ce code objet a une architecture du processeur et des caractéristiques système différentes de celles du système où la compilation a été effectuée. Avant de commencer toute opération de compilation, il y avait lieu d’analyser les dépendances de la librairie Libdash. Cette analyse a révélé que celle-ci dépend des trois librairies Libcurl, Libxml2 et zlib. Il est à signaler que la librairie Libcurl ne fait pas partie des libraires natives d’Android. A cet effet, nous avons été obligés de compiler Libcurl pour Android. Par contre, Libxml2 et zlib font déjà partie de l’architecture Android.Toutefois, nous avons dû recompiler aussi libxml2 avec le flag « http » comme «enabled » (par défaut ce flag a pour valeur « disabled »). Ce changement de flag s’est avéré indispensable pour permettre l’analyse et le téléchargement de fichiers XML distants (accessibles via une URL). Les différentes librairies précitées se distinguent par les caractéristiques suivantes: 

Libcurl est une bibliothèque open source de transfert de fichiers via URL côté client supportant les protocoles FTP, FTPS, HTTP et HTTPS. Page 49

Android MPEG DASH Player





libxml2 Libxml2 est un XML parser(analyseur de fichier xml) à base de langage C et boîte à outils développée pour le projet Gnome, c’est un librairie open source et libre disponible sous la licence MITLibxml2. zlib zlib est une bibliothèque logicielle utilisée pour la compression de données. La première version publique de zlib 0,9, a été libérée le 1er mai 1995 et a été initialement conçu pour être utilisé avec la bibliothèque d'images libpng qui est un logiciel libre, distribué sous la licence zlib.

Pour permettre l’ajout d’une librairie C++, la plate-forme Android fournit une bibliothèque Libstd C + +. Mais cette librairie ne dispose que d’un nombre très limité de fonctionnalités et ne permet pas de supporter le STL (Standard Template Library). Comme Libdash est une librairie C++ utilisant des fonctions de type STL, il nous a fallu utiliser la librairie Stlport. Il est à signaler que STLport est un ANSI C + + multiplateforme. Il est un produit gratuit, open-source, et présentant des techniques de pointe et des optimisations pour une efficacité maximale Pour compiler les librairies précitées (Libdash, Libcurl), nous avons eu recours à l’utilisation de fichiers makefile qui ont une structure spéciale, et qui doivent s’appeler obligatoirement « Android.mk ». Un fichier Android.mk est un GNU(GNU's Not UNIX) Makefile écrit pour décrire et énumérer les fichiers sources C et C + + à reconnaitre par le système de compilation (dans notre cas le compilateur est le « arm-eabi-g++ compiler »). La syntaxe du fichier Android.mk est conçue pour permettre de regrouper les sources en des «modules». Un module peut être sous la forme de: -Bibliothèque statique -Bibliothèque partagée (Shared Library) Un Android makefile peut contenir la description d’un ou de plusieurs modules. Suite à cette phase de compilation, nous avons obtenu la couche librairie représentée par la figure 27.

Figure 27 Couche librairies de l'architecture du système Android généré

A ce stade, et comme la librairie Libdash ne fait que fournir une interface C++ pour les Page 50

Android MPEG DASH Player différentes fonctionnalités d’analyse de fichier MPD et téléchargement de segments, Il n’est pas encore pas possible de bénéficier de toutes les fonctionnalités de streaming du protocole MPEG DASH. Ainsi, nous devons développer la partie Dash Streaming Control de notre système afin de se conformer avec l’architecture du système fixé lors de la section 5.1 du chapitre précédent.

6.2.2 Réalisation de la partie Dash Streaming Control Après l’intégration de cette librairie dans la couche native d’Andoid l’étape suivante est la réalisation d’une application C++ qui exploite l’API fournie par la librairie Libdash afin de mettre en place la partie de contrôle de Streaming (Dash Streaming Control). L’application (DASH Player) crée, comporte une solution capable d’instancier une entité de contrôle nommée « DashReceiver » qui assure les fonctions suivantes  Télécharger le fichier MPD  Parser le fichier MPD téléchargé  Télécharger le contenu multimédia segment par segment  Remplir le Buffer de lecture. Pour pouvoir contrôler la qualité de la vidéo en cours de streaming, il a fallu réaliser une logique qui contrôle le téléchargement de segment avec une certaine qualité. Cette logique d’adaptation est un algorithme qui selon des critères de choix, fait les calculs nécessaires afin de pouvoir choisir la qualité convenable voire la meilleure qualité possible. Ces critères qui dépendent essentiellement des caractéristiques du terminal d’utilisation seront détaillés dans la section 6.2.3.

6.2.3 La logique d’adaptation : Algorithme de décision pour le choix de la qualité de streaming Le protocole MPEG DASH a pour but de permettre aux utilisateurs finaux de bénéficier de la meilleure qualité de streaming qui leur est possible. En tenant compte de la variation de la bande passante de la connexion internet utilisée et en fonction de la capacité (fréquence maximale du processeur) de leurs Device (terminaux). L’évolution de la qualité du streaming en fonctions des critères précités s’organise selon une logique d’adaptation. Un des points forts du protocole MPEG DASH est que cette logique d’adaptation est à la charge du client et non du serveur. Ainsi, le serveur n’a pas à se soucier de la nature et des caractéristiques du client. Il ne fait que fournir au client un fichier MPD présentant les différentes qualités disponibles pour le média. a- Critères de décision de l’algorithme d’adaptation Après une série de tests effectués sur l’application MPEG DASH Player, sans la mise en place d’un algorithme d’adaptation, on a pu constater que la qualité et la fluidité du streaming varient essentiellement selon les critères suivants : 

Bande/passante~ état du buffer Le critère de choix est l’état du buffer de lecture. En effet, l’état du buffer de lecture permet de donner une idée sur l’état réel de la bande passante. Il y a lieux de signaler Page 51

Android MPEG DASH Player que plus la bande passante est importante plus le Buffer se remplit plus vite. En connaissant l’état de la bande passante, la qualité d’affichage la plus convenable peut être choisie aisément. 

Charge CPU La visualisation et plus précisément la phase de décodage des contenus multimédias sur Android est très consommatrice en charge CPU et en mémoire. La connaissance de la charge CPU instantanée peut donner une idée précise cet instant sur l’aptitude du terminal Android à décoder un contenu multimédia d’une meilleure qualité.



Qualité actuelle de Streaming Pour pouvoir prendre la décision de passer à une meilleure/inférieure qualité il y a lieux d’avoir au préalable une idée précise sur la qualité actuelle du streaming pour éviter de passer à une qualité que le terminal utilisé lors du streaming n’est pas capable de la supporter.

b- Structure du Buffer Selon les spécifications du protocole MPEG DASH la lecture de contenu multimédia doit être effectuée selon une chaine continue d’intervalles de temps de durée égale (8 secondes dans notre cas).A chaque intervalle on peut se retrouver dans les cas critiques suivants :  Le Buffer est vide ce qui cause un arrêt de streaming, en attente de remplissage du Buffer de lecture. Pour éviter ce cas critique, l’algorithme d’adaptation comporte le mécanisme de contrôle suivant :  

Le streaming ne se lance qu’après un remplissage minimum du Buffer de lecture par 5 segments. Le streaming se lance par défaut dès l’atteinte du taux minimale de remplissage du buffer en adoptant automatiquement la qualité d’image la plus faible.

 Le taux de remplissage du Buffer est compris entre 20% et 80% : lors de cet intervalle le choix de niveau de la qualité d’affichage se fait selon les critères vitesse de la lecture et de l’écriture dans le buffer. Lorsque la lecture dans le buffer se fait beaucoup plus rapidement que l’écriture, il est plus opportun d’opter pour une taille de données à télécharger plus petite que celle déjà téléchargé ce qui entraine le passage à une qualité d’image plus faible. Dans le cas contraire, la lecture dans le buffer se fait beaucoup plus lentement que l’écriture, on optera pour l’amélioration de la qualité de la vidéo afin de de pouvoir télécharger des données ayant des tailles importantes et ainsi ralentir l’écriture dans le buffer. Dans le cas d’égalité entre la vitesse de la lecture et celle de l’écriture, il y a lieux de maintenir la même qualité d’affichage.  Le taux de remplissage du Buffer est compris entre 80% et 100% : Dans cet intervalle le choix de la qualité convenable se fait en fonction de la charge CPU du terminal.  Le taux de remplissage du Buffer est égal à 100%. Dans ce cas le buffer est en train de se remplir à une vitesse beaucoup plus importante que celle de la lecture de flux. Dans ce cas, on doit arrêter temporairement le remplissage du buffer afin de libérer de Page 52

Android MPEG DASH Player l’espace de stockage nécessaire pour permettre les téléchargements ultérieurs de données. L’algorithme de décision adoptée dans notre projet peut être modélisé comme suit : Fonctionnement de l’algorithme Début Algorithme d’adaptation : qualité_actuelle=0 ; Tant que (! fin de streaming) Faire Si (l’état du buffer est 20% et l’état du Buffer est vitesse_ecriture) alors Passer_a_la_qualité(qualité_actuelle-1) ; qualité_actuelle= qualité_actuelle-1 ; Fin si sinon si (vitesse lecture=vitesse_ecriture) alors garder_la_qualité(qualité_actuelle) ; sinon si (vitesse lecture80%) alors Si (charge_CPU1 >1 1 =1 >1 =1 1 =1 >1 >1 =1 =1 1

320 320 320 320 320 480 480 480 320 320 320 320 320 320 320 320

240 240 240 240 240 360 360 360 240 240 240 240 240 240 240 240

1 1 1 2 2 3 3 3 2 2 2 1 1 1 1 2

Tableau 7 Emulation de l'algorithme de décision

En observant le tableau 7 on remarque : Lorsque l’état du buffer de lecture marque un taux de remplissage inférieur à 20% (les lignes en couleur bleu du tableau) l’algorithme a pris la décision de maintenir la qualité d’affichage la plus faible conformément à ce qui a été indiqué lors de la section 6.2.3. Pour les taux de remplissage allant de 20% à 80% (lignes vertes du tableau), trois cas se présentent :   

la vitesse de lecture du buffer est plus importante que celle de l’écriture, on remarque qu’il y a eu un passage à une qualité d’affichage plus faible. La vitesse d’écriture du buffer est plus importante que celle de lecture, on remarque qu’il y a eu un passage à une meilleure qualité d’affichage. Les deux vitesses de lecture et écriture dans le buffer sont égales, la qualité d’affichage à cet instant est maintenue.

Pour les taux de remplissage dépassants les 80% les lignes en jaune, dès que la charge CPU dépasse le seuil 90% l’algorithme a décidé de diminuer la qualité d’affichage afin d’alléger la charge CPU et ainsi éviter tout risque de blocage de l’application. On conclue que les données du tableau 7 permettent de confirmer la bonne fonctionnalité de l’algorithme de décision conçu dans le cadre de notre projet.

Page 60

Android MPEG DASH Player

Conclusion Ce chapitre est le dernier volet de notre rapport. Nous avons indiqué, dans sa première partie, l'environnement matériel et logiciel utilisé. Par la suite, la démarche adoptée pour la réalisation de l’Android MPEG DASH Player a été explicitée. La troisième partie a été consacrée à la présentation de notre travail moyennant des captures d'écran de l’application développée. Nous exposons, dans ce qui suit, la conclusion générale de notre rapport ainsi que quelques perspectives envisageables suite au travail réalisé.

Page 61

Android MPEG DASH Player

Conclusion générale

A la fin de ce rapport, nous pouvons récapituler les principales étapes de nos travaux et résumer les plus importantes conclusions auxquelles nous avons abouti durant le stage de projet de fin d’études effectué à la société TELNET. Il y a lieu de rappeler que le but de ce projet est de créer un lecteur de contenu multimédia supportant le protocole MPEG DASH pour la plateforme Android. Les différentes phases de l’élaboration du MPEG-DASH Player ont été présentées et détaillées via le présent rapport. En premier lieu, une étude sur les protocoles de streaming disponibles sur le marché a été faite. Elle nous a permis de mieux définir notre système dans son environnement et de présenter les notions préliminaires indispensables à la compréhension des exigences fixées pour le projet. Nous avons effectué ensuite une recherche sur le protocole MPEG DASH et une étude critique sur les différentes techniques envisageables pour le mettre en œuvre. Ceci nous a permis de repérer les limites de chacune des dites techniques et d’adopter en conséquence la solution optimale pour réaliser nos objectifs. Cette phase a été suivie successivement par la phase de spécification des besoins et la phase de conception. Ce qui nous a permis de modéliser notre système et fixer ses limites. Par la suite nous avons procédé à la phase de réalisation du Player Android. Cette étape nous a permis de maitriser parfaitement l’architecture du système Android et de manipuler quelques nouvelles notions telles que la couche JNI, les fragments Android, les librairies de décodage de média et la compilation croisée. Grâce aux différentes études réalisées et aux conseils de nos encadreurs, nous sommes parvenus à réaliser cette application tout en respectant le cahier des charges du sujet et en satisfaisant les besoins requis pour le bon fonctionnement de notre application, besoins spécifiés dans le troisième chapitre du présent document. Cette application comprend un algorithme de décision permettant d’obtenir la meilleure qualité de streaming possible pour chaque utilisateur de l’application quel que soit le terminal utilisé. Le résultat final du travail réalisé a été exposé dans le dernier chapitre en recourant à quelques captures écran illustrant les différentes fonctions et le bon fonctionnement de notre application. C’était un stage agréable et très instructif lors duquel nous avons pu nous initier à de nouvelles technologies qui sont surtout des technologies de pointes. Ce stage a constitué, aussi, pour nous une bonne occasion pour s’initier au développement pour les systèmes embarqués, grâce à la manipulation de la carte d’évaluation de Texas Instruments « TI am335xevm » mise à notre disposition. De plus ce projet nous a permis de mettre en œuvre les connaissances que nous avons pu Page 62

Android MPEG DASH Player acquérir lors de nos années d’études à l’Ecole Nationale d’Ingénieurs de Sousse. En effet, ce projet a été l’occasion de pouvoir mettre en place notre propre solution ayant une architecture client-serveur de type business déporté. Enfin, il y a lieu de préciser que les quatre mois et demi que nous avons pu passer dans l’enceinte de cette société de grande envergure, ayant une maitrise des techniques innovantes, avec des ressources humaines de valeurs et de compétences variées, nous ont été très bénéfiques pour nos connaissances académiques et notre apprentissage à participer à des travaux de recherche et de création. Ce stage nous a permis aussi de mieux nous rapprocher du monde de travail et de l’entreprise et acquérir ainsi les moyens nécessaires pour une intégration dans une équipe avec une entière participation et une efficacité optimale. Comme perspectives pour notre solution, nous envisageons comme prochaines étapes la mise en place en premier lieu de notre propre serveur web de streaming et la réalisation d’une application qui permettrait d’administrer ce serveur. En deuxième étape, nous pourrons nous atteler à mettre en œuvre la principale qualité du protocole MPEG DASH qui est son interopérabilité. Cet objectif pourrait être atteint avec le développement d’autres lecteurs de contenu multimédia pour les autres plateformes tels que les Smartphones « IPhone » d’Apple, Windows 8 et Windows phone 8 de Microsoft.

Page 63

Android MPEG DASH Player Bibliographie

[Net1]http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/whit e_paper_c11-520862.html Dernière consultation le 20 Avril 2013 [Net 2] http://www.groupe-telnet.com/index.php/fr/ Dernière consultation le 10 Juin 2013 [Net3]http://www.academia.edu/454947/Feedback_Control_for_Adaptive_Live_Video_Strea ming Dernière consultation le 30 Mars 2013 [Ne4] http://www.gartner.com/newsroom/id/2482816 Dernière consultation le 20 Mai 2013 [Net5]http://www.bitmovin.net/isoiec-mpeg-dash-featuring-session-mobility/ consultation le 22 Avril 2013

Dernière

[Net6] http://www.bitmovin.net/libdash Dernière consultation le 20 Avril 2013 [Net7]http://www.ti.com/lsds/ti/arm/sitara_arm_cortex_a_processor/sitara_arm_cortex_a8/am 335x_arm_cortex_a8/toolsw.page Dernière consultation le 10 Juin 2013 [Net8]http://developer.android.com/ Dernière consultation le 13 Juin 2013 [Net9]http://www.webmproject.org/ Dernière consultation le 20 Mai 2013 [Net10]https://helix-client.helixcommunity.org/ Dernière consultation le 15 Mars 2013 [Net11]http://gstreamer.freedesktop.org/ Dernière consultation le 15 Mars 2013. [Net12]http://mpeg.chiariglione.org/ Dernière consultation le 29 Mai 2013 [Net13] http://www-itec.uni-klu.ac.at/dash/?p=833 Dernière consultation le 14 Mars 2013 [Net14] http://www-itec.uni-klu.ac.at/dash/?p=1083 Dernière consultation le 14 Mars 2013 [Net15]http://dashpg.com/ Dernière consultation le 28 Mai 2013.

Page 64

Android MPEG DASH Player Glossaire CDN : Content Delivery Networks CODEC: COmpressor-DECompressor DASH: Dynamic Adaptive Streaming over HTTP DDR: Double Data Rate DVM: Dalvik Virtual Machine HDS: Adobe's HTTP Dynamic Streaming HLS: Apple's HTTP Live Streaming HTTP : HyperText Transfer Protocol IP : Internet Protocol ISO: International Organization for Standardization IEC: International Electrotechnical Commission LSS: Microsoft's Live Smooth Streaming MPEG: Moving Picture Experts Group RTP: Real-time Transport Protocol RTCP: Real Time Control Protocol RTSP: Real Time Streaming Protocol SDK : Software Development Kit TCP: Transmission Control Protocol UDP: User Datagram Protocol URI : Uniform Resource Identifier URL : Uniform Resource Locator MPD : Media Presentation Description IETF: Internet Engineering Task Force ITEC: Institute for Technology, Enterprise and Competitiveness MMT: (Modeling Multi-commodity Trade) SE: Système d’Exploitation JVM: Java Virtual Machine LCD: Liquid Crystal Display IEEE: Institue of Electrical and Electronics Engineers MIME: Multipurpose Internet Mail Extensions RAM: Random Access Memory USB: Universal Serial Bus JTAG: Joint Test Action Group IPTV: Internet Protocol Television OpenGL: Open Graphics Library XML : eXtensible Markup Language Wi-fi: WIreless FIdelity

Page 65

Android MPEG DASH Player Annexe A : Structure d’un fichier MPD

Figure 35 Structure d'un fichier MPD L

Page 66

Android MPEG DASH Player Le tableau 8 suivant présentera une liste exhaustive des différents composants d’un fichier MPD (figure 35) ainsi que leurs rôles Elément MPD

@id @type

Location Baseurl

Period Representation @bandwidth SegmentBase @codecs SegmentList @qualityRanking

mimeType

AdaptationSet

Range

Description C’est l'élément racine d’un fichier MPD et il contient la description d’une présentation multimédia. L’élément identifiant d’une description de média indique si le MPD peut être ou non mis à jour. Cet attribut peut prendre les valeurs suivantes : (@ type = "dynamic") ou (@ type = "static"). Les fichiers MPD statiques sont généralement utilisés pour les services de streaming à la demande. les fichiers MPD dynamiques sont utilisés pour les services de streaming en direct. spécifie un emplacement dans lequel le MPD est disponible spécifie une URL de base qui peut être utilisée pour la résolution de référence et pour la sélection des URL alternatives lors du passage d’un segment à un autre. spécifie les informations d'une période. Elément contenant la description d’une représentation. Spécifie la bande passante minimale pour passer à un niveau de qualité. Spécifie la base de segment par défaut. Spécifie les codecs présents au sein de la « Representation ». Indique les informations sur la liste des segments indique un classement de la qualité d’une « Representation » par rapport à la qualité des autres « Representation » dans le même ensemble d'adaptation. spécifie le type MIME de la concaténation du segment d'initialisation, s'il est présent.Alors on déduit que tous les segments du MPD sont consécutifs. C’est un ensemble englobant plusieurs représentations d’un contenu multimédia codé en plusieurs versions interchangeables spécifie la période de temps pendant laquelle le DASH collection de métrologie est Page 67

Android MPEG DASH Player

@duration SegmentURL

demandé. Quand il n'est pas présent, DASH collection de métrologie est demandé pour toute la durée du contenu Cet élément, s’il existe, il indique la durée approximative constante des segments. spécifie l'URL d'un segment

Tableau 8 Analyse de la structure d'un fichier MPD

Page 68

Android MPEG DASH Player Annexe B : Architecture du système d’exploitation Android La figure 36 illustre les principaux composants du système d’exploitation Android. De première vue, on peut remarquer que l’architecture du SE Android est organisée en cinq couches : 

La couche Applications



La couche Framework



La couche Android Runtime



La couche Librairies(Bibliothèques)



La couche Noyau Linux

Figure 36 Architecture du système d'exploitation Android

La couche Applications

Figure 37 La couche Application de l'architecture du SE Android

Chaque version d’Android est fournie avec un ensemble d’applications basiques (figure 37) comme le client email, l’application d’envois et de réception de SMS, le calendrier, le service de cartographie, un navigateur… .Toutes ces applications sont écrites à l’aide du langage de programmation JAVA. L’ensemble de ces applications constitue la couche Applications, Page 69

Android MPEG DASH Player couche supérieure de l’architecture du système Android. Généralement, un utilisateur débutant de l'appareil Android ne pourrait être capable d’interagir qu’avec cette couche et à travers les fonctions basiques (faire des appels téléphoniques, utilisation du navigateur Web, …etc.). Par contre, les couches plus basses de l’architecture du SE Android sont accessibles principalement par les développeurs. La couche Framework

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

Cette couche(figure 38) fournit les classes requises pour développer une application Android tout en faisant abstraction de la nature du matériel utilisé. Les principaux composants de la couche Framework sont les classes suivantes :     

ActivityManager: cette entité gère le cycle de vie de l'activité des applications. Content Providers ou Fournisseurs de contenu: permet de gérer le partage des données entre les applications. Telephony Manager: cette classe est utilisée pour pouvoir accéder aux appels vocaux dans une application. Location Manager: permet la gestion des emplacements, en utilisant le GPS ou BTS de téléphonie cellulaire. Resource Manager: gère les différents types de ressources

Les applications Android interagissent directement avec les classes précitées. Ces applications permettent de gérer les fonctions de base d’un téléphone Android comme la gestion des ressources, la gestion des appels vocaux, etc. La Couche des Libraries

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

Page 70

Android MPEG DASH Player La troisième couche de l’architecture est la couche des librairies. Cette couche (figure38) est composée par un ensemble de librairies C / C++ utilisées par les différents composants du système Android. Ces librairies natives sont open source et permettent de guider le dispositif Android dans le traitement des différents types de données. Par exemple, la lecture et l'enregistrement de divers formats audio et vidéo sont guidés par la bibliothèque de Media Framework Les librairies suivantes peuvent être citées à titre d’exemple :         

Surface Manager: responsable de l’affichage de fenêtre sur l’écran SGL: bibliothèque graphique gérant les dessins 2d sur Android Open GL|ES: bibliothèque graphique gérant les dessins 3d sur Android Media Framework: Ensemble de Bibliothèques gérant la lecture et l’enregistrement de diffèrent formats audio et vidéos. Free Type: librairie gérant les différents formats d’écriture WebKit: Moteur de navigateur web libc (libraire C du système) SQLite : librairie de gestion de Base donnée locale sur Android Open SSL : librairie implémentant les protocoles SSL(Secure Sockets Layer) et TLS (Transport Layer Security) .

La couche Android Runtime

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

Comme l’indique la figure 40, la couche Android Runtime se compose de deux éléments : les « Core Libraries » et la Dalvik Virtual Machine. Core Libraries Android inclut un ensemble de librairies de base offrant la plupart des fonctions disponibles dans les bibliothèques de base du langage de programmation Java, telles que les « java.sql, java.nio » et aussi d’autre librairies qui ont été ajoutées comme « org.apache.commons.codec », « org.apache.commons.httpclient » et « org.bluez » . La Dalvik virtual Machine Dalvik est le nom de la machine virtuelle open source dans laquelle les applications Android sont exécutés. Les programmes destinés à la plateforme Android sont communément écrits à l’aide du langage Java puis compilés en Bytecode. Les fichiers .class sont ensuite convertis en .dex (Dalvik Executable) avant l'installation sur le terminal d’exécution. Le format « .dex » est le type de fichiers exécutables propre à Android. Le principal apport de ce format est sa gestion de mémoire optimisée. Page 71

Android MPEG DASH Player La couche noyau Linux Android utilise un noyau linux avec des différents patches pour la gestion de l'alimentation, le partage mémoire, etc. permettant une meilleure gestion de ces caractéristiques pour les appareils mobiles. Il permet le partage de librairies entre différents processus, le chargement et le déchargement de modules à chaud.

La liste des différents noyaux linux utilisés par Android est la suivante : Version Android

Version du noyau Linux

1.0

2.6.25

1.5 (Cupcake)

2.6.27

1.6 (Donut)

2.6.29

2.2(Froyo)

2.6.32

2.3 (GingerBread)

2.6.35

3.0 (HoneyComb)

2.6.36

4.0.x (Ice Cream Sandwitch)

3.0.1

4.1/4.2 (Jely Bean)

3.0.31 Tableau 9 Les noyaux linux utilisés par Android

Page 72

Android MPEG DASH Player

Annexe C:Procédure de mise en place de l’environnement Android sur la carte TI AM335xevm

L’objectif de cet annexe est d’illustrer les phases nécessaires afin de mettre en place l’environnement Android ICS du kit de développement spécifique aux plateformes TI AM335x. Tout d’abord il y a lieu d’installer les paquets nécessaires à l’ordinateur accueillant pour qu’il puisse supporter l’environnement de développement .Ces paquets sont le git-Core ,libsdl, zlib ,curl et la JRE6( java Runtime environment) de Sun.

Ensuite il serait nécessaire de télécharger et d’installer l’outil Repo qui est un outil permettant la synchronisation de fichiers distants et locaux.

Téléchargement de l’outil Repo

L’étape suivante est celle du téléchargement du code source Android ICS A cet effet, nous devons créer au préalable un répertoire nommé « rowboat-android » qui va contenir l’image synchrone des sources Android.

Il est à noter que cette étape peut durer de plusieurs heures voire même quelques jours selon le débit de la connexion internet utilisée.

Page 73

Android MPEG DASH Player Une fois le code source Android est téléchargé, on passe à la phase de préparation des binaires nécessaires pour installer le SE Android sur la carte TI AM335x evm. Ainsi, il faut tout d’abord compiler le Bootloader

L’étape suivante est la compilation du noyau linux de l’environnement Android déjà téléchargé

A ce niveau on doit procéder à la construction et à la génération du système de fichiers correspondant à l’environnement Android de la carte TI AM335x evm

Enfin, on doit préparer une carte mémoire de type SD bootable Android avec l’image Android et les binaires génères lors des précédentes phases.

Page 74