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é à 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.