HDS と HLS ライブ ストリーミングの背後にある基盤となるテクノロジの一部をすばやく習得しようとしています。
EC2 の Amazon WebServices インスタンスに Wowza Media サーバー 3.5 をセットアップし、CloudFront 経由で配布しています。私は初めてライブ イベントを行い、サーバーの負荷がどんどん高くなっていくのを見ていました。HDS/HLS ライブ ストリーミング (および nDVR...) の基盤のいくつかを理解するのを手伝ってくれる人がいるかどうか疑問に思っていました。
- Wowza は私のクラウドフロント ディストリビューションのオリジン サーバーです
- HDS マニフェスト ファイルは、CF で 2 秒間キャッシュするように設定されています (TTL 時間)
- Wowza インスタンスにヒットするすべての IP を確認したところ、実際には CF キャッシュ ロケーションまたはエッジ サーバーであることがわかりました。
- (仮定) すべての HDS トラフィックはポート 80 を介しているため、すべてのビデオ コンテンツは最終的にエッジの場所にキャッシュされます (2 秒間ではありますが)。
ここで私の質問が出てきます: データがビデオ コンテンツにどのように提供されるか (これが私の理解です。はっきりさせてください!): /audio (DVR アプリケーション インスタンス内の m4fa および m4fv?) データを次に再生する必要があります。このデータもポート 80 経由で配信されるため、同様にキャッシュされます。
上記の説明が正しければ、HDS および HLS の最適化について次のことが理にかなっています。
ケース 1: DVR サービス: CloudFront でキャッシュのルールを次のように設定しました。
- 「f4m」、「m3u8」、および「?DVR」で終わるものを 2 秒間キャッシュします (プレイリスト/マニフェスト ファイル)
- 他のすべてのデフォルトは、より長くキャッシュする必要があります (おそらく 1 時間、または 24 時間...?) この方法では、DVR データはキャッシュされたままですが、プレイリストは 2 秒ごとに更新され続けます。
ケース 2: DVR サービスがない (これは最適化するためのより良い方法ですか?)
- DVR サービスをまとめて停止することで、サーバーの負荷も最適化できるのではないかと考えています。この方法では、CF を介して配信されるすべてのデータは最新のオーディオ/ビデオ パケットにすぎません。したがって、すべての視聴者は同じプレイリストとデータ ファイルを要求する必要があります。私のサーバーはマニフェスト ファイルを更新するために各エッジ ロケーションから 2 秒ごとにヒットするだけなので、これらのファイルを要求する多数の人々は大したことではありません)。
- このメディア ファイル チャンクに長いキャッシュ時間が与えられた場合、メディアがキャッシュされたままの場合、DVR サービスを強制終了しても問題になるでしょうか?
あなたが提供できる洞察をありがとう！