Ce billet est le second d’une série de 5 :

1. introduction et considérations pour le SSTIC ;
2. l’architecture de streaming ;
3. la chaîne de capture audio/vidéo sur place ;
4. le transcodage des flux en différentes qualités ;
5. les serveurs frontaux accédés par les internautes.

Aperçu général

L’architecture a été divisée de manière à pouvoir anticiper plusieurs évolutions, comme la diffusion sur place en multi-salles ou sur écrans, l’ajout à la volée de nouveaux serveurs frontaux en cas de forte affluence, ou même encore la diffusion vers un service tiers tel que justin.tv (désormais devenu Twitch) ou YouTube.

Il y a trois composantes principales que vous retrouvez sur le schéma ci-dessous :

On y retrouve :

• la chaîne de capture audio/vidéo sur place (en vert à gauche) ;
• le transcodage des flux en différentes qualités (en bleu au centre) ;
• les serveurs frontaux accédés par les internautes (en rouge à droite).

Le schéma décrit également un résumé des flux vidéos induits par la configuration des serveurs RTMP.

Chacune de ces composantes est traîtée dans un billet dédié permettant d’en reproduire le fonctionnement (cliquez sur les liens ci-dessus pour y accéder directement).

Avantages

Il est possible d’adapter les trois composantes principales en fonction des moyens (financiers et matériels) :

• si le débit disponible en upload vers internet le permet, le transcodage peut être effectué sur place, avec du matériel grand public (un second ordinateur par exemple, même portable) ;
• le nombre de serveurs frontaux peut être augmenté rapidement pour faire face à l’afflux de spectateurs, et leur seul pré-requis est de disposer d’une bande bassante suffisante (nous avons toujours utilisé deux serveurs frontaux disposant de 1 Gbit/s chacun, pouvant ainsi supporter environ 2000 spectateurs) ;
• il est possible de placer un serveur relais en interne d’un réseau d’entreprise afin de limiter la saturation d’une connexion à Internet : il s’agit simplement d’un serveur avec la même configuration que nos frontaux ;
• une diffusion locale à l’évènement peut facilement être mise en place : la configuration d’un serveur frontal peut être adaptée pour monter une machine relais interne (un Raspberry Pi suffira) avec un pass-through vers le serveur de transcodage et en même temps diffuser les flux sur un LAN local (pour un écran avec VLC par exemple) ;
• si les cartes d’acquisition HDMI / VGA viennent à manquer, il est possible d’installer le logiciel de capture directement sur le poste de présentation, d’y encoder le flux de l’écran, et de le transmettre en interne vers le poste de composition et d’encodage final (une solution similaire a été utilisée de 2015 à 2017, voir plus bas) ;
• il est possible d’avoir une chaine de capture minimaliste avec uniquement deux ordinateurs portables, une webcam, une entrée audio et un LAN entre les deux : un ordinateur pour l’orateur qui capturera l’écran, l’autre avec la webcam et l’audio pour filmer la scène et mixer le flux RTMP venant du PC de l’orateur avec la vidéo et l’audio de l’orateur ;
• enfin, toutes les possibilités précédentes permettent de s’adapter aux contraintes de la salle : position des sources, distance des câbles, etc. En effet, les câbles VGA, RCA ou jack ont des limites de distance relativement faibles, il devient possible de poser un ordinateur près de la source, et de monter un réseau pour streamer les différentes sources vers le poste de composition / encodage final.

La seule limite est la complexité de la synchronisation des différentes sources audio et vidéo.

Historique

Pour la première utilisation en 2014, l’architecture ressemblait déjà fortement à l’actuelle. Dans les mois qui ont précédé la conférence, elle fut inspirée de justin.tv, l’ancêtre de Twitch, service bien connu des amateurs de jeu vidéo en ligne (en particulier ce write-up datant de 2010).

La même architecture que celle du SSTIC 2014 a été utilisée par NSC lors de sa dernière édition en novembre 2014. À vrai dire, il s’agissait des mêmes serveurs et des mêmes cartes de capture, les frontaux ont été mis à disposition par des membres des comités d’organisation.

Pour l’histoire, l’aventure du streaming a même débuté sur IRC, le vendredi 11 avril 2014 (6 jours avant l’ouverture de la billetterie et moins de deux mois avant la conférence) :

<     co1 > je suis tellement à l'arrache que je sais pas où on en est
<  troll1 > faudra faire une reorg de l'orga du sstic !
<     co1 > si y a des volontaires motivés pour rentrer dans le CO, dites le moi!
<   anon1 > co1: ça consiste en quoi ?
<   anon1 > enfin y'a quoi à faire :)
<     co1 > Gérer les inscriptions par exemple, coder du Python pour le site Web ou générer les factures, organiser le challenge, intégrer les actes LaTeX, faire la logistique sur place, avoir de nouvelles idées pour que le SSTIC se renouvelle
<     co1 > Si t'es pas blasé par la vie, y a plein de trucs à faire ou d'idées à pousser
<     co1 > comme se lancer dans le streaming des conférences
< bonaldi > ptain le streaming
< bonaldi > je viens de tester ça, c'est bien bien chiant
<   anon4 > tu crées un compte sur twitch.tv et yolo
< bonaldi > non mais streamer depuis linux tu oublies déjà
<   anon4 > pas besoin d'oublier, j'y avais même pas pensé :)
<   anon4 > pourtant ça a pas l'air la mort, les gamers qui publient leur stream semblent pas des dieux de l'informatique
<   anon3 > < bonaldi >  non mais streamer depuis linux tu oublies déjà
<   anon3 > j'avais mis ça en place y'a 10 ans
<   anon3 > ça marchait !
< bonaldi > ouais, moi aussi
< bonaldi > mais pas avec des tcus funkys pour twitch, mais via du vlc server
<   anon4 > pourtant ça a pas l'air la mort, si tu as un flux vidéo, VLC est limite fait pour ça
<   anon4 > le soucis si tu fais tout tout seul c'est la bande passante ...
< bonaldi > ouais mais pour une conf tu veux faire de la composition : les slides + la tronche du mec
<   anon4 > ahhhh
<   anon4 > ouais non
< bonaldi > donc il te faut de l'acquisition, un soft de compositing
<   anon4 > bah franchement, un stream avec caméra fixe qui marche, c'est mieux qu'un projet de stream de malade
< bonaldi > la distance avec tes sources fait bien chier avec les softs click-click, parce que tu passes par du matos un peu plus pro que les webcams de gamers
<   anon4 > le plus important c'est la prise de son
<   anon4 > si les slides sont téléchargeables à côté
<  troll1 > les slides tu les as sur l'ecran derriere le speaker :)
< bonaldi > c'est pas optimal
<   anon4 > je suis d'accord que ce n'est pas optimal, mais j'ai déjà regardé des enregistrements faits avec une caméra de merde sur trépied + un micro déporté, et c'est 10000000x mieux que de ne rien avoir
<   anon4 > le mieux est l'ennemi du bien, tout ça
<   anon4 > (pour le coup c'était pas du streaming)
<     co1 > c'est plutôt pour l'année prochaine
<  troll2 > au debut c'etait enregistré en video
<     co1 > c'était un service de l'ESAT il me semble
<     co1 > en plus de leur salle secrète //
< bonaldi > et eux ils savaient streamer !
<  troll3 > ah ah les gens qui galèrent à streamer
<  troll3 > alors que Google Hangout On Air est gratuit, streamé sur YouTube, et tu as le droit à 8h en continu par session
<  troll2 > c fort
<  troll3 > pro tip: le podcast NoLimitSecu fonctionne comme ça :)

Certaines idées furent progressivement reprises de cette discussion : filmer l’orateur et l’écran de projection derrière (2014), capture des slides et incrustation de l’orateur (2015). D’autres par contre, n’ont pas été retenues, comme l’usage de services tiers pour la diffusion : nous préférons maîtriser toute la chaîne, mais aussi permettre aux auteurs de ne pas se retrouver sur des plateformes de géants du net sans leur accord explicite. En effet, leur contrat de cession de droit avec l’association ne couvre pas la publication des vidéos sur YouTube, mais uniquement sur le site de la conférence.

Dès la seconde utilisation en 2015, les slides des orateurs sont capturés directement à la source, grâce à l’achat de la fameuse chaîne d’adaptateurs et doubleurs VGA et HDMI. L’architecture utilise alors deux ordinateurs dans la salle :

Au top de la débrouillardise, en 2017, le SSTIC a connu une architecture de capture impliquant 3 ordinateurs en plus de celui de l’orateur :

• on souhaitait laisser la possibilité à l’orateur d’utiliser son ordinateur pour éventuellement effectuer des démos : un ordinateur utilisait donc une carte de capture HDMI pour joueurs (Elgato Game Capture HD) capturant les slides (ce qui impliquait de dupliquer le flux VGA et de le convertir en HDMI) ;
• un ordinateur capturait le flux vidéo de la caméra et le flux audio provenant de la console de mixage de la salle ;
• chacun des ordinateurs précédents encodait leur capture en un flux RTMP, ceux-ci étant streamés en local vers un troisième ordinateur qui les recevait et les rejouait en local afin de composer le picture-in-picture (slides et caméra en incrustation) dans un logiciel de capture et d’encodage final.

Cette solution a engendré d’innombrables défis de synchronisation du son et des différentes vidéos (slides / caméra), parfois dus à des causes inattendues :

• buffers des drivers des cartes de capture ;
• buffers du module RTMP pour nginx ;
• buffers de mplayer / ffmpeg ;
• buffer du logiciel de composition peu stable ;
• désynchro son due au lag de quelques frames de la sortie HDMI du 5D Mark III ;
• désynchro vidéo/son due à des bugs de Mac OS X sur la synchronisation verticale  lors de rendus vidéo (pro-tip : la consommation CPU baisse lorsque la fenêtre de rendu vidéo n’a plus que quelques pixels de visibles, mais elle reste capturable dans son intégralité) ;
• désynchro due à de multiples recaptures des flux vidéos en raison de l’instabilité de la fonctionnalité de source RTMP dans OBS Studio (en 2015, les flux des deux postes de capture étaient rejoués en local sur le poste d’encodage final avec mplayer).

Chaîne de capture audio/vidéo

La chaîne de capture a peu évolué avant l’édition 2018. La pression des inscriptions nous contraignait à chercher une nouvelle salle : dès lors, il était inutile d’investir dans du matériel professionnel quand on savait que la nouvelle salle aurait probablement une installation vidéo flambant neuve.

2014-2017 : version MacGyver

Les recettes réalisées à chaque édition pouvant parfois être négatives, le SSTIC a initialement fait avec les moyens du bord, la plupart prêtés par les membres de l’association, et du petit matériel acheté en propre (adaptateurs, câbles…).

Entre 2014 et 2017, le matériel de capture était :

• caméra : Canon 5D Mark III, pour les performances en faible luminosité mais surtout pour sa sortie HDMI 1080p «propre» (sans menus, image brute) ;
• cartes de capture : Elgato Game Capture HD, en raison de son entrée son analogique mixable avec l’entrée HDMI et du «pass-through» HDMI. La carte coutait environ 150 euros à l’époque ; elle n’est plus disponible et n’a pas d’équivalent immédiat dans la même gamme de prix aujourd’hui.

Ces deux choix ont contraint la suite :

• la salle n’ayant qu’un projecteur VGA, il fallait convertir le flux des slides soit de VGA vers HDMI après duplication à la source, soit de HDMI vers VGA après le pass-through de la carte de capture. Cette dernière option s’est révélée la moins stable ;
• le matériel de conversion VGA-HDMI peut s’avérer très couteux alors que nous savions que la future salle aurait des câbles HDMI de bout en bout. Le choix se pose entre un frame-grabber VGA, au risque d’avoir un framerate limité (10-15 images / seconde), et un «upscaler» VGA vers HDMI. Ce dernier se trouve pour quelques dizaines de dollars sur des sites asiatiques, et s’est avéré être une solution étonnamment fiable ;
• le fait que la carte de capture gère mal certaines résolutions nous a contraint à placer l’upscaler avant celle-ci, afin de lui fournir un flux garanti en 720p. Ceci nous a donc contraint à doubler le flux VGA avant la capture avec un doubleur passif : le signal perd en puissance et certains projecteurs ne détectent plus l’entrée.

Par chance, les projecteurs des deux salles où la conférence s’est déroulée l’ont supporté. En contrepartie, la luminosité de la projection était affaiblie et la netteté de l’image était impactée. L’explication a été détaillée dans une rump lors de l’édition 2016 : «Pourquoi c’est flou ?».

2018 : version professionnelle

Pour l’édition 2018, le couvent des Jacobins met à disposition une régie audio/vidéo dernier cri : les slides nous arrivent directement en HDMI ou en SDI (au choix) et le son est câblé en XLR ou en RCA.

La rump «Pourquoi c’est flou^W net?» introduit la révolution.

Le matériel de capture est désormais :

• caméra : toujours le Canon 5D Mark III, désormais éprouvé, avec le firmware Magic Lantern ;
• objectif : un 70-200mm f/2.8 avec doubleur de focale (l’ouverture effective est donc de f/5.6) pour couvrir la profondeur plus importante de la salle mais ne pas nécessiter une puissance trop importante des lumières de scène (l’éclairage est très perturbant pour les orateurs). Si besoin, le firmware Magic Lantern permet de configurer la capture vidéo du 5D Mark III en mode «crop», plutôt que d’utiliser toute la surface du capteur : il est alors possible de bénéficier d’un zoom 3x sans perte de qualité en 1080p, et donc d’un équivalent 210-600mm mais à f/2.8 ;
• cartes de capture : deux Blackmagic Ultrastudio 4K 2. Elles ont coûté à l’association environ 950 euros TTC l’unité. Les raisons de ce choix sont détaillées plus bas.

L’un des problèmes du système de capture précédent était l’emploi de multiples ordinateurs d’encodage. L’emploi de cartes d’encodage professionnelles permet de n’utiliser plus qu’un seul ordinateur pour faire la composition finale, et de garantir la bonne synchronisation des flux audio et vidéo. De plus, cela permet de décharger le CPU du portable qui ne fera plus que deux décodages et un encodage.

Les cartes Blackmagic peuvent être soit internes en PCI Express, soit externes en Thunderbolt ou USB3 type C. Elles présentent l’avantage d’avoir des pilotes supportés sur Linux, macOS et Windows, et elles sont gérées comme source par OBS Studio (logiciel libre) sur ces trois OS.

Nous avons besoin de deux sources vidéo distinctes dans notre logiciel de composition : les slides et la scène. Certaines cartes internes «DeckLink» du même constructeur permettent de capturer plusieurs flux vidéos en parallèle et de les servir comme des sources distinctes. Les cartes externes, même si elles présentent plusieurs interfaces vidéo (SDI, HDMI et analogique), ne présentent qu’une seule source, les boutons en façade permettant de changer l’entrée vidéo active (utilisé en 2018 pour basculer entre une caméra fixe cadrant le pupitre et le 5D Mark III pour les plans mobiles).

Nous avons choisi de prendre deux cartes externes : une première pour les slides et l’audio du poste de présentation en HDMI et en XLR, et une seconde pour la scène et l’audio des micros. En effet, l’option permettant de tout faire avec une seule carte nécessite l’achat d’un PC tour complet dédié à l’encodage et ne serait pas pratique à déplacer à chaque édition. De plus, l’emploi d’ordinateurs portables permet d’avoir un spare qui sera utilisé en 2019 pour servir de PC du présentateur (avec la garantie qu’il marche sur le projecteur).

Deux PC portables de configuration identique seront donc utilisés. La carte Blackmagic Ultrastudio 4K 2 présente une connectique Thunderbolt «Apple» (mini DisplayPort), mais un adaptateur vers USB type C existe. Il est ainsi possible de connecter les deux cartes de capture en «daisy chain», c’est-à-dire l’une à l’autre, puis de n’avoir que l’une des deux branchée au portable de capture (ils ne disposent souvent que d’un unique port Thunderbolt). Enfin, cette version est donc compatible avec l’ancienne connectique, ce qui nous permet de disposer d’encore plus de solutions de secours si les deux ordinateurs prévus venaient à dysfonctionner.

Si vous cherchez une solution, celle-ci a été validée sous les trois OS avec le logiciel OBS Studio. En réalité, la quasi-totalité des modèles Blackmagic fonctionneront pareil. Si vous n’avez besoin que d’une seule entrée HDMI (et que le son est embarqué dans le flux), le modèle UltraStudio Mini vous suffira pour environ 150 euros. Les performances du portable peuvent être modestes : il ne faut pas beaucoup plus que 4 Go de RAM et un CPU Intel i5 à 2.5 Ghz est suffisant. Il doit probablement être possible descendre en dessous, au prix de concessions sur la qualité de l’encodage (720p30, enregistrement local identique au flux Internet, impossibilité d’envisager le 4K ou le 60 fps à l’avenir).

Transcodage des flux

L’emploi d’une solution libre, là encore, a été privilégié. Le choix de RTMP impose l’emploi d’un serveur de transcodage gérant ce protocole. La solution la plus simple, la plus flexible et la mieux documentée reste encore aujourd’hui nginx-rtmp-module, qui est l’un des rares à supporter de nombreuses options de live streaming. À terme, il sera probablement remplacé par nginx-ts-module.

Ce module permet d’automatiser énormément de choses :

• bascule automatique vers un autre flux lorsque le direct est hors ligne (pendant les pauses) ;
• gestion du cache HLS et du time-shifting ;
• multi-source, permettant par exemple de laisser le choix de l’angle de caméra visionné par le spectateur …

Il est même possible de pousser au serveur de transcodage le flux de la caméra indépendamment du flux des slides, et de le laisser faire la composition vidéo (images «overlay» pour le thème visuel et picture-in-picture, moyennant une bonne dose de ffmpeg-fu).

Ce transcodage peut ainsi être porté soit par n’importe quelle machine ayant suffisemment de puissance CPU pour supporter le nombre d’encodage nécessaire pour les opérations voulues. Dans le cas du SSTIC, il procède :

• au réencodage en 1080p, même si la source est en 1080p, afin de réduire le débit et de forcer les paramètres d’encodage des flux audio/vidéo pour assurer la compatibilité avec un maximum de lecteurs natifs, surtout mobiles (profils h264 et codecs audio, une galère) ;
• au transcodage vers des résolutions et des débits inférieurs (aujourd’hui 720p et 540p) ;
• au watermarking des vidéos (bandeau semi-transparent en haut, uniquement visible dans le flux en direct), qui est principalement utilisé pour insérer un timestamp et permettre aux spectateurs d’identifier leurs problèmes de lag ou de buffering.

Le transcodage permet aussi de finement limiter le débit en pic, ce qui arrive fréquemment lors des transitions de plein écran (passage des slides à l’orateur). Nous assurons aussi de cette manière les débits maximums des flux à ceux annoncés, cela permet d’avoir un flux stable en mobilité tant que l’on tient le débit demandé (1, 2 ou 4 Mbits/s).

La configuration sera intégralement donnée et commentée dans un billet ultérieur.

De 2014 à 2018, le serveur de transcodage utilisé pour le SSTIC présentait la configuration matérielle suivante :

• serveur physique :
  • serveur dédié OVH
  • CPU : Intel Xeon E3-1245 V2 @ 3.40GHz (4 cores, 8 threads)
  • RAM : 32 Go
  • Hyperviseur Xen
• machine virtuelle Xen
  • CPU : 6 vCPU
  • RAM : 2 Go
  • Debian

À partir de 2019, la configuration est la suivante (pas d’usage de machine virtuelle) :

• serveur physique :
  • serveur dédié Online
  • CPU : Intel Xeon E3-1231 V3 @ 3.40GHz (4 cores, 8 threads)
  • RAM : 32 Go
  • Debian

En charge, environ 500 à 800 Mo de RAM sont utilisés, presque 90% CPU. Le passage de 4 à 6 vCPU a été nécessaire pour supporter le 1080p30 (pour 2019, l’association a loué un serveur plus récent permettant de gérer un flux 4K en plus ou du 60 fps). Un débit réseau de 10 Mbits suffirait. Aujourd’hui, il était envoyé depuis la salle un flux initial CBR de 4 à 6 Mbits, mais il aurait été possible de descendre à 2 Mbits. Il est donc tout à fait possible de diffuser en 4G, pour peu que le débit soit stable. La diffusion d’une édition de SSTIC consommait environ 30 à 60 Go (prévoir 15 Go à 2 Mbits/s).

Le serveur de transcodage a été placé sur un serveur loué pour limiter le débit nécessaire dans la salle et permettre un éventuel repli sur de la 4G. Mais si votre salle dispose d’un débit d’upload suffisant, vous pouvez économiser cette location (45 euros par mois environ) et transcoder les flux sur place. Pour trois qualités différentes publiées, nous consommons environs 8 Mbits/s en sortie de transcodage (comptez 10 Mbits/s pour avoir de la marge). Cette bande passante est à multiplier par le nombre de serveurs frontaux et de relais que vous mettrez en place. Ainsi, si vous transcodez vos flux sur place, il faudra :

• soit envoyer vers chaque serveur frontal, multipliant ainsi la bande passante nécessaire ;
• soit envoyer vers un serveur frontal qui deviendra la source des flux RTMP pour les autres serveurs frontaux et les relais (sa configuration nginx devra être adaptée) .

Le serveur de transcodage peut très bien servir de frontal et être contacté directement par votre public. Ce n’est cependant pas le choix que nous avons retenu :

• le risque d’effet slashdot est trop important et nous voulions pouvoir augmenter le nombre de frontaux à la volée : cela impose de «protéger» le serveur de transcodage d’une saturation de bande passante. Il n’est donc pas atteignable par le public, mais délivre le flux uniquement aux frontaux et aux relais ;
• le coût des relais devient minimal : il devient possible de monter des relais avec des SoC peu couteux, la seule contrainte étant qu’ils disposent d’une bande passante intéressante (comptez en moyenne 1 Mbits/s par spectateur). Il est même possible d’en héberger chez soi avec une connexion fibre ou VDSL ;
• dans le pire des cas, le serveur de transcodage peut être hébergé chez quelqu’un disposant d’une connexion fibre pour bénéficier presque «gratuitement» d’une machine suffisamment puissante. Nous recommandons cependant l’usage d’un serveur dédié pour assurer la diffusion finale aux spectateurs.

Nous pouvions ainsi nous reposer sur des «box» personnelles de membres du comité de programme, ou même sur des relais gracieusement mis à disposition par des inconnus.

Enfin, c’est sur ce serveur de transcodage que sont jouées les vidéos de test avant la conférence : un ffmpeg en local lit un fichier mp4 et le diffuse en RTMP sur le endpoint dédié en temps normal au flux venant de la salle. Cela permet de demander à des cobayes de tester toute l’infrastructure de diffusion et de relais, en conditions réelles, et de disposer d’un flux de test permanent pour le diagnostic en cas de problème.

Serveurs frontaux

Enfin, les serveurs frontaux sont le point final de la chaîne de traitement, et le seul réellement visible des spectateurs en ligne. Là encore, il est fait usage de nginx et de son module nginx-rtmp-module. L’avantage principal est qu’il est possible de créer un serveur relais qui dispose exactement de la même procédure d’installation que le serveur principal, voire du même fichier de configuration (seule la partie concernant le frontal sera alimentée en flux à traiter).

Les contraintes de ressources qui pèsent sur les frontaux sont extrêmement limitées :

• de quoi absorber les hits HTTP dus au HLS ;
• de la bande passante pour absorber un nombre significatifs de clients.

Ils sont à moitié passifs :

• ils ne réalisent aucun transcodage, car tout est préparé par l’unique serveur de transcodage : leur charge CPU est donc dédiée au traitement des requêtes RTMP et HTTP ;
• ils réalisent localement la découpe des chunks HLS et leur mise à disposition sur HTTP.

Ce dernier choix peut être discutable :

• la création des chunks sur chacun des frontaux peut créer des problèmes de désynchronisation, particulièrement dans le cas où le load-balancing est réalisé avec du round-robin DNS : en effet, deux frontaux peuvent éventuellement découper les flux en chunks différents ; si un client change subitement de frontal suite à une nouvelle résolution DNS, il risque d’avoir une saute de flux en avant ou en arrière, ou pire, une rupture complète à cause d’une exception non gérée par le lecteur HLS ;
• il est possible de mettre en place une infrastructure de proxy ou de mise en cache de ces chunks, afin de garantir que l’intégralité des frontaux soit cohérente ;
• il devient possible d’avoir des stratégies de caching différentes selon les frontaux ou relais : certains peuvent avoir une durée de 15 minutes pour offrir du «time-shifting», d’autres peuvent limiter ce cache pour ne pas consommer d’espace disque.

Cependant, réaliser proprement l’infrastructure de cache distribué est d’une complexité encore plus grande, quand le défi est de délivrer de manière fiable un flux en continu. On ne peut pas se reposer sur des reverse-proxies opportunistes, qui viendront récupérer le chunk à la première demande. En effet, si certains lecteurs mettent en cache un certain nombre de chunks avant de démarrer la lecture, d’autres sont moins précautionneux, et peuvent les demander presque au dernier moment. Le temps de rapatrier le chunk sur le frontal peut s’avérer fatal.

Des solutions existent, mais en pratique, le problème n’a jamais été significatif. De plus, il est possible de le contourner simplement en Javascript : au lieu de faire du round-robin DNS, c’est le lecteur Javascript qui tirera au hasard le frontal qu’il emploiera. Un client ne changera donc pas de frontal en cours de lecture.

Les flux RTMP leurs sont donc poussés par le serveur de transcodage, qui retente chaque seconde en cas de rupture de flux.

Enfin, nous avons toujours opté pour un minimum de deux serveurs frontaux : l’un chez OVH, l’autre chez Online, pour limiter les problèmes de peering, et éventuellement donner l’URL d’accès direct à l’un ou l’autre des deux si nous devions avoir connaissance de problèmes.

De même que pour les autres éléments, la configuration d’un serveur frontal sera détaillée dans un billet ultérieur.