"拡張可能バイナリマークアップ言語EBMLコンテナファイル内にパッケージ化されたエンコードされたビデオの複数の代替ストリームを使用して、適応型ビットレートストリーミングを行うように構成される再生デバイスであって、該複数の代替ストリームの各々は、EBMLコンテナファイルの要素中へパックされたエンコードされたビデオの各部分が、クローズドピクチャ群GOPを始めるイントラフレームで開始し、該EBMLコンテナファイルの各々は、該EBMLコンテナファイル内に含有されるストリームのエンコーディングパラメータを指定する少なくとも1つの要素を含むように、異なる該エンコーディングパラメータを使用してエンコードされた同一のソースビデオであり、該再生デバイスは、クライアントアプリケーションを介して、ファイルの部分を遠隔サーバから要求するように構成されるプロセッサを備え、該クライアントアプリケーションは、複数のEBMLコンテナファイルを識別し、該EBMLコンテナファイル内に含有される該代替ストリームの少なくとも最大のビットレートを記述するトップレベルインデックスデータを読み出すことと、該トップレベルインデックスデータを解析して、該複数のEBMLコンテナファイルを識別する情報を取得することと、該EBMLコンテナファイル内に含有される該ストリームの該エンコーディングパラメータを指定する該少なくとも1つの要素を含有する該EBMLコンテナファイルのうちの少なくとも1つの部分を要求することと、該EBMLコンテナファイルのうちの少なくとも1つ内のエンコードされたビデオの部分を含有する各要素を参照するインデックスを読み出すことと、該インデックスを利用して、エンコードされたビデオの部分を含有する要素を含む第1のEBMLコンテナファイルの部分を要求することと、該要求された要素を受信およびバッファリングすることと、該エンコーディングパラメータを利用して、該バッファリングされた要素内に含有された該エンコードされたビデオをデコードすることと、現在のストリーミング状態を測定することと、デコーディングのために、エンコードされたビデオの部分を含有する要素を読み出すべき該EBMLコンテナファイルの別の1つを選択することであって、該選択は、該測定されたストリーミング状態および該トップレベルデータ内に含有される該代替ストリームのビットレートの記述に基づく、こととを行うように該プロセッサをさらに構成する、再生デバイス。前記EBMLコンテナファイルの各々は、複数のCluster要素を備え、各Cluster要素は、前記エンコードされたビデオの部分を含有し、該Cluster要素の各々の中の該エンコードされたビデオの部分は、イントラフレームで開始し、少なくとも1つのクローズドピクチャ群を含む、請求項1に記載の再生デバイス。前記Cluster要素の各々の中の前記エンコードされたビデオの部分は、同一の持続時間を有する、請求項2に記載の再生デバイス。前記Cluster要素の各々の中の前記エンコードされたビデオの部分は、2秒の持続時間を有する、請求項2に記載の再生デバイス。各Cluster要素は、タイムコードを含有し、該Cluster要素内に含有される前記エンコードされたビデオの部分の各エンコードされたフレームは、別個のBlockGroup要素内に含有される、請求項2に記載の再生デバイス。前記Cluster要素中の第1のBlockGroup要素は、前記イントラフレームを含有する、請求項5に記載の再生デバイス。前記第1のBlockGroup要素は、前記Cluster要素のタイムコードに関して前記イントラフレームのタイムコード属性を指定するBlock要素を含有する、請求項6に記載の再生デバイス。前記エンコードされたビデオの代替ストリームの各々は、異なる最大ビットレートでエンコードされる、請求項1に記載の再生デバイス。前記エンコードされたビデオの代替ストリームのうちの少なくとも2つは、同一の表示アスペクト比においてであるが、異なるサンプルアスペクト比を使用する異なる解像度を用いてエンコードされる、請求項8に記載の再生デバイス。前記EBMLコンテナファイル内に含有されるストリームの前記エンコーディングパラメータを指定する該EBMLコンテナファイルの各々の中の少なくとも1つの要素は、該EBMLコンテナファイル内に含有される前記ビデオストリームのフレーム高さ、フレーム幅、およびサンプルアスペクト比を指定する、請求項9に記載の再生デバイス。前記クライアントアプリケーションは、前記EBMLコンテナファイルのうちの1つからバッファリングされた要素内に含有されるエンコードされたビデオのデコーディングの開始に先立って、前記フレーム高さ、フレーム幅、およびサンプルアスペクト比を設定するように前記プロセッサを構成する、請求項10に記載の再生デバイス。前記エンコードされたビデオの代替ストリームのうちの少なくとも2つは、異なるフレームレートでエンコードされる、請求項8に記載の再生デバイス。前記EBMLコンテナファイル内に含有されるストリームの前記エンコーディングパラメータを指定する該EBMLコンテナファイルの各々の中の少なくとも1つの要素は、該EBMLコンテナファイル内に含有されるビデオストリームのフレームレートを指定する、請求項12に記載の再生デバイス。前記クライアントアプリケーションは、前記EBMLコンテナファイルのうちの1つからバッファリングされた要素内に含有される前記エンコードされたビデオのデコーディングの開始に先立って、前記フレームレートを設定するように前記プロセッサを構成する、請求項13に記載の再生デバイス。前記クライアントアプリケーションは、ハイパーテキスト転送プロトコルHTTPバイト範囲要求を介して、遠隔サーバから、ファイルの部分を要求するように前記再生デバイスを構成する、請求項11に記載の再生デバイス。前記トップレベルインデックスデータは、SMILデータであり、前記複数のEBMLコンテナファイルを識別する情報は、該EBMLコンテナファイルの各々の場所を識別する複数の汎用リソースインジケータURIである、請求項1に記載の再生デバイス。前記SMILデータは、前記URIの各々によって識別される前記EBMLコンテナファイル内に含有されるエンコードされたストリームの最大ビットレートを指定する、請求項1に記載の再生デバイス。前記EBMLコンテナファイル内の前記エンコードされたストリームの部分を含有する要素の各々を参照するインデックスは、該EBMLコンテナファイルの少なくとも1つの要素内に位置し、前記SMILファイルは、前記エンコーディングパラメータを含有する要素を含有する該EBMLコンテナファイルの部分を指定し、前記クライアントアプリケーションは、該SMILファイルを解析して、該エンコーディングパラメータを含有する要素を含有する該EBMLコンテナファイルの部分を識別することと、該エンコーディングパラメータを含有する要素を含有する該EBMLコンテナファイルの部分を要求することとを行うように前記プロセッサを構成する、請求項17に記載の再生デバイス。各EBMLコンテナファイルは、該EBMLコンテナファイル内の前記エンコードされたビデオの部分を含有する各要素を参照するインデックスを含有する少なくとも1つの要素を含み、前記クライアントアプリケーションは、該インデックスを含有する少なくとも1つの要素を含む該EBMLコンテナファイルの部分を要求することによって、該EBMLコンテナファイル内のエンコードされたビデオの部分を含有する各要素を参照するインデックスを読み出すように前記プロセッサを構成する、請求項1に記載の再生デバイス。前記インデックスは、前記EBMLコンテナファイル内のCue要素内に位置する、請求項19に記載の再生デバイス。前記Cue要素は、時間属性を含み、前記EBMLファイル内のエンコードされたビデオの部分を含有する各要素の場所を指し示す複数のCuePoint要素を含む、請求項20に記載の再生デバイス。前記クライアントアプリケーションは、前記インデックス内の前記CuePoint要素の時間属性を使用して、前記EBMLファイル内のエンコードされたビデオの特定の部分を含有する要素の場所を検索することと、該CuePoint要素を使用して識別された少なくとも該要素を含む該EBMLファイルの部分を要求することとを行うように前記プロセッサを構成する、請求項21に記載の再生デバイス。前記エンコードされたビデオをデコードするために利用される前記エンコーディングパラメータは、フレームレート、フレーム高さ、フレーム幅、サンプルアスペクト比、最大ビットレート、および最小バッファサイズから成る群から選択される少なくとも1つのエンコーディングパラメータを含む、請求項1に記載の再生デバイス。前記クライアントアプリケーションは、前記要素が要求された時間から、要求された要素を受信するためにかかった時間を測定することによって、現在のストリーミング状態を測定するように前記プロセッサを構成する、請求項1に記載の再生デバイス。前記クライアントアプリケーションは、最初に、第1のEBMLコンテナファイル内に含有されるストリームの前記エンコーディングパラメータを指定する少なくとも1つの要素を含有する該第1のEBMLコンテナファイルの部分を要求するように前記プロセッサを構成し、該クライアントアプリケーションは、該クライアントアプリケーションが前記測定されたストリーミング状態および前記トップレベルインデックス内に含有される前記代替ストリームのビットレートの記述に基づいて第2のEBMLコンテナファイルからデコードするために、エンコードされたビデオの部分を含有する要素を読み出すことを選択するとき、該第2のEBMLコンテナファイル内に含有されるストリームのエンコーディングパラメータを指定する少なくとも1つの要素を含有する該第2のEBMLコンテナファイルの部分を要求するように前記プロセッサをさらに構成する、請求項1に記載の再生デバイス。前記再生デバイスは、トリックプレイトラックを含有するEBMLコンテナファイルを使用して、適応型ビットレートストリーミングを行うようにさらに構成される、請求項1に記載の再生デバイス。前記クライアントアプリケーションは、ユーザ命令に応答してエンコードされたビデオの部分を含有する要素を読み出すべき前記EBMLコンテナファイルとして、前記トリックプレイトラックを含有する該EBMLコンテナファイルを選択するように前記プロセッサを構成する、請求項26に記載の再生デバイス。前記再生デバイスは、エンコードされたオーディオのトラックを含有する少なくとも1つのEBMLコンテナファイルを使用して、適応型ストリーミングを行うようにさらに構成される、請求項1に記載の再生デバイス。前記クライアントアプリケーションは、エンコードされたオーディオをオーディオトラックを含有する前記少なくとも1つのEBMLコンテナファイルのうちの1つから読み出し、デコードし、該デコードされたオーディオを前記デコードされたビデオと同期させるように前記プロセッサを構成する、請求項28に記載の再生デバイス。前記EBMLコンテナファイルの各々は、前記エンコードされたビデオで多重化された少なくとも1つのエンコードされたオーディオのトラックを含有する要素を含む、請求項1に記載の再生デバイス。前記クライアントアプリケーションは、前記エンコードされたオーディオのトラックのうちの1つの部分を含む要素を含有する前記EBMLファイルの部分を読み出すことと、該読み出され、エンコードされたオーディオをデコードすることと、該デコードされたオーディオと前記デコードされたビデオとを同期させることとを行うように構成される、請求項28に記載の再生デバイス。前記再生デバイスは、字幕トラックを含有する少なくとも1つのEBMLコンテナファイルを使用して、適応型ストリーミングを行うようにさらに構成される、請求項1に記載の再生デバイス。前記クライアントアプリケーションは、字幕を字幕トラックを含有する前記少なくとも1つのEBMLコンテナファイルのうちの1つから読み出すことと、該字幕を前記デコードされたビデオと同期させることと、該字幕を該デコードされたビデオ上にオーバレイすることとを行うように前記プロセッサを構成する、請求項32に記載の再生デバイス。前記EBMLコンテナファイルの各々は、前記エンコードされたビデオで多重化された少なくとも1つの字幕トラックを含有する要素を含む、請求項1に記載の再生デバイス。前記クライアントアプリケーションは、前記字幕トラックのうちの1つの部分を含む要素を含有する前記EBMLファイルの部分を読み出すことと、該字幕を前記デコードされたビデオと同期させることと、該字幕を該デコードされたビデオ上にオーバレイすることとを行うように構成される、請求項34に記載の再生デバイス。拡張可能バイナリマークアップ言語EBMLコンテナファイル内にパッケージ化されたエンコードされたビデオの複数の代替ストリームを使用して、再生デバイス上でメディアの適応型ビットレートストリーミングを行う方法であって、該ビデオの代替ストリームの各々は、EBMLコンテナファイルの要素中へパックされたエンコードされたビデオの各部分が、クローズドピクチャ群GOPを始めるイントラフレームで開始し、該EBMLコンテナファイルの各々は、該EBMLコンテナファイル内に含有されるストリームのエンコーディングパラメータを指定する少なくとも1つの要素を含むように、異なるエンコーディングパラメータを使用してエンコードされた同一のソースビデオであり、該方法は、該複数のEBMLコンテナファイルの各々を識別し、該EBMLコンテナファイル内に含有される該代替ストリームの各々の少なくとも最大ビットレートを記述するトップレベルインデックスデータを読み出すことと、該トップレベルインデックスデータを解析して、該複数のEBMLコンテナファイルを識別する情報を取得することと、該EBMLコンテナファイル内に含有されるストリームの該エンコーディングパラメータを指定する少なくとも1つの要素を含有する該EBMLコンテナファイルのうちの少なくとも1つの部分を要求することと、該EBMLコンテナファイルのうちの少なくとも1つ内のエンコードされたビデオの部分を含有する各要素を参照するインデックスを読み出すことと、該インデックスを利用して、エンコードされたビデオの部分を含有する要素を含む第1のEBMLコンテナファイルの部分を要求することと、該要求された要素を受信およびバッファリングすることと、該エンコーディングパラメータを使用して、該バッファリングされた要素内に含有される該エンコードされたビデオをデコードすることと、現在のストリーミング状態を測定することと、デコーディングのために、エンコードされたビデオの部分を含有する要素を読み出すべき該EBMLコンテナファイルの別の1つを選択することであって、該選択は、該測定されたストリーミング状態および該トップレベルインデックスデータ内に含有される該代替ストリームのビットレートの記述に基づいている、ことと含む、方法。コンテナファイル内にパックされる複数の代替ビデオストリームとしてソースビデオをエンコードするように構成されるソースエンコーダであって、該コンテナファイルは、拡張可能バイナリマークアップ言語EBMLファイルであり、該ソースエンコーダは、ソースエンコーディングアプリケーションを介して、ソースビデオを含有する少なくとも1つのマルチメディアファイルを取り込むように構成されるプロセッサを備え、該ソースエンコーディングアプリケーションは、該ソースビデオの部分を選択することと、該ソースビデオの該選択された部分をエンコードされたビデオの複数の代替部分にトランスコードすることであって、各代替部分は、異なる一組のエンコーディングパラメータを使用してエンコードされ、クローズドピクチャ群GOPを始めるイントラフレームで開始する、ことと、該エンコードされたビデオの代替部分の各々を異なるEBMLコンテナファイルの要素に書き込むことであって、各要素は、該エンコードされたビデオの代替部分をエンコードするために使用される該エンコーディングパラメータを示す別の要素もまた含むEBMLコンテナファイル内に位置する、ことと、あるエントリを該EBMLコンテナファイルの各々の中の該エンコードされたビデオの代替部分のうちの1つを含有する要素の場所を識別する少なくとも1つのインデックスに追加することとを行うように該プロセッサを構成する、ソースエンコーダ。前記ソースビデオの選択された部分をトランスコードすることは、該選択された部分を少なくとも1つのクローズドピクチャ群にトランスコードすることをさらに含む、請求項37に記載のソースエンコーダ。前記ソースビデオの部分は、前記ソースビデオの選択された部分の持続時間に基づいて選択される、請求項37に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、2秒の持続時間を有する前記ソースビデオの部分を選択するように前記プロセッサを構成する、請求項39に記載のソースエンコーダ。前記エンコードされたビデオの代替部分の各々は、異なる最大ビットレートでエンコードされる、請求項37に記載のソースエンコーダ。前記エンコードされたビデオの代替部分のうちの少なくとも2つは、異なる解像度でエンコードされる、請求項41に記載のソースエンコーダ。前記エンコードされたビデオの代替部分のうちの少なくとも2つは、異なるフレームレートでエンコードされる、請求項41に記載のソースエンコーダ。エンコードされたビデオの各代替部分が書き込まれる前記EBMLコンテナファイルの要素は、タイムコードを含有するCluster要素であり、該エンコードされたビデオの部分は、該Cluster要素内のBlockGroup要素内に含有される、請求項37に記載のソースエンコーダ。前記Cluster要素内に含有される前記エンコードされたビデオの代替部分の各エンコードされたフレームは、別個のBlockGroup要素内に含有される、請求項44に記載のソースエンコーダ。前記Cluster要素内の第1のBlockGroup要素は、IDRフレームを含有する、請求項45に記載のソースエンコーダ。前記第1のBlockGroup要素は、前記Cluster要素のタイムコードに対して、前記IDRフレームのタイムコード属性を指定するBlock要素を含有する、請求項46に記載のソースエンコーダ。前記エンコードされたビデオの代替部分の各々が書き込まれる各要素は、同一のタイムコードが割り当てられる、請求項37に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、前記EBMLコンテナファイルの各々のためのインデックスを作成するように前記プロセッサをさらに構成する、請求項37に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、前記EBMLコンテナファイルの各々の中の前記エンコードされたビデオの代替部分のうちの1つを含有する要素の場所を、該EBMLコンテナファイルのためのインデックスに追加するように前記プロセッサをさらに構成する、請求項49に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、各EBMLコンテナファイルのための前記インデックスを該EBMLコンテナファイル中へパックするように前記プロセッサをさらに構成する、請求項49に記載のソースエンコーダ。各インデックスは、Cues要素を備える、請求項51に記載のソースエンコーダ。各Cue要素は、前記EBMLファイル内の前記エンコードされたビデオの代替部分のうちの1つを含有する要素の場所を指し示すCuePoint要素を含む、請求項52に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、前記EBMLコンテナファイルの各々を識別するトップレベルインデックスファイルを作成するように前記プロセッサをさらに構成する、請求項37に記載のソースエンコーダ。前記取り込まれたマルチメディアファイルはまた、ソースオーディオを含む、請求項37に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、オーディオを前記EBMLコンテナファイルの各々の中に多重化するように前記プロセッサを構成する、請求項55に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、前記オーディオを別個のEBMLコンテナファイルに書き込むように前記プロセッサを構成する、請求項55に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、前記少なくとも1つのオーディオトラックのうちの少なくとも1つをトランスコードするように前記プロセッサをさらに構成する、請求項55に記載のソースエンコーダ。前記取り込まれたマルチメディアファイルは、字幕をさらに備える、請求項55に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、前記字幕を前記EBMLコンテナファイルの各々の中に多重化するように前記プロセッサを構成する、請求項59に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、前記字幕を別個のEBMLコンテナファイルに書き込むように前記プロセッサを構成する、請求項59に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、前記ソースビデオをトランスコードして、より低いフレームレートトリックプレイトラックを作成し、および該トリックプレイトラックを別個のEBMLコンテナファイルに書き込むように前記プロセッサをさらに構成する、請求項37に記載のソースエンコーダ。前記トリックプレイトラックはまた、前記ソースビデオよりも低い解像度である、請求項62に記載のソースエンコーダ。前記ソースエンコーディングアプリケーションは、一組のエンコーディングパラメータを含有する要素を前記EBMLコンテナファイルの各々の中に書き込むように前記プロセッサをさらに構成する、請求項37に記載のソースエンコーダ。前記一組のエンコーディングパラメータは、フレームレート、フレーム高さ、フレーム幅、サンプルアスペクト比、最大ビットレート、および最小バッファサイズから成る群から選択される少なくとも1つのパラメータを含む、請求項64に記載のソースエンコーダ。ソースエンコーダを使用して、拡張可能バイナリマークアップ言語EBMLファイル中にパックされる複数の代替ストリームとして、ソースビデオをエンコードする方法であって、該方法は、該ソースエンコーダを使用して、該ソースビデオの部分を繰り返し選択することと、該ソースエンコーダを使用して、該ソースビデオの該選択された部分をエンコードされたビデオの複数の代替部分にトランスコードすることであって、各代替部分は、異なる一組のエンコーディングパラメータを使用してエンコードされ、クローズドピクチャ群GOPを始めるイントラフレームで開始する、ことと、該ソースエンコーダを使用して、該エンコードされたビデオの代替部分の各々を異なるEBMLコンテナファイルの要素に書き込むことであって、各要素は、該ビデオの部分をエンコードするために使用される該エンコーディングパラメータに対応する一組のエンコーディングパラメータを含有する別の要素もまた含むEBMLコンテナファイル内に位置する、ことと、あるエントリを該EBMLコンテナファイルの各々の中の該エンコードされたビデオの代替部分のうちの1つを含有する要素の場所を識別する少なくとも1つのインデックスに追加することとを含む、方法。本発明の実施形態による、ハイパーテキスト転送プロトコルHTTPを利用するMatroskaコンテナファイル内に記憶されるメディアの適応型ビットレートストリーミングのためのシステムおよび方法が開示される。一実施形態では、プロセッサは、クライアントアプリケーションを介して、ファイルの部分を遠隔サーバから要求するように構成される。加えて、クライアントアプリケーションはさらに、複数のEBMLコンテナファイルを識別し、EBMLコンテナファイル内に含有される代替ストリームの少なくとも最大のビットレートを記述する、トップレベルインデックスデータを読み出し、トップレベルインデックスデータを解析し、複数のEBMLコンテナファイルを識別する情報を取得し、EBMLコンテナファイル内に含有されるストリームのエンコーディングパラメータを指定する少なくとも1つの要素を含有する、EBMLコンテナファイルのうちの少なくとも1つの部分を要求し、EBMLコンテナファイルのうちの少なくとも1つ内のエンコードされたビデオの部分を含有する各要素を参照する、インデックスを読み出し、インデックスを利用して、エンコードされたビデオの部分を含有する要素を含む、第1のEBMLコンテナファイルの部分を要求し、要求された要素を受信およびバッファリングし、エンコーディングパラメータを利用して、バッファリングされた要素内に含有されるエンコードされたビデオをデコードし、現在のストリーミング状態を測定し、測定されたストリーミング状態およびトップレベルデータ内に含有される代替ストリームのビットレートの記述に基づいて、デコーディングのために、エンコードされたビデオの部分を含有する要素を読み出すべきEBMLコンテナファイルの別の1つを選択するように、プロセッサを構成する。さらなる実施形態は、複数のEBMLコンテナファイルのそれぞれを識別し、EBMLコンテナファイル内に含有される代替ストリームのそれぞれの少なくとも最大のビットレートを記述するトップレベルインデックスデータを読み出すステップと、トップレベルインデックスデータを解析し、複数のEBMLコンテナファイルを識別する情報を取得するステップと、EBMLコンテナファイル内に含有されるストリームのエンコーディングパラメータを指定する、少なくとも1つの要素を含有する、EBMLコンテナファイルのうちの少なくとも1つの部分を要求するステップと、EBMLコンテナファイルのうちの少なくとも1つ内の各エンコードされたビデオの部分を含有する要素を参照する、インデックスを受信するステップと、インデックスを利用して、エンコードされたビデオの部分を含有する要素を含む、第1のEBMLコンテナファイルの部分を要求するステップと、要求された要素を受信およびバッファリングするステップと、エンコーディングパラメータを使用して、バッファリングされた要素内に含有されるエンコードされたビデオをデコードするステップと、現在のストリーミング状態を測定するステップと、デコーディングのために、エンコードされたビデオの部分を含有する要素を受信するべきEBMLコンテナファイルの別の1つを選択するステップであって、選択は、測定されたストリーミング状態およびトップレベルインデックスデータ内に含有される代替ストリームのビットレートの記述に基づく、ステップとを含む。本発明の別の実施形態は、ソースエンコーディングアプリケーションを介して、ソースビデオを含有する少なくとも1つのマルチメディアファイルを取り込むように構成される、プロセッサを含む。加えて、ソースエンコーディングアプリケーションはさらに、ソースビデオの部分を選択し、ソースビデオの選択された部分をエンコードされたビデオの複数の代替部分にトランスコードし、各代替部分は、異なる一組のエンコーディングパラメータを使用してエンコードされ、クローズドピクチャ群GOPを始めるイントラフレームで開始し、エンコードされたビデオの代替部分のそれぞれを異なるEBMLコンテナファイルの要素に書き込み、各要素は、エンコードされたビデオの代替部分をエンコードするために使用されるエンコーディングパラメータを示す、別の要素もまた含む、EBMLコンテナファイル内に位置し、あるエントリを、EBMLコンテナファイルのそれぞれ内のエンコードされたビデオの代替部分のうちの1つを含有する要素の場所を識別する、少なくとも1つのインデックスに追加するように、プロセッサを構成する。別のさらなる実施形態は、ソースエンコーダを使用して、ソースビデオの部分を繰り返し選択するステップと、ソースエンコーダを使用して、ソースビデオの選択された部分をエンコードされたビデオの複数の代替部分にトランスコードするステップであって、各代替部分は、異なる一組のエンコーディングパラメータを使用して、エンコードされ、クローズドピクチャ群GOPを始めるイントラフレームで開始する、ステップと、ソースエンコーダを使用して、エンコードされたビデオの代替部分のそれぞれを異なるEBMLコンテナファイルの要素に書き込むステップであって、各要素は、ビデオの部分をエンコードするために使用されるエンコーディングパラメータに対応する一組のエンコーディングパラメータを含有する別の要素もまた含む、EBMLコンテナファイル内に位置する、ステップと、あるエントリを、EBMLコンテナファイルのそれぞれ内のエンコードされたビデオの代替部分のうちの1つを含有する要素の場所を識別する、なくとも1つのインデックスに追加するステップとを含む。次に、図面を参照すると、本発明の実施形態による、ハイパーテキスト転送プロトコルHTTPを利用するMatroskaコンテナファイル内に記憶されたメディアの適応型ビットレートストリーミングのためのシステムおよび方法が図示されている。いくつかの実施形態では、ソースメディアは、いくつかの代替ストリームとして、エンコードされる。各ストリームは、MatroskaMKVコンテナファイル内に記憶される。多くの実施形態では、Matroskaコンテナファイルは、各ストリーム内のメディアがエンコードされ、コンテナ内に記憶される様式が、ストリーミング性能を改善するように制約されるという点において、特殊Matroskaコンテナファイルである。いくつかの実施形態では、Matroskaコンテナファイルは、付加的インデックス要素すなわち、Matroskaコンテナ形式の部分として指定されない要素が、適応型ビットレートストリーミングの間、所望のメディアの読み出しを促進するために、ファイル内に含まれることができるという点において、さらに特殊である。いくつかの実施形態では、各ストリームすなわち、オーディオ、ビデオ、または字幕は、別個のMatroskaコンテナファイル内に記憶される。他の実施形態では、エンコードされたビデオストリームは、各Matroskaコンテナファイル内の1つ以上のエンコードされたオーディオおよび/または字幕ストリームで多重化される。コンテナファイルのそれぞれ内に含有されるストリームへのインデックスを含有する、トップレベルインデックスファイルもまた、エンコードされたメディアの適応型ビットレートストリーミングを可能にするように生成される。多くの実施形態では、トップレベルインデックスファイルは、Matroskaコンテナファイルのそれぞれに対するURIを含有する同期マルチメディア統合言語SMILファイルである。他の実施形態では、種々のファイル形式のいずれも、トップレベルインデックスファイルの生成において利用されることができる。本発明の実施形態による、適応型ビットレートストリーミングシステムの性能は、ビデオの部分が、瞬時復号更新IDRフレームで開始する単一または、少なくとも1つのクローズドピクチャ群GOPとして、各ストリーム内にエンコードされるように、各ビットレートにおいて、ソースビデオの各部分をエンコードすることによって、有意に向上されることができる。各ストリームのためのGOPは、次いで、ストリームのためのMatroskaコンテナファイル内のCluster要素として記憶されることができる。このように、再生デバイスは、の再生完了時、ストリーム間で切り替えることができ、クラスタが取得されるストリームに関係なく、クラスタ内の第1のフレームは、IDRフレームであって、Cluster要素内に含有されるエンコードされたメディア以外の任意のエンコードされたメディアを参照せずに、デコードされることができる。多くの実施形態では、GOPとしてエンコードされるソースビデオのセクションはすべて、同一の持続時間である。いくつかの実施形態では、ソースビデオの各2秒のシーケンスが、GOPとしてエンコードされる。適応型ストリーミングの間、HTTPを使用するメディアの読み出しは、付加的インデックス情報をエンコードされたストリームのそれぞれを含有するために使用されるMatroskaコンテナファイルに追加することによって、改善されることができる。いくつかの実施形態では、インデックスは、インデックスが各クラスタの開始時のIDRにのみポイントするという点において、簡略インデックスである。多くの実施形態では、Matroskaコンテナファイルのインデックスは、再生デバイスが、バイト範囲要求を使用して、HTTPを介して、Cluster要素をMatroskaコンテナファイルから読み出すことができるように、クラスタのそれぞれのサイズを指定する、付加的非標準的属性すなわち、Matroskaコンテナファイル形式仕様の部分を形成しない、属性を含む。前述のようにエンコードされたソースメディアの適応型ストリーミングは、本発明の実施形態による、再生デバイスによって調整されることができる。再生デバイスは、トップレベルインデックスファイルから、利用可能なストリームのそれぞれに関する情報を取得し、1つ以上のストリームを選択し、メディアの再生において利用する。再生デバイスは、次いで、ヘッダ情報を1つ以上のビットストリームまたはストリームを含有するMatroskaコンテナファイルから取得することができ、ヘッダが、ストリームのデコーディングに関する情報を提供する。再生デバイスはまた、関連Matroskaコンテナファイル内に記憶されるエンコードされたメディアをインデックス化するインデックス情報を要求することができる。インデックス情報は、Matroskaコンテナファイル内に、あるいはMatroskaコンテナファイルとは別個に、トップレベルインデックスまたは別個のインデックスファイル内に記憶されることができる。インデックス情報は、再生デバイスが、サーバから、HTTPを経由して、エンコードされたメディアの特定の部分を含有するMatroskaコンテナファイル内のCluster要素に対応するバイト範囲を要求することを可能にする。再生デバイスが、Cluster要素をHTTPサーバから受信するにつれて、再生デバイスは、現在のストリーミング状態を評価し、ストリーミングされるメディアのビットレートを増加または減少すべきかどうかを決定することができる。再生デバイスが、ビットレート内の変化が必要であると決定する場合、再生デバイスは、所望のストリームを含有するコンテナファイルに対するヘッダ情報およびインデックス情報を取得することができる再生デバイスが、この情報を既に取得していないと仮定して。インデックス情報は、次いで、所望のビットレートでエンコードされたソースメディアの次の部分を含有するCluster要素のバイト範囲を識別するために使用されることができ、識別されたCluster要素は、HTTPを介して、サーバから読み出されることができる。要求されるソースメディアの次の部分は、一般的には、再生デバイスによって既に要求されたCluster要素および再生デバイスによってバッファリングされたCluster要素に基づいて識別される。代替ストリームから要求されるソースメディアの次の部分は、再生デバイスによる、ソースメディアの次の部分を含有するCluster要素の受信に先立って、再生デバイスのバッファがアンダーフローすなわち、再生するためのメディアの枯渇を起こすであろう可能性を最小にするために要求される。このように、再生デバイスは、Matroskaコンテナファイルのそれぞれ内のCluster要素を記述するトップレベルインデックスおよびインデックス情報を使用して、ストリーミング状態に対する適切性に応じて、順次Cluster要素を種々のストリームから読み出すことによって、適応型ビットレートストリーミングを達成することができる。いくつかの実施形態では、異なるストリーム間のビットレートの変動は、ビットレート、フレームレート、および解像度を含むが、それらに限定されない各ストリームに対するエンコーディングパラメータを修正することによって、達成されることができる。異なるストリームが異なる解像度を含むとき、各ストリームの表示アスペクト比は、同一であって、サンプルアスペクト比は、ある解像度から別の解像度へのスムーズな遷移を確実にするように修正される。適応型ビットレートストリーミングにおける使用のためのソースビデオのエンコーディングと、本発明の実施形態による、適応型ビットレートストリーミングを達成するためのHTTP要求を使用したエンコードされたソースビデオの再生は、以下にさらに論じられる。適応型ストリーミングシステムアーキテクチャ本発明のある実施形態による、適応型ストリーミングシステムは、図1に図示される。適応型ストリーミングシステム10は、いくつかの代替ストリームとして、ソースメディアをエンコードするように構成されるソースエンコーダ12を含む。図示される実施形態では、ソースエンコーダは、サーバである。他の実施形態では、ソースエンコーダは、プロセッサと、ソースメディアビデオ、オーディオ、および/または字幕を含むが、それらに限定されないのトランスコーディングを行うための十分なリソースとを含む、任意の処理デバイスであることができる。以下にさらに論じられるように、ソースエンコーディングサーバ12は、ストリームを含有する複数のコンテナファイルへのトップレベルインデックスを生成し、そのうちの少なくとも複数は、代替ストリームである。代替ストリームは、同一のメディアコンテンツを異なる方法でエンコードする、ストリームである。多くの事例では、代替ストリームは、異なるビットレートでメディアコンテンツ限定されないが、ビデオ等をエンコードする。いくつかの実施形態では、代替ストリームは、異なる解像度および/または異なるフレームレートでエンコードされる。トップレベルインデックスファイルおよびコンテナファイルは、HTTPサーバ14にアップロードされる。種々の再生デバイスは、次いで、HTTPまたは別の適切なステートレスプロトコルを使用して、インターネット等のネットワーク16を介して、トップレベルインデックスファイルおよびコンテナファイルの部分を要求することができる。多くの実施形態では、トップレベルインデックスファイルは、SMILファイルであって、メディアは、Matroskaコンテナファイル内に記憶される。以下にさらに論じられるように、メディアは、メディアの適応型ビットレートストリーミングを促進するように、Matroskaコンテナファイル内に記憶されることができる。多くの実施形態では、Matroskaコンテナファイルは、メディアの適応型ビットレートストリーミングの間、HTTPを介して、メディアの特定の部分の読み出しを促進する、強化すなわち、Matroskaファイル形式仕様の部分を形成しない要素を含む、特殊Matroskaコンテナファイルである。図示される実施形態では、再生デバイスは、パーソナルコンピュータ18および携帯電話20を含む。他の実施形態では、再生デバイスは、消費者電子機器デバイス、例えば、DVDプレーヤ、Blu-ray登録商標プレーヤ、テレビ、セットトップボックス、ビデオゲームコンソール、タブレット、およびHTTPを介して、サーバに接続し、エンコードされたメディアを再生可能である、他のデバイスを含むことができる。具体的アーキテクチャは、図1に示されるが、任意の種々のアーキテクチャのいずれも、再生デバイスが、本発明の実施形態に従って、トップレベルインデックスファイルおよびコンテナファイルの部分を要求することを可能にするように利用されることができる。ファイル構造本発明の実施形態による、再生デバイスへのストリーミングのために、ソースエンコーダによって生成され、および/またはHTTPサーバ上に記憶される、ファイルは、図2に図示される。ソースメディアの適応型ビットレートストリーミング内で利用されるファイルは、トップレベルインデックス30と、それぞれ、少なくとも1つのストリームを含有する、複数のコンテナファイル32とを含む。トップレベルインデックスファイルは、コンテナファイルのそれぞれのコンテンツを記述する。以下にさらに論じられるように、トップレベルインデックスファイルは、SMILファイルを含む、種々の形態をとることができ、コンテナファイルは、特殊Matroskaコンテナファイルを含む、種々の形態をとることができる。多くの実施形態では、各Matroskaコンテナファイルは、単一ストリームを含有する。例えば、ストリームは、いくつかの代替ビデオストリームのうちの1つ、オーディオストリーム、いくつかの代替オーディオストリームのうちの1つ、字幕ストリーム、いくつかの代替字幕ストリームのうちの1つ、トリックプレイストリーム、またはいくつかの代替トリックプレイストリームのうちの1つであり得る。いくつかの実施形態では、Matroskaコンテナファイルは、複数の多重化されたストリームを含む。例えば、Matroskaコンテナは、ビデオストリーム、および1つ以上のオーディオストリーム、1つ以上の字幕ストリーム、および/または1つ以上のトリックプレイストリームを含み得る。以下にさらに論じられるように、多くの実施形態では、Matroskaコンテナファイルは、特殊ファイルである。メディアのエンコーディングおよびメディアがMatroskaコンテナファイル内のCluster要素内に記憶される様式は、適応型ビットレートストリーミングシステムの性能を向上させるように設計される制約を条件とすることができる。加えて、Matroskaコンテナファイルは、メディアの適応型ストリーミングの間、種々のMatroskaコンテナファイルからのCluster要素の特定およびダウンロードを促進する、インデックス要素を含むことができる。本発明の実施形態による適応型ビットレートストリーミングシステムにおいて使用されることができるトップレベルインデックスファイルおよびMatroskaコンテナファイルは、以下に論じられる。トップレベルインデックスファイル本発明の多くの実施形態による、再生デバイスは、トップレベルインデックスファイルを利用して、適応型ビットレートストリーミングにおいて使用するための再生デバイスに利用可能なストリームを含有する、コンテナファイルを識別する。多くの実施形態では、トップレベルインデックスファイルは、それぞれ、エンコードされたメディアの代替ストリームを含むコンテナファイルへの参照を含むことができる。再生デバイスは、トップレベルインデックスファイル内の情報を利用して、再生デバイスによって経験されるストリーミング状態に従って、コンテナファイルのそれぞれからエンコードされたメディアを読み出すことができる。いくつかの実施形態では、トップレベルインデックスファイルは、再生デバイスが、コンテナファイルのそれぞれ内のメディアのエンコーディングに関する情報と、コンテナファイルのそれぞれ内のエンコードされたメディアへのインデックスを読み出すことを可能にする、情報を提供する。いくつかの実施形態では、各コンテナファイルは、コンテナファイル内に含有されるエンコードされたメディアに関する情報と、コンテナファイル内のエンコードされるメディアへのインデックスを含み、トップレベルインデックスファイルは、この情報を含有する各コンテナファイルの部分を示す。したがって、再生デバイスは、トップレベルインデックスファイルを読み出し、トップレベルインデックスファイルを使用して、コンテナファイル内に含有されるエンコードされたメディアに関する情報と、コンテナファイル内のエンコードされるメディアへのインデックスを含む、コンテナファイルのうちの1つ以上の部分を要求することができる。本発明の実施形態による、適応型ビットレートストリーミングシステムにおいて使用されることができる、種々のトップレベルインデックスファイルは、以下でさらに論じられる。トップレベルインデックスSMILファイルいくつかの実施形態では、メディアの適応型ビットレートストリーミングにおいて利用されるトップレベルインデックスファイルは、SMILファイルであって、これは、ストリームのそれぞれを記述するURIおよびストリームを含有するコンテナファイルのリストを含む、XMLファイルである。URIは、情報、例えば、ストリーム内に含有されるストリームのシステム-ビットレートおよびコンテナファイル内のデータの特定の断片の場所に関する情報を含むことができる。SMILファイルの基本的構造は、XML宣言およびSMIL要素を提供することを伴う。SMIL要素は、適応型ビットレートストリーミングにおいて使用するために利用可能なストリームを定義し、一般的には、空のままにされる、HEAD要素と、一般的には、PARパラレル要素のみを含有する、BODY要素とを含む。PAR要素は、同時に再生することができる、ストリームすなわち、同時に提示されることができる、メディアを含むを記述する。SMIL仕様は、適応型ビットレートストリーミングにおいて使用するために利用可能なストリームを指定するために利用されることができるPAR要素に対して、いくつかの子要素を定義する。VIDEO、AUDIO、およびTEXTSTREAM要素は、特定のビデオ、オーディオ、または字幕ストリームを定義するために利用されることができる。VIDEO、AUDIO、およびTEXTSTREAM要素は、集合的に、メディアオブジェクトと称されることができる。メディアオブジェクトの基本的属性は関連ストリームを含有するコンテナファイルへの完全パスまたはURIを指定するSRC属性と、3文字の言語コードを含むXML:LANG属性である。メディアオブジェクトに関する付加的情報は、PARAM要素を使用して指定することができる。PARAM要素は、一般的な名前と値との組を提供するためのSMIL形式内の標準的方法である。本発明のいくつかの実施形態では、特定のPARAM要素は、適応型ビットレートストリーミングの間に利用されるように定義される。多くの実施形態では、ヘッダ-要求PARAM要素は、ストリームを含有するコンテナファイルのヘッダセクションのサイズを指定するように定義される。ヘッダ-要求PARAM要素の値は、一般的には、ファイルの開始とファイル内のエンコードされたメディアの開始との間のバイト数を指定する。多くの実施形態では、ヘッダは、メディアがエンコードされる様式に関する情報を含有し、再生デバイスは、エンコードされたメディアの再生のためのデコーダを構成可能にするために、エンコードされたメディアの再生に先立って、ヘッダを読み出す。ヘッダ-要求PARAM要素の実施例は、である。いくつかの実施形態では、mimePARAM要素は、ストリームのMIMEタイプを指定するように定義される。ストリームをH.264ストリームすなわち、MPEG-4アドバンスドビデオコーデック規格に従ってエンコードされたストリームとして識別するmimePARAM要素は、である。ストリームのMIMEタイプは、特定のストリーム例えば、AACオーディオまたはUTF-8テキストストリームのエンコーディングに対する適切性に応じて、mimePARAM要素を使用して指定されることができる。メディアオブジェクトが、VIDEO要素であるとき、付加的属性は、VIDEO要素によって識別されるコンテナファイル内のストリームのビットレートを指定するsystemBitrate属性と、エンコードされたビデオの寸法を画素で指定する幅および高さ属性を含むSMILファイル形式仕様内で定義される。付加的属性はまた、PARAM要素を使用して定義することができる。いくつかの実施形態では、vbvPARAM要素は、ビデオストリームのVBVバッファサイズをバイトで指定するように定義される。ビデオバッファリング検証子VBVは、エンコードされたビデオストリームが、正確にバッファリングされ、デコーダデバイスで再生され得ることを確実にするために使用される、理論的MPEGビデオバッファモデルである。1000バイトのVBVサイズを指定するvbvPARAM要素の実施例は、である。前述の属性を含む、VIDEO要素の実施例は、である。本発明の実施形態による、適応型ビットレートストリーミングシステムは、トリックプレイストリームに対応することができ、これは、適応型ビットレートストリーミングのためにエンコードされるソースコンテンツのスムーズな視覚的検索を提供するために使用されることができる。トリックプレイストリームは、再生時、ソースメディアを通して、視覚的検索が加速されているかのようにエンコードされることが、実際は、トリックプレイストリームは、単に、より低いフレームレートでソースメディアをエンコードする別個のトラックである。システムの多くの実施形態では、トリックプレイトラックの参照は、VIDEO要素は、VIDEO要素のsystemProfile属性によって示される。他の実施形態では、種々の技法のいずれも、特定のストリームがトリックプレイストリームであることを、トップレベルインデックスファイル内で示すために利用されることができる。本発明のある実施形態による、トリックプレイストリームVIDEO要素の実施例は、である。本発明のいくつかの実施形態では、reservedBandwidthPARAM要素が、AUDIO要素のために定義されることができる。reservedBandwidthPARAM要素は、オーディオストリームのビットレートをKbpsで指定する。本発明のある実施形態に従って指定されるAUDIO要素の実施例は、である。いくつかの実施形態では、reservedBandwidthPARAM要素はまた、TEXTSTREAM要素のために定義される。本発明のある実施形態による、reservedBandwidthPARAM要素を含む、TEXTSTREAM要素の実施例は、である。他の実施形態では、種々の機構のいずれも、特定のアプリケーションに対する適切性に応じて、VIDEO、AUDIO、およびSUBTITLE要素に関する情報を指定するために利用されることができる。SWITCH要素は、適応型または代替ストリームを定義するために利用され得る、SMILファイル形式仕様内で定義される機構である。SWITCH要素が、異なるビットレートで代替ビデオストリームを指定するために利用され得る様式の実施例は、である。SWTICH要素は、3つの代替ビデオストリームのURLを指定する。ファイル名は、ストリームのそれぞれの異なるビットレートを示す。以下にさらに論じられるように、SMILファイル形式仕様は、トップレベルインデックスSMILファイル内において、ストリームおよびそれが含有されるコンテナファイルに関する付加的情報を指定するために、本発明の実施形態に従って利用されることができる、機構を提供する。本発明の多くの実施形態では、EXCL除外要素は、ストリーミング状態を伴う再生の間、適応しない代替トラックを定義するために使用される。例えば、EXCL要素は、代替オーディオトラックまたは代替字幕トラックを定義するために使用することができる。EXCL要素が、代替EnglishおよびFrenchオーディオストリームを指定するために利用されることができる様式の実施例は、である。本発明のある実施形態による、2つの代替ビデオレベル、オーディオストリームおよび字幕ストリームの属性ならびにパラメータを定義する、トップレベルインデックスSMILファイルの実施例は、である。トップレベルインデックスSMILファイルは、ソースメディアが、適応型ビットレートストリーミングを介して、再生のためにエンコードされるとき、生成されることができる。代替として、トップレベルインデックスSMILファイルは、再生デバイスがエンコードされたメディアの再生の開始を要求するとき、生成されることができる。再生デバイスが、トップレベルインデックスSMILファイルを受信すると、再生デバイスは、SMILファイルを解析し、利用可能なストリームを識別することができる。再生デバイスは、次いで、ストリームを選択し、コンテンツを再生するために利用することができ、SMILファイルを使用して、コンテナファイルの部分を識別し、特定のストリームのエンコーディングに関する情報を取得する、および/またはコンテナファイル内のエンコードされたメディアへのインデックスを取得するためにダウンロードすることができる。トップレベルインデックスSMILファイルが、前述されているが、種々のトップレベルインデックスファイル形式のいずれも、本発明のある実施形態による、具体的アプリケーションに対する適切性に応じて、トップレベルインデックスファイルを作成するために利用されることができる。本発明の実施形態による、適応型ビットレートストリーミングを使用して、エンコードされたメディアの再生を可能にするためのトップレベルインデックスファイルの使用は、以下にさらに論じられる。適応型ビットレートストリーミングのために、メディアをMATROSKAファイルに記憶する本発明のある実施形態による、エンコードされたビデオを記憶するために使用されるMatroskaコンテナファイルは、図3に図示される。コンテナファイル32は、Matroskaコンテナファイル形式の拡張機能である、拡張可能バイナリマークアップ言語EBMLファイルである。特殊Matroskaコンテナファイル32は、標準的EBML要素34と、標準的SeekHead要素40、標準的Segment情報要素42、および標準的Tracks要素44を含む標準的Segment要素36とを含む。これらの標準的要素は、Matroskaコンテナファイル内に含有されるメディアを記述する。Segment要素36はまた、標準的Clusters要素46を含む。以下に説明されるように、エンコードされたメディアが、Clusters要素46内の個々のCluster要素48内に挿入される様式は、適応型ストリーミングシステム内のメディアの再生を改善するために制約される。多くの実施形態では、エンコードされたビデオに課される制約は、Matroskaコンテナファイル形式の仕様と一致し、各クラスタが、IDRフレームで開始する少なくとも1つのクローズドGOPを含むように、ビデオをエンコードすることを伴う。前述の標準的要素に加え、Segment要素36はまた、標準的Cues要素52の修正されたバージョンを含む。以下にさらに論じられるように、Cues要素は、HTTPを介して、特定のCluster要素内に含有されるメディアの読み出しを促進する、特殊CuePoint要素すなわち、非標準的CuePoint要素を含む。本発明の実施形態による、適応型ビットレートストリーミングのためのメディアのエンコーディングに課される制約およびMatroskaコンテナファイルのClusters要素内のエンコードされたメディアの形式、ならびにコンテナファイル内に挿入される付加的インデックス情報は、以下にさらに論じられる。Cluster要素内に挿入するためのメディアのエンコーディング適応型ビットレートストリーミングシステムは、再生デバイスによって経験されるストリーミング状態に従って、再生の間、再生デバイスに、エンコードされたメディアの異なるストリーム間で選択を行う選択肢を提供する。多くの実施形態では、ストリーム間の切り替えは、各ストリームのエンコーディングパラメータに従って、ソースメディアの離散部分を別個に事前にエンコードし、次いで、各別個にエンコードされた部分をストリームのコンテナファイル内のその独自のCluster要素内に含めることによって促進される。さらに、各クラスタ内に含有されるメディアは、メディアが、ストリーム内の任意の他のクラスタ内に含有されるメディを参照せずに、再生可能であるように、エンコードされる。このように、各ストリームは、ソースメディアの同一の離散部分に対応するCluster要素を含み、随時、再生デバイスは、再生デバイスによって経験されるストリーミング状態に最も適切であるストリームからCluster要素を選択することができ、Cluster要素内に含有されるメディアの再生を始めることができる。故に、再生デバイスは、再生デバイスによって経験されるストリーミング状態が、経時的に変化するにつれて、異なるストリームからクラスタを選択することができる。いくつかの実施形態では、Cluster要素はさらに、各Cluster要素が、同一の持続時間を有するソースメディアからエンコードされたメディアの部分を含有するように、制約される。いくつかの実施形態では、各Cluster要素は、2秒のエンコードされたメディアを含む。メディアのタイプすなわち、ビデオ、オーディオ、または字幕に応じて、各Cluster要素内でエンコードされるメディアに適用される具体的制約は、以下に論じられる。本発明のある実施形態による、ビデオストリームを含有するMatroskaコンテナファイルのClusters要素は、図4aに図示される。Clusters要素46は、それぞれ、エンコードされたビデオの離散部分を含有する複数のCluster要素48を含む。図示される実施形態では、各Cluster要素48は、2秒のエンコードされたビデオを含む。他の実施形態では、Cluster要素は、2秒超または未満を有するエンコードされたビデオを含む。Cluster要素が小さいほどすなわち、各Cluster要素内のエンコードされるメディアの持続時間が短いほど、各Cluster要素を要求することと関連付けられるオーバーヘッドが高くなる。したがって、ストリーミング状態の変化への再生デバイスの応答性と所与の一組のストリーミング状態のための適応型ストリーミングシステムの有効データレートすなわち、エンコードされたメディアを伝送するために実際に利用される、利用可能な帯域幅の部分との間には、トレードオフが存在する。いくつかの実施形態では、Cluster要素内のエンコードされたビデオシーケンスは、異なる持続時間を有する。各Cluster要素48は、Cluster要素および複数のBlockGroup要素内のエンコードされたビデオの開始時間を示すTimecode要素60を含む。前述のように、クラスタ内に記憶されたエンコードされたビデオは、コンテナファイル内の他のCluster要素のいずれか内に含有されるエンコードされたビデオを参照せずに、再生され得るように、制約される。多くの実施形態では、第1のフレームがIDRフレームである、GOPとして、Cluster要素内に含有されるビデオのエンコーディングは、制約を強いる。図示される実施形態では、第1のBlockGroup要素62は、IDRフレームを含有する。したがって、第1のBlockGroup要素62は、ReferenceBlock要素を含まない。第1のBlockGroup要素62は、Cluster要素48のTimecodeに対して、Block要素64内でエンコードされるフレームのTimecode属性を指定する、Block要素64を含む。後続BlockGroup要素66は、それらが含有することができるフレームのタイプが制限されないCluster要素内に含有されないフレームを参照することができないこと以外。したがって、後続BlockGroup要素66は、BlockGroup内に含有されるフレームのデコーディングにおいて利用される他のBlockGroup要素を参照する、ReferenceBlock要素68を含むことができる、またはIDRフレームを含有することができ、第1のBlockGroup要素62に類似する。前述のように、エンコードされたビデオが、MatroskaファイルのCluster要素内に挿入される様式は、Matroskaファイル形式の仕様に一致する。本発明の実施形態による、MatroskaコンテナファイルのCluster要素46内へのエンコードされたオーディオおよび字幕情報の挿入は、図4bおよび4cに図示される。図示される実施形態では、エンコードされたメディアは、図4aに関連して前述のエンコードされたビデオに適用される同一の制約を条件として、Cluster要素48内に挿入される。加えて、各Cluster要素内のエンコードされたオーディオおよび字幕情報の持続時間は、エンコードされたビデオを含有するMatroskaコンテナファイルの対応するCluster要素内のエンコードされたビデオの持続時間に対応する。他の実施形態では、オーディオおよび/または字幕ストリームを含有するコンテナファイル内のCluster要素は、代替ビデオストリームを含有するコンテナファイル内のCluster要素の開始時間および持続時間と対応する必要はない。単一MKVコンテナファイル内のストリームの多重化図4a-4cに示されるクラスタ要素は、単一ストリームが、各Matroskaコンテナファイル内に含有されると仮定する。いくつかの実施形態では、複数のストリームからのメディアは、単一Matroskaコンテナファイル内において多重化される。このように、単一コンテナファイルは、1つ以上の対応するオーディオストリームおよび/または1つ以上の対応する字幕ストリームで多重化されたビデオストリームを含有することができる。ストリームをこのように記憶することは、複数の代替ビデオストリームにわたるオーディオおよび字幕ストリームの複製をもたらすことができる。しかしながら、ビデオストリームおよび関連付けられたオーディオおよび/または字幕ストリームから、エンコードされたメディアを読み出すための検索時間は、サーバ上のデータの隣接する記憶のために低減され得る。本発明のある実施形態による、多重化されたビデオ、オーディオ、および字幕データを含有するMatroskaコンテナファイルのクラスタ要素46は、図4dに図示されている。図示される実施形態では、各Cluster要素48は、多重化されたストリームのそれぞれに対する付加的BlockGroup要素を含む。第1のCluster要素は、エンコードされたビデオフレームを含有し、Cluster要素の開始時間に対するフレームのTimecode属性すなわち、Timecode属性60を示すBlock要素64vを含む、エンコードされたビデオのための第1のBlockGroup要素62vを含む。第2のBlockGroup要素62aは、エンコードされたオーディオシーケンスを含み、Cluster要素の開始時間に対するエンコードされたオーディオのTimecodeを示すBlock要素64aを含み、第3のBlockGroup要素62sは、エンコードされた字幕を含有し、Cluster要素の開始時間に対するエンコードされた字幕のTimecodeを示すBlock要素64sを含む。図示されないが、図示される実施形態では、各Cluster要素48は、付加的エンコードされたビデオ、オーディオ、または字幕を含有する付加的BlockGroup要素を含む可能性が高い。エンコードされたビデオ、オーディオ、および/または字幕ストリームの多重化にかかわらず、エンコードされたメディアに関する同一の制約が、適用される。適応型ビットレートストリーミングシステムにおいて使用するためのMKVコンテナファイル内へのトリックプレイトラックの組み込みMatroskaコンテナファイル内へのトリックプレイトラックの組み込みは、DivX,LLCによって、2008年10月29日出願の米国特許出願第12/260,404号ApplicationEnhancementTracksにおいて提案されており、その開示は、参照することによって全体として本明細書に組み込まれる。米国特許出願第12/260,404号に説明されるトリックプレイトラックに類似するトリックプレイトラックは、本発明のある実施形態による、適応型ビットレートストリーミングシステムにトリックプレイストリームを提供し、適応型ビットレートストリーミングのためのエンコードされたソースコンテンツを通して、スムーズな視覚的検索を提供するために使用されることができる。別個のトリックプレイトラックは、再生時、ソースメディアを通して、視覚的検索が加速されたようにエンコードされることができるが、実際には、トリックプレイトラックは、単に、より低いフレームレートにおいてソースメディアをエンコードする別個のトラックである。いくつかの実施形態では、トリックプレイストリームは、米国特許出願第12/260,404号に概略されるように、トリックプレイトラックを生成し、Matroksaコンテナファイル中へのビデオストリームの挿入に関する前述の制約を条件として、トリックプレイトラックをMatroskaコンテナファイル中に挿入することによって、作成される。多くの実施形態では、トリックプレイトラックはまた、トリックプレイトラック内の各Cluster要素のGOP内の各フレームが、IDRフレームとして、エンコードされるというさらなる制約を条件とする。他のビデオストリームと同様に、各Cluster要素は、他のストリーム内の対応するCluster要素と同一の2秒のソースメディアに対応するGOPを含有する。トリックプレイトラックのGOP内には、単に、より少ないフレームが存在し、各フレームは、より長い持続時間を有する。このように、トリックプレイストリームへおよびそこからの遷移は、他のエンコードされたストリームのいずれか間の遷移が、本発明の実施形態による、適応型ビットレートストリーミングシステム内で処理されるのと同一の方法で処理されることができる。視覚的検索の加速を達成するために、トリックプレイトラック内に含有されるフレームの再生は、一般的には、再生デバイスが、検索の加速のレートの所望の増加例えば、x2、x4、x6等を達成するために、再生デバイスのデコーダへのフレームの提供に先立って、エンコードされたビデオのフレームに割り当てられるタイムコードを操作することを含む。トリックプレイトラックからエンコードされたメディアを含有するCluster要素は、図4eに示される。図示される実施形態では、エンコードされたトリックプレイは、図4aに関連して前述のエンコードされたビデオに適用される同一の制約を条件として、Cluster要素48内に挿入される。しかしながら、各Block要素は、IDRを含有する。他の実施形態では、トリックプレイトラックを含有するコンテナファイル内のCluster要素は、代替ビデオストリームを含有するコンテナファイル内のCluster要素の開始時間および持続時間に対応する必要はない。多くの実施形態では、ソースコンテンツは、適応型ビットレートストリーミングシステムによって使用するための単一トリックプレイトラックまたは複数のトリックプレイトラックを提供するようにエンコードされることができる。単一トリックプレイトラックが提供されるとき、トリックプレイトラックは、一般的には、低ビットレートでエンコードされる。複数の代替トリックプレイトラックが提供されるとき、適応型レートストリーミングはまた、トリックプレイトラックに関して行われることができる。いくつかの実施形態では、複数のトリックプレイトラックは、エンコードされたメディアを通して、異なるレートの視覚的検索の加速に対応するように提供される。MKVコンテナファイル内へのインデックス化情報の組み込みMatroskaコンテナファイル形式のための仕様は、コンテナファイル内のBlock要素をインデックス化するために使用される、随意のCue要素を提供する。本発明のある実施形態による、Matroskaコンテナファイル中に組み込まれ、HTTPを使用して再生デバイスによるクラスタの要求を促進することができる修正されたCue要素52が、図5に図示される。修正されたCue要素52は、それぞれ、CueTime属性72を含む複数のCuePoint要素70を含む。各CuePoint要素は、CueTrack76およびCueClusterPosition78属性を含有するCueTrackPosition要素74を含む。多くの実施形態では、CuePoint要素は、主に、Cluster要素内の特定のBlock要素とは対照的に、特定のCluster要素を識別するように構成される。但し、いくつかの用途では、Cluster要素内の特定のBlockGroup要素を検索する能力が要求され、付加的インデックス情報がCue要素内に含まれる。本発明のある実施形態による、MatroskaファイルのClusters要素内のエンコードされたメディアをインデックス化するための修正されたCues要素の使用が図6に図示されている。CuePoint要素は、Matroskaコンテナファイル内の各Cluster要素に対応するように生成される。CuePoint要素70のCueTime属性72は、対応するCluster要素48のTimecode属性60に対応する。加えて、CuePoint要素は、対応するCluster要素48の開始をポイントするCueClusterPosition属性78を有する、CueTrackPosition要素74を含有する。CueTrackPosition要素74はまた、CueBlockNumber属性を含むことができ、これは、一般的には、Cluster要素48内の第1のIDRフレームを含有するBlock要素を示すために使用される。容易に理解され得るように、修正されたCue要素52は、Matroskaコンテナファイル内のCluster要素48のそれぞれへのインデックスを形成する。さらに、CueTrackPosition要素は、HTTPまたは別の好適なプロトコルを介して、遠隔サーバから、特定のCluster要素48のバイト範囲を要求するために、再生デバイスによって使用され得る情報を提供する。従来のMatroskaファイルのCue要素は、直接、Cluster要素内に含有されるエンコードされたビデオの全部を取得するために、Cluster要素の開始から、要求するためのバイト数に関する情報を再生デバイスに提供しない。Cluster要素のサイズは、次のCluster要素の第1のバイトをインデックスするCueTrackPosition要素のCueClusterPosition属性を使用することによって、修正されたCue要素内で推測されることができる。代替として、付加的CueTrackPosition要素は、Cluster要素の最後のバイトをインデックスするCluster要素の第1のバイトをインデックスするCueTrackPosition要素に加え、本発明の実施形態による、修正されたCue要素に追加され得る、および/またはCueClusterPosition属性によってポイントされるCluster要素のサイズを指定する非標準的CueClusterSize属性が、各CueTrackPosition要素内に含まれ、HTTPバイト範囲要求または類似プロトコルを介して、Matroskaコンテナファイル内の特定のCluster要素の読み出しを補助する。前述のようなCue要素の修正は、適応型ビットレートストリーミングの間、HTTPまたは類似プロトコルを介して、MatroskaコンテナファイルからのCluster要素の読み出しを有意に簡略化する。加えて、各クラスタ内の第1のフレームをインデックス化することだけによって、インデックスのサイズが有意に減少される。インデックスが、一般的には、再生に先立ってダウンロードされることを前提として、Cue要素すなわち、インデックスのサイズの減少は、再生が、より迅速に始まることができることを意味する。CueClusterPosition要素を使用して、再生デバイスは、単に、所望のCluster要素のためのTimecode属性を使用して、関連Matroskaコンテナファイルのインデックスを参照することによって、再生デバイスによって経験されるストリーミング状態に最も好適なストリームから、特定のCluster要素を要求することができる。いくつかの実施形態では、Cue要素内のいくつかの属性は、適応型ビットレートストリーミングの間に利用されない。したがって、Cue要素はさらに、利用されていない属性を除去し、各Matroskaコンテナファイルのためのインデックスの全体的サイズを減少させることによって修正されることができる。本発明のある実施形態による、単一のエンコードされたストリームを含む、Matroskaコンテナファイル内で利用され得る修正されたCue要素は、図5aに図示される。図5aに示されるCue要素52’は、図5に示されるCue要素52と類似するが、CuePoint要素70’は、CueTime属性図5の72参照を含まない、および/またはCueTrackPosition要素74’は、CueTrack属性図5の76を含まない。Motroskaコンテナファイル内の各Cluster要素内のエンコードされたメディアの部分が、同一の持続時間を有するとき、CueTime属性は、必要ではない。Matroskaが、単一のエンコードされたストリームを含むファイルを含有するとき、CueTrack属性は、必要ではない。他の実施形態では、MatroskaコンテナファイルのCue要素および/または他の要素は、ストリームがエンコードされ、Matroskaコンテナファイル内に挿入される様式を前提として、Matroskaコンテナファイル内に含有されるエンコードされたストリームの適応型ビットレートストリーミングに必要ではない要素および/または属性を除去するように修正されることができる。Matroskaコンテナファイル内のCluster要素のそれぞれのサイズに関する情報を含み、不必要属性を排除するためのCue要素への種々の修正が、前述されるが、本発明の多くの実施形態は、従来のMatroskaコンテナを利用する。いくつかの実施形態では、再生デバイスは、単に、従来のCues要素から取得される情報を使用して、オンザフライで、Cluster要素のサイズを決定し、および/またはMKVコンテナファイル内のCluster要素のサイズおよび/または場所に関する情報を含有する別個のインデックスファイルに依拠する。いくつかの実施形態では、付加的インデックス情報が、トップレベルインデックスファイル内に記憶される。いくつかの実施形態では、付加的インデックス情報が、トップレベルインデックスファイル内で識別される、別個のファイル内に記憶される。Cluster要素をMatroskaコンテナファイルから読み出すために利用されるインデックス情報が、コンテナファイルと別個に記憶されるとき、Matroskaコンテナファイルは、依然として、一般的には、前述のように、Cluster要素内への含有のために、メディアをエンコードするように制約される。加えて、インデックス情報がどこに位置する場合でも、インデックス情報は、一般的には、各Cluster要素をインデックスし、少なくとも各Cluster要素の開始場所、多くの事例では、そのサイズに関する情報但し、それに限定されないを含むであろう。適応型ビットレートストリーミングのためのソースメディアのエンコーディング本発明のある実施形態による、トップレベルインデックスファイルとしてソースメディアをエンコードするためのプロセスと、適応型ビットレートストリーミングシステムにおいて使用するための複数のMatroskaコンテナファイルは、図7に図示される。エンコーディングプロセス100は、ソースメディアの第1の部分を選択するステップ102と、各ストリームのためのエンコーディングパラメータを使用して、ソースメディアをエンコードするステップ104によって始まる。メディアの部分が、ビデオであるとき、ソースビデオの部分は、IDRフレームで開始する単一GOPとしてエンコードされる。多くの実施形態では、代替GOPを作成するために使用されるエンコーディングパラメータは、ビットレート、フレームレート、エンコーディングパラメータ、および解像度に基づいて変動する。このように、メディアの部分は、一組の互換可能代替としてエンコードされ、再生デバイスは、再生デバイスによって経験されるストリーミング状態に最も適切な代替を選択することができる。異なる解像度に対応するとき、ストリームのエンコーディングは、各ストリームが、同一の表示アスペクト比を有するように制約される。一定の表示アスペクト比が、ストリームの解像度に伴って、サンプルアスペクト比を変動させることによって、異なる解像度ストリームにわたって達成されることができる。多くの事例では、解像度の低下は、同一のビットレートでエンコードされたより高い解像度ビデオと比較して、より高い品質のビデオをもたらすことができる。多くの実施形態では、ソースメディア自体がエンコードされ、エンコーディングプロセス104は、適応型ビットレートストリーミングシステムによって対応される代替ストリームのそれぞれのエンコーディングパラメータに従って、エンコードされたソースメディアをトランスコードまたは翻訳することを含む。ソースメディアが、エンコードされたメディアの一組の代替部分としてエンコードされると、エンコードされたメディアの代替部分はそれぞれ、エンコードされたメディアの部分が属するストリームに対応するMatroskaコンテナファイル内のCluster要素中に挿入される106。多くの実施形態では、エンコーディングプロセスはまた、メディアが、コンテナ内のCluster要素中に挿入されるにつれて、各Matroskaコンテナファイルのためのインデックスを構築する。したがって、プロセス100はまた、Matroskaコンテナファイル内に挿入されるCluster要素をポイントするCuePoint要素を作成するステップを含むことができる。CuePoint要素は、ソースメディアが完全にエンコードされるまで、バッファ内に保持されることができる。前述のプロセスは、ソースメディアを通して、単一パスにおいて、エンコードされたメディアの代替部分のそれぞれを連続してエンコードするステップを説明するが、本発明の多くの実施形態は、ソースメディアを通して、別個のパスを行い、代替ストリームのそれぞれをエンコードすることを伴う。図7に戻って参照すると、プロセスは、ソースメディア全体が、適応型ビットレートストリーミングのためにエンコードされる108まで、ソースメディアの部分の選択102およびエンコード104を継続し、次いで、メディアのエンコードされた部分を適切なストリームに対応するMatroskaコンテナファイル中に挿入する106。その時点において、プロセスは、各ストリームに対して、インデックスをMatroskaコンテナ中に挿入110し、Matroskaコンテナファイル内に含有されるエンコードされたストリームのそれぞれをインデックスするトップレベルインデックスファイルを作成112することができる。前述のように、インデックスは、エンコードされたメディアとして作成され、CuePoint要素が、Mastroskaコンテナファイル内の各Cluster要素をインデックスするように、Matroskaコンテナファイル中に挿入することができる。エンコーディングの完了に応じて、CuePoint要素はそれぞれ、Cue要素内に含まれることができ、Cue要素は、Cluster要素に続いて、Matroskaコンテナファイル中に挿入されることができる。ソースメディアのエンコーディングに続いて、トリックプレイストリームの生成を含むことができるエンコーディングプロセスの間に生成されるストリームのそれぞれを含有するMatroskaコンテナファイルと、Matroskaコンテナファイル内のストリームのそれぞれをインデックスするトップレベルインデックスファイルを生成した後、トップレベルインデックスファイルおよびMatroskaコンテナファイルは、再生デバイスへの適応型ビットレートストリーミングのために、HTTPサーバにアップロードされることができる。HTTP要求を使用して、本発明の実施形態に従ってエンコードされたメディアの適応型ビットレートストリーミングは、以下にさらに論じられる。HTTPを使用したMKVコンテナファイルからの適応型ビットレートストリーミングソースメディアが、ビデオ、オーディオ、および字幕コンテンツのうちの少なくとも1つのための別個のMatroskaコンテナファイル内に含有される代替ストリームが存在するようにエンコードされると、Matroskaコンテナファイル内に含有されるメディアの適応型ストリーミングは、HTTP要求または類似ステートレスデータ転送プロトコルを使用して達成されることができる。多くの実施形態では、再生デバイスは、サーバ上に常駐するトップレベルインデックスファイルを要求し、再生デバイスに利用可能なストリームを識別するためのインデックス情報を使用する。再生デバイスは、次いで、Matroskaファイルのうちの1つ以上のためのインデックスを読み出すことができ、HTTP要求または類似ステートレスプロトコルを使用して、Matroskaコンテナファイル内に含有されるストリームのうちの1つ以上からメディアを要求するために、インデックスを使用することができる。前述のように、本発明の多くの実施形態は、修正されたCue要素を使用して、Matroskaコンテナファイルのそれぞれに対するインデックスを実装する。しかしながら、いくつかの実施形態では、各ストリームに対するエンコードされたメディアは標準的Matroskaコンテナファイル内に含有され、別個のインデックスファイルはまた、コンテナファイルのそれぞれのために提供されることができる。再生デバイスによって経験されるストリーミング状態に基づいて、再生デバイスは、異なるビットレートでエンコードされた代替ストリームから、メディアを選択することができる。ストリームのそれぞれからのメディアが、前述のように、Matroskaコンテナファイル中に挿入されると、ストリーム間の遷移が、Cluster要素内のメディアの再生の完了に応じて生じることができる。したがって、Cluster要素のサイズすなわち、Cluster要素内のエンコードされたメディアの持続時間は、一般的には、再生デバイスが、ストリーミング状態の変化およびトリックプレイトラックの利用を伴うユーザからの命令に十分に迅速に対応可能であるように、選定される。Cluster要素が小さいほどすなわち、各Cluster要素内のエンコードされたメディアの持続時間が短いほど、各Cluster要素の要求と関連付けられたオーバーヘッドが高くなる。したがって、ストリーミング状態の変化への再生デバイスの応答性と、所与の一組のストリーミング状態に対する適応型ストリーミングシステムの有効データレートすなわち、エンコードされたメディアを伝送するために実際に利用される、利用可能な帯域幅の部分との間に、トレードオフが存在する。多くの実施形態では、Cluster要素のサイズは、各Cluster要素が、2秒のエンコードされたメディアを含有するように、選定される。他の実施形態では、エンコードされたメディアの持続時間は、2秒超または未満であることができ、および/またはエンコードされたメディアの持続時間は、Cluster要素毎に変動することができる。本発明のある実施形態による、トップレベルインデックスファイルによってインデックスされたMatroskaコンテナファイル内に含有される別個のストリームにおいてエンコードされたメディアの再生の間の再生デバイスまたはクライアントとHTTPサーバとの間の通信は、図8に図示される。図示される実施形態では、再生デバイス200は、データを受信するために、HTTP要求または類似プロトコルを使用して、サーバ202からトップレベルインデックスファイルを要求することによって、再生を始める。サーバ202は、要求に対応するバイトを提供する。再生デバイス200は、次いで、トップレベルインデックスファイルを解析し、ソースメディアの特定の断片から導出されたエンコードされたメディアのストリームを含有するMatroskaコンテナファイルのそれぞれのURIを識別する。再生デバイスは、次いで、HTTPまたは類似プロトコルを介して、Matroskaコンテナファイルのうちの1つ以上のヘッダに対応するバイト範囲を要求することができ、バイト範囲は、関連MatroskaコンテナファイルのためのURI内に含有される情報を使用して決定される前述の議論参照。サーバは、Matroskaコンテナファイルのヘッダを含有するバイト範囲に対する要求に応答して、の情報を返す。EBML要素は、一般的には、ファイルバージョンに対応することを確実にするために、再生デバイスによって処理される。SeekHead要素は、Matroskaインデックス要素の場所を見つけるために解析され、SegmentInfo要素は、再生において利用される2つの重要な要素を含有する、すなわち、TimecodeScaleおよびDurationである。TimecodeScaleは、MatroskaコンテナファイルのSegment内の全タイムコードに対するタイムコードスケールを指定し、Durationは、TimecodeScaleに基づいて、Segmentの持続時間を指定する。Tracks要素は、MatroskaファイルのClusters要素内に含有されるエンコードされたメディアをデコードするために、再生デバイスによって使用される情報を含有する。前述のように、本発明の実施形態による、適応型ビットレートストリーミングシステムは、フレームレートおよび解像度を含むが、それらに限定されない、異なるエンコーディングパラメータを使用してエンコードされ異なるストリームに対応することができる。したがって、再生デバイスは、Matroskaコンテナファイルのヘッダ内に含有される情報を使用して、遷移が、エンコードされたストリーム間で行われるたびに、デコーダを構成することができる。多くの実施形態では、再生デバイスは、トップレベルインデックスファイル内でインデックスされたMatroskaコンテナファイルの全部に対して、ヘッダを受信しない。代わりに、再生デバイスは、最初に、再生を始めるために利用されるであろうストリームを決定し、対応するMatroskaコンテナファイルからヘッダを要求する。トップレベルインデックスファイル内に含有されるURIの構造に応じて、再生デバイスは、URIからの情報またはMatroskaコンテナファイルのヘッダからの情報のいずれかを使用して、関連Matroskaコンテナファイルからのインデックスの少なくとも部分を含有するサーバからバイト範囲を要求することができる。バイト範囲は、インデックス全体に対応することができる。サーバは、インデックス情報を含有する関連バイト範囲を再生デバイスに提供し、再生デバイスは、インデックス情報を使用して、この情報を使用してエンコードされたメディアを含有するCluster要素のバイト範囲を要求することができる。Cluster要素が受信されると、再生デバイスは、エンコードされたメディアをCluster要素内のBlock要素から抽出することができ、その関連付けられたTimecode属性に従って、Block要素内のメディアをデコードおよび再生することができる。図示される実施形態では、再生デバイス200は、再生デバイスが、インデックス情報を使用して、選択されたストリームのそれぞれの全体をストリーミングすることができるように、再生の開始に先立って、十分なインデックス情報をHTTPサーバから要求する。他の実施形態では、再生デバイスは、メディアが再生されるにつれて、継続的に、インデックス情報を読み出す。いくつかの実施形態では、最低ビットレートストリームに対するインデックス情報は全部、最低ビットレートストリームに対するインデックス情報が、再生の間、ストリーミング状態が急に劣化する場合、再生デバイスに利用可能となるように、再生に先立って、要求される。ストリーム間での切り替え図8に図示される通信は、再生デバイスが、メディアの再生全体を通して、同一のストリームすなわち、Matroskaコンテナファイルから、メディアの要求を継続すると仮定する。実際、再生デバイスによって経験されるストリーミング状態は、ストリーミングメディアの再生の間、変化する可能性が高く、再生デバイスは、代替ストリームすなわち、異なるMatroskaコンテナファイルからメディアを要求し、再生デバイスによって経験されるストリーミング状態のための最良ピクチャ品質を提供することができる。加えて、再生デバイスは、トリックプレイトラックストリームを利用する、トリックプレイ機能を行うために、ストリームを切り替えてもよい。再生デバイスが、本発明の実施形態に従って、新しいストリームに切り替えるときの再生デバイスとサーバとの間の通信は、図9aに図示される。図9aに図示される通信は、新しいストリームのためのインデックス情報が、再生デバイスによって以前に要求されておらず、情報が、新しいストリームを含有するMatroskaコンテナファイルに関して、取得されている間、古いストリームからのCluster要素のダウンロードが進むと仮定する。再生デバイス200が、ストリーミング状態の変化を検出し、より高いビットレートストリームが、このストリーミング状態で利用することができることを決定する、またはユーザからのトリックプレイ命令を受信すると、再生デバイスは、トップレベルインデックスファイルを使用して、再生デバイスが、現在、エンコードされたメディアを要求している、ビデオ、オーディオ、または字幕ストリームのうちの少なくとも1つにより適切な代替ストリームのためのURIを識別することができる。再生デバイスは、現在のストリームに関する情報を保存することができ、対応するURIのパラメータを使用して、新しいストリームを含有するMatroskaコンテナファイルのためのヘッダのバイト範囲を要求することができる。このように情報をキャッシュすることは、再生デバイスが、ストリームのビットレートを下方に適応させようとするときに有益であり得る。再生デバイスが、利用可能な帯域幅の減少を経験すると、再生デバイスは、理想的には、より低いビットレートストリームに迅速に切り替えるであろう。再生デバイスによって経験される帯域幅減少のため、再生デバイスは、ヘッダおよびインデックス情報を要求するための付加的帯域幅を有する可能性が低い。理想的には、再生デバイスは、全利用可能な帯域幅を利用して、既に要求されたより高いレートのCluster要素をダウンロードし、ローカルにキャッシュされたインデックス情報を使用して、より低いビットレートストリームを含有するMatroskaコンテナファイルからのCluster要素の要求を開始する。新しいストリームを含有するMatroskaコンテナファイルに対するインデックス情報のためのバイト範囲は、図8に関連して前述のように、HTTPサーバ202から要求されることができる。その時点において、再生デバイスは、以前のストリームからのCluster要素のダウンロードを停止することができ、Matroskaコンテナファイルからのインデックス情報を使用して、HTTPサーバからの新しいストリームを含有するMatroskaコンテナファイルからの適切なCluster要素のバイト範囲の要求を開始し、再生デバイスによって読み出された最後のCluster要素内のエンコードされたメディアに続くエンコードされたメディアを含有するCluster要素を識別することができる。前述のように、あるストリームから別のストリームへのスムーズな遷移は、対応するCluster要素が、同一のTimecode要素およびIDRフレームで開始するように、代替ストリームのそれぞれをエンコードすることによって促進される。再生デバイスが、メディアの再生において利用された各ストリームに対するヘッダおよびインデックス全体をキャッシュすると、以前に使用されたストリームに逆切り替えするプロセスを簡略化することができる。再生デバイスは、既に、以前に利用されたストリームを含有するMatroskaファイルに対するヘッダおよびインデックス情報を有し、再生デバイスは、単に、この情報を使用して、HTTPを介して、以前に利用されたストリームのMatroskaコンテナファイルからのCluster要素の要求を開始することができる。本発明のある実施形態による、再生デバイスが、ヘッダおよびインデックス情報をキャッシュしたストリームに逆切り替えするときの再生デバイスとHTTPサーバとの間の通信は、図9bに図示される。図9bに図示されるプロセスは、利用可能なリソースの減少が、メディアに加え、インデックス情報をダウンロードする必要性によって悪化され得るため、理想的には、ビットレートを下方に適応させるときに行われる。再生の中断の可能性は、再生デバイスがストリーム間で切り替えを行う速度を増加させ、切り替えを達成するためにダウンロードされるオーバーヘッドデータの量を低減させることによって減少される。本発明は、ある具体的側面において説明されたが、多くの付加的修正および変形例が、当業者に明白となるであろう。したがって、本発明は、例えば、本発明の範囲および精神から逸脱することなく、それらが準拠する特定の規格内で指定されるもの以外の特徴に対応する、エンコーダおよびデコーダを利用する、実装における種々の変更を含め、具体的に説明される以外に、別様に実践されてもよいことを理解されたい。したがって、本発明の実施形態は、あらゆる観点において、制限ではなく、例示と見なされるべきである。"