Un flux 24/7 qui ne se reconnecte pas entre les vidéos : un seul ffmpeg alimenté via un pipe
Vidéo
Une chaîne en direct qui diffuse des vidéos finies en continu propose deux conceptions simples, mais chacune a un défaut. Redémarrer ffmpeg pour chaque vidéo coupe la connexion RTMP à chaque changement. Une liste de lecture concaténée est lue une seule fois au démarrage, si bien qu'une nouvelle vidéo attend le redémarrage suivant.
La conception
Chaque vidéo est convertie une seule fois en MPEG-TS à la résolution et à la fréquence d'images du flux ; une vidéo verticale est centrée sur une copie floue d'elle-même plutôt que sur des bandes noires. Un seul processus ffmpeg lit le MPEG-TS depuis son entrée standard et encode à débit constant avec une image clé toutes les deux secondes, comme l'attend l'ingestion en direct. Un petit alimentateur écrit les fichiers préparés dans ce pipe les uns après les autres, à vitesse réelle, en choisissant le fichier suivant à chaque changement : les vidéos jamais jouées en premier, puis les moins récemment jouées. Le lecteur MPEG-TS de ffmpeg voit que les horodatages de chaque fichier repartent de zéro et les décale, de sorte que sa sortie s'enchaîne sans rupture.
Détail 1 : la cadence à partir du premier octet
Notre première version démarrait l'horloge au lancement de ffmpeg. La préparation du premier fichier prenait neuf secondes, si bien que l'alimentateur pensait avoir neuf secondes de retard et les envoyait toutes d'un coup. Démarrer l'horloge au premier octet écrit a résolu le problème : une exécution de 53 secondes a produit 53 secondes de flux.
Détail 2 : l'audio à la jonction
À un changement, l'audio du fichier suivant commençait 17 millisecondes avant la fin de l'audio du fichier précédent. L'encodeur signalait que son entrée remontait « dans le temps » et le multiplexeur corrigeait un horodatage. Le rééchantillonnage avec aresample=async=1:min_hard_comp=0.01:first_pts=0 réduit ou complète ces chevauchements avant que l'encodeur ne les voie. Lors d'une exécution d'un peu plus d'une minute avec cinq changements, tous les horodatages audio et vidéo du flux reçu augmentaient, et le flux se décodait sans une seule erreur.
Détail 3 : certains avertissements sont normaux
Chaque fichier réinitialise ses compteurs MPEG-TS et son horloge, si bien que ffmpeg signale « Packet corrupt » et « timestamp discontinuity » à chaque changement. Ces lignes sont attendues, et nous les excluons du journal pour que les vraies erreurs ressortent.
Le Chien de garde
Si ffmpeg se termine ou si sa progression s’arrête pendant une minute, le flux redémarre avec des pauses croissantes et envoie un message après des échecs répétés. Lors de notre test, nous avons arrêté l’encodeur manuellement ; le flux est revenu sept secondes plus tard, et une vidéo ajoutée en cours d’exécution a rejoint la rotation sans reconnexion. Un redémarrage est une courte reconnexion, donc configurez la diffusion YouTube pour qu’elle démarre automatiquement et ne s’arrête pas automatiquement. La clé de flux est masquée dans chaque ligne de journal, y compris celles de ffmpeg. Studio fournit ce canal en direct en tant que service systemd.