Des expériences de visionnage personnalisées au niveau 1:1 transforment l’expérience télévisuelle. Au lieu d’une taille unique, les téléspectateurs reçoivent une publicité ciblée et hautement pertinente, un contenu personnalisé, des recommandations pour de nouveaux programmes et une gestion DRM/blackout précise, le tout en fonction du type d’appareil, de l’emplacement, de l’historique, des données démographiques et d’autres données de vos téléspectateurs.
Mais la mise à l’échelle de flux vidéo personnalisés à des millions de téléspectateurs, en particulier pour la programmation en direct comme le sport, est presque aussi difficile que de frapper pour le cycle dans le baseball. Les volumes de spectateurs peuvent osciller de manière sauvage, augmentant de centaines de milliers lors de moments incontournables tels que le coup d’envoi, les heures supplémentaires et les matchs rapprochés. Supposons que votre infrastructure de prise en charge de la personnalisation ne soit pas suffisamment adaptable et évolutive. Dans ce cas, votre expérience personnalisée sera terminée, et votre entreprise entière pourrait être en danger dans le monde de OTT.
Le rôle central du serveur de manifest dans la personnalisation
La personnalisation OTT repose sur les performances du serveur de manifest pour générer une liste de lecture unique de contenu, de publicités et d’instructions de lecture. Le serveur de manifest doit faire face aux dépendances suivantes :
- Latence du serveur publicitaire : la communication avec les serveurs publicitaires peut ajouter une latence qui doit être prise en compte dans le flux de travail, en particulier lorsque plusieurs sauts sont impliqués.
- Monétisation/reporting — une fois la publicité diffusée, une balise doit être renvoyée au(x) serveur(s) publicitaire(s) pour mesurer les impressions publicitaires et permettre la monétisation.
- Aspects apatrides d’Internet — pour que les manifestes personnalisés fonctionnent à grande échelle, l’état doit être maintenu sur plusieurs demandes pour chaque utilisateur.
- DRM/Authentication : le serveur de manifest doit garder un œil sur la gestion des droits numériques (DRM), le chiffrement au niveau de la session et l’authentification.
- Droits et restrictions d’interdiction/de contenu — en fonction de l’emplacement de l’utilisateur, le contenu en streaming peut être soumis à diverses règles d’interdiction, qui doivent toutes être gérées avec précision.
- Recommandations de contenu — les internautes attendent de vous que vous les connaissiez et personnalisiez vos recommandations pour les aider dans le processus de recherche et de découverte.
- Localisation du contenu — pour les événements majeurs, il est essentiel de fournir aux utilisateurs les variations régionales appropriées, y compris les pistes audio, les sous-titres codés et les sous-titres.
Personnalisation des flux en temps réel
Comme indiqué dans la partie 1 de cette série de blogs, un flux en direct ou VOD est ingéré, codé et empaqueté par notre application logicielle Slicer. Des limites publicitaires peuvent être insérées pour permettre aux propriétaires de contenu de personnaliser l’expérience du spectateur. Au fur et à mesure que les publicités sont ingérées, elles sont également traitées via un Slicer exécuté dans le cloud pour une expérience de lecture plus proche de la diffusion.
Lorsque le Slicer commence à ingérer le flux en direct ou VOD, il communique continuellement avec notre infrastructure backend, gardant la base de données à jour sur le nombre de segments disponibles. Les serveurs de manifeste utilisent ces données pour personnaliser l’expérience de chaque visionneur. Lorsqu’un joueur demande un flux, le serveur de manifeste détermine quels segments vidéo et audio doivent être listés dans le fichier de manifeste, qui agit comme une liste de lecture. La possibilité de modifier ou de personnaliser dynamiquement le manifeste au niveau de chaque utilisateur permet d’adapter l’expérience de visualisation. Dans le cas de la vidéo en direct, un nouveau manifeste est demandé toutes les quelques secondes, ce qui permet aux serveurs de manifest d’appliquer dynamiquement des ajustements à mesure que les conditions de visualisation changent.
Rôle central du serveur de manifest dans la personnalisation des flux vidéo
Comme indiqué ci-dessus, au cœur de la personnalisation manifeste se trouve la communication. Avec la plupart des exigences commerciales d’OTT, cela signifie des communications avec les serveurs publicitaires pour fournir des publicités ciblées et personnalisées en temps réel. Les données individuelles, y compris l’adresse IP, l’emplacement et le type d’appareil d’un téléspectateur — essentiellement toutes les informations que nous pouvons capturer tout en respectant les règles et réglementations strictes en matière de PII — sont fournies au système de décision publicitaire. La solution résultante est suffisamment robuste pour apprendre ce qui est pertinent pour un spectateur lors de la diffusion de publicités pendant les diffusions en direct. Le système est également suffisamment robuste pour faire face à des défis tels que la gestion des restrictions d’interdiction et des droits de contenu par utilisateur, tout en prenant en charge des capacités de personnalisation importantes telles que des recommandations de contenu et d’autres localisations.
Architecture de l’infrastructure de manifeste à l’échelle
Dans notre plate-forme vidéo, le serveur de manifest est responsable de générer un manifeste de streaming personnalisé pour chaque spectateur. Il doit également être conscient des autres exigences mentionnées ci-dessus, telles que les restrictions de contenu et les recommandations. Dans ce modèle, nous envoyons un flux intégré, ce qui signifie qu’il n’y a pas de problèmes de « roue tampon » pendant que les clients attendent que les publicités se chargent au milieu du flux.
Pour construire un système de livraison de manifestes résilient, nous maintenons des clusters de serveurs de génération de manifestes dans le cloud qui sont répartis dans différentes régions géographiques à travers le monde. Aux États-Unis, par exemple, ces serveurs sont organisés en cinq régions à travers le pays. Lorsqu’une demande de nouveau flux arrive d’un joueur basé aux États-Unis, cette demande est acheminée de manière aléatoire vers l’une des zones américaines.
Le défi du « troupeau tonneux »
Cela peut sembler contre-intuitif, mais il est fait pour éviter les modes de défaillance en cascade. La majorité des téléspectateurs américains se trouvent dans les régions orientales du pays. Si nous devions tous les acheminer vers la zone la plus proche d’eux, et que notre fournisseur de cloud connaissait une défaillance dans cette région, la majorité de nos téléspectateurs connaîtrait cette défaillance. Pour aggraver le problème, si tous ces téléspectateurs rafraîchissent le flux, et que nous dirigeons maintenant les téléspectateurs vers leur zone saine la plus proche, nous connaîtrions un problème de « troupeau tondant » où tous les téléspectateurs de la zone défaillante s’empilent maintenant sur la zone la plus proche suivante. Le pic de trafic inattendu qui en résulte pourrait potentiellement causer une défaillance secondaire jusqu’à ce que nos systèmes dans la nouvelle zone puissent évoluer pour répondre à la demande supplémentaire.
Au lieu de cela, la distribution aléatoire de nos visionneuses américaines aide à atténuer l’effet de toute défaillance initiale et nous permet de distribuer uniformément le trafic de basculement au reste des zones saines.
Dans notre plate-forme de streaming, nous distribuons la charge du serveur manifeste entre les zones. Cela évite de surcharger une zone spécifique pendant les pics d’audience, en particulier si les téléspectateurs sont soudainement déplacés vers une zone adjacente pendant le basculement.
Chacune de nos zones dispose d’un magasin de données distinct dédié au stockage des données de session associées. Une fois qu’un visualiseur est acheminé vers une zone, nous créons une session pour ce visualiseur et l’enregistrons dans le cluster de sessions de la zone. La session est un ensemble de données sur le visualiseur et les paramètres fournis par le client sur la façon dont il souhaite personnaliser la session pour ce visualiseur. Pour surmonter le défi posé par la nature sans état d’Internet, les serveurs de manifest construisent des URL pour chaque session incluse dans le manifeste renvoyé au lecteur. Les requêtes suivantes du lecteur sont acheminées directement vers la zone où la session du spectateur a été créée et stockée (au lieu d’être acheminées aléatoirement vers l’une des autres zones).
Comme le montrent les trois graphiques ci-dessous, différents événements peuvent avoir de nombreuses exigences différentes selon la taille de l’auditoire et si l’auditoire est local ou dispersé géographiquement. Jetez un coup d’œil aux trois exemples illustrant les défis en matière d’infrastructure auxquels les diffuseurs sont confrontés pour soutenir les événements en direct.
Dans le premier scénario, nous présentons un concours de nourriture (oui, nous en avons diffusé un en direct) car il illustre un public distribué mais de petite taille. Peut-être que le jour viendra où les concours alimentaires deviendront courants, mais pour l’instant, ils restent un événement de niche qui attire un petit nombre de téléspectateurs à travers une large géographie. La charge du serveur manifeste est répartie facilement sur plusieurs zones et clusters de serveurs manifestes. C’est là que la valeur de la personnalisation devient évidente en facilitant l’insertion d’annonces appropriées pour chaque région et en permettant également de gérer les droits et les pannes.
Le scénario change considérablement pour les championnats de football de l’État du Texas, où un grand nombre de téléspectateurs se trouvent dans la même zone géographique. Nous gérons cela de deux façons. Comme indiqué ci-dessus, nous avons constaté que nous pouvons assigner des visualiseurs à des serveurs de manifest situés dans des zones en dehors de la géographie immédiate sans affecter l’expérience du visualiseur. En plus de cela, nous avons un système qui surveille les niveaux de consultation dans chaque zone et peut automatiquement faire tourner les serveurs de génération de manifestes si nécessaire sur une base par zone.
Nous pouvons pré-dimensionner en fonction du nombre de spectateurs attendus pour de grands événements tels que les finales de la NBA. Pourtant, nous avons eu plusieurs événements où nos systèmes de mise à l’échelle automatique ont traité près d’un million de téléspectateurs sans nécessiter de préchauffage. En plus d’augmenter l’évolutivité, la possibilité de répartir instantanément la charge sur les serveurs de manifeste de manière indépendante de la zone améliore considérablement la fiabilité et la redondance sur l’ensemble du réseau.
Requêtes des joueurs et balisage publicitaire
Un certain nombre de changements et de tendances dans l’industrie rendent l’évolutivité du cloud plus importante que jamais. Un facteur majeur est le rétrécissement de l’intervalle entre les demandes du lecteur. Notre demande de lecteur linéaire en direct standard de 8 secondes « What’s next » est portée à 5 secondes et peut être aussi brève que toutes les 2 secondes pour les flux où une faible latence est importante. Cela a un impact majeur sur l’utilisation du processeur car le serveur doit répondre à 4 fois plus de requêtes (à intervalles de 2 secondes par rapport à des intervalles de 8 secondes). De plus, les recommandations de contenu et de panne doivent désormais être vérifiées plus fréquemment que par le passé pour éviter les erreurs.
De même, le monde de la ad-tech devient de plus en plus complexe et exigeant. Pour chaque annonce insérée dans un flux, un serveur publicitaire aura au moins cinq balises utilisées à des fins de reporting. Une solution d’insertion publicitaire côté serveur (SSAI) est nécessaire pour s’assurer qu’elle envoie ces balises afin que ses clients soient payés par leurs annonceurs. Alors que cinq balises sont le minimum, il peut y en avoir beaucoup plus. En fait, nous avons vu des cas où une seule annonce a de 30 à 100 balises à signaler.
De plus, les réseaux complexes de serveurs publicitaires deviennent de plus en plus fréquents dans les campagnes de nos clients. Plusieurs sauts de réseau publicitaire peuvent commencer à causer des problèmes de latence. Par exemple, le réseau #1 pourrait dire : « Voici la liste des annonces dans cette pause », pour découvrir que la publicité #2 dans cette pause nécessite une requête à un autre réseau. La publicité #3 introduit deux sauts de plus, et ainsi de suite.
Dans l’exemple ci-dessus, les pauses publicitaires peuvent doubler ou tripler l’utilisation du processeur. Les demandes de lecture vidéo en direct peuvent aggraver ce facteur de 10 à 30 %.
Looking Ahead — microservices et évolutivité
Avec la complexité croissante, l’une des mesures que nous avons prises est de séparer les différentes charges de travail précédemment gérées par les serveurs de manifest en microservices plus petits. La première étape que nous avons faite est de déplacer les communications et le balisage des serveurs publicitaires vers son propre service, aidant à relever le défi de la latence des serveurs publicitaires. Ce service de proxy publicitaire offre plusieurs fonctionnalités avancées que nous aborderons plus en détail dans un prochain article de blog.
À l’avenir, nous continuerons à développer d’autres microservices afin de supprimer plus de travail des serveurs manifest et d’offrir une approche plus ciblée de l’évolutivité. Bientôt, nous ajouterons des zones de plusieurs fournisseurs de cloud pour devenir résilients aux défaillances de n’importe quel fournisseur.
En couplant SSAI évolutif avec des microservices, nous pouvons optimiser les coûts des serveurs, la structure de notre base de code et d’autres caractéristiques spécifiques au trafic publicitaire. En outre, nous pouvons surmonter plusieurs défis clés, y compris la latence des serveurs publicitaires, les restrictions d’interdiction et la monétisation. Parallèlement, en répartissant la charge de traitement sur plusieurs zones, notre service de streaming vidéo en direct peut évoluer largement et surmonter les principaux défis, ce qui nous permet de fournir de manière fiable des millions de flux personnalisés simultanés sans mettre à rude épreuve notre réseau de diffusion.
