La technologie WebRTC (appels vocaux et vidéo) est bonne car elle est intégrée directement sur le Web, ce qui, bien sûr, est parfait pour WebRTC. Cependant, le Web est parfois très compliqué lorsque WebRTC doit fonctionner à l'encontre des exigences générales d'utilisation des navigateurs. Le dernier exemple est la lecture automatique (ci-après dénommée «lecture automatique») de l'audio / vidéo, lorsque de nombreux utilisateurs perdent soudainement le son. L'ancien auteur de webrtcHacks -
Dag-Inge Aas - a personnellement rencontré ce problème. Voici ses réflexions: à quoi s'attendre des navigateurs en termes de lecture automatique, les derniers changements dans Chrome 66+, ainsi que quelques conseils sur la façon de vivre avec ces restrictions.
Les navigateurs ne veulent pas entendre le mal, donc les politiciens en lecture automatique coupent le son dans tous les médias. Cela peut être un problème pour les applications WebRTC.Si vous lisez ceci, il est très probable que vous ayez rencontré un étrange bug dans les navigateurs Safari 11+ et Chrome 66+. Nous parlons de sons d'interface qui sont soudainement devenus inaudibles (par exemple, un signal d'appel entrant), ou d'un visualiseur audio inactif, ou de la façon dont les interlocuteurs ne sont pas entendus.
Pour le moment, le bogue a affecté presque tous les lecteurs WebRTC populaires. C'est drôle, mais il semble que Meet de Google et Chromebox pour les réunions soient également affectés.
La racine de tous les maux: les changements dans les politiques de lecture automatique. Dans cet article, je parlerai des innovations, de leur relation avec WebRTC et de la manière de les gérer dans vos applications.
Erreur de l'année: erreur non interceptée: le contenu audio n'a pas été autorisé à démarrer. Il doit être repris (ou créé) après un geste de l'utilisateur sur la page. https://goo.gl/7K7WLuChangements
Tout a commencé en 2007, lorsque l'iPhone et iOS sont apparus. Si vous avez travaillé avec Safari pour iOS dans le passé, vous avez peut-être remarqué que Safari a besoin de la participation de l'utilisateur
pour lire les éléments <audio> et <video> avec du son . Plus tard, cette exigence a été légèrement assouplie lorsque iOS 10 a permis aux éléments vidéo de jouer automatiquement, mais sans son. Cela est devenu un problème pour WebRTC, car l'élément <video> doit «voir» et «entendre» le flux multimédia. Dans le contexte de WebRTC, laisser la vidéo s'exécuter automatiquement sans son est inutile, car pendant un appel vidéo, vous devez entendre les interlocuteurs par défaut, et ne pas appuyer sur "play" pour ce faire. Quoi qu'il en soit, peu de développeurs WebRTC étaient impliqués dans Safari pour iOS, car la plateforme ne prenait en charge WebRTC
que récemment . Avant iOS 11.
J'ai rencontré un bug pour la première fois lorsque j'ai testé la dernière implémentation (à l'époque) des appels vidéo pour iOS. À ma grande surprise, il a cessé de fonctionner, alors que je n'étais pas seul. L'
utilisateur de Github,
kylemcdonald, a signalé un bogue getUserMedia sur iOS. Solution? Ajoutez une
nouvelle propriété playsinline à l'
élément vidéo, ce qui permet à la vidéo de jouer avec le son. Malheureusement, les développeurs n'ont pas mentionné WebRTC dans le post d'origine sur la modification de la lecture automatique dans Safari, mais ils ont tout de même
écrit sur WebRTC séparément, avant la sortie. L'article dit ce qui suit sur
MediaStreams et la lecture audio:
- Les médias utilisant MediaStream seront lus automatiquement si la page Web utilise déjà une caméra / un microphone;
- Les médias utilisant MediaStream seront automatiquement lus si la page Web lit déjà du son. Pour que la lecture du son commence, l'implication de l'utilisateur est toujours nécessaire.
Donc, ce document ne mentionne pas
playsinline , mais si vous combinez les deux annonces, vous pouvez comprendre comment faire fonctionner l'application WebRTC dans Safari sur iOS.
Pourquoi la lecture automatique est-elle limitée?
Au départ, ils voulaient protéger les utilisateurs des coûts de trafic inutiles. En 2007, le transfert de données était coûteux (et le reste dans une grande partie du monde) et seuls quelques sites ont été adaptés au mobile. De plus, le son de lecture automatique a été et reste la chose la plus ennuyeuse sur le Web. Par conséquent, pour lire (et télécharger) la vidéo, l'action de l'utilisateur était requise; cela garantissait que l'utilisateur était au courant de ce qui se passait.
Puis vint le GIF. Les gifs ne sont que des animations à l'intérieur de <img>, ils ne nécessitaient donc pas la "permission" de l'utilisateur. Cependant, ils
peuvent être difficiles et donc douloureux pour les utilisateurs d'Internet mobile. La vidéo épargne le trafic, mais nécessite le consentement du téléchargement - les pages Web ont donc continué à utiliser les GIF. Tout a changé dans iOS 10 lorsque Safari a activé la lecture automatique avec le son désactivé. Depuis lors, l'optimisation de la charge est une question de vidéo autorisée et de départ de gifs de trois minutes dans l'oubli.
Limitation de la lecture automatique dans les navigateurs de bureau
Si vous cherchez comment arrêter le son de la lecture automatique, vous trouverez de nombreuses façons. Récemment, les agences de presse ont constaté que lorsqu'elles utilisent un son TRÈS FORT après le chargement de la page, les utilisateurs passent plus de temps sur le site et cliquent sur la publicité. Bien sûr, cela vaut la peine de le faire, mais ils le font toujours. Par conséquent, les navigateurs de bureau ont suivi l'exemple de Safari et ont interdit le son de lecture automatique - en particulier Chrome, qui a déployé de
nouvelles politiques de lecture automatique dans la version 66.
Cependant, Chrome s'est soudainement tourné vers le
Media Engagement Index (MEI) d'origine.
L'indice d'engagement des médias (MEI)
MEI est la façon dont Chrome mesure la volonté d'un utilisateur d'autoriser la lecture automatique sur une page; cet index dépend du comportement précédent sur la page. Vous pouvez voir à quoi cela ressemble ici:
chrome: // media-engagement / . MEI est considéré séparément pour chaque profil utilisateur et fonctionne en mode navigation privée (pour cette raison, il est très difficile pour les développeurs de tester des pages avec zéro MEI avant de les lancer en production). Quelqu'un devine-t-il ce qui va se passer ensuite?
Capture d'écran de la page interne de Chrome: // media-engagement / (source: developers.google.com/web/updates/2017/09/autoplay-policy-changes )Non seulement <audio> et <video>
Il s'est avéré que les nouvelles politiques affectaient non seulement les balises <audio> et <video>. Un modèle UX populaire pour WebRTC consiste à montrer à l'utilisateur
le niveau de volume du microphone . Pour ce faire, le son est
analysé via un AudioContext , qui prend un
MediaStream et émet son signal sous la forme d'un histogramme. Dans ce cas, le son n'est pas
lu , mais l'analyse audio est toujours bloquée en raison de l'
AudioContext , qui, en théorie, vous permet de produire du son.
Exemple de test de microphoneLe problème a été signalé pour la première fois dans le
traqueur de bogues Webkit en décembre , et six jours plus tard, un
correctif est arrivé dans Webkit . Correction? Ne bloquez pas
AudioContext si la page reçoit déjà du son et de la vidéo.
Alors pourquoi lisez-vous toujours cet article? Il s'est avéré que
Chrome a fait la même erreur que Safari . Bien que cela ait affecté de nombreux services WebRTC, Google est silencieux à ce sujet. Il y a eu de nombreuses tentatives pour les amener
à faire une déclaration publique sur l'impact de la lecture automatique sur WebRTC, mais cela ne s'est pas encore produit.
Les valeurs MEI interfèrent avec les tests
Comment en sommes-nous arrivés là? Bien sûr, les développeurs ont dû tester
AudioContext avant même les modifications de Chrome 66 qui affectaient chaque utilisateur. Et voici l'IEDM; vous comprenez, une interaction fréquente avec la page vous donne un MEI plus élevé, respectivement, les développeurs sont moins susceptibles de rencontrer un bug, car l'audio est depuis longtemps autorisé à jouer et à analyser. Et oui, le mode navigation privée n'aide pas, car MEI continue d'y être compté. Seul le lancement de Chrome avec un nouveau compte détectera un bogue - un fait que même
les ingénieurs expérimentés de Google QA peuvent facilement oublier.
Que doivent faire les fabricants de navigateurs?
Les changements dans les fonctionnalités de base sont difficiles à mettre en œuvre correctement. Chrome a publié de nombreux changements de stratégie de lecture automatique, mais aucun d'entre eux n'était lié à WebRTC ou
MediaStreams . Apparemment, les
API d'autorisations oubliées
n'ont pas
été mises à jour, les développeurs ne peuvent donc pas tester la demande d'actions personnalisées. Alternativement, vous pouvez autoriser
AudioContext à émettre du son si la page fonctionne déjà avec une caméra / un microphone (comme Safari), mais cela ressemble plus à un hack qu'à une solution. Et cela n'aidera pas dans d'autres cas d'analyse sonore lorsque
getUserMedia n'est pas utilisé.
Une solution concrète renforcée pour les fabricants de navigateurs consiste à autoriser
les autorisations des médias à influencer MEI. Si l'utilisateur a donné un accès constant à sa caméra et son microphone, il est logique de supposer que la page Web peut être suffisamment fiable pour produire du son sans actions supplémentaires et indépendamment du fait qu'elle fonctionne avec la caméra / le microphone ou non. Au final, l'utilisateur estime que vous ne partagerez pas sa caméra et son microphone avec des millions de personnes à leur insu. Dans ce cas, la lecture des sons d'interface est le moindre des problèmes.
Comment aider votre application
Heureusement, il existe quelques astuces pour vous aider. Voici une liste de ce que nous avons ajouté à Confrere lorsque nous avons rencontré un problème dans Safari pour iOS.
Jeux en ligne ajoutés
Pour renvoyer le son à la vidéo, ajoutez l'attribut
playsinline à l'élément vidéo. Cet attribut est bien documenté, fonctionne dans Safari et Chrome et n'a aucun effet secondaire dans les autres navigateurs.
Actions utilisateur
Pour «guérir» un visualiseur audio, ajoutez simplement une action personnalisée. Nous avons eu de la chance car nous avons pu ajouter (et ajouté) à notre écran de test de nombreuses étapes, impliquant la participation explicite de l'utilisateur. Vous avez peut-être moins de chance. Jusqu'à ce que Google se charge de le réparer, il n'y a pas d'autre moyen que d'impliquer l'utilisateur.
Impossible de corriger les sons d'interface
Ce n'est actuellement pas possible. Certaines personnes essaient de créer un
AudioContext qui est réutilisé dans l'application et tous les sons le traversent, mais je n'ai pas testé cette méthode. Safari est un peu plus simple: si vous travaillez déjà avec un appareil photo / microphone, vous pouvez jouer les sons des messages et appels entrants. Mais je ne pense pas que vous souhaitiez utiliser constamment la caméra / le microphone juste pour alerter profondément l'utilisateur d'un appel entrant.
Comme vous pouvez le voir, il existe déjà des moyens de résoudre le problème jusqu'à ce qu'une solution à long terme apparaisse. Oui, et n'oubliez pas
de vous abonner au bug pour recevoir les mises à jour.