La faible latence est une aspiration universelle dans les médias. Lorsqu'une entreprise comme Wowza produit le graphique parfait pour expliquer les technologies de streaming à faible latence, vous devez leur retirer votre chapeau et utiliser le graphique, avec attribution et quelques modifications mineures. Je présente ledit graphique comme la figure 1; discutons-en dans l’ordre indiqué par les chiffres en surbrillance que j’ai ajoutés.
1. Applications pour une faible latence
GUIDE PRODUIT
Meilleures caméras PTZ pour la diffusion en direct
Pour nous assurer que nous sommes tous sur la même longueur d'onde, la latence dans le contexte de la diffusion en direct signifie le délai de verre à verre. Le premier verre est la caméra de l'événement en direct, le second est l'écran que vous regardez. La latence est le délai entre le moment où le apparaît dans l'appareil photo et le moment où il apparaît sur votre téléphone. Des facteurs tels que le temps d'encodage (lors de l'événement), le temps de transport vers le cloud, le temps de transcodage dans le cloud (pour créer l'échelle d'encodage), le délai de livraison et, de manière critique, combien de secondes votre lecteur tamponne avant de commencer à jouer contribuent à la latence.
La couche supérieure affiche les applications typiques et leurs exigences de latence. Les applications populaires manquant à la faible latence et à la latence quasi temps réel sont les sites de jeux d'argent et d'enchères.
Avant de plonger dans notre discussion sur la technologie, comprenez que plus la latence de votre flux en direct est faible, moins le flux est résilient aux interruptions de bande passante. Par exemple, en utilisant les paramètres par défaut, un flux HLS sera lu pendant plus de 15 secondes de bande passante interrompue, et s'il est restauré à ce stade, le spectateur peut ne jamais savoir qu'il y a eu un problème. En revanche, un flux à faible latence s'arrêtera de jouer presque immédiatement après une interruption. Ainsi, l'avantage du temps de démarrage à faible latence doit toujours être équilibré par rapport au négatif des arrêts de lecture. Si vous n’avez pas absolument besoin d’une faible latence, il ne vaut peut-être pas la peine de sacrifier la résilience pour l’obtenir.
Cela dit, il est utile de diviser la latence en trois catégories, comme suit.
BULLETIN PROAudio + Vidéo + IT. Nos éditeurs sont des experts en intégration audio / vidéo et informatique. Obtenez des informations quotidiennes, des actualités et un réseautage professionnel. Abonnez-vous à Pro AV aujourd'hui.
- Bon d'avoir - Plus rapide est toujours meilleur, mais si vous diffusez en direct une réunion du conseil scolaire ou un match de football au lycée, vous pouvez décider que la robustesse du flux est plus importante que la faible latence, en particulier si de nombreux téléspectateurs regardent sur des connexions à faible débit.
- Avantage compétitif - Dans certains cas, une faible latence offre un avantage concurrentiel, ou une latence lente signifie un désavantage concurrentiel. Vous noterez dans le graphique que la latence typique de la télévision par câble est d'environ cinq secondes. Si votre service de streaming est en concurrence avec le câble, vous devez être dans cette plage, avec une latence plus faible offrant un avantage concurrentiel modeste.
- Communications en temps réel - Si vous êtes un site de jeux d'argent ou d'enchères, ou que votre application nécessite des communications en temps réel, vous devez absolument fournir une faible latence.
- Guide de comparaison de la diffusion en direct
- Comment prédire le succès du codec
Maintenant que nous connaissons les catégories, examinons le moyen le plus efficace de fournir le niveau requis de faible latence.
2/3 agréable d'avoir une faible latence
Le chiffre 2 montre qu'Apple HLS et MPEG-DASH déployés en utilisant leurs paramètres par défaut entraînent environ 30 secondes de latence. Les chiffres sont simples; si vous utilisez des tailles de segment de dix secondes et que trois segments doivent figurer dans la mémoire tampon du lecteur avant le début de la lecture, vous êtes à trente secondes. En vérité, Apple a changé ses exigences de dix secondes à six secondes il y a quelques années, et la plupart des producteurs de DASH utilisent des segments de 4 à 6 secondes, de sorte que le nombre par défaut est vraiment plus proche de 20 secondes.
Pourtant, le numéro 3, HLS Tuned et DASH Tuned, montre une latence d'environ 6-8 secondes. Essentiellement, le réglage signifie passer de segments de 10 secondes à des segments de 2 secondes qui, en appliquant les mêmes calculs, fournissent les 6 à 8 secondes de latence. Ainsi, lorsque la latence est agréable à avoir, vous pouvez réduire considérablement la latence sans temps ni coût de développement, ou risque de délivrabilité considérablement accru.
4. Avantage concurrentiel - Technologies HTTP à faible latence
Lorsqu'une faible latence est nécessaire comme avantage concurrentiel, il ne suffit pas de réduire la taille des segments; vous devrez mettre en œuvre une véritable technologie à faible latence. Ici, il y a deux classes; Technologies HTTP comme HLS à faible latence et CMAF à faible latence pour DASH, et solutions basées sur d'autres technologies, telles que WebSockets et WebRTC.
Pour la plupart des producteurs avec des applications de cette classe, les technologies HTTP à faible latence offrent le meilleur mélange d'accessibilité, de rétrocompatibilité, de flexibilité et de fonctionnalités. Je vais donc couvrir les technologies HLS à faible latence et CMAF à faible latence pour DASH dans cette section, et d'autres technologies dans la suivante.
Tous les systèmes à faible latence basés sur HLS / DASH / CMAF fonctionnent de la même manière de base, comme le montre la figure 2. C'est-à-dire, plutôt que d'attendre qu'un segment complet soit codé, ce qui prend généralement entre 6 et 10 secondes (haut de la figure 2) , l'encodeur crée des morceaux beaucoup plus courts qui sont transférés vers le CDN dès qu'ils sont complets (bas de la figure 2).
Par exemple, si votre encodeur produisait des segments de six secondes, vous auriez au moins six secondes de latence; triple si les trois segments normaux devaient être reçus par le spectateur avant le début de la lecture. Cependant, si votre encodeur émettait des morceaux toutes les 200 millisecondes et que le lecteur était configuré pour démarrer la lecture immédiatement, la latence devrait être beaucoup, beaucoup moins. L'un des principaux avantages de ce schéma est la compatibilité ascendante; comme des segments sont toujours en cours de création, les joueurs non compatibles avec le schéma à faible latence devraient toujours pouvoir lire les segments, bien qu'avec une latence plus longue. Ces segments sont également disponibles instantanément pour les présentations VOD à partir du flux en direct.
Au-delà de ces avantages, les technologies HTTP à faible latence prennent en charge la plupart des fonctionnalités de leurs frères et sœurs à latence normale, notamment le chiffrement, l'insertion de publicités et le sous-titrage, qui ne sont pas universellement pris en charge dans les technologies WebRTC et WebSockets. Vous pouvez probablement implémenter la technologie à faible latence sélectionnée à l'aide de votre lecteur et de votre infrastructure de livraison existants, en minimisant les coûts de développement et autres coûts technologiques.
Choisir une technologie HTTP à faible latence
Il existe deux normes principales pour le streaming adaptatif HTTP, HLS et DASH, ainsi qu'un format de conteneur unificateur, CMAF. Une fois qu'Apple a annoncé sa solution HLS à faible latence, elle a instantanément déplacé plusieurs efforts de base et est devenue la technologie de choix pour fournir une faible latence à HLS. Bien que la spécification soit encore relativement nouvelle, elle est déjà prise en charge par des fournisseurs de technologie tels que Wowza et WMSPanel avec leur produit Nimble Streamer.
Il existe une norme DVB pour DASH à faible latence et le DASH Industry Forum a approuvé plusieurs modes à faible latence pour DASH à inclure dans leurs prochaines directives d'interopérabilité. Conformément à toutes ces spécifications, les développeurs d'encodeurs et de lecteurs et les réseaux de diffusion de contenu travaillent depuis plusieurs années pour assurer l'interopérabilité afin que toutes les applications DASH / CMAF à faible latence soient mises en marche.
À titre d'exemple, Harmonic et Akamai ont démontré ensemble une faible latence CMAF dès NAB et IBC 2017, montrant une livraison OTT en direct avec une latence inférieure à cinq secondes. Depuis, Harmonic a intégré la fonctionnalité DASH à faible latence dans ses produits basés sur des appliances (Packager XOS et Electra XOS) et dans ses solutions SaaS (VOS Cluster et VOS260). De nombreux autres fournisseurs d'encodeurs et de lecteurs ont fait de même.
Que vous choisissiez d'implémenter HLS à faible latence ou à faible latence pour DASH, ou les deux, la transition de votre architecture de livraison HLS et / ou DASH existante devrait être relativement transparente et peu coûteuse.
5. Communications en temps réel
WebRTC est généralement le moteur d'un package intégré qui comprend l'encodeur, le lecteur et l'infrastructure de livraison. Parmi les exemples de solutions de streaming à grande échelle basées sur le WebRTC, citons Real Time de Phenix, Limelight Realtime Streaming et Millicast de CoSMo Software et Influxis (Figure 3). Vous pouvez également accéder à la technologie WebRTC dans des outils tels que le moteur de streaming Wowza, le logiciel CoSMO et le serveur Red 5 Pro. Les temps de latence pour les technologies de cette classe vont de 0,5 seconde pour 71% des flux (Phenix), sous 500 millisecondes (Red5 Pro), à moins d'une seconde (Limelight). Si vous avez besoin d'une latence inférieure à deux secondes, WebRTC est une option que vous devez envisager.
Si vous avez besoin de communications en temps réel, vous devrez probablement mettre en œuvre une solution WebRTC ou Websockets. WebRTC a été formulé pour les communications de navigateur à navigateur et est pris en charge par tous les principaux navigateurs de bureau, sur Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 et BlackBerry 10, il devrait donc fonctionner sans téléchargement sur aucune de ces plates-formes. Comme son nom l'indique, WebRTC est un protocole permettant de diffuser des flux en direct à chaque spectateur, soit d'égal à égal, soit de serveur à poste.
WebSockets est un protocole en temps réel qui crée et maintient une connexion persistante entre un serveur et un client que chaque partie peut utiliser pour transmettre des données. Cette connexion peut être utilisée pour prendre en charge à la fois la diffusion vidéo et d'autres communications, ce qui est pratique si votre application a besoin d'interactivité. Comme les implémentations WebRTC, les services qui utilisent WebSockets sont généralement proposés en tant que service comprenant un lecteur et un CDN, et vous pouvez utiliser n'importe quel encodeur capable de transporter des flux vers le serveur via RTMP ou WebRTC. Les exemples incluent le nanoStream Cloud de Nanocosmos et le Streaming Cloud de Wowza avec une latence ultra faible. Wowza revendique une latence inférieure à 3 secondes pour leur solution, tandis que Nanocosmos revendique environ une seconde, verre à verre.
Autres technologies à faible latence
Il existe une quatrième catégorie de produits mieux nommée «autre» qui utilise différentes technologies pour fournir une faible latence. Cette catégorie comprend le protocole HESP (High Efficiency Streaming Protocol) de THEO Technologies, un protocole de streaming adaptatif HTTP propriétaire qui, selon THEO, offre une latence inférieure à 100 millisecondes tout en réduisant la bande passante d'environ 10% par rapport aux autres technologies à faible latence. HESP utilise des encodeurs et des CDN standard, mais nécessite une prise en charge personnalisée dans le conditionneur et le lecteur (Figure 4). Vous pouvez en savoir plus sur HESP dans un livre blanc disponible en téléchargement, ici.
Voici une liste de questions à prendre en compte lors du choix de la technologie à faible latence à implémenter et de la manière de le faire.
Construire ou acheter?
Si vous implémentez la technologie vous-même, assurez-vous de répondre à toutes les questions énumérées ci-dessous avant de choisir une technologie. Si vous choisissez un fournisseur de services, utilisez-le pour comparer les différents fournisseurs de services.
Vous choisissez un standard ou un partenaire?
Nous avons décrit ci-dessus les différentes technologies permettant d'obtenir une faible latence, mais les mises en œuvre varient d'un fournisseur de services à l'autre. Ainsi, toutes les implémentations de LL HLS n'intègreront pas la livraison ABR, du moins pas au début. La plupart des applications de diffusion traditionnelles migreront probablement vers des normes basées sur HTTP comme HLS / DASH / CMAF à faible latence, tandis que les applications nécessitant une latence ultra-faible comme les paris et les enchères se tourneront vers les autres technologies. Dans les deux cas, lors du choix d’un fournisseur de services, il est plus important de déterminer s’il peut atteindre vos objectifs technologiques et commerciaux que la technologie qu’il met en œuvre.
Peut-il évoluer et à quel prix?
L'un des avantages des technologies basées sur HTTP est qu'elles évoluent au prix standard en utilisant la plupart des CDN. En revanche, la plupart des technologies basées sur WebRTC et WebSocket nécessitent une infrastructure de livraison dédiée implémentée par le fournisseur de services. Pour cette raison, les services non basés sur HTTP peuvent être plus coûteux à fournir que HLS / DASH / CMAF. Lorsque vous comparez les fournisseurs de services, vérifiez le coût de l'événement, y compris l'entrée, le transcodage, la bande passante, la création de fichiers VOD, les configurations ponctuelles ou par événement, etc.
Problèmes liés à la mise en œuvre?
Posez les questions suivantes liées à la mise en œuvre et à l'utilisation de la technologie.
- Quelle est la latence réalisable à une échelle adaptée à la taille de votre audience et à la répartition géographique?
- Y a-t-il des limites de qualité - certaines technologies peuvent être limitées à certaines résolutions maximales ou profils H.264.
- Les paquets passeront-ils par un pare-feu? Les systèmes basés sur HTTP utilisent des protocoles HTTP, qui sont compatibles avec les pare-feu. D'autres utilisent UDP, qui peut ne pas passer automatiquement à travers les pare-feu. Si UDP, y a-t-il des backchannels à fournir aux téléspectateurs bloqués?
- Quelles plates-formes sont prises en charge? Vraisemblablement des ordinateurs et des appareils mobiles, mais qu'en est-il des décodeurs, des dongles, des appareils OTT et des téléviseurs intelligents?
- Le système peut-il évoluer pour répondre à votre nombre de spectateurs cible? L'infrastructure CDN est-elle privée et, dans l'affirmative, peut-elle être diffusée à tous les téléspectateurs concernés sur tous les marchés concernés? Quels sont les coûts prévus de la mise à l'échelle?
- Pouvez-vous utiliser votre propre lecteur ou devez-vous utiliser le lecteur du système? Si c'est le vôtre, quels changements sont nécessaires et combien cela coûtera-t-il?
- De quoi avez-vous besoin pour la lecture sur mobile? Les flux seront-ils lus dans un navigateur ou une application est-elle requise? Si une application est requise (ou souhaitable), des SDK sont-ils disponibles?
- Quels encodeurs le système peut-il utiliser? La plupart devraient utiliser n'importe quel encodeur capable de prendre en charge les connexions RTMP dans le transcodeur cloud, mais vérifiez si d'autres protocoles sont nécessaires.
- Le contenu peut-il être réutilisé pour la VOD ou un recodage sera-t-il nécessaire? Ce n'est pas un gros problème car il en coûte environ 20 $ / heure de vidéo pour transcoder vers une échelle de codage raisonnable mais cher pour les diffusions fréquentes.
- Quelles sont les options de redondance et quels sont les coûts? Pour les diffusions critiques, vous voudrez savoir comment dupliquer le flux de travail de codage / diffusion en cas de panne d'un composant du système pendant l'événement. Cette redondance est-elle prise en charge et quel en est le coût?
Quelles fonctionnalités sont disponibles et à quelle échelle?
Il y aura une grande variété d'offres de fonctionnalités des différents fournisseurs, qui peuvent ou non inclure:
- Diffusion ABR - combien de flux et y a-t-il des limitations de débit ou de résolution pertinentes?
- Qu'en est-il des fonctionnalités DVR? Les téléspectateurs peuvent-ils arrêter et redémarrer la lecture sans perdre aucun contenu?
- Synchronisation vidéo - Le système peut-il synchroniser tous les téléspectateurs au même point dans le flux? Les flux peuvent dériver sur les emplacements et les appareils, et sans cette capacité, les utilisateurs sur certaines connexions peuvent avoir un avantage pour les enchères ou les jeux d'argent.
- Quelle protection de contenu est disponible? Si vous êtes un producteur de contenu premium, vous aurez peut-être besoin d'un véritable DRM. D'autres peuvent se débrouiller avec l'authentification ou d'autres techniques similaires.
- Les légendes sont-elles disponibles? Les sous-titres sont légalement obligatoires pour certaines émissions, mais généralement bénéfiques pour tous.
- Qu'en est-il de l'insertion publicitaire ou d'un autre schéma de monétisation? Le fournisseur de technologie / service prend-il en charge cela?
En général, si vous êtes un magasin de streaming cherchant à atteindre ou à battre des temps de diffusion de l'ordre de 5 à 6 secondes, une technologie HTTP basée sur des normes est probablement votre meilleur pari, car elle se rapprochera le plus de la prise en charge du même ensemble de fonctionnalités que vous. vous utilisez actuellement, comme la protection du contenu, les sous-titres et la monétisation. Si votre application nécessite une latence beaucoup plus faible, vous aurez probablement besoin d'une solution WebRTC ou Websockets, ou d'une technologie HTTP propriétaire. Dans les deux cas, poser les questions énumérées ci-dessus devrait vous aider à identifier la technologie et / ou le fournisseur de services qui répond le mieux à vos besoins.