Fonctionnalité Live — Retour d'utilisation

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.

1 Like

Merci pour les retours ! J’ai trop hâte que tout ça soit dispo en version stable !

Petit soucis d’augmentation de l’utilisation CPU du serveur dans le temps lors d’un live

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é

  • nombre de clients qui visualisaient le stream non constant
  • flux vidéo qui passait d’images relativement statique a des séquence avec plus de mouvements

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

  • un seul client visualisant le live
  • 4 résolutions de transcoding d’activées
  • publication du replay activée

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 :

  • un seul client visualisant le live
  • **1 seule résolutions de transcoding d’activée **
  • publication du replay activée

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 :

  • un seul client visualisant le live
  • **pas de transcoding activé : **
  • publication du replay activée

Mais il y avait toujours une augmentation de l’utilisation CPU dans le temps.

Première heure de streaming :


Après environ 10h30 de streaming :

Graphe sur toute la durée du test :

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

  • un seul client visualisant le live
  • 1 résolutions de transcoding d’activée
  • publication du replay désactivée

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)

1 Like

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 :

  • 4 vCore
  • 6 GB RAM
  • 32 GB de disque

Hote Physique : Serveur dédié chez Online/Scaleway modèle « Dedibox Pro-2-M-SATA »

  • 4 Cores / 8 Threads (Intel® Xeon® CPU E3-1230 v3 @ 3.30GHz)
  • 32 Go RAM,
  • 2x 1.8 To HDD en RAID-1
  • 100 Mbit/s de bande passante internet

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 »

  • 4 vCore
  • 8 Go RAM
  • 160 Go SSD NVMe
  • 1 Gbit/s de bande passante internet

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

1 Like

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

  • streaming en 720p
  • transcoding activé en 720p et 480p
  • publication du replay activée

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 :


Le basculement du premier au deuxième live était à 0h33
Les infos d’exécution du job « video-live-ending » :

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!

1 Like

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.

1 Like

Les deux derniers glitchs devraient disparaître avec https://github.com/Chocobozzz/PeerTube/commit/2650d6d489f775a38c5c3fdb65daabc7d55c15b5 et https://github.com/Chocobozzz/PeerTube/commit/15feebd97ab5291f81b2a8cdcb16a8e4f4c5aa69.

1 Like

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 :

  1. Les 8 premières secondes de la vidéo des lives sont figés. Ça arrive pendant les live et sur les replay
  2. Il y a une coupure périodique sur la bande son toutes les 8 secondes. Ces coupures ne sont pas présentes pendant les live, uniquement sur les replay.
  3. Il y a par moments quelques légères saccades dans les images.
  4. Les replay durent légèrement plus longtemps que ce qui est envoyé pendant le live : 4 secondes de plus pour un live de 5 minutes. 52 secondes de plus pour un live d’une heure.
  5. Dans certains cas le replay d’un live envoyé en 1080p est publié dans une résolution étrange de 1072p. Ça n’arrive que sur un des deux type de vidéos que je génère. Et je n’ai pas observé le même genre de soucis en 720p

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

3 Likes

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 :

  • Le nombre de spectateurs, en bas à gauche du live, n’est pas cohérent avec le nombre de pairs affichés. Il ne se met pas à jour en temps réel.
  • À peu près toutes les 8 secondes, le contenu de l’image se floute fortement puis revient à la normale.

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 :


Je diffuse dessus en ce moment avec OBS en 1080p, 10 img/s
Je testerais des interruptions et reprises de la diffusion plus tard dans la journée