Vous êtes sur la page 1sur 75

Réf :

Université de Sousse

AU : 2012-2013

Réf : Université de Sousse AU : 2012-2013 Ecole Nation ale d’Ing énieurs de Sousse Mémoire

Ecole Nationale d’Ingénieurs de Sousse

AU : 2012-2013 Ecole Nation ale d’Ing énieurs de Sousse Mémoire de Projet de Fin d'Études

Mémoire de Projet de Fin d'Études

Présenté en vue de lobtention 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

Android MPEG DASH Player Résumé Au cours des dernières années, l’ Internet est devenu un canal

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é

la meilleure qualité possible. Mots-clés: Streaming, MPEG DASH, Android, multimédia, HTTP, Adaptivité, Qualité Page 1
la meilleure qualité possible. Mots-clés: Streaming, MPEG DASH, Android, multimédia, HTTP, Adaptivité, Qualité Page 1

Android MPEG DASH Player

Android MPEG DASH Player Abstract In recent years, the Internet has become an important channel for

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

streaming to obtain the best possible quality. Keywords: Streaming MPEG DASH, Adaptivity, multimedia, HTTP, Quality Page
streaming to obtain the best possible quality. Keywords: Streaming MPEG DASH, Adaptivity, multimedia, HTTP, Quality Page

Android MPEG DASH Player

Android MPEG DASH Player صخلم ربع لولأا ماقملا يف طئاسولا ةددعتم تانايبلا

صخلم

ربع لولأا ماقملا يف طئاسولا ةددعتم تانايبلا عيزوتل ةليسو مهأ تنرتنلإا ةكبش تحبصأ، ةريخلأا تاونسلا للاخ

ةيلاع ةدوج نامض عم لصاوتمو سلس قفدت قيقحتل

.«HTTP » لوكوتوربلا

«HTTP » لوكوتوربلا ىلع ةيكذ تلاوكوتورب ةدع تدنتسا

.«MPEG DASH » شاد قبم لوكوتوربلا ركذن اهنيب نم تانايبل ا ضرع ةيعون يف

تانلت ةيسنوتلا ةسسؤملا تكردأ

ثبل شاد قبم لامعتسا نم نكمي قيبطت ريوطت و جاتنا تررقف. شاد قبم لوكوتوربلا لامعتسلا رهازلا لبقتسملا و ةماهلا .تانايبلا

تافاضلاا يملعلا ثحبلا و راكتبلاا و ايجولونكتلا تلااجم يف ةدئار ةسسؤم اهتفصب

ةزهجأ ىلع شاد قبم لوكوتوربلا ربع ةقفدتم ويديف ةطرشلأ ةلصاوتم و ةسلس ةدهاشم نم نكمي هزاجنا عمزملا قيبطتلا .ديوردنأ ليغشت ماظن تاذ ةيكذلا فتاوهلا .ثبلل ةنكمم ةدوج لضفأ ىلع لوصحلا نم نكمت ةيمزراوخ ىلع ىوتحي قيبطتلا اذه

شاد قبم, ةددعتملا طئاسولا, ةدوج ,قفدت , ديوردنأ : حيتافم

اذه شاد قبم , ةددعتملا طئاسولا , ةدوج , قفدت , ديوردنأ : حيتافم Page 3
اذه شاد قبم , ةددعتملا طئاسولا , ةدوج , قفدت , ديوردنأ : حيتافم Page 3

Android MPEG DASH Player

Android MPEG DASH Player Remerciements Nous souhaitons que cette page du présent document puisse exprimer tous

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 dispo- nibilité, 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.

forts remerciements à tous les membres du jury qui ont bien voulu accepter d’évaluer notre modeste
forts remerciements à tous les membres du jury qui ont bien voulu accepter d’évaluer notre modeste

Android MPEG DASH Player

Android MPEG DASH Player Table des matières Introduction Générale 10 Chapitre 1 : Présentation et contexte

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

Fonctionnels 35 4.2.2 Besoins non fonctionnels 35 4.3 Diagramme des cas d’utilisation 35 Page 5
Fonctionnels 35 4.2.2 Besoins non fonctionnels 35 4.3 Diagramme des cas d’utilisation 35 Page 5

Android MPEG DASH Player

Android MPEG DASH Player 4.3.1 Identification des acteurs 35 4.3.2 Liste des cas d’utilisation 35

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

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

Android MPEG DASH Player

Android MPEG DASH Player Liste des tableaux Tableau 1 Description du cas d'utilisation Arrêter le streaming

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

8 Analyse de la structure d'un fichier MPD 68 Tableau 9 Les noyaux linux utilisés par
8 Analyse de la structure d'un fichier MPD 68 Tableau 9 Les noyaux linux utilisés par

Android MPEG DASH Player

Android MPEG DASH Player Liste des figures Figure 1 Trafic Internet envisagé pour les prochaines années

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

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

22

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

25

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

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 27 Couche librairies de l'architecture du système Android généré

50

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

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

d'exploitation Android 69 Figure 37 La couche Application de l'architecture du SE Android 69 Page 8
d'exploitation Android 69 Figure 37 La couche Application de l'architecture du SE Android 69 Page 8

Android MPEG DASH Player

Android MPEG DASH Player Figure 38 La couche Framework de l'architecture du SE Android 70 Figure

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

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

Android MPEG DASH Player

Android MPEG DASH Player Introduction Générale Aujourd’hui, le streaming est une technologie très populaire par

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).

trafic total du réseau en 2015 et 67.5% du trafic en 2017). Figure 1 Trafic Internet

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.

Comme le montre la figure 2, le trafic vidéo va croître de façon exponentielle dans les
Comme le montre la figure 2, le trafic vidéo va croître de façon exponentielle dans les

Android MPEG DASH Player

Android MPEG DASH Player Figure 2 Estimation du type de trafic internet des Smartphones triée par
Android MPEG DASH Player Figure 2 Estimation du type de trafic internet des Smartphones triée par

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 à

détaillées. Dans le quatrième chapitre, nous présenterons les études faites lors de la phase consacrée à
détaillées. Dans le quatrième chapitre, nous présenterons les études faites lors de la phase consacrée à

Android MPEG DASH Player

Android MPEG DASH Player l’analyse et la spécification des besoins. Le cinquième chapitre contiendra la description

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.

les perspectives suscitées par notre travail ainsi que les améliorations qui peuvent lui être apportées. Page
les perspectives suscitées par notre travail ainsi que les améliorations qui peuvent lui être apportées. Page

Android MPEG DASH Player

Android MPEG DASH Player Chapitre 1 : Présentation et contexte du projet Introduction Dans ce chapitre,

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

objectifs. 1.1 Présentation de l’organisme d’accuei l Figure 3 Logo de TELNET [Net 2] TELNET HOLDING(le

Figure 3 Logo de TELNET [Net 2]

TELNET HOLDING(le logo de TELNET est représenté dans la figure 3) est un groupe com- posé 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 ga- ranti 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.

entre les deux parties dans les domaines de l’aéronautique, de la sécurité et des cartes à
entre les deux parties dans les domaines de l’aéronautique, de la sécurité et des cartes à

Android MPEG DASH Player

Android MPEG DASH Player  Deux ans après ce premier accord, les deux groupes Altran (groupe

Deux ans après ce premier accord, les deux groupes Altran (groupe Français) et TEL- NET 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 tech- nologies 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 confidentia- lité 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.

représentent des activités importantes et pour leur bonne gestion, Telnet leur a consacré des départements. Page
représentent des activités importantes et pour leur bonne gestion, Telnet leur a consacré des départements. Page

Android MPEG DASH Player

Android MPEG DASH Player 1.1.3. Organigramme de TELNET Les départements sont organisés de la manière présentée

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
Conseil D’administration

Direction Administrative et financière

Direction Administrative et financière D i r e c t i o n G é n

Direction Générale

Figure 4 Organigramme de TELNET

Direction Marketing & Télécom

Page 15

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 ain- si 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 con- ception 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écom- munications, 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éveloppe- ment 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 logi- ciels embarqués (commutateurs, routeurs, compteurs électroniques).

: où s’effectue le développement des log i- ciels embarqués (commutateurs, routeurs, compteurs électroniques).
: où s’effectue le développement des log i- ciels embarqués (commutateurs, routeurs, compteurs électroniques).
Département Systèmes Electroniques Département Études Logicielles Département Réseaux et Télécoms Automobil
Département Systèmes
Electroniques
Département Études
Logicielles
Département Réseaux et
Télécoms
Automobil
Multimédia
Monétique
& carte à
puce
Défense &
Système
Industrie
Télécom
Sécurité
e
Avionique
d’information

Android MPEG DASH Player

Android MPEG DASH Player N ous avons eu l’occasion de réaliser notre projet de fin d’étude

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.

actuelles. Les techniques adaptatives les plus populaires seront présentées dans le prochain chapitre. Page 16
actuelles. Les techniques adaptatives les plus populaires seront présentées dans le prochain chapitre. Page 16

Android MPEG DASH Player

Android MPEG DASH Player Figure 5 Schéma simplifié du streaming adaptatif [Net3] Plusieurs systèmes d'exploitation
Android MPEG DASH Player Figure 5 Schéma simplifié du streaming adaptatif [Net3] Plusieurs systèmes d'exploitation

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

Les ventes mondiales de smartphones classés par système d'exploitation en Mai 2011

 

Android    Android 36%

 

Android 36%  Android  

56,9%

 

Symbian 8,5%

%

Symbian 8,5 % Symbian

SymbianSymbian 8,5 %

27,4% Autre 3,3%

27,4%

Autre 3,3%27,4%

Autre 10,2 %  Symbian 8,5 % Symbian 27,4% Autre 3,3% Windows phone 1,9% Windows Phone 3,6 % iOs

Windows phone 1,9%Windows Phone 3,6 %

Windows Phone 3,6 %Windows phone 1,9%

iOs 16,8%27,4% Autre 3,3% Autre 10,2 % Windows phone 1,9% Windows Phone 3,6 %   iOS 22,5

 

iOS 22,5 %    RIM 12,9%

 

RIM 12,9%  iOS 22,5 %  

% iOs 16,8%   iOS 22,5 %   RIM 12,9% Le système d’exploitation Android est devenu

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

du marché des Smartphones Figure 6 Les ventes mondiales de Smartphones triées par système d’exploitation Page
du marché des Smartphones Figure 6 Les ventes mondiales de Smartphones triées par système d’exploitation Page

Android MPEG DASH Player

Android MPEG DASH Player A l'heure actuelle, il existe peu de services de streaming adaptatif pour

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.

être définis facilement et clairement afin de pouvoir comparer efficacement les mécanismes d'adaptation. Page 18
être définis facilement et clairement afin de pouvoir comparer efficacement les mécanismes d'adaptation. Page 18

Android MPEG DASH Player

Android MPEG DASH Player - La proposition et l'évaluation des différents mécanismes d'adaptation du côté du

- 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.

d’exploitation Android. Dans le chapitre suivant, nous présenterons l’état de l’art du streaming . Page 19
d’exploitation Android. Dans le chapitre suivant, nous présenterons l’état de l’art du streaming . Page 19

Android MPEG DASH Player

Android MPEG DASH Player Chapitre 2 : Etat de l’art d u Streaming Introduction Notre sujet

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).

Protocol (MEGACO), le contrôle d'appel Skinny Protocol (SCCP), ou le Session Initiation Protocol (SIP). Page 20
Protocol (MEGACO), le contrôle d'appel Skinny Protocol (SCCP), ou le Session Initiation Protocol (SIP). Page 20

Android MPEG DASH Player

Android MPEG DASH Player RTP ne fournit pas un mécanisme pour assurer la livraison en temps

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

nécessite que le codeur (l’encodeur) fournisse une vidéo à des débits multiples (ou plusieurs encodeurs Page
nécessite que le codeur (l’encodeur) fournisse une vidéo à des débits multiples (ou plusieurs encodeurs Page

Android MPEG DASH Player

Android MPEG DASH Player peuvent être utilisés). En conséquence, les utilisateurs auront la meilleure qualité de

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

Paramètres d’encodage

+
+
Streaming Adaptatif
Streaming
Adaptatif

Contenu Brut

Transcodeur

Contrôleur Paramètres d’encodage + Streaming Adaptatif Contenu Brut Transcodeur

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.

de formats de CODEC évolutives. Un schéma de principe de cette technique est représenté dans la
de formats de CODEC évolutives. Un schéma de principe de cette technique est représenté dans la

Android MPEG DASH Player

Android MPEG DASH Player Contrôleur Paramètres d’encodage Streaming Adaptatif + Contenu Brut

Contrôleur

Paramètres d’encodage

Streaming Adaptatif
Streaming
Adaptatif
+
+

Contenu Brut

Contenu Brut Encodeur évolutif Vidéo évolutive

Encodeur évolutif

Contenu Brut Encodeur évolutif Vidéo évolutive

Vidéo évolutive

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.

des niveaux différents pour assurer une lecture continue. Figure 9 Approche du Stream switching pour le

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

pour assurer une lecture continue. Figure 9 Approche du Stream switching pour le streaming adaptatif [Net3]
pour assurer une lecture continue. Figure 9 Approche du Stream switching pour le streaming adaptatif [Net3]

Android MPEG DASH Player

Android MPEG DASH Player L'objectif principal de cette méthode est de minimiser les coûts de traitement,

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).

chaque segment a été totalement joué (non partiellement). Figure 10 Exemple illustrant la commutation de Stream

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

ou inférieur. Un exemple de base est représenté sur la figure 11, où le dispositif de
ou inférieur. Un exemple de base est représenté sur la figure 11, où le dispositif de

Android MPEG DASH Player

Android MPEG DASH Player représente la logique de commutation appliquée sur le côté client. Les flèches

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 Envoie du Manifest fichier Manifest Analysé GET
GET :Manifest
Lance la
lecture
200 OK
Fichier
Envoie du
Manifest
fichier Manifest
Analysé
GET :segment 1:level 1
Adaptation
200 OK
Envoie segment 1
avec la qualité 1
GET :segment i:level k
Demande
200 OK
segment i
Envoie segment i
avec la qualité k
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

RTP qui nécessitent des ports ouverts dans le pare-feu ou nécessitent l'utilisation d'une passerelle de Page
RTP qui nécessitent des ports ouverts dans le pare-feu ou nécessitent l'utilisation d'une passerelle de Page

Android MPEG DASH Player

Android MPEG DASH Player couche application). Initialement, les utilisateurs téléchargent une playlist M3U étendu qui

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é.

ont l’ajout du support à la plateform e Android est l’objectif essentiel de notre projet, sera
ont l’ajout du support à la plateform e Android est l’objectif essentiel de notre projet, sera

Android MPEG DASH Player

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

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 Phase de Phase de d’exploration réalisation normalisation Juillet 2009
3.1.2 Chronologie de développement
Phase
Phase de
Phase de
d’exploration
réalisation
normalisation
Juillet 2009
Avril 2010
Janvier 2011
Novembre 2011

Figure 12 Chronologie du développement du standard MPEG DASH

2009 Avril 2010 Janvier 2011 Novembre 2011 Figure 12 Chronologie du développement du standard MPEG DASH
2009 Avril 2010 Janvier 2011 Novembre 2011 Figure 12 Chronologie du développement du standard MPEG DASH

Android MPEG DASH Player

Android MPEG DASH Player La technologie MPEG-DASH a été développée par le groupe MPEG (groupe spécialisé

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).

figure 14) qui contient toute la structure d'une présentation multimédia exposée ci-dessous (figure 13). Page 28
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

Android MPEG DASH Player Figure 13 Schéma d'illustration du contenu d'un fichier MPD Figure 14 Exemple
Android MPEG DASH Player Figure 13 Schéma d'illustration du contenu d'un fichier MPD Figure 14 Exemple

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

Schéma d'illustration du contenu d'un fichier MPD Figure 14 Exemple d'un fichier MPD Le protocole MPEG

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

du MPD, le format de segments, et le protocole de livraison (HTTP). Heureusement, il permet des
du MPD, le format de segments, et le protocole de livraison (HTTP). Heureusement, il permet des

Android MPEG DASH Player

Android MPEG DASH Player flexibles pour mettre en œuvre différents types de services de streaming. Les

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.

et d'autres paramètres déterminés par le client. Figure 15 Communication client-serveur dans le cadre du

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.

le long d’ une période, changements en fonction de la variation de la bande passante disponible.
le long d’ une période, changements en fonction de la variation de la bande passante disponible.

Android MPEG DASH Player

Android MPEG DASH Player Figure 16 Illustration du changement de la qualité des segments téléchargés selon
Android MPEG DASH Player Figure 16 Illustration du changement de la qualité des segments téléchargés selon

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).

librairies soit des plugins offrant la capacité de supporter le protocole MPEG DASH (Libdash et gstdashdemux).
librairies soit des plugins offrant la capacité de supporter le protocole MPEG DASH (Libdash et gstdashdemux).

Android MPEG DASH Player

Android MPEG DASH Player 3.2.1 Helix DNA Client Helix DNA Client pour Android fournit un HLS,

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

sur une architecture modulaire composée d'un cœur (GStreamer) et de plugins (Base, Good,Ugly, Bad). Pour Page
sur une architecture modulaire composée d'un cœur (GStreamer) et de plugins (Base, Good,Ugly, Bad). Pour Page

Android MPEG DASH Player

Android MPEG DASH Player faciliter les usages commerciaux de GStreamer, Fluendo et Collabora ont œuvré ensemble

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.

le chapitre suivant nous allons entamer l’étape d’analyse et spécification des besoins de notre système. Page
le chapitre suivant nous allons entamer l’étape d’analyse et spécification des besoins de notre système. Page

Android MPEG DASH Player

Android MPEG DASH Player Chapitre 4 Analyse et spécification des besoins Introduction L’analyse des besoins est

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.

de service de streaming provenant du serveur MPEG DASH. Figure 17 Architecture d'un système de streaming

Figure 17 Architecture d'un système de streaming MPEG-DASH

Dans le cadre de notre projet la tâche sera essentiellement cliente (Smartphone de la figure 17).

la réalisation

de l’application

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

Android MPEG DASH Player

Android MPEG DASH Player 4.2 Expression des besoins Avant de réaliser le diagramme de cas d’utilisation

4.2 Expression des besoins

Avant de réaliser le diagramme de cas d’utilisation il est nécessaire de classer les différents besoins de notre système selon leurs natures.

4.2.1 Besoins Fonctionnels

déterminer et de

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 :

l’utilisateur d’un Smartphone et notre application on peut prévoir les cas d’utilisation suivants : Page 35
l’utilisateur d’un Smartphone et notre application on peut prévoir les cas d’utilisation suivants : Page 35

Android MPEG DASH Player

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

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.

du système sera ainsi modélisé à l’aide de ce diagramme. Figure 18 Diagramme de cas d'utilisation

Figure 18 Diagramme de cas d'utilisation global

du système sera ainsi modélisé à l’aide de ce diagramme. Figure 18 Diagramme de cas d'utilisation
du système sera ainsi modélisé à l’aide de ce diagramme. Figure 18 Diagramme de cas d'utilisation

Android MPEG DASH Player

Android MPEG DASH Player 4.4 Description des cas d’utilisation Une fois la modélisation des différents cas

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

«

Arrêter le streaming »

But

Arrêter la visualisation d’une vidéo quelconque en cours de lecture

Résumé

L’utilisateur choisit d’arrêter le streaming de la vidéo en cours de lecture

Acteurs

Utilisateur du Smartphone

Pré conditions

Une vidéo en cours de lecture

Besoin d’IHM

Bouton permettant l’arrêt du streaming

Exigences non fonctionnelles

 

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

Cas d’utilisation

Titre

«

Passer en mode d’adaptation automatique »

But

Obtenir la meilleure qualité d’affichage d’une façon automatique

Résumé

L’utilisateur

choisit

l’option

d’adaptation

automatique

Acteurs

Utilisateur du Smartphone

 

Pré conditions

Mode d’adaptation manuel en cours

Besoin d’IHM

Menu de sélection du mode d’adaptation

Exigences non fonctionnelles

Le passage doit se faire instantanément

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

Cas d’utilisation

Titre

«

Visualiser une vidéo en mode plein écran »

But

Visualiser une vidéo en mode plein écran

Résumé

L’utilisateur choisit l’option de visualisation en mode plein écran

Acteurs

Utilisateur du Smartphone

Pré conditions

une vidéo en cours de lecture

Besoin d’IHM

Bouton permettant le passage en mode plein écran

Exigences non fonctionnelles

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

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

Android MPEG DASH Player

Android MPEG DASH Player Cas d’ut ilisation Titre « Passer à une supérieure/inférieure résolution vidéo »

Cas d’utilisation

Titre

« Passer à une supérieure/inférieure résolution vidéo »

But

Obtenir une qualité meilleure /inférieur de la vidéo

Résumé

L’utilisateur choisit à un instant donné de passer à une qualité meilleure/inférieure

Acteurs

Utilisateur du Smartphone

Pré conditions

Vidéo en cours de streaming à un niveau de qualité affiché sur l’écran

Besoin d’IHM

2 boutons pour permettre le passage à d’autre niveau de qualité ainsi qu’un champ pour afficher le niveau de résolution actuel

Exigences non fonctionnelles

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 dintercommunications 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 ci- aprè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.

en mode d’adaptation manuel afin de pouvoir finalement améliorer la qualité d’affichage manuellement. Page 38
en mode d’adaptation manuel afin de pouvoir finalement améliorer la qualité d’affichage manuellement. Page 38

Android MPEG DASH Player

Android MPEG DASH Player Figure 19 Diagramme de séquence d'un scénario d'utilisation du MPEG DASH Player
Android MPEG DASH Player Figure 19 Diagramme de séquence d'un scénario d'utilisation du 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.

diagramme de séquence. Dans le chapitre suivant nous allons entamer l’ étape de conception de notre
diagramme de séquence. Dans le chapitre suivant nous allons entamer l’ étape de conception de notre

Android MPEG DASH Player

Android MPEG DASH Player Chapitre 5 La phase Conception du Android MPEG DASH Player Introduction Nous

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).

qui utilise Libdash et plus précisément à la partie de contrôle du streaming (Dash Streaming Control).
qui utilise Libdash et plus précisément à la partie de contrôle du streaming (Dash Streaming Control).

Android MPEG DASH Player

Android MPEG DASH Player Figure 20 Architecture globale du système de streaming en utilisant Libdash[Net5] La
Android MPEG DASH Player Figure 20 Architecture globale du système de streaming en utilisant Libdash[Net5] La

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.

le contrôle sur la qualité et l’ordre de téléchargement des segments après analyse du fichier MPD.
le contrôle sur la qualité et l’ordre de téléchargement des segments après analyse du fichier MPD.

Android MPEG DASH Player

Android MPEG DASH Player 5.2 Conception détaillée Après avoir exposé l’architecture globale de notre système ,

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

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.

Pour commencer, nous exposerons le diagramme de déploiement

Pour commencer, nous exposerons le diagramme de déploiement Figure 21 Diagramme de déploiement du système D’après

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.

dans notre système. Il est à noter que la communication entre ces deux nœuds se fait
dans notre système. Il est à noter que la communication entre ces deux nœuds se fait

Android MPEG DASH Player

Android MPEG DASH Player 5.2.2 Architecture Logique Media Player Librairies de Couche d’accès aux flux Librairies

5.2.2 Architecture Logique

Media Player

Media Player Librairies de Couche d’accès aux flux Librairies décodage graphiques Flux Audio & vidéo brut
Librairies de Couche d’accès aux flux Librairies décodage graphiques Flux Audio & vidéo brut
Librairies de
Couche d’accès aux flux
Librairies
décodage
graphiques
Flux Audio & vidéo brut

Dash Streaming Control : Dash Player

API de manipulation du fichier MPD
API de manipulation du
fichier MPD

Libdash

Produire un flux/fournir une API

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

Données échangé

Demander/accepter un flux

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

:  La librairie Libdash  Le Dash Streaming Control  La Couche d’accès aux flux.
:  La librairie Libdash  Le Dash Streaming Control  La Couche d’accès aux flux.

Android MPEG DASH Player

Android MPEG DASH Player Après avoir exposé l’architecture logique globale de notre système nous passons à

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).

classes de la partie Dash Streaming Control (Dash Player). Figure 23 Diagramme de classe du DASH

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 :

des éléments MPD, DashManager, MediaObjectBuffer et AdaptationLogic. Le rôle de chacun de ces attributs est :
des éléments MPD, DashManager, MediaObjectBuffer et AdaptationLogic. Le rôle de chacun de ces attributs est :

Android MPEG DASH Player

Android MPEG DASH Player  Le MPD est la classe responsable de modéliser et gérer toutes

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.

LAdaptationLogic 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.

entité est la classe responsable de la construction de la surface nécessaire à la visualisation de
entité est la classe responsable de la construction de la surface nécessaire à la visualisation de

Android MPEG DASH Player

Android MPEG DASH Player Figure 24 Diagramme de classes du Android Media Player Conclusion Dans ce
Android MPEG DASH Player Figure 24 Diagramme de classes du Android Media Player Conclusion Dans ce

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.

suivant, nous allons mettre en application cette étude avec tous ses détails afin de pouvoir la
suivant, nous allons mettre en application cette étude avec tous ses détails afin de pouvoir la

Android MPEG DASH Player

Android MPEG DASH Player Chapitre 6 Réalisation de l’application Android MPEG DASH Player Introduction Après avoir

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'ap- plication, 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

Dell Inspiron N5010

Système d’exploitation

Ubuntu 10.04 32 bits

Processeur

Intel i5 430M (2.67 GHz/3MB Cache)

RAM

4GB DDR3

Disque dur

500 GB SATA

Carte graphique

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.

la carte TI AM335x evm (figure 25) qui est une carte de développement conçue par la
la carte TI AM335x evm (figure 25) qui est une carte de développement conçue par la

Android MPEG DASH Player

Android MPEG DASH Player Figure 25 Carte d'essai TI AM335x evm [Net7] Les principales Caractéristiques techniques
Android MPEG DASH Player Figure 25 Carte d'essai TI AM335x evm [Net7] Les principales Caractéristiques techniques

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

Les principales Caractéristiques techniques de la carte TI am335xevm sont :

Processeur

AM335 A8 ARM Microprocessor

Ram

512MB DDR2

Système d’exploitation supportés

Linux EZ SDK Android

Alimentation

Gestionnaire d’alimentation TPS65910

Connectivité

WiFi/BT) via WL1271

Affichage

Ecran tactile LCD 7 pouces

Ports

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.

et l'enregistrement de divers formats audio et vidéo sont guidés par la bibliothèque de Media Framework.
et l'enregistrement de divers formats audio et vidéo sont guidés par la bibliothèque de Media Framework.

Android MPEG DASH Player

Android MPEG DASH Player Parmi les deux solutions présentées lors du troisième chapitre, nous avons opté

Parmi les deux solutions présentées lors du troisième chapitre, nous avons opté pour la so- lution 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 Visualisation du flux
Compilation de la librairie Libdash Réalisation de la partie Dash Streaming Control Visualisation du flux

Compilation de la librairie Libdash

Réalisation de la partie Dash Streaming ControlCompilation de la librairie Libdash Visualisation du flux Réalisation de la couche accès aux flux

Libdash Réalisation de la partie Dash Streaming Control Visualisation du flux Réalisation de la couche accès
Libdash Réalisation de la partie Dash Streaming Control Visualisation du flux Réalisation de la couche accès
Visualisation du flux Réalisation de la couche accès aux flux

Visualisation du flux

Visualisation du flux Réalisation de la couche accès aux flux

Réalisation de la couche accès aux fluxVisualisation du flux

Visualisation du flux Réalisation de la couche accès aux flux

du flux Réalisation de la couche accès aux flux  Elaboration de la Logique d’adaptation Décodage
du flux Réalisation de la couche accès aux flux  Elaboration de la Logique d’adaptation Décodage

Elaboration de la Logique d’adaptation Logique d’adaptation

Décodage de fluxaux flux  Elaboration de la Logique d’adaptation Les différentes librairies précitées se distinguent par

Les différentes librairies précitées se distinguent par les caractéristiques suivantes:

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

pour l’environnement Android ICS de la carte TI AM335x Après analyse de l’architecture Android (voire Annexe

Après analyse de l’architecture Android (voire Annexe C), on peut constater que les librai- ries 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 croi- sée. Il fait référence au processus de compilation de source en utilisant des chaînes de compi- lation 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épen- dances 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).

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

open source de transfert de fichiers via URL côté client supportant les protocoles FTP, FTPS, HTTP
open source de transfert de fichiers via URL côté client supportant les protocoles FTP, FTPS, HTTP

Android MPEG DASH Player

Android MPEG DASH Player  libxml2 Libxml2 est un XML parser(analyseur de fichier xml) à base

libxml2

Libxml2 est un XML parser(analyseur de fichier xml) à base de langage

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é initiale- ment conçu pour être utilisé avec la bibliothèque d'images libpng qui est un logiciel libre, distribué sous la licence zlib.

C et

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 utili- ser 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 à lutilisation 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.

obtenu la couche librairie représentée par la figure 27. Figure 27 Couche librairies de l'architecture du

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

Android généré A ce stade, et comme la librairie Libdash ne fait que fournir une interface
Android généré A ce stade, et comme la librairie Libdash ne fait que fournir une interface

Android MPEG DASH Player

Android MPEG DASH Player différentes fonctionnalités d’analyse de fichier MPD et téléchargement de segments, Il

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 linté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

buffer de lecture permet de donner une idée sur l’état réel de la bande passante .
buffer de lecture permet de donner une idée sur l’état réel de la bande passante .

Android MPEG DASH Player

Android MPEG DASH Player que plus la bande passante est importante plus le Buffer se remplit

que plus la bande passante est importante plus le Buffer se remplit plus vite. En con- naissant 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 ca- pable de la supporter.

b- Structure du Buffer Selon les spécifications du

doit être effectuée selon une chaine continue d’intervalles de temps de durée égale (8 se- condes dans notre cas).A chaque intervalle on peut se retrouver dans les cas critiques sui-

protocole MPEG DASH la lecture de contenu multimédia

vants :

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 lec- ture 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

de la lecture de flux. Dans ce cas, on doit arrêter temporairement le remplissage du buffer
de la lecture de flux. Dans ce cas, on doit arrêter temporairement le remplissage du buffer

Android MPEG DASH Player

Android MPEG DASH Player l’espace de stockage nécessaire pour permettre les téléchargements ultérieurs de don-

l’espace de stockage nécessaire pour permettre les téléchargements ultérieurs de don- né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%) alors passer à la qualité la plus faible ; Sinon Si( l’état du buffer est >20% et l’état du Buffer est <80 %) alors si (vitesse lecture>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 lecture<vitesse_ecriture) alors Passer_a_la_qualité(qualité_actuelle+1) ; qualité_actuelle= qualité_actuelle+1 ; Fin si Fin si Sinon Si (l’état du buffer est >80%) alors Si (charge_CPU<90%) alors Passer_a_la_qualité(qualité_actuelle +1) ; sinon Passer_a_la_qualité(i-1) ; fin si

Fin si Fin Tant que Fin

En analysant l’algorithme précédent la structure du Buffer peut être modélisée par la figure suivante (figure 28)

5%

75%

20%

Le taux de remplissage du Buffer est insuffisant pour commencer la lecture

Choix de qualité du streaming selon la valeur du rapport vitesse de lecture du buffer/vitesse d’écriture dans le buffer

Choix de qualité du streaming selon la charge CPU actuelle

Figure 28 Modélisation de la structure du buffer de lecture

de qualité du streaming selon la charge CPU actuelle Figure 28 Modélisation de la structure du
de qualité du streaming selon la charge CPU actuelle Figure 28 Modélisation de la structure du

Android MPEG DASH Player

Android MPEG DASH Player 6.2.4 Phase de décodage A ce stade et grâce au Dash Streaming

6.2.4 Phase de décodage

A ce stade et grâce au Dash Streaming Control, on peut gérer le téléchargement d’un fichier MPD, son analyse, le téléchargement des différents segments selon la spécification de l’algorithme d’adaptation et enfin remplir le buffer de lecture. Mais le contenu du buffer reste inexploitable directement, ce flux doit passer par la phase de décodage.

Pour réaliser la tâche de décodage nous avons opté pour l’utilisation de l’outil FFMPEG.

FFMPEG est un ensemble de bibliothèques de lecture et d’encodage de vidéo. Très puissant comme son alter ego Mencoder, il assure en ligne de commande la possibilité de convertir les fichiers vidéo d'un format à un autre.

Une des librairies de FFMPEG qu’on a utilisé est « Libavformat ». La librairie Libavformat fournit un cadre générique pour le multiplexage et de démultiplexage des flux audio, vidéo et sous-titres. Elle englobe plusieurs multiplexeurs et démultiplexeurs pour les formats de conteneurs multimédias.

Elle prend également en charge plusieurs protocoles d'entrée et de sortie permettant d'accéder

à une ressource multimédia

.

Une deuxième librairie de FFMPEG a été utilisée et elle a pour nom « Libavutil » Libavutil est une librairie qui contient la définition des utilitaires communs au projet FFMPEG. Elle est indispensable au bon fonctionnement de toutes les autres librairies de FFMPEG.

Une autre librairie de FFMPEG a été utilisée et elle est nommée « Libavcodec »

Libavcodec est une bibliothèque libre écrite en langage C, développée dans le cadre du pro- jet FFmpeg. Elle permet de décoder et d'encoder de nombreux codecs audio et vidéo. Elle est distribuée sous licence GNU LGPL et elle est disponible sous Linux (Unix), Mac OS X et Windows.

La bibliothèque « Libavcodec » est indissociable de Libavformat et Libavutil.

Comme cette librairie(FFMPEG) ne fait pas partie des librairies natives d’Android, il s’est avéré nécessaire de la compiler pour la plateforme Android de la même façon que nous avons procédé lors de la compilation de Libdash.

6.2.5 Réalisation de la couche accès aux flux

Après avoir établi la logique d’adaptation et le décodage de flux multimédia au niveau natif (C++), nous voudrions maintenant que ces fonctions soient accessibles depuis le langage Java, outil de Base permettant la programmation des applications Android. Afin de pouvoir réaliser ce type d’appel nous avons eu recours au kit de développement natif de Google le Android NDK. Le Android NDK est un kit de développent fournissant un ensemble d'outils qui permettent de mettre en œuvre une application Android qui comporte des parties qui utilisent des lan- gages de code natif comme C et C + +.

une application Android qui comporte des parties qui utilisent des lan- gages de code natif comme
une application Android qui comporte des parties qui utilisent des lan- gages de code natif comme

Android MPEG DASH Player

Android MPEG DASH Player L’A ndroid NDK est un outil puissant pour concevoir une couche JNI

L’Android NDK est un outil puissant pour concevoir une couche JNI (Java Native Interface) d’une application.

La JNI est une technologie permettant l’appel de code de niveau natif(C/C++) à partir de code de haut niveau comme le langage Java. Cette technologie peut être très utile dans le cadre de développement d’application Android en effet elle permet d’assurer une meilleure performance.

C’est donc cette couche qui nous permettra d’accéder flux crées au niveau natif à partie du code Java. Pour mette en œuvre couche JNI nous sommes passés par les étapes suivantes :

La déclaration de différentes fonctions natives utilisées dans des classes Java.

La compilation de ces classes Java (PlayerUI et PlayerControl) à l’aide de l’outil javac de la JDK.

La génération du fichier d'en-tête avec l'outil javah.

L'écriture du code natif en utilisant entre autre les fichiers d'en-tête fournis par le JDK et ceux générés précédemment. Lors de cette étape nous avons effectué l’appel des différentes fonctions assurées par le Dash Streaming Control et celles de déco- dage(FFMPEG).

La compilation du code natif sous la forme d'une bibliothèque.

Pour réaliser cette interface nous avons respecté les différentes spécifications de l’Android NDK indiquant la correspondance entre type Java et type JNI et ainsi rendre l’appel des fonctions C++ possible à partir du langage Java.

6.2.6 Phase de visualisation

Une fois la phase de décodage de flux est achevée, la phase d’affichage de ce flux sur l’écran de la carte Ti am335xevm commence. Pour réaliser l’affichage les trois méthodes suivantes ont été envisagées:

Utiliser la librairie SDL(Simple DirectMedia Layer) :la compilation de SDL pour Android est nécessaire.

Utiliser les librairies OpenGL et les GLtextures

Utiliser Libjnigraphics

Les deux premières méthodes (SDL et OpenGL) n’ont pas été retenues car elles nécessitent une étape de conversion de couleur du format Yuv en RGB. Cette conversion est une opération très couteuse en mémoire et en charge CPU ce qui rend l’affichage de vidéo beaucoup moins fluide que celui avec utilisation de la librairie Libjnigraphics La troisième méthode ne nécessite pas l’étape de conversion précitée, ce qui la rend la plus rapide et la plus performante malgré la difficulté de sa mise en œuvre. Enfin et pour gagner en réutilisabilité du code de notre application et afin qu’elle soit utilisable de la même façon pour toute taille d’écran, nous avons opté pour l’utilisation des Fragments.

de la même façon pour toute taille d’écran, nous avons opté pour l’utilisation des Fragments. Page
de la même façon pour toute taille d’écran, nous avons opté pour l’utilisation des Fragments. Page

Android MPEG DASH Player

Android MPEG DASH Player 6.3 Tests et résultats expérimentaux Le résultat final obtenu après toutes les

6.3 Tests et résultats expérimentaux

Le résultat final obtenu après toutes les opérations exposées précédemment est :

Dès l’ouverture de l’application l’utilisateur sera en face d’un écran d’accueil provisoire qui s’affiche le temps nécessaire jusqu’à la construction entière des différents composants de l’application. L’écran d’accueil est représenté par la figure 29.

L’ é cran d’ accueil est représenté par la figure 29. Figure 29 Ecran d'attente L

Figure 29 Ecran d'attente

L’utilisateur aura tout de suite, à sa disposition la fenêtre principale de l’application Android MPEG DASH Player. La figure 30 représente le contenu de cette fenêtre.

Cette fenêtre est composée d’un ListFragment qui contient la liste des vidéos disponibles et un autre fragment pour l’affichage de la vidéo.

et un autre fragme nt pour l’affichage de la vidéo . Figure 30 Fenêtre principale de

Figure 30 Fenêtre principale de l'application Android MPEG-DASH Player

nt pour l’affichage de la vidéo . Figure 30 Fenêtre principale de l'application Android MPEG-DASH Player
nt pour l’affichage de la vidéo . Figure 30 Fenêtre principale de l'application Android MPEG-DASH Player

Android MPEG DASH Player

Android MPEG DASH Player L’utilisateur peut choisir entre consulter ou non consulter la liste des vidéos

L’utilisateur peut choisir entre consulter ou non consulter la liste des vidéos disponibles grâce à un bouton qui lance une animation de défilement de la liste des vidéos (figure31).

animation de défilement de la liste des vidéos (figure31). Figure 31 Vidéo en cours de lecture

Figure 31 Vidéo en cours de lecture avec playlist couverte

Aussi à chaque instant l’utilisateur a les informations concernant sa bande passante disponible, l’état du Buffer de lecture et le niveau de qualité d’affichage actuel. En analysant ces informations il peut choisir de passer manuellement à une qualité d’affichage qu’il souhaite (figure 31,32).

qualité d’affichage qu’il souhaite (figure 31,32). Figure 32 Illustrations des différentes fonctionnalités

Figure 32 Illustrations des différentes fonctionnalités disponibles pour le contrôle manuel de la qualité

Figure 32 Illustrations des différentes fonctionnalités disponibles pour le contrôle manuel de la qualité Page 57
Figure 32 Illustrations des différentes fonctionnalités disponibles pour le contrôle manuel de la qualité Page 57

Android MPEG DASH Player

Android MPEG DASH Player Faible Qualité d’affichage Passage à une meilleure Qualité Figure 33 Illustration du
Faible Qualité d’affichage Passage à une meilleure Qualité
Faible
Qualité
d’affichage
Passage
à une
meilleure
Qualité
Faible Qualité d’affichage Passage à une meilleure Qualité

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

Passage à une meilleure Qualité Figure 33 Illustration du changement de la qualité d'image automatique Page
Passage à une meilleure Qualité Figure 33 Illustration du changement de la qualité d'image automatique Page

Android MPEG DASH Player

Android MPEG DASH Player Enfin voici (figure 34) un exemple de passage d’une vidéo à une

Enfin voici (figure 34) un exemple de passage d’une vidéo à une autre

34) un exemple de passage d’une vidéo à une autre Figure 34 Illustration de passage d'une
34) un exemple de passage d’une vidéo à une autre Figure 34 Illustration de passage d'une

Figure 34 Illustration de passage d'une vidéo à une autre dans la playlist

Une émulation de l’algorithme de décision élaboré dans notre application est représentée par le tableau 7 suivant. Ce tableau contiendra les informations sur la décision prise par l’algorithme d’adaptation dans le temps en tenant compte des critères : état du Buffer de lecture, charge CPU et le Niveau de qualité actuel de l’affichage.

compte des critères : état du Buffer de lecture, charge CPU et le Niveau de qualité
compte des critères : état du Buffer de lecture, charge CPU et le Niveau de qualité

Android MPEG DASH Player

Android MPEG DASH Player Bande état du charge Niveau de Rapport largeur hauteur Décision

Bande

état

du

charge

Niveau de

Rapport

largeur

hauteur

Décision

passante

Buffer

de

CPU

qualité

vitesse

disponible

lecture

actuel

lecture/écriture

du Buffer

50Ko/s

7%

40%

1

>1

320

240

1

60

Ko/s

15%

42%

1

>1

320

240

1

65

Ko/s

26%

55%

1

<1

320

240

1

120

Ko/s

35%

60%

1

>1

320

240

2

200

Ko/s

41%

70%

2

=1

320

240

2

300

Ko/s

55%

78%

2

>1

480

360

3

280

Ko/s

66%

77%

3

=1

480

360

3

450

Ko/s

85 %

90%

3

<1

480

360

3

400

Ko/s

82%

92%

3

>1

320

240

2

320

Ko/s

75%

60%

2

=1

320

240

2

110

Ko/s

55%

63%

2

>1

320

240

2

45

Ko/s

32%

66%

2

>1

320

240

1

75

Ko/s

40%

70%

1

=1

320

240

1

90

Ko/s

50%

80%

1

=1

320

240

1

120

Ko/s

60%

75%

1

<1

320

240

1

115

Ko/s

68%

77%

1

>1

320

240

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