動画間で再接続しない24/7配信：1つのffmpegをパイプ経由で駆動する
動画
完成した動画を24時間流し続けるライブチャンネルには、2つのシンプルな設計がありますが、どちらも何かを失います。動画ごとにffmpegを再起動すると、切り替えのたびにRTMP接続が切れます。concatプレイリストは起動時に一度だけ読み込まれるため、新しい動画は次の再起動まで待ちます。
設計
各動画は、配信のサイズとフレームレートで一度だけMPEG-TSに変換されます。縦動画は、黒帯ではなく、ぼかした自身のコピーの上に配置されます。1つのffmpegプロセスが標準入力からMPEG-TSを読み込み、ライブ取り込みが期待する通り、2秒ごとにキーフレームを挿入して一定ビットレートでエンコードします。小さなフィーダーが、準備済みのファイルをリアルタイムのペースでそのパイプに次々と書き込み、切り替えのたびに次のファイルを選択します。まず未再生の動画、次に最も再生間隔が長い動画です。ffmpegのMPEG-TSリーダーは、各ファイルのタイムスタンプがゼロから始まることを認識してシフトするため、出力は途切れずに続きます。
詳細1：最初のバイトから始まるペース
最初のバージョンでは、ffmpegの起動時にクロックを開始していました。最初のファイルの準備に9秒かかったため、フィーダーは9秒遅れていると判断し、すべてを一度に送信しました。書き込まれた最初のバイトでクロックを開始するように修正したところ、53秒間の実行で53秒分のストリームが生成されました。
詳細2：継ぎ目の音声
切り替え時、次のファイルの音声は、前のファイルの音声が終了する17ミリ秒前に始まりました。エンコーダーは入力が「時間的に逆戻りしている」と警告し、マルチプレクサーがタイムスタンプを補正しました。aresample=async=1:min_hard_comp=0.01:first_pts=0によるリサンプリングは、エンコーダーが処理する前に、こうした重複をトリミングまたはパディングします。5回の切り替えを含む1分強の実行では、受信ストリーム内のすべての音声およびビデオのタイムスタンプが上昇し、エラーなしでデコードされました。
詳細3：一部の警告は正常
各ファイルはMPEG-TSのカウンターとクロックをリセットするため、ffmpegは切り替えのたびに「Packet corrupt」と「timestamp discontinuity」を報告します。これらの行は想定内であり、実際のエラーが目立つようにログから除外しています。
ウォッチドッグ
ffmpegが終了するか、1分間進捗が止まると、間隔を徐々に広げながら配信を再開し、繰り返し失敗した場合はメッセージを送信します。当社のテストでは、エンコーダーを手動で強制終了しました。7秒後に配信は復旧し、実行中に追加した動画も再接続なしでローテーションに参加しました。再起動は短い再接続であるため、YouTubeのブロードキャストは自動開始し、自動停止しないように設定してください。ストリームキーは、ffmpeg自身のログを含め、すべてのログ行でマスクされています。Studioでは、このライブチャンネルをsystemdサービスとして提供しています。