AAPFUI18 M4DP Lot 3.2.2 site web audio API et son code ...€¦ · Livrable3.2.2)v1.0) ! Le)lecteur)media)accessible)à)tous! !! Media4Dplayer!–Site)web)(audio)API))et)son)code)source)documenté!!!!!

Livrable 3.2.2 v 1.0

www.media4dplayer.com

Le lecteur media accessible à tous

Media4Dplayer –Site web (audio API) et son code source documenté

1

Livrable 3.2.2


Version 1.0 Date 20/05/15

Auteur(s) francetélévisions

N° du Lot 3.2

Livrable 3.2.2 : site web (audio API) et son code source documenté

Titre du projet media4Dplayer

Abréviation M4DP

Désignation media4Dplayer, le lecteur media accessible à tous.

Durée du projet De Janvier 2015 à Juin 2016 – 18 mois

Coordinateur projet France Télévisions

Partenaires du lot FRANCE TELEVISIONS (FTV) DOTSCREEN (DT)

Prestataires du lot IRCAM

Organisme labellisateur CAP DIGITAL

Financeurs La Région Ile-de-France La BPIfrance

Titre de subvention Fonds Unique Interministériel – FUI18





2

Le projet media4Dplayer, lecteur media accessible à tous.

Site web (audio API) et son code source documenté

Date de soumission : 20/05/15 Version : 1.0

Objectif(s) du livrable

Développer une plate-forme HTML5 mettant en œuvre l'API Web Audio et exploitant les fonctionnalités de rendu audio utiles au démonstrateur final (sans synchronisation). Historique Date Modification(s)

V 1.0 20/05/15 Création du document





3

Le projet media4Dplayer Media4Dplayer est un projet collaboratif labellisé par le pôle de compétitivité Cap Digital et subventionné au titre du Fonds Unique Interministériel (FUI) par la région Île de France et BPIfrance. Ce projet de recherche et de développement s’inscrit dans la stratégie de Cap Digital, autour des thématiques d’accessibilité des contenus, de développement numérique et de Silver économie.

Durée de projet 18 mois : Janvier 2015 – Juin 2016

Avertissement Les informations contenues dans ce document peuvent être sujet à modification sans préavis. Société ou noms de produits mentionnés dans ce document peuvent être des marques ou des marques déposées de leurs sociétés respectives.

Tous les droits sont réservés

Le document est la propriété des membres du consortium media4Dplayer. Aucune copie ou distribution, sous quelque forme ou par tout moyen, n’est autorisé sans l'accord écrit et préalable du (des) propriétaire(s) des droits.

Ce document ne reflète que le point de vue de ses auteurs. Le consortium media4Dplayer et les financeurs ne peuvent être tenus responsables de l'usage qui pourrait être fait des informations contenues dans ce document.

©2016 media4Dplayer





4

Table Des Matières

1. INTRODUCTION ...................................................................................................................................... 5

2. PRESENTATION DES MODULES AUDIO DE MEDIA4DPLAYER ................................................................... 6

2.1. CARACTERISTIQUES GENERALES ......................................................................................................................................... 6 2.2. MODULE “SMART FADER” ........................................................................................................................................... 7 2.3. MODULE “MULTICHANNEL SPATIALISER” ................................................................................................................... 9 2.4. MODULE “OBJECT SPATIALISER AND MIXER” ............................................................................................................ 10 2.5. MODULE “DIALOG ENHANCEMENT” ......................................................................................................................... 12

CONCLUSION ................................................................................................................................................ 14

ANNEXE ....................................................................................................................................................... 15





5

1. Introduction francetélévisions a lancé une consultation dans le but d’adresser les problématiques audio et problématiques d’interopérabilité entre les différents navigateurs HTML5, l’API Web Audio et l’application media4Dplayer. Les réponses des différents candidats ont permis de statuer sur les processus audio avancés qu’il était possible de développer dans le temps et le budget impartis, en visant la finalité d’une preuve de concept et non d’un produit commercial. Dans les solutions que proposaient les candidats, certaines étaient clairement axées sur les performances et pointaient du doigt des mises à jour profondes à prévoir au niveau du moteur audio des navigateurs, afin de garantir un respect des latences audio/vidéo et répondre strictement au cahier des charges fixé par francetélévisions. Une autre approche, plus légère et clé en main décrivait des développements centrés sur l’utilisation des fonctionnalités strictement offertes par l’API Web Audio. C’est cette piste, proposée par l’IRCAM, qui fut finalement retenue. Les développements ont pu démarrer dans la foulée, selon le principe de la méthode agile.





6

2. Présentation des modules audio de media4Dplayer

Suite à la consultation lancée par francetélévisions et à l’analyse des réponses des différents candidats, l’IRCAM a été retenu en qualité de sous-‐traitant pour le développement des process audio avancés. Listés ci-‐dessous, ces modules devaient être développés dans l’environnement HTML5/JavaScript à l’aide de l’API Web Audio, puis faire l’objet d’une publication open source sous licence CeCILL/GNU-‐GPL.

2.1. Caractéristiques générales

L’application globale (le lecteur multimédia et son interface graphique), dénommée media4Dplayer est développée en parallèle des modules audio sur une base de navigateur Chromium/Google Chrome. Jusqu’à 3 lecteurs/décodeurs de flux audio instanciés par l’application media4Dplayer peuvent simultanément alimenter l’API Web Audio. Ces flux peuvent présenter les caractéristiques suivantes :

● monophonique (1.0) ;

● stéréophonique (2.0) ;

● multicanal sans LFE (5.0) ;

● multicanal (5.1) ;

● 8 canaux (7.1) ;

Pour chaque type de flux, l’affectation des différents canaux est figée afin de simplifier les développements (ordre normalisé ITU). En pratique, ces formats de flux audio correspondent aux différentes versions livrées pour chaque programme, telles que décrits dans le livrable 3.1 (audio principal et un ou plusieurs flux audio enrichi).

En cas d’incompatibilité ou d’erreur de fonctionnement au niveau de l’API Web Audio, une remontée d’information vers media4Dplayer est souhaitée.

La validation des modules développés s’est effectuée en amont de l’intégration finale à l’application media4Dplayer, à l’aide d’une interface utilisateur sommaire instanciée sous la même version de Chromium/Google Chrome que l’application (ci-‐après dénommée “SandBox”).





7

Figure 1 : exemple d'environnement de développement Web Audio (SandBox)

Bien que la totalité des latences induites par les process audio était souhaitée fixe, quelque soit l’état actif/inactif des modules, les résultats d’étude (livrable 3.2.1) ont contraint les équipes projet à mener des tests in situ pour vérifier à minima un respect de la synchronisation vidéo/audio.

2.2. Module “SMART FADER”

Il s’agit du contrôleur de volume final, destiné à ajuster le niveau d’écoute, notamment en milieu difficile. Une fois activé, le module permet d’augmenter substantiellement le volume global sans nuire à la qualité de l’écoute. Le réglage de niveau que ce module réalise s’appuie sur 3 variables qui lui sont communiquées par l’application media4Dplayer (à travers la fiche de métadonnées aspirée au préalable par le back office) :

● la position du fader indiquée par l’utilisateur ; ● la mesure intégrée de loudness du programme écouté (ITU-‐R BS.1770-‐3) ; ● la mesure de MaxTruePeak du programme écouté (ITU-‐R BS.1770-‐3) ;

Le réglage du volume se comporte de la façon suivante :

● atténuation classique du volume sonore entre le niveau nominal (gain = 0) et en deçà ; ● augmentation classique du volume sonore entre le niveau nominal et le niveau

maximal (niveau max = niveau nominal + I MaxTruePeak I) ; ● limiteur/compresseur multicanal au delà du niveau maximum ;





8

Ce module communique également une variable d’état à l’application client, reporté dans l’interface graphique, un indicateur d’état “compression dynamique” lorsque cette fonction est active.

Ce premier module, assez simple, revient à transposer dans l’environnement Web Audio le fonctionnement d’une tranche de console audionumérique sur laquelle on insèrerait un processeur de dynamique. Le seuil de déclenchement dudit processeur est lui-‐même commandé par une métadonnée externe |MaxTruePeak|, tout en tenant compte du loudness intégré du programme, de sorte à aligner le niveau nominal sur cette valeur, puis en déduire la quantité de “réserve” disponible avant compression.

Cependant, le processeur de dynamique intégré à Chromium/Google Chrome se limite à un traitement purement stéréophonique, le passage à une version multicanale est d’ailleurs souhaité de longue date par la communauté. Les développeurs ont tout d’abord tenté d’utiliser les fonctionnalités embarquées en chaînant plusieurs instances stéréophoniques du nœud DynamicProcessorNode, mais les résultats des tests furent éliminatoires à l’écoute. Dans une logique agile et open source, l’IRCAM a lancé des recherches sur du code source C/C++ libre de droit, permettant de remplir la fonction. Une fois traduit en langage JavaScript et inséré dans la SandBox par l’utilisation d’un nœud ScriptProcessorNode, le résultat s’est avéré beaucoup plus qualitatif que le processeur intégré à l’API Web Audio. La mesure de latence induite par ce processus supplémentaire fut considérée comme négligeable.

Figure 2 : tests et réglages du module SMART FADER dans la SandBox





9

2.3. Module “MULTICHANNEL SPATIALISER”

Il s’agit du “moteur de spatialisation” de l’application, mis en œuvre pour spatialiser un contenu multicanal lors d’une écoute au casque (écoute binaurale) ou sur une paire de haut-‐parleurs (écoute transaurale). Ce module reçoit plusieurs variables de l’application :

● le nombre et la nature des flux audio à traiter (voir 2.1 Caractéristiques générales), et notamment pour chaque flux sa position dans l’espace (azimut, élévation, distance) ;

● le rappel d’un preset de HRTFs (Head-‐Related Transfert Function, ensemble des filtres nécessaire au process de spatialisation) au format AES-‐69 hébergé sur le serveur OpenDAP de l’IRCAM ;

● le rappel d’un preset d’égalisation du type de casque ou d’oreillettes utilisé ; ● un gain d’offset afin de maintenir un niveau subjectif après l’enclenchement du

process de spatialisation ;

● la direction de l’axe d’écoute par rapport à l’écran ;

Le procédé consiste à spatialiser les différents canaux en vue d’une écoute binaurale ou transaurale. Pour ce faire, il s’appuie sur le jeu de HRTFs rappelé (preset) ou fourni. Ce process inclut une égalisation débrayable pour compenser la réponse en fréquences du casque ou de la paire d’oreillettes utilisée le cas échéant. L’ensemble est ajusté en gain au moyen de l’offset communiqué, de sorte de maintenir le niveau d’écoute du programme.

Le process transaural requiert un traitement supplémentaire de sorte d’annuler les trajets croisés haut-‐parleur/oreille. Il est optimisé pour une paire de haut-‐parleurs d’ordinateurs (25 à 30 cm d’écartement). Il peut être adapté en temps réel pour suivre la direction de l’axe d’écoute (head-‐tracking). Pour réaliser ce suivi, il est généralement admis de doubler le process de spatialisation puis réaliser une bascule d’un jeu de HRTFs à l’autre en fonction de l’évolution de l’axe d’écoute. Cette dernière fonction a bien été développée et intégrée dans la SandBox, mais pas réinjecté dans l’application finale car trop coûteuse en matière de ressources.

Figure 3 : activation du module MULTICHANNEL SPATIALISER dans la SandBox





10

2.4. Module “OBJECT SPATIALISER AND MIXER”

Il s’agit d’un embryon de “moteur de rendu” pour des contenus audio orienté objets, limité à la mise en œuvre d’un seul objet sonore mixé à la volée avec le son principal du programme. Ce module, particulièrement adapté au mixage de l’audiodescription doit aussi permettre la spatialisation de cet objet dans l’espace tridimensionnel lors d’une écoute au casque (écoute binaurale). Ce module reçoit plusieurs variables de l’application :

● la description du flux audio à traiter (voir 2.1 Caractéristiques générales) ;

● la position souhaitée par l’utilisateur pour la spatialisation du commentaire additionnel (azimut, élévation, distance) ;

● le rappel d’un preset de HRTFs au format AES-‐69, et l’offset de gain correspondant, identiques au module précédent ;

● la direction de l’axe d’écoute par rapport à l’écran, identique au module précédent ;

Le procédé consiste à mixer automatiquement et à la demande un commentaire additionnel avec l’audio du programme principal. En amont du mixage, ce commentaire se trouve spatialisé en azimut en cas d’écoute sur haut-‐parleurs, et en azimut, élévation et distance en cas d’utilisation d’un casque (grâce au jeu de HRTFs rappelé ou fourni), en suivant potentiellement l’axe d’écoute (head-‐tracking comme décrit au module précédent). Puis ce mixage, en l’absence de métadonnées dynamiques pour en renseigner les paramètres, fait l’objet d’un ajustement automatique du niveau du programme principal selon les principes suivants :

● Dès que le niveau RMS du commentaire C dépasse la valeur N, le niveau RMS du programme P est analysé :

○ Si P > X, le programme P sera compressé proportionnellement avant d’être mixé avec le commentaire C ;

○ Si P < X, le programme P et le commentaire C sont simplement mixés ;

● En l’absence de commentaire C, le programme P n’est pas modifié.

Les paramètres de compression dynamique du programme P tels que threshold, ratio, temps d’attaque et de descente restent ajustables.

Durant les tests de qualité, le rendu de la partie spatialisation du commentaire a fait l’unanimité, ce procédé utilisant principalement le moteur de rendu développé dans le module précédent. En revanche, le service rendu par le process “Receiver-‐Mix” (le mixage automatique du commentaire d’audiodescription et du programme principal) s’est avéré inopérant, pointant les manques du processeur de dynamique intégré à l’API Web Audio. L’équipe projet a longuement travaillé sur les différents réglages possibles, en vain… Les analyses de niveau relatif programme/commentaire en temps réel dépassaient les ressources processeur en mode pur JavaScript. À la demande de francetélévisions et en adéquation avec l’étude Web Audio préalablement menée, l’IRCAM a développé un module équivalent sous la forme d’une application native Max/MSP pour système Mac OS X (Max/MSP est un autre environnement de développement orienté audio qui s’appuie sur des objets et des fonctions logiques codés en C/C++).





11

Figure 4 : sous-‐module “Receiver-‐M

ix” en version native et fonctionnelle

Cette version native et fonctionnelle du Receiver-‐Mix donne un aperçu de la plus-‐value qu’apporte la fonctionnalité de mixage automatique d’un commentaire avec le programme principal. Même s’il n’existe pas de réglages universels qui donnent satisfaction sur tous les programmes (les excursions de dynamique varient), le résultat médian reste très convaincant. Dans l’attente d’un possible portage de cette fonction dans l’environnement HTML5, le démonstrateur media4Dplayer propose dans ses préférences un réglage manuel et global du niveau de commentaire d’audiodesription





12

2.5. Module “DIALOG ENHANCEMENT”

Il s’agit d’un contrôleur prédisposé à ajuster le niveau des dialogues, placé en amont des modules précédents, il fonctionne selon plusieurs modes, pilotés par la fiche de métadonnées EBUCore ingérée à travers le back office :

● Mode 1 : l’ajustement total du niveau des dialogues en cas de fourniture séparée des éléments “dialogues seuls” et “ambiances, musiques et effets” ;

● Mode 2 : l’ajustement partiel du niveau des dialogues en cas de fourniture d’un mixage TV 5.0 ou 5.1, par action sur le niveau sonore de la voie centrale ;

● Mode 3 : le renforcement partiel du niveau des dialogues par la mise en œuvre d’une égalisation dynamique centrée sur les fréquences de la voix.

Pour son fonctionnement, ce module agit ou réagit par rapport à 3 variables :

● la composition du programme et des audio associés : éléments séparés (“dialogues seuls” + “ambiances, musiques et effets”), type 5.0 ou 5.1, ou simple programme stéréo qui conduisent au choix respectif du Mode 1, 2 ou 3

● en fonction du mode, l’interface graphique adapte la présentation et le champ d’action du fader “dialogues” :

Mode 1 : aux extrêmes les “dialogues” peuvent être coupés ou les “ambiances, musiques et effets” peuvent être coupés, le fader “dialogues” agit comme une balance entre les deux

Mode 2 : l’excursion du fader “dialogues” est limitée aux graduations -‐6/+6

Mode 3 : l’excursion du fader “dialogues” est limitée aux graduations 0/+6

● la position du fader “dialogues” indiquée par l’utilisateur

● Le réglage du niveau des dialogues doit se comporter de la façon suivante :

Mode 1 : en fonction de la position du fader “dialogues”, la balance est ajustée entre “dialogues seuls” et “ambiances, musiques et effets”. La position centrale 0 correspond au niveau de mixage nominal entre les deux éléments sonores.

Mode 2 : en fonction de la position du fader “dialogues”, le niveau de la voie centrale est atténué/augmenté de -‐6 à +6 dB.

Mode 3 : en fonction de la position du fader “dialogues”, le signal stéréo est analysé de sorte d’en extraire les éléments monophoniques avant de leur appliquer un traitement dynamique associé à une égalisation centrée sur les fréquences de la voix, dans la limite d’une excursion de +6 dB.





13

Sur ce module, les interfaces proposées par l’API Web Audio ont été quasiment suffisantes pour traduire l’entièreté du cahier des charges en langage JavaScript, les développeurs ont utilisé :

1. un nœud GainNode spécifique pour le mixage d’une source audio monophonique de type “dialogue”. Le potentiomètre de ce nœud agit comme une balance entre les dialogues et les autres éléments séparés (fonction de crossfade) ;

2. un ChannelSplitterNode pour isoler la voie centrale d’un flux 5.1, puis un GainNode permettant son mixage indépendamment des autres canaux. Dans ce mode, une routine permet de limiter à +/-‐6 dB l’action du GainNode ;

3. une librairie supplémentaire branchée sur un ScriptProcessorNode, pour un matriçage M/S et une analyse temps réel du flux stéréophonique, afin d’en extraire les éléments monophoniques (exclusivement les dialogues). Dans ce 3ème mode, le rendu est raisonnablement moins bon qu’en cas de présence d’une piste de dialogue séparé ou d’une version 5.1, mais la qualité audio reste très acceptable, tout en augmentant suffisamment l’intelligibilité du programme.

Figure 5 : ajustement du niveau des dialogues via la SandBox





14

Conclusion L'évolution des fonctionnalités audio au sein des players est en phase avec l'arrivée de l'Ultra Haute Définition vidéo. Il s'agit de tirer partie de nombreux avantages offerts par les technologies numériques telle qu'une grande souplesse d'intégration, à comparer avec le design assez figé des récepteurs de télévision jusqu'à présent. Dans le domaine open-‐source, le consortium W3C à l'origine de la standardisation des outils du web, a lancé toute une boîte à outils pour la réalisation de process audio avancés : l'API Web Audio.

Le projet media4Dplayer, ambitieux dans le domaine des traitements audio avancés, peut considérer être allé au bout des possibilités actuelles de l'API Web Audio. Plusieurs modules totalement novateurs dans le domaine de l'open-‐source, sont désormais capables de rivaliser, en termes de qualité et d'usages, avec des technologies sous licences difficilement applicables dans le domaine multimédia de service public. En revanche, certaines fonctionnalités n'ont pas pu voir le jour, disqualifiées soit sur le plan de la qualité, soit au raison d'une trop lourde consommation de process.

Les travaux menés dans le cadre du projet ont néanmoins permis de convaincre les partenaires de l'utilité et le potentiel de l'API Web Audio, renforçant la conviction de participer à son évolution par le biais de contributions abouties auprès du consortium W3C. Pour ce faire, un rapprochement avec la BBC R&D, co-‐chair du groupe audio en charge de la standardisation de cette API, a pu être initié.





15

Annexe Hébergement du code source de la SandBox développée par l’IRCAM :

https://github.com/Ircam-‐RnD/m4dp-‐audio-‐modules

Exemple de code source commenté :

Documents

AAPFUI18 M4DP Lot 3.2.2 site web audio API et son code ...€¦ · Livrable3.2.2)v1.0) ! Le)lecteur)media)accessible)à)tous! !! Media4Dplayer!–Site)web)(audio)API))et)son)code)source)documenté!!!!!