JP6657313B2 - ソースビデオストリームからビデオの一組の代替ストリームをエンコードする方法 - Google Patents

Description

本発明は、概して、適応型ストリーミングに関し、より具体的には、ハイパーテキスト転送プロトコルを使用して、Ｍａｔｒｏｓｋａコンテナファイル内に含有されるエンコードされたメディアの適応型ビットレートストリーミングに関する。

メディアのストリーミングという用語は、再生デバイス上におけるメディアの再生を説明しており、メディアは、サーバ上に記憶され、再生の間、ネットワークを経由して、再生デバイスに継続的に送信される。一般的には、再生デバイスは、メディアの次の部分の受信に先立って、全バッファリングされたメディアの再生を完了するため、再生デバイスは、再生の間、任意の所与の時間において、十分な量のメディアをバッファ内に記憶し、再生の途絶を防止する。適応型ビットレートストリーミングまたは適応型ストリーミングは、このストリーミング状態（例えば、ユーザのネットワーク帯域幅およびＣＰＵ容量）をリアルタイムで検出し、適宜、ストリーミングされるメディアの質を調節することを含む。一般的には、ソースメディアは、複数のビットレートでエンコードされ、再生デバイスまたはクライアントは、利用可能なリソースに応じて、異なるエンコーディングのストリーミング間で切り替える。

適応型ストリーミングソリューションは、一般的には、ＲＦＣ２６１６として、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ ＦｏｒｃｅおよびＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍによって公開されたハイパーテキスト転送プロトコル（ＨＴＴＰ）、またはＲＦＣ２３２６として、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅによって公開されたリアルタイムストリーミングプロトコル（ＲＴＳＰ）のいずれかを利用して、サーバと再生デバイスとの間でメディアをストリーミングする。ＨＴＴＰは、再生デバイスが、ファイル内のバイト範囲を要求することを可能にする、ステートレスプロトコルである。ＨＴＴＰは、サーバが、再生デバイスから受信された要求に応答するために、情報を要求する再生デバイスの状態または再生デバイスによって要求されたバイト範囲に関する情報を記録することが要求されないため、ステートレスとして説明される。ＲＴＳＰは、ストリーミングメディアサーバを制御するために使用されるネットワーク制御プロトコルである。再生デバイスは、メディアをストリーミングするサーバに、「再生」および「一時停止」等の制御コマンドを発行し、メディアファイルの再生を制御する。ＲＴＳＰが利用されるとき、メディアサーバは、各クライアントデバイスの状態を記録し、クライアントデバイスから受信した命令およびクライアントの状態に基づいて、ストリーミングするためのメディアを決定する。

適応型ストリーミングシステムでは、ソースメディアは、一般的には、実際のビデオおよびオーディオデータを含有する、いくつかの代替ストリームをポイントするトップレベルインデックスファイルとして、メディアサーバ上に記憶される。各ストリームは、一般的には、１つ以上のコンテナファイル内に記憶される。異なる適応型ストリーミングソリューションは、一般的には、異なるインデックスおよびメディアコンテナを利用する。Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍによって開発された同期マルチメディア統合言語（ＳＭＩＬ）は、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ（Ｒｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎ）によって開発されたＩＩＳスムーズストリーミング、およびＡｄｏｂｅ Ｓｙｓｔｅｍｓ Ｉｎｃｏｒｐｏｒａｔｅｄ（Ｓａｎ Ｊｏｓｅ，Ｃａｌｉｆｏｒｎｉａ）によって開発されたフラッシュダイナミックストリーミングを含む、いくつかの適応型ストリーミングソリューションにおいて、インデックスを作成するために利用される。Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒ Ｉｎｃｏｒｐｏｒａｔｅｄ（Ｃｕｐｅｒｔｉｎｏ，Ｃａｌｉｆｏｒｎｉａ）によって開発されたＨＴＴＰ適応型ビットレートストリーミングは、一般的には、メディアコンテナファイルを識別する、ＵＲＩのリストを含有するテキストファイルである、拡張Ｍ３Ｕ再生ファイル（．Ｍ３Ｕ８）を使用して、インデックスファイルを実装する。最も一般に使用されるメディアコンテナ形式は、ＭＰＥＧ−４ Ｐａｒｔ １４（すなわち、ＩＳＯ／ＩＥＣ １４４９６−１４）に指定されるＭＰ４コンテナ形式、およびＭＰＥＧ−２ Ｐａｒｔ １（すなわち、ＩＳＯ／ＩＥＣ規格１３８１８−１）に指定されるＭＰＥＧトランスポートストリーム（ＴＳ）コンテナである。ＭＰ４コンテナ形式は、ＩＩＳスムーズストリーミングおよびフラッシュダイナミックストリーミングにおいて利用される。ＴＳコンテナは、ＨＴＴＰ適応型ビットレートストリーミングにおいて使用される。

Ｍａｔｒｏｓｋａコンテナは、Ｍａｔｒｏｓｋａ非営利組織（Ａｕｓｓｏｎｎｅ，Ｆｒａｎｃｅ）によって、オープン標準プロジェクトとして開発されたメディアコンテナである。Ｍａｔｒｏｓｋａコンテナは、拡張可能マークアップ言語（ＸＭＬ）のバイナリ派生版である拡張可能バイナリメタ言語（ＥＢＭＬ）に基づく。Ｍａｔｒｏｓｋａコンテナのデコーディングは、多くの消費者電子機器（ＣＥ）デバイスによって対応されている。ＤｉｖＸ，ＬＬＣ（Ｓａｎ Ｄｉｅｇｏ，Ｃａｌｉｆｏｒｎｉａ）によって開発されたＤｉｖＸ Ｐｌｕｓファイル形式は、Ｍａｔｒｏｓｋａコンテナ形式（すなわち、Ｍａｔｒｏｓｋａコンテナ形式に基づくが、Ｍａｔｒｏｓｋａ形式内に指定されない要素を含む）の拡張機能を利用する。

本発明の実施形態による、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を利用するＭａｔｒｏｓｋａコンテナファイル内に記憶されるメディアの適応型ビットレートストリーミングのためのシステムおよび方法が開示される。一実施形態では、プロセッサは、クライアントアプリケーションを介して、ファイルの部分を遠隔サーバから要求するように構成される。加えて、クライアントアプリケーションはさらに、複数のＥＢＭＬコンテナファイルを識別し、ＥＢＭＬコンテナファイル内に含有される代替ストリームの少なくとも最大のビットレートを記述する、トップレベルインデックスデータを読み出し、トップレベルインデックスデータを解析し、複数のＥＢＭＬコンテナファイルを識別する情報を取得し、ＥＢＭＬコンテナファイル内に含有されるストリームのエンコーディングパラメータを指定する少なくとも１つの要素を含有する、ＥＢＭＬコンテナファイルのうちの少なくとも１つの部分を要求し、ＥＢＭＬコンテナファイルのうちの少なくとも１つ内のエンコードされたビデオの部分を含有する各要素を参照する、インデックスを読み出し、インデックスを利用して、エンコードされたビデオの部分を含有する要素を含む、第１のＥＢＭＬコンテナファイルの部分を要求し、要求された要素を受信およびバッファリングし、エンコーディングパラメータを利用して、バッファリングされた要素内に含有されるエンコードされたビデオをデコードし、現在のストリーミング状態を測定し、測定されたストリーミング状態およびトップレベルデータ内に含有される代替ストリームのビットレートの記述に基づいて、デコーディングのために、エンコードされたビデオの部分を含有する要素を読み出すべきＥＢＭＬコンテナファイルの別の１つを選択するように、プロセッサを構成する。

さらなる実施形態は、複数のＥＢＭＬコンテナファイルのそれぞれを識別し、ＥＢＭＬコンテナファイル内に含有される代替ストリームのそれぞれの少なくとも最大のビットレートを記述するトップレベルインデックスデータを読み出すステップと、トップレベルインデックスデータを解析し、複数のＥＢＭＬコンテナファイルを識別する情報を取得するステップと、ＥＢＭＬコンテナファイル内に含有されるストリームのエンコーディングパラメータを指定する、少なくとも１つの要素を含有する、ＥＢＭＬコンテナファイルのうちの少なくとも１つの部分を要求するステップと、ＥＢＭＬコンテナファイルのうちの少なくとも１つ内の各エンコードされたビデオの部分を含有する要素を参照する、インデックスを受信するステップと、インデックスを利用して、エンコードされたビデオの部分を含有する要素を含む、第１のＥＢＭＬコンテナファイルの部分を要求するステップと、要求された要素を受信およびバッファリングするステップと、エンコーディングパラメータを使用して、バッファリングされた要素内に含有されるエンコードされたビデオをデコードするステップと、現在のストリーミング状態を測定するステップと、デコーディングのために、エンコードされたビデオの部分を含有する要素を受信するべきＥＢＭＬコンテナファイルの別の１つを選択するステップであって、選択は、測定されたストリーミング状態およびトップレベルインデックスデータ内に含有される代替ストリームのビットレートの記述に基づく、ステップとを含む。

本発明の別の実施形態は、ソースエンコーディングアプリケーションを介して、ソースビデオを含有する少なくとも１つのマルチメディアファイルを取り込むように構成される、プロセッサを含む。加えて、ソースエンコーディングアプリケーションはさらに、ソースビデオの部分を選択し、ソースビデオの選択された部分をエンコードされたビデオの複数の代替部分にトランスコードし、各代替部分は、異なる一組のエンコーディングパラメータを使用してエンコードされ、クローズドピクチャ群（ＧＯＰ）を始めるイントラフレームで開始し、エンコードされたビデオの代替部分のそれぞれを異なるＥＢＭＬコンテナファイルの要素に書き込み、各要素は、エンコードされたビデオの代替部分をエンコードするために使用されるエンコーディングパラメータを示す、別の要素もまた含む、ＥＢＭＬコンテナファイル内に位置し、あるエントリを、ＥＢＭＬコンテナファイルのそれぞれ内のエンコードされたビデオの代替部分のうちの１つを含有する要素の場所を識別する、少なくとも１つのインデックスに追加するように、プロセッサを構成する。

別のさらなる実施形態は、ソースエンコーダを使用して、ソースビデオの部分を繰り返し選択するステップと、ソースエンコーダを使用して、ソースビデオの選択された部分をエンコードされたビデオの複数の代替部分にトランスコードするステップであって、各代替部分は、異なる一組のエンコーディングパラメータを使用して、エンコードされ、クローズドピクチャ群（ＧＯＰ）を始めるイントラフレームで開始する、ステップと、ソースエンコーダを使用して、エンコードされたビデオの代替部分のそれぞれを異なるＥＢＭＬコンテナファイルの要素に書き込むステップであって、各要素は、ビデオの部分をエンコードするために使用されるエンコーディングパラメータに対応する一組のエンコーディングパラメータを含有する別の要素もまた含む、ＥＢＭＬコンテナファイル内に位置する、ステップと、あるエントリを、ＥＢＭＬコンテナファイルのそれぞれ内のエンコードされたビデオの代替部分のうちの１つを含有する要素の場所を識別する、なくとも１つのインデックスに追加するステップとを含む。
本発明は、例えば、以下を提供する。
（項目１）
拡張可能バイナリマークアップ言語（ＥＢＭＬ）コンテナファイル内にパッケージ化されたエンコードされたビデオの複数の代替ストリームを使用して、適応型ビットレートストリーミングを行うように構成される再生デバイスであって、該複数の代替ストリームの各々は、ＥＢＭＬコンテナファイルの要素中へパックされたエンコードされたビデオの各部分が、クローズドピクチャ群（ＧＯＰ）を始めるイントラフレームで開始し、該ＥＢＭＬコンテナファイルの各々は、該ＥＢＭＬコンテナファイル内に含有されるストリームのエンコーディングパラメータを指定する少なくとも１つの要素を含むように、異なる該エンコーディングパラメータを使用してエンコードされた同一のソースビデオであり、
該再生デバイスは、
クライアントアプリケーションを介して、ファイルの部分を遠隔サーバから要求するように構成されるプロセッサを備え、
該クライアントアプリケーションは、
複数のＥＢＭＬコンテナファイルを識別し、該ＥＢＭＬコンテナファイル内に含有される該代替ストリームの少なくとも最大のビットレートを記述するトップレベルインデックスデータを読み出すことと、
該トップレベルインデックスデータを解析して、該複数のＥＢＭＬコンテナファイルを識別する情報を取得することと、
該ＥＢＭＬコンテナファイル内に含有される該ストリームの該エンコーディングパラメータを指定する該少なくとも１つの要素を含有する該ＥＢＭＬコンテナファイルのうちの少なくとも１つの部分を要求することと、
該ＥＢＭＬコンテナファイルのうちの少なくとも１つ内のエンコードされたビデオの部分を含有する各要素を参照するインデックスを読み出すことと、
該インデックスを利用して、エンコードされたビデオの部分を含有する要素を含む第１のＥＢＭＬコンテナファイルの部分を要求することと、
該要求された要素を受信およびバッファリングすることと、
該エンコーディングパラメータを利用して、該バッファリングされた要素内に含有された該エンコードされたビデオをデコードすることと、
現在のストリーミング状態を測定することと、
デコーディングのために、エンコードされたビデオの部分を含有する要素を読み出すべき該ＥＢＭＬコンテナファイルの別の１つを選択することであって、該選択は、該測定されたストリーミング状態および該トップレベルデータ内に含有される該代替ストリームのビットレートの記述に基づく、ことと
を行うように該プロセッサをさらに構成する、再生デバイス。
（項目２）
前記ＥＢＭＬコンテナファイルの各々は、複数のＣｌｕｓｔｅｒ要素を備え、各Ｃｌｕｓｔｅｒ要素は、前記エンコードされたビデオの部分を含有し、
該Ｃｌｕｓｔｅｒ要素の各々の中の該エンコードされたビデオの部分は、イントラフレームで開始し、少なくとも１つのクローズドピクチャ群を含む、項目１に記載の再生デバイス。
（項目３）
前記Ｃｌｕｓｔｅｒ要素の各々の中の前記エンコードされたビデオの部分は、同一の持続時間を有する、項目２に記載の再生デバイス。
（項目４）
前記Ｃｌｕｓｔｅｒ要素の各々の中の前記エンコードされたビデオの部分は、２秒の持続時間を有する、項目２に記載の再生デバイス。
（項目５）
各Ｃｌｕｓｔｅｒ要素は、タイムコードを含有し、該Ｃｌｕｓｔｅｒ要素内に含有される前記エンコードされたビデオの部分の各エンコードされたフレームは、別個のＢｌｏｃｋＧｒｏｕｐ要素内に含有される、項目２に記載の再生デバイス。
（項目６）
前記Ｃｌｕｓｔｅｒ要素中の第１のＢｌｏｃｋＧｒｏｕｐ要素は、前記イントラフレームを含有する、項目５に記載の再生デバイス。
（項目７）
前記第１のＢｌｏｃｋＧｒｏｕｐ要素は、前記Ｃｌｕｓｔｅｒ要素のタイムコードに関して前記イントラフレームのタイムコード属性を指定するＢｌｏｃｋ要素を含有する、項目６に記載の再生デバイス。
（項目８）
前記エンコードされたビデオの代替ストリームの各々は、異なる最大ビットレートでエンコードされる、項目１に記載の再生デバイス。
（項目９）
前記エンコードされたビデオの代替ストリームのうちの少なくとも２つは、同一の表示アスペクト比においてであるが、異なるサンプルアスペクト比を使用する異なる解像度を用いてエンコードされる、項目８に記載の再生デバイス。
（項目１０）
前記ＥＢＭＬコンテナファイル内に含有されるストリームの前記エンコーディングパラメータを指定する該ＥＢＭＬコンテナファイルの各々の中の少なくとも１つの要素は、該ＥＢＭＬコンテナファイル内に含有される前記ビデオストリームのフレーム高さ、フレーム幅、およびサンプルアスペクト比を指定する、項目９に記載の再生デバイス。
（項目１１）
前記クライアントアプリケーションは、前記ＥＢＭＬコンテナファイルのうちの１つからバッファリングされた要素内に含有されるエンコードされたビデオのデコーディングの開始に先立って、前記フレーム高さ、フレーム幅、およびサンプルアスペクト比を設定するように前記プロセッサを構成する、項目１０に記載の再生デバイス。
（項目１２）
前記エンコードされたビデオの代替ストリームのうちの少なくとも２つは、異なるフレームレートでエンコードされる、項目８に記載の再生デバイス。
（項目１３）
前記ＥＢＭＬコンテナファイル内に含有されるストリームの前記エンコーディングパラメータを指定する該ＥＢＭＬコンテナファイルの各々の中の少なくとも１つの要素は、該ＥＢＭＬコンテナファイル内に含有されるビデオストリームのフレームレートを指定する、項目１２に記載の再生デバイス。
（項目１４）
前記クライアントアプリケーションは、前記ＥＢＭＬコンテナファイルのうちの１つからバッファリングされた要素内に含有される前記エンコードされたビデオのデコーディングの開始に先立って、前記フレームレートを設定するように前記プロセッサを構成する、項目１３に記載の再生デバイス。
（項目１５）
前記クライアントアプリケーションは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）バイト範囲要求を介して、遠隔サーバから、ファイルの部分を要求するように前記再生デバイスを構成する、項目１１に記載の再生デバイス。
（項目１６）
前記トップレベルインデックスデータは、ＳＭＩＬデータであり、前記複数のＥＢＭＬコンテナファイルを識別する情報は、該ＥＢＭＬコンテナファイルの各々の場所を識別する複数の汎用リソースインジケータ（ＵＲＩ）である、項目１に記載の再生デバイス。
（項目１７）
前記ＳＭＩＬデータは、前記ＵＲＩの各々によって識別される前記ＥＢＭＬコンテナファイル内に含有されるエンコードされたストリームの最大ビットレートを指定する、項目１に記載の再生デバイス。
（項目１８）
前記ＥＢＭＬコンテナファイル内の前記エンコードされたストリームの部分を含有する要素の各々を参照するインデックスは、該ＥＢＭＬコンテナファイルの少なくとも１つの要素内に位置し、
前記ＳＭＩＬファイルは、前記エンコーディングパラメータを含有する要素を含有する該ＥＢＭＬコンテナファイルの部分を指定し、
前記クライアントアプリケーションは、
該ＳＭＩＬファイルを解析して、該エンコーディングパラメータを含有する要素を含有する該ＥＢＭＬコンテナファイルの部分を識別することと、
該エンコーディングパラメータを含有する要素を含有する該ＥＢＭＬコンテナファイルの部分を要求することと
を行うように前記プロセッサを構成する、項目１７に記載の再生デバイス。
（項目１９）
各ＥＢＭＬコンテナファイルは、該ＥＢＭＬコンテナファイル内の前記エンコードされたビデオの部分を含有する各要素を参照するインデックスを含有する少なくとも１つの要素を含み、
前記クライアントアプリケーションは、該インデックスを含有する少なくとも１つの要素を含む該ＥＢＭＬコンテナファイルの部分を要求することによって、該ＥＢＭＬコンテナファイル内のエンコードされたビデオの部分を含有する各要素を参照するインデックスを読み出すように前記プロセッサを構成する、項目１に記載の再生デバイス。
（項目２０）
前記インデックスは、前記ＥＢＭＬコンテナファイル内のＣｕｅ要素内に位置する、項目１９に記載の再生デバイス。
（項目２１）
前記Ｃｕｅ要素は、時間属性を含み、前記ＥＢＭＬファイル内のエンコードされたビデオの部分を含有する各要素の場所を指し示す複数のＣｕｅＰｏｉｎｔ要素を含む、項目２０に記載の再生デバイス。
（項目２２）
前記クライアントアプリケーションは、
前記インデックス内の前記ＣｕｅＰｏｉｎｔ要素の時間属性を使用して、前記ＥＢＭＬファイル内のエンコードされたビデオの特定の部分を含有する要素の場所を検索することと、
該ＣｕｅＰｏｉｎｔ要素を使用して識別された少なくとも該要素を含む該ＥＢＭＬファイルの部分を要求することと
を行うように前記プロセッサを構成する、項目２１に記載の再生デバイス。
（項目２３）
前記エンコードされたビデオをデコードするために利用される前記エンコーディングパラメータは、フレームレート、フレーム高さ、フレーム幅、サンプルアスペクト比、最大ビットレート、および最小バッファサイズから成る群から選択される少なくとも１つのエンコーディングパラメータを含む、項目１に記載の再生デバイス。
（項目２４）
前記クライアントアプリケーションは、前記要素が要求された時間から、要求された要素を受信するためにかかった時間を測定することによって、現在のストリーミング状態を測定するように前記プロセッサを構成する、項目１に記載の再生デバイス。
（項目２５）
前記クライアントアプリケーションは、最初に、第１のＥＢＭＬコンテナファイル内に含有されるストリームの前記エンコーディングパラメータを指定する少なくとも１つの要素を含有する該第１のＥＢＭＬコンテナファイルの部分を要求するように前記プロセッサを構成し、
該クライアントアプリケーションは、該クライアントアプリケーションが前記測定されたストリーミング状態および前記トップレベルインデックス内に含有される前記代替ストリームのビットレートの記述に基づいて第２のＥＢＭＬコンテナファイルからデコードするために、エンコードされたビデオの部分を含有する要素を読み出すことを選択するとき、該第２のＥＢＭＬコンテナファイル内に含有されるストリームのエンコーディングパラメータを指定する少なくとも１つの要素を含有する該第２のＥＢＭＬコンテナファイルの部分を要求するように前記プロセッサをさらに構成する、項目１に記載の再生デバイス。
（項目２６）
前記再生デバイスは、トリックプレイトラックを含有するＥＢＭＬコンテナファイルを使用して、適応型ビットレートストリーミングを行うようにさらに構成される、項目１に記載の再生デバイス。
（項目２７）
前記クライアントアプリケーションは、ユーザ命令に応答してエンコードされたビデオの部分を含有する要素を読み出すべき前記ＥＢＭＬコンテナファイルとして、前記トリックプレイトラックを含有する該ＥＢＭＬコンテナファイルを選択するように前記プロセッサを構成する、項目２６に記載の再生デバイス。
（項目２８）
前記再生デバイスは、エンコードされたオーディオのトラックを含有する少なくとも１つのＥＢＭＬコンテナファイルを使用して、適応型ストリーミングを行うようにさらに構成される、項目１に記載の再生デバイス。
（項目２９）
前記クライアントアプリケーションは、エンコードされたオーディオをオーディオトラックを含有する前記少なくとも１つのＥＢＭＬコンテナファイルのうちの１つから読み出し、デコードし、該デコードされたオーディオを前記デコードされたビデオと同期させるように前記プロセッサを構成する、項目２８に記載の再生デバイス。
（項目３０）
前記ＥＢＭＬコンテナファイルの各々は、前記エンコードされたビデオで多重化された少なくとも１つのエンコードされたオーディオのトラックを含有する要素を含む、項目１に記載の再生デバイス。
（項目３１）
前記クライアントアプリケーションは、
前記エンコードされたオーディオのトラックのうちの１つの部分を含む要素を含有する前記ＥＢＭＬファイルの部分を読み出すことと、
該読み出され、エンコードされたオーディオをデコードすることと、
該デコードされたオーディオと前記デコードされたビデオとを同期させることと
を行うように構成される、項目２８に記載の再生デバイス。
（項目３２）
前記再生デバイスは、字幕トラックを含有する少なくとも１つのＥＢＭＬコンテナファイルを使用して、適応型ストリーミングを行うようにさらに構成される、項目１に記載の再生デバイス。
（項目３３）
前記クライアントアプリケーションは、
字幕を字幕トラックを含有する前記少なくとも１つのＥＢＭＬコンテナファイルのうちの１つから読み出すことと、
該字幕を前記デコードされたビデオと同期させることと、
該字幕を該デコードされたビデオ上にオーバレイすることと
を行うように前記プロセッサを構成する、項目３２に記載の再生デバイス。
（項目３４）
前記ＥＢＭＬコンテナファイルの各々は、前記エンコードされたビデオで多重化された少なくとも１つの字幕トラックを含有する要素を含む、項目１に記載の再生デバイス。
（項目３５）
前記クライアントアプリケーションは、
前記字幕トラックのうちの１つの部分を含む要素を含有する前記ＥＢＭＬファイルの部分を読み出すことと、
該字幕を前記デコードされたビデオと同期させることと、
該字幕を該デコードされたビデオ上にオーバレイすることと
を行うように構成される、項目３４に記載の再生デバイス。
（項目３６）
拡張可能バイナリマークアップ言語（ＥＢＭＬ）コンテナファイル内にパッケージ化されたエンコードされたビデオの複数の代替ストリームを使用して、再生デバイス上でメディアの適応型ビットレートストリーミングを行う方法であって、該ビデオの代替ストリームの各々は、ＥＢＭＬコンテナファイルの要素中へパックされたエンコードされたビデオの各部分が、クローズドピクチャ群（ＧＯＰ）を始めるイントラフレームで開始し、該ＥＢＭＬコンテナファイルの各々は、該ＥＢＭＬコンテナファイル内に含有されるストリームのエンコーディングパラメータを指定する少なくとも１つの要素を含むように、異なるエンコーディングパラメータを使用してエンコードされた同一のソースビデオであり、
該方法は、
該複数のＥＢＭＬコンテナファイルの各々を識別し、該ＥＢＭＬコンテナファイル内に含有される該代替ストリームの各々の少なくとも最大ビットレートを記述するトップレベルインデックスデータを読み出すことと、
該トップレベルインデックスデータを解析して、該複数のＥＢＭＬコンテナファイルを識別する情報を取得することと、
該ＥＢＭＬコンテナファイル内に含有されるストリームの該エンコーディングパラメータを指定する少なくとも１つの要素を含有する該ＥＢＭＬコンテナファイルのうちの少なくとも１つの部分を要求することと、
該ＥＢＭＬコンテナファイルのうちの少なくとも１つ内のエンコードされたビデオの部分を含有する各要素を参照するインデックスを読み出すことと、
該インデックスを利用して、エンコードされたビデオの部分を含有する要素を含む第１のＥＢＭＬコンテナファイルの部分を要求することと、
該要求された要素を受信およびバッファリングすることと、
該エンコーディングパラメータを使用して、該バッファリングされた要素内に含有される該エンコードされたビデオをデコードすることと、
現在のストリーミング状態を測定することと、
デコーディングのために、エンコードされたビデオの部分を含有する要素を読み出すべき該ＥＢＭＬコンテナファイルの別の１つを選択することであって、該選択は、該測定されたストリーミング状態および該トップレベルインデックスデータ内に含有される該代替ストリームのビットレートの記述に基づいている、ことと
含む、方法。
（項目３７）
コンテナファイル内にパックされる複数の代替ビデオストリームとしてソースビデオをエンコードするように構成されるソースエンコーダであって、該コンテナファイルは、拡張可能バイナリマークアップ言語（ＥＢＭＬ）ファイルであり、
該ソースエンコーダは、
ソースエンコーディングアプリケーションを介して、ソースビデオを含有する少なくとも１つのマルチメディアファイルを取り込むように構成されるプロセッサを備え、
該ソースエンコーディングアプリケーションは、
該ソースビデオの部分を選択することと、
該ソースビデオの該選択された部分をエンコードされたビデオの複数の代替部分にトランスコードすることであって、各代替部分は、異なる一組のエンコーディングパラメータを使用してエンコードされ、クローズドピクチャ群（ＧＯＰ）を始めるイントラフレームで開始する、ことと、
該エンコードされたビデオの代替部分の各々を異なるＥＢＭＬコンテナファイルの要素に書き込むことであって、各要素は、該エンコードされたビデオの代替部分をエンコードするために使用される該エンコーディングパラメータを示す別の要素もまた含むＥＢＭＬコンテナファイル内に位置する、ことと、
あるエントリを該ＥＢＭＬコンテナファイルの各々の中の該エンコードされたビデオの代替部分のうちの１つを含有する要素の場所を識別する少なくとも１つのインデックスに追加することと
を行うように該プロセッサを構成する、ソースエンコーダ。
（項目３８）
前記ソースビデオの選択された部分をトランスコードすることは、該選択された部分を少なくとも１つのクローズドピクチャ群にトランスコードすることをさらに含む、項目３７に記載のソースエンコーダ。
（項目３９）
前記ソースビデオの部分は、前記ソースビデオの選択された部分の持続時間に基づいて選択される、項目３７に記載のソースエンコーダ。
（項目４０）
前記ソースエンコーディングアプリケーションは、２秒の持続時間を有する前記ソースビデオの部分を選択するように前記プロセッサを構成する、項目３９に記載のソースエンコーダ。
（項目４１）
前記エンコードされたビデオの代替部分の各々は、異なる最大ビットレートでエンコードされる、項目３７に記載のソースエンコーダ。
（項目４２）
前記エンコードされたビデオの代替部分のうちの少なくとも２つは、異なる解像度でエンコードされる、項目４１に記載のソースエンコーダ。
（項目４３）
前記エンコードされたビデオの代替部分のうちの少なくとも２つは、異なるフレームレートでエンコードされる、項目４１に記載のソースエンコーダ。
（項目４４）
エンコードされたビデオの各代替部分が書き込まれる前記ＥＢＭＬコンテナファイルの要素は、タイムコードを含有するＣｌｕｓｔｅｒ要素であり、該エンコードされたビデオの部分は、該Ｃｌｕｓｔｅｒ要素内のＢｌｏｃｋＧｒｏｕｐ要素内に含有される、項目３７に記載のソースエンコーダ。
（項目４５）
前記Ｃｌｕｓｔｅｒ要素内に含有される前記エンコードされたビデオの代替部分の各エンコードされたフレームは、別個のＢｌｏｃｋＧｒｏｕｐ要素内に含有される、項目４４に記載のソースエンコーダ。
（項目４６）
前記Ｃｌｕｓｔｅｒ要素内の第１のＢｌｏｃｋＧｒｏｕｐ要素は、ＩＤＲフレームを含有する、項目４５に記載のソースエンコーダ。
（項目４７）
前記第１のＢｌｏｃｋＧｒｏｕｐ要素は、前記Ｃｌｕｓｔｅｒ要素のタイムコードに対して、前記ＩＤＲフレームのタイムコード属性を指定するＢｌｏｃｋ要素を含有する、項目４６に記載のソースエンコーダ。
（項目４８）
前記エンコードされたビデオの代替部分の各々が書き込まれる各要素は、同一のタイムコードが割り当てられる、項目３７に記載のソースエンコーダ。
（項目４９）
前記ソースエンコーディングアプリケーションは、前記ＥＢＭＬコンテナファイルの各々のためのインデックスを作成するように前記プロセッサをさらに構成する、項目３７に記載のソースエンコーダ。
（項目５０）
前記ソースエンコーディングアプリケーションは、前記ＥＢＭＬコンテナファイルの各々の中の前記エンコードされたビデオの代替部分のうちの１つを含有する要素の場所を、該ＥＢＭＬコンテナファイルのためのインデックスに追加するように前記プロセッサをさらに構成する、項目４９に記載のソースエンコーダ。
（項目５１）
前記ソースエンコーディングアプリケーションは、各ＥＢＭＬコンテナファイルのための前記インデックスを該ＥＢＭＬコンテナファイル中へパックするように前記プロセッサをさらに構成する、項目４９に記載のソースエンコーダ。
（項目５２）
各インデックスは、Ｃｕｅｓ要素を備える、項目５１に記載のソースエンコーダ。
（項目５３）
各Ｃｕｅ要素は、前記ＥＢＭＬファイル内の前記エンコードされたビデオの代替部分のうちの１つを含有する要素の場所を指し示すＣｕｅＰｏｉｎｔ要素を含む、項目５２に記載のソースエンコーダ。
（項目５４）
前記ソースエンコーディングアプリケーションは、前記ＥＢＭＬコンテナファイルの各々を識別するトップレベルインデックスファイルを作成するように前記プロセッサをさらに構成する、項目３７に記載のソースエンコーダ。
（項目５５）
前記取り込まれたマルチメディアファイルはまた、ソースオーディオを含む、項目３７に記載のソースエンコーダ。
（項目５６）
前記ソースエンコーディングアプリケーションは、オーディオを前記ＥＢＭＬコンテナファイルの各々の中に多重化するように前記プロセッサを構成する、項目５５に記載のソースエンコーダ。
（項目５７）
前記ソースエンコーディングアプリケーションは、前記オーディオを別個のＥＢＭＬコンテナファイルに書き込むように前記プロセッサを構成する、項目５５に記載のソースエンコーダ。
（項目５８）
前記ソースエンコーディングアプリケーションは、前記少なくとも１つのオーディオトラックのうちの少なくとも１つをトランスコードするように前記プロセッサをさらに構成する、項目５５に記載のソースエンコーダ。
（項目５９）
前記取り込まれたマルチメディアファイルは、字幕をさらに備える、項目５５に記載のソースエンコーダ。
（項目６０）
前記ソースエンコーディングアプリケーションは、前記字幕を前記ＥＢＭＬコンテナファイルの各々の中に多重化するように前記プロセッサを構成する、項目５９に記載のソースエンコーダ。
（項目６１）
前記ソースエンコーディングアプリケーションは、前記字幕を別個のＥＢＭＬコンテナファイルに書き込むように前記プロセッサを構成する、項目５９に記載のソースエンコーダ。
（項目６２）
前記ソースエンコーディングアプリケーションは、前記ソースビデオをトランスコードして、より低いフレームレートトリックプレイトラックを作成し、および該トリックプレイトラックを別個のＥＢＭＬコンテナファイルに書き込むように前記プロセッサをさらに構成する、項目３７に記載のソースエンコーダ。
（項目６３）
前記トリックプレイトラックはまた、前記ソースビデオよりも低い解像度である、項目６２に記載のソースエンコーダ。
（項目６４）
前記ソースエンコーディングアプリケーションは、一組のエンコーディングパラメータを含有する要素を前記ＥＢＭＬコンテナファイルの各々の中に書き込むように前記プロセッサをさらに構成する、項目３７に記載のソースエンコーダ。
（項目６５）
前記一組のエンコーディングパラメータは、フレームレート、フレーム高さ、フレーム幅、サンプルアスペクト比、最大ビットレート、および最小バッファサイズから成る群から選択される少なくとも１つのパラメータを含む、項目６４に記載のソースエンコーダ。
（項目６６）
ソースエンコーダを使用して、拡張可能バイナリマークアップ言語（ＥＢＭＬ）ファイル中にパックされる複数の代替ストリームとして、ソースビデオをエンコードする方法であって、
該方法は、
該ソースエンコーダを使用して、該ソースビデオの部分を繰り返し選択することと、
該ソースエンコーダを使用して、該ソースビデオの該選択された部分をエンコードされたビデオの複数の代替部分にトランスコードすることであって、各代替部分は、異なる一組のエンコーディングパラメータを使用してエンコードされ、クローズドピクチャ群（ＧＯＰ）を始めるイントラフレームで開始する、ことと、
該ソースエンコーダを使用して、該エンコードされたビデオの代替部分の各々を異なるＥＢＭＬコンテナファイルの要素に書き込むことであって、各要素は、該ビデオの部分をエンコードするために使用される該エンコーディングパラメータに対応する一組のエンコーディングパラメータを含有する別の要素もまた含むＥＢＭＬコンテナファイル内に位置する、ことと、
あるエントリを該ＥＢＭＬコンテナファイルの各々の中の該エンコードされたビデオの代替部分のうちの１つを含有する要素の場所を識別する少なくとも１つのインデックスに追加することと
を含む、方法。

図１は、本発明のある実施形態による、適応型ビットレートストリーミングシステムのネットワーク図である。 図２は、本発明の実施形態による、ソースメディアのエンコーディングによって生成されるトップレベルインデックスファイルおよびＭａｔｒｏｓｋａコンテナファイルを概念的に図示する。 図３は、本発明のある実施形態による、修正されたＣｕｅ要素を組み込む、特殊Ｍａｔｒｏｓｋａコンテナファイルを概念的に図示する。 図４ａ−４ｃは、本発明の実施形態による、適応型ビットレートストリーミングを促進する種々の制約を条件とする、Ｍａｔｒｏｓｋａコンテナファイルのクラスタ要素中への異なるタイプのメディアの挿入を概念的に図示する。 図４ａ−４ｃは、本発明の実施形態による、適応型ビットレートストリーミングを促進する種々の制約を条件とする、Ｍａｔｒｏｓｋａコンテナファイルのクラスタ要素中への異なるタイプのメディアの挿入を概念的に図示する。 図４ａ−４ｃは、本発明の実施形態による、適応型ビットレートストリーミングを促進する種々の制約を条件とする、Ｍａｔｒｏｓｋａコンテナファイルのクラスタ要素中への異なるタイプのメディアの挿入を概念的に図示する。 図４ｄは、本発明のある実施形態による、適応型ビットレートストリーミングを促進する種々の制約を条件とする、Ｍａｔｒｏｓｋａコンテナファイルのクラスタ要素中への異なるタイプのメディアの多重化を概念的に図示する。 図４ｅは、本発明のある実施形態による、適応型ビットレートストリーミングを促進する種々の制約を条件とする、ＭａｔｒｏｓｋａコンテナファイルのＣｌｕｓｔｅｒ要素中へのトリックプレイトラックの含有を概念的に図示する。 図５は、本発明のある実施形態による、特殊Ｍａｔｒｏｓｋａコンテナファイルの修正されたＣｕｅ要素を概念的に図示しており、Ｃｕｅ要素は、ＨＴＴＰバイト範囲要求を使用して、Ｃｌｕｓｔｅｒ要素の読み出しを可能にする情報を含む。 図５ａは、本発明のある実施形態による、特殊Ｍａｔｒｏｓｋａコンテナファイルの修正されたＣｕｅ要素を概念的に図示しており、Ｃｕｅ要素は、図５に示されるＣｕｅ要素に類似するが、適応型ビットレートストリーミングの間に利用されない属性は、除去される。 図６は、本発明の実施形態による、コンテナファイル内で修正されたＣｕｅＰｏｉｎｔ要素を利用する、特殊Ｍａｔｒｏｓｋａコンテナファイル内のＣｌｕｓｔｅｒ要素のインデックス化を概念的に図示する。 図７は、本発明のある実施形態による、適応型ビットレートストリーミングのために、ソースメディアをエンコードするためのプロセスを図示する、流れ図である。 図８は、本発明のある実施形態による、トップレベルインデックスファイルによってインデックス化されたＭａｔｒｏｓｋａコンテナファイル内に含有されるエンコードされたメディアのストリーミングの開始と関連付けられる、再生デバイスとＨＴＴＰサーバとの間の通信を概念的に図示する。 図９ａおよび９ｂは、本発明の実施形態による、ストリームの切り替え決定に先立って、再生デバイスによって経験されるストリーミング状態に応答した、かつ再生デバイスに利用可能なインデックス情報に応じた、ストリーム間の切り替えと関連付けられる、再生デバイスとＨＴＴＰサーバとの間の通信を概念的に図示する。 図９ａおよび９ｂは、本発明の実施形態による、ストリームの切り替え決定に先立って、再生デバイスによって経験されるストリーミング状態に応答した、かつ再生デバイスに利用可能なインデックス情報に応じた、ストリーム間の切り替えと関連付けられる、再生デバイスとＨＴＴＰサーバとの間の通信を概念的に図示する。

次に、図面を参照すると、本発明の実施形態による、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を利用するＭａｔｒｏｓｋａコンテナファイル内に記憶されたメディアの適応型ビットレートストリーミングのためのシステムおよび方法が図示されている。いくつかの実施形態では、ソースメディアは、いくつかの代替ストリームとして、エンコードされる。各ストリームは、Ｍａｔｒｏｓｋａ（ＭＫＶ）コンテナファイル内に記憶される。多くの実施形態では、Ｍａｔｒｏｓｋａコンテナファイルは、各ストリーム内のメディアがエンコードされ、コンテナ内に記憶される様式が、ストリーミング性能を改善するように制約されるという点において、特殊Ｍａｔｒｏｓｋａコンテナファイルである。いくつかの実施形態では、Ｍａｔｒｏｓｋａコンテナファイルは、付加的インデックス要素（すなわち、Ｍａｔｒｏｓｋａコンテナ形式の部分として指定されない要素）が、適応型ビットレートストリーミングの間、所望のメディアの読み出しを促進するために、ファイル内に含まれることができるという点において、さらに特殊である。いくつかの実施形態では、各ストリーム（すなわち、オーディオ、ビデオ、または字幕）は、別個のＭａｔｒｏｓｋａコンテナファイル内に記憶される。他の実施形態では、エンコードされたビデオストリームは、各Ｍａｔｒｏｓｋａコンテナファイル内の１つ以上のエンコードされたオーディオおよび／または字幕ストリームで多重化される。コンテナファイルのそれぞれ内に含有されるストリームへのインデックスを含有する、トップレベルインデックスファイルもまた、エンコードされたメディアの適応型ビットレートストリーミングを可能にするように生成される。多くの実施形態では、トップレベルインデックスファイルは、Ｍａｔｒｏｓｋａコンテナファイルのそれぞれに対するＵＲＩを含有する同期マルチメディア統合言語（ＳＭＩＬ）ファイルである。他の実施形態では、種々のファイル形式のいずれも、トップレベルインデックスファイルの生成において利用されることができる。

本発明の実施形態による、適応型ビットレートストリーミングシステムの性能は、ビデオの部分が、瞬時復号更新（ＩＤＲ）フレームで開始する単一（または、少なくとも１つ）のクローズドピクチャ群（ＧＯＰ）として、各ストリーム内にエンコードされるように、各ビットレートにおいて、ソースビデオの各部分をエンコードすることによって、有意に向上されることができる。各ストリームのためのＧＯＰは、次いで、ストリームのためのＭａｔｒｏｓｋａコンテナファイル内のＣｌｕｓｔｅｒ要素として記憶されることができる。このように、再生デバイスは、の再生完了時、ストリーム間で切り替えることができ、クラスタが取得されるストリームに関係なく、クラスタ内の第１のフレームは、ＩＤＲフレームであって、Ｃｌｕｓｔｅｒ要素内に含有されるエンコードされたメディア以外の任意のエンコードされたメディアを参照せずに、デコードされることができる。多くの実施形態では、ＧＯＰとしてエンコードされるソースビデオのセクションはすべて、同一の持続時間である。いくつかの実施形態では、ソースビデオの各２秒のシーケンスが、ＧＯＰとしてエンコードされる。

適応型ストリーミングの間、ＨＴＴＰを使用するメディアの読み出しは、付加的インデックス情報をエンコードされたストリームのそれぞれを含有するために使用されるＭａｔｒｏｓｋａコンテナファイルに追加することによって、改善されることができる。いくつかの実施形態では、インデックスは、インデックスが各クラスタの開始時のＩＤＲにのみポイントするという点において、簡略インデックスである。多くの実施形態では、Ｍａｔｒｏｓｋａコンテナファイルのインデックスは、再生デバイスが、バイト範囲要求を使用して、ＨＴＴＰを介して、Ｃｌｕｓｔｅｒ要素をＭａｔｒｏｓｋａコンテナファイルから読み出すことができるように、クラスタのそれぞれのサイズを指定する、付加的非標準的属性（すなわち、Ｍａｔｒｏｓｋａコンテナファイル形式仕様の部分を形成しない、属性）を含む。

前述のようにエンコードされたソースメディアの適応型ストリーミングは、本発明の実施形態による、再生デバイスによって調整されることができる。再生デバイスは、トップレベルインデックスファイルから、利用可能なストリームのそれぞれに関する情報を取得し、１つ以上のストリームを選択し、メディアの再生において利用する。再生デバイスは、次いで、ヘッダ情報を１つ以上のビットストリームまたはストリームを含有するＭａｔｒｏｓｋａコンテナファイルから取得することができ、ヘッダが、ストリームのデコーディングに関する情報を提供する。再生デバイスはまた、関連Ｍａｔｒｏｓｋａコンテナファイル内に記憶されるエンコードされたメディアをインデックス化するインデックス情報を要求することができる。インデックス情報は、Ｍａｔｒｏｓｋａコンテナファイル内に、あるいはＭａｔｒｏｓｋａコンテナファイルとは別個に、トップレベルインデックスまたは別個のインデックスファイル内に記憶されることができる。インデックス情報は、再生デバイスが、サーバから、ＨＴＴＰを経由して、エンコードされたメディアの特定の部分を含有するＭａｔｒｏｓｋａコンテナファイル内のＣｌｕｓｔｅｒ要素に対応するバイト範囲を要求することを可能にする。再生デバイスが、Ｃｌｕｓｔｅｒ要素をＨＴＴＰサーバから受信するにつれて、再生デバイスは、現在のストリーミング状態を評価し、ストリーミングされるメディアのビットレートを増加または減少すべきかどうかを決定することができる。再生デバイスが、ビットレート内の変化が必要であると決定する場合、再生デバイスは、所望のストリームを含有するコンテナファイルに対するヘッダ情報およびインデックス情報を取得することができる（再生デバイスが、この情報を既に取得していないと仮定して）。インデックス情報は、次いで、所望のビットレートでエンコードされたソースメディアの次の部分を含有するＣｌｕｓｔｅｒ要素のバイト範囲を識別するために使用されることができ、識別されたＣｌｕｓｔｅｒ要素は、ＨＴＴＰを介して、サーバから読み出されることができる。要求されるソースメディアの次の部分は、一般的には、再生デバイスによって既に要求されたＣｌｕｓｔｅｒ要素および再生デバイスによってバッファリングされたＣｌｕｓｔｅｒ要素に基づいて識別される。代替ストリームから要求されるソースメディアの次の部分は、再生デバイスによる、ソースメディアの次の部分を含有するＣｌｕｓｔｅｒ要素の受信に先立って、再生デバイスのバッファがアンダーフロー（すなわち、再生するためのメディアの枯渇）を起こすであろう可能性を最小にするために要求される。このように、再生デバイスは、Ｍａｔｒｏｓｋａコンテナファイルのそれぞれ内のＣｌｕｓｔｅｒ要素を記述するトップレベルインデックスおよびインデックス情報を使用して、ストリーミング状態に対する適切性に応じて、順次Ｃｌｕｓｔｅｒ要素を種々のストリームから読み出すことによって、適応型ビットレートストリーミングを達成することができる。

いくつかの実施形態では、異なるストリーム間のビットレートの変動は、ビットレート、フレームレート、および解像度を含むが、それらに限定されない各ストリームに対するエンコーディングパラメータを修正することによって、達成されることができる。異なるストリームが異なる解像度を含むとき、各ストリームの表示アスペクト比は、同一であって、サンプルアスペクト比は、ある解像度から別の解像度へのスムーズな遷移を確実にするように修正される。適応型ビットレートストリーミングにおける使用のためのソースビデオのエンコーディングと、本発明の実施形態による、適応型ビットレートストリーミングを達成するためのＨＴＴＰ要求を使用したエンコードされたソースビデオの再生は、以下にさらに論じられる。

（適応型ストリーミングシステムアーキテクチャ）
本発明のある実施形態による、適応型ストリーミングシステムは、図１に図示される。適応型ストリーミングシステム１０は、いくつかの代替ストリームとして、ソースメディアをエンコードするように構成されるソースエンコーダ１２を含む。図示される実施形態では、ソースエンコーダは、サーバである。他の実施形態では、ソースエンコーダは、プロセッサと、ソースメディア（ビデオ、オーディオ、および／または字幕を含むが、それらに限定されない）のトランスコーディングを行うための十分なリソースとを含む、任意の処理デバイスであることができる。以下にさらに論じられるように、ソースエンコーディングサーバ１２は、ストリームを含有する複数のコンテナファイルへのトップレベルインデックスを生成し、そのうちの少なくとも複数は、代替ストリームである。代替ストリームは、同一のメディアコンテンツを異なる方法でエンコードする、ストリームである。多くの事例では、代替ストリームは、異なるビットレートでメディアコンテンツ（限定されないが、ビデオ等）をエンコードする。いくつかの実施形態では、代替ストリームは、異なる解像度および／または異なるフレームレートでエンコードされる。トップレベルインデックスファイルおよびコンテナファイルは、ＨＴＴＰサーバ１４にアップロードされる。種々の再生デバイスは、次いで、ＨＴＴＰまたは別の適切なステートレスプロトコルを使用して、インターネット等のネットワーク１６を介して、トップレベルインデックスファイルおよびコンテナファイルの部分を要求することができる。

多くの実施形態では、トップレベルインデックスファイルは、ＳＭＩＬファイルであって、メディアは、Ｍａｔｒｏｓｋａコンテナファイル内に記憶される。以下にさらに論じられるように、メディアは、メディアの適応型ビットレートストリーミングを促進するように、Ｍａｔｒｏｓｋａコンテナファイル内に記憶されることができる。多くの実施形態では、Ｍａｔｒｏｓｋａコンテナファイルは、メディアの適応型ビットレートストリーミングの間、ＨＴＴＰを介して、メディアの特定の部分の読み出しを促進する、強化（すなわち、Ｍａｔｒｏｓｋａファイル形式仕様の部分を形成しない要素）を含む、特殊Ｍａｔｒｏｓｋａコンテナファイルである。

図示される実施形態では、再生デバイスは、パーソナルコンピュータ１８および携帯電話２０を含む。他の実施形態では、再生デバイスは、消費者電子機器デバイス、例えば、ＤＶＤプレーヤ、Ｂｌｕ−ｒａｙ（登録商標）プレーヤ、テレビ、セットトップボックス、ビデオゲームコンソール、タブレット、およびＨＴＴＰを介して、サーバに接続し、エンコードされたメディアを再生可能である、他のデバイスを含むことができる。具体的アーキテクチャは、図１に示されるが、任意の種々のアーキテクチャのいずれも、再生デバイスが、本発明の実施形態に従って、トップレベルインデックスファイルおよびコンテナファイルの部分を要求することを可能にするように利用されることができる。

（ファイル構造）
本発明の実施形態による、再生デバイスへのストリーミングのために、ソースエンコーダによって生成され、および／またはＨＴＴＰサーバ上に記憶される、ファイルは、図２に図示される。ソースメディアの適応型ビットレートストリーミング内で利用されるファイルは、トップレベルインデックス３０と、それぞれ、少なくとも１つのストリームを含有する、複数のコンテナファイル３２とを含む。トップレベルインデックスファイルは、コンテナファイルのそれぞれのコンテンツを記述する。以下にさらに論じられるように、トップレベルインデックスファイルは、ＳＭＩＬファイルを含む、種々の形態をとることができ、コンテナファイルは、特殊Ｍａｔｒｏｓｋａコンテナファイルを含む、種々の形態をとることができる。

多くの実施形態では、各Ｍａｔｒｏｓｋａコンテナファイルは、単一ストリームを含有する。例えば、ストリームは、いくつかの代替ビデオストリームのうちの１つ、オーディオストリーム、いくつかの代替オーディオストリームのうちの１つ、字幕ストリーム、いくつかの代替字幕ストリームのうちの１つ、トリックプレイストリーム、またはいくつかの代替トリックプレイストリームのうちの１つであり得る。いくつかの実施形態では、Ｍａｔｒｏｓｋａコンテナファイルは、複数の多重化されたストリームを含む。例えば、Ｍａｔｒｏｓｋａコンテナは、ビデオストリーム、および１つ以上のオーディオストリーム、１つ以上の字幕ストリーム、および／または１つ以上のトリックプレイストリームを含み得る。以下にさらに論じられるように、多くの実施形態では、Ｍａｔｒｏｓｋａコンテナファイルは、特殊ファイルである。メディアのエンコーディングおよびメディアがＭａｔｒｏｓｋａコンテナファイル内のＣｌｕｓｔｅｒ要素内に記憶される様式は、適応型ビットレートストリーミングシステムの性能を向上させるように設計される制約を条件とすることができる。加えて、Ｍａｔｒｏｓｋａコンテナファイルは、メディアの適応型ストリーミングの間、種々のＭａｔｒｏｓｋａコンテナファイルからのＣｌｕｓｔｅｒ要素の特定およびダウンロードを促進する、インデックス要素を含むことができる。本発明の実施形態による適応型ビットレートストリーミングシステムにおいて使用されることができるトップレベルインデックスファイルおよびＭａｔｒｏｓｋａコンテナファイルは、以下に論じられる。

（トップレベルインデックスファイル）
本発明の多くの実施形態による、再生デバイスは、トップレベルインデックスファイルを利用して、適応型ビットレートストリーミングにおいて使用するための再生デバイスに利用可能なストリームを含有する、コンテナファイルを識別する。多くの実施形態では、トップレベルインデックスファイルは、それぞれ、エンコードされたメディアの代替ストリームを含むコンテナファイルへの参照を含むことができる。再生デバイスは、トップレベルインデックスファイル内の情報を利用して、再生デバイスによって経験されるストリーミング状態に従って、コンテナファイルのそれぞれからエンコードされたメディアを読み出すことができる。

いくつかの実施形態では、トップレベルインデックスファイルは、再生デバイスが、コンテナファイルのそれぞれ内のメディアのエンコーディングに関する情報と、コンテナファイルのそれぞれ内のエンコードされたメディアへのインデックスを読み出すことを可能にする、情報を提供する。いくつかの実施形態では、各コンテナファイルは、コンテナファイル内に含有されるエンコードされたメディアに関する情報と、コンテナファイル内のエンコードされるメディアへのインデックスを含み、トップレベルインデックスファイルは、この情報を含有する各コンテナファイルの部分を示す。したがって、再生デバイスは、トップレベルインデックスファイルを読み出し、トップレベルインデックスファイルを使用して、コンテナファイル内に含有されるエンコードされたメディアに関する情報と、コンテナファイル内のエンコードされるメディアへのインデックスを含む、コンテナファイルのうちの１つ以上の部分を要求することができる。本発明の実施形態による、適応型ビットレートストリーミングシステムにおいて使用されることができる、種々のトップレベルインデックスファイルは、以下でさらに論じられる。

（トップレベルインデックスＳＭＩＬファイル）
いくつかの実施形態では、メディアの適応型ビットレートストリーミングにおいて利用されるトップレベルインデックスファイルは、ＳＭＩＬファイルであって、これは、ストリームのそれぞれを記述するＵＲＩおよびストリームを含有するコンテナファイルのリストを含む、ＸＭＬファイルである。ＵＲＩは、情報、例えば、ストリーム内に含有されるストリームの「システム−ビットレート」およびコンテナファイル内のデータの特定の断片の場所に関する情報を含むことができる。

ＳＭＩＬファイルの基本的構造は、ＸＭＬ宣言およびＳＭＩＬ要素を提供することを伴う。ＳＭＩＬ要素は、適応型ビットレートストリーミングにおいて使用するために利用可能なストリームを定義し、一般的には、空のままにされる、ＨＥＡＤ要素と、一般的には、ＰＡＲ（パラレル）要素のみを含有する、ＢＯＤＹ要素とを含む。ＰＡＲ要素は、同時に再生することができる、ストリーム（すなわち、同時に提示されることができる、メディアを含む）を記述する。

ＳＭＩＬ仕様は、適応型ビットレートストリーミングにおいて使用するために利用可能なストリームを指定するために利用されることができるＰＡＲ要素に対して、いくつかの子要素を定義する。ＶＩＤＥＯ、ＡＵＤＩＯ、およびＴＥＸＴＳＴＲＥＡＭ要素は、特定のビデオ、オーディオ、または字幕ストリームを定義するために利用されることができる。ＶＩＤＥＯ、ＡＵＤＩＯ、およびＴＥＸＴＳＴＲＥＡＭ要素は、集合的に、メディアオブジェクトと称されることができる。メディアオブジェクトの基本的属性は関連ストリームを含有するコンテナファイルへの完全パスまたはＵＲＩを指定するＳＲＣ属性と、３文字の言語コードを含むＸＭＬ：ＬＡＮＧ属性である。メディアオブジェクトに関する付加的情報は、ＰＡＲＡＭ要素を使用して指定することができる。ＰＡＲＡＭ要素は、一般的な名前と値との組を提供するためのＳＭＩＬ形式内の標準的方法である。本発明のいくつかの実施形態では、特定のＰＡＲＡＭ要素は、適応型ビットレートストリーミングの間に利用されるように定義される。

多くの実施形態では、「ヘッダ−要求」ＰＡＲＡＭ要素は、ストリームを含有するコンテナファイルのヘッダセクションのサイズを指定するように定義される。「ヘッダ−要求」ＰＡＲＡＭ要素の値は、一般的には、ファイルの開始とファイル内のエンコードされたメディアの開始との間のバイト数を指定する。多くの実施形態では、ヘッダは、メディアがエンコードされる様式に関する情報を含有し、再生デバイスは、エンコードされたメディアの再生のためのデコーダを構成可能にするために、エンコードされたメディアの再生に先立って、ヘッダを読み出す。「ヘッダ−要求」ＰＡＲＡＭ要素の実施例は、

である。

いくつかの実施形態では、「ｍｉｍｅ」ＰＡＲＡＭ要素は、ストリームのＭＩＭＥタイプを指定するように定義される。ストリームをＨ．２６４ストリーム（すなわち、ＭＰＥＧ−４アドバンスドビデオコーデック規格に従ってエンコードされたストリーム）として識別する「ｍｉｍｅ」ＰＡＲＡＭ要素は、

である。

ストリームのＭＩＭＥタイプは、特定のストリーム（例えば、ＡＡＣオーディオまたはＵＴＦ−８テキストストリーム）のエンコーディングに対する適切性に応じて、「ｍｉｍｅ」ＰＡＲＡＭ要素を使用して指定されることができる。

メディアオブジェクトが、ＶＩＤＥＯ要素であるとき、付加的属性は、ＶＩＤＥＯ要素によって識別されるコンテナファイル内のストリームのビットレートを指定するｓｙｓｔｅｍＢｉｔｒａｔｅ属性と、エンコードされたビデオの寸法を画素で指定する幅および高さ属性を含むＳＭＩＬファイル形式仕様内で定義される。付加的属性はまた、ＰＡＲＡＭ要素を使用して定義することができる。いくつかの実施形態では、「ｖｂｖ」ＰＡＲＡＭ要素は、ビデオストリームのＶＢＶバッファサイズをバイトで指定するように定義される。ビデオバッファリング検証子（ＶＢＶ）は、エンコードされたビデオストリームが、正確にバッファリングされ、デコーダデバイスで再生され得ることを確実にするために使用される、理論的ＭＰＥＧビデオバッファモデルである。１０００バイトのＶＢＶサイズを指定する「ｖｂｖ」ＰＡＲＡＭ要素の実施例は、

である。

前述の属性を含む、ＶＩＤＥＯ要素の実施例は、

である。

本発明の実施形態による、適応型ビットレートストリーミングシステムは、トリックプレイストリームに対応することができ、これは、適応型ビットレートストリーミングのためにエンコードされるソースコンテンツのスムーズな視覚的検索を提供するために使用されることができる。トリックプレイストリームは、再生時、ソースメディアを通して、視覚的検索が加速されているかのようにエンコードされることが、実際は、トリックプレイストリームは、単に、より低いフレームレートでソースメディアをエンコードする別個のトラックである。システムの多くの実施形態では、トリックプレイトラックの参照は、ＶＩＤＥＯ要素は、ＶＩＤＥＯ要素のｓｙｓｔｅｍＰｒｏｆｉｌｅ属性によって示される。他の実施形態では、種々の技法のいずれも、特定のストリームがトリックプレイストリームであることを、トップレベルインデックスファイル内で示すために利用されることができる。本発明のある実施形態による、トリックプレイストリームＶＩＤＥＯ要素の実施例は、

である。

本発明のいくつかの実施形態では、「ｒｅｓｅｒｖｅｄＢａｎｄｗｉｄｔｈ」ＰＡＲＡＭ要素が、ＡＵＤＩＯ要素のために定義されることができる。「ｒｅｓｅｒｖｅｄＢａｎｄｗｉｄｔｈ」ＰＡＲＡＭ要素は、オーディオストリームのビットレートをＫｂｐｓで指定する。本発明のある実施形態に従って指定されるＡＵＤＩＯ要素の実施例は、

である。

いくつかの実施形態では、「ｒｅｓｅｒｖｅｄＢａｎｄｗｉｄｔｈ」ＰＡＲＡＭ要素はまた、ＴＥＸＴＳＴＲＥＡＭ要素のために定義される。本発明のある実施形態による、「ｒｅｓｅｒｖｅｄＢａｎｄｗｉｄｔｈ」ＰＡＲＡＭ要素を含む、ＴＥＸＴＳＴＲＥＡＭ要素の実施例は、

である。

他の実施形態では、種々の機構のいずれも、特定のアプリケーションに対する適切性に応じて、ＶＩＤＥＯ、ＡＵＤＩＯ、およびＳＵＢＴＩＴＬＥ要素に関する情報を指定するために利用されることができる。

ＳＷＩＴＣＨ要素は、適応型または代替ストリームを定義するために利用され得る、ＳＭＩＬファイル形式仕様内で定義される機構である。ＳＷＩＴＣＨ要素が、異なるビットレートで代替ビデオストリームを指定するために利用され得る様式の実施例は、

である。

ＳＷＴＩＣＨ要素は、３つの代替ビデオストリームのＵＲＬを指定する。ファイル名は、ストリームのそれぞれの異なるビットレートを示す。以下にさらに論じられるように、ＳＭＩＬファイル形式仕様は、トップレベルインデックスＳＭＩＬファイル内において、ストリームおよびそれが含有されるコンテナファイルに関する付加的情報を指定するために、本発明の実施形態に従って利用されることができる、機構を提供する。

本発明の多くの実施形態では、ＥＸＣＬ（除外）要素は、ストリーミング状態を伴う再生の間、適応しない代替トラックを定義するために使用される。例えば、ＥＸＣＬ要素は、代替オーディオトラックまたは代替字幕トラックを定義するために使用することができる。ＥＸＣＬ要素が、代替ＥｎｇｌｉｓｈおよびＦｒｅｎｃｈオーディオストリームを指定するために利用されることができる様式の実施例は、

である。

本発明のある実施形態による、２つの代替ビデオレベル、オーディオストリームおよび字幕ストリームの属性ならびにパラメータを定義する、トップレベルインデックスＳＭＩＬファイルの実施例は、

である。

トップレベルインデックスＳＭＩＬファイルは、ソースメディアが、適応型ビットレートストリーミングを介して、再生のためにエンコードされるとき、生成されることができる。代替として、トップレベルインデックスＳＭＩＬファイルは、再生デバイスがエンコードされたメディアの再生の開始を要求するとき、生成されることができる。再生デバイスが、トップレベルインデックスＳＭＩＬファイルを受信すると、再生デバイスは、ＳＭＩＬファイルを解析し、利用可能なストリームを識別することができる。再生デバイスは、次いで、ストリームを選択し、コンテンツを再生するために利用することができ、ＳＭＩＬファイルを使用して、コンテナファイルの部分を識別し、特定のストリームのエンコーディングに関する情報を取得する、および／またはコンテナファイル内のエンコードされたメディアへのインデックスを取得するためにダウンロードすることができる。

トップレベルインデックスＳＭＩＬファイルが、前述されているが、種々のトップレベルインデックスファイル形式のいずれも、本発明のある実施形態による、具体的アプリケーションに対する適切性に応じて、トップレベルインデックスファイルを作成するために利用されることができる。本発明の実施形態による、適応型ビットレートストリーミングを使用して、エンコードされたメディアの再生を可能にするためのトップレベルインデックスファイルの使用は、以下にさらに論じられる。

（適応型ビットレートストリーミングのために、メディアをＭＡＴＲＯＳＫＡファイルに記憶する）
本発明のある実施形態による、エンコードされたビデオを記憶するために使用されるＭａｔｒｏｓｋａコンテナファイルは、図３に図示される。コンテナファイル３２は、Ｍａｔｒｏｓｋａコンテナファイル形式の拡張機能である、拡張可能バイナリマークアップ言語（ＥＢＭＬ）ファイルである。特殊Ｍａｔｒｏｓｋａコンテナファイル３２は、標準的ＥＢＭＬ要素３４と、標準的Ｓｅｅｋ Ｈｅａｄ要素４０、標準的Ｓｅｇｍｅｎｔ情報要素４２、および標準的Ｔｒａｃｋｓ要素４４を含む標準的Ｓｅｇｍｅｎｔ要素３６とを含む。これらの標準的要素は、Ｍａｔｒｏｓｋａコンテナファイル内に含有されるメディアを記述する。Ｓｅｇｍｅｎｔ要素３６はまた、標準的Ｃｌｕｓｔｅｒｓ要素４６を含む。以下に説明されるように、エンコードされたメディアが、Ｃｌｕｓｔｅｒｓ要素４６内の個々のＣｌｕｓｔｅｒ要素４８内に挿入される様式は、適応型ストリーミングシステム内のメディアの再生を改善するために制約される。多くの実施形態では、エンコードされたビデオに課される制約は、Ｍａｔｒｏｓｋａコンテナファイル形式の仕様と一致し、各クラスタが、ＩＤＲフレームで開始する少なくとも１つのクローズドＧＯＰを含むように、ビデオをエンコードすることを伴う。前述の標準的要素に加え、Ｓｅｇｍｅｎｔ要素３６はまた、標準的Ｃｕｅｓ要素５２の修正されたバージョンを含む。以下にさらに論じられるように、Ｃｕｅｓ要素は、ＨＴＴＰを介して、特定のＣｌｕｓｔｅｒ要素内に含有されるメディアの読み出しを促進する、特殊ＣｕｅＰｏｉｎｔ要素（すなわち、非標準的ＣｕｅＰｏｉｎｔ要素）を含む。

本発明の実施形態による、適応型ビットレートストリーミングのためのメディアのエンコーディングに課される制約およびＭａｔｒｏｓｋａコンテナファイルのＣｌｕｓｔｅｒｓ要素内のエンコードされたメディアの形式、ならびにコンテナファイル内に挿入される付加的インデックス情報は、以下にさらに論じられる。

（Ｃｌｕｓｔｅｒ要素内に挿入するためのメディアのエンコーディング）
適応型ビットレートストリーミングシステムは、再生デバイスによって経験されるストリーミング状態に従って、再生の間、再生デバイスに、エンコードされたメディアの異なるストリーム間で選択を行う選択肢を提供する。多くの実施形態では、ストリーム間の切り替えは、各ストリームのエンコーディングパラメータに従って、ソースメディアの離散部分を別個に事前にエンコードし、次いで、各別個にエンコードされた部分をストリームのコンテナファイル内のその独自のＣｌｕｓｔｅｒ要素内に含めることによって促進される。さらに、各クラスタ内に含有されるメディアは、メディアが、ストリーム内の任意の他のクラスタ内に含有されるメディを参照せずに、再生可能であるように、エンコードされる。このように、各ストリームは、ソースメディアの同一の離散部分に対応するＣｌｕｓｔｅｒ要素を含み、随時、再生デバイスは、再生デバイスによって経験されるストリーミング状態に最も適切であるストリームからＣｌｕｓｔｅｒ要素を選択することができ、Ｃｌｕｓｔｅｒ要素内に含有されるメディアの再生を始めることができる。故に、再生デバイスは、再生デバイスによって経験されるストリーミング状態が、経時的に変化するにつれて、異なるストリームからクラスタを選択することができる。いくつかの実施形態では、Ｃｌｕｓｔｅｒ要素はさらに、各Ｃｌｕｓｔｅｒ要素が、同一の持続時間を有するソースメディアからエンコードされたメディアの部分を含有するように、制約される。いくつかの実施形態では、各Ｃｌｕｓｔｅｒ要素は、２秒のエンコードされたメディアを含む。メディアのタイプ（すなわち、ビデオ、オーディオ、または字幕）に応じて、各Ｃｌｕｓｔｅｒ要素内でエンコードされるメディアに適用される具体的制約は、以下に論じられる。

本発明のある実施形態による、ビデオストリームを含有するＭａｔｒｏｓｋａコンテナファイルのＣｌｕｓｔｅｒｓ要素は、図４ａに図示される。Ｃｌｕｓｔｅｒｓ要素４６は、それぞれ、エンコードされたビデオの離散部分を含有する複数のＣｌｕｓｔｅｒ要素４８を含む。図示される実施形態では、各Ｃｌｕｓｔｅｒ要素４８は、２秒のエンコードされたビデオを含む。他の実施形態では、Ｃｌｕｓｔｅｒ要素は、２秒超または未満を有するエンコードされたビデオを含む。Ｃｌｕｓｔｅｒ要素が小さいほど（すなわち、各Ｃｌｕｓｔｅｒ要素内のエンコードされるメディアの持続時間が短いほど）、各Ｃｌｕｓｔｅｒ要素を要求することと関連付けられるオーバーヘッドが高くなる。したがって、ストリーミング状態の変化への再生デバイスの応答性と所与の一組のストリーミング状態のための適応型ストリーミングシステムの有効データレート（すなわち、エンコードされたメディアを伝送するために実際に利用される、利用可能な帯域幅の部分）との間には、トレードオフが存在する。いくつかの実施形態では、Ｃｌｕｓｔｅｒ要素内のエンコードされたビデオシーケンスは、異なる持続時間を有する。各Ｃｌｕｓｔｅｒ要素４８は、Ｃｌｕｓｔｅｒ要素および複数のＢｌｏｃｋＧｒｏｕｐ要素内のエンコードされたビデオの開始時間を示すＴｉｍｅｃｏｄｅ要素６０を含む。前述のように、クラスタ内に記憶されたエンコードされたビデオは、コンテナファイル内の他のＣｌｕｓｔｅｒ要素のいずれか内に含有されるエンコードされたビデオを参照せずに、再生され得るように、制約される。多くの実施形態では、第１のフレームがＩＤＲフレームである、ＧＯＰとして、Ｃｌｕｓｔｅｒ要素内に含有されるビデオのエンコーディングは、制約を強いる。図示される実施形態では、第１のＢｌｏｃｋＧｒｏｕｐ要素６２は、ＩＤＲフレームを含有する。したがって、第１のＢｌｏｃｋＧｒｏｕｐ要素６２は、ＲｅｆｅｒｅｎｃｅＢｌｏｃｋ要素を含まない。第１のＢｌｏｃｋＧｒｏｕｐ要素６２は、Ｃｌｕｓｔｅｒ要素４８のＴｉｍｅｃｏｄｅに対して、Ｂｌｏｃｋ要素６４内でエンコードされるフレームのＴｉｍｅｃｏｄｅ属性を指定する、Ｂｌｏｃｋ要素６４を含む。後続ＢｌｏｃｋＧｒｏｕｐ要素６６は、それらが含有することができるフレームのタイプが制限されない（Ｃｌｕｓｔｅｒ要素内に含有されないフレームを参照することができないこと以外）。したがって、後続ＢｌｏｃｋＧｒｏｕｐ要素６６は、ＢｌｏｃｋＧｒｏｕｐ内に含有されるフレームのデコーディングにおいて利用される他のＢｌｏｃｋＧｒｏｕｐ要素を参照する、ＲｅｆｅｒｅｎｃｅＢｌｏｃｋ要素６８を含むことができる、またはＩＤＲフレームを含有することができ、第１のＢｌｏｃｋＧｒｏｕｐ要素６２に類似する。前述のように、エンコードされたビデオが、ＭａｔｒｏｓｋａファイルのＣｌｕｓｔｅｒ要素内に挿入される様式は、Ｍａｔｒｏｓｋａファイル形式の仕様に一致する。

本発明の実施形態による、ＭａｔｒｏｓｋａコンテナファイルのＣｌｕｓｔｅｒ要素４６内へのエンコードされたオーディオおよび字幕情報の挿入は、図４ｂおよび４ｃに図示される。図示される実施形態では、エンコードされたメディアは、図４ａに関連して前述のエンコードされたビデオに適用される同一の制約を条件として、Ｃｌｕｓｔｅｒ要素４８内に挿入される。加えて、各Ｃｌｕｓｔｅｒ要素内のエンコードされたオーディオおよび字幕情報の持続時間は、エンコードされたビデオを含有するＭａｔｒｏｓｋａコンテナファイルの対応するＣｌｕｓｔｅｒ要素内のエンコードされたビデオの持続時間に対応する。他の実施形態では、オーディオおよび／または字幕ストリームを含有するコンテナファイル内のＣｌｕｓｔｅｒ要素は、代替ビデオストリームを含有するコンテナファイル内のＣｌｕｓｔｅｒ要素の開始時間および持続時間と対応する必要はない。

（単一ＭＫＶコンテナファイル内のストリームの多重化）
図４ａ−４ｃに示されるクラスタ要素は、単一ストリームが、各Ｍａｔｒｏｓｋａコンテナファイル内に含有されると仮定する。いくつかの実施形態では、複数のストリームからのメディアは、単一Ｍａｔｒｏｓｋａコンテナファイル内において多重化される。このように、単一コンテナファイルは、１つ以上の対応するオーディオストリームおよび／または１つ以上の対応する字幕ストリームで多重化されたビデオストリームを含有することができる。ストリームをこのように記憶することは、複数の代替ビデオストリームにわたるオーディオおよび字幕ストリームの複製をもたらすことができる。しかしながら、ビデオストリームおよび関連付けられたオーディオおよび／または字幕ストリームから、エンコードされたメディアを読み出すための検索時間は、サーバ上のデータの隣接する記憶のために低減され得る。本発明のある実施形態による、多重化されたビデオ、オーディオ、および字幕データを含有するＭａｔｒｏｓｋａコンテナファイルのクラスタ要素４６は、図４ｄに図示されている。図示される実施形態では、各Ｃｌｕｓｔｅｒ要素４８は、多重化されたストリームのそれぞれに対する付加的ＢｌｏｃｋＧｒｏｕｐ要素を含む。第１のＣｌｕｓｔｅｒ要素は、エンコードされたビデオフレームを含有し、Ｃｌｕｓｔｅｒ要素の開始時間に対するフレームのＴｉｍｅｃｏｄｅ属性（すなわち、Ｔｉｍｅｃｏｄｅ属性６０）を示すＢｌｏｃｋ要素６４ｖを含む、エンコードされたビデオのための第１のＢｌｏｃｋＧｒｏｕｐ要素６２ｖを含む。第２のＢｌｏｃｋＧｒｏｕｐ要素６２ａは、エンコードされたオーディオシーケンスを含み、Ｃｌｕｓｔｅｒ要素の開始時間に対するエンコードされたオーディオのＴｉｍｅｃｏｄｅを示すＢｌｏｃｋ要素６４ａを含み、第３のＢｌｏｃｋＧｒｏｕｐ要素６２ｓは、エンコードされた字幕を含有し、Ｃｌｕｓｔｅｒ要素の開始時間に対するエンコードされた字幕のＴｉｍｅｃｏｄｅを示すＢｌｏｃｋ要素６４ｓを含む。図示されないが、図示される実施形態では、各Ｃｌｕｓｔｅｒ要素４８は、付加的エンコードされたビデオ、オーディオ、または字幕を含有する付加的ＢｌｏｃｋＧｒｏｕｐ要素を含む可能性が高い。エンコードされたビデオ、オーディオ、および／または字幕ストリームの多重化にかかわらず、エンコードされたメディアに関する同一の制約が、適用される。

（適応型ビットレートストリーミングシステムにおいて使用するためのＭＫＶコンテナファイル内へのトリックプレイトラックの組み込み）
Ｍａｔｒｏｓｋａコンテナファイル内へのトリックプレイトラックの組み込みは、ＤｉｖＸ，ＬＬＣによって、２００８年１０月２９日出願の米国特許出願第１２／２６０，４０４号「Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｈａｎｃｅｍｅｎｔ Ｔｒａｃｋｓ」において提案されており、その開示は、参照することによって全体として本明細書に組み込まれる。米国特許出願第１２／２６０，４０４号に説明されるトリックプレイトラックに類似するトリックプレイトラックは、本発明のある実施形態による、適応型ビットレートストリーミングシステムにトリックプレイストリームを提供し、適応型ビットレートストリーミングのためのエンコードされたソースコンテンツを通して、スムーズな視覚的検索を提供するために使用されることができる。別個のトリックプレイトラックは、再生時、ソースメディアを通して、視覚的検索が加速されたようにエンコードされることができるが、実際には、トリックプレイトラックは、単に、より低いフレームレートにおいてソースメディアをエンコードする別個のトラックである。いくつかの実施形態では、トリックプレイストリームは、米国特許出願第１２／２６０，４０４号に概略されるように、トリックプレイトラックを生成し、Ｍａｔｒｏｋｓａコンテナファイル中へのビデオストリームの挿入に関する前述の制約を条件として、トリックプレイトラックをＭａｔｒｏｓｋａコンテナファイル中に挿入することによって、作成される。多くの実施形態では、トリックプレイトラックはまた、トリックプレイトラック内の各Ｃｌｕｓｔｅｒ要素のＧＯＰ内の各フレームが、ＩＤＲフレームとして、エンコードされるというさらなる制約を条件とする。他のビデオストリームと同様に、各Ｃｌｕｓｔｅｒ要素は、他のストリーム内の対応するＣｌｕｓｔｅｒ要素と同一の２秒のソースメディアに対応するＧＯＰを含有する。トリックプレイトラックのＧＯＰ内には、単に、より少ないフレームが存在し、各フレームは、より長い持続時間を有する。このように、トリックプレイストリームへおよびそこからの遷移は、他のエンコードされたストリームのいずれか間の遷移が、本発明の実施形態による、適応型ビットレートストリーミングシステム内で処理されるのと同一の方法で処理されることができる。視覚的検索の加速を達成するために、トリックプレイトラック内に含有されるフレームの再生は、一般的には、再生デバイスが、検索の加速のレートの所望の増加（例えば、ｘ２、ｘ４、ｘ６等）を達成するために、再生デバイスのデコーダへのフレームの提供に先立って、エンコードされたビデオのフレームに割り当てられるタイムコードを操作することを含む。

トリックプレイトラックからエンコードされたメディアを含有するＣｌｕｓｔｅｒ要素は、図４ｅに示される。図示される実施形態では、エンコードされたトリックプレイは、図４ａに関連して前述のエンコードされたビデオに適用される同一の制約を条件として、Ｃｌｕｓｔｅｒ要素４８内に挿入される。しかしながら、各Ｂｌｏｃｋ要素は、ＩＤＲを含有する。他の実施形態では、トリックプレイトラックを含有するコンテナファイル内のＣｌｕｓｔｅｒ要素は、代替ビデオストリームを含有するコンテナファイル内のＣｌｕｓｔｅｒ要素の開始時間および持続時間に対応する必要はない。

多くの実施形態では、ソースコンテンツは、適応型ビットレートストリーミングシステムによって使用するための単一トリックプレイトラックまたは複数のトリックプレイトラックを提供するようにエンコードされることができる。単一トリックプレイトラックが提供されるとき、トリックプレイトラックは、一般的には、低ビットレートでエンコードされる。複数の代替トリックプレイトラックが提供されるとき、適応型レートストリーミングはまた、トリックプレイトラックに関して行われることができる。いくつかの実施形態では、複数のトリックプレイトラックは、エンコードされたメディアを通して、異なるレートの視覚的検索の加速に対応するように提供される。

（ＭＫＶコンテナファイル内へのインデックス化情報の組み込み）
Ｍａｔｒｏｓｋａコンテナファイル形式のための仕様は、コンテナファイル内のＢｌｏｃｋ要素をインデックス化するために使用される、随意のＣｕｅ要素を提供する。本発明のある実施形態による、Ｍａｔｒｏｓｋａコンテナファイル中に組み込まれ、ＨＴＴＰを使用して再生デバイスによるクラスタの要求を促進することができる修正されたＣｕｅ要素５２が、図５に図示される。修正されたＣｕｅ要素５２は、それぞれ、ＣｕｅＴｉｍｅ属性７２を含む複数のＣｕｅＰｏｉｎｔ要素７０を含む。各ＣｕｅＰｏｉｎｔ要素は、ＣｕｅＴｒａｃｋ７６およびＣｕｅＣｌｕｓｔｅｒＰｏｓｉｔｉｏｎ７８属性を含有するＣｕｅＴｒａｃｋＰｏｓｉｔｉｏｎ要素７４を含む。多くの実施形態では、ＣｕｅＰｏｉｎｔ要素は、主に、Ｃｌｕｓｔｅｒ要素内の特定のＢｌｏｃｋ要素とは対照的に、特定のＣｌｕｓｔｅｒ要素を識別するように構成される。但し、いくつかの用途では、Ｃｌｕｓｔｅｒ要素内の特定のＢｌｏｃｋＧｒｏｕｐ要素を検索する能力が要求され、付加的インデックス情報がＣｕｅ要素内に含まれる。

本発明のある実施形態による、ＭａｔｒｏｓｋａファイルのＣｌｕｓｔｅｒｓ要素内のエンコードされたメディアをインデックス化するための修正されたＣｕｅｓ要素の使用が図６に図示されている。ＣｕｅＰｏｉｎｔ要素は、Ｍａｔｒｏｓｋａコンテナファイル内の各Ｃｌｕｓｔｅｒ要素に対応するように生成される。ＣｕｅＰｏｉｎｔ要素７０のＣｕｅＴｉｍｅ属性７２は、対応するＣｌｕｓｔｅｒ要素４８のＴｉｍｅｃｏｄｅ属性６０に対応する。加えて、ＣｕｅＰｏｉｎｔ要素は、対応するＣｌｕｓｔｅｒ要素４８の開始をポイントするＣｕｅＣｌｕｓｔｅｒＰｏｓｉｔｉｏｎ属性７８を有する、ＣｕｅＴｒａｃｋＰｏｓｉｔｉｏｎ要素７４を含有する。ＣｕｅＴｒａｃｋＰｏｓｉｔｉｏｎ要素７４はまた、ＣｕｅＢｌｏｃｋＮｕｍｂｅｒ属性を含むことができ、これは、一般的には、Ｃｌｕｓｔｅｒ要素４８内の第１のＩＤＲフレームを含有するＢｌｏｃｋ要素を示すために使用される。

容易に理解され得るように、修正されたＣｕｅ要素５２は、Ｍａｔｒｏｓｋａコンテナファイル内のＣｌｕｓｔｅｒ要素４８のそれぞれへのインデックスを形成する。さらに、ＣｕｅＴｒａｃｋＰｏｓｉｔｉｏｎ要素は、ＨＴＴＰまたは別の好適なプロトコルを介して、遠隔サーバから、特定のＣｌｕｓｔｅｒ要素４８のバイト範囲を要求するために、再生デバイスによって使用され得る情報を提供する。従来のＭａｔｒｏｓｋａファイルのＣｕｅ要素は、直接、Ｃｌｕｓｔｅｒ要素内に含有されるエンコードされたビデオの全部を取得するために、Ｃｌｕｓｔｅｒ要素の開始から、要求するためのバイト数に関する情報を再生デバイスに提供しない。Ｃｌｕｓｔｅｒ要素のサイズは、次のＣｌｕｓｔｅｒ要素の第１のバイトをインデックスするＣｕｅＴｒａｃｋＰｏｓｉｔｉｏｎ要素のＣｕｅＣｌｕｓｔｅｒＰｏｓｉｔｉｏｎ属性を使用することによって、修正されたＣｕｅ要素内で推測されることができる。代替として、付加的ＣｕｅＴｒａｃｋＰｏｓｉｔｉｏｎ要素は、Ｃｌｕｓｔｅｒ要素の最後のバイトをインデックスする（Ｃｌｕｓｔｅｒ要素の第１のバイトをインデックスするＣｕｅＴｒａｃｋＰｏｓｉｔｉｏｎ要素に加え）、本発明の実施形態による、修正されたＣｕｅ要素に追加され得る、および／またはＣｕｅＣｌｕｓｔｅｒＰｏｓｉｔｉｏｎ属性によってポイントされるＣｌｕｓｔｅｒ要素のサイズを指定する非標準的ＣｕｅＣｌｕｓｔｅｒＳｉｚｅ属性が、各ＣｕｅＴｒａｃｋＰｏｓｉｔｉｏｎ要素内に含まれ、ＨＴＴＰバイト範囲要求または類似プロトコルを介して、Ｍａｔｒｏｓｋａコンテナファイル内の特定のＣｌｕｓｔｅｒ要素の読み出しを補助する。

前述のようなＣｕｅ要素の修正は、適応型ビットレートストリーミングの間、ＨＴＴＰまたは類似プロトコルを介して、ＭａｔｒｏｓｋａコンテナファイルからのＣｌｕｓｔｅｒ要素の読み出しを有意に簡略化する。加えて、各クラスタ内の第１のフレームをインデックス化することだけによって、インデックスのサイズが有意に減少される。インデックスが、一般的には、再生に先立ってダウンロードされることを前提として、Ｃｕｅ要素（すなわち、インデックス）のサイズの減少は、再生が、より迅速に始まることができることを意味する。ＣｕｅＣｌｕｓｔｅｒＰｏｓｉｔｉｏｎ要素を使用して、再生デバイスは、単に、所望のＣｌｕｓｔｅｒ要素のためのＴｉｍｅｃｏｄｅ属性を使用して、関連Ｍａｔｒｏｓｋａコンテナファイルのインデックスを参照することによって、再生デバイスによって経験されるストリーミング状態に最も好適なストリームから、特定のＣｌｕｓｔｅｒ要素を要求することができる。

いくつかの実施形態では、Ｃｕｅ要素内のいくつかの属性は、適応型ビットレートストリーミングの間に利用されない。したがって、Ｃｕｅ要素はさらに、利用されていない属性を除去し、各Ｍａｔｒｏｓｋａコンテナファイルのためのインデックスの全体的サイズを減少させることによって修正されることができる。本発明のある実施形態による、単一のエンコードされたストリームを含む、Ｍａｔｒｏｓｋａコンテナファイル内で利用され得る修正されたＣｕｅ要素は、図５ａに図示される。図５ａに示されるＣｕｅ要素５２’は、図５に示されるＣｕｅ要素５２と類似するが、ＣｕｅＰｏｉｎｔ要素７０’は、ＣｕｅＴｉｍｅ属性（図５の７２参照）を含まない、および／またはＣｕｅＴｒａｃｋＰｏｓｉｔｉｏｎ要素７４’は、ＣｕｅＴｒａｃｋ属性（図５の７６）を含まない。Ｍｏｔｒｏｓｋａコンテナファイル内の各Ｃｌｕｓｔｅｒ要素内のエンコードされたメディアの部分が、同一の持続時間を有するとき、ＣｕｅＴｉｍｅ属性は、必要ではない。Ｍａｔｒｏｓｋａが、単一のエンコードされたストリームを含むファイルを含有するとき、ＣｕｅＴｒａｃｋ属性は、必要ではない。他の実施形態では、ＭａｔｒｏｓｋａコンテナファイルのＣｕｅ要素および／または他の要素は、ストリームがエンコードされ、Ｍａｔｒｏｓｋａコンテナファイル内に挿入される様式を前提として、Ｍａｔｒｏｓｋａコンテナファイル内に含有されるエンコードされたストリームの適応型ビットレートストリーミングに必要ではない要素および／または属性を除去するように修正されることができる。

Ｍａｔｒｏｓｋａコンテナファイル内のＣｌｕｓｔｅｒ要素のそれぞれのサイズに関する情報を含み、不必要属性を排除するためのＣｕｅ要素への種々の修正が、前述されるが、本発明の多くの実施形態は、従来のＭａｔｒｏｓｋａコンテナを利用する。いくつかの実施形態では、再生デバイスは、単に、従来のＣｕｅｓ要素から取得される情報を使用して、オンザフライで、Ｃｌｕｓｔｅｒ要素のサイズを決定し、および／またはＭＫＶコンテナファイル内のＣｌｕｓｔｅｒ要素のサイズおよび／または場所に関する情報を含有する別個のインデックスファイルに依拠する。いくつかの実施形態では、付加的インデックス情報が、トップレベルインデックスファイル内に記憶される。いくつかの実施形態では、付加的インデックス情報が、トップレベルインデックスファイル内で識別される、別個のファイル内に記憶される。Ｃｌｕｓｔｅｒ要素をＭａｔｒｏｓｋａコンテナファイルから読み出すために利用されるインデックス情報が、コンテナファイルと別個に記憶されるとき、Ｍａｔｒｏｓｋａコンテナファイルは、依然として、一般的には、前述のように、Ｃｌｕｓｔｅｒ要素内への含有のために、メディアをエンコードするように制約される。加えて、インデックス情報がどこに位置する場合でも、インデックス情報は、一般的には、各Ｃｌｕｓｔｅｒ要素をインデックスし、少なくとも各Ｃｌｕｓｔｅｒ要素の開始場所、多くの事例では、そのサイズに関する情報（但し、それに限定されない）を含むであろう。

（適応型ビットレートストリーミングのためのソースメディアのエンコーディング）
本発明のある実施形態による、トップレベルインデックスファイルとしてソースメディアをエンコードするためのプロセスと、適応型ビットレートストリーミングシステムにおいて使用するための複数のＭａｔｒｏｓｋａコンテナファイルは、図７に図示される。エンコーディングプロセス１００は、ソースメディアの第１の部分を選択するステップ（１０２）と、各ストリームのためのエンコーディングパラメータを使用して、ソースメディアをエンコードするステップ（１０４）によって始まる。メディアの部分が、ビデオであるとき、ソースビデオの部分は、ＩＤＲフレームで開始する単一ＧＯＰとしてエンコードされる。多くの実施形態では、代替ＧＯＰを作成するために使用されるエンコーディングパラメータは、ビットレート、フレームレート、エンコーディングパラメータ、および解像度に基づいて変動する。このように、メディアの部分は、一組の互換可能代替としてエンコードされ、再生デバイスは、再生デバイスによって経験されるストリーミング状態に最も適切な代替を選択することができる。異なる解像度に対応するとき、ストリームのエンコーディングは、各ストリームが、同一の表示アスペクト比を有するように制約される。一定の表示アスペクト比が、ストリームの解像度に伴って、サンプルアスペクト比を変動させることによって、異なる解像度ストリームにわたって達成されることができる。多くの事例では、解像度の低下は、同一のビットレートでエンコードされたより高い解像度ビデオと比較して、より高い品質のビデオをもたらすことができる。多くの実施形態では、ソースメディア自体がエンコードされ、エンコーディングプロセス（１０４）は、適応型ビットレートストリーミングシステムによって対応される代替ストリームのそれぞれのエンコーディングパラメータに従って、エンコードされたソースメディアをトランスコードまたは翻訳することを含む。

ソースメディアが、エンコードされたメディアの一組の代替部分としてエンコードされると、エンコードされたメディアの代替部分はそれぞれ、エンコードされたメディアの部分が属するストリームに対応するＭａｔｒｏｓｋａコンテナファイル内のＣｌｕｓｔｅｒ要素中に挿入される（１０６）。多くの実施形態では、エンコーディングプロセスはまた、メディアが、コンテナ内のＣｌｕｓｔｅｒ要素中に挿入されるにつれて、各Ｍａｔｒｏｓｋａコンテナファイルのためのインデックスを構築する。したがって、プロセス１００はまた、Ｍａｔｒｏｓｋａコンテナファイル内に挿入されるＣｌｕｓｔｅｒ要素をポイントするＣｕｅＰｏｉｎｔ要素を作成するステップを含むことができる。ＣｕｅＰｏｉｎｔ要素は、ソースメディアが完全にエンコードされるまで、バッファ内に保持されることができる。前述のプロセスは、ソースメディアを通して、単一パスにおいて、エンコードされたメディアの代替部分のそれぞれを連続してエンコードするステップを説明するが、本発明の多くの実施形態は、ソースメディアを通して、別個のパスを行い、代替ストリームのそれぞれをエンコードすることを伴う。

図７に戻って参照すると、プロセスは、ソースメディア全体が、適応型ビットレートストリーミングのためにエンコードされる（１０８）まで、ソースメディアの部分の選択（１０２）およびエンコード（１０４）を継続し、次いで、メディアのエンコードされた部分を適切なストリームに対応するＭａｔｒｏｓｋａコンテナファイル中に挿入する（１０６）。その時点において、プロセスは、各ストリームに対して、インデックスをＭａｔｒｏｓｋａコンテナ中に挿入（１１０）し、Ｍａｔｒｏｓｋａコンテナファイル内に含有されるエンコードされたストリームのそれぞれをインデックスするトップレベルインデックスファイルを作成（１１２）することができる。前述のように、インデックスは、エンコードされたメディアとして作成され、ＣｕｅＰｏｉｎｔ要素が、Ｍａｓｔｒｏｓｋａコンテナファイル内の各Ｃｌｕｓｔｅｒ要素をインデックスするように、Ｍａｔｒｏｓｋａコンテナファイル中に挿入することができる。エンコーディングの完了に応じて、ＣｕｅＰｏｉｎｔ要素はそれぞれ、Ｃｕｅ要素内に含まれることができ、Ｃｕｅ要素は、Ｃｌｕｓｔｅｒ要素に続いて、Ｍａｔｒｏｓｋａコンテナファイル中に挿入されることができる。

ソースメディアのエンコーディングに続いて、トリックプレイストリームの生成を含むことができるエンコーディングプロセスの間に生成されるストリームのそれぞれを含有するＭａｔｒｏｓｋａコンテナファイルと、Ｍａｔｒｏｓｋａコンテナファイル内のストリームのそれぞれをインデックスするトップレベルインデックスファイルを生成した後、トップレベルインデックスファイルおよびＭａｔｒｏｓｋａコンテナファイルは、再生デバイスへの適応型ビットレートストリーミングのために、ＨＴＴＰサーバにアップロードされることができる。ＨＴＴＰ要求を使用して、本発明の実施形態に従ってエンコードされたメディアの適応型ビットレートストリーミングは、以下にさらに論じられる。

（ＨＴＴＰを使用したＭＫＶコンテナファイルからの適応型ビットレートストリーミング）
ソースメディアが、ビデオ、オーディオ、および字幕コンテンツのうちの少なくとも１つのための別個のＭａｔｒｏｓｋａコンテナファイル内に含有される代替ストリームが存在するようにエンコードされると、Ｍａｔｒｏｓｋａコンテナファイル内に含有されるメディアの適応型ストリーミングは、ＨＴＴＰ要求または類似ステートレスデータ転送プロトコルを使用して達成されることができる。多くの実施形態では、再生デバイスは、サーバ上に常駐するトップレベルインデックスファイルを要求し、再生デバイスに利用可能なストリームを識別するためのインデックス情報を使用する。再生デバイスは、次いで、Ｍａｔｒｏｓｋａファイルのうちの１つ以上のためのインデックスを読み出すことができ、ＨＴＴＰ要求または類似ステートレスプロトコルを使用して、Ｍａｔｒｏｓｋａコンテナファイル内に含有されるストリームのうちの１つ以上からメディアを要求するために、インデックスを使用することができる。前述のように、本発明の多くの実施形態は、修正されたＣｕｅ要素を使用して、Ｍａｔｒｏｓｋａコンテナファイルのそれぞれに対するインデックスを実装する。しかしながら、いくつかの実施形態では、各ストリームに対するエンコードされたメディアは標準的Ｍａｔｒｏｓｋａコンテナファイル内に含有され、別個のインデックスファイルはまた、コンテナファイルのそれぞれのために提供されることができる。再生デバイスによって経験されるストリーミング状態に基づいて、再生デバイスは、異なるビットレートでエンコードされた代替ストリームから、メディアを選択することができる。ストリームのそれぞれからのメディアが、前述のように、Ｍａｔｒｏｓｋａコンテナファイル中に挿入されると、ストリーム間の遷移が、Ｃｌｕｓｔｅｒ要素内のメディアの再生の完了に応じて生じることができる。したがって、Ｃｌｕｓｔｅｒ要素のサイズ（すなわち、Ｃｌｕｓｔｅｒ要素内のエンコードされたメディアの持続時間）は、一般的には、再生デバイスが、ストリーミング状態の変化およびトリックプレイトラックの利用を伴うユーザからの命令に十分に迅速に対応可能であるように、選定される。Ｃｌｕｓｔｅｒ要素が小さいほど（すなわち、各Ｃｌｕｓｔｅｒ要素内のエンコードされたメディアの持続時間が短いほど）、各Ｃｌｕｓｔｅｒ要素の要求と関連付けられたオーバーヘッドが高くなる。したがって、ストリーミング状態の変化への再生デバイスの応答性と、所与の一組のストリーミング状態に対する適応型ストリーミングシステムの有効データレート（すなわち、エンコードされたメディアを伝送するために実際に利用される、利用可能な帯域幅の部分）との間に、トレードオフが存在する。多くの実施形態では、Ｃｌｕｓｔｅｒ要素のサイズは、各Ｃｌｕｓｔｅｒ要素が、２秒のエンコードされたメディアを含有するように、選定される。他の実施形態では、エンコードされたメディアの持続時間は、２秒超または未満であることができ、および／またはエンコードされたメディアの持続時間は、Ｃｌｕｓｔｅｒ要素毎に変動することができる。

本発明のある実施形態による、トップレベルインデックスファイルによってインデックスされたＭａｔｒｏｓｋａコンテナファイル内に含有される別個のストリームにおいてエンコードされたメディアの再生の間の再生デバイスまたはクライアントとＨＴＴＰサーバとの間の通信は、図８に図示される。図示される実施形態では、再生デバイス２００は、データを受信するために、ＨＴＴＰ要求または類似プロトコルを使用して、サーバ２０２からトップレベルインデックスファイルを要求することによって、再生を始める。サーバ２０２は、要求に対応するバイトを提供する。再生デバイス２００は、次いで、トップレベルインデックスファイルを解析し、ソースメディアの特定の断片から導出されたエンコードされたメディアのストリームを含有するＭａｔｒｏｓｋａコンテナファイルのそれぞれのＵＲＩを識別する。再生デバイスは、次いで、ＨＴＴＰまたは類似プロトコルを介して、Ｍａｔｒｏｓｋａコンテナファイルのうちの１つ以上のヘッダに対応するバイト範囲を要求することができ、バイト範囲は、関連ＭａｔｒｏｓｋａコンテナファイルのためのＵＲＩ内に含有される情報を使用して決定される（前述の議論参照）。サーバは、Ｍａｔｒｏｓｋａコンテナファイルのヘッダを含有するバイト範囲に対する要求に応答して、

の情報を返す。

ＥＢＭＬ要素は、一般的には、ファイルバージョンに対応することを確実にするために、再生デバイスによって処理される。ＳｅｅｋＨｅａｄ要素は、Ｍａｔｒｏｓｋａインデックス要素の場所を見つけるために解析され、ＳｅｇｍｅｎｔＩｎｆｏ要素は、再生において利用される２つの重要な要素を含有する、すなわち、ＴｉｍｅｃｏｄｅＳｃａｌｅおよびＤｕｒａｔｉｏｎである。ＴｉｍｅｃｏｄｅＳｃａｌｅは、ＭａｔｒｏｓｋａコンテナファイルのＳｅｇｍｅｎｔ内の全タイムコードに対するタイムコードスケールを指定し、Ｄｕｒａｔｉｏｎは、ＴｉｍｅｃｏｄｅＳｃａｌｅに基づいて、Ｓｅｇｍｅｎｔの持続時間を指定する。Ｔｒａｃｋｓ要素は、ＭａｔｒｏｓｋａファイルのＣｌｕｓｔｅｒｓ要素内に含有されるエンコードされたメディアをデコードするために、再生デバイスによって使用される情報を含有する。前述のように、本発明の実施形態による、適応型ビットレートストリーミングシステムは、フレームレートおよび解像度を含むが、それらに限定されない、異なるエンコーディングパラメータを使用してエンコードされ異なるストリームに対応することができる。したがって、再生デバイスは、Ｍａｔｒｏｓｋａコンテナファイルのヘッダ内に含有される情報を使用して、遷移が、エンコードされたストリーム間で行われるたびに、デコーダを構成することができる。

多くの実施形態では、再生デバイスは、トップレベルインデックスファイル内でインデックスされたＭａｔｒｏｓｋａコンテナファイルの全部に対して、ヘッダを受信しない。代わりに、再生デバイスは、最初に、再生を始めるために利用されるであろうストリームを決定し、対応するＭａｔｒｏｓｋａコンテナファイルからヘッダを要求する。トップレベルインデックスファイル内に含有されるＵＲＩの構造に応じて、再生デバイスは、ＵＲＩからの情報またはＭａｔｒｏｓｋａコンテナファイルのヘッダからの情報のいずれかを使用して、関連Ｍａｔｒｏｓｋａコンテナファイルからのインデックスの少なくとも部分を含有するサーバからバイト範囲を要求することができる。バイト範囲は、インデックス全体に対応することができる。サーバは、インデックス情報を含有する関連バイト範囲を再生デバイスに提供し、再生デバイスは、インデックス情報を使用して、この情報を使用してエンコードされたメディアを含有するＣｌｕｓｔｅｒ要素のバイト範囲を要求することができる。Ｃｌｕｓｔｅｒ要素が受信されると、再生デバイスは、エンコードされたメディアをＣｌｕｓｔｅｒ要素内のＢｌｏｃｋ要素から抽出することができ、その関連付けられたＴｉｍｅｃｏｄｅ属性に従って、Ｂｌｏｃｋ要素内のメディアをデコードおよび再生することができる。

図示される実施形態では、再生デバイス２００は、再生デバイスが、インデックス情報を使用して、選択されたストリームのそれぞれの全体をストリーミングすることができるように、再生の開始に先立って、十分なインデックス情報をＨＴＴＰサーバから要求する。他の実施形態では、再生デバイスは、メディアが再生されるにつれて、継続的に、インデックス情報を読み出す。いくつかの実施形態では、最低ビットレートストリームに対するインデックス情報は全部、最低ビットレートストリームに対するインデックス情報が、再生の間、ストリーミング状態が急に劣化する場合、再生デバイスに利用可能となるように、再生に先立って、要求される。

（ストリーム間での切り替え）
図８に図示される通信は、再生デバイスが、メディアの再生全体を通して、同一のストリーム（すなわち、Ｍａｔｒｏｓｋａコンテナファイル）から、メディアの要求を継続すると仮定する。実際、再生デバイスによって経験されるストリーミング状態は、ストリーミングメディアの再生の間、変化する可能性が高く、再生デバイスは、代替ストリーム（すなわち、異なるＭａｔｒｏｓｋａコンテナファイル）からメディアを要求し、再生デバイスによって経験されるストリーミング状態のための最良ピクチャ品質を提供することができる。加えて、再生デバイスは、トリックプレイトラックストリームを利用する、トリックプレイ機能を行うために、ストリームを切り替えてもよい。

再生デバイスが、本発明の実施形態に従って、新しいストリームに切り替えるときの再生デバイスとサーバとの間の通信は、図９ａに図示される。図９ａに図示される通信は、新しいストリームのためのインデックス情報が、再生デバイスによって以前に要求されておらず、情報が、新しいストリームを含有するＭａｔｒｏｓｋａコンテナファイルに関して、取得されている間、古いストリームからのＣｌｕｓｔｅｒ要素のダウンロードが進むと仮定する。再生デバイス２００が、ストリーミング状態の変化を検出し、より高いビットレートストリームが、このストリーミング状態で利用することができることを決定する、またはユーザからのトリックプレイ命令を受信すると、再生デバイスは、トップレベルインデックスファイルを使用して、再生デバイスが、現在、エンコードされたメディアを要求している、ビデオ、オーディオ、または字幕ストリームのうちの少なくとも１つにより適切な代替ストリームのためのＵＲＩを識別することができる。再生デバイスは、現在のストリームに関する情報を保存することができ、対応するＵＲＩのパラメータを使用して、新しいストリームを含有するＭａｔｒｏｓｋａコンテナファイルのためのヘッダのバイト範囲を要求することができる。このように情報をキャッシュすることは、再生デバイスが、ストリームのビットレートを下方に適応させようとするときに有益であり得る。再生デバイスが、利用可能な帯域幅の減少を経験すると、再生デバイスは、理想的には、より低いビットレートストリームに迅速に切り替えるであろう。再生デバイスによって経験される帯域幅減少のため、再生デバイスは、ヘッダおよびインデックス情報を要求するための付加的帯域幅を有する可能性が低い。理想的には、再生デバイスは、全利用可能な帯域幅を利用して、既に要求されたより高いレートのＣｌｕｓｔｅｒ要素をダウンロードし、ローカルにキャッシュされたインデックス情報を使用して、より低いビットレートストリームを含有するＭａｔｒｏｓｋａコンテナファイルからのＣｌｕｓｔｅｒ要素の要求を開始する。

新しいストリームを含有するＭａｔｒｏｓｋａコンテナファイルに対するインデックス情報のためのバイト範囲は、図８に関連して前述のように、ＨＴＴＰサーバ２０２から要求されることができる。その時点において、再生デバイスは、以前のストリームからのＣｌｕｓｔｅｒ要素のダウンロードを停止することができ、Ｍａｔｒｏｓｋａコンテナファイルからのインデックス情報を使用して、ＨＴＴＰサーバからの新しいストリームを含有するＭａｔｒｏｓｋａコンテナファイルからの適切なＣｌｕｓｔｅｒ要素のバイト範囲の要求を開始し、再生デバイスによって読み出された最後のＣｌｕｓｔｅｒ要素内のエンコードされたメディアに続くエンコードされたメディアを含有するＣｌｕｓｔｅｒ要素を識別することができる。前述のように、あるストリームから別のストリームへのスムーズな遷移は、対応するＣｌｕｓｔｅｒ要素が、同一のＴｉｍｅｃｏｄｅ要素およびＩＤＲフレームで開始するように、代替ストリームのそれぞれをエンコードすることによって促進される。

再生デバイスが、メディアの再生において利用された各ストリームに対するヘッダおよびインデックス全体をキャッシュすると、以前に使用されたストリームに逆切り替えするプロセスを簡略化することができる。再生デバイスは、既に、以前に利用されたストリームを含有するＭａｔｒｏｓｋａファイルに対するヘッダおよびインデックス情報を有し、再生デバイスは、単に、この情報を使用して、ＨＴＴＰを介して、以前に利用されたストリームのＭａｔｒｏｓｋａコンテナファイルからのＣｌｕｓｔｅｒ要素の要求を開始することができる。本発明のある実施形態による、再生デバイスが、ヘッダおよびインデックス情報をキャッシュしたストリームに逆切り替えするときの再生デバイスとＨＴＴＰサーバとの間の通信は、図９ｂに図示される。図９ｂに図示されるプロセスは、利用可能なリソースの減少が、メディアに加え、インデックス情報をダウンロードする必要性によって悪化され得るため、理想的には、ビットレートを下方に適応させるときに行われる。再生の中断の可能性は、再生デバイスがストリーム間で切り替えを行う速度を増加させ、切り替えを達成するためにダウンロードされるオーバーヘッドデータの量を低減させることによって減少される。

本発明は、ある具体的側面において説明されたが、多くの付加的修正および変形例が、当業者に明白となるであろう。したがって、本発明は、例えば、本発明の範囲および精神から逸脱することなく、それらが準拠する特定の規格内で指定されるもの以外の特徴に対応する、エンコーダおよびデコーダを利用する、実装における種々の変更を含め、具体的に説明される以外に、別様に実践されてもよいことを理解されたい。したがって、本発明の実施形態は、あらゆる観点において、制限ではなく、例示と見なされるべきである。

Claims (35)

1. ソースビデオストリームからビデオの一組の代替ストリームをエンコードする方法であって、
   少なくとも１つのソースエンコーディングサーバシステムを使用して、複数の代替ビデオストリームの各々のための一組のエンコーディングパラメータを選択することと、
   少なくとも１つのソースエンコーディングサーバシステムを使用して、前記複数の代替ビデオストリームの各々の前記エンコーディングパラメータによって前記ソースビデオストリームの離散部分を別個に事前にエンコードすることと、
   少なくとも１つのソースエンコーディングサーバシステムを使用して、複数の代替ビデオストリームの各々のためのコンテナファイルを組み立てることであって、前記コンテナファイルを組み立てることは、
   所与のストリームのための前記エンコーディングパラメータによってエンコードされた別個に事前にエンコードされた離散部分を前記所与のストリームのために前記コンテナファイル内に含むことであって、前記事前にエンコードされた離散部分は、前記所与のストリームのための前記コンテナファイル内にビデオトラック塊として記憶されており、各記憶されたビデオトラック塊は、エンコードされたビデオフレームのシーケンスを含む、ことと、
   各ビデオトラック塊のためのインデックス内にエントリを生成することであって、各ビデオトラック塊のための前記インデックス内の前記エントリは、前記ビデオトラック塊内に含まれるエンコードされたビデオフレームのシーケンスを取得するために対応するビデオトラック塊の開始から要求するためのバイト数に関する情報を含む、ことと、
   各ビデオトラック塊のための前記インデックスを前記所与のストリームのために前記コンテナファイル内に含むことと
   によって行われる、ことと、
   再生デバイスへの適応型ビットレートストリーミングのために、前記複数の代替ビデオストリームのための前記コンテナファイルをサーバにアップロードすることと
   を含み、
   各ビデオトラック塊は、前記コンテナファイル内の任意のタイプの要素である、方法。
2. 所与のストリームのための前記コンテナファイル内の各ビデオトラック塊のための前記インデックスは、各ビデオトラック塊の持続時間に関する情報をさらに含む、請求項１に記載の方法。
3. 所与のストリームのための各ビデオトラック塊は、瞬時復号更新（ＩＤＲ）フレームと開始するクローズドピクチャ群（ＧＯＰ）を含む、請求項１に記載の方法。
4. 所与のストリームのための前記コンテナファイル内の各ビデオトラック塊のための前記インデックスは、前記ビデオトラック塊内に前記ＩＤＲフレームの場所に関する情報をさらに含む、請求項３に記載の方法。
5. 前記複数の代替ビデオストリームのための前記コンテナファイルは、拡張可能バイナリマークアップ言語（ＥＢＭＬ）ファイルであり、各ビデオトラック塊は、ＥＢＭＬファイル内のクラスタ要素である、請求項３に記載の方法。
6. 少なくとも１つのソースエンコーディングサーバシステムを使用して、トップレベルインデックスファイルを生成することであって、前記トップレベルインデックスファイルは、複数の代替ビデオストリームのための各コンテナファイルを説明する情報を含み、前記複数の代替ビデオストリームのための各コンテナファイルを説明する前記情報は、
   前記コンテナファイルがアップロードされるサーバの場所を示す情報と、
   前記コンテナファイル内に含まれる前記ビデオストリームのビットレートと、
   前記コンテナファイル内の各ビデオトラック塊のための前記インデックスの前記コンテナファイル内の場所に関する情報と
   を含む、請求項１に記載の方法。
7. 前記ビットレートは、前記コンテナファイル内に含まれる前記ストリームのための最大ビットレートであり、前記複数の代替ビデオストリーム内の各ストリームは、異なる最大ビットレートを有する、請求項６に記載の方法。
8. 前記複数の代替ビデオストリームのための各コンテナファイルを説明する前記トップレベルインデックスファイル内の前記情報は、複数の画素内の前記コンテナファイル内に含まれる前記ストリームの幅および高さをさらに含む、請求項６に記載の方法。
9. 前記トップレベルインデックスファイル内の前記情報は、最小バッファサイズをさらに含む、請求項６に記載の方法。
10. 前記複数の代替ビデオストリームの各々のためのコンテナファイルを組み立てることは、前記所与のストリームをエンコードするために使用される前記一組のエンコーディングパラメータの少なくとも一部を前記所与のストリームのために前記コンテナファイルのヘッダ内に含むことをさらに含む、請求項６に記載の方法。
11. 前記複数の代替ビデオストリームのための各コンテナファイルを説明する前記トップレベルインデックスファイル内の前記情報は、前記コンテナファイルのヘッダセクションのサイズを説明するヘッダサイズをさらに含む、請求項１０に記載の方法。
12. 前記複数の代替ビデオストリームのための各コンテナファイルを説明する前記トップレベルインデックスファイル内の前記情報は、前記コンテナファイル内の各ビデオトラック塊の場所に関する情報をさらに含む、請求項６に記載の方法。
13. 前記複数の代替ビデオストリームのための各コンテナファイルを説明する前記トップレベルインデックスファイル内の前記情報は、前記コンテナファイル内の各ビデオトラック塊の持続時間に関する情報をさらに含む、請求項１２に記載の方法。
14. 前記複数の代替ビデオストリームの各々のための前記コンテナファイルは、ＨＴＴＰサーバにアップロードされ、前記ＨＴＴＰサーバは、アップロードされた前記コンテナファイルの部分に関するＨＴＴＰバイト範囲要求を受信するように構成されている、請求項１に記載の方法。
15. 前記複数の代替ビデオストリームの各々のエンコーディングパラメータによって前記ソースビデオストリームの離散部分を別個に事前にエンコードすることは、前記複数の代替ビデオストリームの各々のための前記コンテナファイルが前記ソースビデオストリームの同一の離散時間部分に対応するビデオトラック塊を含むように、前記事前にエンコードされた離散部分をエンコードすることをさらに含む、請求項１に記載の方法。
16. 所与のコンテナファイル内の複数のビデオトラック塊は、同一の数のフレームを有するビデオフレームのシーケンスを含む、請求項１５に記載の方法。
17. 前記複数の代替ビデオストリーム内のビデオストリームは、同一の表示アスペクト比を有し、前記ビデオストリームのうちの少なくとも２つは、異なるサンプルアスペクト比を有する、請求項１に記載の方法。
18. 前記複数の代替ビデオストリーム内のビデオストリームは、異なるビットレートを有する、請求項１に記載の方法。
19. 前記複数の代替ビデオストリーム内のビデオストリームは、異なる解像度を有する、請求項１８に記載の方法。
20. ソースビデオストリームからビデオの一組の代替ストリームをエンコードする方法であって、
    少なくとも１つのソースエンコーディングサーバシステムを使用して、複数の代替ビデオストリームの各々のための一組のエンコーディングパラメータを選択することと、
    少なくとも１つのソースエンコーディングサーバシステムを使用して、前記複数の代替ビデオストリームの各々が前記ソースビデオストリームの同一の離散時間部分に対応する事前にエンコードされた離散部分を含むように、前記複数の代替ビデオストリームの各々の前記エンコーディングパラメータによって前記ソースビデオストリームの離散部分を別個に事前にエンコードすることと、
    少なくとも１つのソースエンコーディングサーバシステムを使用して、複数の代替ビデオストリームの各々のためのコンテナファイルを組み立てることであって、前記コンテナファイルを組み立てることは、
    所与のストリームのための前記エンコーディングパラメータによってエンコードされた別個に事前にエンコードされた離散部分を前記所与のストリームのために前記コンテナファイル内に含むことであって、前記事前にエンコードされた離散部分は、前記所与のストリームのための前記コンテナファイル内にクローズドピクチャ群（ＧＯＰ）として記憶されており、前記ＧＯＰは、エンコードされたビデオフレームのシーケンスを含み、瞬時復号更新（ＩＤＲ）フレームと開始する、ことと、
    前記クローズドＧＯＰを含む前記コンテナファイルの各部分のためのインデックス内にエントリを生成することであって、前記クローズドＧＯＰを含む前記コンテナファイルの各部分のための前記インデックス内の前記エントリは、前記クローズドＧＯＰ内に含まれるエンコードされたビデオフレームのシーケンスを取得するために、前記クローズドＧＯＰを含む前記コンテナファイルの部分の開始から要求するためのバイト数に関する情報を含む、ことと、
    前記クローズドＧＯＰを含む前記コンテナファイルの各部分のための前記インデックスを前記所与のストリームのために前記コンテナファイル内に含むことと
    によって行われる、ことと、
    前記複数の代替ビデオストリームのための前記コンテナファイルをサーバにアップロードすることであって、前記複数の代替ビデオストリームは、異なるビットレートでエンコードされている、ことと、
    少なくとも１つのソースエンコーディングサーバシステムを使用して、トップレベルインデックスファイルを生成することであって、前記トップレベルインデックスファイルは、前記複数の代替ビデオストリームのための各コンテナファイルを説明する情報を含み、前記複数の代替ビデオストリームのための各コンテナファイルを説明する前記情報は、
    前記コンテナファイルがアップロードされるサーバの場所を示す情報と、
    前記コンテナファイル内に含まれる前記ビデオストリームのビットレートと、
    前記クローズドＧＯＰを含む前記コンテナファイルの各部分のための前記インデックスの前記コンテナファイル内の場所に関する情報と
    を含む、ことと
    を含み、
    前記クローズドＧＯＰは、前記コンテナファイル内の任意のタイプの要素である、方法。
21. 前記所与のストリームのための前記クローズドＧＯＰを含む前記コンテナファイルの各部分のための前記インデックスは、各クローズドＧＯＰの持続時間に関する情報をさらに含む、請求項２０に記載の方法。
22. 前記所与のストリームのための前記クローズドＧＯＰを含む前記コンテナファイルの各部分のための前記インデックスは、前記クローズドＧＯＰを開始する各ＩＤＲフレームの場所に関する情報をさらに含む、請求項２０に記載の方法。
23. 前記複数の代替ビデオストリームのための前記コンテナファイルは、拡張可能バイナリマークアップ言語（ＥＢＭＬ）ファイルであり、各クローズドＧＯＰは、ＥＢＭＬファイル内のクラスタ要素に書かれている、請求項２０に記載の方法。
24. 前記複数の代替ビデオストリームのための各コンテナファイルを説明する前記トップレベルインデックスファイル内の前記情報は、複数の画素内の前記コンテナファイル内に含まれる前記ストリームの幅および高さをさらに含む、請求項２０に記載の方法。
25. 前記トップレベルインデックスファイル内の前記情報は、最小バッファサイズをさらに含む、請求項２０に記載の方法。
26. 前記複数の代替ビデオストリームの各々のためのコンテナファイルを組み立てることは、前記所与のストリームのための前記コンテナファイルのヘッダにおいて前記所与のストリームをエンコードするために使用される一組のエンコーディングパラメータの少なくとも一部を含むことをさらに含む、請求項２０に記載の方法。
27. 前記複数の代替ビデオストリームのための各コンテンナファイルを説明する前記トップレベルインデックスファイル内の前記情報は、前記コンテナファイルのヘッダセクションのサイズを説明するヘッダサイズをさらに含む、請求項２６に記載の方法。
28. 前記複数の代替ビデオストリームのための各コンテンナファイルを説明する前記トップレベルインデックスファイル内の前記情報は、前記コンテナファイル内の前記クローズドＧＯＰを含む前記コンテナファイルの各部分の場所に関する情報をさらに含む、請求項２０に記載の方法。
29. 前記複数の代替ビデオストリームのための各コンテンナファイルを説明する前記トップレベルインデックスファイル内の前記情報は、前記コンテナファイル内の前記クローズドＧＯＰを含む前記コンテナファイルの各部分の持続時間に関する情報をさらに含む、請求項２０に記載の方法。
30. 前記複数の代替ビデオストリームのための各コンテンナファイルを説明する前記トップレベルインデックスファイル内の前記情報は、
    複数の画素内の前記コンテナファイル内に含まれる前記ストリームの幅および高さと、
    前記コンテナファイル内に含まれる前記ストリームのための最小バッファサイズと、
    前記コンテナファイルのヘッダセクションのサイズを説明するヘッダサイズと
    をさらに含む、請求項２０に記載の方法。
31. 前記複数の代替ビデオストリームの各々のためのコンテナファイルは、ＨＴＴＰサーバにアップロードされ、前記ＨＴＴＰサーバは、アップロードされた前記コンテナファイルの部分に関するＨＴＴＰバイト範囲要求を受信するように構成されている、請求項２０に記載の方法。
32. 少なくとも１つのソースエンコーディングサーバシステムを使用して、前記複数の代替ビデオストリームの各々の前記エンコーディングパラメータによって前記ソースビデオストリームの離散部分を別個に事前にエンコードすることは、前記複数の代替ビデオストリームの各々のための前記コンテナファイルが、前記ソースビデオストリームの同一の離散時間部分に対応するクローズドＧＯＰを含むように、前記事前にエンコードされた離散部分をエンコードすることをさらに含む、請求項２０に記載の方法。
33. 所与のコンテナファイル内の複数のクローズドＧＯＰは、同一の数のフレームを有するビデオフレームのシーケンスを含む、請求項２０に記載の方法。
34. 前記複数の代替ビデオストリーム内のビデオストリームは、同一の表示アスペクト比を有し、前記ビデオストリームのうちの少なくとも２つは、異なるサンプルアスペクト比を有する、請求項２０に記載の方法。
35. 前記複数の代替ビデオストリーム内のビデオストリームは、異なる解像度を有する、請求項２０に記載の方法。