CAHIER DES CHARGES. VOD par HTML5. CHAPTAL Sébastien & OCCELLO Alexandre M1 Informatique Année universitaire 2011/2012 Semestre 1

Transcription

1 CAHIER DES CHARGES VOD par HTML5 CHAPTAL Sébastien & OCCELLO Alexandre M1 Informatique Année universitaire 2011/2012 Semestre 1

2 SOMMAIRE Sommaire... 2 Introduction... 3 Contexte général... 3 Présentation de l équipe... 3 Présentation du client... 3 Présentation du projet... 4 Expression du besoin... 4 Liste des fonctionnalités... 6 Réponse aux besoins... 8 Différents types d utilisateurs... 8 Cas d utilisations Réponse technique Présentation du streaming vidéo Technologies utilisées Organisation du projet Ressources utilisées Réunions Conclusion Références

3 INTRODUCTION Contexte général Dans le cadre du Master 1 Informatique, les étudiants du Centre d Enseignement et de Recherche en Informatique (CERI) d Avignon ont pour objectif de réaliser un projet se déroulant sur deux semestres consécutifs. Le premier semestre est consacré à la rédaction du cahier des charges ci-présent, qui comporte le résultat de l analyse effectuée ainsi qu une maquette correspondant à l application qui sera à développer lors du second semestre. Présentation de l équipe Notre équipe est composée de deux étudiants en M1 Informatique, Sébastien CHAPTAL et Alexandre OCCELLO, tous deux suivant une spécialisation en Ingénierie Logicielle. Nous sommes chargés de la réalisation du projet «VOD (Vidéo à la Demande) par HTML5». Notre tuteur, qui nous encadre lors de la réalisation de ce projet, est Maxime CHARPENNE, directeur technique à la Direction Opérationnelle des Systèmes d Information (DOSI) de l Université d Avignon et des Pays du Vaucluse (UAPV). Présentation du client Le client principal du projet que nous avons à réaliser est l Université d Avignon. Celle-ci comprend : Plus de 7000 étudiants (7125 pour l année universitaire 2009/2010), répartis en 10 Unités de Formation et de Recherche (UFR) ; 357 enseignants-chercheurs et enseignants ; Plus de 300 Ingénieurs, Administratifs, Techniciens et Ouvriers de Service (IATOS) et personnels de Bibliothèque. De plus, le parc informatique de l Université d Avignon est composé de plus de 1500 postes informatiques accessibles à chacun. Chaque membre de l Université est donc un potentiel client, directement ou indirectement, de l application que nous aurons à réaliser d ici la fin du second semestre. 3

4 PRESENTATION DU PROJET Expression du besoin L Université d Avignon utilise Internet depuis plusieurs années pour y publier des vidéos liées à différents thèmes : Cours en ligne ; Promotions de l Université ; Assemblées ; Forums ; Mises en avant de différents projets ou concours ; Etc. Cependant, l Université a eu tendance à disperser les vidéos qu elle publiait à travers plusieurs réseaux. En effet, même si elle dispose de son propre serveur qui contient certaines vidéos, l Université d Avignon communique essentiellement via des réseaux extérieurs, avec des sites tels que YouTube ou Dailymotion, sur lesquels nous pouvons trouver par exemple la série de clips «Choisir Avignon pour son Université» ou des vidéos de forums organisés en amphithéâtres. De plus, la DOSI souhaite remplacer son serveur Flash pour la gestion des vidéos hébergées sur le domaine de l Université d Avignon et désire utiliser les nouvelles technologies Web existantes. La volonté d'utiliser son propre serveur et de le moderniser présenterait ainsi un certain nombre d avantages pour l Université. Cela lui permettrait d abord de centraliser tous les contenus vidéo publiés en un seul espace accessible facilement pour tous les utilisateurs, mais cela lui donnerait également et surtout la possibilité de personnaliser la gestion de ses vidéos à sa convenance, grâce à un système évolutif. En outre, l emploi de nouvelles technologies lui permettraient de s assurer un avenir sur le long terme, les grandes entreprises de diffusion de vidéos évoluant elles aussi dans ce sens. C est pourquoi notre mission sera de développer une nouvelle interface de gestion de vidéos permettant à l Université d Avignon d obtenir un système à la fois suffisamment fiable et durable pour lui permettre de s affranchir d applications extérieures. Celle-ci devra de surcroît être intuitive, afin qu elle puisse être utilisée par tout type d utilisateur, y compris par ceux qui ne sont pas familiers avec les outils informatiques. La contrainte principale que nous avons à respecter pour mener à bien ce projet est l utilisation de la technologie HTML5, qui est la nouvelle révision majeure d HTML toujours en développement, pour permettre la diffusion des vidéos, grâce à l interface de programmation (API) qu elle vient d introduire. Bien que cette technologie ne soit toujours pas finalisée, nous tenons à préciser que tous les navigateurs récents ont déjà implémenté un certain nombre de fonctionnalités de HTML5, dont celles que nous allons employer. 4

5 L utilisateur de l application de gestion de vidéos ne verra pas de différence avec une architecture en Flash lors de l envoi de sa vidéo car la distinction se fait essentiellement au niveau de l encodage de celle-ci et lors de sa lecture. En effet, contrairement à une architecture en Flash pour laquelle les vidéos sont visibles depuis n importe quel navigateur du moment que Flash est supporté, une architecture utilisant HTML5 lit directement le fichier envoyé sur le serveur sans l encoder dans un format spécifique. Les différents navigateurs web existants à ce jour ne supportant pas tous les mêmes formats de vidéo, il nous faudra donc utiliser différents codecs lors de l encodage d une vidéo afin que celle-ci puisse être lue sur la totalité des plates-formes existantes. Pour résumer l intérêt de l application que nous devrons délivrer, voici un bref schéma récapitulatif mettant en avant le produit (l interface de gestion de vidéos) : Figure 1 - Diagramme "Bête à cornes" (Synthèse du besoin) Initialement, le projet n incluait pas la réalisation d une interface de gestion mais seulement la conduite d une analyse sur les différentes solutions d encodage possibles dans le cadre d une mise en œuvre d un système de diffusion de vidéos en utilisant HTML5, ainsi que la réalisation d une maquette fonctionnelle permettant de diffuser des vidéos. Ne jugeant pas le sujet assez conséquent, la possibilité de réaliser une interface de gestion a ensuite été rajoutée avant de devenir notre objectif principal. 5

6 Liste des fonctionnalités Fonctionnalités existantes Un serveur Flash (avec beaucoup d espace disponible). Une interface de gestion de vidéos. Fonctionnalités à implémenter L utilisateur pourra mettre en ligne les vidéos de son choix. L utilisateur pourra associer à chaque vidéo un certain nombre d informations : un titre, une catégorie, une liste de tags, un statut, une licence, etc. L utilisateur pourra gérer ses propres vidéos : Il pourra modifier ses informations : titre, catégorie, tags, licence, statut. Il pourra donner le contrôle de celle-ci à un autre utilisateur. Il aura la possibilité de récupérer le code HTML d intégration de celle-ci dans une page web. Il pourra la supprimer. Si l utilisateur est un administrateur, il pourra gérer les autres utilisateurs et leurs vidéos. Dans le cadre d une vidéo envoyée automatiquement, un administrateur pourra donner le contrôle de celle-ci à un utilisateur. Exigences fonctionnelles 3 statuts doivent être possibles pour une vidéo : Privée (par défaut) : seuls le propriétaire de la vidéo et les administrateurs peuvent la voir. Partagée : seules les personnes connectées à l application peuvent accéder à la vidéo cela permet de s échanger les vidéos ou simplement de savoir quelles sont les vidéos déjà présentes sur le serveur. Publique : tout le monde peut voir la vidéo. Plusieurs niveaux d administration doivent être disponibles : Utilisateur classique : enseignant, enseignant-chercheur, personnel de l Université. Administrateur : un utilisateur standard promu et disposant de fonctionnalités de gestion supplémentaires. L encodage des vidéos doit être effectué en respectant ces exigences : Il faudra utiliser le codec WebM (développé par Google) qui semble être le meilleur compromis grâce à sa qualité, à son statut open-source et à sa compatibilité avec les navigateurs Google Chrome, Mozilla Firefox, Internet Explorer et Opera. Il faudra également utiliser H.264 pour couvrir la quasi-totalité des navigateurs (dont Safari). Il faudra donc effectuer deux encodages distincts pour chaque vidéo (une fois celle-ci envoyée sur le serveur dans un format quelconque). L application à réaliser devra respecter le plus possible la charte graphique de l Université d Avignon. 6

7 Il faudra transcoder les vidéos déjà présentes sur le serveur Flash actuel afin que celles-ci puissent être lisibles via la nouvelle architecture HTML5. Exigences non fonctionnelles Nous utiliserons les langages web suivants pour développer l application : HTML, CSS, PHP, JavaScript, AJAX. Nous utiliserons le framework libre Symfony pour nous aider dans le développement de l interface de gestion de vidéos. Nous disposerons d approximativement 4 mois pour développer l interface de gestion de vidéos. Une maquette doit être réalisée avant le début du développement afin de présenter le travail d analyse effectué. Un rapport témoignant du travail fourni sera également à délivrer une fois l application terminée. Nous utiliserons l application libre FFmpeg pour encoder les vidéos. 7

8 REPONSE AUX BESOINS Différents types d utilisateurs Il a été établi que seul le personnel de l Université d Avignon aura la possibilité de se connecter à l application. Cela implique que toute personne extérieure à celle-ci n aura pas la possibilité de créer un compte pour partager ses vidéos. De plus, même si les étudiants pourront se connecter à l interface de gestion de vidéos, leurs identifiants étant stockés dans les bases de données de l Université, ils n auront accès à aucune des fonctionnalités que peut proposer l application. Ainsi, les seules personnes qui profiteront d un accès à l interface de gestion de vidéos seront les enseignants-chercheurs, les enseignants, les IATOS et personnels de Bibliothèque. Chaque personne aura une utilisation différente de l application et bénéficiera donc de fonctionnalités spécifiques. L application comporte ainsi deux types d utilisateurs : Les utilisateurs «standards», ayant accès aux fonctionnalités de base de l application : Envoi de vidéos sur le serveur ; Gestion de celles-ci : modification de leurs informations ou suppression ; Possibilité de les partager en insérant le code HTML approprié dans une page web. Les administrateurs, ayant accès à des fonctionnalités de gestion avancées : Les mêmes fonctionnalités que les utilisateurs standards ; Gestion des utilisateurs et de leurs vidéos ; Attribution de vidéos sans propriétaire (vidéos envoyées automatiquement sur le serveur) à un utilisateur ; Gestion des catégories de vidéos (ajout, modification, suppression). Cependant, même si seules les personnes énoncées ci-dessus profiteront d un accès à l application, il faut souligner le fait que tout le monde pourra visionner les vidéos qu elle contient, à condition bien sûr que celles-ci soient intégrées dans une page web et que leur statut soit public. Page d accueil La page d accueil de l application s adapte au type d utilisateur connecté. Dans le cas où l utilisateur n est pas encore identifié, celui-ci est redirigé vers la page du Service Central d Authentification (CAS), qui lui permettra de s authentifier sur l ensemble des services de l Université partageant ce système. 8

9 Connexion en tant qu utilisateur standard Figure 2 - Page d'accueil d'un utilisateur standard Connexion en tant qu administrateur Figure 3 - Page d'accueil en tant qu'administrateur 9

10 Nous pouvons témoigner, via ces deux captures d écran, des différences qu il peut exister entre un utilisateur standard et un administrateur. Les deux utilisateurs peuvent visualiser d un bref coup d œil les dernières vidéos qu ils ont envoyées sur le serveur, rechercher une vidéo en particulier ou bien envoyer une nouvelle vidéo. Cependant, l administrateur bénéficie d options supplémentaires, que ce soit dans le corps de la page ou dans le menu de navigation situé en haut de celle-ci. En effet, l administrateur peut rapidement voir quelles sont les dernières vidéos envoyées sur le serveur (tous utilisateurs compris), mais il peut surtout accéder aux vidéos sans propriétaire, c est-à-dire aux vidéos envoyées automatiquement sur le serveur (notamment via des boîtes d enregistrement présentes en amphithéâtres, qui permettent d enregistrer le contenu d un cours ou d une assemblée). Il pourra ainsi choisir d affecter un utilisateur à cette vidéo afin que celle-ci puisse être modifiée et/ou partagée avec différentes personnes. Par ailleurs, le menu indique que l administrateur dispose de fonctionnalités de gestion des utilisateurs et des catégories, auxquelles il peut accéder depuis n importe quelle page. Cas d utilisations Envoyer une vidéo L envoi de vidéos au serveur se fait en deux parties : L utilisateur choisit la vidéo qu il veut envoyer au serveur ; Pendant l envoi de celle-ci, il peut modifier ses informations en remplissant un formulaire. L utilisateur peut accéder à l envoi de vidéos via le menu situé en haut de page ou via la page d accueil (en cliquant sur le lien «Ajouter une vidéo»). Choisir la vidéo Figure 4 - Mise en ligne d'une vidéo 10

11 But : envoyer la vidéo sur le serveur en vue d éventuellement la partager. Description : l utilisateur choisit la vidéo qu il veut envoyer sur le serveur. Acteurs : l utilisateur standard ou l administrateur. Préalables : l utilisateur est correctement connecté à l application. Conséquents : la vidéo s envoie sur le serveur et l utilisateur est pendant ce temps redirigé vers une page sur laquelle il devra compléter les informations de celle-ci. Exceptions : le fichier envoyé n est pas un fichier vidéo ; le fichier envoyé ne respecte pas l un des formats imposés ; le fichier envoyé dépasse la taille maximale autorisée. Compléter les informations de la vidéo Figure 5 - Remplissage du formulaire (informations de la vidéo) 11

12 But : compléter les informations concernant la vidéo afin de mieux la classer et d informer les personnes qui la visualiseront de leurs droits par rapport à celle-ci (licence). Description : l utilisateur donne un titre à sa vidéo, puis l affecte à une catégorie tout en lui attribuant une liste de tags. Il peut ensuite lui donner un statut afin de décider des personnes avec qui il souhaite partager cette vidéo. Enfin, il doit choisir une licence pour sa vidéo pour informer les personnes la visualisant de leurs droits par rapport à celle-ci. Acteurs : l utilisateur standard ou l administrateur. Préalables : l utilisateur a envoyé un fichier vidéo valide. Conséquents : la vidéo envoyée sur le serveur s encode dans les deux formats WebM et H.264 (en tâche de fond) ; l utilisateur peut continuer sa navigation sur l application. Exceptions : l un des champs texte rempli est trop long ou contient des caractères interdits ; l utilisateur laisse un ou plusieurs champs vides ; une erreur est survenue lors de l envoi de la vidéo (déconnexion brutale, l utilisateur a quitté la page, ). Gérer mes vidéos L utilisateur peut accéder à la gestion de ses vidéos depuis le menu situé en haut de chaque page. Figure 6 - Gérer mes vidéos 12

13 But : disposer d une vue de l ensemble de ses propres vidéos en disposant d options de filtrage et de tri dans le but d accéder à une ou plusieurs vidéos en particulier. Description : l utilisateur accède à l ensemble de ses vidéos, réparties sur une ou plusieurs pages, chaque vidéo étant accompagnée d un récapitulatif de ses informations. Il a la possibilité de filtrer celles-ci via la barre de recherche qui agit sur les noms, catégories et tags de vidéos. Il peut également trier les vidéos qui lui sont retournées par date, nom, catégorie, tag, licence ou durée. Acteurs : l utilisateur standard ou l administrateur. Préalables : l utilisateur est connecté à l application et a déjà envoyé une ou plusieurs vidéos. Conséquents : en cliquant sur l une des vidéos retournées, l utilisateur sera dirigé vers la page de modification de celle-ci. Exceptions : l utilisateur n a envoyé aucune vidéo ; l utilisateur saisit un nom, une catégorie ou un tag qui n existe pas (aucune vidéo retournée). Modifier une vidéo L utilisateur peut accéder à la page de modification d une vidéo en ayant cliqué sur celle-ci depuis la page de gestion de ses vidéos ou depuis la page d accueil (dernières vidéos envoyées). 13

14 Figure 7 - Modifier une vidéo But : mieux classer la vidéo, changer sa visibilité ou sa licence, récupérer son code d intégration, donner son contrôle à un autre utilisateur ou encore la supprimer. Description : l utilisateur dispose de plusieurs champs pré-remplis à compléter. Il peut modifier le titre de sa vidéo, sa catégorie, ses tags, son statut, sa licence et sa miniature (l application peut lui en proposer une automatiquement ou l utilisateur peut décider d en choisir une manuellement). Il peut aussi décider de donner le contrôle de celle-ci en saisissant le nom de la personne qui bénéficiera de cet accès dans le champ «Propriétaire» (via un système de saisie semi-automatique, proposant une liste de noms correspondant à ce qui est saisi). L utilisateur a également la possibilité de récupérer le 14

15 code HTML d intégration de la vidéo afin de l incorporer dans une page web. Il peut enfin décider de la supprimer. Cette dernière action étant irréversible, si l utilisateur souhaite partager à nouveau sa vidéo, il sera dans l obligation de la renvoyer sur le serveur. Acteurs : l utilisateur standard ou l administrateur. Préalables : l utilisateur est connecté à l application, a déjà envoyé une ou plusieurs vidéos et a cliqué sur l une d elles. Conséquents : les informations sont mises à jour et l utilisateur peut alors continuer sa navigation sur le site. Exceptions : l un des champs texte rempli est trop long ou contient des caractères interdits ; l utilisateur laisse un ou plusieurs champs vides ; l utilisateur saisit un nom d utilisateur qui n existe pas. Gérer les utilisateurs La gestion des utilisateurs se fait en deux parties : L administrateur doit choisir un utilisateur à gérer ; Une fois choisi, l administrateur peut accéder aux vidéos de l utilisateur. L administrateur peut accéder à la gestion des utilisateurs via le menu situé en haut de page. Choisir l utilisateur à gérer Figure 8 Choisir l utilisateur à gérer 15

16 But : accéder aux vidéos d un utilisateur ou modifier son niveau d administration. Description : l administrateur bénéficie d une vue de l ensemble des utilisateurs (sur plusieurs pages) et de leur nombre de vidéos. Il peut décider de filtrer les résultats en tapant le nom d un utilisateur via la barre de recherche. Acteurs : l administrateur. Préalables : l utilisateur est correctement connecté à l application et dispose des droits nécessaires. Conséquents : en cliquant sur l un des utilisateurs, l administrateur sera dirigé vers la page de gestion de celui-ci. Exceptions : l administrateur saisit un nom d utilisateur qui n existe pas. Gérer l utilisateur sélectionné Figure 9 - Gérer l'utilisateur sélectionné 16

17 But : promouvoir administrateur l utilisateur choisi pour qu il bénéficie d options de gestion supplémentaires ou modifier l une de ses vidéos. Description : l administrateur accède à l ensemble des vidéos de l utilisateur sélectionné, réparties sur une ou plusieurs pages, chaque vidéo étant accompagnée d un récapitulatif de ses informations. Il a la possibilité de filtrer celles-ci via la barre de recherche et de trier les vidéos qui lui sont retournées. L administrateur peut également promouvoir administrateur l utilisateur choisi. Acteurs : l administrateur. Préalables : l utilisateur est correctement connecté à l application, dispose des droits nécessaires et a cliqué sur l utilisateur affiché. Conséquents : en cliquant sur l une de ses vidéos, l administrateur sera dirigé vers la page de modification de celle-ci. Exceptions : l utilisateur n a envoyé aucune vidéo ; l administrateur saisit un nom, une catégorie ou un tag qui n existe pas (aucune vidéo retournée). 17

18 REPONSE TECHNIQUE Présentation du streaming vidéo Deux types de streaming Il convient tout d abord de différencier les deux types de streaming existants : le pseudo-streaming (téléchargement progressif) ; le streaming (diffusion en continu). Le pseudo-streaming permet de télécharger le fichier vidéo le plus rapidement possible indépendamment du débit de celui-ci. Généralement, l utilisateur peut démarrer le visionnement de la vidéo avant que celle-ci ne soit entièrement chargée, la lecture débutant à partir du moment où il y a assez de données téléchargées pour procéder à une lecture continue. Cette solution est donc relativement peu économe en bande-passante mais il s agit du modèle utilisé par les grandes entreprises de VOD, comme YouTube ou Dailymotion. Le streaming fonctionne différemment car il diffuse la vidéo en fonction de son débit, indépendamment de la vitesse de connexion de l utilisateur. Cette solution est plus économe en bande-passante que le pseudo-streaming (en cas de visionnage partiel) mais elle implique que l utilisateur ne charge que ce qu il regarde et les données chargées sont immédiatement supprimées une fois qu elles ont été affichées. Cette méthode est donc avantageuse dans le cas où l on souhaite effectuer une diffusion en direct via un serveur de streaming. Technologies permettant le streaming De nombreux modules externes aux navigateurs web existent pour visionner des vidéos : Silverlight, Quicktime, Windows Media Player et surtout Flash. Mais récemment, HTML5 est apparu comme un nouveau moyen efficace de diffuser du contenu vidéo. Nous allons ici détailler brièvement les trois principales technologies utilisées de nos jours, à savoir Flash, HTML5 et, dans une moindre mesure, Silverlight : Adobe Flash : Il s agit du moyen le plus populaire aujourd hui pour insérer une vidéo dans une page web. Cela peut être expliqué par le fait qu il n y a pas besoin de télécharger de lecteur vidéo ni d'installer de codecs car seul l installation du plugin Flash pour le navigateur est requise. HTML5 : Flash et Silverlight sont des technologies propriétaires et non-standardisées. La balise «video» d HTML5 permet de corriger ces problèmes et semble ainsi représenter l avenir du streaming vidéo. HTML5 n est pas encore totalement répandu car il est toujours en développement et, par conséquent, tous les navigateurs ne le supportent pas encore totalement. Silverlight : Il s agit d une technologie de Microsoft destinée à produire des applications web riche et fonctionne de façon similaire à Flash. Silverlight dispose de technologies intéressantes comme le Smooth Streaming, qui adapte instantanément le débit de la vidéo en fonction de la connexion de l utilisateur. 18

19 Technologies utilisées HTML5 HTML5 est la nouvelle révision majeure d HTML (HyperText Markup Language), qui est un langage conçu pour gérer et organiser le contenu des pages web. Il fut officialisé en 2007 par le World Wide Web Consortium (W3C), qui est un organisme de standardisation chargé de promouvoir la compatibilité des technologies du World Wide Web (WWW). Bien qu HTML5 soit toujours en développement, tous les navigateurs utilisent déjà certaines de ses fonctionnalités. Le successeur de HTML 4.01 intègre de nombreuses nouveautés, incluant de nouvelles balises, de nouveaux attributs ou encore de nouvelles API, ainsi qu un allégement général du code des pages HTML et de nouvelles fonctionnalités JavaScript (géolocalisation, WebSockets, etc.). De toutes ces fonctionnalités, celle qui nous sera essentielle dans la réalisation de notre projet est l API permettant de jouer des vidéos en utilisant la nouvelle balise «video», fonctionnant sur tous les navigateurs web récents. La balise «video» d HTML5 permet de se libérer des modules externes aux navigateurs en proposant son propre système et en intégrant directement un lecteur vidéo dans une page HTML très facilement. De plus, même si ses fonctionnalités ne sont pas encore aussi avancées que celles qu un lecteur Flash peut proposer, la balise «video» propose des attributs intéressants et simples à utiliser : autoplay : commence automatiquement la lecture de la vidéo dès le chargement de la page ; controls : affiche la barre de contrôles de la vidéo du navigateur (chaque navigateur web dispose de sa propre barre de contrôles, possibilité de la masquer si l on préfère créer la sienne) ; loop : permet de jouer en boucle la vidéo ; muted : permet de couper le son ; preload : trois valeurs autorisées : none : minimise le trafic du serveur en ne pré-chargeant aucune donnée ; metadata : ne pré-charge pas la vidéo mais charge uniquement ses métadonnées (dimensions, durée, etc.) ; automatic : l utilisateur peut charger la ressource complète (déclenche le chargement en cache de la vidéo en même temps que la page). width : largeur de la vidéo ; height : hauteur de la vidéo. Nous pouvons donc modifier de façon très simple les paramètres d une vidéo. Cependant, si nous énoncions plus haut que la balise «video» est supportée par tous les navigateurs récents, le W3C n a émis aucune obligation quant au codec à utiliser lors de la lecture d un fichier vidéo. Nous pouvons en effet trouver aujourd hui trois codecs principaux : H.264, Ogg Theora et WebM, chaque navigateur web supportant différents codecs. 19

20 Voici donc un tableau récapitulant les compatibilités de chaque codec avec les différents navigateurs : Figure 10 - Tableau des compatibilités des différents navigateurs Nous pouvons ainsi constater qu il nous est impossible d utiliser un seul codec dans le cadre du streaming de fichiers vidéo via HTML5. Ainsi, la seule solution possible est de passer par deux encodages différents. Nous allons détailler les trois codecs cités ci-dessus puis nous expliquerons quelle est la solution que nous avons retenue. H.264 Le codec H.264, qui est extrêmement populaire, est l un des codecs les plus avancés actuellement. Il comporte ainsi plusieurs avantages qui ont permis de contribuer à son succès. Il offre tout d abord aux vidéos un excellent ratio de compression par rapport à la qualité d encodage, ce qui est un point essentiel pour toute personne désirant visionner une vidéo sur internet. Il possède également la capacité de décoder matériellement les flux. Enfin, étant donné qu il est déjà utilisé sur la plupart des sites de VOD qui utilisent Flash, la transition vers HTML5 s en retrouve facilitée. Cependant, son plus gros défaut est qu il s agit d un codec propriétaire appartenant à la MPEG-LA, il contient donc énormément de brevets. Par conséquent, les éditeurs souhaitant implémenter le codec H.264 dans leur navigateur devront payer des licences très onéreuses. Le principe du codec est donc contraire à la philosophie initiale d internet. Ogg Theora Le codec Ogg Theora a pour principal avantage d être libre et ouvert. Pourtant, son absence de décodage matériel et surtout ses performances bien moindres que celles du codec H.264 font qu il reste moins intéressant à utiliser. WebM WebM est un codec open-source développé par Google. Il est réputé pour sa faible consommation de bande-passante et a l avantage de pouvoir proposer une qualité de vidéo proche de celle du codec H.264, en étant largement supérieur à celle que propose Ogg Theora. De plus, WebM dispose de nombreux partenaires, dont Android, Flash, Chrome, Opera, Mozilla Firefox, Java, Oracle, Skype, AMD, Logitech, Nvidia ou encore YouTube. En outre, WebM est un codec disponible sur presque tous les navigateurs à ce jour. Effectivement, Internet Explorer 9 intègre désormais le codec si celui-ci est installé sur Windows (non précisé dans le tableau ci-dessus), Microsoft incitant par ailleurs très fortement tous ses utilisateurs à passer à la version la plus récente de leur navigateur. 20

21 Nous allons donc utiliser les codecs H.264 et WebM pour l encodage des fichiers vidéos sur notre application. WebM est celui qui nous semble le plus pertinent et le plus prometteur, grâce à sa qualité de vidéo correcte, à ses nombreux partenaires et à son approche open-source. Nous utiliserons également H.264 pour toucher la totalité des navigateurs. Pour conclure cette partie, nous pouvons affirmer sans le moindre doute qu HTML5 est une technologie extrêmement prometteuse, dotée d un très grand potentiel. Certes les standards ne sont pas encore tous définis pour le moment, mais il est malgré tout déjà possible d utiliser les fonctionnalités présentes, de prendre de l avance et donc de faire avancer la standardisation. 21

22 ORGANISATION DU PROJET Ressources utilisées GroupZ Nous avons utilisé l outil GroupZ présent sur l ENT de l Université, qui nous a permis de disposer d un espace de gestion de fichiers, dans lequel nous avons pu partager différents documents : les rapports de chaque réunion, les besoins attendus ou encore la maquette de l application. Nous avons également communiqué au sein du groupe par mails via l adresse associée. RdvZ Nous avons utilisé l outil RdvZ, présent également sur l ENT, pour fixer chaque rendez-vous. Cet outil nous a permis de visualiser rapidement et clairement les disponibilités de chacun d entre nous afin de trouver une date qui convienne à tout le groupe. Espace projet L espace pour le projet que nous avons à disposition nous a permis de déposer les rapports de chaque réunion et permettra également d y déposer le présent cahier des charges ainsi que le rapport final du second semestre. Nous continuerons évidemment à le mettre à jour régulièrement au cours de l année. Réunions Fréquence Les réunions se sont déroulées à une fréquence d une par mois. Cependant, nous avons rencontrés quelques soucis dans notre organisation, en raison d un léger problème dans notre communication. Nous espérons donc pouvoir améliorer celle-ci pour le second semestre. Points abordés Les réunions ont suivi un même schéma, en débutant généralement par un bref rappel de ce qui a été dit antérieurement. Nous présentons ce que nous avons effectué depuis la réunion précédente puis nous discutons de ce qu il serait intéressant d ajouter ou de modifier. Nous terminons habituellement en faisant un dernier point sur les tâches à réaliser pour la réunion suivante. 22

23 CONCLUSION La partie du projet que nous avons eu à réaliser ce premier semestre nous a permis de se renseigner sur les différentes technologies web existantes. Nous avons également pu réfléchir à la problématique des différences de compatibilités de chaque navigateur afin de proposer des solutions permettant de satisfaire les attentes de chacun. De plus, nous avons pu analyser ce qui était attendu de notre part pour la réalisation de l application que nous aurons à délivrer au second semestre, avant de finir par présenter une maquette correspondant à celle-ci et détaillant les différents cas d utilisation. Ce cahier des charges contient donc le résultat de notre réflexion. Pour conclure, cette première partie fut très instructive et intéressante. Nous avons ainsi pu expérimenter le travail de groupe sur plusieurs mois consécutifs tout en préparant notre travail pour le second semestre. Enfin, découvrir les dernières technologies web fut très enrichissant, car celles-ci auront sans nul doute un rôle déterminant à jouer dans un futur proche. 23

24 REFERENCES Chiffres-clés de l Université d Avignon : Chaîne Dailymotion de l Université d Avignon : Chaîne Youtube de l Université d Avignon : Site web du projet : Documentation officielle de HTML5 (site du W3C) : Tableaux des compatibilités de chaque navigateur web : Philosophie initiale d internet : 24