Commencez par séparer le protocole, le transport et le conteneur

Les termes HLS, FLV, HTTP-FLV et RTMP sont souvent utilisés comme s'ils décrivaient la même couche. Ce n'est pas le cas.

• HLS (HTTP Live Streaming) est un protocole de diffusion de médias développé à l'origine par Apple. Il utilise des listes de lecture et une séquence de segments de médias diffusés via HTTP ou HTTPS.

• FLV (Flash Video) est un format de conteneur qui peut transporter de l'audio et de la vidéo encodés. FLV en lui-même ne définit pas comment un flux circule sur le réseau.

• HTTP-FLV maintient le flux FLV ouvert sur une connexion HTTP. Le lecteur reçoit les médias en continu au lieu de demander une liste de lecture et des segments séparés.

• RTMP est un protocole de streaming distinct historiquement associé à Flash. Il reste courant du côté de la contribution ou de l'ingestion, même lorsque les spectateurs reçoivent du HLS ou un autre format de sortie.

Cette distinction est importante lors de la conception du système. Une plateforme peut accepter RTMP depuis un encodeur, traiter la source une fois, et publier des sorties HLS et HTTP-FLV pour différents groupes de spectateurs. Choisir une méthode de diffusion ne nécessite donc pas nécessairement de changer la caméra, l'encodeur ou le protocole de contribution amont.

Pourquoi la diffusion segmentée fonctionne bien à grande échelle

HLS divise un programme en direct ou à la demande en segments de médias et les liste dans une liste de lecture M3U8. Les déploiements traditionnels utilisent couramment des segments MPEG-2 Transport Stream, généralement identifiés par l'extension .ts. Le HLS moderne peut également utiliser du MP4 fragmenté (souvent appelé fMP4), qui fournit une base pratique pour les flux de travail d'encodage et de conditionnement contemporains. L'audio et les sous-titres peuvent être proposés en tant que renditions séparées aux côtés de la vidéo.

Étant donné que les listes de lecture et les segments sont des ressources HTTP ordinaires, ils peuvent être servis par des serveurs web standard, des proxy inverses et des réseaux de diffusion de contenu. Les caches périphériques peuvent conserver les segments populaires près des spectateurs, ce qui réduit le trafic répété vers l'origine. Cela fait de HLS un bon choix pour les événements publics en direct, les portails de formation, les applications mobiles et les services avec des audiences géographiquement dispersées.

La diffusion à débit binaire adaptatif est un autre avantage majeur. La plateforme prépare plusieurs versions du même programme à différentes résolutions et débits. En fonction du débit actuel, de l'état du tampon et des capacités de l'appareil, le lecteur peut basculer entre ces variantes pour maintenir une lecture stable. Un spectateur sur une connexion mobile changeante peut recevoir une version de résolution inférieure au lieu de subir une interruption complète.

La contrepartie est que la lecture HLS classique attend généralement la création des segments, les mises à jour de la liste de lecture et un tampon de lecture. Le délai réel dépend de la durée des segments, de la conception de la liste de lecture, des paramètres du lecteur et des conditions réseau. Le Low-Latency HLS peut réduire ce délai, mais il nécessite un support coordonné entre le conditionneur, l'origine, le CDN et le lecteur. Il doit être considéré comme un choix de bout en bout plutôt qu'un simple interrupteur ajouté à la dernière étape.

La durée des segments doit être choisie en fonction de l'objectif du service. Des segments plus courts peuvent aider le lecteur à découvrir plus rapidement les nouveaux médias, mais ils augmentent également les mises à jour de la liste de lecture, les requêtes d'objets et la charge de conditionnement. Des segments plus longs réduisent la fréquence des requêtes et peuvent améliorer l'efficacité de la diffusion, mais ils peuvent augmenter le temps de démarrage et rendre les changements de qualité moins réactifs. L'intervalle des images clés de l'encodeur doit suivre le plan de conditionnement afin que chaque rendition expose des points de commutation nets aux mêmes positions.

Où un flux HTTP continu reste pertinent

HTTP-FLV envoie des balises FLV via une réponse HTTP de longue durée. Une fois la lecture commencée, les données média continuent d'arriver sur la même connexion. Il n'y a pas de liste de lecture de segments à rafraîchir, donc un système correctement ajusté peut généralement rester plus proche de la source live qu'un flux de travail segmenté classique.

Ce comportement est utile dans les applications destinées aux opérateurs où les personnes doivent observer les événements et réagir rapidement : pages de surveillance vidéo, tableaux de bord de production, supervision d'équipements, inspection à distance et systèmes internes de visualisation en direct. Il peut également simplifier la diffusion via des réseaux qui autorisent déjà le trafic HTTP ou HTTPS.

Cependant, il ne faut pas confondre HTTP-FLV avec le support vidéo natif du navigateur. La fin d'Adobe Flash Player a supprimé l'ancien chemin de lecture via plugin : Adobe a mis fin au support de Flash Player le 31 décembre 2020 et a commencé à bloquer le contenu Flash le 12 janvier 2021. La lecture HTTP-FLV moderne repose donc sur un lecteur HTML5, utilisant généralement JavaScript pour analyser le flux FLV et une API média du navigateur pour alimenter les codecs audio et vidéo pris en charge dans le décodeur.

Cela crée une dépendance de compatibilité. Le navigateur doit prendre en charge l'API média requise et les codecs transportés dans le conteneur FLV. Par conséquent, HTTP-FLV est mieux adapté aux clients web contrôlés et aux applications dédiées qu'à un public public non restreint. Un grand nombre de connexions continues peut également exercer une pression plus soutenue sur le serveur de diffusion et les équipements réseau intermédiaires que les objets segmentés compatibles avec le cache.

Adaptez le chemin de diffusion à l'exigence de visualisation

Une décision de protocole doit commencer par les exigences opérationnelles, et non par une liste de contrôle de fonctionnalités. La comparaison suivante fournit un point de départ utile.

Utilisez HLS comme sortie principale lorsque la taille de l'audience est imprévisible, que les spectateurs utilisent une large gamme d'appareils, que la continuité de la lecture est plus importante que l'immédiateté, ou que la diffusion via CDN fait partie du plan. Utilisez HTTP-FLV lorsque la plateforme contrôle le lecteur web, que l'audience est connue, que le nombre de spectateurs simultanés est gérable et que la réduction du délai de visualisation en direct a une valeur opérationnelle claire.

Avant d'approuver l'un ou l'autre chemin, définissez un budget de délai pour chaque étape : capture, encodage, ingestion réseau, traitement des médias, distribution, mise en tampon par le lecteur et décodage. Cela évite que le protocole de diffusion soit blâmé pour des délais introduits ailleurs. Une sortie à faible latence ne peut pas compenser un encodeur avec un GOP long, un transcodeur surchargé ou un lecteur configuré avec un grand tampon de sécurité. Mesurez le résultat sur le point d'extrémité réel et le réseau utilisés en production.

Aucune des deux options ne convient à toutes les formes de communication en temps réel. Si les utilisateurs doivent mener une conversation bidirectionnelle ou utiliser un appareil avec des contraintes de temps d'interaction très serrées, une technologie de communication en temps réel peut être plus appropriée. L'important est de séparer la distribution vidéo unidirectionnelle des médias interactifs avant de choisir l'architecture de diffusion.

Une conception hybride couvre plus d'utilisateurs sans dupliquer la source

De nombreux projets n'ont pas besoin d'une décision exclusive. Une plateforme hybride peut ingérer une source, normaliser les horodatages et les codecs, puis conditionner des sorties séparées pour différents clients.

1. Acquérez la source. Recevez la vidéo en direct d'une caméra, d'un encodeur, d'une passerelle ou d'une plateforme amont via le protocole de contribution pris en charge par l'équipement terrain.

2. Inspectez les médias. Vérifiez le codec, la résolution, la fréquence d'images, le format audio et la continuité des horodatages avant de décider si le flux peut être reconditionné ou doit être transcodé.

3. Créez les renditions de diffusion. Produisez une échelle de débits adaptative pour HLS. Générez une sortie HTTP-FLV uniquement pour les clients qui en ont besoin et qui peuvent décoder son profil média.

4. Séparez les chemins d'audience. Envoyez HLS via une origine et un CDN pour une visualisation externe ou à grande échelle. Acheminez HTTP-FLV via un cluster de diffusion contrôlé pour les utilisateurs des opérations.

5. Appliquez des contrôles d'accès. Utilisez HTTPS, des autorisations de courte durée, une protection de l'origine et des politiques de session appropriées à chaque chemin.

6. Mesurez la chaîne complète. Surveillez la continuité de l'ingestion, la charge de transcodage, les erreurs de conditionnement, le temps de la première image, la mise en tampon, les déconnexions et le délai de bout en bout.

Ce modèle évite de forcer chaque client à un même compromis. Les spectateurs publics reçoivent un flux résilient et scalable, tandis que les opérateurs peuvent utiliser un chemin à plus faible latence. La plateforme média devient également le point où les formats source hérités sont convertis en sorties que les navigateurs et applications actuels peuvent consommer.

Choisir entre reconditionnement et transcodage

Si les codecs entrants correspondent déjà au profil de diffusion, la plateforme peut n'avoir qu'à reconditionner les médias compressés. Le reconditionnement modifie le conteneur ou la structure de sortie sans décoder ni encoder chaque image, il consomme donc généralement moins de ressources de traitement et préserve la qualité source. Il n'est approprié que lorsque la prise en charge des codecs, les horodatages, le placement des images clés et les paramètres audio sont déjà adaptés aux lecteurs cibles.

Le transcodage est nécessaire lorsque le codec source ne peut pas être décodé par le client visé, lorsque plusieurs résolutions et débits sont nécessaires, ou lorsque la fréquence d'images, le format audio et la structure des images clés doivent être normalisés. Il ajoute un coût de calcul et un délai de traitement, donc la capacité doit être calculée pour le pic de canaux simultanés plutôt que pour une utilisation moyenne. L'accélération matérielle peut augmenter la densité de canaux, mais la qualité et le comportement de la sortie doivent encore être testés avec le lecteur choisi.

Les systèmes de production doivent également éliminer les points de défaillance uniques. Utilisez des origines redondantes, une reconnexion contrôlée du lecteur et des règles de basculement testées sans créer de boucles de reprise agressives qui amplifient une panne.

Vérifications de déploiement qui évitent les pannes évitables

La seule sélection du protocole ne garantit pas un service fiable. Avant le lancement, vérifiez l'ensemble du chemin des médias et du réseau.

• Confirmez la prise en charge des codecs au point d'extrémité. Un transport peut atteindre le lecteur avec succès alors que la lecture échoue parce que le navigateur ne peut pas décoder le profil audio ou vidéo.

• Maintenez des horodatages continus. Des horodatages corrompus ou non monotones peuvent provoquer des saccades, une dérive audio et des changements de qualité échoués.

• Alignez les images clés avec les règles de conditionnement. Les renditions HLS doivent utiliser des limites d'images clés coordonnées afin que le lecteur puisse changer de qualité sans interruption visible.

• Prévoyez HTTPS de la source au lecteur. Les pages sécurisées ne doivent pas demander de médias non sécurisés, et les certificats doivent être valides sur les couches d'origine et de distribution.

• Testez des conditions réseau réelles. Validez le démarrage, la récupération et les changements de qualité sous bande passante limitée, perte de paquets et courtes interruptions, plutôt que de tester uniquement sur un réseau local.

• Dimensionnez en fonction du comportement des connexions. La planification de la capacité HLS se concentre fortement sur les requêtes de segments, le stockage et le taux de hit du cache. La planification HTTP-FLV doit tenir compte des connexions simultanées de longue durée et du trafic sortant soutenu.

• Fournissez une politique de repli. Si le lecteur ou le format préféré n'est pas disponible, l'application doit renvoyer une alternative prise en charge ou une erreur claire au lieu de réessayer indéfiniment.

Pour la plupart des services tournés vers l'extérieur, HLS est le choix par défaut le plus sûr car il combine la lecture à débit adaptatif avec une distribution HTTP mature. HTTP-FLV reste utile là où un lecteur géré et une latence plus faible sont plus importants que la portée universelle. Une architecture hybride est souvent la réponse la plus pratique lorsque la même source live doit servir les deux groupes.

Peut-on ajouter des sous-titres à un flux de travail de diffusion en direct ?

Oui. Les sous-titres peuvent être générés en amont ou insérés lors du traitement des médias. Pour HLS, les renditions de sous-titres WebVTT sont une option courante. Un lecteur HTTP-FLV personnalisé peut nécessiter un canal de texte synchronisé séparé et sa propre logique de synchronisation.

Les spectateurs peuvent-ils revenir en arrière pendant qu'un événement en direct est toujours en cours ?

Ils le peuvent si le service maintient une fenêtre live suffisamment longue et que le lecteur expose des contrôles de décalage temporel. La fenêtre de rétention, la capacité de stockage et les droits sur le contenu doivent être définis avant d'activer le retour en arrière en direct.

Un lecteur peut-il basculer sur l'audio uniquement lorsque la bande passante vidéo n'est pas disponible ?

Oui, à condition que la plateforme publie une version audio uniquement ou un flux audio séparé, et que le lecteur soit configuré pour le sélectionner. Cela peut préserver les commentaires critiques ou les instructions sur des connexions très limitées.

L'analyse peut-elle distinguer une sortie de spectateur d'une panne réseau ?

Pas à partir d'un seul événement de déconnexion. Combinez les événements du lecteur, les intervalles de battement de cœur, les identifiants de session, le comportement de reprise et les journaux de connexion du serveur pour classer les sorties avec plus de confiance.

Que doit-il arriver à une URL live après la fin d'un événement ?

La plateforme peut fermer la session live, publier un écran de fin, ou rediriger les utilisateurs vers un programme archivé une fois le traitement terminé. Définissez la transition à l'avance afin que les lecteurs intégrés et les liens partagés n'échouent pas sans explication.