24時間配信はVPSで自作するか、マネージドクラウドサービスを使うか

VPSとFFmpegを使えば24時間配信は実現できます。レンタルサーバーに動画をアップロードし、concat用のプレイリストを書いて、プラットフォームのRTMP URLに向けてループ再生するだけです。実際に動きますし、学習用のプロジェクトとしても優れています。ただし本当のコストはあなたの時間であり、それはエンコード、クラッシュからの復旧、監視、帯域の計画に費やされます。

ここでは、自作に実際に何が必要なのか、そしてどんなときにマネージドサービスのほうが時間の使い方として賢いのかを説明します。

この記事のポイント

• 基本的なFFmpegのループはすぐに作れますが、何か月も動かし続けることこそが本当の仕事です。
• フレームレートやタイムスタンプの不一致があると、コピーモードのプレイリストがクラッシュして最初に戻ることがあります。
• FFmpegは自分で再起動もしなければ、異常を通知してもくれません。
• 配信先を1つ増やすごとに、そのビットレート分がまるごと送信トラフィックに加算されます。

VPSで自作する構成の全体像

一般的な自前ホスティングの構成は4つの要素でできています。

1. Linux VPS：動画ライブラリ用のディスク容量と、止まらない配信を支える送信転送量が必要です。
2. 動画ファイル：SFTPでアップロードするか、ストレージから同期します。
3. プレイリストファイル：FFmpegのconcatデマルチプレクサ用です。
4. FFmpegコマンド：プレイリストをリアルタイムで読み込んでループし、rtmp://a.rtmp.youtube.com/live2 のようなインジェストURLとストリームキーに送出します。

多くのチュートリアルはストリームコピーモードを使います。これはFFmpegが映像と音声を再エンコードせずにそのまま通す方式です。CPU使用率はごくわずかなので小さなサーバーでも対応でき、最初の配信を立ち上げるのは本当にあっという間です。

落とし穴は、コピーモードがスムーズに動くのはすべてのファイルが技術的に揃っているときだけ、という点です。長期的な手間の大半はここに費やされます。

エンコードとタイムスタンプ：FFmpegのプレイリストが最初に戻る理由

ストリームコピーでは、FFmpegはファイルをそのままつなぎ合わせるため、1本でも異質なファイルがあると継ぎ目が壊れます。よくある原因は次のとおりです。

• フレームレートの不一致：30 fpsのファイルの中に29.97 fpsで書き出した動画が混ざっている、あるいは可変フレームレートのスマホ録画が入っているケースです。
• 解像度や音声フォーマットの違い：1080pのファイル群の中に720pのクリップが1本だけある、といった状況です。
• 特殊なタイムベースやタイムスタンプの欠落：一部の編集ソフトや画面録画ツールが残すものです。

症状はログの警告から映像のフリーズ、FFmpegの終了までさまざまです。再起動するとプレイリストは最初の動画からやり直しになるため、視聴者は同じ冒頭の1時間を何度も見ることになります。

解決策は、プレイリストに入れる前にすべての動画を1つのプロファイルに再エンコードすることです。解像度、固定フレームレート、キーフレーム間隔、音声フォーマットをすべて揃えます。詳しくは24時間配信向けのエンコード設定をご覧ください。

クラッシュ、再起動、監視をすべて自分で担う

FFmpegは素晴らしいツールですが、単一のプロセスにすぎず、生き続けることには関心がありません。プラットフォームが接続を切ったとき、ネットワークが一瞬途切れたとき、あるいはファイルがエラーを引き起こしたときに終了し、次のような仕組みを自分で作っていない限り、誰も元に戻してくれません。

• スーパーバイザー：自動再起動を設定したsystemdサービスなど。
• 再生位置の記録：再起動してもプレイリストが先頭から始まらないようにするためのものです。
• ヘルスチェック：プラットフォームが実際に映像を受信しているかを確認します。プロセスが動いていても配信がオフライン表示になることがあるからです。
• スマホへのアラート：深夜3時の障害が朝食の時間まで続かないようにします。

さらに保守作業もあります。アップデート、再起動、ログで埋まっていくディスク、平文のスクリプトに書かれたストリームキーなどです。どれも単体では難しくありませんが、まとめるとパートタイムの仕事になります。何を監視すべきかは配信の状態と稼働率の監視で解説しています。

1台のサーバーからの帯域と複数配信先

止まらない配信は、多くの人が想像する以上にデータを使います。6 Mbpsの配信を30日間流し続けると、およそ1.9 TBを送信します。これを3つのプラットフォームに送ると、サーバーは24時間ずっと約18 Mbpsを送出し、月に6 TB近くになります。プロバイダーの送信転送量の上限と超過料金の条件を確認してください。

複数の配信先へのFFmpeg送出には独特の癖もあります。プラットフォームごとに1プロセスを立てれば、監視すべきプロセスが複数になります。FFmpegのteeマルチプレクサを使えば1つの入力を複数の出力に送れますが、各出力を失敗に耐えるよう設定していない限り、古いキーをプラットフォームが拒否するなど、たった1つの配信先の失敗でプロセス全体が落ちることがあります。

プラットフォーム固有の仕様への対応も自分の仕事です。たとえばYouTubeの12時間アーカイブ制限は、単純なループでは考慮されません。

VPSでの自作配信が正解になるケース

次の項目の多くに当てはまるなら、自前ホスティングが向いています。

• Linuxのコマンドラインに慣れていて、システムの保守を楽しめる。
• 配信先は1つだけ、または複数の配信先の障害処理を自分で作り込む意欲がある。
• ライブラリが小さく安定していて、すべてのファイルの書き出し方を自分で管理している。
• ときどきプレイリストが先頭から再開しても、視聴者にとって大きな問題にならない。
• 配信が裏側でどう動いているのかを学びたい。

一方、配信が収益やブランドを支えている、動画を頻繁に追加する、複数のプラットフォームが必要、あるいは時間をコンテンツ制作に使ったほうがいい、という場合はマネージドサービスが理にかなっています。公平な比較とは、サーバー代にセットアップの時間と深夜の対応時間を足したものと、それらの問題をすでに解決済みのサービスとを比べることです。

同じ24時間ループをStreamHouseで動かす

StreamHouseは、この構成の要素を一つひとつ置き換えます。アップロードした動画は事前に1つの統一されたエンコードプロファイルに変換されるため、ビットレートとタイムスタンプが安定し、規格の合わないファイルでプレイリストが最初に戻ることはありません。ブラウザでプレイリストを作成し、YouTube、Twitch、Rumble、Facebook、カスタムRTMP、SRTなどの配信先を追加して、「開始」を押すか開始時刻を予約するだけです。

ループはクラウド上で24時間稼働し、プラットフォームやネットワークの一時的な不具合の後も自動で再接続します。配信中でも動画の追加、削除、並べ替えができ、変更は次の動画から反映されます。配信先を増やしても追加の配信枠は消費しません。また、連携済みのYouTubeチャンネルでは、録画保護機能により、指定したタイミングで最初のブロードキャストを終了し、プレイリストを再起動することなく新しいブロードキャストで配信を続けられます。

サブスクリプションと従量課金のクレジットは料金ページで比較できます。

よくある質問

VPS上のFFmpegでYouTubeの24時間配信はできますか？

はい、できます。YouTubeのRTMP URLに向けてFFmpegコマンドをループさせれば、チャンネルをライブ状態に保てます。難しいのは何週間も健全な状態を保つことで、統一されたエンコード、自動再起動、監視、長時間配信のアーカイブ対応はすべて自分の責任になります。

FFmpegのプレイリストが何度も最初から再生されてしまうのはなぜですか？

多くの場合、1本のファイルだけがフレームレート、解像度、音声フォーマットなどで他と一致していません。コピーモードではタイムスタンプが壊れ、FFmpegが終了して最初の動画から再開します。すべてのファイルを1つの固定プロファイルに再エンコードしてください。

24時間配信は1か月でどれくらいの帯域を使いますか？

6 Mbpsの配信を30日間ノンストップで流すと約1.9 TBで、ビットレートが高い場合や配信先を増やした場合はそれに比例して増えます。同じビットレートで3つのプラットフォームに送ると6 TB近くになるため、まずサーバーの転送量の上限を確認してください。

24時間配信には高性能なVPSが必要ですか？

ファイルを事前にエンコードしてストリームコピーを使うなら必要ありません。CPUはほとんど使いません。ただし、サーバー上で1080pをリアルタイムエンコードする場合は話が別で、専用コアが必要になり、小規模な共有プランではリアルタイムの速度に追いつけないことがよくあります。

次に読む

• 高価な機材なしで24時間配信を運用する
• クラッシュした配信を自動で再開する
• サーバーなしでYouTubeに24時間配信する
• サブスクリプションとクレジットを比較する