Home Articles techniques Encodage vidéo dans le cloud pour diffuser des événements en direct à grande échelle
Applications

Encodage vidéo dans le cloud pour diffuser des événements en direct à grande échelle

About The Author

Outline

Alors que les dollars publicitaires et les téléspectateurs continuent de s’éloigner de la télévision traditionnelle, les propriétaires de contenu et les diffuseurs cherchent à diffuser des événements en direct soutenus par la publicité pour attirer de nouveaux publics et augmenter leurs revenus grâce au streaming OTT (over-the-top). OTT offre de nouvelles opportunités de distribution, qui permettent à un éditeur de diffuser et de monétiser du contenu sous licence qui n’avait auparavant pas sa place à la télévision. Mais avant qu’un éditeur puisse commencer à diffuser des événements en direct, les obstacles techniques dans la première étape du flux de production vidéo en streaming doivent être pris en compte :

  • La qualité de la connexion et la disponibilité de la bande passante entre le lieu et le point d’acquisition peuvent être un maillon faible du flux de travail. La redondance et la fiabilité doivent être intégrées.
  • Les flux en direct doivent être encodés dans divers formats et protocoles de débit adaptatif, tels que Apple HLS et MPEG-DASH, tout en minimisant la latence.
  • Les solutions de téléchargement et d’encodage doivent être évolutives, fiables et évolutives pour gérer l’émergence du 4k et d’autres formats de haute qualité.
  • Le workflow vidéo doit être capable de prendre en charge l’insertion publicitaire côté serveur pour une expérience de visionnage optimale et des stratégies de monétisation les plus opportunes.

Dans ce blog technologique, nous examinons comment nous avons construit notre plate-forme pour permettre à un éditeur d’optimiser la première étape du flux de travail vidéo en streaming, examinons certains des défis impliqués et expliquons comment nous encodons le flux en direct pour permettre un streaming en direct à haute performance, à faible latence et soutenu par la publicité.

‍Background : le trancheur

Avant de nous plonger dans les considérations techniques de l’encodage, nous devons expliquer notre technologie appelée « Slicer ». Un puissant client logiciel, The Slicer, lance le flux en direct de votre site vers notre plateforme vidéo cloud. Il simplifie une tâche extraordinairement complexe sans sacrifier la flexibilité et la fonctionnalité. Le Slicer est une raison essentielle pour laquelle les diffuseurs disposant de ressources techniques étendues et ceux qui n’en disposent pas peuvent tirer parti de notre plate-forme pour créer des expériences OTT puissantes et différenciées.

Le Slicer prépare votre contenu pour l’encodage, calcule les paramètres d’encodage idéaux et gère les marqueurs d’insertion publicitaire. Vous pouvez exécuter le Slicer sur votre matériel sécurisé ou choisir les économies de coûts et l’évolutivité des emplacements indémodables prenant en charge différents formats, y compris SDI, vidéo IP, RTP/FEC et RTMP.

Le Slicer divise votre contenu en petits morceaux et les crypte avant de les envoyer à notre pile d’encodage cloud certifiée ISO, vous offrant ainsi la tranquillité d’esprit qui vient lorsque vous savez que votre contenu est toujours sécurisé. Il offre une gamme flexible de workflows, allant de simples configurations en un clic à des scripts plus avancés dans le langage de programmation de votre choix, en passant par l’écriture de fonctions cloud qui déclenchent des workflows pour les notifications, le traitement des tâches et les intégrations d’apprentissage automatique.

Notre « Live Slicer », une version du Slicer, est optimisée pour le streaming d’événements en direct. Les flux HD-SDI ou IP sont rapidement ingérés et fractionnés en segments cryptés de 2 ou 4 secondes au débit binaire le plus élevé souhaité, réduisant ainsi les besoins en bande passante à 3–5 Mbit/s pour le 1080p et à environ 15 Mbit/s pour le 4K. Notre processus conserve automatiquement les métadonnées et les messages intrabande et hors bande pour déclencher des pauses de programme et de publicité ou remplacer du contenu. Notre architecture de plug-in vous permet de créer des scripts personnalisés qui gèrent vos exigences uniques en matière d’événements de signalisation. Live Slicer peut également écouter des messages SCTE 35 / 104 ou recevoir des appels API pour insérer des pauses publicitaires, des démarrages de contenu ou des déclencheurs de blackout.

Un flux OTT est généré à partir d’une alimentation linéaire en direct avec un investissement initial minimal et de faibles besoins en bande passante.

Réduction de la bande passante

Maintenant que vous comprenez le Slicer, vous vous demandez peut-être pourquoi nous allions développer un composant logiciel frontal pour déplacer les flux en direct des événements vers le cloud. Pourquoi les éditeurs ne pourraient-ils pas envoyer un flux RTMP (Real-Time Messaging Protocol), par exemple ? (Vous pouvez le faire si vous le souhaitez, mais la plupart de nos clients profitent du Slicer.) la réponse a autant à voir avec les attentes des consommateurs pour des flux en direct de haute qualité qu’avec le travail autour des défis de bande passante sur les sites en direct. Il s’agit de trouver le bon équilibre entre de nombreux facteurs concurrents. D’une part, vous devez conserver autant de flux d’origine que possible, avec un œil vers des formats de meilleure qualité et 4K. D’autre part, vous devez optimiser le flux afin qu’il puisse être livré efficacement sans vous enliser par des frais généraux supplémentaires, tels que la publicité personnalisée. Trouver le bon équilibre est essentiel pour cette étape du workflow vidéo.

C’est là que le Slicer est essentiel. Comme indiqué ci-dessus, il réduit considérablement la bande passante requise pour un flux donné en créant le profil de débit binaire le plus élevé sur le site et en envoyant uniquement ce profil vers le cloud. Selon notre observation – basée sur la diffusion de millions d’heures de séquences en direct à des milliards de téléspectateurs dans le monde – l’approche alternative consistant à envoyer un flux RTMP beaucoup plus important vers le cloud n’entraîne pas une augmentation appréciable de la qualité de l’expérience de visionnage. Mais il augmente considérablement la bande passante, ce qui augmente les coûts.

Les coûts de backhaul peuvent augmenter rapidement. Si vos besoins sont tels que vous avez besoin d’une liaison montante satellite, un camion en bande Ka, par exemple, loue pour environ 2 000 $ par jour, et la bande passante coûte environ 400 $ par heure. Étant donné les conditions incohérentes et limitées en bande passante dans certains lieux, tels que les hôtels ou les centres de conférence, ou même sur des sites sportifs du monde entier, l’essentiel est qu’il est toujours judicieux de réduire les besoins en bande passante de téléchargement dans la mesure du possible tout en vous assurant d’offrir une expérience de type broadcast à vos téléspectateurs.

Haies de codage

Une fois que le flux vidéo en direct quitte la salle, l’étape suivante du workflow est l’encodage. Ici, un encodeur vidéo crée plusieurs versions ou variantes de l’audio et de la vidéo à différents débits binaires, résolutions et niveaux de qualité. Il segmente ensuite les variantes en petits fichiers ou segments multimédias. Plusieurs étapes supplémentaires doivent être effectuées, telles que la création d’une liste de lecture multimédia pour chaque variante contenant une liste d’URL pointant vers les segments multimédias de la variante. La liste de lecture principale résultante est le choix du joueur de la variante la plus appropriée pour l’appareil et la bande passante actuellement mesurée ou disponible.

Deux protocoles majeurs de streaming vidéo ajoutent à la complexité, et d’autres peuvent avoir besoin d’être pris en charge pour couvrir la myriade de périphériques de lecture potentiels. HLS est un protocole de communication multimédia en streaming basé sur HTTP implémenté par Apple. Il prend en charge tous les appareils Apple et la plupart des navigateurs et appareils Google, Android, Linux et Microsoft. La plupart mais pas tous. Vous avez également besoin de MPEG-DASH, un protocole de streaming multimédia basé sur HTTP concurrent. Vous devrez peut-être également ajouter la prise en charge de Microsoft Smooth Streaming pour les consoles de jeux.

DRM peut également compliquer l’encodage en exigeant son propre ensemble de formats multiples pour prendre en charge les exigences d’un large public. Par exemple, les anciens joueurs qui ne prennent pas en charge les DRM ont besoin de HLS et AES-128. Les anciens appareils iOS nécessitent HLS et FairPlay. Les nouveaux appareils iOS prennent en charge HLS et FairPlay, ainsi que CMAF CBC. Windows et Android plus anciens prennent uniquement en charge le CTR CMAF. Android, Windows et iOS plus récents devraient prendre en charge tous les formats CMAF. Votre contenu doit être emballé dans plusieurs formats pour permettre la lecture sur tous les appareils.

Si cela semble être beaucoup de travail d’encodage, vous avez raison. À mesure que les résolutions augmentent et que les codecs deviennent plus complexes, il devient plus difficile d’encoder une échelle de codage ABR complète sur une seule machine, que ce soit dans le cloud ou sur site. Si votre matériel d’encodage n’est pas à la hauteur de la tâche de suivre le flux en direct, vous devrez peut-être réduire le nombre de segments sur l’échelle d’encodage, ce qui pourrait avoir un impact sur l’expérience de votre audience.

Pour suivre le rythme des exigences d’encodage plus complexes, le modèle traditionnel signifie que les éditeurs doivent continuellement investir dans du nouveau matériel pour maintenir la vitesse et la qualité. En fin de compte, pour un service de streaming comme Edgio, anciennement Verizon Digital Media Services, le modèle 1:1 stream-to-encoder ne parvient pas à fournir la fiabilité, la flexibilité et l’évolutivité dont nous avons besoin pour répondre aux attentes de nos clients.

Au lieu de cela, nous avons développé un système de courtage sophistiqué qui permet d’utiliser autant d’encodeurs que nécessaire, tous exécutés dans une infrastructure basée sur le cloud. Le système de courtage reçoit les morceaux de contenu des instances Slicer et les déplace vers le codeur le plus optimal. Cette action empêche les processus d’encodage de surcharger une machine spécifique et permet aux morceaux de se déplacer dans le système vers le stockage et vers les visionneuses.

Le processus de courtage fait évoluer notre infrastructure d’encodeur cloud de manière transparente et, plus important encore, automatiquement.

Dans notre implémentation, une instance de courtier agit comme un gestionnaire qui parle entre le Slicer et les encodeurs. Le courtier veille à ce que les données de tout nouveau Slicer soient acheminées vers le codeur approprié et vérifie que le codeur peut gérer la charge de travail. De plus, nous disposons d’une infrastructure évolutive très performante. Si nous sommes soudainement vidés avec un million d’heures de contenu VOD qui doit être encodé, nous pouvons accélérer les instances de serveur rapidement et commencer à traiter le contenu. Nous pouvons également réduire nos effectifs tout aussi rapidement pour préserver les ressources. Ce processus de courtier gère l’ensemble de notre infrastructure cloud de manière transparente et, plus important encore, automatiquement.

Encodeurs sans état

Bien sûr, le système de courtage serait d’une valeur limitée si tout ce qu’il pouvait faire était de pointer un Slicer vers un encodeur unique qui pourrait ou non être en mesure de suivre les exigences du flux en direct, un problème sérieux avec 4K. La solution que nous avons développée implique l’utilisation de codeurs sans état. Au lieu de consacrer une seule machine à l’ensemble du flux, chaque encodeur ne reçoit qu’un seul segment vidéo de 2 ou 4 secondes à la fois. Chaque segment comprend suffisamment d’informations pour amorcer le codeur afin qu’il puisse coder ce segment et rejeter tout ce qui n’est pas nécessaire pour les amorçages, comme les informations d’entrée et de sortie. À ce stade, le segment complet est terminé et prêt à fonctionner, libérant ainsi l’encodeur pour qu’il puisse commencer à encoder un autre contenu à partir d’un autre canal ou de tout autre élément.

Ce modèle a également une quantité considérable de redondance intégrée dans le système. Par exemple, si un encodeur se bloque pendant le traitement d’un segment, le même segment démarre sur une autre machine et se termine à temps avant que des problèmes ne soient remarqués dans le flux.

Cette approche permet également d’utiliser du matériel plus rentable. Par exemple, si nous savons qu’une machine plus lente peut prendre 8 secondes pour traiter un fichier de 4 secondes à partir d’un Slicer, nous pouvons répartir la charge de travail sur plusieurs encodeurs comme indiqué ci-dessous : le serveur A obtient la tranche 1, le serveur B obtient la tranche 2, et ainsi de suite. Ensuite, les morceaux ont été livrés sans problèmes car ils ont tous été terminés à un moment prévisible. Comme le montre le graphique ci-dessous, cet exemple entraînerait une latence de 16 à 20 secondes derrière le temps réel.

L’utilisation de plusieurs encodeurs dans le cloud minimise la latence et permet l’utilisation de serveurs qui autrement ne seraient pas en mesure de suivre un flux en direct.

En fin de compte, le volume de serveurs dans le cloud, même si les serveurs individuels sont plus lents, signifie que les processus d’encodage peuvent toujours répondre aux demandes en direct. Si vous souhaitez mettre en place une infrastructure d’encodage à l’aide d’un modèle traditionnel, vous devez investir dans des machines hautes performances coûteuses ou du matériel spécialisé, chacun capable de traiter l’intégralité de la vidéo entrante sans assistance en temps réel. En tirant parti de l’évolutivité du cloud, nous réduisons considérablement les coûts d’encodage.

Un autre avantage de l’encodage cloud sans état est que nous pouvons facilement déplacer les charges de travail vers d’autres fournisseurs de cloud puisque nous n’avons pas d’exigences de serveur spécialisées. Avec un réseau de plus de 250 Tbps de capacité, une approche multi-cloud offre des avantages inhérents.

Diffusion en direct économique

Pour les producteurs de contenu en direct, les considérations techniques pour préparer la vidéo en direct pour le streaming dans le cloud peuvent présenter des obstacles redoutables. Vous serez confronté à divers problèmes allant des limitations de bande passante du lieu aux questions complexes entourant les encodeurs et les protocoles de streaming. Bien qu’il n’élimine pas le besoin d’une certaine connectivité sur le site, un workflow simplifié avec des exigences réduites en bande passante sur le front-end peut réduire considérablement les dépenses initiales et continues tout en fournissant les flux de haute qualité et à faible latence que vos spectateurs attendent.