何年もの間、インターネット・ストリーミングには、RTMPのようなサーバーベースの独自技術と、プログレッシブ・ダウンロードという2つの基本モデルがあった。サーバーベースのストリーミングは、オンデマンドで切り替え可能なマルチビットレート・ストリームを配信できるが、高価なソフトウェアのライセンスが必要だ。プログレッシブ・ダウンロードはApache上で可能だが、ビットレートを切り替えるには再生を停止する必要がある。
HLSやSmooth StreamingのようなHTTPベースのストリーミング・プロトコルの登場は、Apacheのようなコモディティ・サーバー・テクノロジーを使って、標準的なHTTP接続でストリーミング配信が可能になることを意味した。シームレスなビットレートの切り替えは一般的になり、CDN経由の配信は、HTTP経由であらゆるファイルを配信するのと基本的に同じであったため、簡単だった。HTTPストリーミングは、ストリーミングメディアの配信に革命をもたらし、高品質のストリーミングのコストと複雑さを大幅に削減しました。
動画プラットフォームを設計する際には、考慮すべきことが無数にあります。しかし、最も重要で見過ごされがちな決定事項の 1 つは、HTTP ベースのマニフェスト ファイルをどのように扱うかです。
静的マニフェスト・ファイル
物理的な世界では、ビデオを購入するとき、パッケージを見て、箱を手に取り、レジに向かい、レジで支払いを済ませ、家に帰り、プレーヤーに挿入する。
ほとんどのビデオプラットフォームは、かなり似たような構造になっています。基本的に、メタデータのグループ（ボックス）は、再生可能なメディアアイテム（ビデオ）に関連付けられます。ほとんどの動画プラットフォームは、メタデータを単一の mp4 動画に接続する単一の URL という概念から始まります。動画プラットフォームがより複雑になると、複数のビットレート、解像度、またはプレビューや特別な機能など、メインアイテムに関連する他のメディアを表すメタデータに接続された複数のURLが存在する可能性があります。
物理モデルを、HLS のような HTTP ベースのストリーミング プロトコルを含むオンライン ストリーミングの世界に拡張しようとすると、事態はより複雑になります。HLS は、マニフェストと呼ばれるテキスト ファイルによってリンクされた、動画ファイルの多くのフラグメントに基づいています。HLS を実装する場合、最も簡単な方法は、マニフェスト、つまり m3u8 ファイルにリンクする URL を追加することです。これは非常に簡単で、基本的に既存のモデルに適合するという利点があります。
欠点は、HLS が静的なメディアアイテムとは似て非なるものであることだ。例えば、MP4 は DVD のビデオトラックのようなもので、単一の解像度とビットレートの単一のビデオです。HLS マニフェストは、おそらく複数のビットレート、解像度、断片化された何千もの動画から構成されています。HLS は MP4 よりもはるかに多くのことができるのに、なぜ同じように扱うのでしょうか？
HLSプレイリスト
HLS のプレイリストには、ストリームの基本的な要素を記述するメタデータと、動画の断片へのリンクの並びが含まれる。動画の各フラグメント（セグメント）をダウンロードし、それらを順番に再生することで、ユーザは単一の連続した動画のように見えるものを見ることができる。
- EXTM3U
- #EXT-X-PLAYLIST-TYPE:VOD
- #EXT-X-TARGETDURATION:10
- #EXTINF:10、
- ファイル-0001.ts
- #EXTINF:10、
- ファイル-0002.ts
- #EXTINF:10、
- ファイル0003.ts
- #EXTINF:10、
- ファイル0003.ts
- #EXT-X-ENDLIST
上記は基本的なm3u8プレイリストです。これは 4 つの動画セグメントにリンクしています。このデータをプログラムで生成するために必要なのは、最初のアイテムのファイル名、セグメントの目標持続時間 (この場合は 10) 、そしてセグメントの総数です。
HLSマニフェスト
HLS マニフェストは、プレイリストへのリンクの並び順のないシリーズです。複数のプレイリストを持つ理由は 2 つあります：さまざまなビットレートを提供するためと、プレイリストのバックアップのためです。以下は典型的なプレイリストで、.m3u8 のそれぞれが別の HLS プレイリストへの相対リンクになっています。
- #EXTM3U
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2040000
- ファイル-2040k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1540000
- ファイル-1540k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1040000
- ファイル-1040k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=640000
- ファイル-640k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=440000
- ファイル-440k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=240000
- ファイル-240k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=64000
- ファイル-64k.m3u8
プレイリストは、ネットワークの状態に関係なくスムーズな再生を提供するために、さまざまなビットレートと解像度を持ちます。マニフェストを生成するために必要なのは、各プレイリストのビットレートとそれらの相対パスだけです。
空白を埋める
動画コーデック、音声コーデック、コンテナ、総ビットレートなど、オンライン動画プラットフォームがエンコードされた動画アセットごとに取得すべき重要な情報は他にもたくさんある。1つの動画アイテムに保存されるデータは、視聴者にとって意味のあるもの（説明、評価、キャスト）、プラットフォームにとって意味のあるもの（視聴時間、視聴回数、エンゲージメント）、アプリケーションにとって意味のあるもの（フォーマット、解像度、ビットレート）でなければなりません。このデータがあれば、視聴者は何を見るかを決め、システムはどのようにプログラムするかを決め、アプリケーションはどのように再生するかを決めることができる。
プレイリスト、マニフェスト、および各プレイリストのコーデック情報をプログラムで生成するために必要なデータをキャプチャすることにより、マニフェストとプレイリストがリクエストごとに生成されるシステムを持つことが可能になります。
例 - 最初のプレイリスト
HLS の仕様では、マニフェストで最初に来るプレイリストのどれが最初に再生されるかを決定します。前のセクションの例では、リストの最初の項目は、最高品質のトラックでもありました。高速で安定したインターネット接続を持つユーザーにとっては問題ありませんが、低速の接続を持つユーザーにとっては、再生開始までに時間がかかります。
デバイスが良好なインターネット接続を持っているように見えるかどうかを判断し、それに応じてプレイリストをカスタマイズする方が良いでしょう。幸運なことに、ダイナミック・マニフェスト生成によって、システムはまさにそれを達成するように設定されている。
この演習では、マニフェストのリクエストがビットレートの順序付き配列で行われると仮定します。たとえば、[2040,1540,1040,640,440,240,64] というリクエストは、前のセクションのものと同じプレイリストを返します。iOSでは、ユーザーがWiFi接続かセルラー接続かを判断することができる。ビットレート、解像度、その他のパラメータを含む各プレイリストに関するデータが取得されているため、アプリはマニフェストの順序をインテリジェントに決定することができます。
例えば、ユーザーがWiFiを使用している場合は800-1200kbpsの間、セルラー接続の場合は200-600kbpsの間で開始するのがベストだと判断されるかもしれない。ユーザーが無線LANを利用している場合、アプリは以下のような配列をリクエストする：[1040,2040,1540,640,440,240,64].アプリがセルラー接続のみを検出した場合は、[440,2040,1540,1040,640,240,64]を要求する。
例 - レガシー・デバイス
Androidでは、動画サポートはちょっとしたブラックボックスだ。何年もの間、Android の公式ドキュメントでは、640×480 のベースライン h.264 mp4 ビデオの使用しかサポートしていなかった。HLSの場合、サポートはさらに断片的で、理解するのが難しい。
幸運なことに、Androidは一握りの主要なデバイスによって支配されている。ダイナミック・マニフェストを使えば、アプリはどのプレイリストから始めるのがベストかをターゲットにできるだけでなく、互換性がないと判断されたプレイリストを除外することもできる。
メディアアイテムは解像度やコーデック情報などのデータも取得しているため、特定のデバイスをターゲットにしたサポートも可能だ。アプリは、すべてのレンディションを送信することを決定することができます：[2040,1540,1040,640,440,240,64].あるいは、720pまでしかサポートしていない古いデバイスは、最も高いレンディションを削除することができます：[1540,1040,640,440,240,64].さらに、モバイルデバイスの世界を超えて、アプリがコネクテッドTVであれば、最低画質のレンディションを削除することができる：[2040,1540,1040,640].
動的または静的
静的マニフェストモデルを選択することはまったく問題ありません。ある程度の柔軟性は失われますが、シンプルであることに問題はありません。多くのユースケース、特にユーザー生成コンテンツの世界では、動的生成に伴う複雑さを必要としません。しかし、動的マニフェスト生成は、積極的に取り組もうとするユーザーにとって多くの扉を開くものです。
マニフェストをどのように扱うかは、動画プラットフォームの長期的な柔軟性に大きな影響を与えるため、専属の圧縮担当者と話し合う必要があります。
