DOCUMENTATION QUI NE CONCERNE QUE LA VERSION 2.7.0 (et supérieure) DE POD
Suite à la pandémie de COVID-19, il a été mis en place, à l'université de Montpellier, un système de classe virtuelle Open Source reposant sur Big Blue Button (BBB).
Pour informations, BigBlueButton (https://bigbluebutton.org/) est un outil de classe virtuelle ayant les fonctionnalités suivantes :
Il faut savoir que l'enregistrement d'une session BBB se fait sous la forme d'une présentation Web. Cette présentation Web peut alors être lue directement depuis un navigateur, en ayant récupéré l'adresse dans le client BBB (typiquement Moodle ou Greenlight).
Bien que cette façon de faire est des avantages - en particulier concernant l'espace de stockage (une présentation Web n'étant pas une vidéo, sa taille est très petite) - elle présente quelques inconvénients, à savoir :
Au final, certains enseignants souhaitaient convertir ces présentations Web sous la forme de vidéos, et les publier directement dans la plateforme vidéo de l'université, qui repose sur Pod v2.
Pour résoudre cette problématique et répondre favorablement aux demandes des enseignants de l'université, j'ai conçu la solution suivante, qui se repose totalement sur Pod v2.
Cette solution fonctionne pour BigBlueButton mais également pour Scalelite (cf. https://github.com/blindsidenetworks/scalelite), un système de répartition de charge pour BigBlueButton.
Ne souhaitant pas que l'ensemble des présentations Web BigBlueButton soient converties automatiquement en vidéo, surtout qu'elles n'ont pas toutes vocation à l'être, il fallait trouver une solution permettant que cela soit l'utilisateur qui choisisse s'il souhaite, ou non, convertir ses présentations Web. De plus, cette solution permet également de n'encoder une présentation Web BigBlueButton qu'une seule fois au maximum; dans le cas où plusieurs modérateurs ont participé à la session BBB, n'importe lequel pourra réaliser cette conversion. Les autres ne pourront plus convertir cette présentation Web, mais ils auront accès à l'information de qui à réaliser cet encodage. Ils pourront alors contacter directement cet utilisateur pour lui demander de partager la vidéo avec eux, voire de les mettre en tant que propriétaire additionnelle de la vidéo. |
L'idée de cette solution est de :
Par exemple, voici la liste des sessions BigBlueButton réalisée à des fins de test.
Voici l'écran permettant la confirmation de la création d'une vidéo à partir d'une présentation BigBlueButton.
Voici le rendu d'une vidéo créée à partir d'une présentation Web BigBlueButton.
Une vidéo créée à partir d'une présentation Web BigBlueButton est réellement identique à cette présentation Web, ce qui signifie qu'elle contient :
Cette solution repose totalement sur Pod et n'impacte en rien BigBlueButton. Aucune modification n'est à réaliser côté BigBlueButton. |
Les informations concernant les modérateurs dans BigBlueButton dépendent du client BBB utilisé : Greenlight ou le plugin mod_bigbluebuttonbn pour Moodle. Le système réalisé n'a été testé qu'avec le plugin mod_bigbluebuttonbn pour Moodle (CASifié, donc les données proviennent de notre annuaire LDAP); cela signifie que les modérateurs sont définis - dans mon cas - sous la forme "Prenom Nom". Il est possible de paramétrer ce format, via le paramètre BBB_USERNAME_FORMAT (à partir de la version 2.7.2). A l'heure actuelle, les formats "Prenom Nom" ou "Nom Prenom" peuvent êtré gérés via ce paramétrage.
|
Pour convertir une présentation Web BigBlueButton en vidéo, certains plugins existent déjà sur Github; il ne paraît pas raisonnable de redévelopper un tel système.
Pour arriver à faire mon choix, j'ai testé les 3 solutions suivantes :
A l'époque de mes tests, le plugin bbb-video-download (https://github.com/tilmanmoser/bbb-video-download) n'existait pas encore. Il pourrait être intéressant de le tester par la suite, s'il s'avère plus prometteur que bbb-recorder. |
Au final, voici ce qui est ressorti de mes tests.
| bbb-recorder | bbb-download | BigBlueButton-liveStreaming | |
|---|---|---|---|
| Enregistre un cours BBB en vidéo |  format webm, mp4 | |  peut enregistré le cours qu'il publie en live au format mkv |
| Exporte un cours BBB en direct live | |  | |
| Enregistre un cours en temps réel | | | |
| Indépendance vis-à-vis de BigBlueButton | peut-être installé sur n'importe quel serveur |
| peut-être installé sur n'importe quel serveur |
| Contenu de la vidéo finale | présentation audio vidéopartage d'écranchatwhiteboard | présentation audio vidéo partage d'écran chat whiteboard | présentation audio vidéo partage d'écran chat whiteboard |
| Technologies | NodeJS, xvfb, Chrome, ffmpeg, shell | Python, ruby, ffmpeg, shell | Docker, python, xvfb, ffmpeg, shell |
| Mise à jour régulière | | Dernière mise à jour en 2018 | |
| Notion de charge |  Le fichier vidéo fait entre 2 et 4Mo par minute, en webm ou mp4 | Encode nécessairement toutes les Web conférences en vidéo |
|
| Commentaires | Facilement modifiable (scripts JS pour NodeJS) | Complètement intégré à BBB (une fois un cours enregistré terminé, une vidéo - en plus de la présentation - est générée) | Il faut bien respecter l'ordre de démarrage (session BBB avant liveStreaming). |
| Remarques sur mes tests | Peut également publier en live le cours (publication RTMP). |  Le fait de partager l'écran semble - dans certains cas - faire planter ce plugin, avec une erreur "Conversion failed ( Error writing trailer of rtmp://xxxx:xxxx@xxxx.umontpellier.fr:1935/live/myStream: Broken pipe)". |
Aux vues des besoins, j'ai alors choisi bbb-recorder comme solution pour la conversion des présentations Web BigBlueButton en fichier vidéo.
Techniquement, la solution repose sur :
Le fait d'exécuter le script bbb-recorder réalise les étapes suivantes :
Il est nécessaire d'installer bbb-recorder sur les serveurs d'encodage.
La documentation de référence est accessible ici : https://github.com/jibon57/bbb-recorder
Pour ma part, sur les serveurs CentOS 7, voici ce qui a été réalisé.
Ce plugin n'a pas besoin d'être installé sur un serveur BigBlueButton.
Installation de Chrome et des pré-requis (sous root)
# Install xvfb podtest@ts-sun:~/$ yum install xorg-x11-server-Xvfb podtest@ts-sun:~/$ wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm podtest@ts-sun:~/$ yum localinstall google-chrome-stable_current_x86_64.rpm |
Étant un serveur d'encodage, je considère que ffmpeg est déjà installé. Si besoin, il est nécessaire d'installer ffmpeg.
Installation effective
Voici l'installation pour un utilisateur %userpod% (pensez à remplacer %userpod% par votre utilisateur).
%userpod%@ts-sun:~/$ cd ~ %userpod%@ts-sun:~/$ git clone https://github.com/jibon57/bbb-recorder %userpod%@ts-sun:~/$ cd bbb-recorder %userpod%@ts-sun:~/bbb-recorder/$ npm install --ignore-scripts %userpod%@ts-sun:~/bbb-recorder/$ cp .env.example .env |
Gestion du répertoire contenant les vidéos : dans mon cas /data/www/%userpod%/bbb-recorder et du répertoire de logs /data/www/%userpod%/bbb-recorder/logs.
%userpod%@ts-sun:~/bbb-recorder/$ mkdir /data/www/%userpod%/bbb-recorder %userpod%@ts-sun:~/bbb-recorder/$ mkdir /data/www/%userpod%/bbb-recorder/logs |
{
"rtmpUrl": "rtmp://xxxxxxxx:xxxxxxxxxx@xxxxx.umontpellier.fr:1935/live/stream",
"ffmpegServer": "ws://localhost",
"ffmpegServerPort": 4000,
"auth": "xxxx",
"copyToPath": "/data/www/%userpod%/bbb-recorder"
} |
const BBBUrl = "https://xxxx.umontpellier.fr/bigbluebutton/", BBBSalt = "xxxxxxxxxxxxxxxxxxxx", joinName = "recorder"; |
Il faut bien penser que bbb-recorder utilise un répertoire temporaire pour générer une vidéo, avant que celle-ci ne soit copiée dans le répertoire configurée (cf. copyToPath). Ce répertoire temporaire correspond à ../Downloads. Ainsi, dans le cas d'une installation dans le home directory de l'utilisateur %userpod%, le répertoire temporaire créé et utilisé par bbb-recorder est /home/%userpod%/Downloads. Il est nécessaire qu'un espace de stockage suffisant soit alors prévu. |
Une fois bbb-recorder installé sur les différents serveurs d'encodage, il reste à configurer le plugin bbb directement dans Pod, via l'édition de fichier custom/settings_local.py :
## # BigBlueButton settings # # Use of BigBlueButton USE_BBB = True # Directory of bbb-recorder plugin (see documentation https://github.com/jibon57/bbb-recorder) # bbb-recorder must be installed in this directory, on all encoding servers # bbb-recorder create a directory 'homedir'/Downloads that needs disk space DEFAULT_BBB_PLUGIN = '/home/%userpod%/bbb-recorder/' # Directory that will contain the video files generated by bbb-recorder DEFAULT_BBB_PATH = '/data/www/%userpod%/bbb-recorder/' # BigBlueButton or Scalelite server URL, where BBB Web presentation and API are BBB_SERVER_URL = 'https://bbb.univ.fr/' # BigBlueButton key or Scalelite LOADBALANCER_SECRET BBB_SECRET_KEY = 'xxxxxxxxxxxxxxxxxxxxxxxx' # Type of the generated video by default DEFAULT_BBB_TYPE_ID = 1 # Number of days before removal the meetings (and associated users) not already published # To not remove old meetings, set 0 value BBB_NUMBER_DAYS_BEFORE_DELETE = 0 |
Les éléments de paramétrage sont les suivants :
DEFAULT_BBB_PLUGIN : répertoire d'installation de bbb-recorder sur les serveurs d'encodage (cf. paragraphe précédent)
Valeurs possibles : 'first_name last_name', 'last_name first_name'
Exemple 1 : si dans le serveur BBB, vous avez un utilisateur au format 'John Doe', mettez BBB_USERNAME_FORMAT = 'first_name last_name' |
Concernant le répertoire contenant les fichiers vidéos générés par bbb-recorder (DEFAULT_BBB_PATH), il est à créer manuellement - en même temps que son sous-répertoire des logs - avec les lignes de commande suivantes; n'hésitez pas à les modifier à votre convenance selon votre architecture système et vos droits :
%userpod%@ts-sun:~/$ mkdir /data/www/%userpod%/bbb-recorder %userpod%@ts-sun:~/$ mkdir /data/www/%userpod%/bbb-recorder/logs %userpod%@ts-sun:~/$ chown %userpod%:nginx /data/www/%userpod%/bbb-recorder/logs |
Il est vrai qu'une création automatique de ces répertoires auraient pu être possible, mais aux vues des problèmes que cela aurait pu engendrer, en lien avec l'architecture et les droits, il m'a paru préférable que l'administrateur de Pod créé ces 2 répertoires à la main. Il sait ce qu'il fait et pourra ainsi choisir son emplacement, ses droits ou autres. |
Comme expliqué préalablement, le système repose principalement sur un job CRON. Ce job CRON est à installer sur un serveur Pod de votre choix et devra tourner régulièrement (toutes les 5 minutes me paraît un délai correct).
Le script à lancer est positionné dans django_projects/podv2/pod/video/management/commands/bbb.py et permet de gérer les enregistrements effectués par BigBlueButton.
Personnellement, mon CRON est configuré de la sorte :
crontab -e */5 * * * * /usr/bin/bash -c 'export WORKON_HOME=/data/www/%userpod%/.virtualenvs; export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3.6; cd /data/www/%userpod%/django_projects/podv2; source /usr/bin/virtualenvwrapper.sh; workon django_pod; python manage.py bbb |
Voici les explications complémentaires sur ce que réalise cette tâche :
Ce script réalise une connexion au serveur BBB / Scalelite pour obtenir des informations sur les réunions en cours et enregistre les informations dans la base de données de Pod.
Ceci est utile pour obtenir les sessions actuelles et la liste des modérateurs (cf. l'avertissement plus bas sur la correspondance des utilisateurs) de ces réunions.
Le script recherche ensuite les enregistrements disponibles pour les réunions sauvegardées. Par précaution, cela ne recherche que les présentations Web des réunions réalisées depuis moins de 4 jours.
L'idée des 4 jours est d'éviter de traiter les enregistrements qui ont été supprimés ou avec de mauvaises données dans la base de données.
Au final, l'API BigBlueButton présente un statut d'enregistrement (attribut recording) mais qui s'avère peu fiable. Dans l'environnement UM, il est quasiment tout le temps à vrai, alors que les sessions n'ont pas été enregistrées. |
Le script tente de réaliser une correspondance entre les utilisateurs BBB - connus par leur prénom et nom seulement - et les utilisateurs existants de pod.
À chaque utilisation de ce script, nous recherchons les correspondances pour les utilisateurs BBB qui ne sont pas encore connus en tant qu'utilisateurs de Po
Je me répète, mais les informations concernant les modérateurs dans BigBlueButton dépendent du client BBB utilisé : Greenlight ou le plugin mod_bigbluebuttonbn pour Moodle. Le système réalisé n'a été testé qu'avec le plugin mod_bigbluebuttonbn pour Moodle (CASifié, donc les données proviennent de notre annuaire LDAP); cela signifie que les modérateurs sont définis - dans mon cas - sous la forme "Prenom Nom". Il est possible de paramétrer ce format, via le paramètre BBB_USERNAME_FORMAT. A l'heure actuelle, les formats "Prenom Nom" ou "Nom Prenom" peuvent êtré gérés via ce paramétrage.
Il est également possible de modifier le code source pour que cette correspondance se réalise, selon le contexte de l'établissement cible. |
Le script vérifie ensuite l'existence de fichiers vidéos dans le répertoire - paramétré via DEFAULT_BBB_PATH. Cela signifie que ces fichiers vidéo ont été générés par bbb-recorder - configuré via DEFAULT_BBB_PLUGIN.
Si des fichiers vidéos sont trouvés, le script va lancer la tâche d'encodage correspondante pour les enregistrer en tant que vidéo Pod.
Il faut bien comprendre que cette étape 4 vient après la publication de présentations Web BigBlueButton par l'usager, dans Pod. Au final, en publiant une présentation Web BigBlueButton, cette présentation est convertie en fichier vidéo qui sera enregistré dans le répertoire, paramétré via DEFAULT_BBB_PATH. L'étape 4 du script, lancé par le CRON, récupèrera alors ce fichier vidéo et la convertira en vidéo Pod, qui apparaîtra alors dans "Mes vidéos" de l'utilisateur. Ainsi, 2 encodages sont réalisés (1 pour convertir la présentation Web BBB en fichier vidéo,1 pour convertir le fichier vidéo en vidéo Pod), mais, aux vues de mes besoins, je n'ai pas trouvé d'autres solutions. |
Si vous avez positionnée une valeur pour BBB_NUMBER_DAYS_BEFORE_DELETE dans votre fichier de configuration, le script va alors supprimer les anciennes sessions BigBlueButton - non publiées - antérieures au nombre de jours défini, ainsi que les utilisateurs associés.
Par exemple : si vous avez positionné BBB_NUMBER_DAYS_BEFORE_DELETE = 90, les sessions BigBlueButton vieilles de plus de 90 jours, qui n'ont pas été publiées précédemment, seront automatiquement supprimées.
| Si ce paramètre BBB_NUMBER_DAYS_BEFORE_DELETE n'existe pas ou a pour valeur 0, aucune suppression n'est réalisée. |
Finalement, s'il y a eu au moins une erreur, un e-mail est envoyé aux administrateurs de Pod.
Dans le cas normal, où tout se passe bien, ce système ne devrait pas engendrer d'exploitation particulière et vous ne recevrez d'emails de la part du système qu'en cas d'erreurs (typiquement si le serveur BigBlueButton ou Scalelite ne répond plus...).
Cependant, une interface d'administration a été prévue afin de suivi des sessions BigBlueButton mais également pour réaliser l'exploitation en cas d'incidents.
Via l'administration de Pod, vous aurez accès à un nouveau menu, BBB, qui contient les options Sessions et Utilisateurs.
Voici l'interface de listing des sessions réalisées dans BigBlueButton, et récupérées via le job :
Il est possible de modifier les données si nécessaire.
Par exemple, via cette interface, il est possible de relancer le processus global pour cette session en modifiant l'étape de l'encodage à 0 et en ne choisissant aucun utilisateur (dans la liste de sélection : ------). Suite à ces changements, il sera possible de republier la présentation Web. |
Voici l'interface de listing des modérateurs de sessions dans BigBlueButton, et récupérées via le job :
Il est possible de modifier les données si nécessaire.
Par exemple, via cette interface, il est possible d'affecter un utilisateur à une session, voire modifier une correspondance si celle-ci n'a pas été trouvée ou est erronée. |
Si nécessaire, il est possible de voir les traitements réalisés par le script - qui doit normalement être exécuté via un job CRON.
Pour ce faire :
Attention : le mode debug ne doit pas être activé dans un environnement de production.Il ne reste plus qu'à exécuter ce script /django_projects/podv2/pod/video/management/commands/bbb.py manuellement via la commande python manage.py bbb main :
cd /data/www/%userpod%/django_projects/podv2 workon django_pod python manage.py bbb main |
En mode débug, le script affiche l'ensemble des traitements réalisés :
Ce système utilise les différents fichiers de logs suivants :
Ce point est crucial pour que le système fonctionne correctement : une correspondance doit exister sur le "Prenom Nom" ou "Nom Prenom" (selon la configuration BBB_USERNAME_FORMAT) des modérateurs de BigBlueButton et le "Prenom Nom" des utilisateurs dans la base de données de Pod.
A priori, cela devrait pouvoir fonctionner avec Greenlight si celui-ci est configuré pour utiliser l'annuaire LDAP de l'établissement et les champs givenName et sn.