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.
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 :
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 :
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 :
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
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 :
.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)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 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 :
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 Mais je pense savoir d’où vient le problème, je m’en occupe lundi
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 ?
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 :
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?
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.