L'essentiel à connaître
Un direct suit toujours la même chaîne : l'encodeur compresse l'image et le son, la contribution envoie ce flux au serveur, la distribution le livre à chaque spectateur. Exemple : ton encodeur compresse la caméra en H.264, une norme de compression vidéo, et pousse le flux en RTMP vers la plateforme, qui le redécoupe en petits fichiers HLS, les segments. Pour envoyer, seul ton débit montant (upload) compte : il doit dépasser celui du flux, avec de la marge.
En contribution, RTMP passe par TCP, qui renvoie tout paquet perdu, quitte à prendre du retard. SRT (Secure Reliable Transport) passe par UDP, qui envoie sans attendre de confirmation, et redemande lui-même les paquets perdus dans une latence fixe. Cette latence se règle à 3 ou 4 fois le RTT, le temps d'aller-retour d'un paquet (The SRT Protocol, 2021).
En distribution, HLS fonctionne en « pull » : le lecteur télécharge une playlist, puis les segments un par un, en HTTP. Le serveur transcode le direct (il le réencode en plusieurs versions de débits différents) et le lecteur passe de l'une à l'autre selon sa connexion : c'est le débit adaptatif. Un CDN, réseau de serveurs répartis près des spectateurs, sert ces fichiers à tous sans surcharger le serveur d'origine.
Définition : Une image clé (IDR) est une image complète, décodable seule ; les autres images ne codent que leurs différences avec les précédentes. Apple impose que chaque segment HLS commence par une image clé (spécification HLS d'Apple, révision 2025).
Formule : volume en octets $V = \dfrac{D \times t}{8}$ ($D$ en bit/s, $t$ en s) ; intervalle d'images clés compté en images $N = f \times T$ ($f$ en images par seconde, $T$ en s).
À retenir : Apple recommande une image clé toutes les 2 s et des segments de 6 s. En HLS classique, la RFC 8216 (2017) demande au lecteur de ne pas démarrer à moins de trois durées de segment de la fin de la playlist.
Quiz : teste tes connaissances
Les questions montent en difficulté, et les trois dernières sont les plus piégeuses.
Question 1 : Dans quel ordre le flux d'un direct traverse-t-il la chaîne ?
Réponse : C. Le signal est compressé, envoyé au serveur, puis distribué aux spectateurs par le CDN. Le piège A inverse les deux trajets : ici, RTMP sert à envoyer depuis la régie, HLS à livrer aux spectateurs.
Question 2 : Quel est le rôle de l'encodeur ?
Réponse : A. Une image HD non compressée est bien trop lourde pour Internet : l'encodeur la ramène à quelques mégabits par seconde. Le piège B décrit le travail du serveur, qui segmente le flux après l'avoir reçu.
Question 3 : Ton test de connexion affiche 300 Mbit/s en descendant et 4 Mbit/s en montant. Ton flux fait 6 Mbit/s. Que conclus-tu ?
Réponse : D. Diffuser, c'est envoyer : seul le débit montant compte. Le piège A lit le mauvais chiffre du test. Il faut baisser le débit du flux nettement sous 4 Mbit/s, ou changer de connexion.
Question 4 : Pour livrer un direct à des milliers de spectateurs, sur navigateur et sur téléphone, quel protocole choisis-tu ?
Réponse : B. HLS passe par HTTP : ses segments sont de simples fichiers, que tout serveur web ou CDN sait servir en masse. Le piège C confond les trajets : SRT sert au trajet de la régie au serveur, pas à servir une foule de lecteurs.
Question 5 : En plein direct HLS, la connexion d'un spectateur faiblit. Que fait le débit adaptatif ?
Réponse : B. Le serveur a préparé plusieurs versions, listées dans une playlist principale, et c'est le lecteur qui choisit celle que sa connexion supporte. Le piège A dégraderait l'image de tous pour un seul spectateur : l'encodeur ne les connaît pas.
Question 6 : Ton direct passe de 100 à 50 000 spectateurs. À quoi sert le CDN ?
Réponse : D. Chaque spectateur télécharge les segments près de chez lui, et le serveur d'origine ne reçoit qu'une petite part des requêtes. Le piège A décrit le transcodage, qui se fait avant la distribution.
Question 7 : Pourquoi chaque segment HLS doit-il commencer par une image clé ?
Réponse : A. Un spectateur qui arrive en cours de direct, ou qui change de version, part d'un segment isolé : il lui faut une image complète pour démarrer. Le piège D est à l'envers : l'image clé, complète, est en général la plus lourde du segment.
Question 8 : SRT veut dire Secure Reliable Transport. D'où vient sa fiabilité sur un réseau 4G instable ?
Réponse : C. Le récepteur signale les paquets manquants et l'émetteur les renvoie, tant que la latence réglée en laisse le temps. Le piège A confond « fiable » et TCP : c'est RTMP qui passe par TCP.
Question 9 : Ton encodeur attend l'intervalle d'images clés en images, pas en secondes. Tu filmes à 25 images par seconde et tu vises une image clé toutes les 2 s. Que saisis-tu ?
Réponse : D. $N = f \times T = 25 \times 2 = 50$ images. Le piège A recopie les secondes dans un champ qui attend des images : une image sur deux serait une image clé, et le débit serait gaspillé.
Question 10 : Entre ta régie mobile et le serveur, le RTT vaut 80 ms. Avec la règle de 3 à 4 fois le RTT, quelle latence SRT règles-tu ?
Réponse : A. $3 \times 80 = 240$ ms et $4 \times 80 = 320$ ms : de quoi signaler une perte et renvoyer le paquet, parfois plus d'une fois. Le piège B ne laisse qu'un aller-retour : un paquet perdu, une fois renvoyé, arrive trop tard, et SRT l'abandonne.
Question 11 : Tu enregistres un direct d'une heure à 6 Mbit/s, son compris. Quelle place occupe le fichier ? Un octet vaut 8 bits, et 1 Go vaut 1 000 Mo.
Réponse : C. $6 \times 3\,600 = 21\,600$ Mbit, puis $21\,600 \div 8 = 2\,700$ Mo, soit 2,7 Go. Le piège A oublie de diviser par 8 : un débit se compte en bits (b minuscule), une taille de fichier en octets (o).
Question 12 : Ton direct part en HLS classique, avec des segments de 6 s. Au plus près, à combien de secondes de la fin de la playlist le lecteur peut-il démarrer ?
Réponse : B. La RFC 8216 demande au lecteur de ne pas démarrer à moins de trois durées de segment de la fin : $3 \times 6 = 18$ s, avant même d'ajouter l'encodage et l'envoi. Le piège A croit qu'un segment d'avance suffit ; le piège C compte trois secondes au lieu de trois segments.
Sources
RFC 8216, HTTP Live Streaming, août 2017.
Apple, HLS authoring specification for Apple devices, révision du 26 juin 2025.
The SRT Protocol, Internet-Draft soumis à l'IETF, septembre 2021.