Sozi est un logiciel permettant de créer et jouer des présentations animées.
Dans une situation d'enseignement à distance, par exemple, la solution souvent utilisée pour diffuser une présentation Sozi à un groupe d'étudiants consiste à partager son écran et à diffuser un flux vidéo, typiquement à travers une solution de visioconférence.
Dans un message publié sur le forum de Sozi, un utilisateur s'interroge sur la possibilité de diffuser une présentation sans passer par un flux vidéo.
Chaque participant téléchargerait la présentation de son côté, et pendant la séance, le déroulement de leur présentation serait piloté à distance par celle de l'orateur.
Ainsi, au lieu de diffuser un flux vidéo, il y aurait simplement un envoi de messages (avancer, reculer, etc) peu exigeants en termes de débit sur le réseau.
Dans mes recherches pour implémenter cette fonctionnalité, je me suis vite intéressé à WebRTC. Mon problème est la nécessité de mettre en place un "signaling server".
Je ne suis pas très enthousiaste à l'idée de fournir ce service moi-même, ni d'utiliser un service commercial existant sachant que :
- Je développe Sozi sur mon temps libre, et je n'ai pas vocation à gérer une plate-forme de services avec toutes les contraintes de maintenance et de sécurité qui vont avec.
- Je n'ai aucune idée du nombre de connexions que ce serveur devra gérer quotidiennement.
- Je ne suis pas sûr que les utilisateurs de Sozi accepteront de financer ce service.
Que feriez-vous à ma place ?
Savez-vous s'il existe d'autres technologies ou plates-formes qui pourraient faciliter le développement de cette fonctionnalité ?
# WebSockets
Posté par ted (site web personnel) . Évalué à 3.
C'est le genre de chose qui devrait être faisable avec des WebSockets:
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers
Mais effectivement ça représente un certain investissement en temps (développement, maintenance) si tu te lances là dedans, à toi de voir si ça vaut le coup.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: WebSockets
Posté par Guillaume Savaton (site web personnel) . Évalué à 1.
Merci pour ce retour.
En effet, les WebSockets pourraient servir de base à une solution mais ça me paraît être d'assez bas niveau.
Avec WebRTC, j'ai l'impression qu'il y a une API prête à l'emploi pour l'échange de messages à condition d'avoir établi une connexion. C'est là que le "signaling server" intervient. Certains serveurs reposent sur les WebSockets mais ce n'est pas obligatoire.
# Des idées, des questions
Posté par GuieA_7 (site web personnel) . Évalué à 2. Dernière modification le 13 septembre 2020 à 15:45.
Si je comprends bien il y aurait un orateur, et les participants peuvent uniquement l'entendre lors du déroulement de la séance, mais pas le voir ?
Du coup est-ce qu'une solution telle que suivant est acceptable :
Auquel cas la plateforme de broadcasting n'a pas besoin de beaucoup de ressources (le plus gros est fait par Jitsi), c'est typiquement quelque chose qui se ferait à coup de WebSocket (comme indiqué au dessus). Sozi est déjà fait en JS du coup le choix le plus évident serait peut-être NodeJS (mais c'est faisable avec n'importe quel langage). Ça me semble assez petit vu comme ça, mais bon c'est facile à dire quand ce n'est pas vous qui investissez votre temps libre, évidemment.
Le résultat intéressait peut-être Framasoft ; sinon est-ce que vos utilisateurs sont du genre à déployer leur instance ?
[^] # Re: Des idées, des questions
Posté par Guillaume Savaton (site web personnel) . Évalué à 2.
C'est comme ça que je vois les choses. D'autres utilisateurs pourraient souhaiter garder un canal vidéo pour une caméra mais pas pour la présentation elle-même.
Je pense que ce serait tout à fait acceptable pour les utilisateurs mais le principe d'une "plate-forme de broadcasting" est justement ce que je cherche à éviter.
Pour le moment, je ne m'intéresse pas tellement à la question du partage des fichiers Sozi. Dans un premier temps, il suffirait que l'orateur configure sa "console de présentation" (le fichier
-presenter.sozi.html
créé par Sozi) en fournissant, par exemple, un nom de serveur et un identifiant de salon. Les spectateurs pourraient alors ouvrir la présentation (le fichier.sozi.html
) en renseignant les mêmes informations.Ensuite, si la voix passe par Jitsi, par exemple, ce serait pratique que Jitsi fournisse également un canal de données pour les messages Sozi. Ou au minimum, que Jitsi serve de "signaling server" pour une connexion WebRTC spécifique à Sozi.
En effet, Framasoft et les CHATONS seraient des partenaires intéressants pour éviter d'avoir un serveur Sozi centralisé.
J'ai très peu d'informations sur les utilisateurs de Sozi mais a priori, je dirais que non.
Ceux qui utilisent Sozi dans l'enseignement supérieur pourraient peut-être faire installer un serveur par leur établissement, mais ce n'est pas toujours possible.
# BBB
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Avec BigBlueButton, tu peux téléverser un document sur le serveur. Je me demande s'il ne faudrait pas suivre la même approche que pour un document LibreOffice et donc s'intégrer sur cette plateforme qui doit avoir 99% des API déjà fonctionnelles pour cela.
[^] # Re: BBB
Posté par Guillaume Savaton (site web personnel) . Évalué à 1.
Merci pour ces informations.
Comme évoqué plus haut en prenant l'exemple de Jitsi, ce serait idéal si le partage et le pilotage des présentations Sozi se faisaient à travers le même service que le streaming audio.
Je vais me renseigner sur BigBlueButton.
[^] # Re: BBB
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Dans Jitsi, le flux data partagé remplace ta caméra. Pour moi, c'est un flux vidéo. Ce qui est bien, c'est que chacun peut partager son écran en même temps et chacun choisit les données qu'il souhaite voir.
Avec BBB, les données sont téléversés sur le serveur et le même flux est envoyé sur tous les clients. Je me demande (mais pas regardé le code) si le flux donnée n'est pas en partie préchargé en cache sur les clients ce qui fait que le flux temps réel est bien moins contraint. Seuls les codes suivants, précédents seraient transmis en temps réel… Mais bon, ce n'est qu'une hypothèse !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.