HTTPビデオストリーミング

最終更新: 2022-11-26 21:49:55 +0800 +0800
tags: Http | Streaming | Video
原文は英語で書かれています。あなたはAI翻訳版を読んでいます。

HTTPによるビデオ配信は、シーク可能な単一ファイルから、短いメディアセグメントの適応型シーケンスまで多岐にわたります。HTTPは表現とバリデーターを転送し、コンテナは時間付きトラックを編成し、コーデックは音声および映像のサンプルをエンコードします。これらのレイヤーを分離すると、レンジ処理、キャッシュ、再生失敗の診断が容易になります。

プログレッシブダウンロード #

ブラウザーは、自己完結型のメディアファイルを <video> 要素で再生できます。通常の GET を開始することも、バイトレンジだけを要求することもあります。

http 
GET /media/talk.mp4 HTTP/1.1
Host: media.example
Range: bytes=0-

選択された表現がレンジをサポートしている場合、サーバーは 206 Partial Content、選択された区間、および表現全体の長さを返します。

http 
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: video/mp4
Content-Range: bytes 0-1048575/73400320
Content-Length: 1048576
ETag: "talk-v3"

満たすことのできる単一レンジには、Content-Range で記述されたバイトだけを正確に含める必要があります。満たすことのできないレンジには、Content-Range: bytes */73400320 とともに 416 Range Not Satisfiable を返します。Range を無視するサーバーは、200 OK とともに表現全体を返せますが、完全なボディを部分レスポンスとして示してはなりません。

バリデーターとキャッシュの再検証 #

レンジは、1つの表現バージョンに適用されます。強い ETag または Last-Modified を送信し、クライアントが再開またはシーク時に If-Range を使用できるようにします。

http 
Range: bytes=32243712-32955076
If-Range: "talk-v3"

バリデーターが依然として一致する場合、サーバーは要求されたレンジを返せます。それ以外の場合は現在の表現全体を返し、2つのエンコードに由来するバイトが結合されるのを防ぎます。通常の条件付きリクエストでは If-None-Match または If-Modified-Since を使用し、304 Not Modified を受け取ることがあります。変更可能性に応じて Cache-Control を定義します。コンテンツアドレス指定されたセグメントは不変にできる一方、ライブコンテンツのマニフェストには短い鮮度期間が必要です。

コーデック、コンテナ、ファイル、ストリーム #

H.264、AV1、AAC、Opusなどのコーデックは、サンプルデータを変換します。ISO Base Media File FormatやWebMなどのコンテナは、1つ以上のエンコード済みトラック、タイムスタンプ、インデックス、メタデータを格納します。1つのファイルに複数のコーデックを含めることができ、同じコーデックが複数のコンテナに現れることもあります。

レンジで配信される有限のMP4ファイルは、ダウンロード完了前に再生が始まる場合でも、プログレッシブダウンロードです。ライブソースはキャプチャ時点では連続していますが、HTTP配信では、移動するマニフェストやメディアセグメントなどの有限リソースとして公開されます。プログレッシブMP4では、クライアントがメディアバイトより先に取得できる位置に初期化メタデータとインデックスメタデータを配置します。一般的には、moov メタデータを先頭付近へ移動するファストスタート処理を使用します。

HLSとDASH #

HTTP Live Streaming（HLS）は、メディアプレイリストとマルチバリアントプレイリストを使用します。MPEG-DASHはMedia Presentation Descriptionを使用します。どちらも、レンディションとアドレス指定可能なメディアセグメントを記述します。プレーヤーはスループットとバッファーの健全性を推定し、コーデック、寸法、ビットレート、デバイス能力が現在の条件に適合するレンディションを選択します。

レンディション間でセグメント境界を揃える必要があります。そうすることで、切り替え時にタイムラインを維持できます。短いセグメントはライブ遅延を削減できますが、リクエスト、マニフェスト、CDNのオーバーヘッドを増加させます。低遅延モードでは、より短い部分セグメントと、オリジンからプレーヤーまでのタイミングに関する厳しい要件が追加されますが、どちらのプロトコルもエンコーダーおよびプレーヤーのバッファリングをなくすものではありません。

CDNは、マニフェストとセグメントを通常のHTTPリソースとしてキャッシュします。バージョン付きのセグメントURL、正しい Content-Type、バリデーター、キャッシュディレクティブを使用します。意図せずキャッシュキーを分割するCookieやクエリ文字列は避けます。ライブプレイリストは、新しいセグメントを認識できるほど速く期限切れにする必要があります。一方、完了したビデオオンデマンドセグメントには、長い不変期間を設定できます。

プリロード、シーク可能性、遅延 #

HTMLの preload 属性はヒントです。値には none、metadata、auto があります。ユーザー設定、省データポリシー、自動再生ルール、実装上の判断によって上書きされることがあります。アプリケーションは、preload="auto" によってファイル全体がダウンロードされると仮定してはなりません。

シークには、再生時間をアクセス可能なバイトまたはセグメントへ対応付ける仕組みが必要です。コンテナのインデックスは、ファイルのレンジベースのシークを可能にします。HLSまたはDASHのタイムラインは、対応するセグメントを識別します。ライブウィンドウでは古いセグメントが破棄されることがあるため、広告されたウィンドウの外へのシークは失敗するか、利用可能な最も早い位置へ移動する必要があります。

起動遅延には、マニフェストまたはメタデータの取得、接続確立、初期セグメントの転送、デコード、プレーヤーの安全バッファーが含まれます。エンドツーエンドのライブ遅延には、キャプチャ、エンコード、パッケージング、CDN伝播、再生バッファリングも含まれます。すべての遅延をネットワーク帯域幅に帰するのではなく、各段階を測定します。

サーバーチェックリスト #

  • プログレッシブファイルについて、HEAD、完全な GET、有効な単一またはマルチパートのバイトレンジ、および 416 レスポンスを一貫してサポートする。
  • ノード間で表現のバリデーターを保持し、正確な Content-Length、Content-Range、メディアの Content-Type 値を返す。
  • すべてのレンジおよびセグメントリクエストを認可する。キャッシュされた部分レスポンスによって、完全なオブジェクトに対するアクセスーポリシーが迂回されてはならない。
  • 冒頭および末尾付近のシーク、同時レンジ、古い If-Range、CDNキャッシュヒット、帯域幅の変化、ライブ再生中のマニフェスト更新をテストする。

1つの表現と通常のシークで要件を満たせる場合は、プログレッシブファイルを使用します。クライアントに適応ビットレート、ライブ公開、複数のレンディション、またはセグメント指向のCDNワークフローが必要な場合は、HLSまたはDASHを使用します。

参考資料 #

コメント

GitHub で閲覧・コメントする（投稿にはログインが必要です）