Flux entrants (vu du serveur, donc émis par les caméras) : environ 2 MB/s et il y avait 5 caméras allumées. C'est ok pour les chanceux (par ex. j'ai 20 Mbps d'upload et iptraf-ng a mesuré que ma session webrtc uploadait à 3 Mbps comme prévu par le design : https://github.com/jitsi/jitsi-meet/issues/1313). Par contre pour les participants avec < 1 Mbps d'upload c'était la peine capitale avec un envoi de 2 images/sec de qualité abyssale (tous les récepteurs ont confirmé).
Flux sortants (vu du serveur) : jusqu'à 7 MB/s, WTF! Oui, environ 60 Mbps ! Pour 5 flux 'miniaturisés' vers 10 participants !
Après il y a peut être une nette différence entre le client natif et le WebRTC mais l'article ne semble pas préciser ce qui a été utilisé pour tester. Dans mon cas le client WebRTC a des performances très médiocres (ne s'adapte pas à la BP, ne respecte pas le réglage LowDef, expérience utilisateur niveau "inutilisable").
Avec les mêmes utilisateurs et dans les mêmes conditions on a testé https://openvidu.io/demos avec succès : 10 participants, 7 flux vidéo et tout le monde se voyait avec une qualité satisfaisante (résolution et fluidité). C'était le jour et la nuit. Très bon backend donc, mais il n'y a pas de client abouti...
Je pense que technologiquement Jitsi est trop simpliste et ne marche que dans des conditions optimales. Donc rarement.
# Ca ne marche pas pour moi...
Posté par zerodeux (site web personnel) . En réponse à la dépêche Organiser des visioconférences de haute qualité (avec le logiciel libre Jitsi Meet). Évalué à 3.
Je n'ai pas du tout ce retour d'expérience.
J'ai installé un serveur tout neuf avec le dernier Jitsi, on a testé jusqu'à 10 participants (via WebRTC) sur une B2-7 OVH : http://zerodeux.net/misc/meet-ovh-test-1.png
Jusqu'à 1 CPU (10 flux) : OK. Mais bien en deça de ce qui est prétendu : https://jitsi.org/jitsi-videobridge-performance-evaluation/ (1000 flux utilisant 20% de 4x4 cores ~= 300 flux/core).
Flux entrants (vu du serveur, donc émis par les caméras) : environ 2 MB/s et il y avait 5 caméras allumées. C'est ok pour les chanceux (par ex. j'ai 20 Mbps d'upload et iptraf-ng a mesuré que ma session webrtc uploadait à 3 Mbps comme prévu par le design : https://github.com/jitsi/jitsi-meet/issues/1313). Par contre pour les participants avec < 1 Mbps d'upload c'était la peine capitale avec un envoi de 2 images/sec de qualité abyssale (tous les récepteurs ont confirmé).
Flux sortants (vu du serveur) : jusqu'à 7 MB/s, WTF! Oui, environ 60 Mbps ! Pour 5 flux 'miniaturisés' vers 10 participants !
Le problème de gestion de qualité/BP est connu mais upstream considère que c'est une feature, pas un bug : https://github.com/jitsi/jitsi-meet/issues/3120
Après il y a peut être une nette différence entre le client natif et le WebRTC mais l'article ne semble pas préciser ce qui a été utilisé pour tester. Dans mon cas le client WebRTC a des performances très médiocres (ne s'adapte pas à la BP, ne respecte pas le réglage LowDef, expérience utilisateur niveau "inutilisable").
Avec les mêmes utilisateurs et dans les mêmes conditions on a testé https://openvidu.io/demos avec succès : 10 participants, 7 flux vidéo et tout le monde se voyait avec une qualité satisfaisante (résolution et fluidité). C'était le jour et la nuit. Très bon backend donc, mais il n'y a pas de client abouti...
Je pense que technologiquement Jitsi est trop simpliste et ne marche que dans des conditions optimales. Donc rarement.