Vous avez peut-être entendu dire que des changements allaient être apportés à l'autoplay sur Apple Safari et Google Chrome et vous souhaitez en savoir plus. Dans ce billet, je reviens sur l'histoire de l'élément vidéo et sur la manière dont la lecture automatique a façonné la prise en charge de la vidéo dans les navigateurs, sur les problèmes rencontrés et sur la manière dont nous les avons résolus, sur les recommandations à l'intention des développeurs pour un comportement optimal de la lecture automatique, et sur les perspectives d'avenir de la lecture automatique sur le web.

Si vous ne souhaitez pas lire l'intégralité du billet, en voici l'essentiel : vous pouvez continuer à utiliser la fonction autoplay et les choses devraient fonctionner, mais pour obtenir le meilleur soutien, vous devriez envisager de vous éloigner de l'attribut autoplay et utiliser l'attribut play() pour tirer parti de la promesse de jeu qu'elle renvoie.

CONTEXTE

En février 2007, Opera a publié un manifeste en faveur de la vidéo sur le web. Il a également publié une spécification technique pour ce que nous connaissons et aimons aujourd'hui sous le nom de <video> l'élément. L'élément WHATWG a rapidement adopté la spécification et d'autres navigateurs ont commencé à la prendre en charge dans les années qui ont suivi.

Apple a été l'un des premiers à prendre en charge l'élément vidéo avec la sortie de Safari 3.1 sur iOS et ordinateur de bureau en mars 2008. Mozilla Firefox a suivi en juin 2009. Google Chrome en octobre 2009. Internet Explorer a été un peu à la traîne ; il a publié IE9 et la prise en charge de l'élément vidéo en mars 2011.

En mars 2011, Opera, IE, Firefox, Chrome et Safari pour les ordinateurs de bureau prenaient en charge la lecture automatique, à l'exception de l'iOS d'Apple, qui limitait la fonctionnalité de lecture automatique. Cela s'explique par les problèmes de batterie et d'expérience utilisateur qui en découlent, notamment parce que les vidéos sur l'iPhone sont toujours lancées dans le lecteur natif au lieu d'être lues en ligne.

Entre 2008 et 2016, l'autonomie des batteries s'est considérablement améliorée et la vidéo sur le web est devenue prolifique. Face à l'essor de la vidéo, Apple a introduit dans iOS 10 la possibilité de lire automatiquement les médias sur les iPhones et les iPads. Toutefois, il y avait un problème : la vidéo devait être mise en sourdine ou ne pas comporter de piste audio. En outre, sur les iPhones, la vidéo doit pouvoir être lue en même temps que la page d'accueil. playsinline attribut.

Après qu'Apple a introduit la lecture automatique en sourdine, Google lui a emboîté le pas et l'a introduite dans Chrome pour Android 53. Dans les mois qui ont suivi, nous avons travaillé, avec les fournisseurs de SDK publicitaires, pour résoudre les problèmes liés au nouveau comportement de l'autoplay.

En juin 2017, Apple a annoncé qu'à partir de Safari 11, ils incluraient le même comportement autoplay sur le bureau, c'est-à-dire que l'autoplay non mis en sourdine serait rejeté. Avec cette annonce, nous avons pensé qu'il était préférable de prendre du recul et de réfléchir aux problèmes liés à l'autoplay, en particulier avec les publicités, pour voir si les problèmes provenaient tous du même endroit. Il était temps d'aborder l'autoplay comme un changement fondamental dans le fonctionnement du lecteur.

En septembre 2017, Google a annoncé qu'il mettait en œuvre des changements similaires dans Google Chrome : Unified Autoplay. Contrairement à Apple, Google va plus loin, en plus d'autoriser l'autoplay en sourdine, il va autoriser l'autoplay si l'utilisateur a interagi avec le site ou si un indice d'engagement des médias (MEI) a été franchi. L'indice d'engagement médiatique est attribué à chaque site web et permet de savoir dans quelle mesure l'utilisateur interagit avec la page et s'il visionne des vidéos ou écoute de l'audio. Ainsi, les sites dont la fonction principale est la vidéo, comme YouTube et Netflix, auraient un indice d'engagement médiatique élevé et ne seraient pas obligés d'attendre un geste de l'utilisateur pour lire une vidéo en sourdine. En revanche, un site que l'utilisateur n'a jamais visité auparavant ne sera pas en mesure de lire automatiquement une vidéo avec du son. Cette fonctionnalité sera disponible au début de l'année 2018, dans le cadre de Google Chrome 64.

LES PROBLÈMES ET CE QUE NOUS AVONS FAIT

Après un test approfondi, il s'est avéré qu'il n'y avait pas beaucoup de changements fondamentaux à apporter au lecteur. Le principal problème venait de la façon dont Video.js s'assurait que l'autoplay était ajouté à l'élément vidéo qu'il créait, et d'une incohérence avec la façon dont les navigateurs traitaient ses attributs et propriétés HTML.

Le premier problème était que lors de l'initialisation, Video.js mettait en place autoplay comme premier attribut de l'élément vidéo avant d'autres attributs tels que muted et playsinline ont été inclus. Alors que Chrome ré-exécutait ses vérifications de lecture automatique lorsque ces attributs étaient définis, ce n'était pas le cas de Safari et d'iOS. Nous nous sommes donc assurés que les attributs autoplay n'a été définie qu'après que la propriété muted et playsinline ont été fournies.

Le deuxième problème était l'incohérence des navigateurs en ce qui concerne les attributs et les propriétés HTML. Par exemple, vous pouvez créer un lecteur en mode autoplay et en sourdine en utilisant des attributs HTML comme suit :

<video autoplay muted playsinline>

Cela a fonctionné, mais si nous avons essayé de le faire de manière programmatique, comme ci-dessous, cela n'a pas fonctionné :

video.muted = true;
video.autoplay = true;

Cela n'a pas fonctionné parce que la vidéo n'était pas réellement mise en sourdine sur certains appareils iOS. Au lieu de cela, nous avons dû nous assurer de définir l'attribut et la propriété ; différentes sections d'appareils ne fonctionneraient pas avec un simple appel à setAttribute. Cela nous amène à la conclusion suivante :

video.muted = true;
 // muted is a boolean attribute, so, any value turns it on, using the name of the attribute is an often used convention
video.setAttribute(‘muted’, ‘muted’);
video.autoplay = true;
video.setAttribute(‘autoplay’, ‘autoplay’);

Les muted Le problème s'est poursuivi en cascade. Lorsque nous utilisions Video.js pour demander si la vidéo était en sourdine, nous obtenions parfois une mauvaise réponse. Video.js utilisait la valeur de la propriété pour vérifier si quelque chose était défini, mais dans certains cas, si la fonctionnalité était définie à l'aide de l'attribut, la propriété n'était pas définie pour refléter cette valeur. Ainsi, avec un code d'intégration comme le suivant :

<video muted>

Nous obtiendrons false lorsque nous avons demandé au joueur la valeur en sourdine :

player.muted();
// -> false

En interne, nous avons donc veillé à ce que chaque paramètre définisse à la fois l'attribut et la propriété, et à ce que chaque élément d'obtention prenne en compte les deux.

LE NOUVEL ÉTAT DE L'AUTOPLAY

Maintenant que ces changements sont disponibles, l'autoplay fonctionne parfaitement, n'est-ce pas ? Pas si vite.... En raison de la manière dont le rejet de la lecture automatique fonctionne lorsque les conditions requises ne sont pas remplies (c'est-à-dire que la lecture automatique ne fonctionne pas lorsque les conditions requises ne sont pas remplies), il n'est pas possible d'utiliser la lecture automatique. muted sur Safari 11, iOS, et Chrome pour Android ainsi que l'ajout de playsinline sur les iPhones), il est difficile de détecter si l'Autoplay a été rejeté ou si l'utilisateur a simplement appuyé sur play et l'a immédiatement fait suivre d'une pause. C'est un aspect que les SDK publicitaires doivent prendre en compte et que nous avons remarqué en tant qu'utilisateurs de Problèmes connus ci-dessous. Sur mobile, la plupart des SDK publicitaires ont déjà été mis à jour pour une prise en charge adéquate, mais il n'y a pas de prise en charge officielle de Safari 11 par les SDK publicitaires à l'heure où nous écrivons ces lignes.

LA PROMESSE DE JEU

Ces dernières années, les navigateurs ont été mis à jour pour renvoyer une promesse, une représentation d'un processus asynchrone et de sa valeur de retour, à partir de la fonction de lecture. La promesse permet de savoir si la lecture a réussi. Si la promesse est résolue, la lecture a réussi ; si la promesse est rejetée, la lecture a échoué. Auparavant, les deux principales raisons pour lesquelles la promesse a été rejetée sont que la vidéo n'a pas pu être lue et que l'utilisateur (ou un autre script) a mis la vidéo en pause peu de temps après la lecture, mais avant qu'elle n'ait pu être lue avec succès.

Nous disposons désormais d'un nouveau motif de rejet pour la promesse de lecture. Si vous utilisez une plateforme qui rejette la lecture automatique si la vidéo n'est pas en sourdine ou silencieuse (ou autorisée à être lue en ligne sur l'iPhone), la promesse sera rejetée.

La promesse de lecture est également le seul moyen (à l'heure actuelle) de savoir si la lecture automatique a été rejetée. C'est pourquoi les éditeurs de navigateurs recommandent de passer à la promesse de lecture. play() par rapport à la méthode autoplay attribut.

RECOMMANDATION

Avec les changements que nous avons apportés, la autoplay fonctionnera et continuera à le faire au mieux de ses capacités. Cependant, le passage à l'utilisation de l'attribut play() est recommandée.

Tout d'abord, les vendeurs de navigateurs eux-mêmes recommandent de l'utiliser plutôt que la norme autoplay et c'est généralement une bonne idée de suivre leurs conseils.

Deuxièmement, en utilisant le play() vous permet, en tant que développeur du lecteur, de savoir si la lecture automatique a réussi lorsque vous écoutez la promesse :

player.play().then(function() {
  // play succeeded!
})
.catch(function(error) {
  // play failed
  console.error(error.message);
});

Ensuite, si la lecture automatique est refusée, vous pouvez afficher un message ou proposer une alternative.

Troisièmement, si le play() est utilisée sur le lecteur, ce dernier peut stocker la promesse créée et l'utiliser en interne pour fournir une meilleure gestion des cas de figure qui surviennent lors du rejet de la lecture automatique.

En résumé, vous pouvez continuer à utiliser le autoplay et les choses devraient fonctionner, mais pour obtenir le meilleur soutien, vous devriez envisager de vous éloigner de l'attribut autoplay et utiliser l'attribut play() pour tirer parti de la promesse de jeu qu'elle renvoie.

L'AVENIR DE L'AUTOPLAY

Il semble que l'avenir de l'autoplay soit, à certains égards, la mort de l'autoplay. Apple adopte une politique assez stricte en matière de lecture automatique : elle n'autorise que la lecture automatique en sourdine, et exige un geste de l'utilisateur pour la lecture en sourdine. L'avantage est que les applications mobiles et de bureau sont cohérentes. Google adopte une politique légèrement plus souple : seule la lecture automatique en sourdine est autorisée, sauf si l'utilisateur a interagi avec le site web au cours de la session, ou s'il s'agit d'un site sur lequel l'utilisateur se rend souvent pour visionner des vidéos. L'Autoplay unifié de Google, cependant, est probablement ce que devrait être l'avenir de l'autoplay. Il impose des restrictions à l'autoplay pour aider l'utilisateur, tout en permettant aux sites web de continuer à fonctionner normalement. En fin de compte, j'espère que tous les navigateurs travailleront ensemble pour maintenir des restrictions cohérentes sur l'autoplay, libérant ainsi le développeur de l'obligation de cibler le comportement de l'autoplay en fonction du navigateur. J'espère que l'avenir de l'autoplay sera unifié.

PROBLÈMES CONNUS

• Les publicités silencieuses (qui ne comportent pas de piste audio) sont diffusées automatiquement sur les plateformes qui rejettent la diffusion automatique sans mise en sourdine. Cependant, lorsque la publicité se termine, le contenu ne reprend pas car le lecteur n'est pas en sourdine et aucune action de l'utilisateur n'a été effectuée. Ceci s'applique à IMA et FreeWheel.
• Si le lecteur est en sourdine, que la lecture automatique commence et que l'utilisateur rétablit le son de la publicité, le contenu ne reprendra pas parce qu'aucune action de l'utilisateur n'a été effectuée et que le lecteur n'est plus en sourdine.
• Dans FreeWheel, si la publicité contient de l'audio mais que la plateforme rejette la lecture automatique (par exemple : sur Safari 11), FreeWheel pensera qu'il y a un problème avec la publicité lorsque la lecture automatique est rejetée. Il attendra l'intervalle de temporisation de la publicité, puis reviendra au contenu, qui ne sera pas en lecture automatique parce que le lecteur n'est pas en sourdine et qu'aucune action de l'utilisateur n'a été effectuée.
• Si l'autoplay est rejeté mais que playsinline a été défini, le lecteur Brightcove masquera le gros bouton de lecture et affichera la barre de contrôle. Cependant, l'image de l'affiche devrait rester visible dans la plupart des cas. Cela est dû à la manière dont le rejet de la lecture automatique fonctionne lorsque l'on utilise la fonction autoplay attribut.