Par contre j’ai l’impression que tous les clients recevaient le flux vidéo depuis le serveur sur lequel était envoyé le live, même si ils le visionnaient en passant par l’autre serveur. Il n’y avait quasiment pas de trafic réseau sur le second serveur.
Est-ce qu’un mécanisme de redondance similaire à celui des vidéo normale est censé fonctionner à ce stade du développement de la fonctionnalité live ou bien est-ce pour plus tard?
Non, et aucun n’est prévu pour l’instant étant donné la difficulté de télécharger et informer le serveur des segments disponibles en mirroir sans doubler la latence.
Je pense qu’il y a plusieurs possibilités de redondance entre instances pour le live, mais je ne les ai pas encore vraiment étudié. Pour l’instant on essaye de faire un truc qui fonctionne, et il faudra voir où sont les réels bottleneck (des fois on est surpris :)).
Oui pas de soucis. C’est un sujet complexe qui mérite d’avancer étapes par étapes. Ma question était juste pour clarifier là ou vous en étiez et confirmer que ce n’était pas une mauvaise configuration de ma part.
Concernant les bottlenecks j’aurais plus d’info à vous donner en fin de journée suite au tests que j’ai réalisés depuis hier et à la répétition que nous allons faire cet après midi pour préparer l’événement du WE prochain que je compte essayer de streamer via peertube. Mais je ne sais pas si ce forum est le meilleur endroit pour postertous les détails des différentes conditions de test que j’ai essayé, de l’utilisation CPU et réseau ainsi que les aléas rencontrés. Est-ce que ça serait mieux que je poste dans des issues sur GitHub ou sur FramaGit ou bien je continue ici?
Ici ça me parait bien, et si besoin on créera des tickets sur github.
Merci pour les retours ! J’ai trop hâte que tout ça soit dispo en version stable !
Sur un des premiers essais que nous avons fais avec plusieurs utilisateurs qui regardaient le stream (environ une douzaine) tout se passait bien au début. Mais au bout d’un moment les utilisateurs on commencé à ressentir du lag. Et au même moment l’OBS utilisé pour générer le stream a commencé à avoir son compteur de dropped frames qui s’incrémentait.
Le problème ne semblait pas venir de l’utilisation mémoire, des disques ni de la bande passante réseau. Seule l’utilisation CPU sur le serveur semblait significative, sans toutefois saturer complètement les capacités du serveur.
Comme il y avait plusieurs paramètres changeant pendant le déroulement du test il n’était pas évident de comprendre ce qui s’était passé
Il semblait y avoir une tendance dans l’utilisation CPU qui augmentait pendant le déroulement du test.
Mais en première analyse l’hypothèse était que que ffmpeg utilisait trop de CPU pour le transcoding dans les phases où le flux vidéo était très dynamique où bien que nous avions atteint un nombre trop important d’utilisateur pour ce serveur a un moment donné du test.
Exemple d’utilisation CPU lors d’un de ces premier test :
Cependant des test supplémentaire réalisé dans le but de déterminer des valeurs optimales pour la résolution de streaming et les résolutions de transcoding ont montré que dans certaines configuration de streaming le niveau de CPU augmentait de manière linéaire au fur et a mesure de la durée de streaming alors que rien de changeait au niveau du nombre de client regardant le stream ou de la dynamique du flux vidéo.
Exemple, test d’une heure de streaming avec
Le début du palier dans l’utilisation CPU vers la fin correspond au moment ou OBS commençait à avoir des dropped frames.
La rampe d’utilisation mémoire un peu après correspond au moment ou OBS à perdu la connexion avec le serveur qui a alors fermé le stream et à commencé à publier le replay.
Test d’une heure de streaming avec :
On peut voir sur ce test qu’avec moins de résolutions de transcoding d’activées l’augmentation d’utilisation CPU a été plus lente.
On a donc essayé de faire un test sans transcoding du tout :
Mais il y avait toujours une augmentation de l’utilisation CPU dans le temps.
Première heure de streaming :
Ce n’est qu’en désactivant la publication du replay que l’utilisation CPU semble rester stable, même en avec du trascoding activé.
Exemple, Test de 13h30 avec
Les différents paliers d’utilisation CPU et réseau correspondent à des changements qui ont eu lieu dans la vidéo qui était streamée, pas à un comportement anormal du serveur peertube.
Durée totale du test :
Dernière heure du test :
Il semblerait que l’augmentation de CPU soit corrélée au nombre de fichiers générés dans /var/www/peertube/storage/streaming-playlists/hls/<hash-de-la-vidéo> (entre 2000 et 4000 fichiers vers la fin des tests ci dessus sauf le dernier ou seuls les quelques fichiers les plus récent sont conservés par le serveur)
Un petit glitch cosmétique au démarrage d’un live :
Un grand merci pour le super rapport. Vous utilisez quoi comme machine/OS ?
De rien c’est un plaisir de tester peertube.
Mon serveur de test (dev.tube.distrilab.org) tourne dans un conteneur LXC sous l’hyperviseur Proxmox VE 6.2 / Debian 10 (Buster). l’OS du conteneur est Debian 10 également.
Conteneur LXC :
Hote Physique : Serveur dédié chez Online/Scaleway modèle « Dedibox Pro-2-M-SATA »
Et le serveur de « prod » du canard réfractaire (fait en fait tourner deux instances peertube en ce moement, canard.tube en v2.4 et live.canard.tube en version dev ) est un VPS chez OVH modèle « Comfort »
Les graphes de CPU ci-dessus ça vient de l’interface ProxMox du serveur de test. Faut qu’on installe quelque chose pour avoir du monitoring sur l’autre serveur mais on a pas encore pris le temps de le faire.
Du coup je pense (espère ?) que ce patch devrait résoudre le soucis : https://github.com/Chocobozzz/PeerTube/commit/937581b8f61fe82fdac044e11740b9a4cb6d96b0
À tester à partir de demain 
On a refait un test, le patch est fonctionnel, 12b va te faire un retour plus tard.
Juste, j’ai constaté un bug cosmétique sans importance :
Après le stream, j’ai pu accéder au replay et le regarder sans le moindre problème, la vidéo se jouait normalement jusqu’à la fin mais la longueur totale de la vidéo indiquée était erronée.
Elle indiquait 1:06:00 quand la vidéo faisait au total, en réalité, 1:06:15.
Aussi, je ne pouvais pas aller plus loin que 1:06:00 quand je souhaitais cliquer sur un temps précis sur le curseur de la vidéo.
Regarde le temps « en cours » vs « total ». Et le curseur sur la deuxième image.
J’espère être clair dans mes explications, il est un peu tard.
Merci pour le fix éclair en tout cas. C’est propre ! À priori, on pourra streamer sans problème l’évènement du week-end prochain.
Oui donc après un test de live d’une heure avec ces paramètres
La CPU reste bien stable maintenant :
Pour valider ce que nous comptons faire le WE prochain on a aussi testé de relancer un autre live juste après l’arrêt du premier pour voir si tout se passait bien sur ce deuxième live pendant que le replay du premier était publié. Il n’y a pas eu de soucis, aucune dropped frame de signalée par OBS sur le deuxième live.
L’utilisation CPU du serveur environ une demi heure après le basculement du premier au deuxième live :
Processed on Dec 1, 2020, 12:38:14 AM
Finished on Dec 1, 2020, 12:40:17 AM
Après l’arrêt du deuxième live :
L’utilisation mémoire a l’air stable également :
Merci pour la réactivité des fix!
Hello,
Oui en effet c’est un bug connu. Je pense qu’il s’agit d’un soucis au niveau de notre player. Mais je vais voir si ffmpeg ne peut pas corriger ce soucis en amont.
Et merci à vous pour les tests, qui m’ont permis de corriger quelques bugs avant même la RC (prévue mi décembre). Si vous avez d’autres retours, n’hésitez pas.
Les deux derniers glitchs devraient disparaître avec https://github.com/Chocobozzz/PeerTube/commit/2650d6d489f775a38c5c3fdb65daabc7d55c15b5 et https://github.com/Chocobozzz/PeerTube/commit/15feebd97ab5291f81b2a8cdcb16a8e4f4c5aa69.
Trop cool ! Je viens de voir que t’as réussi à pondre le live permanent avant ce week-end, on va tester ça et te faire nos retours au plus vite !
Merci mille fois pour ton efficacité !
Edité : Pour les autres points, 12b a fait pas mal de tests ces derniers jours et te fera parvenir un retour complet bientôt.
J’ai perdu un peu de temps dans mes tests parce-que j’en ai eu marre d’utiliser OBS pour générer des live. Aussi je voulais utiliser des flux vidéo un peu plus reproductibles et qui permettent de mieux visualiser/entendre les soucis éventuels dans la transmission en direct.
Je me suis donc lancé dans le bricolage de petits scripts pour générer des fichiers et des flux RTMP avec ffmpeg, que je ne connaissais pas trop.
Ça m’a pris un moment pour arriver à ce que je voulais mais j’ai maintenant de quoi me lancer dans des tests plus complets avec plusieurs live simultanés pour essayer de caractériser les limites des serveurs que nous utilisons. En mettant au point ces scripts j’ai trouvé quelque petits bugs supplémentaires :
Des exemples de replay où ces phénomène sont présents se trouvent sur mon serveur peertube de test : https://dev.tube.distrilab.org/video-channels/live12/videos
Et si ça peut être utile, les scripts que j’utilise pour générer mes flux vidéos de test sont par là :
On vient de terminer un test à plus grande échelle, en demandant à un moment à la commu’ de Mastodon de participer pour ajouter de la charge sur le serveur.
On a lancé quatre lives de 4h ayant le replay activé. Transcoding sur 720p et 480p.
Ensuite, on a lancé un cinquième live pointant sur le monitoring du serveur, sans replay, avec les transcodings 480p, 720p, 1080p. Il est encore accessible ici à l’heure où j’écris le message : https://dev.tube.distrilab.org/videos/watch/1c59c1d6-d554-4555-abe0-dea55aa2b5ad
Une fois Mastodon contacté, on a eu à peu près 91 fenêtres de live ouvertes simultanément sur 41 IP différentes.
Au pic d’activité le serveur est monté à une moyenne d’utilisation de 64% de CPU, 3,24 Go de RAM, et au niveau du réseau, 40,5 Mbit/s OUT et 12 Mbit/s IN. C’est une moyenne sur trente minutes.
Stats au lancement du stream
Stats au pic d’activité
Stats après que tous les lives se soient terminés
Le thread lancé sur Mastodon avec les commentaires utilisateurs :
Le live a été testé sur plusieurs navigateurs, sur smartphone (Android/iPhone), tablette et desktop. Dans l’ensemble, tout semblait fonctionnel. Le live était fonctionnel via l’embed de Mastodon
Maintenant, plusieurs problématiques ont été soulevées :
Pour ce qui est du live permanent, on essaiera demain. On a voulu faire un essai, mais ça ne marchait pas sur le coup alors on s’est dit qu’on verrait ça demain. On a capté après coup que l’essai était paramétré pour du 1080p et que le serveur était peut-être en train de pleurer. Cela correspond au gros pic d’activité du CPU sur la deuxième image.
Si t’as des questions, n’hésite pas.
J’ai arrêté le live du monitoring du serveur de test de l’URL qu’a posté @Booteille ci-dessus et j’en ai relancé un autre à la place avec la nouvelle option de live permanent :
