Le 9 octobre dernier, se tenait la conférence de Jean Marc Manach "Vie privée, un problème de vieux cons ?".

FAImaison s'est alors proposée pour diffuser en ligne cette conférence puisque nous l'avions déjà fait pour notre cycle de conférences un peu plus tôt dans l'année.

Note : l'enregistrement de cette vidéo est accessible en torrent, sur media.faimaison.net mais aussi sur youtube

Ce post est un petit retour sur les nouveaux choix techniques pour cette conférence, les contraintes que nous avions et c'est également pour moi l'occasion de donner un peu plus d'informations sur l'infrastructure que nous utilisons jusqu'à présent.

À ce retour s'ajoutent les retours de FAImaison et du Conseil de Développement de Loire Atlantique (CLDA44).

Les contraintes

Jusque là nous avions déjà une petite série de contraintes que nous nous imposions (liste non-exhaustive) :

1. On doit utiliser des logiciels libres
2. On doit se passer de tout acteur majeur et centralisant
3. On doit pouvoir suivre la conférence avec une connexion de 512Kbps
4. En cas de problème, la diffusion doit reprendre d'elle même (tant du coté salle, que du coté serveur ou bien du coté client)

Pour le premier point, on a toujours du Icecast, le flux est poussé par de l'oggfwd après être passé dans un coup de ffmpeg. Il y a une brique maison en plus : le répartiteur de charge (load balancer, abordé plus bas dans ce ce post).

Pour le second point, DIY, on installe tout: de la capture, à la diffusion en passant par la répartition de charge. Il en va de même pour la communication événementielle et le suivi / monitoring de l'ensemble durant l'événement. Cette fois nous avons fait appel aux membres de la FFDN pour disposer d'un nombre suffisant de machines. Merci aux nombreux bénévoles ayant répondu ! <3 <3 <3

Pour le troisième point : on choisit soigneusement les paramètres d'encodage.

Pour le quatrième point on met plusieurs dispositifs en place :

• On s'appuie sur des listes de lectures: si un serveur de la liste de lecture devient indisponible, le client est censé essayer le suivant
• La page Web que l'on met à disposition utilise un lecteur utilisant les capacités HTML5 (balise video) sur laquelle on a ajouté le support des listes de lecture
• L'ensemble des processus de la chaîne se relance automatiquement en cas d'anomalie

L'utilisation des listes de lecture permet de s'assurer que la lecture reprend en cas d'incident. En général on dispose de plusieurs secondes avant que le client n'ait parcouru toute la liste de lecture et qu'au final on le "perde".

L'installation : ce qui a changé

Comme à chaque conférence, c'est une superbe occasion d'essayer de nouvelles méthodes ou de nouveaux outils :)

Les choses qui ont changé :

• Capture en HD plutôt qu'en SD
• Amélioration du lecteur vidéo HTML5/js
• Diffusion de plusieurs flux simultanés (vidéo qualité maximale, vidéo qualité réduite, audio uniquement)
• Augmentation du nombre de serveurs (on nous a annoncé une probable fréquentation de 4000 clients simultanés; chiffre basé sur le nombre de visite de la page de l'événement)

Pour la partie capture HD on a utilisé un appareil photo numérique et une carte d'acquisition HDMI.

Vu le manque de temps sur le choix d'outils et qu'il n'était pas possible de contrôler le cadrage de la vidéo en direct (l'écran de l'appareil photo s'éteignant quand un câble HDMI y est connecté), un écran a été branché sur la carte d'acquisition:

Schématiquement parlant, ça donne ceci :

Vu depuis le bas de l'amphi, l'installation ressemblait à ça :

Taux de fréquentation

Nous avons eu un pic de 180 clients simultanés. Bien loin de la capacité d'accueil de 4000 connexion que nous avions prévu. Cela dit vu le sujet traité et le fait que la diffusion avait lieu en pleine journée, ce n'est probablement pas si étonnant. En conséquence nous n'avons pas pu vérifier que ca tenait le volume prévu même si il n'y a aucune raison théorique pour que ça ne tienne pas.

Une autre explication qu'on devine : les codecs utilisés excluaient certains utilisateurs de-facto (on a utilisé de l'ogg theora puisque c'est ce que supporte Icecast pour le moment). Ainsi les utilisateurs d'Internet Explorer ou de Safari devaient passer par un lecteur vidéo tiers en utilisant l'URL du flux donné sous le lecteur Vidéo intégré à la page dont nous avions communiqué l'adresse.

Comment ça fonctionne ?

Allez c'est parti, expliquons le fonctionnement de cette infrastructure de streaming !

Pour commencer, prenons un cas simple: une source vidéo, un serveur de diffusion, des clients.

On va faire ça en allant de la salle où a lieu la captation jusqu'au client qui visionne la vidéo diffusée.

Le principe général est simple: on prend un contenu (une capture en direct d'un événement, un fichier déjà existant, ...), on l'encode dans un format suffisamment léger pour être diffusé en ligne puis on pousse ce contenu encodé sur un serveur de diffusion; serveur auprès duquel les clients peuvent récupérer ce contenu.

L'encodage a lieu sur le lieu de captation, le serveur de diffusion est quelque part sur Internet derrière une bonne connexion (oubliez l'ADSL). Le lieu où se déroule l'événement n'a pas besoin d'avoir une connexion si énorme que ça puisqu'un seul flux doit être envoyé au serveur de diffusion (en général une connexion ADSL suffit). C'est au niveau du serveur de diffusion que le besoin en bande passante (montante) est le plus élevé.

Dans la salle

Partons de l'hypothèse que l'on veut diffuser en direct une captation d'un événement (on pourrait diffuser un fichier vidéo existant bien sûr).

Note : L'accès à la salle quelques jours avant la diffusion est un plus pour se rassurer et voir ce qu'il y a de disponible sur place en terme d'accès à une source d'électricité, à la connexion au réseau, ...

Pour une installation minimale pour diffuser un événement, on a besoin :

• D'électricité :)
• D'une connexion à Internet :)
• D'une caméra
• D'un ordinateur capable de lire le flux de la caméra et de faire l'encodage de celui-ci

À cette liste j'ajouterais quand même à ce minimum un micro.

Captation audio

Pour la captation audio, on prend de préférence un micro à proximité de l'intervenant. Il n'y a rien de plus pénible que de suivre une conférence en entendant un bruit de fond (celui émis par le public en général) en plus de la voix de l'intervenant.

On évitera également l'utilisation de micro d'ambiance (exemple de micro d'ambiance: le micro intégré à la caméra ou au PC).

On privilégie un micro à main, un micro cravate, un micro de table/pupitre. Si la diffusion a lieu depuis une salle équipée d'une sonorisation, il y a de bonnes chances de pouvoir accéder à une sortie audio propre et mixée (il faut alors prendre contact avec les gérants et techniciens du lieu). Dans ce dernier cas c'est souvent du gâteau; la seule inconnue restant la connectique mise à disposition pour récupérer le flux audio.

Il faudra donc prévoir plusieurs combinaisons de câbles et d'adapteurs pour être sûr de pouvoir se raccoder à peu près n'importe quelle installation de sonorisation. Le plus souvent c'est du XLR, du jack 6mm, ou 3.5mm, plus rarement du RCA. Avoir un micro de secours est tout aussi intéressant.

Maintenant que nous avons notre entrée son, on va parler un peu des caméras.

Captation vidéo

Choisir sa caméra c'est pas forcément si simple. Ci-dessous, une liste de points de vigilance qu'il est intéressant de garder à l'esprit :

• La caméra ne doit pas être sur batteries (c'est un ennui de moins)
• Elle doit disposer de la résolution adaptée à l'exigence de qualité
• L'image de la caméra doit être récupérable en direct sur un ordinateur (captation en direct; une caméra qui ne sait qu'enregistrer sur un support de stockage sans exporter l'image qu'elle capte en direct n'est pas intéressante)
• Fonctionner sur votre système d'exploitation et compatible avec vos logiciels (drivers / modules disponibles, ...)
• La caméra doit être adaptée à vos conditions d'éclairage
• Le nombre d'images par secondes doit rester stable quelque soit la luminosité
• Aucun affichage en sur-impression (overlay) ne doit être ajouté à l'image
• Si la caméra a un autofocus, il est intéressant qu'il soit débrayable
• Si la caméra a un zoom, c'est mieux
• Si la caméra dispose d'une vis pour un trépied photo/vidéo, c'est mieux

On trouve 3 types de caméras principalement :

• Les Webcams
• Les appareils photo
• Les camescopes/caméras dédiées

Pour faire des tests une Webcam suffit.

Par contre, pour assurer la diffusion d'un événement, c'est un peu moins sûr : une Webcam peut faire l'affaire mais c'est pas toujours la panacée.

On pense par exemple à certaines caméra dont le débit d'image à la seconde (i/s, fps) varie selon la luminosité du lieu (ces caméras jouent sur la durée d'exposition pour afficher une image plus claire dans des conditions sombres), c'est le cas de la HD5000 par exemple. Dans un cas comme celui-ci, quand on fait l'encodage on peut se retrouver avec un décalage son / image.

Les Webcams sont pas toutes bonnes pour capter dans les conditions de votre événement: s'il celui-ci a lieu en environnement sombre ou à l'extérieur c'est pas la même histoire.

De la même façon, une Webcam est en général moins pratique à manipuler pour cadrer et zoomer pendant la diffusion.

Leur principal intérêt est le prix faible pour se lancer : il n'y a pas besoin d'ajouter de carte d'acquisition pour récupérer l'image d'une Webcam.

Idéalement on évitera les Webcams.

Il peut être tentant de faire la captation avec un appareil photo doté d'un mode vidéo.

Si vous avez la chance d'avoir un modèle qui s'alimente par bloc secteur, qu'il n'affiche pas en surimpression (overlay) d'information à l'image (chez Canon le firmware alternatif Magic Lantern ajoute cette option) et qu'il dispose d'une sortie USB (mode Webcam finalement) ou HDMI, ca peut être une bonne idée.

Comme dit plus haut, ne pas hésiter à se monter un labo et à éprouver le matériel: si l'événement dure 4h, ne pas hésiter à tester votre installation pendant au moins 4h. C'est durant une phase de test de ce type que j'ai remarqué les 2 mesures anti-piratage de films intégrée à mon reflex. Les deux mesures se déclenchent sur des périodes de temps régulières mais différentes. La première toute les ~25 minutes : le miroir se baisse et remonte : on perd l'affichage quelques instants. La seconde est plus gênante : au bout d'un moment (~50 minutes) la carte d'acquisition reçoit des informations erronées (décalage de timecode) et du coup l'encodage plante.

Dans le cas d'un appareil photo avec une sortie HDMI / composite, il faudra disposer d'une carte d'acquisition vidéo adéquate.

Petite vigilance sur le choix de la carte d'acquisition d'autant plus si l'entrée voulue est du HDMI : le marché des cartes d'acquisition pour joueurs est assez développé, on trouve sur le marché des cartes d'acquisition qui ne font qu'enregistrer le contenu capté sur un disque dur sans possibilité de faire de l'acquisition en direct sur un PC : il n'est donc pas possible de diffuser en direct un événement avec de telles cartes.

Finalement, on revient souvent au constat qu'il faut prendre l'appareil qui est fait pour ça. Et c'est le bon vieux petit camescope à papa.

Comme pour les précédentes solutions pas forcément la peine de se lancer dans la course à l'armement tant que les prérequis de base sont respectés.

Il faudra souvent recourir à une carte d'acquisition vidéo. Il convient de faire quelques tests là encore mais c'est à priori moins hasardeux.

Dans notre cas ce qui a le mieux marché jusque là c'est un vieux camescope sortant un flux en 756i sur une interface firewire. En plus c'est du matériel qui devient accessible, la carte d'acquisition est peu cher aussi (environ 30€).

Quelques détails à vérifier, comme pour la solution à base d'appareil photo, on ne veut pas d'indication en incrustation sur l'image, pas même quand on utilise le zoom de la caméra.

L'encodage

Maintenant que nous avons notre source vidéo et audio, il nous faut un ordinateur qui va encoder ces flux, les assembler et les envoyer vers un serveur de diffusion.

Chez FAImaison, on a mis ça sous le format de mallette, c'est pratique pour le transport, il y a assez de place pour mettre des câbles, des adaptateurs, et même d'avoir un réseau pré-câblé avec des points d'accès Wifi :

Quand tout le bazar est enlevé :

Point d'amélioration possible : choisir des matériaux plus robustes.

Autre chose d'intéressant avec la formule mallette : le réseau.

La mallette intègre sa propre "infrastructure" réseau. Par là on entend un routeur qui prend en "entrée" le réseau du lieu, et "sort" sur un point d'accès Wifi et sur un réseau "streaming" (où on branche le PC de la mallette et éventuellement d'autres machines: suivi, supervision, monitoring, communication événementielle, ...).

Cette infrastructure permet deux choses intéressantes : proposer du Wifi aux visiteurs et avoir un réseau dédié à nos machines (streaming, monitoring, événementiel, ...).

Amener du Wifi est très apprécié par les visiteurs (encore plus quand le lieu d'accueil n'en donne pas d'habitude). Le problème c'est que les utilisateurs de ce réseau ont besoin de bande passante, notre stream aussi. Pour nous assurer que la partie streaming dispose d'une quantité de bande passante suffisante, on met de la QOS.

Si le lieu dispose déjà d'un accès public, on dit aux visiteurs d'utiliser notre réseau et on ne communique pas la procédure pour utiliser le réseau Wifi du lieu.

Pour conclure sur la partie matériel : vous pouvez faire avec les moyens du bord et adapter au fur et à mesure. Pour ma part je continue d'améliorer le dispositif.

Coté logiciels, on utilise :

• ffmpeg (+video4linux)
• oggfwd

Une commande typique :

ffmpeg -f alsa -ac 1 -ar 48000 -i hw:0,0 -f video4linux2 -i /dev/video0 -s 640x480 -r 10 -codec:v libtheora -qscale:v 7 -codec:a libvorbis -qscale:a 5 -f ogg - | oggfwd server.example.com 8000 password /mountpoint

ffmpeg :

• -f alsa -ac 1 -ar 48000 -i hw:0,0 permet de configurer l'entrée son
• -f video4linux2 -i /dev/video0 -s 640x480 -r 10 permet de configurer l'entrée vidéo
• -codec:v libtheora -qscale:v 7 -codec:a libvorbis -qscale:a 5 -f ogg permet de configurer les codecs et la qualité vidéo/audio de sortie

Ensuite, on passe ça à l'exécutable oggfwd qui a pour objet de se connecter au serveur de diffusion Icecast et de lui envoyer le flux encodé.

Cette commande prend en premier paramètre le nom ou l'adresse IP du serveur Icecast, puis le port, le mot de passe et le nom du point de montage sur lequel le flux sera accessible. La commande oggfwd offre des arguments pour, entre autres, changer le titre du flux.

Pour résumer, la ligne de commande précédente prend le premier périphérique alsa sur un canal, avec une fréquence d'échantillonnage de 48kHz; le premier périphérique vidéo avec une résolution de 640x480 à 10 images par seconde; encode ces deux et l'envoie au serveur de diffusion. Le flux est ensuite visible à l'adresse http://server.example.com:8000/mountpoint.

Le Serveur de diffusion

Le but du serveur de diffusion est de prendre en entrée un flux vidéo (en provenance du lieu de notre événement) et de le "recopier" vers les clients qui en font la demande. Ainsi il faut disposer de suffisamment de bande passante montante pour accueillir l'audience estimée. Il faudra ajuster la résolution, la qualité, le nombre d'images par secondes, les bitrates audio / vidéo en fonction des ressources disponibles.

Jusque là nous avons utilisé Icecast comme serveur de diffusion.

On me pose souvent la question de la consommation en ressources de la machine qui héberge un serveur Icecast. Réponse : très peu.

Que faire quand le serveur de diffusion atteint les limites des ressources qui lui sont allouées ?

C'est ici que ca devient intéressant :)

Passage à l'échelle

Un serveur Icecast avec une connexion 100Mb/s peut servir environ 200 connexions maximum avec une vidéo à environ 500Kb/s.

Vous en conviendrez c'est peu. Surtout quand on a réussi sa communication :)

Icecast propose un mode relais. Il y a 2 configurations possibles :

• Relais simple
• Master/slave

Dans le premier cas, chaque relais agit comme un client du serveur principal en ne recopiant qu'un point de montage (flux) spécifique. C'est pratique mais pas très flexible (il faut changer la configuration de chaque relais à la main pour ajouter un nouveau point de montage).

Le second cas est plus intéressant : le master est la machine vers laquelle on pousse le flux vidéo depuis le lieu de l'événement, les machines configurées en slave vont chercher la liste des points de montage disponibles sur le master et les rendent accessibles à d'autres clients.

Le master et les slaves proposent les mêmes points de montage (je simplifie un peu, puisqu'on peut avoir des points de montage en plus sur le slave que n'aura pas le master, etc...).

La méthode classique pour répartir les clients sur les différents serveurs de diffusion (donc master + slaves) c'est de créer une liste de lecture avec les différents serveurs.

[playlist]
NumberOfEntries=3
Title1= Un super stream
File1=http://server1:8000/mountpoint
Title2= Un super stream
File2=http://server2:8000/mountpoint
Title3= Un super stream
File3=http://server3:8000/mountpoint

Il y a deux inconvénients :

• Les lecteurs HTML5 ne supportent pas les listes de lectures. Par contre on a un super membre de FAImaison qui nous a développé une lib qui permet de faire ca (et qui permet aussi la reprise sur incident).
• Le premier serveur en haut de cette liste est celui qui sera utilisé en priorité par tous les clients (sauf si on a des clients avec le mode aléatoire actif).

C'est là que vient alors l'idée d'un répartiteur de charge dynamique. Le principe est simple : choisir quel serveur sera utilisé par un client donné.

L'idéal étant d'avoir une charge répartie uniformément sur les différentes machines (ce sont des machines prêtées par des membres de la FFDN qui ont pas nécessairement qu'Icecat à faire tourner). Heureusement, Icecast permet de créer des templates au format XSL. Il est alors possible de récupérer la charge du serveur par point de montage, le nombre de connexions maximum, ...

<load>
  <mount name="/mountpoint" max_listeners_count="100" current_listeners_count="1"/>
</load>

En se basant sur ces données, on peut rediriger chaque client vers le serveur le moins chargé à l'aide d'un logiciel (représenté par le bloc "Load Balancer") :

Dans un premier temps, le client demande au "load balancer" une liste de lecture. Le "load balancer" créé la liste des serveurs de diffusion disponibles du moins chargé au plus chargé et l'envoie au client. Le client joint alors le premier serveur de la liste qui lui a été donné. En parallèle, le "load balancer" interroge chaque serveur de diffusion pour connaître la charge actuelle (et réelle) de ceux-ci.

Ce logiciel propose également une interface de monitoring pour surveiller l'ensemble des machines de diffusion et rapporter l'audience globale et l'audience par serveur.

En haut de la page on retrouve l'audience globale, ici : durant des tests avant la conférence de Jean-Marc Manach :

Ce "load balancer" a été développé en Python, avec le framework django; celery avec un backend RabbitMQ ont été utilisés pour gérer des tâches asynchrones comme celles de récupérer la charge des différents serveurs ou encore de sauvegarder l'audience à intervalles réguliers. Des solutions moins « DIY » sont à explorer.

Les pistes d'amélioration

Comme à chaque fois on trouve de nouvelles pistes d'amélioration.

Quelques idées en vrac :

• Revoir les matériaux de la mallette
• Changement de caméra
• Plus de redondance (éviter les SPOF, actuellement le serveur master et le load balancer ne sont pas redondés)
• Tester HAProxy en lieu et place du "load balancer" custom
• Tester des solutions p2p

~