jch a écrit 18 commentaires

  • [^] # Re: Vive IPv6

    Posté par  . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 3.

    Il n'y a pas de multicast en ipv6?

    Le support pour le multicast est obligatoire dans les hôtes, mais le routage du multicast est optionnel. En pratique, le multicast ne fonctionne donc que localement au lien: il est utile pour localiser les imprimantes localement connectées (Bonjour/Zeroconf/mDNS), mais pas pour communiquer sur l'Internet.

    (Le multicast est aussi déployé dans les réseaux des FAI pour la télévision sur IP, mais l'infra n'est pas directement par l'utilisateur pour autre chose que recevoir les flux de télévision.)

  • [^] # Re: Vive IPv6

    Posté par  . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 3.

    Ton idée est sérieusement d'avoir pour un salon de 100 personnes un envoi de 100 flux par chaque machine? Tu te rends comptes de ce que ça représente comme bande passante

    Ça fait dans les 50Mbit/s (pour de la basse résolution), donc c'est pas complètement absurde de nos jours. Bien-sûr, il faudrait éviter de recoder la vidéo 100 fois, et l'implémentation de WebRTC dans les navigateurs actuels ne permet pas ça.

  • [^] # Re: alternatives qui utilisent jitsi

    Posté par  . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 5.

    Galène c'est sur https://galene.org/ et ça marche bien. En cliquant sur Try it out on peut comme pour Jitsi créer une conférence visio

    Et si vous faites un mail amical à l'auteur (moi) en expliquant que c'est pour une bonne cause, il vous fera sûrement un groupe public dont vous êtes l'administrateur.

    (Mais l'idéal c'est bien-sûr de s'autohéberger. Comme-ça, vous ne dépendez de la bonne volonté de personne.)

  • [^] # Re: Et sinon Galène

    Posté par  . En réponse au lien Quel logiciel de visioconférence utiliser ?. Évalué à 4. Dernière modification le 26 janvier 2022 à 15:51.

    Ils ont fait une interface pour la gestion des salons?

    Non, il n'y en a pas pour le moment.

    La solution que la plupart des utilisateurs emploient, c'est d'activer la création automatique des groupes dans le serveur : vous faites un groupe, par exemple "/public", avec l'option "allow-subgroups" activée. Lorsqu'un utilisateur se connecte à un groupe "/public/quelquechose", le groupe est créé dynamiquement et reste actif pendant quatre heures.

    Pour ce qui est d'une interface de gestion, comme le serveur remarque automatiquement la création d'un nouveau groupe, il suffit d'écrire une interface dans le framework de votre choix qui écrit des fichiers JSON sur disque. Ça devrait prendre une heure pour un programmeur web compétent.

    Enfin, la version 0.5 de Galène sera capable de déléguer la gestion des groupes à un serveur tiers. Le code est dans la branche "auth" du dépôt de Galène, et vous trouverez un exemple de serveur d'authentification ici : https://galene.org/galene-auth-server.py

  • [^] # Re: Moins gourmand que BigBlueButton ?

    Posté par  . 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  . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 8.

    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.

  • [^] # Re: Moins gourmand que BigBlueButton ?

    Posté par  . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 4.

    est-ce que ça pourrait fonctionner en mode logiciel, avec des performances correctes ?

    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  . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 7.

    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.

  • [^] # Re: Moins gourmand que BigBlueButton ?

    Posté par  . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 2.

    les tests ont été fait avec quel matériel ?

    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  . 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  . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 9.

    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.

  • [^] # Re: Reverse proxy et matériel ARM64

    Posté par  . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 4.

  • [^] # Re: Pourquoi le choix GAFAM ?

    Posté par  . 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  . 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  . 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.

    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 ?

    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  . 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  . 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  . 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:

    • 4 GB of memory with swap enabled (8 GB of memory is better)
    • 4 CPU cores (8 is better or more)

    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.