プロトコル、トランスポート、コンテナを分離することから始める

HLS、FLV、HTTP-FLV、RTMPという用語は、しばしば同じレイヤーを説明するかのように使用されますが、そうではありません。

• HLS（HTTP Live Streaming）は、Appleによって開発されたメディア配信プロトコルです。プレイリストと、HTTPまたはHTTPS経由で配信される一連のメディアセグメントを使用します。

• FLV（Flash Video）は、エンコードされたオーディオとビデオを運ぶことができるコンテナフォーマットです。FLV自体はストリームがネットワーク上をどのように移動するかを定義しません。

• HTTP-FLVは、HTTP接続を介してFLVストリームを開いたままにします。プレーヤーは、プレイリストと個別のセグメントを要求する代わりに、メディアを継続的に受信します。

• RTMPは、歴史的にFlashに関連付けられた別個のストリーミングプロトコルです。視聴者がHLSや他の出力フォーマットを受信する場合でも、取り込み側で依然として一般的です。

この区別はシステム設計時に重要です。プラットフォームはエンコーダからRTMPを受け入れ、ソースを一度処理し、異なる視聴者グループ向けにHLSとHTTP-FLVの出力を公開できます。したがって、配信方法の選択は、必ずしもカメラ、エンコーダ、または上流の取り込みプロトコルの変更を必要としません。

セグメント配信が大規模でうまく機能する理由

HLSは、ライブまたはオンデマンドのプログラムをメディアセグメントに分割し、M3U8プレイリストにリストします。従来のデプロイメントでは、通常.ts拡張子で識別されるMPEG-2トランスポートストリームセグメントを使用します。最新のHLSはフラグメントMP4（fMP4と呼ばれることが多い）も使用でき、これは現代のエンコーディングおよびパッケージングワークフローに実用的な基盤を提供します。オーディオと字幕は、ビデオとともに別のレンディションとして提供できます。

プレイリストとセグメントは通常のHTTPリソースであるため、標準のWebサーバー、リバースプロキシ、コンテンツ配信ネットワーク（CDN）によって提供できます。エッジキャッシュは人気のセグメントを視聴者の近くに保持できるため、オリジンへの繰り返しトラフィックを削減します。これにより、HLSは公開ライブイベント、トレーニングポータル、モバイルアプリケーション、地理的に分散した視聴者を持つサービスに適した選択肢となります。

アダプティブビットレート配信はもう一つの中心的な利点です。プラットフォームは、異なる解像度とビットレートで同じプログラムの複数のレンディションを準備します。現在のスループット、バッファステータス、デバイス機能に基づいて、プレーヤーはこれらのバリアント間を移動し、再生を安定させることができます。変化するモバイル接続の視聴者は、完全な中断を経験する代わりに、より低いレンディションを受信する可能性があります。

トレードオフは、従来のHLS再生は通常、セグメント作成、プレイリスト更新、再生バッファを待つことです。実際の遅延は、セグメント期間、プレイリスト設計、プレーヤー設定、ネットワーク条件によって異なります。低遅延HLSはこの遅延を減らすことができますが、パッケージャ、オリジン、CDN、プレーヤー間の協調的なサポートが必要です。それは最終段階で追加するスイッチではなく、エンドツーエンドの設計選択として扱うべきです。

セグメント期間はサービス目標に合わせて選択する必要があります。短いセグメントは、プレーヤーが新しいメディアをより早く発見するのに役立ちますが、プレイリストの更新、オブジェクトリクエスト、パッケージングオーバーヘッドも増加させます。長いセグメントはリクエスト頻度を減らし、配信効率を向上させる可能性がありますが、起動時間を増やし、品質変更の応答性を低下させる可能性があります。エンコーダのキーフレーム間隔はパッケージング計画に従い、すべてのレンディションが同じ位置にクリーンなスイッチポイントを公開するようにする必要があります。

継続的なHTTPストリームが依然として有効なケース

HTTP-FLVは、長寿命のHTTPレスポンスを介してFLVタグを送信します。再生が開始されると、メディアデータは同じ接続を介して到着し続けます。更新するセグメントプレイリストがないため、適切に調整されたシステムは通常、従来のセグメント化ワークフローよりもライブソースに近い状態を維持できます。

この動作は、オペレーター向けアプリケーション（イベントを観察して迅速に反応する必要がある場合、ビデオ監視ページ、プロダクションダッシュボード、機器監視、リモートインスペクション、内部ライブビューシステムなど）で役立ちます。また、HTTPまたはHTTPSトラフィックをすでに許可しているネットワークを介した配信を簡素化することもできます。

ただし、HTTP-FLVはブラウザのネイティブビデオサポートと混同すべきではありません。Adobe Flash Playerの終了により、古いプラグインベースの再生経路が削除されました。Adobeは2020年12月31日にFlash Playerのサポートを終了し、2021年1月12日にFlashコンテンツのブロックを開始しました。そのため、最新のHTTP-FLV再生はHTML5プレーヤーに依存し、通常はJavaScriptを使用してFLVストリームを解析し、ブラウザのメディアAPIを介してサポートされているオーディオおよびビデオコーデックをデコーダに供給します。

これにより、互換性の依存関係が生じます。ブラウザは、必要なメディアAPIとFLVコンテナ内で運ばれるコーデックをサポートしている必要があります。その結果、HTTP-FLVは制御されたWebクライアントや専用アプリケーションに適しており、制限のない公開視聴者にはあまり適していません。多数の継続的な接続は、キャッシュ可能なセグメントオブジェクトよりも、配信サーバーや中間ネットワークデバイスに持続的な負荷をかける可能性があります。

配信経路を視聴要件に合わせる

プロトコルの決定は、機能チェックリストではなく、運用要件から始めるべきです。以下の比較は有用な出発点を提供します。

視聴者数が予測不能な場合、視聴者が多様なデバイスを使用する場合、再生継続性が即時性よりも重要な場合、またはCDN配信が計画の一部である場合は、HLSを主要な出力として使用します。プラットフォームがWebプレーヤーを制御し、視聴者が既知であり、同時視聴者数が管理可能で、ライブ視聴遅延の削減に明確な運用価値がある場合は、HTTP-FLVを使用します。

いずれかの経路を承認する前に、各段階（キャプチャ、エンコード、ネットワーク取り込み、メディア処理、配信、プレーヤーバッファリング、デコード）の遅延予算を定義してください。これにより、配信プロトコルが他の場所で導入された遅延のせいにされるのを防ぎます。低遅延出力は、長いGOPのエンコーダ、過負荷のトランスコーダ、または大きなセーフティバッファで構成されたプレーヤーを補償できません。本番環境で使用される実際のエンドポイントとネットワークで結果を測定してください。

どちらのオプションもあらゆる形式のリアルタイム通信に適しているわけではありません。ユーザーが双方向会話を行うか、非常に厳しいインタラクションタイミングでデバイスを操作する必要がある場合は、リアルタイム通信技術がより適切かもしれません。重要な点は、配信アーキテクチャを選択する前に、単方向ビデオ配信をインタラクティブメディアから分離することです。

ハイブリッド設計はソースを複製せずにより多くのユーザーをカバーする

多くのプロジェクトは二者択一の決定を必要としません。ハイブリッドプラットフォームは1つのソースを取り込み、タイムスタンプとコーデックを正規化し、異なるクライアント向けに別々の出力をパッケージングできます。

1. ソースを取得する。 カメラ、エンコーダ、ゲートウェイ、または上流プラットフォームから、フィールドデバイスがサポートする取り込みプロトコルを介してライブビデオを受信します。

2. メディアを検査する。 ストリームを再パッケージ化できるか、トランスコードする必要があるかを決定する前に、コーデック、解像度、フレームレート、オーディオフォーマット、タイムスタンプの連続性を検証します。

3. 配信レンディションを作成する。 HLS用のアダプティブビットレートラダーを生成します。HTTP-FLV出力は、それを必要とし、そのメディアプロファイルをデコードできるクライアントに対してのみ生成します。

4. 視聴者経路を分離する。 HLSはオリジンとCDNを介して外部または大規模視聴用に送信します。HTTP-FLVは運用ユーザー向けに制御された配信クラスタを介してルーティングします。

5. アクセス制御を適用する。 各経路に適したHTTPS、短期認証、オリジン保護、セッションポリシーを使用します。

6. 完全なチェーンを測定する。 取り込みの継続性、トランスコード負荷、パッケージングエラー、初回フレーム時間、バッファリング、切断、エンドツーエンド遅延を監視します。

このモデルは、すべてのクライアントに同じ妥協を強いることを回避します。公開視聴者は回復力がありスケーラブルなストリームを受け取り、オペレーターは低遅延の経路を使用できます。メディアプラットフォームは、レガシーソースフォーマットを現在のブラウザやアプリケーションが消費できる出力に変換するポイントにもなります。

再パッケージ化とトランスコーディングの選択

入力コーデックがすでに配信プロファイルに一致している場合、プラットフォームは圧縮メディアを再パッケージ化するだけでよいかもしれません。再パッケージ化は、各フレームをデコードおよびエンコードせずにコンテナまたは出力構造を変更するため、通常は処理リソースを少なく消費し、ソース品質を保持します。これは、コーデックサポート、タイムスタンプ、キーフレーム配置、オーディオパラメータがすでにターゲットプレーヤーに適している場合にのみ適切です。

トランスコーディングは、ソースコーデックが意図されたクライアントでデコードできない場合、複数の解像度とビットレートが必要な場合、またはフレームレート、オーディオフォーマット、キーフレーム構造を正規化する必要がある場合に必要です。計算コストと処理遅延が追加されるため、キャパシティは平均使用量ではなくピーク同時チャネル数に基づいて計算する必要があります。ハードウェアアクセラレーションはチャネル密度を向上させることができますが、出力品質と動作は選択したプレーヤーでテストする必要があります。

本番システムは単一障害点も排除する必要があります。冗長オリジン、制御されたプレーヤー再接続、テスト済みのフェイルオーバールールを使用し、障害を増幅させる攻撃的な再試行ループを作成しないようにします。

回避可能な障害を防ぐデプロイメントチェック

プロトコルの選択だけでは信頼性の高いサービスを保証しません。起動前に、完全なメディアおよびネットワーク経路を検証してください。

• エンドポイントでのコーデックサポートを確認する。 トランスポートはプレーヤーに正常に到達しても、ブラウザがオーディオまたはビデオプロファイルをデコードできないために再生が失敗することがあります。

• タイムスタンプを連続させる。 壊れたまたは非単調なタイムスタンプは、ストール、オーディオドリフト、品質切り替えの失敗を引き起こす可能性があります。

• キーフレームをパッケージングルールに合わせる。 HLSレンディションは、プレーヤーが目に見える中断なしに品質を切り替えられるように、調整されたキーフレーム境界を使用する必要があります。

• ソースからプレーヤーまでのHTTPSを計画する。 セキュアなページは非セキュアなメディアを要求すべきではなく、証明書はオリジンおよび配信レイヤー全体で有効でなければなりません。

• 実際のネットワーク条件をテストする。 ローカルネットワークでのみテストするのではなく、限られた帯域幅、パケットロス、短い中断下での起動、リカバリ、品質変化を検証してください。

• 接続動作に合わせてサイジングする。 HLSのキャパシティプランニングは、セグメントリクエスト、ストレージ、キャッシュヒット率に大きく焦点を当てます。HTTP-FLVの計画は、長寿命の同時接続と持続的な出力トラフィックを考慮する必要があります。

• フォールバックポリシーを提供する。 優先プレーヤーまたはフォーマットが利用できない場合、アプリケーションは無制限に再試行するのではなく、サポートされている代替手段または明確なエラーを返すべきです。

ほとんどの外部向けサービスでは、HLSがより安全なデフォルトです。なぜなら、アダプティブビットレート再生と成熟したHTTP配信を組み合わせているからです。HTTP-FLVは、管理されたプレーヤーと低遅延がユニバーサルリーチよりも重要な場合に依然として有用です。ハイブリッドアーキテクチャは、同じライブソースが両方のグループにサービスを提供しなければならない場合に、しばしば最も実用的な答えとなります。

よくある質問

ライブ配信ワークフローに字幕を追加できますか？

はい。字幕は上流で生成するか、メディア処理中に挿入できます。HLSでは、WebVTT字幕レンディションが一般的なオプションです。カスタムHTTP-FLVプレーヤーは、別個のタイムドテキストチャネルと独自の同期ロジックを必要とする場合があります。

ライブイベントが進行中に視聴者は巻き戻しできますか？

サービスが十分に長いライブウィンドウを維持し、プレーヤーがタイムシフト制御を提供している場合は可能です。保持ウィンドウ、ストレージ容量、コンテンツ権利は、ライブ巻き戻しを有効にする前に定義する必要があります。

ビデオ帯域幅が利用できない場合、プレーヤーはオーディオのみにフォールバックできますか？

はい、プラットフォームがオーディオ専用レンディションまたは別個のオーディオストリームを公開し、プレーヤーがそれを選択するように設定されている場合に限ります。これにより、非常に制約のある接続でも重要な解説や指示を維持できます。

分析は視聐者の退出とネットワーク障害を区別できますか？

単一の切断イベントだけではできません。プレーヤーイベント、ハートビート間隔、セッション識別子、再試行動作、サーバー接続ログを組み合わせて、より確実に退出を分類します。

イベント終了後、ライブURLはどうなるべきですか？

プラットフォームはライブセッションを閉じるか、エンドスレートを公開するか、処理完了後にユーザーをアーカイブプログラムにリダイレクトできます。埋め込みプレーヤーや共有リンクが説明なく失敗しないように、事前に遷移を定義してください。