Le SSTIC a commencé à être diffusé en direct en 2014. Inspiré des balbutiements de la diffusion de jeux vidéos sur Twitch, ce qui a commencé avec des moyens artisanaux a évolué les années suivantes : capture des postes des orateurs et du son, replay et time-shifting… le tout sur une infrastructure maîtrisée intégralement par notre association.

Ce billet est le premier 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.

Cette série de billets a donc pour objectif de présenter les défis successifs posés par la diffusion en direct du SSTIC depuis 2014. Elle servira également de documentation à l’architecture actuelle : à l’issue de cette lecture, vous serez capable de remonter la même infrastructure de live streaming.

Seront couverts :

• les problématiques générales, les idées clés de la conception et des évolutions (c’est ce que vous êtes en train de lire) ;
• l’architecture globale ;
• l’infrastructure de capture audio/vidéo et ses évolutions ;
• la configuration du serveur de transcodage ;
• la configuration des serveurs frontaux.

Les questions de coûts, d’investissements, le matériel employé, les raisonnements qui ont mené à certains choix et les multiples problèmes rencontrés seront également évoqués en détail.

Idées clés

Le SSTIC revendique son indépendance : chaque année, le public aussi nous conforte dans ce choix vis-à-vis d’annonceurs ou de sponsors. Mais cela se traduit également techniquement : nous cherchons volontairement à ne dépendre d’aucune plateforme et à maîtriser l’intégralité de ce que nous mettons en place.

L’architecture de live streaming est donc prévue pour ne pas dépendre de plateformes clés en mains, qui apportent certes une relative simplicité, mais également un lot de problèmes techniques, éthiques ou légaux. Nous voulons ne pas être redevable de quiconque et donc éviter autant que possible les arrangements, même gratuits, où nous nous sentirions obligés de faire indirectement de la pub à un acteur : cela brouillerait notre message.

L’association ne disposant pas de fonds illimités (voire au contraire, d’une marge de manœuvre très limitée), le coût de la solution doit rester raisonnable. Pendant plusieurs années, le matériel personnel des membres du comité d’organisation a permis de limiter les dépenses à quelques centaines d’euros pour du câblage et un serveur.

D’un point de vue technique s’est posé le défi des évolutions dans les habitudes de consommation et l’interopérabilité de la solution : pouvoir toucher de manière transparente les geeks sous Linux, comme la personne contrainte par les logiciels autorisés de sa DSI. Il faut être visible sur tablette ou smartphone et que ça fonctionne autant que possible dans le métro.

Enfin, il faut anticiper l’avenir : le succès toujours grandissant du SSTIC, le stress des inscriptions nous a toujours montré que le live streaming serait très attendu. Peut-être aussi aurions-nous un jour à subir un afflux soudain de spectateurs : comment y répondre ?

Il a donc fallu rechercher quelles solutions et compromis répondaient au mieux à toutes ces problématiques :

• apports de HTML5 et des lecteurs en Javascript ;
• solutions de transcodage pour gérer des qualités diverses ;
• protocoles de transmission des flux et compatibilité ;
• facilité de mise en œuvre ;
• sécurité de la solution ;
• évolutivité du côté des clients comme de la production du contenu.

Le monde merveilleux du live streaming

Bienvenue dans une plongée dans le business de la vidéo en ligne : il est extrêmement compliqué de trouver comment faire sans payer une dîme conséquente pour chaque bout de la chaîne (lecteur vidéo payant dans le cloud, solution de transcodage dans le cloud, prestation de captation externalisée…), sans faire de concessions sur son indépendance et ce dans un budget raisonnable.

Les problèmes principaux que vous rencontrerez seront :

• vous voulez lire un flux en direct et non des vidéos pré-enregistrées, ce qui requiert un lecteur vidéo compatible. Attention, quand on parle de live streaming, nombreux sont ceux qui pensent que lire un .mp4 pré-enregistré tombe dans ce cas du moment que le lecteur le télécharge au fil de la lecture… mais on cherche bien à lire un flux qui n’a pas de fin prédéfinie, qui n’est (généralement) pas «seekable», et encore moins transcodable dans des dizaines de formats en parallèle en fonction du support côté client (YouTube propose par exemple de nombreux formats comme webm ou mp4) ;
• il vous faut alimenter un serveur de contenu dans un format compatible avec le live streaming, pour de (très) nombreux clients : ce format comprend le conteneur (flv, mkv, ts…) et le codec (par exemple pour la vidéo : h264, VP8…) ;
• l’écosystème technique dans l’évènementiel / l’audiovisuel est un monde de m… de prestations et de clients captifs des technologies propriétaires de quelques-uns.

En fait, vous cherchez à concurrencer Twitch, Ustream, Dailymotion, YouTube, Facebook live et autres Periscope sur le créneau montant du live streaming. Il y a beaucoup d’acteurs, mais leurs technologies sous-jacentes ne sont pas reversées à la communauté. Et pour cause : c’est bien le fond de leur business et de leur avantage concurrentiel.

Ceux qui ont vécu les débuts d’internet se souviendront avec émotion des flux RealMedia, RTSP, ASV et autres technologies qui vous faisaient miroiter la «télé du futur» dans une soupe de pixels transmise avec des modems 33.6 Kbits/s. Oui, c’était horrible de regarder une vidéo en ligne à l’époque de WinAMP. Les belles promesses d’entre temps n’y ont rien changé : Theora, OGG vorbis, shoutcast/icecast…

Aujourd’hui, ce monde est toujours dominé par les acteurs du moment, Adobe étant le premier d’entre eux. Twitch et ses gamers ont réussi à mettre tout le monde d’accord : RTMP (développé par Macromedia / Adobe) s’est imposé comme protocole de streaming sur quasiment toutes les plateformes en ligne, avec l’usage du format… FLV (beurk, du Flash !? Vraiment ? Oui.). MPEG-DASH changera peut-être la donne en revenant de manière préférentielle au vénérable format TS, tout en étant agnostique au niveau du codec (ça reste à voir selon les navigateurs / plateformes). Cependant, en 2017 il n’existait toujours pas de combinaison serveur de flux - lecteur HTML5/JavaScript libre qui était satisfaisante pour un usage de live streaming (et non de VOD) avec DASH.

Le fait est que la popularité du live streaming de jeux vidéo a largement contribué au développement de l’écosystème matériel et logiciel : cartes de capture à bas coût, logiciels de streaming abordable voire même opensource…

Si le côté «production» du contenu est de plus en plus accessible, il reste que les côtés transcodage / transport et lecture souffrent toujours d’un sacré déficit : il est compliqué de trouver comment mettre en oeuvre une solution complète de bout-en-bout, comme un serveur de transcodage et un système de publication de flux. Aussi, le «business» est plus rentable à vous faire payer une solution de live streaming dans le «cloud» qu’à vous laisser monter votre propre infrastructure. De même, vous seriez surpris de savoir combien de lecteurs vidéo Javascript (ou même Flash) clés en main supportent le live streaming sans vous faire payer un abonnement ou une version pro à plusieurs milliers d’euros (réponse : un ou deux, et pour certains autres il faut coder sérieusement). Exit donc les Wowza, Bitmovin, THEOplayer, JW Player… ou même l’implémentation de référence Dash.js qui ne permettait pas en 2017 de faire du live streaming correctement. HLS, développé et poussé par Apple alors qu’ils cherchaient à tuer Flash sur mobile, a bénéficié d’une longueur d’avance et d’une adoption rapide. En 2014, c’était la solution la plus simple à déployer soi-même pour s’assurer de toucher le plus grand nombre et c’est probablement toujours le cas (même si le retard des solutions libres basées sur DASH se comble).

Pour faire simple, il y a trois alternatives crédibles :

• vous imposez à vos spectateurs d’utiliser des clients lourds type VLC / mplayer, qui ouvriront une URL entrée manuellement, mais du coup vous vous restreignez à une population de geeks et ne toucherez pas les «professionnels» qui subissent les contraintes de leur DSI et ne peuvent installer ce qu’ils veulent sur leur poste ;
• vous utilisez un lecteur Flash pour du RTMP ou du HLS, mais qui ne seront pas pérennes après l’arrêt du support par les navigateurs. Rendez-vous compte, la popularité de Twitch fait toujours partie des raisons pour lesquelles Flash est encore supporté dans Chrome ;
• vous utilisez les fonctionnalités HTML5 de lecture vidéo, mais vous découvrez que les groupes de standardisation au W3C ne se sont pas suffisemment mis d’accord pour avoir une solution commune standard (merci Adobe, Apple, Google et Netflix), ni même d’implémentation de référence «utilisable» (encore une fois Dash.js). Le temps de développement se présente comme «important» pour une personne seule sur son temps libre.

Entre 2014 et maintenant, la situation s’est un peu améliorée avec l’apparition de lecteurs Javascript supportant de mieux en mieux le live streaming… en HLS. Heureusement, car l’arrêt annoncé du support de Flash par les navigateurs aurait été compliquée à compenser. Le plus complet que nous ayions trouvé est clappr, un projet initié par des employés d’un groupe de télévision brésilien (Globo) et utilisé pour retransmettre la coupe du monde de football en 2014 (une lecture très intéressante sur la génèse de ce lecteur se trouve ici, et partage certains constats que nous avons pu faire). D’autres lecteurs se sont bien améliorés depuis (Shaka Player semble le plus prometteur pour le support du live streaming en DASH).

Enfin, Theora et d’autres tentatives émergeantes n’ont jamais été réellement utilisables : pendant longtemps, il fallait un plugin de navigateur en Java ou similaire, alors qu’on cherche justement à s’en débarrasser. La matrice de compatibilité ne montre aucun gain par rapport aux autres options, surtout vis-à-vis de l’emploi de codecs complètement open-source (ce qui aurait été quasiment l’unique intérêt de cette solution).

Impact sur les clients et comportements

De nombreux problèmes que l’on n’anticiperait pas au premier abord se posent vis-à-vis des clients, logiciels comme humains :

• des solutions trop libres ne sont pas adoptées par les navigateurs. Ayons à nouveau une petite pensée pour Theora, qui n’est aujourd’hui supporté en HTML5 que par Chrome et Firefox ;
• on pourrait imaginer que le HTML5 et les Media Source Extensions (MSE) auraient réglé des problèmes qui vont fêter leurs 20 ans comme celui des codecs, mais pas du tout : vous pourrez parfois lire des mp4 pré-enregistrés mais pas leur version streamée en live (y compris avec les paramètres d’encodage identique, voire une copie directe des pistes) sans la bonne surcouche Javascript, soit à cause du profil H264 (ne sortez pas du profil baseline pour du live streaming avec des lecteurs Javascript émergents !), soit en raison du codec audio… les APIs des navigateurs sont capricieuses, et pour être décodable sur une plateforme mobile il faut parfois respecter d’obscures exigences à l’encodage (particulièrement pénibles à débugger pour le DASH).

Tout bêtement, ces deux problèmes proviennent de l’évolution des usages : la consultation depuis un appareil Android ou iOS impose de gérer au minimum Chrome, Safari et maintenant Edge, tandis que la consultation classique sur PC rajoute au moins Firefox et Internet Explorer. Ce ne sont pas les sempiternels problèmes de rendu CSS, mais bien le découpage du flux et l’interprétation des trames dans un flux live qui posent à nouveau problème, en plus des codecs comme évoqué ci-dessus.

Au niveau du comportement des usagers, il faudra aussi veiller à quelques autres sujets :

• la mobilité et/ou la performance des machines clientes et de leur connexion, qui imposent de fournir plusieurs qualités et débits afin de satisfaire le plus grand nombre. Un flux 0.5 ou 1 Mbits/s sera plus facilement lisible dans le métro que sa version full HD. De même, certains utilisateurs pourraient préférer une version audio uniquement, réduisant encore plus le débit nécessaire (et il est facile d’aller très bas pour un son mono) ;
• un lecteur vidéo trop «intelligent» peut nuire à l’expérience : la sélection automatique du bitrate ou de la résolution peut provoquer de nombreux problèmes sur les liaisons bas débit ou sur les liaisons partagées. De même, les flux à bitrate variable sont complexes à calibrer pour assurer une certaine qualité de service : même en visant une moyenne basse, des pics soudains peuvent survenir, particulièrement lors des transitions de layout vidéo (passage de slides à une caméra en plein écran par exemple) ;
• le stream ripping peut créer des problèmes inattendus, surtout avec une diffusion sur HTTP comme DASH ou HLS, voire avec des fonctionnalités de time-shifting : un client qui veut ripper le flux pourra télécharger en masse les chunks vidéo depuis le cache présent sur le serveur HTTP, ce qui génèrera un pic de bande passante pouvant nuire aux autres clients. Réduire la durée disponible en tampon ou imposer du rate-limit peut aider à décourager ces actions. Et oui, malgré la publication rapide des vidéos, il existe toujours de nombreuses personnes qui font cela : le choix de ne proposer que 15 minutes de time-shifting est lié à ces facteurs : on ne cherche qu’à permettre la «pause pipi» et le retour en arrière pour revenir sur quelques mots que l’on a mal compris, car la vidéo sera disponible au plus tard quelques heures après.

Anticiper les besoins

Proposer du live streaming ouvre de nouvelles possibilités, qu’il convient d’anticiper :

• interactivité, chat en temps réel et participation du public en ligne ;
• rediffusion multi-salles ou multi-écrans dans l’enceinte de la conférence ;
• projection «retour» de l’orateur sur l’écran de l’auditorium…

Il faut penser dès maintenant à des bricolages ou techniques permettant facilement d’apporter ces fonctionnalités sans chambouler son câblage ou sa configuration.

Par exemple, une rediffusion multi-salles impose la mise en place d’un serveur relais local, mais qui doit être en amont de la chaîne de diffusion sur Internet pour ne pas souffrir d’un délai considérable par rapport à ce qu’il se passe dans la salle d’à côté.

La capture des slides indépendamment de l’image de l’orateur pose un défi de câblage : à Beaulieu, les slides provenaient de la scène (en VGA), l’audio venait d’une console son située en bas sur le côté droit dans un mur et la vidéo devait être capturée depuis le public. Sans investir dans des convertisseurs de qualité (VGA - HDMI) et des câbles onéreux, la solution la plus simple est ici de multiplier le nombre d’ordinateurs réalisant de l’encodage vidéo, et de relier tous ceux-ci par un réseau qui servira à streamer localement chacun des flux indépendamment. Un dernier ordinateur reçoit, décode, synchronise et compose les flux (audio compris) pour encoder la vidéo finale.

La bande passante et la qualité de la connexion disponible pour l’upload du flux live peuvent être des facteurs importants :

• où sera effectué le transcodage vers les différentes qualités ? La position de cette machine détermine la puissance CPU et la bande-passante requise sur le lieu de l’évènement. A l’inverse, il peut être plus simple d’amener ou d’acheter un PC puissant pour effectuer tous ces transcodages plutôt que de louer un serveur dédié octo-core… ou encore on peut profiter de certaines capacités d’encodage matériel des GPU modernes comme NVENC, VCE ou QSV ;
• le coût de cette liaison permet-il d’obtenir un débit suffisant pour diffuser en même temps qu’envoyer les vidéos précédentes ?
• la stabilité des équipements réseau est-elle satisfaisante ? Certains switchs ont pu nous causer des coupures intermittentes de plusieurs secondes, et s’en rendre compte pendant l’évènement rend impossible toute tentative de correction ;
• le câblage de la salle vous permet-il de vous placer de manière idéale ? Par exemple, il a pu être plus rentable d’acheter plusieurs rouleaux de 30m de câble réseau plutôt qu’allonger la distance entre une source vidéo et son PC d’encodage ;
• un moyen de secours est-il disponible en cas de coupure prolongée ? En 2017, la connexion présentait 30% de pertes de paquets la veille de la conférence, et un débit insuffisant pour la diffusion (5 Mbits/s requis) : le SSTIC a failli être diffusé en utilisant du tethering 4G. Mais en 4G ou en Wifi, attention aux rigolos qui provoqueront des désassociations ou qui satureront l’eNodeB local ; le bon vieux câble RJ-45 sera toujours préférable.

Enfin, il reste un point à traiter qui est souvent oublié : la cession des droits d’auteur. C’est ce qui nous permet d’envoyer directement les vidéos sans attendre longuement que les auteurs daignent lire leurs mails pour nous autoriser à publier la vidéo de leur prestation.

Le SSTIC fait donc signer à l’ensemble des auteurs un contrat de cession de droits qui couvre la représentation, la reproduction, l’adaptation, la traduction, la correction orthographique de même que les autorisations relevant du droit à l’image. Cependant, nous ne demandons pas l’exclusivité des travaux et leur diffusion est aujourd’hui exclusivement limitée au domaine sstic.org. Ainsi, l’association ne peut publier les vidéos sur YouTube ou toute plateforme tierce sans un nouvel accord explicite des orateurs. Les vidéos ne sont donc pas diffusées sous licence libre, volontairement. Ce point pourrait évoluer, mais cela reste cohérent avec nos choix d’indépendance et un certain respect des choix personnels des auteurs vis-à-vis d’autres acteurs du numérique. Libre à eux de rediffuser eux-même les vidéos sur d’autres plateformes. Il appartient donc au public de respecter ce choix.

Choix techniques du SSTIC

Considérant l’ensemble des problématiques évoquées précédemment, les choix techniques du SSTIC se sont posés sur :

• l’usage de RTMP comme protocole de diffusion principal (et donc, à regrets, le format de conteneur FLV), permettant de profiter de l’écosystème logiciel de capture et composition vidéo très abordable issu des gamers ;
• l’usage du module nginx-rtmp-module pour construire les différents serveurs : diffusion locale, transcodage, frontaux et relais : son excellente compatibilité avec les lecteurs Flash, Javascript/HTML5, mobiles et historiques (VLC…) nous conforte dans ce choix, de même que la facilité avec laquelle il est possible de chaîner plusieurs relais ou de réaliser des traitements complexes sur les flux vidéos (transcodage par ffmpeg, overlay, enregistrement local, génération des chunks HLS/DASH…) ;
• l’usage de RTMP et de HLS comme protocoles disponibles aux clients : RTMP pour sa faible latence principalement (même s’il nécessite soit un client lourd comme VLC, soit un lecteur Flash) et HLS car il bénéficie d’un support quasi-unanime par les navigateurs fixes, mobiles et d’un plus grand nombre de projets comme les lecteurs Javascript ;
• une capture locale des flux audio et vidéo et leur compositing sont permis par Open Broadcaster Software (OBS Studio), logiciel libre en constante évolution qui permet d’effectuer la composition de l’encodage et du streaming vidéo de manière relativement simple (le SSTIC n’a pas besoin d’artifices techniques mirobolants). Les alternatives sont Nageru (qui reste libre et cette présentation de BreizhCamp vaut le coup d’œil), Wirecast (qui coûte à lui seul entre 600 et 1000 euros), XSplit Broadcaster qui marche par abonnement, ou les autres logiciels utilisés pour diffuser sur Twitch par exemple ;
• un transcodage effectué sur un serveur dédié, afin de réduire au maximum les besoins en bande passante, de même qu’en CPU, puisque nous utilisons des laptops pour traiter l’encodage sur le lieu de l’évènement : ce genre de matériel supporte moins bien une charge de 100% pendant 8 heures d’affilée.

De ces choix, les deux les plus dimensionnants pour l’architecture sont l’usage de OBS sur l’évènement, qui contraindra par la suite la manière de récupérer les sources audio et vidéo, et l’emploi du RTMP pour permettre la mise en place d’une architecture évolutive et modulaire : nginx-rtmp-module permet de manière triviale d’augmenter le nombre de serveurs frontaux, de transcodage, ou d’ajouter un serveur local pour une diffusion simultanée sur écrans ou multi-salles… Autrement dit : le choix des cartes de captures ou des lecteurs HTML5/Javascript s’est fait en fonction de leur compatibilité avec OBS et ce serveur RTMP.

Les évolutions de OBS depuis 2014 ont même permis la simplification de la chaîne de capture comme l’usage de matériel professionnel directement pour effectuer la capture vidéo et audio.

Ces choix techniques seront ainsi détaillés dans les billets suivants.

Génèse et historique

En réalité, l’architecture générale a très peu bougé depuis sa création. Les logiciels utilisés ça et là ont bénéficié de nouvelles fonctionnalités et ce sont principalement ces évolutions qui ont permis d’abandonner les multiples bricolages qui permettaient de faire tomber l’ensemble en marche.

Par exemple, la stabilisation d’OBS Studio et l’ajout de fonctionnalités ont permis une gestion plus simple des incrustations et des sources vidéos multiples :

• en 2014, il n’y a qu’une seule capture : la vidéo prend l’orateur et les slides, l’audio est mixé/synchronisé à côté. La chaîne de capture comprend au moins 6 logiciels successifs pour arriver à mettre l’ensemble dans un flux unique (capture vidéo Elgato Game Capture, serveur RTMP local, mplayer, Syphoner, Audio Hijack, OBS). Les dépenses restent très maîtrisées, car la pression des inscriptions nous oblige à envisager un déménagement, avec les inconnues que cela génère : coût de la nouvelle salle, matériel qui sera disponible…). Il devient moins évident d’acheter quasiment 10000 euros de matériel vidéo quand on ne sait pas s’il sera utile après 2 ans ;

• en 2015, un PC dédié à la capture des slides fait son apparition, grâce à l’un des fameux adaptateurs commandés sur dealextreme ;

• en 2016, un troisième PC permet de soulager le CPU pour la composition vidéo, qui était au bout de sa vie pendant 6 ou 7h par jour. Le changement de salle se précise et nous empêche de faire des investissments qui ne seraient pas pérennes ;

• en 2017, le changement de salle se matérialise avec le passage à la fac de droit, mais l’infrastructure technique ne bouge pas. Nous abandonnons complètement certains lecteurs obsolètes comme FlasHLS et GrindPlayer qui pouvaient parfois faire un peu peur dans la bouche ;

• en 2018, la nouvelle salle permet enfin d’accéder à la modernité des connectiques numériques, ce qui simplifiera énormément la vie pour la capture vidéo, en plus de permettre des investissements.

Pour 2019, ces expériences nous permettent de dimensionner les derniers achats afin de ne plus être dépendant du matériel personnel des uns et des autres pour assurer la diffusion. La connaissance des capacités techniques de la nouvelle salle permet d’acheter du matériel cher (caméra, poste d’encodage…), mais dont on sait qu’il durera.

Evolutions et défis

Quelques défis subsistent pour le live streaming du SSTIC :

• le support du TLS sera nécessaire en 2019, ce qui impose de revoir l’organisation des serveurs frontaux et le positionnement du lecteur vidéo, tout en conservant la possibilité d’augmenter à la volée le nombre de serveurs. Chiffrer les flux vidéo risque également d’avoir un impact sur notre bande passante, les chunks HLS pouvant être mis en cache par les proxy intermédiaires ;
• le support du 60 fps augmente sensiblement la charge CPU, mais cette année il a principalement buté sur des problèmes lié au pipeline de transcodage (passage des flux par les différentes étapes de la chaîne) et au support par le lecteur Javascript ;
• la résolution 4K, qui est désormais supportée par notre matériel de capture, mais qui amène de gros défis techniques pour un gain très relatif. La consommation CPU presque triplée impose l’usage de plusieurs serveurs de transcodage pour continuer à fournir autant de qualités différentes en streaming : le bi-xeon actuel atteint ses limites avec 4 flux transcodés pour du 720p maximum, ou 3 flux avec du 1080p.

Dans le genre inattendu, voire difficile à mesurer, l’arrivée d’un live streaming détourne certains spectateurs de la conférence. Certains paient leur place mais préfèrent le confort de leur chambre d’hôtel pour regarder les présentations du vendredi matin. D’autres sèchent parfois tout bonnement les incriptions pour venir ne profiter que des afters à la rue de la soif.

Avec le passage à 800 participants nous anticipions une baisse de fréquentation du streaming… Il n’en a rien été : avec toujours entre 350 et 600 spectateurs selon les horaires, en 2018 les chiffres sont restés sensiblement similaires aux années précédentes.

Pour autant, nous sommes résolus à apporter quelques nouveautés :

• du TLS de bout en bout (lecteur Javascript/HTML5 et serveurs de contenu) ;
• une évolution vers le MPEG-DASH lorsque la technologie sera rodée ;
• la fourniture de conteneurs prêts à l’emploi pour dupliquer l’infrastructure du SSTIC (transcodage, frontaux, relais…).

En attendant, les billets suivants vous permettront de reconstruire tout cela vous-même en maîtrisant les moindres détails.