UCAmedia : La nouvelle plateforme de création, gestion et diffusion de médias de l'Université Clermont Auvergne basée sur Opencast - JRES 2021/22
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
UCAmedia : La nouvelle plateforme de création,
gestion et diffusion de médias de l’Université
Clermont Auvergne basée sur Opencast
Yoann Raison
Lylian Blaud
Cédric Bois
Alexis Ozwald
David Delon
DSI, UCA
7 avenue Blaise Pascal
63170 Aubière
Résumé
La fusion des deux universités auvergnates a entraîné de profonds changements, notamment au
niveau structurel avec le regroupement des deux services informatiques. En effet, chaque
établissement disposant de son propre système de captation, il était indispensable de mettre en
place une nouvelle solution unique, afin d’homogénéiser la production et la diffusion de capsules
audio et vidéo.
Après avoir étudié plusieurs systèmes existants, la solution Opencast est apparue comme étant la
plus adaptée et a été retenue selon plusieurs critères : son coût, sa compatibilité avec les agents de
capture Extrons (SMP 351), sa communauté très réactive et sa modularité qui offre une liberté de
développement.
Le système ne couvrant pas totalement l’ensemble de nos besoins, nous avons développé la suite
logicielle « UCAmedia », afin d’intégrer au mieux cette solution à notre système d’information.
L’objectif était d’urbaniser la chaîne de production afin de rendre autonomes les enseignants et les
étudiants, de la création de leurs médias interactifs, jusqu’à la publication en ligne sur la WebTV.
Cette présentation détaillera les choix techniques, fonctionnels et organisationnels qui ont permis à
« UCAmedia » de devenir le nouvel outil de gestion, partage et diffusion de l’Université Clermont
Auvergne (UCA).
Mots-clefs
Média, Vidéo, Streaming, Encodage, FFMPEG
JRES 2021 – Marseille 1/17
1 Contexte
L’Université Clermont Auvergne étant le résultat de la fusion entre l’Université d’Auvergne (UDA)
et l’Université Blaise Pascal (UBP), les systèmes de captations de ces deux établissements étaient
différents en tout point. En fin d’année 2018, la question d’uniformisation des systèmes
d’information était à l’ordre du jour. Les deux solutions existantes, Inwicast et Mediasite n’étaient
plus maintenues et il était impératif de migrer vers un système unique pour la nouvelle université.
La direction a donc missionné l’équipe de développement logiciel pour démarrer un nouveau projet.
Un groupe de travail composé de la DSI, du pôle d’innovation pédagogique, de la bibliothèque
universitaire et du service de communication a été formé. Chaque service a exposé ses souhaits
quant à cette nouvelle solution, permettant la rédaction d’un cahier des charges visant à définir les
spécifications de base de ce projet. L’objectif était de préserver l’autonomie des enseignants lors de
l’utilisation du système de captation et de garantir au minimum les mêmes fonctionnalités que les
solutions précédentes.
À la demande de la direction, trois solutions ont été examinées : Panopto, Ubicast et Opencast.
L’équipe de la DSI en charge du projet (Yoann Raison et Lylian Blaud) devait réaliser des tests sur
ces solutions et lister les avantages et inconvénients afin de présenter une analyse pour statuer sur
l’offre à adopter. Du fait de de nombreux avantages : maîtrise des coûts, open source, modularité et
une communauté très réactive, la solution Opencast fut retenue.
Les livrables du projet ont été divisés dans le temps pour permettre aux utilisateurs d’utiliser l’outil
le plus rapidement possible :
• Partie 1 (2019) :
◦ mise en place de l’architecture Opencast ;
◦ outil de gestion des vidéos ;
◦ module d’enregistrement depuis un navigateur ;
◦ plugin Moodle1.
• Partie 2 (2020/2021) :
◦ solution de gestion des retransmissions depuis les amphithéâtres ;
◦ solution d’indexation des médias ;
◦ WebTV.
1 Plateforme pédagogique de l’université.
JRES 2021 – Marseille 2/17
2 Architecture Système
Figure 1: Architecture système de l’outil UCAmedia
2.1 Opencast
Lors du premier déploiement de la solution, nous avons procédé à une installation « All-in-one »
afin de découvrir, prendre en main et valider l'interopérabilité avec notre système d’information.
Une telle installation n’était pas adaptée pour une mise en production. En effet, si le serveur est
soumis à une forte charge, comme pour le traitement de vidéos, cela affectera la lecture des médias
pour les utilisateurs. Il était donc impératif d’utiliser plusieurs serveurs afin de séparer les
différentes couches applicatives pour gagner en performance et scalabilité.
Nous avons décidé d’adopter une configuration distribuée en répartissant sur trois machines
virtuelles les nœuds d’administration, de diffusion et d’encodage de secours. Une machine physique
est quant à elle exclusivement réservée au traitement des vidéos. Elle possède 56 cœurs et une carte
graphique Nvidia Tesla T4 utilisant la technologie NVENC, créée par NVIDIA pour effectuer
l’encodage matériel de vidéos. Un « Node Exporter2 » a été installé sur cette machine afin de
contrôler ses performances (métriques3) lors des traitements.
2.2 Machines virtuelles
Nous avons travaillé étroitement avec l’équipe système afin de déterminer l’architecture que nous
souhaitions mettre en place, avec pour objectif une répartition des charges la plus optimale possible.
Cette architecture système (cf. Figure 1) se compose de cinq serveurs pour les applications tierces et
2 Transforme les métriques de sources spécifiques dans un format pouvant être ingéré par Prometheus.
3 Mesure quantifiable de l’état de la machine à un instant T.
JRES 2021 – Marseille 3/17
de quatre pour Opencast, le tout sous distribution CentOS. Le choix du système d’exploitation était
motivé par la facilité de déploiement, d’administration et de mise à jour pour l’équipe système.
La suite logicielle UCAmedia se compose quant à elle, de deux machines virtuelles, l’une
hébergeant les outils de gestion et d’indexation de médias et l’autre étant exclusivement réservée à
l’enregistreur UCAstudio. Cette dernière est dimensionnée afin de pouvoir supporter l’encodage
dynamique des flux transmis par les clients lors de leurs enregistrements.
2.3 Stockage
Concernant le stockage des données, nous avons fait le choix de mettre en place un stockage
partagé, avec un export NFS4 vers une baie EMC Unity 300. Ce stockage permet de garder les liens
physiques créés par Opencast afin d’éviter de dupliquer les médias et de ne pas utiliser de l’espace
disque inutilement. Deux solutions ont également été mises en œuvre pour la sécurisation des
données. La première est un instantané5 quotidien réalisé automatiquement par la baie sur les deux
dernières semaines, qui permet d’identifier rapidement des changements opérés au niveau
applicatif. La seconde consiste en une sauvegarde complète du système de fichier sur une
bandothèque LTO76. Ce procédé est effectué par l’intermédiaire de notre logiciel « Time
Navigator » (Tina7) qui utilise le protocole de gestion des données réseau (NDMP 8) et permet de
faciliter la sauvegarde des nombreux liens physiques générés par Opencast. Enfin, une machine
dédiée aux tests a été mise en service avec une installation de la solution en « All-in-one » afin de
maquetter les montées de version et de valider les modifications du code source avant une mise en
production.
2.4 Équipements
Après avoir consulté un intégrateur audiovisuel, nous avons fait le choix de nous orienter vers le
fabricant Extron, et notamment l’encodeur physique SMP351. En effet, il peut être configuré afin
de s’intégrer directement avec le système Opencast. Il permet d’enregistrer et de diffuser un ou
plusieurs flux provenant de caméras, microphones et écrans connectés, et produit un fichier MP4
qui est transmis à Opencast. Sa capacité à générer deux flux offre à l’utilisateur final la possibilité
de modifier la disposition de sa vidéo directement depuis le lecteur vidéo (cf. figure 2).
Figure 2: Exemple de vidéo double flux
4 Network File System.
5 Snapshot.
6 Linear Tape-Open, stockage sur bande magnétique.
7 Logiciel de sauvegarde et de restauration de données.
8 Network Data Management Protocol.
JRES 2021 – Marseille 4/17
3 L’écosystème
Figure 3: Schéma fonctionnel de l'outil UCAmedia
Toutes ces applications gravitent autour du cœur « Opencast » qui nous permet de créer, de
centraliser l’information lors de la gestion et de diffuser les vidéos publiquement ou localement.
Pour aider à la compréhension du système global, les applications sont réparties en trois catégories
(Cf. figure 4).
Figure 4: Répartition des applications
Sur Opencast, toutes les étapes du processus sont personnalisables par l’intermédiaire du système de
workflow9 intégré. Ils permettent de réaliser une suite de traitement sur la vidéo avant publication.
Par exemple, lors du transfert d’un média, un workflow examine, traite et publie la vidéo en
fonction de la résolution et du type de fichier. D’autres peuvent notamment être utilisés pour mettre
à jour les contrôles d’accès, ajouter une image de prévisualisation, des sous-titres ou même éditer la
vidéo.
9 Suite de tâches ou d’opérations automatisées.
JRES 2021 – Marseille 5/17
4 Créer
4.1 UCAStudio
Figure 5: Capture d'enregistrement UCAStudio
Lors du premier déploiement d’Opencast en version 6, aucun outil de production de vidéos depuis
son navigateur n’était implémenté. Nous connaissions la pertinence de procurer un tel service aux
utilisateurs non-initiés. En effet, la solution Inwicast proposait un « WebRecorder » offrant ce type
de service. Toutefois, cette application présentait quelques limites. Après une exploitation de
plusieurs années, des problèmes récurrents liés à l’espace disque et l’utilisation de la mémoire vive
par l’outil, ont été à maintes reprises remontés par les utilisateurs. Cela se traduisait par le « crash »
du navigateur, entraînant ainsi la perte totale de l’enregistrement effectué.
Afin de proposer un outil similaire, nous avons développé le studio d’enregistrement
« UCAStudio » intégré à l’ENT et à la plateforme pédagogique. Cet outil est un fork 10 du projet
« Ghettostudio », dont le fonctionnement était similaire à celui du WebRecorder d’Inwicast, avec
entre autres les problèmes liés aux ressources insuffisantes des utilisateurs. Son auteur, Duncan
Smith, est devenu contributeur pour le studio d’enregistrement que propose aujourd’hui Opencast.
Afin de ne pas réitérer ces problèmes de mémoire et d'espace propre à chaque utilisateur, nous
avons décidé de nous tourner vers la technologie socket.io, qui permet d'établir une communication
directe entre le client (navigateur) et le serveur afin d’envoyer au fur et à mesure, par segments,
l'enregistrement de l'utilisateur. De ce fait, les ressources de l’utilisateur sont très peu impactées et
nous pouvons nous abstraire de la configuration du périphérique utilisé pour s'enregistrer.
UCAStudio utilise les capacités fournies par l’API WebRTC, intégrée aux navigateurs modernes
permettant d’accéder aux périphériques de l’utilisateur. Lors d'un enregistrement de flux, les pistes
audio et/ou vidéo partagées sont stockées de façon temporaire dans la mémoire vive du navigateur.
10 Copie d’un projet permettant d’y apporter publiquement des modifications.
JRES 2021 – Marseille 6/17
Ces segments, appelés « blob », sont envoyés toutes les secondes d’enregistrement au serveur
socket.io, qui encode dynamiquement ces données avec l'outil FFMPEG 11. Cela évite de surcharger
la mémoire ou le stockage du poste client. Une fois l'enregistrement terminé, selon la bande
passante de l’utilisateur, les quelques segments restants sont envoyés vers le serveur. Le média
résultant est alors soumis à Opencast pour le traitement. L’utilisateur peut quant à lui prévisualiser
les flux qu’il vient d’enregistrer et récupérer directement une archive de son média avec les
métadonnées saisies au préalable. S’il le souhaite, il peut également générer un nouveau média qui
incorpore les deux sources fusionnées.
La première version de l’application a été développée sans tenir compte du débit de l’utilisateur. Les
plus hautes résolutions étaient sélectionnées sans tenir compte de leur vitesse de connexion, ce qui
engendrait une mise en mémoire trop importante des flux et provoquait le crash de l’application.
Nous avons donc développé un système de contrôle de débit qui permet d’orienter l’utilisateur vers
les résolutions adéquates. Lors du partage de la caméra, un contrôle est réalisé afin de déterminer
les différentes résolutions supportées par la webcam.
Afin d’optimiser la transmission des flux vers le serveur d’encodage, nous avons établi un tableau
de correspondance nous permettant de paramétrer la méthode de partage de WebRTC afin de définir
les débits vidéo et fréquences d’images en adéquation avec la bande passante de l’utilisateur.
A titre d’exemple, avec une connexion fibre, l'enregistrement de deux flux (caméra et écran en
haute résolution) peut être réalisé sur plusieurs heures d'affilées.
Figure 6: Exemple d'enregistrement terminé
11 FFmpeg est une collection de logiciels libres destinés au traitement de flux audio ou vidéo
JRES 2021 – Marseille 7/17
4.2 Assistant de production
Figure 7: Assistant de production
Toujours dans un souci de rendre accessible au plus grand nombre la création et la diffusion
d’enregistrements, nous avons développé un assistant de production, disponible depuis les salles et
amphithéâtres équipés avec le matériel Extron.
Cet assistant permet dans un premier temps de sélectionner la salle où l'on souhaite effectuer
l'enregistrement, puis, grâce à une connexion au logiciel d'emploi du temps (ADE), de consulter son
occupation afin de sélectionner le créneau horaire désiré. L'utilisateur renseigne ensuite le créateur
et les intervenants de la captation, avant de définir, s’il le souhaite, les paramètres de la
retransmission sur la WebTV et/ou Teams.
Concernant la retransmission vers la WebTV, le créateur de l’événement peut sélectionner différents
niveaux d’accessibilité pour sa retransmission tel que la diffusion :
• publique sans restriction ;
• interne à l’UCA par l’intermédiaire du système d’authentification de l’université ;
• externe par la saisie d’un code d’accès communiqué au préalable par le créateur de
l’événement.
Il peut également spécifier s’il souhaite bénéficier d’une fenêtre de discussion instantanée, afin de
permettre les échanges entre les présentateurs et les utilisateurs.
JRES 2021 – Marseille 8/17
D’autre part, nous avons étudié l’API Web du matériel Extron afin d’interfacer des fonctionnalités
de gestion des flux (Cf. figure. 8), permettant à l’utilisateur de pouvoir organiser dynamiquement sa
présentation.
Une fois l’événement terminé, les fichiers vidéo produits sont transférés vers le serveur Opencast.
Le média résultant est mis à disposition de son auteur à travers le gestionnaire de médias (cf. partie
5).
Figure 8: Enregistrement en cours
5 Gérer
Figure 9: Interface du gestionnaire
Opencast possède par défaut un gestionnaire de médias et de bibliothèques12 intégré à l’interface
d’administration des instances. Nous avons décidé de redévelopper une interface plus accessible,
12 Dossier de vidéos appelé « série » dans Opencast.
JRES 2021 – Marseille 9/17
plus riche et plus modulaire, permettant de développer des fonctionnalités supplémentaires autour d’Opencast et de répondre aux besoins exprimés dans le cahier des charges. Cette application est accessible depuis notre ENT et sur la plateforme pédagogique Moodle sous la forme d’un plugin intégré à l’éditeur « TinyMCE ». Cette application a été développée en PHP/Symfony et utilise l’API REST et le nœud ElasticSearch13 d’Opencast pour communiquer. Le besoin exprimé par les équipes pédagogiques, les enseignants et les étudiants était de centraliser la gestion, la création et la diffusion des médias. Pour répondre à cette demande, nous avons mis en place l’outil nommé « gestionnaire UCAmedia », qui regroupe l’ensemble des applications réalisées. Cinq onglets ont été développés. Le premier, « Gérer vos médias », permet à l’utilisateur de lister les médias de chaque bibliothèque dont il a les droits. Les paramètres par défaut accessibles sont la lecture de la vidéo , la visualisation des statistiques , l’obtention de codes d’intégration et le téléchargement des sources. Si les droits de la bibliothèque le permettent, l’utilisateur peut alors effectuer des modifications sur les vidéos avec l’éditeur intégré à Opencast , éditer les métadonnées et les supprimer . Un outil de chapitrage a été développé en PHP/Javascript et intégré à la demande des équipes pédagogiques. Une interface d’organisation de médias par dossier appelée « bibliothèque » a été mise en œuvre, permettant aux utilisateurs d’organiser leurs vidéos comme ils le souhaitent. Dans cette partie, il est notamment possible de créer , modifier et supprimer ses bibliothèques. Le deuxième onglet de ce gestionnaire est un formulaire de téléversement. Il permet à un utilisateur d‘envoyer jusqu’à deux flux simultanément à Opencast afin de créer une vidéo comprenant une ou deux sources (cf. figure 2). Une fois traité, le média pourra être retrouvé dans la partie « Gérer vos médias ». Le troisième onglet, « Enregistrer », est une intégration de l’outil d’enregistrement UCAStudio (cf. partie 4.1) permettant aux utilisateurs de démarrer un enregistrement depuis n’importe quelle plateforme (Moodle ou ENT). Le quatrième onglet, « Partager sa bibliothèque », intègre la fonctionnalité de partager sa ou ses bibliothèques en lecture14 et en écriture15 aux personnels de l’université en réécrivant les contrôles d’accès d’Opencast. Enfin, le dernier onglet liste les anciens médias produits depuis la solution Inwicast et permet de les migrer vers Opencast. Il offre également la possibilité à l’utilisateur de demander le remplacement automatique de son activité sur la plateforme pédagogique. Cela se traduit par le masquage de l’ancienne activité et la création d’une nouvelle. Cette fonctionnalité est disponible depuis septembre 2021 et permettra en septembre 2022 d’arrêter l’ancien service Inwicast. 13 Moteur d’indexations des données. 14 Possibilité de lire et partager. 15 Possibilité de lire, partager, modifier et supprimer. JRES 2021 – Marseille 10/17
6 Diffuser
6.1 Indexation des médias et publication WebTV
Figure 10: Module d'indexation
La demande formulée dans le cahier des charges par les agents de la Bibliothèque Universitaire était
de leur fournir un rôle d’indexation, de modération et d’archivage des médias à destination de la
WebTV. Pour réaliser cela, nous avons imaginé et développé un outil permettant de réunir
l’ensemble de ces fonctionnalités que nous avons appelé « module d’indexation des médias ».
Figure 11: Schéma d'une demande de publication sur la
WebTV
JRES 2021 – Marseille 11/17Une autre demande de nos collègues bibliothécaires était de supporter la norme d’indexation
LOMFR16, basée sur le protocole OAI-PMH 17. En effet, l’objectif était de pouvoir fournir à un
service externe la possibilité de « moissonner » les métadonnées des publications de la WebTV à
des fins d’archivages. Il était donc impératif de prendre en compte cet aspect au moment du
développement de l’outil afin d’harmoniser les champs d’indexations avec les champs obligatoires
de LOMFR.
Cet outil sert d’intermédiaire entre les utilisateurs et la WebTV. Ses fonctionnalités ont été
agrémentées au fur et à mesure du projet, lui permettant d’être un réel outil d’administration de la
WebTV. Il permet de modifier le menu du site – le carrousel – dynamiquement et d’ajouter des
collections de vidéos.
D’autre part, lors d’une demande de publication, un ticket est créé permettant d’instancier un
dialogue entre modérateurs et utilisateurs. Lorsque nos collègues bibliothécaires ont des doutes sur
la thématique ou les métadonnées à renseigner, ils peuvent échanger avec l’utilisateur depuis
l’interface de gestion de ticket JIRA18 dédiée. Ce ticket est automatiquement commenté lorsque le
média est refusé, publié ou archivé, informant ainsi l’utilisateur de l’état de sa demande.
En plus d’administrer et de modérer la WebTV, à la demande du service des affaires juridiques,
l’outil devait permettre de s’assurer que chaque média publié ait toutes les autorisations nécessaires.
Au moment de la demande de publication, tous les intervenants sont sollicités afin de signer
numériquement un document de cession de droit à l’image et de droit d’auteur. La modération se
réserve alors le droit de refuser la publication d’une vidéo si l'ensemble des documents ne sont pas
signés.
Figure 12: Page d'accueil de la WebTV
16 Learning Object Metadata.
17 Open Archives Initiative - Protocol for Metadata Harvesting.
18 Centre d’assistance / de service.
JRES 2021 – Marseille 12/176.2 Diffusion en direct
Afin d’assurer la retransmission des flux en direct vers la WebTV de l’Université, nous avons
décidé d’utiliser le logiciel open source SRS19 qui permet de redistribuer les flux RTMP20 provenant
des agents de capture (SMP351) par l’intermédiaire du protocole HLS21.
Le choix de ce protocole de streaming a été motivé par le fait qu’il se base sur le protocole HTTP et
permet ainsi d’être compatible avec la plupart des appareils. Il donne la possibilité au client de
s’adapter de façon transparente aux conditions changeantes du réseau en augmentant ou en
diminuant la qualité du flux.
Afin de mettre en place l’adaptation des flux à la bande passante de l’utilisateur, nous avons utilisé
un système de « hook http » fourni par SRS, permettant de créer dynamiquement des « Master
playlist22 » pour le lecteur intégré à la WebTV. En effet, HLS prend en charge une liste de lecture
principale qui définit plusieurs listes de lecture et en sélectionne une automatiquement en fonction
de la bande passante.
6.3 Devoir Moodle
À la demande des enseignants, un autre plugin a été réalisé pour la plateforme pédagogique,
permettant de rendre un devoir au format vidéo ou audio.
Au moment de paramétrer l’activité « devoir », l’enseignant doit choisir l’option « Remise de
médias UCAmedia » et sélectionner la bibliothèque de dépôt. Les médias des étudiants seront alors
dupliqués dans cette bibliothèque lors du rendu. L’enseignant pourra donc visualiser les vidéos dans
l’activité « devoir » ainsi que dans son gestionnaire de vidéos.
Figure 13: Remise de devoir
19 Simple real time server.
20 Real-Time Messaging Protocol.
21 HTTP Live Streaming.
22 Liste de lecture principale.
JRES 2021 – Marseille 13/177 Problèmes rencontrés et solutions
7.1 Durée d’encodage : du CPU au GPU
Sur Opencast, chaque média encodé est par défaut traité par le CPU 23 avec le logiciel FFMPEG. La
commande exécutée effectue trois encodages en parallèle sur le média afin d’obtenir trois fichiers
de résolutions différentes (480p, 720p et 1080p). Ce traitement est particulièrement long pour les
vidéos faisant plus d’une quinzaine de minutes, surtout si la vidéo contient plusieurs sources. Afin
de pallier ce problème et d’améliorer drastiquement ce temps d’encodage, nous avons substitué
l’encodage CPU par de l’encodage GPU24.
Afin d’effectuer ce traitement, nous avons cherché à acquérir une carte graphique permettant ce
type d’encodage. Après avoir échangé avec l’équipe système, nous avons décidé de choisir la
Nvidia tesla T4. Son avantage est de permettre de supporter parallèlement le même nombre
d’encodages simultanés que le processeur pour une qualité similaire ou supérieure. Une fois les
commandes FFMPEG mises en place sur Opencast, les processus de traitement des vidéos sont
deux à trois fois plus rapides pour les médias longs.
Figure 14: Comparaison des temps d'encodage entre le processeur et la carte graphique en trois
résolutions (480p, 720p et 1080p)
7.2 Requêtage API et ElasticSearch
Le gestionnaire de médias a d'abord été implémenté en utilisant l'API externe fournie par Opencast,
afin de récupérer les bibliothèques et médias des utilisateurs.
Cependant, après deux années d’exploitation et un nombre conséquent de données stockées, nous
avons constaté que le chargement de ces données était de plus en plus long, ce qui dégradait
l’expérience utilisateur. Après avoir analysé le fonctionnement de l’API d'Opencast et identifié
qu’elle utilisait son propre nœud interne ElasticSearch pour récupérer les données, nous avons
décidé de communiquer directement avec ce dernier. Cela nous a permis de réduire
considérablement les temps de chargement en passant d’une dizaine de secondes à quelques 800
millisecondes pour les utilisateurs propriétaires de nombreuses bibliothèques.
23 Processeur.
24 Processeur graphique.
JRES 2021 – Marseille 14/177.3 Fichiers audios
Une fonctionnalité complexe à gérer avec Opencast a été le traitement des fichiers audios. Bien que
cette tâche soit plutôt bien supportée dans la dernière version de la solution, le support de ces
fichiers n'était pas optimisé lors de son déploiement en version 6.
La solution apportée pour contourner le problème a été de générer une image sur chaque fichier
audio, et d’ajouter un « waveform » avec une commande FFMPEG pour convertir le fichier audio
initial en fichier vidéo au format mp4.
Aujourd'hui, malgré l'amélioration du support des fichiers audios sur Opencast, nous avons décidé
de conserver notre système, notamment pour des raisons esthétiques.
Figure 15: Exemple lecture fichier audio
8 Et après
UCAmedia a été mis en production en fin d’année 2019. Durant les années exceptionnelles de 2020
et 2021, l’utilisation des contenus vidéos a grandement augmenté chez les enseignants, ce qui eut
pour conséquence de mettre notre solution à rude épreuve. Opencast a été dimensionné de manière à
supporter une telle charge et compte maintenant plus de 10 000 vidéos téléversées sur la plateforme.
Avec 36 000 étudiants et 3 300 personnels, pas moins de 2 500 bibliothèques ont été créées et 1 250
000 vues comptabilisées au total sur les différentes vidéos.
Figure 16: Chiffres d'audiences
JRES 2021 – Marseille 15/17Des formations mensuelles sont animées par le pôle d'ingénierie pédagogique et de production audiovisuelle. Ils forment une dizaine de personnels à l'utilisation des outils qui composent la suite logiciel UCAmedia. Ses ingénieur·e·s nous soumettent également des pistes d'amélioration de l’outil, à la fois grâce à leur propre expérience et à celles remontées par les enseignants. En termes de coûts, l’université a mobilisé deux personnels à hauteur de 50% de leurs temps de travail pendant deux ans, pour le développement et la mise en place de la solution. Le projet est dès à présent dans une phase de maintenance corrective et évolutive permettant de libérer partiellement ces ressources humaines pour d’autres projets. UCAmedia reposant sur des solutions open-source, aucune licence ou logiciel n’engendre de coûts supplémentaires. Pour les perspectives d’évolutions de la plateforme, il est prévu d’équiper de plus en plus de salles et d’amphithéâtres avec des encodeurs Extron afin d’offrir un choix plus large aux enseignants (quatre amphithéâtres sont actuellement équipés et deux autres le seront en 2022). Nous envisageons également d’améliorer les statistiques disponibles pour les vidéos afin qu’il soit notamment possible de visualiser le nombre de vues pour une date donnée. JRES 2021 – Marseille 16/17
Bibliographie
[1] L. Auxepaules, S. Michel, M. Bouchlaghem, T. Naudin, G. Scalbert, C. Cousquer, Y.
Roualdes.10 ans après : une nouvelle plateforme de captation et diffusion en direct et en différé
de vidéos de cours. Actes du congrès JRES 2017, Nantes, Novembre 2017. https://conf-
ng.jres.org/2017/document_revision_2842.html.
Webographie
Opencast, https://opencast.org/
Extron SMP351, http://www.extron.com/product/product.aspx?id=smp351
Paella player, http://paellaplayer.upv.es
Duncan Smith Github, https://github.com/slampunk/ghettostudio
OSSRS Github, https://github.com/ossrs/srs
UCAStudio Github, https://github.com/UCA-Squad/ucastudio
OvenPlayer, https://github.com/AirenSoft/OvenPlayer
JRES 2021 – Marseille 17/17Vous pouvez aussi lire
