Lecteurs vidéo

Lecteurs vidéos pour site : lecteur HTML5 libre, extension WordPress ou lecteur de l’hébergeur

Un lecteur vidéo pour site est le programme JavaScript qui affiche la vidéo dans la page, avec ses boutons, sa barre de progression, le choix de la qualité et, sur un site qui vit de la publicité, les annonces. Il se distingue d’un logiciel de lecture comme VLC, installé sur l’ordinateur du visiteur. Le navigateur sait déjà lire une vidéo avec la balise video de HTML5, mais ses contrôles changent d’un navigateur à l’autre et ne gèrent ni la publicité ni les statistiques.

Trois familles se partagent le marché. Les lecteurs HTML5 open source se posent dans n’importe quelle page avec quelques lignes de code et ne coûtent rien en licence. Fluid Player en est un exemple sous licence MIT, conçu pour la publicité vidéo. Les extensions WordPress ajoutent une interface d’administration, des codes courts et souvent la connexion à plusieurs hébergeurs vidéo. Les lecteurs fournis par un service de diffusion vidéo arrivent avec le stockage et l’encodage, et ne lisent que ce que ce service héberge.

Un lecteur propriétaire se paie en général par domaine, avec un an de mises à jour, et retire sa marque de l’écran contre la licence. Un lecteur open source ne coûte rien et ne promet aucun support : l’aide passe par le dépôt public, et une panne un samedi soir se règle avec votre développeur. Le choix dépend du nombre de sites, du besoin de support et de la plateforme du site.

Un lecteur ne stocke rien et n’encode rien. Il lit des fichiers déjà préparés, posés sur un serveur ou un réseau de diffusion, et la bande passante reste facturée par l’hébergeur. Sur un tube ou un site de vidéos, le lecteur et l’hébergement se choisissent donc ensemble.

Formats et lecture : MP4, HLS, qualité adaptative et poids du script

Le MP4 encodé en H.264 est le format que tous les navigateurs lisent, sur ordinateur comme sur téléphone. Le HEVC compresse mieux mais reste inégalement pris en charge par les navigateurs, et l’AV1, plus efficace encore, demande un encodage plus lent et des appareils récents pour être décodé sans peine. Un catalogue adulte encodé en H.264, avec une seconde version en AV1 pour les navigateurs qui la lisent, couvre tout le monde.

Le HLS découpe la vidéo en petits segments disponibles en plusieurs qualités, décrits par une liste de lecture. Le lecteur mesure le débit du visiteur et passe d’une qualité à l’autre sans couper la lecture : c’est la qualité adaptative. Safari lit le HLS nativement, et sur les autres navigateurs le lecteur s’appuie souvent sur une bibliothèque JavaScript. Le DASH rend le même service avec un autre format de liste. Un lecteur qui ne lit que le MP4 envoie le fichier entier en une seule qualité, trop lourde sur une connexion mobile.

Certains lecteurs lisent aussi les vidéos intégrées depuis YouTube, Vimeo ou d’autres plateformes, et réunissent ces sources sous une seule interface. D’autres refusent toute source intégrée par cadre et n’acceptent qu’un fichier ou une adresse de flux. La question se pose avant l’achat, selon l’endroit où vit le catalogue.

Le poids du script compte pour le référencement. Un lecteur chargé sur toutes les pages, vidéo ou non, ralentit l’affichage et dégrade les signaux de vitesse que Google mesure. La bonne pose charge le script sur les seules pages qui lisent une vidéo, affiche une image d’attente et ne télécharge la vidéo qu’au clic. Servir le script depuis le CDN de l’éditeur, sur une adresse qui suit toujours la dernière version, fait dépendre chaque page d’un domaine tiers et publie les mises à jour sans votre accord. Un fichier servi depuis votre propre domaine, avec une version figée, évite les deux.

L’interface d’un lecteur est souvent en anglais. Certains traduisent leurs libellés par un réglage de langue, d’autres demandent de réécrire chaque libellé dans la configuration.

Lecteur vidéo VAST : emplacements publicitaires, VPAID et balises de repli

VAST, pour Video Ad Serving Template, est la norme de l’IAB qui décrit comment une régie envoie une publicité vidéo à un lecteur. Le lecteur appelle l’adresse d’une balise VAST, la régie répond par un fichier XML qui contient la vidéo publicitaire, sa durée, l’adresse du clic et les adresses de suivi. Le lecteur joue l’annonce, puis signale à la régie chaque événement : impression, démarrage, premier quart, moitié, troisième quart, fin et clic. C’est sur ces signaux que l’annonceur paie et que l’éditeur est payé.

Un lecteur vidéo VAST place ces annonces à des moments précis. La publicité avant la vidéo est la plus répandue. La publicité pendant la vidéo se déclenche à l’instant choisi, et celle d’après la vidéo sert l’inventaire restant. Sur un tube, l’emplacement déclenché quand le visiteur met en pause affiche une bannière pendant qu’il regarde encore l’écran. Tous les lecteurs ne proposent pas tous les emplacements, et certains vendent la publicité comme une extension à part, facturée chaque année et par domaine.

Le VPAID ajoutait des annonces interactives, exécutées en JavaScript dans le lecteur. L’IAB l’a déclaré obsolète au profit de SIMID pour l’interactivité et d’Open Measurement pour la vérification, mais une partie des régies du secteur adulte en sert encore. Un lecteur qui accepte le VPAID le désactive parfois par défaut, et un inventaire VPAID sans ce réglage donne un taux de remplissage anormalement bas. Le VMAP, enfin, décrit dans un seul fichier le calendrier des pauses publicitaires d’une vidéo.

Les balises de repli permettent au lecteur d’essayer une deuxième régie quand la première ne renvoie rien, ce qui sauve l’impression. Le chaînage des balises, quand une régie en appelle une autre, se limite par un nombre de redirections à régler soi-même sur une chaîne d’échange longue. Le délai d’attente de la réponse publicitaire se raccourcit sur mobile. Les erreurs les plus courantes viennent d’une réponse XML servie avec un mauvais type de contenu et des en-têtes d’accès entre domaines absents côté régie. Fluid Player, par exemple, écarte une réponse qui n’est pas servie comme du XML et laisse l’emplacement vide.

Protéger ses vidéos : jetons d’adresse, filigrane, téléchargement et hébergement

Un catalogue de vidéos adultes se copie et se revend. La première protection est le jeton d’adresse, appelé aussi lien signé : le réseau de diffusion n’accepte l’adresse d’un fichier que si elle porte une signature et une date d’expiration calculées par votre site. Une adresse copiée ailleurs cesse de fonctionner à l’expiration, ce qui coupe le vol de bande passante par des sites qui lisent vos fichiers depuis leurs propres pages.

Le filigrane incruste votre marque ou l’identifiant du membre dans l’image. Il signe la vidéo, et un filigrane par membre désigne le compte qui a fait fuiter un fichier. Le blocage du téléchargement retire le bouton d’enregistrement et sert la vidéo en segments plutôt qu’en fichier entier. Aucune de ces mesures n’arrête une capture d’écran. Seul un DRM, Widevine chez Google ou FairPlay chez Apple, chiffre la vidéo jusqu’à l’écran, au prix d’un serveur de licences et d’une intégration plus lourde, réservée aux catalogues premium.

YouTube interdit la pornographie et Vimeo le contenu sexuellement explicite, donc une vidéo adulte intégrée depuis ces plateformes finit retirée et laisse un lecteur vide sur votre page. Un catalogue adulte vit chez un hébergeur vidéo ou un réseau de diffusion qui accepte l’activité par écrit.

FV Player illustre l’approche qui sépare le lecteur de l’hébergement. L’extension WordPress pilote des sources très différentes, de Bunny Stream à Amazon S3, depuis la même interface, et sa version professionnelle ajoute le filigrane et les jetons d’adresse. Un catalogue peut alors changer d’hébergeur sans changer de lecteur ni retoucher ses pages.