Il me semble que l'architecture est au final assez proche de Jitsi
Oui, et aussi de Janus et de Ion-SFU, que je cite sur galene.org. Ce sont tous des SFU, et ils sont tous bien faits.
Il n'était pas possible d'améliorer [Jitsi] ?
Jitsi est écrit en Java, ce qui complique un peu sont déploiement (il faut installer un JRE sur le serveur), et augmente sensiblement la consommation de mémoire. Par contre, j'avais sérieusement considéré la possibilité de baser Galène sur Janus, qui est économe, propre, et écrit en C; j'ai finalement décidé de faire mon propre serveur, j'ai peut-être eu tort. Quant à Ion-SFU, il n'était pas encore prêt à l'époque.
il y a du code commun entre les deux projets ?
Nous collaborons régulièrement avec les auteurs de Ion-SFU, qui, comme Galène, est basé sur Pion WebRTC. Lorsqu'il y a du code qui peut être utile aux deux projets, nous essayons de le contribuer à Pion: c'est mieux que de faire du copier-coller, et ça profite à tous les projets basés sur Pion.
Dans le cas de conf, le préchargement des PDF dans BBB est pas mal.
[…]
Il faudrait passer d'un mode SFU en MCU selon le nombre de personne ;-)
[…]
pouvoir diffuser simplement vers du webcast youtube ou autre
Il faut faire attention à ne pas ajouter trop de fonctionnalités : le but de Galène est d'être un logiciel simple, efficace et robuste et dont les fonctionnalités sont strictement limitées.
Des irresponsables sans éthique sont-ils les contributeurs avec qui tu souhaites collaborer pour ton projet ?
L'interface de Galène doit fonctionner sur tous les navigateurs: il est important qu'un étudiant qui a un problème d'ordinateur puisse suivre mon cours sur son smartphone. Comme je ne possède de smartphone moi-même, je dois compter sur la bonne volonté des utilisateurs pour me rapporter les problèmes avec Safari pour iOS — et cela alors même que, comme toi, j'ai des doutes sur les aspects éthiques de l'utilisation des systèmes d'Apple.
D'après /proc/cpuinfo, c'est un Haswell à 2.4Ghz, mais c'est une machine virtuelle, et je ne sais pas dans quelle mesure ça réflète le matériel sous-jacent.
Un SFU pousse les paquets sans les interpréter: toute l'intelligence est dans le client. Un MCU décode la vidéo qu'il reçoit, et la recode avant de l'envoyer au client.
Il y a un seul serveur (qu'il faut payer) et de nombreux clients (qui ont déjà été payés). C'est donc a priori une bonne idée que de distribuer les opérations coûteuses en CPU (le codage de la vidéo) sur les clients et d'économiser le CPU du serveur — avantage au SFU. Par contre, si on recode la vidéo, on peut faire plein de choses malines, par exemple combiner plusieurs vidéos en une seule mosaïque à basse résolution, convertir l'audio en un format compatible avec SIP — avantage au MCU.
Il me semble — mais je suis sans doute biaisé — que le modèle SFU est préférable lorsqu'on a assez de CPU et de débit côté client. Comme tu le fais remarquer, si le CPU est généralement disponible, ce n'est pas nécessairement le cas du débit. Galène contourne le problème en permettant au client de choisir quels flots il décide recevoir, par exemple uniquement l'audio, ou uniquement l'audio et la présentation.
En pratique, nous avons deux serveurs: un serveur à un seul cœur (galene.org), utilisé pour l'enseignement, pour les réunions d'une association, et pour les apéritifs confinés, et un serveur à quatre cœurs, payé par le CNRS, et réservé aux activités de recherche. Le petit serveur commence à s'essouffler autour de 400 flots, mais Galène ne se plante pas: les vidéos commencent à freezer, puis reprennent lorsque les gens éteignent leurs caméras. Le gros serveur sert pour les réunions du laboratoire et pour les exposés scientifiques; il a aussi servi lors d'une conférence internationale (SOCS'2020). On ne l'a pas encore chargé suffisamment pour savoir comment il se comporte en situation de crise.
Je suppose que c'est scénario d'usage du type 1 personne diffusant vers 70 autres,
Oui.
qu'il y ait 20 personnes […] dans une seule salle ou dans 10, c'est la même charge côté serveur ?
Pas du tout.
Avec 20 personnes dans un groupe, le serveur reçoit 20 flots, qu'il reémet chacun à 19 personnes. On a donc un total de 20+20*19 = 400 flots.
Avec 10 groupes de deux personnes chacun, le serveur reçoit 20 flots qu'il reémet à une seule personne chacun, pour un total de 20+20=40 flots.
Galène est capable, selon mes tests, de pousser de l'ordre de 400 flots par cœur. Sur un serveur à 4 cœurs, on devrait être capables de pousser 1600 flots, soit une réunion à 40 ou un amphi de 1600 personnes.
Je suis d'accord avec toi : c'est un compromis, voire une compromission.
Dans une vie antérieure, j'ai essayé d'éviter GitHub. Le résultat, c'est que les gens ne contribuaient pas: ils ne me soumettaient pas de rapports de bugs (flemme de s'authentifier sur un autre site), ils se plaignaient qu'il fallait apprendre de nouvelles manières de soumettre un patch, ou, carrément, ils trollaient les forums en disant que le code n'est pas libre puisqu'il n'est pas sur GitHub.
J'ai donc adopté un compromis: le code et le bug tracker sont sur GitHub, mais la liste de diffusion et la page web restent indépendantes. Comme tout compromis, il se fait critiquer des deux côtés : il y a des gens comme toi qui me critiquent pour mon utilisation de GitHub, et des gens qui se plaignent que je maintienne une page web au lieu d'utiliser un WiKi GitHub (regarde les archives de la liste de diffusion de Galène du 23 décembre).
Le protocole WebRTC (utilisé pour communiquer avec les navigateurs) chiffre et authentifie obligatoirement le traffic. On n'a donc pas le choix, il faut tout chiffrer.
Par curiosité — pourquoi as-tu besoin de communication en clair ? Est-ce pour des raisons légales ?
Est-ce que Galène est prévu pour fonctionner derrière un reverse proxy ou un load-balancer ?
Galène utilise trois protocoles :
HTTPS pour le serveur web intégré ;
WSS (WebSocket au dessus de TLS) pour le chat et la signalisation ;
SRTP pour le traffic audio et vidéo.
Pour le traffic HTTPS et WSS, tu fais comme d'habitude. Pour le traffic SRTP, il te faudra un serveur TURN, qui est essentiellement un proxy UDP. Le README inclus avec Galène donne quelques indications sur la mise en place.
Galène va essayer d'établier un flot SRTP direct avant de se rabattre sur TURN après quelques centaines de millisecondes. Je vais ajouter une option qui indique que seul TURN doit être utilisé.
Le site mentionne que Galène a fonctionné avec succès sur de l'ARM64. Quelles sont les cartes ARM64 qui ont été utilisées pour le faire fonctionner ?
BigBlueButton (BBB) a énormément de fonctionnalités avancées : passerelle SIP, interprétation des PDF, des document LibreOffice et Microsoft Office, annotation et tableau blanc partagé, etc. Chacune de ces fonctionnalités est implémentée par un binaire différent, et tous ces composants communiquent à travers un bus Redis:
Galène a une architecture différente. Le serveur implémente le strict minimum de fonctionnalités : il se limite essentiellement à garantir la sécurité des échanges, à décider quelle donnée est destinée à quel client, et à pousser des flux RTP aussi efficacement que possible. Comme le serveur est de taille modeste, il est implémenté comme un seul binaire monolithique (multi-threadé), ce qui permet d'utiliser des structures de données partagées et donc de limiter la copie des données.
Clairement, Galène n'est pas un concurrent de BBB: Galène ne sera jamais capable de supporter la plupart des fonctionnalités de ce dernier. Par exemple, Galène ne pourra jamais interpréter un document Microsoft Office: il n'est tout simplement pas raisonnable d'intégrer un interpréteur du format OOXML dans l'architecture de Galène. De même, Galène n'intégrera jamais une passerelle SIP: comme Galène n'interprète (presque) pas les flux qui la traversent, elle ne peut pas convertir le traffic WebRTC en un traffic compatible avec SIP.
Je recommande que les gens qui ont besoin de fonctionnalités avancées continuent à utiliser BBB — c'est un excellent logiciel, qui domine tous les autres en nombre de fonctionnalités. Le but de Galène est d'être un logiciel simple, robuste et efficace aux fonctionnalités strictement limitées.
et 46Mo de mémoire:
galene@galene:~$ ps l 24280
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 1001 24280 1 20 0 714792 46520 - Ssl ? 111:15 /home/galene/galene -redirect galene.org:8443
En ce qui concerne le CPU, il s'agit d'un serveur avec un seul cœur (le VPS OVH bas de gamme), et nous nous en servons régulièrement pour faire des cours avec 70 étudiants présents.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 2.
N'hésite pas à envoyer une annonce à galene@lists.galene.org.
[^] # Re: Jitsi
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 8.
Oui, et aussi de Janus et de Ion-SFU, que je cite sur galene.org. Ce sont tous des SFU, et ils sont tous bien faits.
Jitsi est écrit en Java, ce qui complique un peu sont déploiement (il faut installer un JRE sur le serveur), et augmente sensiblement la consommation de mémoire. Par contre, j'avais sérieusement considéré la possibilité de baser Galène sur Janus, qui est économe, propre, et écrit en C; j'ai finalement décidé de faire mon propre serveur, j'ai peut-être eu tort. Quant à Ion-SFU, il n'était pas encore prêt à l'époque.
Nous collaborons régulièrement avec les auteurs de Ion-SFU, qui, comme Galène, est basé sur Pion WebRTC. Lorsqu'il y a du code qui peut être utile aux deux projets, nous essayons de le contribuer à Pion: c'est mieux que de faire du copier-coller, et ça profite à tous les projets basés sur Pion.
Il faut faire attention à ne pas ajouter trop de fonctionnalités : le but de Galène est d'être un logiciel simple, efficace et robuste et dont les fonctionnalités sont strictement limitées.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 4.
Sur un Raspberry Pi 4 — probablement, l'Ethernet est connecté en RGMII, et la librairie standard de Go implémente AES en assembleur NEON.
Sur un Raspberry Pi 1 — probablement pas, l'Ethernet est connecté en USB, le coût des entrées-sorties risque d'être prohibitif.
Si tu décides d'essayer, je serai reconnaissant si tu postes tes conclusions sur la liste de diffusion de Galène.
[^] # Re: Pourquoi le choix GAFAM ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 7.
L'interface de Galène doit fonctionner sur tous les navigateurs: il est important qu'un étudiant qui a un problème d'ordinateur puisse suivre mon cours sur son smartphone. Comme je ne possède de smartphone moi-même, je dois compter sur la bonne volonté des utilisateurs pour me rapporter les problèmes avec Safari pour iOS — et cela alors même que, comme toi, j'ai des doutes sur les aspects éthiques de l'utilisation des systèmes d'Apple.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 2.
Le VPS bas de gamme "Value" d'OVH: https://www.ovhcloud.com/fr/vps/compare/
D'après /proc/cpuinfo, c'est un Haswell à 2.4Ghz, mais c'est une machine virtuelle, et je ne sais pas dans quelle mesure ça réflète le matériel sous-jacent.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 10.
Un SFU pousse les paquets sans les interpréter: toute l'intelligence est dans le client. Un MCU décode la vidéo qu'il reçoit, et la recode avant de l'envoyer au client.
Il y a un seul serveur (qu'il faut payer) et de nombreux clients (qui ont déjà été payés). C'est donc a priori une bonne idée que de distribuer les opérations coûteuses en CPU (le codage de la vidéo) sur les clients et d'économiser le CPU du serveur — avantage au SFU. Par contre, si on recode la vidéo, on peut faire plein de choses malines, par exemple combiner plusieurs vidéos en une seule mosaïque à basse résolution, convertir l'audio en un format compatible avec SIP — avantage au MCU.
Il me semble — mais je suis sans doute biaisé — que le modèle SFU est préférable lorsqu'on a assez de CPU et de débit côté client. Comme tu le fais remarquer, si le CPU est généralement disponible, ce n'est pas nécessairement le cas du débit. Galène contourne le problème en permettant au client de choisir quels flots il décide recevoir, par exemple uniquement l'audio, ou uniquement l'audio et la présentation.
En pratique, nous avons deux serveurs: un serveur à un seul cœur (galene.org), utilisé pour l'enseignement, pour les réunions d'une association, et pour les apéritifs confinés, et un serveur à quatre cœurs, payé par le CNRS, et réservé aux activités de recherche. Le petit serveur commence à s'essouffler autour de 400 flots, mais Galène ne se plante pas: les vidéos commencent à freezer, puis reprennent lorsque les gens éteignent leurs caméras. Le gros serveur sert pour les réunions du laboratoire et pour les exposés scientifiques; il a aussi servi lors d'une conférence internationale (SOCS'2020). On ne l'a pas encore chargé suffisamment pour savoir comment il se comporte en situation de crise.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 9.
Oui.
Pas du tout.
Avec 20 personnes dans un groupe, le serveur reçoit 20 flots, qu'il reémet chacun à 19 personnes. On a donc un total de 20+20*19 = 400 flots.
Avec 10 groupes de deux personnes chacun, le serveur reçoit 20 flots qu'il reémet à une seule personne chacun, pour un total de 20+20=40 flots.
Galène est capable, selon mes tests, de pousser de l'ordre de 400 flots par cœur. Sur un serveur à 4 cœurs, on devrait être capables de pousser 1600 flots, soit une réunion à 40 ou un amphi de 1600 personnes.
[^] # Re: Reverse proxy et matériel ARM64
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 4.
Apparemment pas : https://www.raspberrypi.org/forums/viewtopic.php?t=243410
[^] # Re: Pourquoi le choix GAFAM ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 10.
Je suis d'accord avec toi : c'est un compromis, voire une compromission.
Dans une vie antérieure, j'ai essayé d'éviter GitHub. Le résultat, c'est que les gens ne contribuaient pas: ils ne me soumettaient pas de rapports de bugs (flemme de s'authentifier sur un autre site), ils se plaignaient qu'il fallait apprendre de nouvelles manières de soumettre un patch, ou, carrément, ils trollaient les forums en disant que le code n'est pas libre puisqu'il n'est pas sur GitHub.
J'ai donc adopté un compromis: le code et le bug tracker sont sur GitHub, mais la liste de diffusion et la page web restent indépendantes. Comme tout compromis, il se fait critiquer des deux côtés : il y a des gens comme toi qui me critiquent pour mon utilisation de GitHub, et des gens qui se plaignent que je maintienne une page web au lieu d'utiliser un WiKi GitHub (regarde les archives de la liste de diffusion de Galène du 23 décembre).
[^] # Re: Reverse proxy et matériel ARM64
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 4.
Le protocole WebRTC (utilisé pour communiquer avec les navigateurs) chiffre et authentifie obligatoirement le traffic. On n'a donc pas le choix, il faut tout chiffrer.
Par curiosité — pourquoi as-tu besoin de communication en clair ? Est-ce pour des raisons légales ?
[^] # Re: Reverse proxy et matériel ARM64
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 10. Dernière modification le 23 décembre 2020 à 13:19.
Galène utilise trois protocoles :
Pour le traffic HTTPS et WSS, tu fais comme d'habitude. Pour le traffic SRTP, il te faudra un serveur TURN, qui est essentiellement un proxy UDP. Le README inclus avec Galène donne quelques indications sur la mise en place.
Galène va essayer d'établier un flot SRTP direct avant de se rabattre sur TURN après quelques centaines de millisecondes. Je vais ajouter une option qui indique que seul TURN doit être utilisé.
J'utilise des Olinuxino-A64 d'Olimex; la caractéristique importante pour Galène, c'est la crypto matérielle. J'ai décrit mes expériences ici : https://www.irif.fr/~jch/software/olimex-a64.html
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 10.
C'est un SFU.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 10.
BigBlueButton (BBB) a énormément de fonctionnalités avancées : passerelle SIP, interprétation des PDF, des document LibreOffice et Microsoft Office, annotation et tableau blanc partagé, etc. Chacune de ces fonctionnalités est implémentée par un binaire différent, et tous ces composants communiquent à travers un bus Redis:
https://docs.bigbluebutton.org/2.2/architecture.html#high-level-architecture
Galène a une architecture différente. Le serveur implémente le strict minimum de fonctionnalités : il se limite essentiellement à garantir la sécurité des échanges, à décider quelle donnée est destinée à quel client, et à pousser des flux RTP aussi efficacement que possible. Comme le serveur est de taille modeste, il est implémenté comme un seul binaire monolithique (multi-threadé), ce qui permet d'utiliser des structures de données partagées et donc de limiter la copie des données.
Clairement, Galène n'est pas un concurrent de BBB: Galène ne sera jamais capable de supporter la plupart des fonctionnalités de ce dernier. Par exemple, Galène ne pourra jamais interpréter un document Microsoft Office: il n'est tout simplement pas raisonnable d'intégrer un interpréteur du format OOXML dans l'architecture de Galène. De même, Galène n'intégrera jamais une passerelle SIP: comme Galène n'interprète (presque) pas les flux qui la traversent, elle ne peut pas convertir le traffic WebRTC en un traffic compatible avec SIP.
Je recommande que les gens qui ont besoin de fonctionnalités avancées continuent à utiliser BBB — c'est un excellent logiciel, qui domine tous les autres en nombre de fonctionnalités. Le but de Galène est d'être un logiciel simple, robuste et efficace aux fonctionnalités strictement limitées.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 10. Dernière modification le 22 décembre 2020 à 21:14.
D'après https://docs.bigbluebutton.org/install#minimum-server-requirements, BBB recquiert:
L'instance de Galène tournant sur galene.org occuppe 10Mo d'espace disque:
galene@galene:~$ echo $(( $(du -s . | cut -f1) - $(du -s ./recordings | cut -f1) ))
10396
et 46Mo de mémoire:
galene@galene:~$ ps l 24280
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 1001 24280 1 20 0 714792 46520 - Ssl ? 111:15 /home/galene/galene -redirect galene.org:8443
En ce qui concerne le CPU, il s'agit d'un serveur avec un seul cœur (le VPS OVH bas de gamme), et nous nous en servons régulièrement pour faire des cours avec 70 étudiants présents.