Fonctionnalité Live — Retour d'utilisation

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

Ok merci, par contre avec le live du dessus (que tu as arrêté) je n’ai pas reproduit le flou toutes les 8 secondes. Ça arrive avec tous les lives, ou seulement certains ? Et est-ce qu’il y a toujours le soucis du son qui saute régulièrement ? je viens de reproduire, je regarde

Le flou toute les 8 secondes est visible sur certain des 4 lives de 4h avec la mire qu’on a fait hier, celui la par exemple :


Mais il n’y a pas le même phénomène sur celui là :

La différence entre les deux est qu’ils n’ont pas été diffusé depuis la même machine. Version de ffmpeg différente et police de caractère différente. Et je viens de récupérer le fichier de la copie du flux vidéo sauvegardé par ffmpeg sur la machine des live qui ont le flou et il y a le soucis dessus également. Ce n’est donc pas causé par peertube.

Les coupures audios c’est sur tous les lives, mais ca ne se produit que sur les replay, pas pendant la diffusion en live ni sur la copie du flux vidéo généré sur la machine qui diffuse le live.
Un exemple :


Et la copie du flux vidéo d’origine où on n’entends pas les coupures :

A noter aussi sur cet exemple la durée de la vidéo qui fait 4 seconde de plus sur le replay du live que sur le flux d’origine. Ca n’apparaît pas dans la durée de la vidéo affichée sur le player mais la lecture de la vidéo dure 4 seconde de plus. Et si on télécharge la vidéo elle fait bien 4 secondes de plus aussi. Les deux phénomènes, coupure son et durée plus élevée, sont peut être lié.

J’ai élucidé mon problème de flou toute les 8 secondes. Mes scripts utilisent l’utilitaire bc pour calculer la taille du buffer d’encodage video pour la fixer à 2 secondes de vidéo à partir du bitrate utilisé. Et cet utilitaire bc n’était pas installé sur une des deux machines que j’utilisais pour diffuser les lives ce qui conduisait ffmpeg à choisir une taille de buffer par defaut qui était probablement trop petite :
[libx264 @ 0x560a3b0624c0] [warning] VBV buffer size cannot be smaller than one frame, using 68 kbit

1 Like

J’ai testé l’interruption et la reprise d’un live permanent. Du coté d’OBS pas de soucis. Ça se reconnecte nickel. Du coté du player il faut recharger la page web dans le navigateur pour que ça reprenne la lecture. (Firefox 83.0 sous linux)

OK merci pour les mises à jours. Donc concernant les autres soucis :

  • Ce commit devrait corriger le soucis du freeze en début de vidéo
  • Ce commit devrait corriger les soucis d’audio rencontrés avec le replay. La création du replay devrait aussi être plus rapide, car on a optimisé la concaténation des fichiers .ts et enlevé le transcoding de l’audio. C’est à tester avec plusieurs streams différents, je ne suis pas 100% sûrs que les replays seront corrects (vidéo qui se joue, audio/vidéo synchronisés etc)
  • Ce commit devrait recharger automatiquement la vidéo lors des lives permanents qui reprennent sans qu’on ait quitté la page
1 Like

Super!

Pour les live permanent ça a a l’air OK. J’ai juste fais un test rapide. La lecture n’a pas reprise toute seule de mon coté mais c’est sûrement parce-que j’ai désactivé la lecture automatique des vidéos dans les paramètres de mon compte peertube. La page s’est bien mise à jour toute seule lors de la reprise du live et il a suffit que je clique au centre de la vidéo pour la relancer. Je n’ai pas eu besoin de recharger la page comme avant.

Pour les autres bugs, j’ai fais un test de 5 minutes en 720p
Le freeze en début de vidéo c’est OK
Les coupures de son ne sont plus là dans le replay. Mais il y a peut-être des tout petit clics a peine perceptible par moment. Il faudrait que je re-écoute dans un environnement plus silencieux que là ou je suis en ce moment et que je vérifie que ca n’est pas des parasites de mon coté dans mon système audio.
edit : il y a bien des petits clics par moment mais ça à l’air lié au navigateur internet. Je ne les entends que sur firefox (j’en entends un autours de 4s du début dans l’exemple ci-dessous) et pas sur chromium. Et ils ne sont pas non plus dans le fichier téléchargé et visionné avec VLC ou mplayer.

Par contre le replay fait 6 minutes au lieu de 5. Arrivé a 300 secondes ça reboucle à 240 :


Pour vérifier la synchro audio/vidéo il faudrait que j’ajoute des petits bips toutes les 10s dans mes flux de test. Je vais voir ce que je peux faire a ce niveau.

Pour pouvoir vérifier la sychronisation audio/video j’ai rajouté a mon flux de test avec la mire des petit bips toutes les dix secondes, synchro avec les moments où le texte qui bouge de droite a gauche touche les bords de l’image.

Un premier test de 5 minutes qui n’a rien révélé d’anormal au niveau de la sychro audio/video (mais le replay fait aussi 6 minutes au lieu de 5 comme sur mon test précédent) :

J’en ai relancé un plus long qui est encore en cours à l’heure ou j’écris ces lignes :

On a fait plus de test avec l’option live permanent. Le player redémarre bien tout seul quand on ne désactive pas la lecture automatique des vidéos. Sauf si on arrête et redémarre le live trop vite. Là il faut recharger la page pour qu’il arrête de tourner en rond.
Mais je pense qu’on va quand même partir sur ce type de live pour ce WE. C’est vraiment mineur comme soucis. Si tout se passe bien on diffusera donc l’université populaire du canard réfractaire a cette adresse :


Et on mettra en ligne des replay manuellement en les enregistrant en parallèle du live avec OBS.

mais le replay fait aussi 6 minutes au lieu de 5 comme sur mon test précédent

Décidément les replays m’auront posé bien des soucis :angry: Mais je pense savoir d’où vient le problème, je m’en occupe lundi :slight_smile:
J’essayerai aussi de voir s’il y a moyen de gérer la déconnexion/reconnexion rapide. Quand tu dis « trop vite », tu parles de combien de temps ?

2 Likes

Trop vite c’est si je relance le live avant que le player ne se soit mis en attente de reprise. Quand il y a le cercle qui tourne au milieu de l’image

J’ai pas (encore) essayé de simuler une déconnection / reconnection encore plus rapide, avant que le payer n’affiche ce cercle qui tourne

Quelque news rapide depuis la régie du live de l’univ pop du canard réfractaire qui est en cours.
Jusqu’ici tout se passe bien. Le serveur a l’air de tenir le coup et les echanges pair à pair ont l’air de bien fonctionner ce qui doit bien soulager sa bande passante réseau :


Note : streaming en 1080p 10 img/s, transcoding en 1080p, 720p et 480p (j’ai changé le framerate un peu plus tard voir le post suivant)

Une question : Est-ce que le nombre de pairs affiché est le nombre total de personnes qui sont en train de regardé le live ou bien est-ce qu’on ne voit que ceux qui regarde la même résolution?

1 Like

Si ma mémoire est bonne, le nombre de spectateurs (affiché en dessous du titre) est aggrégé, et le nombre de pairs (dans le player donc) ne porte que sur la définition courante de la vidéo. Le premier n’est pas encore mis à jour sans rechargement de la page.

Pour info, je viens de faire un tour sur votre live, et dans la console de mon firefox j’ai plusieurs fois l’erreur WebRTC: ICE failed, add a TURN server and see about:webrtc for more details.
Mais la vidéo marche nickel, pas de soucis à signaler.

Et je viens aussi d’avoir :
Uncaught (in promise) DOMException: RTCPeerConnection is gone (did you enter Offline mode?) PeerConnection.jsm:1154:12 _validateIdentity resource://gre/modules/media/PeerConnection.jsm:1154

Le nombre de pair n’a pas l’air de vraiment refléter le nombre de personnes qui regardent la vidéo, même si on ne considère que la résolution qu’on est en train de regarder.
Là en ce moment sur le player que j’ai lancé depuis le début du live ca m’affiche 245 pairs. Et sur un autre qui ne tourne que depuis quelques minutes, en regardant la même résolution, je n’en ai que 12.

Coté charge du serveur, le plus gros pic que j’ai vu jusqu’ici c’était pendant l’intervention de @Pouhiou avec 256Mbit/s de bande passante réseau utilisée en émission (moyenne sur une période de 5 min).
Mon player affichait 171 pairs à ce moment là mais je me demande si ce n’est pas un cumul de tous les pairs qu’il a vu passer depuis le début, pas uniquement ceux qui sont actifs à un instant t.

Plus de détails sur la copie d’écran ci-dessous :


Note : streaming en 1080p 24 img/s, transcoding en 1080p, 720p et 480p

Il y aurait un autre moyen d’avoir le nombre instantané de clients en train de regarder un live?

Genre une simple commande CLI pour faire simple et rapide ?

Oui il y a peut-être une API pour ca?