Quel lecteur vidéo la plupart des éditeurs utilisent-ils ?

Publié: 2018-08-03
lecteur vidéo de l'éditeur

Ce message a été mis à jour pour la dernière fois le 6 juillet 2022

Dans cet article de blog détaillé, nous examinerons de plus près les différents lecteurs vidéo disponibles pour les éditeurs sur le marché, comparerons leurs fonctionnalités (tableau de comparaison inclus), examinerons la diffusion d'annonces vidéo, les différents blocs d'annonces vidéo et même les pièges de diffusion d'annonces.

Si vous travaillez actuellement avec Google Ad Exchange, nous avons également inclus une section présentant les meilleures pratiques pour la diffusion d'annonces vidéo. Commençons!

JW joueur

Le lecteur JW est l'un des lecteurs Web les plus utilisés qui prend en charge un large éventail de formats (HLS, VAST 3.0, VPAID 2.0) et s'intègre à la plupart des principaux réseaux publicitaires.

En savoir plus sur VPAID vs VAST ici.

Ce lecteur vidéo prend en charge la diffusion d'annonces multiplateforme avec des fonctionnalités avancées telles que la prise en charge de la diffusion en direct, le sous-titrage codé et est à l'épreuve du temps avec une prise en charge native de la lecture de vidéos 360 et VR.

Il fournit des SDK natifs pour Android et iOS pour les implémentations intégrées à l'application. C'est également un fournisseur de confiance pour la diffusion d'annonces via la suite DoubleClick de Google et un partenaire d'édition certifié par Google.

Les clients du lecteur JW incluent Amazon, Vice, Univision, Fox et bien d'autres. Le lecteur JW, en collaboration avec SpotX, a récemment introduit l'enchère d'en-tête native (vidéo) pour la monétisation du contenu diffusé à l'aide du lecteur JW.

Des démos et des exemples d'implémentations de lecteur peuvent être trouvés ici, pour avoir une idée des capacités du lecteur et des aspects fonctionnels.

Fonctionnalités disponibles dans la version 8 de JW player :

  • Prise en charge du streaming multiprotocole : HLS, DASH (Adobe RTMP non pris en charge)
  • Prise en charge de la lecture vidéo 4k en mode HTML5
  • Prise en charge de la lecture vidéo 60FPS
  • Prise en charge des listes de lecture au format RSS/XML et JSON
  • Prise en charge de VAST 4.0, VPAID 2.0, VMAP
  • Intégration avec les principaux SDK de serveurs publicitaires : Google IMA SDK et FreeWheel Ad Manager SDK
  • Podding, cascade/de secours, planification des annonces

Le prix de ce lecteur vidéo commence à 5 $ par mois (facturé annuellement). La tarification personnalisée pour la monétisation via la diffusion d'annonces en fonction du trafic est supérieure à 50 $ par mois. L'intégration du SDK IMA n'est pas disponible pour les offres d'entrée (5 $ pm) et de niveau intermédiaire (50 $ pm).

Ooyala

La dernière version du lecteur vidéo Ooyala se vante d'une longue liste de fonctionnalités, qui répondront à tous vos besoins de publication et de monétisation vidéo. Leur conception d'interface utilisateur suit les directives de Google Material UX et est hautement personnalisable pour refléter votre image de marque.

Certaines des fonctionnalités disponibles dans Ooyala player 4.0 sont :

  • Commandes de lecteur sensibles au contenu
  • Sous-titres codés (DFXP)
  • Possibilité de partager du contenu sur les médias sociaux
  • Moteur de recommandation
  • Formats pris en charge : VAST 3.0, VPAID 2.0, VMAP 1.0, HLS et MP4, OSMF Flash HDS, Akamai packagé HDS et DASH et HLS
  • Recherche arrière sur la lecture de contenu en direct
  • Gestion des pods et des points de repère
  • SDK Android et iOS
  • Intégration de Google IMA via un plugin.
  • Prise en charge de plusieurs plates-formes d'analyse (Adobe, comScore, Nielsen, Google Analytics, etc.)
  • Offre de monétisation native via Ooyala pulse.
  • A plusieurs intégrations de réseaux publicitaires prêtes à l'emploi.

Tarification : Voir la structure de tarification client.

Brightcove

Les offres de publication et de monétisation vidéo de Brightcove s'adressent aux grands éditeurs avec un trafic élevé et d'énormes catalogues de contenu. La suite de produits Brightcove répond à toutes les exigences en matière de publication de contenu vidéo, de la lecture de contenu de base à l'hébergement de contenu, l'ingestion de contenu, les analyses avancées et les outils marketing.

Cela aidera à réduire le nombre de pièces mobiles, éliminant ainsi tout problème de compatibilité et augmentant la fiabilité. Certaines des plus grandes marques telles que Ford, BBC, Oracle, Condenast et GoDaddy utilisent la suite Brightcove pour leurs besoins de publication.

Les fonctionnalités incluent:

  • Intégration Google IMA, OnceUX, SpotX et FreeWheel
  • Prise en charge de la lecture vidéo 360
  • Disponibilité de la protection du contenu DRM (format Widevine Media)
  • Prise en charge de la diffusion multiformat en direct (HLS, DASH, FairPlay Streaming d'Apple)
  • SDK natifs iOS et Android pour les implémentations dans l'application
  • Prise en charge native de tvOS (Apple TV)
  • Prise en charge d'Airplay pour le contenu non monétisé avec le SDK iOS natif
  • Intégration de Native Analytics et d'Adobe Analytics
  • Prise en charge de plusieurs pistes audio sur les SDK natifs iOS et Android
  • Prise en charge de la diffusion d'annonces côté serveur

Tarification : Seuls les tarifs personnalisés sont disponibles.

Vidéo.js

Contrairement aux autres lecteurs de cette liste, Video.js est une offre open source d'un lecteur vidéo basé sur HTML5 avec prise en charge de la monétisation vidéo. Le sponsor principal du projet est Brightcove, dont le lecteur vidéo est également construit sur le framework video.JS.

Le projet a une communauté très utile avec un large éventail de plugins pour l'intégration de tiers et des services supplémentaires. Il peut être personnalisé selon les besoins (ajustement HTML, CSS et Javascript requis) ou peut être utilisé prêt à l'emploi.

Consultez le guide ici et le plug-in disponible pour prendre en charge l'intégration du SDK IMA.

Certains clients bien connus incluent Instagram, Twitter, Microsoft, Github, IGN, The Guardian et bien d'autres.

Les fonctionnalités prises en charge par les plugins sont :

  • Curation de playlist personnalisée
  • Prise en charge d'Airplay et de Chromecast (en fonction du navigateur et de l'appareil)
  • Intégration Google Analytics
  • Prise en charge de la diffusion en direct (HLS et DASH)
  • Rapport d'erreur personnalisé
  • Lecture de contenu DRM (Apple Fairplay)
  • Intégration du SDK IMA
  • Intégration CDN Ooyala
  • Prise en charge des vidéos 360, VR et panoramiques
  • Moteur de recommandation de contenu
  • Intégration du partage social

Prix ​​: Gratuit

Matrice de comparaison des fonctionnalités

Joueur JW Ooyala Brightcove Vidéo.JS
HTML5
Analytique native

CDN

Personnalisable
Prise en charge de plusieurs débits
Soutien

Contracter

Livraison sécurisée
Prise en charge des API
Gratuit

Informations générales sur les lecteurs vidéo

Traditionnellement, les lecteurs vidéo n'avaient qu'un seul travail à faire, lire le contenu avec uniquement des commandes de navigation de base. Les joueurs avaient une liste de formats vidéo qu'ils pouvaient rendre, et c'est à peu près tout.

Aujourd'hui, les lecteurs vidéo ont évolué pour répondre à une demande toujours croissante et à de nombreuses fonctionnalités en plus de la simple lecture d'un élément vidéo. Avec l'adoption de HTML5 à l'échelle de l'industrie, les lecteurs autrefois largement utilisés, basés sur le framework flash, connaissent un déclin rapide.

Il existe plusieurs raisons pour lesquelles vous devez passer à un lecteur HTML5 plutôt qu'à des lecteurs flash, dont les deux principaux facteurs moteurs sont la vitesse et la sécurité.

Cependant, si vous cherchez à diffuser du contenu flash, plusieurs options s'offrent à vous, même à l'heure actuelle, de nombreux lecteurs vidéo prennent en charge les fichiers vidéo au format flash.

Dans le contexte de la diffusion d'annonces, Flash n'est plus pris en charge par tous les principaux navigateurs Web.

Comment un lecteur vidéo demande-t-il et diffuse-t-il une annonce ?

Un lecteur nécessite d'abord la mise en œuvre d'un tag d'emplacement publicitaire vidéo, qui sera déclenché aux points de repère où l'annonce est censée être diffusée.

Il existe trois positions principales où les annonces vidéo sont diffusées :

  1. Pre-roll : La publicité lorsqu'elle est lue/rendue avant que la lecture du contenu ne soit lancée.
  2. Mid-roll : Toute position entre le début et la fin du contenu est considérée comme mid-roll.
  3. Post-roll : l'annonce lorsqu'elle est lue/affichée à la fin/à la fin du contenu.

Lorsque la demande est adressée au serveur publicitaire, la sélection d'annonces/RTB a lieu et l'annonce gagnante est renvoyée dans une réponse XML VAST avec tous les éléments multimédias associés et les pings d'événements de suivi.

(VAST signifie "Digital Video Ad Serving Template", qui est une spécification développée par l'IAB pour avoir une réponse XML commune de tous les serveurs publicitaires. Auparavant, chaque serveur publicitaire et lecteur nécessitait une réponse dans différents formats, ce qui n'était pas efficace)

Une fois que le lecteur reçoit la réponse XML VAST du serveur publicitaire, il récupère les fichiers de ressources créatives et les affiche aux points de repère prédéfinis avant/pendant/après la lecture du contenu.

Le lecteur déclenchera également les événements de suivi renvoyés dans le XML VAST aux déclencheurs d'événements associés. En cas d'échec/problème, une erreur VAST est déclenchée et enregistrée dans le serveur publicitaire pour une analyse future.

Il existe trois manières différentes d'héberger des éléments multimédias en cas de diffusion d'annonces vidéo :

Serveur publicitaire hébergé

Les éléments multimédias sont hébergés au sein du serveur publicitaire utilisé pour diffuser les publicités. L'avantage de cette approche est qu'une URL d'hébergement directe des fichiers multimédias est renvoyée dans la réponse VAST. Cela réduit considérablement la latence et le taux d'échec de la récupération des fichiers multimédias par le lecteur.

Hébergé en externe

Les ressources multimédias sont hébergées sur un CDN tiers et l'URL d'hébergement est renvoyée dans le XML VAST. Cela peut augmenter la latence lors de la récupération des fichiers multimédias, en fonction du temps de réponse du CDN.

Balises de redirection

Il s'agit du type d'hébergement d'éléments multimédias le plus couramment utilisé dans lequel une balise de redirection est gérée dans le serveur publicitaire et la même balise est renvoyée dans le XML VAST. Le lecteur déclenche alors la balise de redirection qui récupère ensuite les fichiers multimédias dans une seconde réponse VAST.

Cette option est généralement utilisée dans les implémentations où une autre enchère est effectuée dans un deuxième serveur publicitaire, et les fichiers multimédias/publicité peuvent être différents pour chaque demande.

Types de blocs d'annonces vidéo/mise en œuvre/diffusion

InStream

Dans ce type de diffusion d'annonces vidéo, les annonces vidéo sont diffusées dans un lecteur/une application. Dans ce cas, l'objectif principal du public cible sera le contenu diffusé via le lecteur vidéo en particulier. Trois formats d'annonces sont généralement diffusés dans cet environnement :

  1. Linéaire : Ce sont généralement des publicités au format vidéo et sont diffusées en interrompant la lecture du contenu.Il existe trois positions/chronologies où les publicités linéaires peuvent être diffusées, avant le contenu (preroll), pendant la lecture du contenu (midroll) et après la fin de la lecture du contenu (post-roll).
  2. Non linéaire : il s'agit généralement d'images statiques ou de formats compatibles rich media, qui n'interrompent/pause pas la lecture du contenu.Ils sont généralement de petite taille et sont superposés dans la section inférieure/inférieure du lecteur vidéo.
  3. Companion : il s'agit d'annonces graphiques générales diffusées avec les annonces linéaires à proximité du lecteur pour offrir une expérience plus immersive et également pour offrir aux utilisateurs la possibilité d'agir en rapport avec l'annonce vidéo diffusée plus tôt, même après sa fin (utile au cas où de courtes annonces vidéo).

Hors flux :

Dans ce type d'implémentation, il n'y a pas de contenu focal sur un lecteur vidéo. Les publicités vidéo sont diffusées conformément au contenu affiché sur la page.

Il existe plusieurs façons ou mises en œuvre pour diffuser des publicités vidéo outstream. Le plus courant est la vidéo In-banner, dans laquelle une publicité vidéo est rendue dans un bloc d'annonces graphiques.

Les autres implémentations couramment utilisées sont la vidéo interstitielle, dans la vidéo de la page (générant un lecteur).

Points de défaillance courants spécifiques à la diffusion d'annonces vidéo :

Délai d'attente : Chaque lecteur a la possibilité de définir un délai d'attente prédéfini qui, lorsqu'il est atteint, le contenu commencera la lecture.Cela garantit que le contenu/lecture n'est pas bloqué en cas de latence/retard dans la récupération des fichiers multimédias, ce qui offre une expérience utilisateur optimale.

Réponse VAST vide : est une possibilité en cas de balises de redirection, si l'URL de redirection n'a pas récupéré d'annonce, c'est-à-dire que la demande adressée au serveur publicitaire tiers n'a pas été satisfaite.

Redirections multiples : certains annonceurs/fournisseurs de créations renvoient une autre balise de redirection pour la première balise de redirection gérée.Cela peut être dû à un chaînage en guirlande et à des boucles infinies ou à un retard dans chacune des réponses de redirection.

Pour éviter cela, les lecteurs vidéo ont une limite de redirection qui, lorsqu'elle est atteinte, déclenche une erreur VAST. S'il n'y a pas de limite définie, le prochain point de défaillance sera d'atteindre le délai d'attente.

Format d'élément multimédia non pris en charge : si le lecteur vidéo ne parvient pas à rendre les fichiers multimédias renvoyés dans le XML VAST, cette erreur se déclenchera.Cette erreur n'est pas assez courante car plusieurs fichiers multimédias seront renvoyés, chacun d'une taille, d'un débit binaire, d'un encodage, etc. différents. Le lecteur peut choisir celui qui convient le mieux à l'environnement dans lequel l'annonce doit être rendue.

Vous perdez des revenus lorsqu'une annonce ne parvient pas à être lue et déclenche une erreur ?

Que se passe-t-il si les balises transmises à votre serveur publicitaire ne parviennent pas à récupérer une annonce ?

L'opportunité de monétiser cette demande/impression spécifique sera perdue. Pour résoudre ce problème, la cascade/repli entre en jeu. Lorsqu'un remplacement est activé dans votre serveur publicitaire, il enverra un nombre prédéfini d'annonces gagnantes dans la réponse XML VAST.

Si le premier échoue pour une raison quelconque, le joueur passera à l'annonce suivante de la liste. Ce processus se poursuit jusqu'à ce que le joueur puisse diffuser une publicité.

La question évidente dans ce scénario est la suivante : cela entraînera-t-il un retard/augmentera-t-il le chargement des annonces et les temps de rendu ?

La surcharge, dans ce cas, est très négligeable et le joueur parcourt le repli en quelques millisecondes.

Un point de défaillance possible même si le repli est configuré correctement :

Le seul point d'échec, dans ce cas, serait si le serveur tiers ne renvoie pas de réponse ou renvoie une réponse vide faute d'annonce.

Dans ce cas, le lecteur vidéo attendra le délai défini qui, une fois atteint, lancera la lecture du contenu. Les annonces de repli n'auront même pas été essayées.

Comment résoudre le problème du déclenchement du délai d'expiration avant que toutes les annonces de la solution de remplacement n'aient été essayées ?

Il y a deux approches à cela :

  1. Testez la latence dans la réponse du serveur publicitaire tiers et évitez d'utiliser des serveurs publicitaires/tags qui prennent beaucoup de temps pour renvoyer une réponse, lorsqu'il n'y a pas d'enchères/annonces gagnantes.
  2. Définissez le délai d'expiration par défaut du lecteur sur une durée plus élevée, en fonction des temps de réponse moyens du serveur publicitaire des balises transmises à votre serveur publicitaire ou à partir des partenaires de demande.

Conseils et bonnes pratiques pour diffuser des annonces vidéo via Google Ad Exchange (AdX)

  • Pour pouvoir diffuser des annonces via les plates-formes programmatiques de Google, il est nécessaire que le lecteur vidéo soit intégré au SDK IMA sans lequel il peut y avoir des incohérences et des divergences dans les rapports.
  • Si l'intégration du SDK IMA n'est pas possible, Google propose une approche alternative pour répondre à la demande AdX via l'utilisation de balises d'adaptateur. Une balise d'adaptateur, lorsqu'elle est diffusée sur un lecteur intégré non IMA, émule la fonctionnalité du SDK IMA pour cette demande spécifique et fournit tous les appels de fonction et toutes les fonctionnalités d'un lecteur intégré au SDK IMA. Les tags d'adaptateur peuvent être générés en sélectionnant la technologie comme "Adaptateur IMA" lors de la génération des tags vidéo dans Google AdX.
  • Évitez de diffuser des balises d'adaptateur IMA sur des lecteurs intégrés au SDK IMA, car cette approche n'est pas recommandée et la diffusion de l'annonce peut échouer, ce qui déclenche une erreur VAST 901.
  • Garantissez la conformité avec les règles spécifiques aux vidéos AdX répertoriées ici, en plus des règles du programme AdX.
  • À partir d'avril 2018, la nouvelle mise à jour de la politique de Chrome impose une restriction sur les publicités vidéo en lecture automatique. Cela n'aura d'impact que si vous diffusez des annonces vidéo en lecture automatique avec du son et ne s'applique pas aux annonces vidéo en lecture automatique qui sont désactivées par défaut.
  • Les annonces vidéo en lecture automatique non désactivées ne peuvent être diffusées que si l'un des critères suivants est rempli :
    • Avant que l'annonce ne lance la lecture, l'utilisateur a interagi sur votre site Web.
    • Le MEI (Media Engagement Index) de l'utilisateur est supérieur à un seuil prédéfini (Uniquement pour desktop). Le calcul de l'indice MEI est détaillé dans cet article.
    • Sur une plate-forme mobile, si l'utilisateur a épinglé/mis en signet le site sur l'écran d'accueil de l'Appareil.

Conclusion

Bien que nous ayons présenté toutes les informations pour vous dans cet article, les lecteurs vidéo et la diffusion d'annonces vidéo peuvent être compliqués. Pour obtenir de l'aide pour choisir le bon pour votre entreprise d'édition et pour le mettre en œuvre correctement, créez un compte professionnel sur MonetizeMore dès aujourd'hui !


Questions supplémentaires

Qu'est-ce que le lecteur JW ?

Le lecteur JW est l'un des lecteurs vidéo Web les plus utilisés qui prend en charge un large éventail de formats et s'intègre à la plupart des réseaux publicitaires. En savoir plus sur ses fonctionnalités dans notre article de blog.

Qu'est-ce que le lecteur Brightcove ?

Le lecteur Brightcove est conçu pour les grands éditeurs avec un trafic élevé et de gros catalogues de contenu. Le lecteur offre un large éventail de fonctionnalités et répond à toutes les exigences en matière de publication de contenu vidéo.

Qu'est-ce que le joueur Ooyala ?

Le lecteur vidéo Ooyala est un lecteur doté d'une longue liste de fonctionnalités répondant à tous les besoins de monétisation vidéo des éditeurs sur plusieurs appareils. Nous discutons davantage du lecteur vidéo dans notre article de blog.

Qu'est-ce que video.js ?

Video.js est un lecteur vidéo open source que les éditeurs peuvent utiliser pour la monétisation vidéo. Brightcove est le sponsor principal du projet. Leur lecteur vidéo est construit sur le framework video.JS.