Ce que Twitch écrit sur le plafond.
La page Broadcast Guidelines pose le plafond en trois phrases. C'est un nombre fixe, pas un réglage du tableau de bord.
La troisième phrase mérite une deuxième lecture. Twitch refuse de décrire ce qui suit la coupure et renvoie à l'encodeur.
La reconnexion est donc l'affaire du streamer, selon les mots de Twitch. Rien sur cette page ne promet qu'une diffusion reprend toute seule.
Ce qui se passe au plafond.
Quatre choses sont observables de l'extérieur, et quatre seulement. Le reste relève des rouages internes de Twitch, donc ce guide n'en parle pas.
La diffusion s'arrête. La chaîne quitte l'annuaire des lives, et le spectateur reçoit l'écran hors ligne à la place de la vidéo.
La VOD de cette diffusion s'arrête au même instant. Un fichier en cours de lecture est donc coupé net, pas à la fin de son contenu.
Se reconnecter crée une nouvelle diffusion. La notification de mise en ligne repart, et les abonnés reçoivent une deuxième alerte pour une chaîne qui n'a jamais vraiment cessé.
- Le flux s'arrête au plafond, où qu'en soit la lecture.
- Le spectateur voit un écran hors ligne, la chaîne sort de l'annuaire.
- La VOD de la diffusion est coupée à la seconde de la déconnexion.
- Une reconnexion est une nouvelle diffusion, donc la notification repart.
Pourquoi se reconnecter après coup échoue.
Le réflexe est de laisser tomber la coupure et de relancer l'encodeur. Ça tient pour une machine qui diffuse un jeu. Pas pour une chaîne qui rediffuse une archive.
La coupure tombe au milieu d'une VOD. Le spectateur arrivé vingt minutes plus tôt perd la suite du fichier, et la rediffusion archivée s'arrête en pleine phrase.
Entre la coupure et la reprise, l'écran est noir. Trente secondes de relance font trente secondes de rien, à l'heure où ça tombe.
La chaîne quitte aussi l'annuaire pendant ce trou. Être listée pendant que tu dors est tout l'intérêt du 24/7, et le trou le rend.
Reste le chat. Si un vote pour la prochaine VOD est ouvert quand l'encodeur meurt, le bot annonce un résultat pour une diffusion qui n'existe plus.
- La coupure tombe dans un fichier, la VOD est tronquée et la fin est perdue.
- L'écran reste noir le temps de la relance.
- La chaîne sort de l'annuaire pendant le trou.
- Un vote en cours se conclut sur un flux déjà terminé.
Planifier la reconnexion, plutôt.
La solution est d'arrêter de traiter la reconnexion comme une panne. Choisis le moment, loin sous le plafond, à une frontière que tu contrôles.
La frontière, c'est l'espace entre deux fichiers. La lecture est une file, donc il existe toutes les quelques heures un point où rien n'est en cours d'image.
La règle tient en une comparaison, faite avant chaque élément. Recycler maintenant si l'âge de la session, plus la durée du prochain élément, plus une marge, dépasse le budget.
Dans VOD247 le budget vaut 12 h par défaut, très en dessous du plafond de 48 h. La marge absorbe le recyclage lui-même et la dérive d'horloge.
Il existe une exception volontaire. Si un élément dure à lui seul plus que le budget entier, recycler avant lui n'apporte rien : il est joué, et la session dépasse.
Cette exception est un choix. Dépasser un budget souple de 12 h coûte peu, couper une VOD en deux coûte cher, et le plafond reste loin dans les deux cas.
La chaîne de référence zerator_247 a été relevée avec des sessions d'environ 12.7 h. C'est la forme que produit un recyclage planifié.
- Avant chaque élément : âge de session + durée du suivant + marge > budget.
- Budget par défaut 12 h, contre un plafond Twitch de 48 h.
- Recyclage uniquement à la frontière entre deux fichiers, jamais en cours de fichier.
- Un élément plus long que le budget est joué quand même, et la session dépasse volontairement.
Ce que voit le spectateur.
Un recyclage planifié est un arrêt suivi d'une reprise immédiate de la même session de publication. En pratique, ça coûte quelques secondes de mise en tampon.
En pratique, Twitch traite une reconnexion rapide comme la suite de la même diffusion. Twitch ne documente pas ce comportement, et sa page dit qu'il dépend de l'encodeur.
La façon honnête de planifier est donc de supposer la reprise visible. La placer entre deux VOD fait que le pire cas est un noir de quelques secondes entre deux fichiers.
Ce que fait le bot de chat.
Le cycle de vote doit survivre au recyclage, et la façon de l'y faire survivre est de l'attacher à la VOD, pas à la connexion.
Dans VOD247 le cycle est clé sur l'élément à l'antenne. Les propositions ouvrent 20 min avant sa fin, le sondage ouvre à 10 min et ferme à 5 min.
La session en dessous peut être recyclée sans toucher à tout ça. Le bot n'annonce jamais un résultat pour une diffusion terminée sous ses pieds.
Le faire à la main avec ffmpeg.
Un cron qui relance OBS toutes les douze heures ne règle rien. Il part à l'heure dite, donc il tombe en cours de fichier, exactement le problème qu'on voulait éviter.
Il faut une relance qui connaît la playlist. Le script attend la fin du fichier en cours, décide, puis relance avant que le suivant commence.
Les étapes ci-dessous sont le minimum. Elles visent un publieur ffmpeg, parce qu'OBS n'offre aucun moyen propre de savoir quand une source média se termine.
Deux détails coûtent du temps quand on les oublie. Les timestamps doivent rester continus d'un fichier à l'autre, et le bot de vote doit apprendre que la session a changé.
- Garde l'instant d'ouverture de la session en cours, en secondes, et conserve-le entre deux relances.
- Sonde le fichier suivant avec ffprobe avant de le jouer, et lis sa durée.
- Applique la comparaison : âge de session + durée + marge contre ton budget.
- Si elle passe, ferme la connexion RTMP et rouvre-en une avant de démarrer le fichier.
- Décale les timestamps de chaque fichier de la durée déjà jouée, pour que le muxeur reste monotone.
- Préviens le bot de chat du changement de session, et laisse un vote ouvert tourner sur l'horloge de la VOD.
- Journalise chaque recyclage avec l'âge de session, pour voir une session qui ne recycle jamais.
La liste de vérification.
Passe cette liste sur ce qui publie ta chaîne aujourd'hui. Chaque case vide est une coupure qui attend une heure où personne ne regarde.
- Ton budget est très en dessous de 48 h, et il est écrit quelque part.
- La relance a lieu à une frontière de fichier, décidée par élément, pas à l'horloge.
- La durée du fichier suivant est connue avant la décision, pas devinée.
- Les timestamps sont continus d'un fichier à l'autre, pour que le lecteur ne cale pas sur un saut.
- Un fichier plus long que le budget a un comportement défini, et ce n'est pas une coupure en plein fichier.
- Le cycle de vote est clé sur la VOD à l'antenne, pas sur la connexion.
- Chaque recyclage est journalisé, avec l'âge de la session au moment où il part.