Alors que les dépenses 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 accroître leurs revenus grâce au streaming OTT (over-the-top) . OTT offre de nouvelles possibilité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 de vidéo en streaming doivent être pris en compte :
- La qualité de la connexion et la disponibilité de la bande passante entre la salle et le point de transfert peuvent être un maillon faible du flux de travail. Redondance et fiabilité doivent être intégrées.
- Les flux en direct doivent être encodés dans divers formats et protocoles adaptatifs de débit binaire, 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 faire face à l’émergence du 4K et d’autres formats de haute qualité.
- Le workflow vidéo doit pouvoir prendre en charge l’insertion publicitaire côté serveur pour une expérience optimale et les stratégies de monétisation les plus opportunes.
Dans ce blog sur la technologie, nous examinons comment nous avons construit notre plateforme pour permettre à un éditeur d’optimiser la première étape du flux de production de vidéos 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 : la trancheuse
Avant de nous plonger dans les considérations techniques de l’encodage, nous devons expliquer notre technologie appelée « trancheuse ». Un puissant client logiciel, The Slicer, permet de diffuser en direct votre site sur notre plateforme vidéo cloud. Il simplifie une tâche extraordinairement complexe sans sacrifier la flexibilité et la fonctionnalité. Le Slicer est l’une des principales raisons pour lesquelles 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 extrêmement différenciées.
Le trancheur 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épendants du cloud prenant en charge différents formats, y compris SDI, vidéo IP, RTP/FEC et RTMP.
Le trancheur découpe votre contenu en petits morceaux et les crypte avant de les envoyer à notre pile d’encodage cloud certifiée ISO, ce qui vous donne la tranquillité d’esprit que procure le fait de savoir 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é pour le streaming d’événements en direct. Les flux HD-SDI ou IP sont rapidement ingérés et découpés en segments chiffrés de 2 ou 4 secondes au débit 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 programmes et de publicités 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 panne.
Un flux OTT est généré à partir d’un flux 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 allons développer un composant logiciel front-end pour déplacer les flux en direct des événements vers le cloud. Pourquoi les éditeurs ne pouvaient-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 tient autant aux attentes des consommateurs en matière de diffusion en direct de haute qualité qu’à la résolution des problèmes de bande passante sur les sites en direct. Il s’agit de trouver le juste équilibre entre de nombreux facteurs concurrents. D’une part, vous devez préserver autant que possible le flux d’origine, avec un souci de formats de meilleure qualité et de 4K. D’autre part, vous devez optimiser le flux afin qu’il puisse être livré efficacement sans s’enliser dans des frais supplémentaires, tels que la publicité personnalisée. Trouver le bon équilibre est essentiel pour cette étape du workflow vidéo.
C’est ici que la trancheuse est essentielle. 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 au cloud. Selon notre observation — basée sur la diffusion en continu 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 significativement plus important vers le cloud n’entraîne pas une augmentation appréciable de la qualité de l’expérience de visionnement. Mais cela augmente considérablement la bande passante, ce qui augmente les coûts.
Les coûts de backhaul peuvent s’ajouter rapidement. Si vos besoins sont tels que vous avez besoin d’une liaison montante satellite, un camion de bande Ka, par exemple, loue 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 les sites sportifs du monde entier, le résultat est qu’il est toujours judicieux de réduire les besoins en bande passante de téléchargement dans toute la mesure possible tout en vous assurant d’offrir une expérience de type broadcast à vos téléspectateurs.
Obstacles à l’encodage
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 de média. 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édia de la variante. La playlist principale résultante est le choix par le lecteur de la variante la plus appropriée pour l’appareil et la bande passante actuellement mesurée ou disponible.
Deux protocoles de streaming vidéo majeurs 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 de streaming multimédia basé sur HTTP mis en œuvre 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.
La DRM peut également compliquer l’encodage en exigeant son propre ensemble de formats multiples pour prendre en charge les besoins d’un large public. Par exemple, les joueurs plus âgés 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 appareils iOS plus récents prennent en charge HLS et FairPlay, ainsi que CMAF CBC. Les versions plus anciennes de Windows et Android prennent uniquement en charge CMAF CTR. Les nouveaux Android, Windows et iOS 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 ressemble à 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 d’encodage 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 en mesure 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 public.
Pour répondre à des exigences de codage plus complexes, le modèle traditionnel signifie que les producteurs doivent continuellement investir dans de nouveaux matériels 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 flux-encodeur 1:1 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 fonctionnant dans une infrastructure basée sur le cloud. Le système de courtage reçoit les morceaux de contenu des instances de 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 maintient les blocs se déplaçant dans le système vers le stockage et vers les visionneuses.
Le processus de courtier fait évoluer notre infrastructure de codeur cloud de manière transparente et, surtout, automatiquement.
Dans notre implémentation, une instance de courtier agit comme un gestionnaire qui parle entre le Slicer et les encodeurs. Le courtier s’assure que tout nouveau Slicer reçoit ses données acheminées vers le codeur approprié et vérifie que le codeur peut gérer la charge de travail. En outre, 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 notre échelle tout aussi rapidement pour préserver les ressources. Ce processus de courtage gère l’ensemble de notre infrastructure cloud de manière transparente et, surtout, automatiquement.
Codeurs 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 seul encodeur qui pourrait ou non être en mesure de suivre les exigences du flux en direct, un problème sérieux avec le 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 contient suffisamment d’informations pour amorcer le codeur afin qu’il puisse coder ce segment et éliminer 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 à être utilisé, libérant ainsi l’encodeur afin qu’il puisse commencer à encoder un autre morceau de contenu à partir d’un autre canal ou autre.
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 est terminé à temps avant que des problèmes ne soient détecté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 blocs ont été livrés sans problème car ils ont tous été terminés à une heure prévisible. Comme le montre le graphique ci-dessous, cet exemple entraînerait une latence derrière Live de 16 à 20 secondes.
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 des serveurs dans le cloud — même si les serveurs individuels sont plus lents — signifie que les processus d’encodage peuvent toujours suivre les demandes en direct. Si vous vouliez 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 cloud puisque nous n’avons pas d’exigences de serveur spécialisé. Avec un réseau de plus de 250 Tbit/s 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 la préparation de la vidéo en direct pour le streaming dans le cloud peuvent présenter de formidables obstacles. 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 flux de travail simplifié avec des exigences de bande passante réduites sur le front-end peut considérablement réduire les dépenses initiales et continues tout en fournissant les flux de haute qualité et à faible latence que vos spectateurs attendent.
