SCTE-104/35 : un regard sur l’insertion publicitaire dans un monde OTT

L’insertion publicitaire occupe une place importante dans la distribution de vidéos en raison de l’aspect monétisation. Avec l’OTT, la Graal de la publicité personnalisée est enfin à portée de main : il est techniquement possible d’envoyer des publicités individuelles et ciblées à chaque utilisateur. De tels systèmes sont en partie basés sur des workflows traditionnels qui mettent en œuvre les normes SCTE-104 et SCTE-35. Cet article donne un aperçu de ces systèmes, en expliquant comment un workflow d’insertion publicitaire traditionnel peut être transposé dans un système OTT. Nous montrerons également d’autres utilisations des infrastructures d’insertion publicitaire (pour la délimitation du programme notamment) et aborderons l’importance de la synchronisation à l’image.

Côté diffuseur :

Le workflow d’insertion publicitaire se présente en général de cette manière :

  • Prenons un flux contenant des programmes et des publicités, typiquement un flux s’adressant à un réseau national. Certaines publicités sont d’une importance nationale pour l’annonceur tandis que d’autres semblent de moindre priorité, et pourraient être remplacées par des annonces locales.
  • Le système d’automation et de playout insère des marques dans le signal bande de base pour délimiter les publicités. Ces marqueurs sont définis par la norme SCTE-104.
  • Un encodeur convertit la vidéo bande de base en un bitstream compressé. Les marqueurs de bande de base sont alors mappés dans le flux compressé pour être transmis avec le contenu.
  • Quelque part dans la chaine de réception, avant que la vidéo ne soit distribuée, de nouvelles annonces sont insérées aux endroits définis par les marqueurs. C’est là que les systèmes OTT prennent le relai.

Figure 1 : Workflow côté diffuseur

Comme le montre la figure 1, le flux SDI traverse un inserteur en charge de l’ajout des marqueurs SCTE-104 dans les VANC selon la norme SMPTE-2010. L’inserteur est contrôlé par le système d’automation/playout, l’interface entre l’automation et l’inserteur est également définie par la norme SCTE-104. La sortie de l’inserteur est un signal SDI « enrichi » des marqueurs SCTE-104. Un encodeur convertit ensuite ce signal SDI en un flux compressé, avec conversion et insertion des marqueurs SCTE-104 en paquets SCTE-35. Le système d’automation peut aussi contrôler directement l’encodeur à travers le protocole réseau SCTE-104, bien que ce scénario ne soit pas standardisé.

Côté broadcaster, le résultat final est un bitstream compressé auquel s’ajoute les marqueurs SCTE-35 : ce flux cible viendra nourrir le workflow d’insertion OTT.

Le système de distribution traditionnel

La figure 2 montre un système de distribution de publicité traditionnel. La station locale reçoit le flux du broadcaster enrichi des marqueurs SCTE-35. Ce flux passe à travers un splicer, lequel lit les marqueurs, sollicite un serveur de qui utilise le protocole SCTE-30 pour recevoir une publicité de substitution qu’il insèrera au bon endroit dans le flux. La sortie du splicer est un nouveau Transport Stream dont la publicité nationale de faible priorité a été remplacée par une publicité locale. Le splicer en profite pour supprimer les marqueurs du nouveau flux TS, rendant le travail des Ad Blocker bien plus difficile. Le client n’a plus aucun moyen pour mettre en place un système qui pourrait scanner le flux et retrouver les marqueurs pour en retirer la publicité. Les systèmes de gestion du back office interagissent aussi avec le serveur d’insertion de publicités pour en faciliter la sélection, et enregistrer cette diffusion à des fins de suivi.

Figure 2 : Système de distribution traditionnel

Le système traditionnel a une approche « taille unique ». On obtient un flux linéaire complètement conforme et décodable par n’importe quel set-top box, sans fonctionnalités particulières. Tous les récepteurs affichent la même publicité, que le flux soit distribué par câble ou par voie terrestre.

Le standard SCTE-138 propose une alternative au système traditionnel, permettant d’adresser une petite quantité de publicités personnalisées et ciblées. Dans cette approche, le flux contient le programme principal auquel s’ajoute un certain nombre d’annonces additionnelles, encapsulées dans le même service que le programme principal mais avec des PID audio/vidéo distincts. Les marqueurs résiduels sont décodés par les set-top box, lesquelles vont alors puiser dans le petit nombre d’annonces disponibles et décider de la publicité à jouer (ou non, la publicité du programme principal prenant alors le relai). Ce système n’autorise qu’un nombre très limité de ciblages publicitaires.

Opérations de base du système OTT

L’expression Over-The-Top (OTT) fait référence à la distribution de contenus par Internet (c’est à dire au somment – top- des services réseau du fournisseur). La figure 3 montre le principe de base de l’OTT.

Figure 3 : Opération de base OTT

Bien qu’il existe plusieurs protocoles OTT, ils fonctionnent tous de la manière suivante :

  • Le flux en provenance du broadcaster, éventuellement enrichi des marqueurs STCE-35, passe par un service de transcodage ;
  • Le transcodeur produit plusieurs versions du flux, avec des résolutions et débits différents : ce sont les « profils » ;
  • Chaque profil est subdivisé en fichiers appelés « segments ». Chaque segment peut être décodé individuellement. En d’autres termes, un segment n’a pas besoin des données du segment précédent pour commencer à être décodé jusqu’à sa dernière image, sans nul besoin des données du segment suivant. Dans le cas d’un flux H.264, le segment démarre sur une image IDR (Intantaneous Decodig Refresh) et son dernier GOP (Group Of pictures) est fermé ;
  • Les segments correspondent à quelques secondes de vidéo (de 2 à 30 secondes, traditionnellement entre 5 et 10) qui sont déposés sur un serveur web ;
  • Un « manifest » est généré et placé sur le serveur web. Celui-ci liste les segments et il est piloté par un manifest de plus haut niveau qui répertorie les profils disponibles avec leurs caractéristiques (à la façon d’une liste de lecture). Les manifests sont des fichiers XML/texte dont le format varie selon les normes ;
  • Les players interrogent le manifest de niveau supérieur pour prendre connaissance des profils disponibles. Ils choisissent un profil en fonction de la bande passante disponible à l’instant de la requête, puis parcourent le manifest correspondant et initient la lecture en décodant les segments. En cours de lecture et en fonction des conditions du réseau, le player pourra basculer sur un profil inférieur ou supérieur. Sur un flux OTT de streaming, les manifests peuvent être mis à jour fréquemment (modification des profils, de la taille des segments, des métadonnées…).
  • Ce principe de fonctionnement a été élaboré par Apple avec son protocole HTTP Live Streaming. La philosophie de départ a ensuite été déclinée sous différentes formes (HLS, HDS, MPEG-DASH…)

Figure 4 : Exemple de lecture OTT

D’un point de vue insertion publicitaire, l’OTT présente les caractéristiques requises :

  • L’OTT est unicast : chaque player établit sa propre connexion au serveur. Si les interfaces du client sont appropriées, les annonces publicitaires peuvent être personnalisées pour chaque utilisateur. Grâce à ce lien client/serveur, les méthodologies d’identification et de tracking traditionnelles du Web peuvent servir de base au scénario d’insertion de publicités.
  • L’OTT se nourrit d’une suite de fragments courts. Puisque chaque segment est décodable individuellement, le splicing n’en est que plus aisé : le player est à même de basculer sur un nouveau contenu en fin de segment. Cette bascule peut être pilotée côté serveur (sans action autonome du player), via la mise à jour du manifest pour qu’il pointe vers une publicité.

Les flux OTT peuvent embarquer les marqueurs originaux SCTE-35 générés par le diffuseur. Le workflow se présente comme suit :

  • En général, l’image identifiée par le marqueur SCTE-35 n’est pas alignée avec une limite de segment. Le transcodeur qui crée les profils doit s’assurer qu’un nouveau segment démarre précisément sur cette image identifiée, quitte à clore le segment précédent plus « tôt ».
  • Le marqueur SCTE-35 est ajouté au manifest. En fonction du parfum d’OTT à l’œuvre, le procédé peut être différent :
  1. STCE-67 détaille les bonnes pratiques pour les protocoles HLS, MPEG-DASH et HDS. Certaines de ces recommandations sont fournies par SCTE-35 2016.
  2. La mise en oeuvre pour DASH est détaillée dans le SCTE-214 part 1 et part 3.

La figure 4 montre un exemple de flux OTT avec insertion publicitaire.

Système de contrôle d’insertion en OTT

Dans certaines situations, un contrôle supplémentaire est requis pour les raisons suivantes :

  • Des contraintes géographiques pour lesquelles un contenu pourra être présenté ou non ;
  • Des contraintes temporelles inhérentes aux possibilités ou non de présenter le contenu (durée des droits…) ;
  • Des différences d’interprétation des messages SCTE-35 par les différents fournisseurs d’accès, nécessitant une traduction en amont ;
  • Des choix sur l’approche de l’insertion de publicités, entre la vision serveur (manipulation des manifest) et client (gestion de l’insertion côté player) ;

Cette fonctionnalité est gérée par l’API ESAM (CableLabs Event Signaling and Management). L’API définit un ensemble d’interfaces entre un transcodeur, un gestionnaire de segments et un outil de contrôle. Elle offre les fonctionnalités suivantes :

Conditionnement du signal de marquage :

  • Validité, timestamp de début/fin, données additionnelles à insérer ;
  • Restrictions de contenus (blackouts) ;

Conditionnement du Manifest :

  • Recommandations sur la façon de manipuler le manifest HLS ;

Le standard propose une architecture HTTP RESTful avec des payload au format XML ou JSON. la figure 5 montre une vue d’ensemble du système ESAM.

Figure 5 : ESAM

Une autre norme destinée à un sous-ensemble de cette fonctionnalité est le SCTE-224, l’ENSI (Event Scheduling ans Notification Interface). Cette norme est plutôt dédiée aux scénarios de blackout.

L’insertion publicitaire en OTT

Après que le programme soit transcodé, convertit en profils OTT, l’insertion devient possible. Il existe deux philosophies de fonctionnement :

Côté client :

  • Le client gère le manifest et y récupère les possibilités d’insertion de publicité ;
  • Le client interroge directement le serveur, lequel lui renvoie une annonce à jouer ;

Coté serveur :

  • Le serveur gère le manifest fourni au client afin de déclencher l’annonce au bon moment. L’opération est transparente pour le client, qui poursuit sa lecture ;

Notons que les deux approches sont compatibles avec la notion de publicités ciblées…

Dans le workflow, l’étape suivante consiste à décider quelle annonce afficher. Dans un système traditionnel, un splicer utilise simplement la norme SCTE-30 pour réclamer une annonce au serveur de publicités ; dans un système simplifié, le serveur de publicités possède une liste d’annonces et les propose sous la forme de séquences. Si l’objectif consiste à proposer une annonce publicitaire personnalisée, nul autre choix que de recourir à un système plus élaboré. Deux standards prennent en compte cette fonctionnalité :

  • L’IAB pour Interactive Advertising Bureau, à l’origine de la norme VAST (Video Ad Serving Template), permettant à un client de demander une annonce publicitaire à un serveur ;
  • VAST est une couche logicielle branchée au dessus des technologies intégrées aux navigateurs, tandis que les interactions player/serveur se satisfont du protocole HTTP ;
  • L’autre option est définie par l’ensemble des normes SCTE-130 (10 parties).

VAST est utilisé principalement comme une interface pour intégrer des annonces tierce-partie, tandis que SCTE-130 adresse les usages où un seul tiers contrôle l’ensemble des infrastructures.

VAST

VAST prend en charge la diffusion d’annonces publicitaires aussi bien côté serveur que client. La figure 6 illustre la diffusion côté client.

Figure 6 : Insertion d’annonces VAST côté client

Les différentes étapes décrites dans la figure 6 :

  1. En réponse à un marqueur, le client envoie une requête VAST à un serveur de publicité ;
  2. Le serveur lui retourne une annonce publicitaire, ou oriente éventuellement le client vers un autre serveur. Ce dernier cas est illustré dans le figure 6, le premier serveur renvoyant une “Wrapper Response” pour diriger le client vers un autre serveur ;
  3. Le client envoie une seconde requête VAST à cet autre serveur ;
  4. Le second serveur fournit alors une réponse InLine (annonce prête à être lue) ;
  5. Le client joue l’annonce publicitaire. Le suivi des pubs s’effectue chez le client en utilisant les cookies standards.

Figure 7 : Insertion d’annonces VAST côté serveur

Figure 7 :

  1. En réponse à un marqueur, le splicer envoie une demande au serveur. Le splicer peut lui-même initier cette requête en inspectant le manifest et en retrouvant le marqueur concerné. La demande peut également provenir du client ;
  2. Le serveur enverra alors une réponse VAST, qui inclut l’annonce dans un format pivot. C’est un format haut débit de bonne qualité qui aura besoin d’être transcodé en amont de sa transmission au client.
  3. Le splicer contactera un transcodeur pour la publicité. Éventuellement, ce transcodeur peut puiser cette publicité prête à l’emploi dans son cache ; dans ce cas, elle est fournie au splicer, qui va « stitcher » la pub au bon endroit puis l’envoyer au client. La norme prévoit le cas où le transcodeur ne dispose pas de cette version en cache. Dans ce cas, une autre annonce de moindre priorité est proposée, pendant que le transcodeur prépare une autre annonce. Dans ce scénario, la possibilité d’insertion à l’instant t est perdue, mais l’annonce sera prête à l’emploi la prochaine fois que qu’une demande d’insertion sera faite.

L’un des problèmes de la diffusion d’annonces côté serveur est lié au monitoring du traffic réseau, car du point de vue du serveur, toutes les requêtes proviennent du même équipement (le splicer). La norme permet cependant d’utiliser des headers pour pouvoir identifier le client…

Annonces interactives avec VAST

L’Interactive Advertising Bureau a défini un protocole appelé VPAID, pour « Video Player-Ad Interface Définition », permettant de prendre en charge les annonces interactives. Il s’agit d’une extension du cas d’usage d’insertion de publicités côté client.

VPAID est superposé à VAST. À partir d’une réponse VAST, le serveur peut fournir un ensemble d’annonces VPAID. Il s’agit d’annonces qui prennent la forme d’applications exécutables qui permettent de rester en contact avec le serveur approprié, offrant de l’interactivité et produisant éventuellement des rapports d’activité. Les annonces exécutables peuvent être écrites en ActionScript 3, Silverlight ou JavaScript.

SCTE-130 en bref

SCTE-130 définit des fonctions logiques et des interfaces pour gérer les systèmes dédiés à la publicité, et est similaire à VAST sous plusieurs aspects. Les fonctions logiques proposées sont :

  • Ad Management Service (ADM) ;
  • Ad Decision Service (ADS) ;
  • General Information Service (GIS) ;
  • Content Information Service (CIS) ;
  • Placement opportunity Service (POIS) ;
  • Subscriber Information Service (SIS) ;

SCTE-130 utilise des modèles de données au format XML, définis dans la seconde partie de la norme. Le réseau de transport, de type SOAP, est défini dans la septième partie. La figure 8 montre un diagramme des fonctions de base de la norme SCTE-130

Figure 8 : Diagramme de base de la norme SCTE-130

Les éléments indiqués dans la figure 8 sont :

  • L’Ad Management System (ADM) est un module qui est en général implémenté côté client ou dans le splicer, il a accès aux marqueurs SCTE-35. Lorsqu’un marqueur est reçu, l’ADM contacte l’Ad Decision Service (ADS) pour déterminer l’annonce publicitaire qui doit être diffusée (la troisième partie de STCE-130 définit cette interface). Un système de base d’insertion publicitaire n’aura besoin que de ces deux modules. Néanmoins, un certain nombre de systèmes complémentaires sont indispensables pour fabriquer une insertion ciblée.
  • Le Content information Service (CIS) sait quel contenu est disponible à la diffusion. Il peut gérer et les annonces publicitaires et les programmes. L’interface avec le SCTE-130 figure dans la quatrième partie.
  • Le Placement Opportunity Information System (POIS) gère les politiques, droits et contraintes. La cinquième partie décrit l’interface POIS/STCE-130. On notera que ESAM peut être utilisée là aussi.
  • Enfin, le Subscriber Information System (SIS) est capable d’agréger des connaissances sur chaque abonné, en vue d’affiner le ciblage. L’interface entre SIS et SCTE-130 se trouve dans la sixième partie.

La chaîne complète

Figure 9 : Vue d’ensemble du système d’insertion publicitaire

La figure 9 représente le schéma de principe de l’insertion publicitaire avec les différents modules décrits dans cet article.

Un schéma plus détaillé est disponible sur le site de SCTE DVS (voir aussi figure 10).

Autres applications des marqueurs SCTE104/35

Figure 10 : Diagramme détaillé

D’un point de vue bas niveau, les marqueurs SCTE-104/35 délimitent des points d’ancrage temporels dans un programme. En plus de signaler la disponibilité des annonces, les marqueurs peuvent délimiter les programmes et apporter d’autres éléments intéressants. Les applications suivantes utilisent cette infrastructure aujourd’hui :

Délimiter les programmes pour l’enregistrement DVR :

  • Les EPG sont généralement imprécis – Les enregistrements peuvent manquer le début ou la fin.
  • Les programmes peuvent être décalés par rapport à l’heure de diffusion prévue initialement.
  • Le déclenchement du DVR par les messages de SCTE-35 garantit de ne pas manquer le début ou la fin du programme.

Renforcer les restrictions DRM pour les programmes et les zones spécifiques.

Remplacement du programme complet :

  • Le plus souvent pour des raisons de droits, un programme complet ne peut être diffusé  pour une région donnée ou distribué par Internet.
  • Les marqueurs SCTE-35 peuvent être utilisés pour le remplacer par un carton d’information, voire un autre programme.

Sélectionner des portions de programmes pour les soumettre à des workflows de mesure d’audience (Nielsen aux USA, Médiamétrie en France)

Utiliser les marqueurs pour créer un contenu VOD :

  • Les directs peuvent être enregistrés par des serveurs VOD pour proposer un accès différé.
  • Les marqueurs SCTE-35 peuvent être utilisés pour segmenter ces enregistrements et créer automatiquement des programmes unitaires dans les serveurs VOD.

Précision à l’image

Dans l’inserteur côté diffuseur (voir Fig. 1), les marqueurs SCTE-104 sont associés à des images spécifiques et bien définies. Ces marqueurs sont insérés dans les VANC pour une image donnée, ils sont donc très précis. Quand la vidéo bande de base se retrouve compressée, les marqueurs SCTE-35 correspondants ont pour référence le PTS (l’horodatage du Transport Stream) d’une image spécifique du bitstream. En conséquence, avec un équipement adéquat, la précision à l’image est maintenu tout au long de la chaîne.

Les applications qui peuvent en bénéficier :

  • Précision à l’image lors de l’enregistrement DVR : on débute et termine aux bons endroits ;
  • Précision pour la création de contenus VOD provenant de directs ;
  • Placement exact de l’annonce publicitaire
D’après un article paru dans TVTechnology SCTE-104/35 and Beyond: A Look at Ad Insertion in an OTT World, traduit de l’anglais par Olivier Jouinot, ajouts et corrections de Vincent Dabouineau.
Ce contenu a été publié dans Big Data, Diffusion. Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *