Adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
21 claims: 2 independent, 19 dependent
- 1再生デバイスを使用して適応型ビットレートストリーミングを実行する方法であって、前記再生デバイスは、前記再生デバイスによって経験されるストリーミング状態に従って、再生中にエンコードされたメディアの複数の異なるストリームの間で選択し、前記方法は、再生デバイスを使用して、ネットワークを介して、オーディオシーケンスおよびビデオシーケンスを含むメディアコンテンツの断片に対するトップレベルインデックスファイルを得ることであって、前記トップレベルインデックスファイルは、前記再生デバイスに対して利用可能なエンコードされたビデオの代替ストリームを識別することであって、前記エンコードされたビデオの識別された代替ストリームのそれぞれは、前記ビデオシーケンスのエンコーディングであり、前記エンコードされたビデオの識別された代替ストリームのそれぞれは、エンコードされたビデオの複数の部分としてエンコードされ、前記エンコードされたビデオの識別された代替ストリームは、複数の異なるビットレートでエンコードされる、ことと、エンコードされたオーディオの少なくとも1つのストリームを識別することであって、前記エンコードされたオーディオの識別された少なくとも1つのストリームのそれぞれは、前記オーディオシーケンスのエンコーディングであり、前記エンコードされたオーディオの識別された少なくとも1つのストリームのそれぞれは、エンコードされたビデオの複数の部分としてエンコードされる、ことと、コンテナファイルの場所に関する情報を含有する別個のインデックスファイルを識別することであって、前記コンテナファイルは、前記エンコードされたビデオの識別された代替ストリームと、前記エンコードされたオーディオの識別された少なくとも1つのストリームとを含有する、こととを行う、ことと、前記エンコードされたビデオの識別された代替ストリームから再生を開始するために、前記再生デバイスを使用して、利用すべきエンコードされたビデオの第1のストリームを選択することと、前記再生デバイスを使用して、前記ネットワークを介して、前記トップレベルインデックスファイルにおいて識別された前記別個のインデックスファイルから第1のインデックスファイルを得ることであって、前記第1のインデックスファイルは、前記エンコードされたビデオの第1のストリームに対するインデックスファイルであり、前記第1のインデックスファイルは、前記エンコードされたビデオの第1のストリームを含有する少なくとも1つのコンテナファイルの場所に関する情報を含有する、ことと、前記再生デバイスを使用して、前記ネットワークを介して、前記第1のインデックスファイルからの情報を利用して、前記エンコードされたビデオの第1のストリームに対するヘッダを得ることと、前記エンコードされたビデオの第1のストリームに対する前記ヘッダ内に含有される情報を使用して、前記再生デバイス内にビデオデコーダを構成することと、前記エンコードされたオーディオの識別された少なくとも1つのストリームから再生を開始するために、前記再生デバイスを使用して、利用すべきエンコードされたオーディオの第1のストリームを選択することと、前記再生デバイスを使用して、前記ネットワークを介して、前記トップレベルインデックスファイルにおいて識別された前記別個のインデックスファイルからオーディオインデックスファイルを得ることであって、前記オーディオインデックスファイルは、前記エンコードされたオーディオの第1のストリームに対するインデックスファイルであり、前記オーディオインデックスファイルは、前記エンコードされたオーディオの第1のストリームを含有する少なくとも1つのコンテナファイルの場所に関する情報を含有する、ことと、前記再生デバイスを使用して、前記ネットワークを介して、前記オーディオインデックスファイルからの情報を利用して、前記エンコードされたオーディオの第1のストリームに対するヘッダを得ることと、前記エンコードされたオーディオの第1のストリームに対する前記ヘッダ内に含有される情報を使用して、前記再生デバイス内にオーディオデコーダを構成することと、前記再生デバイスを使用して、前記 ネットワーク を介して、前記第1のインデックスファイルからの情報を利用して、前記エンコードされたビデオの第1のストリームからエンコードされたビデオの少なくとも第1の部分を得ることと、前記再生デバイスを使用して、前記ネットワークを介して、前記オーディオインデックスファイルからの情報を利用して、前記エンコードされたオーディオの第1のストリームからエンコードされたオーディオの少なくとも第1の部分を得ることと、前記メディアコンテンツの再生を開始することであって、前記開始することは、前記再生デバイス内の前記ビデオデコーダを使用して、前記エンコードされたビデオの第1のストリームからの前記エンコードされたビデオの少なくとも第1の部分内のエンコードされたビデオをデコードすることと、前記再生デバイス内の前記オーディオデコーダを使用して、前記エンコードされたオーディオの第1のストリームからの前記エンコードされたオーディオの少なくとも第1の部分内のエンコードされたオーディオをデコードすることとによって行われる、ことと、前記再生デバイスがエンコードされたメディアの付加的部分を得るにつれて、前記再生デバイスにおいて、前記再生デバイスによって経験される現在のストリーミング状態を評価することと、前記再生デバイスを使用して、前記再生デバイスによって経験される前記現在のストリーミング状態に基づいて、前記エンコードされたビデオの識別された代替ストリームからエンコードされたビデオの第2のストリームを選択することと、前記 第1の インデックスファイルと、前記ビデオデコーダを構成するために使用される前記エンコードされたビデオの第1のストリームに対する前記ヘッダ内に含有される前記情報とを前記再生デバイスのメモリ内に記憶することと、前記再生デバイスを使用して、前記ネットワークを介して、前記トップレベルインデックスファイルにおいて識別された前記別個のインデックスファイルから第2のインデックスファイルを得ることであって、前記第2のインデックスファイルは、前記エンコードされたビデオの第2のストリームに対するインデックスファイルであり、前記第2のインデックス ファイル は、前記エンコードされたビデオの第2のストリームの前記エンコードされたビデオの複数の部分を含有する少なくとも1つのコンテナファイルの場所を含有する、ことと、前記再生デバイスを使用して、前記ネットワークを介して、前記第2のインデックスファイルからの情報を利用して、前記エンコードされたビデオの第2のストリームに対するヘッダを得ることと、前記エンコードされたビデオの第2のストリームに対する前記ヘッダ内に含有される情報を使用して、前記再生デバイス内にビデオデコーダを構成することと、前記再生デバイスを使用して、前記ネットワークを介して、前記第2のインデックスファイルからの情報を利用して、前記エンコードされたビデオの第2のストリームからエンコードされたビデオの少なくとも1つの部分を得ることと、前記再生デバイスを使用して、前記ネットワークを介して、前記オーディオインデックスファイルからの情報を利用して、前記エンコードされたオーディオの第1のストリームからエンコードされたオーディオの少なくとも1つの付加的部分を得ることと、前記メディアコンテンツの再生を継続することであって、前記継続することは、前記再生デバイス内の前記ビデオデコーダを使用して、前記エンコードされたビデオの第2のストリームからの前記エンコードされたビデオの少なくとも1つの部分内のエンコードされたビデオをデコードすることと、前記再生デバイス内の前記オーディオデコーダを使用して、前記エンコードされたオーディオの第1のストリームからの前記エンコードされたオーディオの少なくとも1つの付加的部分内のエンコードされたオーディオをデコードすることとによって行われる、こととを含む、方法。
- 2前記方法は、前記再生デバイスがエンコードされたメディアのさらなる付加的部分を得るにつれて、前記再生デバイスによって経験される現在のストリーミング状態を評価することと、前記再生デバイスを使用して、前記再生デバイスによって経験される前記現在のストリーミング状態に基づいて、前記エンコードされたビデオの識別された代替ストリームから前記エンコードされたビデオの第1のストリームを選択することと、前記再生デバイスの前記メモリから、前記 第1の インデックスファイルと、前記ビデオデコーダを構成するために使用される前記エンコードされたビデオの第1のストリームに対する前記ヘッダ内に含有される前記情報とを読み出すことと、前記再生デバイスの前記メモリから読み出された前記エンコードされたビデオの第1のストリームに対する前記ヘッダ内に含有される前記情報を使用して、前記再生デバイス内にビデオデコーダを構成することと、前記再生デバイスを使用して、前記ネットワークを介して、前記再生デバイスの前記メモリから読み出された前記第1のインデックスファイルからの情報を利用して、前記エンコードされたビデオの第1のストリームからエンコードされたビデオの少なくとも1つの部分を得ることと、前記再生デバイスを使用して、前記ネットワークを介して、前記オーディオインデックスファイルからの情報を利用して、前記エンコードされたオーディオの第1のストリームからエンコードされたオーディオの少なくとも1つのさらなる部分を得ることと、前記メディアコンテンツの再生を継続することであって、前記継続することは、前記再生デバイス内の前記ビデオデコーダを使用して、前記エンコードされたビデオの第1のストリームからの前記エンコードされたビデオの少なくとも1つの部分内のエンコードされたビデオをデコードすることと、前記再生デバイス内の前記オーディオデコーダを使用して、前記エンコードされたオーディオの第1のストリームからの前記エンコードされたオーディオの少なくとも1つのさらなる部分内のエンコードされたオーディオをデコードすることとによって行われる、こととをさらに含む、請求項1に記載の方法。
- 3前記ビデオデコーダを構成するために使用される前記エンコードされたビデオの第1のストリームに対するヘッダ内に含有される前記情報を記憶することは、前記エンコードされたビデオの第1のストリームからの前記ヘッダを記憶することを含む、請求項1に記載の方法。
- 4現在のストリーミング状態を評価することは、バッファ占有率、ネットワーク帯域幅、再生デバイスプロセッサ容量からなる群から選択される少なくとも1つのストリーミング状態を評価することを含む、請求項1に記載の方法。
- 5前記再生デバイスは、前記現在のストリーミング状態に基づいて前記第2のストリームを選択することに先立って、前記第2のインデックスファイルと、前記エンコードされたビデオの第2のストリームに対する前記ヘッダとを得る、請求項1に記載の方法。
- 6前記再生デバイスは、再生を開始することに先立って、前記第2のインデックスファイルと、前記エンコードされたビデオの第2のストリームに対する前記ヘッダとを読み出す、請求項5に記載の方法。
- 7前記第1のインデックスファイルは、前記エンコードされたビデオの第1のストリームを含有するコンテナファイルの場所に関する情報と、前記コンテナファイル内のビデオの部分の場所に関する情報とを含有し、前記エンコードされたビデオの第1のストリームからの前記エンコードされたビデオの少なくとも第1の部分は、前記再生デバイスによって、前記ネットワークを介して、前記コンテナファイル内のビデオの部分の場所に関する前記情報を使用して生成されたバイト範囲要求を使用して得られる、請求項1に記載の方法。
- 8前記コンテナファイル内のビデオの部分の場所に関する前記情報は、開始場所およびサイズからなる群から選択されるエンコードされたビデオの各部分に対する情報を含む、請求項7に記載の方法。
- 9前記第1のインデックスファイルは、複数のコンテナファイルの場所に関する情報を含有し、前記複数のコンテナファイルのそれぞれは、前記エンコードされたビデオの第1のストリームからのエンコードされたビデオの部分を含有し、前記エンコードされたビデオの第1のストリームからの前記エンコードされたビデオの少なくとも第1の部分は、前記再生デバイスによって、前記ネットワークを介して、前記複数のコンテナファイルの場所に関する前記情報を使用して前記複数のコンテナファイルのうちの1つを要求することによって得られる、請求項1に記載の方法。
- 10前記エンコードされたビデオの第2のストリームからの前記エンコードされたビデオの少なくとも1つの部分からのエンコードされたビデオの各部分は、瞬時復号更新(IDR)フレームで開始するクローズドピクチャ群(GOP)を備える、請求項1に記載の方法。
- 11前記トップレベルインデックスファイルは、前記エンコードされたビデオの識別された代替ストリームを含むメディアのストリームを記述する統一リソース識別子(URI)のリストを含む拡張可能マークアップ言語(XML)を含有し、前記方法は、前記エンコードされたビデオの識別された代替ストリームのそれぞれを記述する前記URIを識別するために、前記再生デバイスを使用して、前記トップレベルインデックスファイルを解析することをさらに含む、請求項1に記載の方法。
- 12前記URIのリストは、オーディオストリームを記述する少なくとも1つのURIを含む、請求項11に記載の方法。
- 13前記URIのリストは、字幕ストリームを記述する少なくとも1つのURIを含む、請求項12に記載の方法。
- 14前記URIのリストは、トリックプレイストリームを記述する少なくとも1つのURIを含む、請求項11に記載の方法。
- 15前記トップレベルインデックスファイルは、前記再生デバイスによって、前記ネットワークを介して、HTTP要求を使用して得られる、請求項11に記載の方法。
- 16前記エンコードされたビデオの第2のストリームは、前記再生デバイスによってサーバシステムから既に要求されたエンコードされたビデオの部分と、前記再生デバイスによってバッファリングされたエンコードされたビデオの部分とからなる群から選択される少なくとも1つのファクターに基づいて選択される、請求項1に記載の方法。
- 17前記エンコードされたビデオの第1のストリームを含有する前記少なくとも1つのコンテナファイルのそれぞれは、拡張可能バイナリマークアップ言語(EBML)ファイルである、請求項1に記載の方法。
- 18前記エンコードされたビデオの識別された代替ストリームのそれぞれは、異なる最大ビットレートを有する、請求項1に記載の方法。
- 19前記エンコードされたビデオの識別された代替ストリームのうちの複数は、異なる解像度を有する、請求項1に記載の方法。
- 20前記エンコードされたビデオの識別された代替ストリームのうちの複数は、異なるサンプルアスペクト比を有するピクセルを有する、請求項1に記載の方法。
- 21再生デバイスを使用して適応型ビットレートストリーミングを実行する方法であって、前記再生デバイスは、前記再生デバイスによって経験されるストリーミング状態に従って、再生中にエンコードされたメディアの複数の異なるストリームの間で選択し、前記方法は、再生デバイスを使用して、ネットワークを介して、オーディオシーケンスおよびビデオシーケンスを含むメディアコンテンツの断片に対するトップレベルインデックスファイルを得ることであって、前記トップレベルインデックスファイルは、前記再生デバイスに対して利用可能なエンコードされたビデオの代替ストリームを識別することであって、前記エンコードされたビデオの識別された代替ストリームのそれぞれは、前記ビデオシーケンスのエンコーディングであり、前記エンコードされたビデオの識別された代替ストリームのそれぞれは、エンコードされたビデオの複数の部分としてエンコードされ、前記エンコードされたビデオの識別された代替ストリームは、複数の異なるビットレートでエンコードされる、ことと、エンコードされたオーディオの少なくとも1つのストリームを識別することであって、前記エンコードされたオーディオの識別された少なくとも1つのストリームのそれぞれは、前記オーディオシーケンスのエンコーディングであり、前記エンコードされたオーディオの識別された少なくとも1つのストリームのそれぞれは、エンコードされたビデオの複数の部分としてエンコードされる、ことと、コンテナファイルの場所に関する情報を含有する別個のインデックスファイルを識別することであって、前記コンテナファイルは、前記エンコードされたビデオの識別された代替ストリームと、前記エンコードされたオーディオの識別された少なくとも1つのストリームとを含有する、こととを行う、ことと、前記エンコードされたビデオの識別された代替ストリームから再生を開始するために、前記再生デバイスを使用して、利用すべきエンコードされたビデオの第1のストリームを選択することと、前記再生デバイスを使用して、前記ネットワークを介して、前記トップレベルインデックスファイルにおいて識別された前記別個のインデックスファイルから第1のインデックスファイルを得ることであって、前記第1のインデックスファイルは、前記エンコードされたビデオの第1のストリームに対するインデックスファイルであり、前記第1のインデックスファイルは、前記エンコードされたビデオの第1のストリームを含有する少なくとも1つのコンテナファイルの場所に関する情報を含有する、ことと、前記再生デバイスを使用して、前記ネットワークを介して、前記第1のインデックスファイルからの情報を利用して、前記エンコードされたビデオの第1のストリームに対するヘッダを得ることと、前記エンコードされたビデオの第1のストリームに対する前記ヘッダ内に含有される情報を使用して、前記再生デバイス内にビデオデコーダを構成することと、前記エンコードされたオーディオの識別された少なくとも1つのストリームから再生を開始するために、前記再生デバイスを使用して、利用すべきエンコードされたオーディオの第1のストリームを選択することと、前記再生デバイスを使用して、前記ネットワークを介して、前記トップレベルインデックスファイルにおいて識別された前記別個のインデックスファイルからオーディオインデックスファイルを得ることであって、前記オーディオインデックスファイルは、前記エンコードされたオーディオの第1のストリームに対するインデックスファイルであり、前記オーディオインデックスファイルは、前記エンコードされたオーディオの第1のストリームを含有する少なくとも1つのコンテナファイルの場所に関する情報を含有する、ことと、前記再生デバイスを使用して、前記ネットワークを介して、前記オーディオインデックスファイルからの情報を利用して、前記エンコードされたオーディオの第1のストリームに対するヘッダを得ることと、前記エンコードされたオーディオの第1のストリームに対する前記ヘッダ内に含有される情報を使用して、前記再生デバイス内にオーディオデコーダを構成することと、前記再生デバイスを使用して、前記 ネットワーク を介して、前記第1のインデックスファイルからの情報を利用して、前記エンコードされたビデオの第1のストリームからエンコードされたビデオの少なくとも第1の部分を得ることと、前記再生デバイスを使用して、前記ネットワークを介して、前記オーディオインデックスファイルからの情報を利用して、前記エンコードされたオーディオの第1のストリームからエンコードされたオーディオの少なくとも第1の部分を得ることと、前記メディアコンテンツの再生を開始することであって、前記開始することは、前記再生デバイス内の前記ビデオデコーダを使用して、前記エンコードされたビデオの第1のストリームからの前記エンコードされたビデオの少なくとも第1の部分内のエンコードされたビデオをデコードすることと、前記再生デバイス内の前記オーディオデコーダを使用して、前記エンコードされたオーディオの第1のストリームからの前記エンコードされたオーディオの少なくとも第1の部分内のエンコードされたオーディオをデコードすることとによって行われる、ことと、前記再生デバイスがエンコードされたメディアの付加的部分を得るにつれて、前記再生デバイスにおいて、前記再生デバイスによって経験される現在のストリーミング状態を評価することと、前記再生デバイスを使用して、前記再生デバイスによって経験される前記現在のストリーミング状態に基づいて、前記エンコードされたビデオの識別された代替ストリームからエンコードされたビデオの第2のストリームを選択することと、前記 第1の インデックスファイルと、前記ビデオデコーダを構成するために使用される前記エンコードされたビデオの第1のストリームに対する前記ヘッダ内に含有される前記情報とを前記再生デバイスのメモリ内に記憶することと、前記再生デバイスを使用して、前記ネットワークを介して、前記トップレベルインデックスファイルにおいて識別された前記別個のインデックスファイルから第2のインデックスファイルを得ることであって、前記第2のインデックスファイルは、前記エンコードされたビデオの第2のストリームに対するインデックスファイルであり、前記第2のインデックス ファイル は、前記エンコードされたビデオの第2のストリームの前記エンコードされたビデオの複数の部分を含有する少なくとも1つのコンテナファイルの場所を含有する、ことと、前記再生デバイスを使用して、前記ネットワークを介して、前記第2のインデックスファイルからの情報を利用して、前記エンコードされたビデオの第2のストリームに対するヘッダを得ることと、前記エンコードされたビデオの第2のストリームに対する前記ヘッダ内に含有される情報を使用して、前記再生デバイス内にビデオデコーダを構成することと、前記再生デバイスを使用して、前記ネットワークを介して、前記第2のインデックスファイルからの情報を利用して、前記エンコードされたビデオの第2のストリームからエンコードされたビデオの少なくとも1つの部分を得ることと、前記再生デバイスを使用して、前記ネットワークを介して、前記オーディオインデックスファイルからの情報を利用して、前記エンコードされたオーディオの第1のストリームからエンコードされたオーディオの少なくとも1つの付加的部分を得ることと、前記メディアコンテンツの再生を継続することであって、前記継続することは、前記再生デバイス内の前記ビデオデコーダを使用して、前記エンコードされたビデオの第2のストリームからの前記エンコードされたビデオの少なくとも1つの部分内のエンコードされたビデオをデコードすることと、前記再生デバイス内の前記オーディオデコーダを使用して、前記エンコードされたオーディオの第1のストリームからの前記エンコードされたオーディオの少なくとも1つの付加的部分内のエンコードされたオーディオをデコードすることとによって行われる、ことと、前記再生デバイスがエンコードされたメディアのさらなる付加的部分を得るにつれて、前記再生デバイスによって経験される現在のストリーミング状態を評価することと、前記再生デバイスを使用して、前記再生デバイスによって経験される前記現在のストリーミング状態に基づいて、前記エンコードされたビデオの識別された代替ストリームから前記エンコードされたビデオの第1のストリームを選択することと、前記再生デバイスの前記メモリから、前記 第1の インデックスファイルと、前記ビデオデコーダを構成するために使用される前記エンコードされたビデオの第1のストリームに対する前記ヘッダ内に含有される前記情報とを読み出すことと、前記再生デバイスの前記メモリから読み出された前記エンコードされたビデオの第1のストリームに対する前記ヘッダ内に含有される前記情報を使用して、前記再生デバイス内にビデオデコーダを構成することと、前記再生デバイスを使用して、前記ネットワークを介して、前記再生デバイスの前記メモリから読み出された前記第1のインデックスファイルからの情報を利用して、前記エンコードされたビデオの第1のストリームからエンコードされたビデオの少なくとも1つの部分を得ることと、前記再生デバイスを使用して、前記ネットワークを介して、前記オーディオインデックスファイルからの情報を利用して、前記エンコードされたオーディオの第1のストリームからエンコードされたオーディオの少なくとも1つのさらなる部分を得ることと、前記メディアコンテンツの再生を継続することであって、前記継続することは、前記再生デバイス内の前記ビデオデコーダを使用して、前記エンコードされたビデオの第1のストリームからの前記エンコードされたビデオの少なくとも1つの部分内のエンコードされたビデオをデコードすることと、前記再生デバイス内の前記オーディオデコーダを使用して、前記エンコードされたオーディオの第1のストリームからの前記エンコードされたオーディオの少なくとも1つのさらなる部分内のエンコードされたオーディオをデコードすることとによって行われる、こととを含む、方法。
Independent claims21
78 paragraphs, as filed
The present invention relates generally to adaptive streaming, and more particularly to adaptive bitrate streaming of encoded media contained within Matroska container files using the HyperText Transfer Protocol.
The term streaming media describes the playback of media on a playback device, where the media is stored on a server and continuously transmitted to the playback device over a network during playback. Typically, the playback device stores a sufficient amount of media in the buffer at any given time during playback to prevent playback interruptions, so that the playback device completes playback of the entire buffered media before receiving the next portion of media. Adaptive bitrate streaming or adaptive streaming involves detecting this streaming condition (e.g., the user's network bandwidth and CPU capacity) in real time and adjusting the quality of the streamed media accordingly. Typically, the source media is encoded at multiple bitrates, and the playback device or client switches between streaming different encodings depending on available resources.
Adaptive streaming solutions are generally based on the HyperText Transfer Protocol (HTTP), published by the Internet Engineering Task Force and the World Wide Web Consortium as RFC2616, or the Internet Engineering Task Force's RFC for the World Wide Web Consortium as RFC2326. Media is streamed between the server and the playback device using either the Real-Time Streaming Protocol (RTSP) published by HTTP or the Real-Time Streaming Protocol (RTSP) published by Force. HTTP is a stateless protocol that allows the playback device to request byte ranges within a file. HTTP is described as stateless because the server is not required to record information about the state of the playback device requesting information or the byte ranges requested by the playback device in order to respond to requests received from the playback device. RTSP is a network control protocol used to control streaming media servers. The playback device issues control commands such as "play" and "pause" to the server that streams the media to control the playback of the media file. When RTSP is used, the media server records the state of each client device and determines the media to stream based on the instructions received from the client device and the state of the client.
In an adaptive streaming system, the source media is typically stored on a media server as a top-level index file that points to several alternative streams, which contain the actual video and audio data. Each stream is typically stored within one or more container files. Different adaptive streaming solutions typically utilize different indexes and media containers. The Synchronized Multimedia Integration Language (SMIL), developed by the World Wide Web Consortium, is used to create the index in several adaptive streaming solutions, including IIS Smooth Streaming, developed by Microsoft Corporation (Redmond, Washington), and Flash Dynamic Streaming, developed by Adobe Systems Incorporated (San Jose, California). Apple Computer HTTP Adaptive Bitrate Streaming, developed by Streams Media Incorporated (Cupertino, California), typically implements an index file using an extended M3U playback file (.M3U8), which is a text file that contains a list of URIs that identify media container files. The most commonly used media container formats are the MP4 container format, specified in MPEG-4 Part 14 (i.e., ISO/IEC 14496-14), and the MPEG Transport Stream (TS) container, specified in MPEG-2 Part 1 (i.e., ISO/IEC standard 13818-1). The MP4 container format is utilized in IIS Smooth Streaming and Flash Dynamic Streaming. The TS container is used in HTTP Adaptive Bitrate Streaming.
The Matroska container is a media container developed by the Matroska non-profit organization (Aussonne, France) as an open standards project. Matroska containers are based on the Extensible Binary Meta Language (EBML), a binary variant of the Extensible Markup Language (XML). Matroska container decoding is supported by many Consumer Electronics (CE) devices. The DivX Plus file format, developed by DivX, LLC (San Diego, California), utilizes extensions to the Matroska container format (i.e., it is based on the Matroska container format, but includes elements not specified in the Matroska format).
<p>According to an embodiment of the present invention, a system and method for adaptive bitrate streaming of media stored in a Matroska container file utilizing the HyperText Transfer Protocol (HTTP) is disclosed. In one embodiment, a processor is configured to request portions of the file from a remote server via a client application. Additionally, the client application further configures the processor to identify a plurality of EBML container files, read top-level index data describing at least a maximum bitrate of the alternative streams contained within the EBML container files, parse the top-level index data to obtain information identifying the plurality of EBML container files, request at least one portion of the EBML container file containing at least one element specifying encoding parameters for the streams contained within the EBML container file, read an index referencing each element containing a portion of the encoded video in the at least one of the EBML container files, utilize the index to request a portion of the first EBML container file including the element containing the portion of the encoded video, receive and buffer the requested element, utilize the encoding parameters to decode the encoded video contained within the buffered element, measure a current streaming state, and select another one of the EBML container files from which to read an element containing the portion of the encoded video for decoding based on the measured streaming state and the description of the bitrates of the alternative streams contained in the top-level data.</p><p>A further embodiment includes the steps of reading top-level index data identifying each of a plurality of EBML container files and describing at least a maximum bit rate of each of the alternative streams contained within the EBML container file; parsing the top-level index data to obtain information identifying the plurality of EBML container files; requesting a portion of at least one of the EBML container files containing at least one element specifying encoding parameters for a stream contained within the EBML container file; receiving an index referencing an element containing a portion of each encoded video in at least one of the EBML container files; utilizing the index to request a portion of a first EBML container file including an element containing a portion of the encoded video; receiving and buffering the requested element;</p><p>Another embodiment of the invention includes a processor configured to import at least one multimedia file containing a source video via a source encoding application, in addition, the source encoding application further configures the processor to select a portion of the source video, transcode the selected portion of the source video into a plurality of alternative portions of an encoded video, each alternative portion being encoded using a different set of encoding parameters, starting with an intraframe that begins a closed group of pictures (GOP), write each of the alternative portions of the encoded video into elements of different EBML container files, each element being located within the EBML container file that also contains another element indicating the encoding parameters used to encode the alternative portion of the encoded video, and add an entry to at least one index that identifies the location of an element containing one of the alternative portions of the encoded video within each of the EBML container files.</p><p>Another further embodiment includes using a source encoder to iteratively select portions of a source video; using the source encoder to transcode the selected portions of the source video into multiple alternative portions of encoded video, each alternative portion encoded using a different set of encoding parameters and starting with an intraframe that begins a closed group of pictures (GOP); using the source encoder to write each of the alternative portions of the encoded video into elements of different EBML container files, each element located within the EBML container file that also contains another element containing a set of encoding parameters that corresponds to the encoding parameters used to encode the portion of the video; and adding an entry to at least one index that identifies the location of an element containing one of the alternative portions of the encoded video within each of the EBML container files.</p><p>The present invention provides, for example, the following:</p><p>1. A playback device configured for adaptive bitrate streaming using multiple alternative streams of encoded video packaged within an Extensible Binary Markup Language (EBML) container file, each of the multiple alternative streams being the same source video encoded using different encoding parameters such that each portion of the encoded video packed into an element of the EBML container file begins at an intraframe that begins a closed group of pictures (GOP), and each of the EBML container files includes at least one element that specifies encoding parameters for the streams contained within the EBML container file. The playback device includes a processor configured to request portions of a file from a remote server via a client application, the client application including: a processor configured to identify multiple EBML container files; read top-level index data describing at least a maximum bitrate of the alternative streams contained within the EBML container file; parse the top-level index data to retrieve the multiple EBML container files; and and selecting, for decoding, another one of the EBML container files from which to read an element containing a portion of encoded video, the selection being based on the measured streaming state and a description of a bit rate of the alternative stream contained in the top level data.</p><p>(Item 2) The playback device described in Item 1, wherein each of the EBML container files comprises a plurality of Cluster elements, each Cluster element containing a portion of the encoded video, the portion of the encoded video within each of the Cluster elements starting with an intraframe and including at least one closed picture group.</p><p>(Item 3) The playback device of item 2, wherein the portions of the encoded video in each of the Cluster elements have the same duration.</p><p>(Item 4) The playback device described in Item 2, wherein the portion of the encoded video in each of the Cluster elements has a duration of 2 seconds.</p><p>(Item 5) The playback device described in Item 2, wherein each Cluster element contains a time code and each encoded frame of the portion of the encoded video contained within the Cluster element is contained within a separate BlockGroup element.</p><p>(Item 6) The playback device described in Item 5, wherein the first BlockGroup element in the Cluster element contains the intra frame.</p><p>(Item 7) The playback device described in Item 6, wherein the first BlockGroup element contains a Block element that specifies a timecode attribute of the intraframe with respect to the timecode of the Cluster element.</p><p>(Item 8) The playback device of item 1, wherein each of the alternative streams of the encoded video is encoded at a different maximum bitrate.</p><p>(Item 9) The playback device of item 8, wherein at least two of the alternative streams of the encoded video are encoded with different resolutions using the same display aspect ratio but different sample aspect ratios.</p><p>(Item 10) The playback device described in Item 9, wherein at least one element in each of the EBML container files that specifies the encoding parameters of the stream contained within the EBML container file specifies the frame height, frame width, and sample aspect ratio of the video stream contained within the EBML container file.</p><p>(Item 11) The playback device described in Item 10, wherein the client application configures the processor to set the frame height, frame width, and sample aspect ratio prior to starting decoding of encoded video contained within an element buffered from one of the EBML container files.</p><p>(Item 12) The playback device of item 8, wherein at least two of the alternative streams of the encoded video are encoded at different frame rates.</p><p>(Item 13) The playback device described in Item 12, wherein at least one element in each of the EBML container files that specifies the encoding parameters of the stream contained within the EBML container file specifies a frame rate of the video stream contained within the EBML container file.</p><p>(Item 14) The playback device described in Item 13, wherein the client application configures the processor to set the frame rate prior to starting decoding of the encoded video contained within an element buffered from one of the EBML container files.</p><p>(Item 15) The playback device of item 11, wherein the client application configures the playback device to request portions of a file from a remote server via HyperText Transfer Protocol (HTTP) byte range requests.</p><p>(Item 16) The playback device described in Item 1, wherein the top level index data is SMIL data, and the information identifying the multiple EBML container files is a multiple Universal Resource Indicators (URIs) that identify the location of each of the EBML container files.</p><p>(Item 17) The playback device described in Item 1, wherein the SMIL data specifies a maximum bit rate for the encoded stream contained within the EBML container file identified by each of the URIs.</p><p>(Item 18) The playback device described in Item 17, wherein an index referencing each of the elements in the EBML container file that contain a portion of the encoded stream is located within at least one element of the EBML container file, the SMIL file specifies the portion of the EBML container file that contains the element that contains the encoding parameters, and the client application configures the processor to parse the SMIL file to identify the portion of the EBML container file that contains the element that contains the encoding parameters and to request the portion of the EBML container file that contains the element that contains the encoding parameters.</p><p>(Item 19) The playback device described in Item 1, wherein each EBML container file includes at least one element containing an index that references each element containing a portion of the encoded video in the EBML container file, and the client application configures the processor to read the index that references each element containing a portion of the encoded video in the EBML container file by requesting a portion of the EBML container file that includes at least one element containing the index.</p><p>(Item 20) The playback device described in Item 19, wherein the index is located within a Cue element in the EBML container file.</p><p>(Item 21) The playback device described in Item 20, wherein the Cue element includes a time attribute and includes multiple CuePoint elements that point to the location of each element containing a portion of the encoded video within the EBML file.</p><p>(Item 22) The playback device described in Item 21, wherein the client application configures the processor to use a time attribute of the CuePoint element in the index to locate an element containing a particular portion of the encoded video in the EBML file and to request a portion of the EBML file that includes at least the element identified using the CuePoint element.</p><p>(Item 23) The playback device described in Item 1, wherein the encoding parameters utilized to decode the encoded video include at least one encoding parameter selected from the group consisting of frame rate, frame height, frame width, sample aspect ratio, maximum bit rate, and minimum buffer size.</p><p>(Item 24) The playback device described in Item 1, wherein the client application configures the processor to measure the current streaming state by measuring the time it takes to receive the requested element from the time the element was requested.</p><p>25. The playback device of claim 1, wherein the client application is configured to initially request a portion of a first EBML container file that contains at least one element that specifies the encoding parameters of a stream contained in the first EBML container file, and the client application is further configured to request a portion of the second EBML container file that contains at least one element that specifies encoding parameters of a stream contained in the second EBML container file when the client application selects to read an element that contains a portion of encoded video for decoding from a second EBML container file based on the measured streaming state and a description of a bit rate of the alternative stream contained in the top level index. 26. The playback device of claim 1, wherein the playback device is further configured to perform adaptive bit rate streaming using an EBML container file that contains a trick play track.</p><p>(Item 27) The playback device described in Item 26, wherein the client application configures the processor to select the EBML container file containing the trick play track as the EBML container file from which to read an element containing a portion of the encoded video in response to a user command.</p><p>(Item 28) The playback device of item 1, wherein the playback device is further configured to perform adaptive streaming using at least one EBML container file containing a track of encoded audio.</p><p>(Item 29) The playback device described in Item 28, wherein the client application configures the processor to read and decode encoded audio from one of the at least one EBML container files containing an audio track, and synchronize the decoded audio with the decoded video.</p><p>(Item 30) The playback device described in Item 1, wherein each of the EBML container files includes an element containing at least one track of encoded audio multiplexed with the encoded video.</p><p>(Item 31) The playback device described in Item 28, wherein the client application is configured to read a portion of the EBML file containing an element including a portion of one of the encoded audio tracks, decode the read encoded audio, and synchronize the decoded audio with the decoded video.</p><p>(Item 32) The playback device of item 1, wherein the playback device is further configured to perform adaptive streaming using at least one EBML container file containing a subtitle track.</p><p>(Item 33) The playback device of item 32, wherein the client application configures the processor to read subtitles from one of the at least one EBML container file containing a subtitle track, synchronize the subtitles with the decoded video, and overlay the subtitles on the decoded video.</p><p>(Item 34) The playback device described in Item 1, wherein each of the EBML container files includes an element containing at least one subtitle track multiplexed with the encoded video.</p><p>(Item 35) The playback device of item 34, wherein the client application is configured to read a portion of the EBML file containing an element including a portion of one of the subtitle tracks, synchronize the subtitles with the decoded video, and overlay the subtitles on the decoded video.</p><p>36. A method for adaptive bitrate streaming of media on a playback device using multiple alternative streams of encoded video packaged within Extensible Binary Markup Language (EBML) container files, each of the alternative streams of video being the same source video encoded using different encoding parameters such that each portion of the encoded video packed into an element of an EBML container file begins at an intraframe that begins a closed group of pictures (GOP), and each of the EBML container files includes at least one element that specifies encoding parameters for a stream contained within the EBML container file, the method comprising: identifying each of the multiple EBML container files and reading top-level index data describing at least a maximum bitrate of each of the alternative streams contained within the EBML container file; parsing the top-level index data to obtain information identifying the multiple EBML container files; and reading the top-level index data to obtain information identifying the multiple EBML container files. and selecting, for decoding, another one of the EBML container files from which to read an element containing a portion of encoded video, the selection being based on the measured streaming state and a description of a bit rate of the alternative stream contained in the top-level index data.</p><p>(Item 37) A source encoder configured to encode a source video as multiple alternative video streams packed within a container file, the container file being an Extensible Binary Markup Language (EBML) file, the source encoder comprising a processor configured to import at least one multimedia file containing a source video via a source encoding application, the source encoding application configuring the processor to: select a portion of the source video; transcode the selected portion of the source video into multiple alternative portions of an encoded video, each alternative portion being encoded using a different set of encoding parameters and beginning with an intraframe that begins a closed group of pictures (GOP); write each of the alternative portions of the encoded video into elements of different EBML container files, each element being located within an EBML container file that also contains another element that indicates the encoding parameters used to encode the alternative portion of the encoded video; and add an entry to at least one index that identifies the location of an element containing one of the alternative portions of the encoded video within each of the EBML container files.</p><p>(Item 38) The source encoder of item 37, wherein transcoding the selected portion of the source video further includes transcoding the selected portion into at least one closed picture group.</p><p>(Item 39) A source encoder as described in Item 37, wherein the portion of the source video is selected based on a duration of the selected portion of the source video.</p><p>(Item 40) A source encoder as described in Item 39, wherein the source encoding application configures the processor to select a portion of the source video having a duration of 2 seconds.</p><p>(Item 41) The source encoder of item 37, wherein each of the alternative portions of the encoded video is encoded at a different maximum bitrate.</p><p>(Item 42) The source encoder of item 41, wherein at least two of the alternative portions of the encoded video are encoded at different resolutions.</p><p>(Item 43) The source encoder of item 41, wherein at least two of the alternative portions of the encoded video are encoded at different frame rates.</p><p>(Item 44) A source encoder as described in Item 37, wherein the element of the EBML container file into which each alternative portion of the encoded video is written is a Cluster element containing a time code, and the portion of the encoded video is contained within a BlockGroup element within the Cluster element.</p><p>(Item 45) A source encoder as described in Item 44, wherein each encoded frame of the alternative portion of the encoded video contained within the Cluster element is contained within a separate BlockGroup element.</p><p>(Item 46) A source encoder as described in Item 45, wherein the first BlockGroup element in the Cluster element contains an IDR frame.</p><p>(Item 47) The source encoder of item 46, wherein the first BlockGroup element contains a Block element that specifies a timecode attribute of the IDR frame relative to the timecode of the Cluster element.</p><p>(Item 48) A source encoder as described in Item 37, wherein each element into which each alternative portion of the encoded video is written is assigned the same timecode.</p><p>(Item 49) The source encoder of item 37, wherein the source encoding application further configures the processor to create an index for each of the EBML container files.</p><p>(Item 50) The source encoder of item 49, wherein the source encoding application further configures the processor to add the location of an element containing one of the alternative portions of the encoded video in each of the EBML container files to an index for the EBML container files.</p><p>(Item 51) The source encoder of item 49, wherein the source encoding application further configures the processor to pack the index for each EBML container file into the EBML container file.</p><p>(Item 52) A source encoder as described in Item 51, wherein each index comprises a Cues element.</p><p>(Item 53) A source encoder as described in Item 52, wherein each Cue element includes a CuePoint element that points to the location of an element in the EBML file that contains one of the alternative portions of the encoded video.</p><p>(Item 54) The source encoder of item 37, wherein the source encoding application further configures the processor to create a top-level index file that identifies each of the EBML container files.</p><p>(Item 55) A source encoder as described in Item 37, wherein the captured multimedia file also includes source audio.</p><p>(Item 56) The source encoder of item 55, wherein the source encoding application configures the processor to multiplex audio into each of the EBML container files.</p><p>(Item 57) The source encoder of item 55, wherein the source encoding application configures the processor to write the audio to a separate EBML container file.</p><p>(Item 58) The source encoder of item 55, wherein the source encoding application further configures the processor to transcode at least one of the at least one audio track.</p><p>(Item 59) The source encoder of item 55, wherein the captured multimedia file further comprises subtitles.</p><p>(Item 60) The source encoder of item 59, wherein the source encoding application configures the processor to multiplex the subtitles into each of the EBML container files.</p><p>(Item 61) The source encoder of item 59, wherein the source encoding application configures the processor to write the subtitles to a separate EBML container file.</p><p>(Item 62) The source encoder of item 37, wherein the source encoding application further configures the processor to transcode the source video to create a lower frame rate trick play track and write the trick play track to a separate EBML container file.</p><p>(Item 63) A source encoder as described in Item 62, wherein the trick play track is also at a lower resolution than the source video.</p><p>(Item 64) The source encoder of item 37, wherein the source encoding application further configures the processor to write an element containing a set of encoding parameters into each of the EBML container files.</p><p>(Item 65) A source encoder as described in Item 64, wherein the set of encoding parameters includes at least one parameter selected from the group consisting of frame rate, frame height, frame width, sample aspect ratio, maximum bit rate, and minimum buffer size.</p><p>(Item 66) A method for encoding a source video as a plurality of alternative streams packed into an Extensible Binary Markup Language (EBML) file using a source encoder, the method including: using the source encoder to repeatedly select a portion of the source video; using the source encoder to transcode the selected portion of the source video into a plurality of alternative portions of encoded video, each alternative portion being encoded using a different set of encoding parameters and beginning with an intraframe that begins a closed group of pictures (GOP); using the source encoder to write each of the alternative portions of the encoded video into elements of different EBML container files, each element being located within an EBML container file that also contains another element containing a set of encoding parameters that correspond to the encoding parameters used to encode the portion of the video; and adding an entry to at least one index that identifies the location of an element containing one of the alternative portions of the encoded video in each of the EBML container files.</p>
<figref num="1">FIG. 1 is a network diagram of an adaptive bitrate streaming system according to one embodiment of the present invention.</figref><figref num="2">FIG. 2 conceptually illustrates a top-level index file and a Matroska container file produced by encoding source media according to an embodiment of the present invention.</figref><figref num="3">FIG. 3 conceptually illustrates a specialized Matroska container file incorporating a modified Cue element according to one embodiment of the present invention.</figref><figref num="4a">4a-4c conceptually illustrate the insertion of different types of media into cluster elements of a Matroska container file, subject to various constraints that facilitate adaptive bitrate streaming, according to an embodiment of the present invention.</figref><figref num="4b">4a-4c conceptually illustrate the insertion of different types of media into cluster elements of a Matroska container file, subject to various constraints that facilitate adaptive bitrate streaming, according to an embodiment of the present invention.</figref><figref num="4c">4a-4c conceptually illustrate the insertion of different types of media into cluster elements of a Matroska container file, subject to various constraints that facilitate adaptive bitrate streaming, according to an embodiment of the present invention.</figref><figref num="4d">FIG. 4d conceptually illustrates the multiplexing of different types of media into cluster elements of a Matroska container file, subject to various constraints that facilitate adaptive bitrate streaming, according to an embodiment of the present invention.</figref><figref num="4e">FIG. 4e conceptually illustrates the inclusion of trick-play tracks in a Cluster element of a Matroska container file, subject to various constraints that facilitate adaptive bitrate streaming, according to an embodiment of the present invention.</figref><figref num="5">FIG. 5 conceptually illustrates a modified Cue element of a special Matroska container file according to one embodiment of the invention, the Cue element containing information that enables reading of a Cluster element using an HTTP byte-range request.</figref><figref num="5a">Figure 5a conceptually illustrates a modified Cue element in a special Matroska container file according to one embodiment of the invention; the Cue element is similar to the Cue element shown in Figure 5, but with attributes that are not utilized during adaptive bitrate streaming removed.</figref><figref num="6">FIG. 6 conceptually illustrates the indexing of Cluster elements in a specialized Matroska container file, utilising modified CuePoint elements in the container file, according to an embodiment of the present invention.</figref><figref num="7">FIG. 7 is a flow diagram illustrating a process for encoding source media for adaptive bitrate streaming according to an embodiment of the present invention.</figref><figref num="8">FIG. 8 conceptually illustrates communication between a playback device and an HTTP server associated with initiating streaming of encoded media contained within a Matroska container file indexed by a top-level index file in accordance with one embodiment of the present invention.</figref><figref num="9a">9a and 9b conceptually illustrate communications between a playback device and an HTTP server associated with switching between streams in response to streaming conditions experienced by the playback device prior to the stream switching decision and according to index information available to the playback device, in accordance with an embodiment of the present invention.</figref><figref num="9b">9a and 9b conceptually illustrate communications between a playback device and an HTTP server associated with switching between streams in response to streaming conditions experienced by the playback device prior to the stream switching decision and according to index information available to the playback device, in accordance with an embodiment of the present invention.</figref>
Referring now to the drawings, a system and method for adaptive bitrate streaming of media stored within a Matroska container file utilizing HyperText Transfer Protocol (HTTP) is illustrated, according to an embodiment of the present invention. In some embodiments, source media is encoded as several alternative streams. Each stream is stored within a Matroska (MKV) container file. In many embodiments, the Matroska container file is a specialized Matroska container file in that the manner in which the media within each stream is encoded and stored within the container is constrained to improve streaming performance. In some embodiments, the Matroska container file is even more specialized in that additional index elements (i.e., elements not specified as part of the Matroska container format) can be included within the file to facilitate retrieval of the desired media during adaptive bitrate streaming. In some embodiments, each stream (i.e., audio, video, or subtitles) is stored within a separate Matroska container file. In other embodiments, an encoded video stream is multiplexed with one or more encoded audio and/or subtitle streams within each Matroska container file. A top-level index file, containing indexes to the streams contained within each of the container files, is also generated to enable adaptive bitrate streaming of the encoded media. In many embodiments, the top-level index file is a Synchronized Multimedia Integration Language (SMIL) file that contains URIs to each of the Matroska container files. In other embodiments, any of a variety of file formats can be utilized in generating the top-level index file.
The performance of an adaptive bitrate streaming system according to an embodiment of the present invention can be significantly improved by encoding each portion of the source video at each bitrate such that the portion of the video is encoded in each stream as a single (or at least one) closed group of pictures (GOP) starting at an instantaneous decoding update (IDR) frame. The GOP for each stream can then be stored as a Cluster element in the Matroska container file for the stream. In this way, a playback device can switch between streams upon completion of playback, and regardless of the stream from which the cluster was obtained, the first frame in the cluster is an IDR frame and can be decoded without reference to any encoded media other than the encoded media contained in the Cluster element. In many embodiments, the sections of the source video that are encoded as GOPs are all of the same duration. In some embodiments, each 2-second sequence of the source video is encoded as a GOP.
During adaptive streaming, retrieval of media using HTTP can be improved by adding additional index information to the Matroska container file used to contain each of the encoded streams. In some embodiments, the index is a simplified index, in that it only points to the IDR at the start of each cluster. In many embodiments, the index of the Matroska container file includes additional non-standard attributes (i.e., attributes that do not form part of the Matroska container file format specification) that specify the size of each of the clusters, so that a playback device can read Cluster elements from the Matroska container file over HTTP using byte range requests.
Adaptive streaming of source media encoded as described above can be adjusted by a playback device according to an embodiment of the present invention. The playback device obtains information about each of the available streams from the top level index file and selects one or more streams to utilize in playing the media. The playback device can then obtain header information from the Matroska container file containing one or more bitstreams or streams, the header providing information for decoding the streams. The playback device can also request index information that indexes the encoded media stored in the associated Matroska container file. The index information can be stored in the top level index or a separate index file, either in the Matroska container file or separately from the Matroska container file. The index information allows the playback device to request, from the server, via HTTP, byte ranges corresponding to Cluster elements in the Matroska container file that contain a particular portion of the encoded media. As the playback device receives Cluster elements from the HTTP server, the playback device can evaluate the current streaming state and determine whether to increase or decrease the bitrate of the streamed media. When the playback device determines that a change in bitrate is required, it can obtain header and index information for the container file containing the desired stream (assuming the playback device has not already obtained this information). The index information can then be used to identify the byte range of the Cluster element containing the next portion of the source media encoded at the desired bitrate, and the identified Cluster element can be retrieved from the server via HTTP. The next portion of source media requested is typically identified based on Cluster elements already requested by the playback device and Cluster elements buffered by the playback device. The next portion of source media requested from the alternative stream is requested prior to receipt by the playback device of the Cluster element containing the next portion of source media to minimize the likelihood that the playback device's buffer will underflow (i.e., run out of media to play). In this way, the playback device can achieve adaptive bitrate streaming by using the top-level index and index information describing the Cluster elements within each of the Matroska container files to sequentially read Cluster elements from the various streams depending on their suitability for the streaming conditions.
In some embodiments, variation of bitrate between different streams can be achieved by modifying encoding parameters for each stream, including, but not limited to, bitrate, frame rate, and resolution. When different streams include different resolutions, the display aspect ratio of each stream is the same, and the sample aspect ratio is modified to ensure a smooth transition from one resolution to another. Encoding of source video for use in adaptive bitrate streaming and playback of encoded source video using HTTP requests to achieve adaptive bitrate streaming in accordance with embodiments of the present invention are discussed further below.
Adaptive Streaming System Architecture An adaptive streaming system according to an embodiment of the present invention is illustrated in FIG. 1. The adaptive streaming system 10 includes a source encoder 12 configured to encode source media as a number of alternate streams. In the illustrated embodiment, the source encoder is a server. In other embodiments, the source encoder can be any processing device that includes a processor and sufficient resources to transcode source media (including, but not limited to, video, audio, and/or subtitles). As discussed further below, the source encoding server 12 generates a top-level index to multiple container files that contain the streams, at least some of which are alternate streams. Alternate streams are streams that encode the same media content in different ways. In many instances, the alternate streams encode media content (such as, but not limited to, video) at different bit rates. In some embodiments, the alternate streams are encoded at different resolutions and/or different frame rates. The top-level index file and the container file are uploaded to an HTTP server 14. Various playback devices can then request the top-level index file and portions of the container file over a network 16, such as the Internet, using HTTP or another suitable stateless protocol.
In many embodiments, the top-level index file is a SMIL file and the media is stored in a Matroska container file. As discussed further below, the media can be stored in the Matroska container file to facilitate adaptive bitrate streaming of the media. In many embodiments, the Matroska container file is a specialized Matroska container file that includes enhancements (i.e., elements that do not form part of the Matroska file format specification) that facilitate retrieval of certain portions of the media over HTTP during adaptive bitrate streaming of the media.
In the illustrated embodiment, the playback devices include a personal computer 18 and a mobile phone 20. In other embodiments, the playback devices can include consumer electronics devices, such as DVD players, Blu-ray players, televisions, set-top boxes, video game consoles, tablets, and other devices that can connect to a server via HTTP and play encoded media. Although a specific architecture is shown in Figure 1, any of a variety of architectures can be utilized to enable a playback device to request portions of the top-level index file and container file in accordance with embodiments of the present invention.
File Structure: The files generated by a source encoder and/or stored on an HTTP server for streaming to a playback device according to an embodiment of the present invention are illustrated in FIG. 2. The files utilized in adaptive bitrate streaming of source media include a top level index 30 and a number of container files 32, each containing at least one stream. The top level index file describes the contents of each of the container files. As discussed further below, the top level index file can take a variety of forms, including a SMIL file, and the container files can take a variety of forms, including a specialized Matroska container file.
In many embodiments, each Matroska container file contains a single stream. For example, the stream may be one of several alternative video streams, an audio stream, one of several alternative audio streams, a subtitle stream, one of several alternative subtitle streams, a trick play stream, or one of several alternative trick play streams. In some embodiments, the Matroska container file contains multiple multiplexed streams. For example, a Matroska container may contain a video stream, and one or more audio streams, one or more subtitle streams, and/or one or more trick play streams. As discussed further below, in many embodiments, the Matroska container file is a special file. The encoding of media and the manner in which the media is stored within Cluster elements within a Matroska container file may be subject to constraints designed to improve the performance of the adaptive bitrate streaming system. In addition, the Matroska container file may contain an index element that facilitates identification and downloading of Cluster elements from various Matroska container files during adaptive streaming of media. Top-level index files and Matroska container files that may be used in an adaptive bitrate streaming system according to embodiments of the present invention are discussed below.
(Top Level Index File) In accordance with many embodiments of the present invention, a playback device utilizes a top level index file to identify container files that contain streams available to the playback device for use in adaptive bitrate streaming. In many embodiments, the top level index file may each include references to container files that contain alternate streams of the encoded media. The playback device may utilize the information in the top level index file to read the encoded media from each of the container files according to the streaming conditions experienced by the playback device.
In some embodiments, the top-level index file provides information that allows a playback device to read information regarding the encoding of the media in each of the container files and an index to the encoded media in each of the container files. In some embodiments, each container file includes information regarding the encoded media contained within the container file and an index to the encoded media in the container file, and the top-level index file indicates the portion of each container file that contains this information. Thus, a playback device can read the top-level index file and use the top-level index file to request one or more portions of the container file that include information regarding the encoded media contained within the container file and an index to the encoded media in the container file. Various top-level index files that can be used in an adaptive bitrate streaming system according to embodiments of the present invention are discussed further below.
Top-Level Index SMIL File In some embodiments, the top-level index file utilized in adaptive bitrate streaming of media is a SMIL file, which is an XML file that contains a list of URIs describing each of the streams and the container files that contain the streams. The URIs can contain information, such as the "system-bitrate" of the stream and information about the location of the particular piece of data within the container file that is contained within the stream.
The basic structure of a SMIL file involves providing an XML declaration and SMIL elements that define the streams available for use in adaptive bitrate streaming, including a HEAD element, which is typically left empty, and a BODY element, which typically contains only a PAR (parallel) element. The PAR elements describe streams that can be played simultaneously (i.e., contain media that can be presented simultaneously).
The SMIL specification defines several child elements for the PAR element that can be used to specify the available streams for use in adaptive bitrate streaming. The VIDEO, AUDIO, and TEXTSTREAM elements can be used to define a specific video, audio, or subtitle stream. Collectively, the VIDEO, AUDIO, and TEXTSTREAM elements can be referred to as media objects. The basic attributes of a media object are the SRC attribute, which specifies the full path or URI to the container file that contains the associated stream, and the XML:LANG attribute, which contains a three-letter language code. Additional information about a media object can be specified using PARAM elements. The PARAM element is a standard way within the SMIL format to provide common name-value pairs. In some embodiments of the present invention, specific PARAM elements are defined to be used during adaptive bitrate streaming.
In many embodiments, a "header-request" PARAM element is defined to specify the size of the header section of the container file that contains the stream. The value of the "header-request" PARAM element typically specifies the number of bytes between the start of the file and the start of the encoded media within the file. In many embodiments, the header contains information about the manner in which the media is encoded, and the playback device reads the header prior to playing the encoded media to enable it to configure a decoder for playback of the encoded media. An example of a "header-request" PARAM element is:
<math num="1"><img file="JP7692956B2_D0001.tif" /></math>It is.
In some embodiments, a "mime" PARAM element is defined to specify the MIME type of the stream. A "mime" PARAM element that identifies a stream as an H.264 stream (i.e., a stream encoded according to the MPEG-4 Advanced Video Codec standard) would be:
<math num="2"><img file="JP7692956B2_D0002.tif" /></math>It is.
The MIME type of the stream can be specified using the "mime" PARAM element, depending on the appropriateness for the encoding of the particular stream (eg, AAC audio or UTF-8 text stream).
When the media object is a VIDEO element, additional attributes are defined within the SMIL File Format specification, including a systemBitrate attribute that specifies the bitrate of the stream in the container file identified by the VIDEO element, and width and height attributes that specify the dimensions of the encoded video in pixels. Additional attributes can also be defined using PARAM elements. In some embodiments, a "vbv" PARAM element is defined to specify the VBV buffer size in bytes for the video stream. The Video Buffering Verifier (VBV) is a theoretical MPEG video buffer model that is used to ensure that an encoded video stream can be correctly buffered and played back on a decoder device. An example of a "vbv" PARAM element specifying a VBV size of 1000 bytes is:
<math num="3"><img file="JP7692956B2_D0003.tif" /></math>It is.
An example of a VIDEO element containing the above attributes is:
<math num="4"><img file="JP7692956B2_D0004.tif" /></math>It is.
An adaptive bitrate streaming system according to an embodiment of the invention can accommodate trick play streams, which can be used to provide smooth visual navigation of source content encoded for adaptive bitrate streaming. A trick play stream is encoded so that upon playback, visual navigation through the source media is accelerated; in fact, the trick play stream is simply a separate track that encodes the source media at a lower frame rate. In many embodiments of the system, references to trick play tracks are indicated by the systemProfile attribute of the VIDEO element. In other embodiments, any of a variety of techniques can be utilized to indicate within the top-level index file that a particular stream is a trick play stream. An example of a trick play stream VIDEO element according to an embodiment of the invention is:
<math num="5"><img file="JP7692956B2_D0005.tif" /></math>It is.
In some embodiments of the present invention, a "reservedBandwidth" PARAM element may be defined for the AUDIO element. The "reservedBandwidth" PARAM element specifies the bitrate of the audio stream in Kbps. An example of an AUDIO element that may be specified according to an embodiment of the present invention is:
<math num="6"><img file="JP7692956B2_D0006.tif" /></math>It is.
In some embodiments, a "reservedBandwidth" PARAM element is also defined for the TEXTSTREAM element. An example of a TEXTSTREAM element that includes a "reservedBandwidth" PARAM element, according to an embodiment of the invention, is:
<math num="7"><img file="JP7692956B2_D0007.tif" /></math>It is.
In other embodiments, any of a variety of mechanisms can be utilized to specify information about the VIDEO, AUDIO, and SUBTITLE elements, depending on appropriateness for a particular application.
The SWITCH element is a mechanism defined within the SMIL file format specification that can be used to define adaptive or alternate streams. An example of how the SWITCH element can be used to specify alternate video streams at different bit rates is:
<math num="8"><img file="JP7692956B2_D0008.tif" /></math>It is.
The SWTICH element specifies the URLs of three alternative video streams. The file names indicate the different bit rates of each of the streams. As discussed further below, the SMIL file format specification provides a mechanism that can be utilized in accordance with embodiments of the invention to specify, within a top-level index SMIL file, additional information about the stream and the container file in which it is contained.
In many embodiments of the present invention, the EXCL (exclude) element is used to define alternative tracks that will not be applied during playback with streaming conditions. For example, the EXCL element can be used to define alternative audio tracks or alternative subtitle tracks. An example of how the EXCL element can be utilized to specify alternative English and French audio streams is:
<math num="9"><img file="JP7692956B2_D0009.tif" /></math>It is.
An example of a top-level index SMIL file that defines attributes and parameters for two alternative video levels, an audio stream, and a subtitle stream according to one embodiment of the invention is:
<math num="10-1"><img file="JP7692956B2_D0010.tif" /></math>
<math num="10-2"><img file="JP7692956B2_D0011.tif" /></math>It is.
The top-level index SMIL file can be generated when source media is encoded for playback via adaptive bitrate streaming. Alternatively, the top-level index SMIL file can be generated when a playback device requests to begin playback of the encoded media. When the playback device receives the top-level index SMIL file, it can parse the SMIL file and identify available streams. The playback device can then select a stream and utilize it to play the content, and can use the SMIL file to identify portions of a container file and obtain information about the encoding of a particular stream and/or download to obtain an index to the encoded media within the container file.
Although a top-level index SMIL file is described above, any of a variety of top-level index file formats may be utilized to create the top-level index file, depending on their suitability for a particular application, in accordance with certain embodiments of the present invention. Use of top-level index files to enable playback of encoded media using adaptive bitrate streaming, in accordance with embodiments of the present invention, is discussed further below.
A Matroska container file used to store encoded video according to one embodiment of the invention (storing media in MATROSKA files for adaptive bitrate streaming) is illustrated in Figure 3. The container file 32 is an Extensible Binary Markup Language (EBML) file, which is an extension to the Matroska container file format. The specialized Matroska container file 32 contains standard EBML elements 34 and standard Seek elements 36. The Segment element 36 includes a standard Segment element 36, which includes a Head element 40, a standard Segment information element 42, and a standard Tracks element 44. These standard elements describe the media contained within the Matroska container file. The Segment element 36 also includes a standard Clusters element 46. As explained below, the manner in which the encoded media is inserted into the individual Cluster elements 48 within the Clusters element 46 is constrained to improve playback of the media within an adaptive streaming system. In many embodiments, the constraints imposed on the encoded video are consistent with the Matroska container file format specification and involve encoding the video such that each cluster contains at least one closed GOP that begins with an IDR frame. In addition to the standard elements mentioned above, the Segment element 36 also includes a modified version of the standard Cues element 52. As discussed further below, the Cues element includes a special CuePoint element (i.e., a non-standard CuePoint element) that facilitates retrieval of the media contained within a particular Cluster element via HTTP.
The constraints imposed on the encoding of media for adaptive bitrate streaming and the format of the encoded media within the Clusters element of a Matroska container file, as well as the additional index information inserted into the container file, according to embodiments of the present invention are discussed further below.
Encoding Media for Insertion into Cluster Elements The adaptive bitrate streaming system provides a playback device with the option to select between different streams of encoded media during playback according to streaming conditions experienced by the playback device. In many embodiments, switching between streams is facilitated by pre-encoding discrete portions of the source media separately according to the encoding parameters of each stream, and then including each separately encoded portion within its own Cluster element in the stream's container file. Furthermore, the media contained within each cluster is encoded such that the media is playable without reference to media contained within any other cluster within the stream. In this way, each stream contains a Cluster element corresponding to the same discrete portion of the source media, and at any time, the playback device can select a Cluster element from the stream that is most appropriate for the streaming conditions experienced by the playback device, and begin playing the media contained within the Cluster element. Thus, the playback device can select clusters from different streams as streaming conditions experienced by the playback device change over time. In some embodiments, the Cluster elements are further constrained such that each Cluster element contains a portion of media encoded from the source media that has the same duration. In some embodiments, each Cluster element contains 2 seconds of encoded media. The specific constraints that apply to the media encoded within each Cluster element depending on the type of media (i.e., video, audio, or subtitles) are discussed below.
A Clusters element of a Matroska container file containing a video stream according to an embodiment of the present invention is illustrated in FIG. 4a. The Clusters element 46 contains multiple Cluster elements 48, each of which contains a discrete portion of the encoded video. In the illustrated embodiment, each Cluster element 48 contains 2 seconds of encoded video. In other embodiments, the Cluster elements contain encoded video having more or less than 2 seconds. The smaller the Cluster element (i.e., the shorter the duration of the encoded media in each Cluster element), the higher the overhead associated with requesting each Cluster element. Thus, there is a trade-off between the responsiveness of the playback device to changes in streaming conditions and the effective data rate (i.e., the portion of the available bandwidth that is actually utilized to transmit the encoded media) of the adaptive streaming system for a given set of streaming conditions. In some embodiments, the encoded video sequences within the Cluster element have different durations. Each Cluster element 48 contains a Timecode element 60 that indicates the start time of the encoded video within the Cluster element and the multiple BlockGroup elements. As previously mentioned, encoded video stored in a Cluster is constrained such that it may be played without reference to encoded video contained in any of the other Cluster elements in the container file. In many embodiments, encoding the video contained in the Cluster element as a GOP, where the first frame is an IDR frame, imposes the constraint. In the illustrated embodiment, the first BlockGroup element 62 contains an IDR frame. Thus, the first BlockGroup element 62 does not contain a ReferenceBlock element. The first BlockGroup element 62 contains a Block element 64 that specifies the Timecode attribute of the frame encoded in the Block element 64 relative to the Timecode of the Cluster element 48. Subsequent BlockGroup elements 66 are not restricted in the types of frames they may contain (other than that they cannot reference frames not contained in a Cluster element). Thus, the subsequent BlockGroup element 66 may contain ReferenceBlock elements 68 that reference other BlockGroup elements utilized in the decoding of the frames contained within the BlockGroup, or may contain IDR frames, similar to the first BlockGroup element 62. As mentioned above, the manner in which encoded video is inserted into the Cluster elements of a Matroska file conforms to the Matroska file format specification.
The insertion of encoded audio and subtitle information into Cluster elements 46 of a Matroska container file according to an embodiment of the invention is illustrated in Figures 4b and 4c. In the illustrated embodiment, the encoded media is inserted into Cluster elements 48, subject to the same constraints that apply to the encoded video discussed above in relation to Figure 4a. In addition, the duration of the encoded audio and subtitle information in each Cluster element corresponds to the duration of the encoded video in the corresponding Cluster element of the Matroska container file containing the encoded video. In other embodiments, Cluster elements in container files containing audio and/or subtitle streams need not correspond to the start times and durations of Cluster elements in container files containing alternative video streams.
Multiplexing Streams in a Single MKV Container File The cluster elements shown in Figures 4a-4c assume that a single stream is contained within each Matroska container file. In some embodiments, media from multiple streams are multiplexed within a single Matroska container file. In this way, a single container file can contain a video stream multiplexed with one or more corresponding audio streams and/or one or more corresponding subtitle streams. Storing the streams in this way can result in duplication of the audio and subtitle streams across multiple alternative video streams. However, retrieval time to retrieve encoded media from a video stream and associated audio and/or subtitle streams can be reduced due to contiguous storage of the data on the server. A cluster element 46 of a Matroska container file containing multiplexed video, audio, and subtitle data according to an embodiment of the invention is illustrated in Figure 4d. In the illustrated embodiment, each Cluster element 48 includes an additional BlockGroup element for each of the multiplexed streams. The first Cluster element includes a first BlockGroup element 62v for the encoded video, which contains an encoded video frame and includes a Block element 64v indicating the Timecode attribute of the frame (i.e., Timecode attribute 60) relative to the start time of the Cluster element. The second BlockGroup element 62a includes an encoded audio sequence and includes a Block element 64a indicating the Timecode of the encoded audio relative to the start time of the Cluster element, and the third BlockGroup element 62s includes an encoded subtitle sequence and includes a Block element 64s indicating the Timecode of the encoded subtitle relative to the start time of the Cluster element. Although not shown, in the illustrated embodiment, each Cluster element 48 likely includes additional BlockGroup elements containing additional encoded video, audio, or subtitles. Regardless of the multiplexing of the encoded video, audio, and/or subtitle streams, the same constraints on the encoded media apply.
Incorporation of trick play tracks into MKV container files for use in adaptive bitrate streaming systems. Incorporation of trick play tracks into Matroska container files is disclosed by DivX, LLC in U.S. patent application Ser. No. 12/260,404, filed Oct. 29, 2008, entitled "Application Enhancement Trick play tracks similar to those described in U.S. patent application Ser. No. 12/260,404 can be used to provide trick play streams for adaptive bitrate streaming systems and to provide smooth visual search through encoded source content for adaptive bitrate streaming, according to certain embodiments of the present invention. A separate trick play track can be encoded such that upon playback, visual search through the source media is accelerated, but in practice the trick play track is simply a separate track that encodes the source media at a lower frame rate. In some embodiments, the trick play stream is created by generating a trick play track as outlined in U.S. patent application Ser. No. 12/260,404, and inserting the trick play track into a Matroska container file, subject to the aforementioned constraints on the insertion of video streams into a Matroska container file. In many embodiments, the trick play track is also subject to the further constraint that each frame in the GOP of each Cluster element in the trick play track is encoded as an IDR frame. As with the other video streams, each Cluster element contains a GOP corresponding to the same 2 seconds of source media as the corresponding Cluster element in the other stream. Within the GOP of the trick play track, there are simply fewer frames, each frame having a longer duration. Thus, transitions to and from the trick play stream can be handled in the same manner as transitions between any of the other encoded streams are handled within an adaptive bitrate streaming system according to an embodiment of the present invention. To achieve visual search acceleration, playback of frames contained within the trick play track typically involves the playback device manipulating time codes assigned to frames of the encoded video prior to providing the frames to a decoder of the playback device to achieve a desired increase in the rate of search acceleration (e.g., x2, x4, x6, etc.).
A Cluster element containing media encoded from a trick play track is shown in Figure 4e. In the illustrated embodiment, the encoded trick play is inserted into Cluster element 48, subject to the same constraints that apply to the encoded video discussed above in relation to Figure 4a. However, each Block element contains an IDR. In other embodiments, the Cluster elements in the container file containing the trick play track need not correspond to the start times and durations of Cluster elements in the container file containing the alternative video stream.
In many embodiments, the source content can be encoded to provide a single trick play track or multiple trick play tracks for use by an adaptive bit rate streaming system. When a single trick play track is provided, the trick play track is typically encoded at a low bit rate. When multiple alternative trick play tracks are provided, adaptive rate streaming can also be performed with respect to the trick play track. In some embodiments, multiple trick play tracks are provided to accommodate different rates of visual search acceleration through the encoded media.
Incorporating Indexing Information into MKV Container Files The specification for the Matroska container file format provides an optional Cue element that is used to index Block elements within the container file. A modified Cue element 52 that can be incorporated into a Matroska container file and facilitate a request for a cluster by a playback device using HTTP is illustrated in FIG. 5 according to an embodiment of the present invention. The modified Cue element 52 includes a number of CuePoint elements 70, each of which includes a CueTime attribute 72. Each CuePoint element includes a CueTrackPosition element 74, which contains a CueTrack 76 and a CueClusterPosition 78 attribute. In many embodiments, the CuePoint element is configured primarily to identify a particular Cluster element, as opposed to a particular Block element within a Cluster element. However, in some applications, the ability to search for a particular BlockGroup element within a Cluster element is required, and additional indexing information is included within the Cue element.
The use of a modified Cues element to index encoded media within a Clusters element of a Matroska file, according to one embodiment of the present invention, is illustrated in Figure 6. A CuePoint element is generated to correspond to each Cluster element in the Matroska container file. The CueTime attribute 72 of the CuePoint element 70 corresponds to the Timecode attribute 60 of the corresponding Cluster element 48. In addition, the CuePoint element contains a CueTrackPosition element 74, which has a CueClusterPosition attribute 78 that points to the start of the corresponding Cluster element 48. The CueTrackPosition element 74 may also include a CueBlockNumber attribute, which is typically used to indicate the Block element that contains the first IDR frame in the Cluster element 48.
As can be easily seen, the modified Cue element 52 forms an index into each of the Cluster elements 48 within the Matroska container file. Additionally, the CueTrackPosition element provides information that can be used by a playback device to request a byte range of a particular Cluster element 48 from a remote server via HTTP or another suitable protocol. The Cue elements of a conventional Matroska file do not directly provide a playback device with information regarding how many bytes to request from the start of the Cluster element to obtain all of the encoded video contained within the Cluster element. The size of the Cluster element can be inferred within the modified Cue element by using the CueClusterPosition attribute of the CueTrackPosition element, which indexes the first byte of the next Cluster element. Alternatively, an additional CueTrackPosition element indexing the last byte of the Cluster element (in addition to the CueTrackPosition element indexing the first byte of the Cluster element) may be added to the modified Cue element in accordance with an embodiment of the present invention, and/or a non-standard CueClusterSize attribute specifying the size of the Cluster element pointed to by the CueClusterPosition attribute may be included within each CueTrackPosition element to facilitate retrieval of a specific Cluster element within a Matroska container file via an HTTP byte-range request or similar protocol.
The modification of the Cue elements as described above significantly simplifies the reading of Cluster elements from a Matroska container file via HTTP or a similar protocol during adaptive bitrate streaming. In addition, by only indexing the first frame in each cluster, the size of the index is significantly reduced. Given that indexes are typically downloaded prior to playback, the reduction in the size of the Cue elements (i.e., indexes) means that playback can begin more quickly. Using the CueClusterPosition element, a playback device can request a particular Cluster element from a stream that best suits the streaming conditions experienced by the playback device, simply by referencing the index of the associated Matroska container file using the Timecode attribute for the desired Cluster element.
In some embodiments, some attributes in a Cue element are not utilized during adaptive bitrate streaming. Therefore, the Cue element can be further modified by removing unused attributes to reduce the overall size of the index for each Matroska container file. A modified Cue element that may be utilized in a Matroska container file containing a single encoded stream according to an embodiment of the present invention is illustrated in FIG. 5a. The Cue element 52' illustrated in FIG. 5a is similar to the Cue element 52 illustrated in FIG. 5, except that the CuePoint element 70' does not include a CueTime attribute (see 72 in FIG. 5) and/or the CueTrackPosition element 74' does not include a CueTrack attribute (76 in FIG. 5). When the portions of encoded media in each Cluster element in a Matroska container file have the same duration, the CueTime attribute is not necessary. When Matroska contains files containing a single encoded stream, the CueTrack attribute is not necessary. In other embodiments, the Cue elements and/or other elements of the Matroska container file may be modified to remove elements and/or attributes that are not necessary for adaptive bitrate streaming of the encoded streams contained within the Matroska container file, given the manner in which the streams are encoded and inserted into the Matroska container file.
Although various modifications to the Cue element to include information about the size of each of the Cluster elements in a Matroska container file and to eliminate unnecessary attributes are described above, many embodiments of the present invention utilize traditional Matroska containers. In some embodiments, the playback device simply determines the size of the Cluster elements on the fly using information obtained from the traditional Cues element and/or relies on a separate index file that contains information about the size and/or location of the Cluster elements in the MKV container file. In some embodiments, the additional index information is stored in the top-level index file. In some embodiments, the additional index information is stored in a separate file that is identified in the top-level index file. When the index information utilized to read the Cluster elements from a Matroska container file is stored separately from the container file, the Matroska container file is still generally constrained to encode media for inclusion in a Cluster element, as described above. In addition, wherever the index information is located, it will generally index each Cluster element and include at least information about the starting location of each Cluster element, and in many cases, its size (but not limited to).
Encoding Source Media for Adaptive Bitrate Streaming A process for encoding source media as a top-level index file and multiple Matroska container files for use in an adaptive bitrate streaming system according to one embodiment of the present invention is illustrated in FIG. 7. The encoding process 100 begins by selecting a first portion of the source media (102) and encoding the source media using encoding parameters for each stream (104). When the portion of media is video, the portion of the source video is encoded as a single GOP starting at an IDR frame. In many embodiments, the encoding parameters used to create the alternate GOPs vary based on the bitrate, frame rate, encoding parameters, and resolution. In this way, the portion of media is encoded as a set of compatible alternatives, and the playback device can select the alternative that is most appropriate for the streaming conditions experienced by the playback device. When supporting different resolutions, the encoding of the streams is constrained such that each stream has the same display aspect ratio. A constant display aspect ratio can be achieved across different resolution streams by varying the sample aspect ratio with the resolution of the stream. In many cases, reducing the resolution can result in higher quality video compared to a higher resolution video encoded at the same bit rate. In many embodiments, the source media itself is encoded, and the encoding process (104) involves transcoding or translating the encoded source media according to the encoding parameters of each of the alternative streams supported by the adaptive bit rate streaming system.
Once the source media has been encoded as a set of alternate portions of the encoded media, each alternate portion of the encoded media is inserted into a Cluster element in the Matroska container file that corresponds to the stream to which the portion of the encoded media belongs (106). In many embodiments, the encoding process also builds an index for each Matroska container file as media is inserted into the Cluster elements in the container. Thus, the process 100 may also include creating a CuePoint element that points to the Cluster element to be inserted into the Matroska container file. The CuePoint element may be held in a buffer until the source media is completely encoded. Although the above process describes sequentially encoding each of the alternate portions of the encoded media in a single pass through the source media, many embodiments of the invention involve making a separate pass through the source media to encode each of the alternate streams.
Referring back to FIG. 7 , the process continues selecting (102) and encoding (104) portions of the source media until the entire source media has been encoded (108) for adaptive bitrate streaming, and then inserting (106) the encoded portions of the media into the Matroska container file corresponding to the appropriate stream. At that point, the process can insert (110) an index into the Matroska container for each stream and create (112) a top-level index file that indexes each of the encoded streams contained within the Matroska container file. As previously mentioned, indexes are created as the encoded media is created and CuePoint elements can be inserted into the Matroska container file such that CuePoint elements index each Cluster element within the Mastroska container file. Upon completion of the encoding, each CuePoint element can be contained within a Cue element, which can be inserted into the Matroska container file following the Cluster element.
Following encoding of the source media, after generating a Matroska container file containing each of the streams generated during the encoding process, which may include generation of trick play streams, and a top-level index file indexing each of the streams within the Matroska container file, the top-level index file and the Matroska container file can be uploaded to an HTTP server for adaptive bitrate streaming to a playback device. Adaptive bitrate streaming of media encoded in accordance with embodiments of the present invention using HTTP requests is discussed further below.
Adaptive Bitrate Streaming from MKV Container Files Using HTTP When source media is encoded such that there are alternative streams contained within separate Matroska container files for at least one of the video, audio, and subtitle content, adaptive streaming of the media contained within the Matroska container files can be achieved using HTTP requests or similar stateless data transfer protocols. In many embodiments, the playback device requests a top-level index file that resides on a server and uses the index information to identify the streams available to the playback device. The playback device can then retrieve the index for one or more of the Matroska files and use the index to request media from one or more of the streams contained within the Matroska container files using HTTP requests or similar stateless protocols. As previously mentioned, many embodiments of the invention implement the index for each of the Matroska container files using modified Cue elements. However, in some embodiments, the encoded media for each stream is contained within a standard Matroska container file and a separate index file can also be provided for each of the container files. Based on the streaming conditions experienced by the playback device, the playback device can select media from the alternative streams encoded at different bit rates. Once the media from each of the streams is inserted into the Matroska container file as described above, transitions between streams can occur upon completion of playback of the media in a Cluster element. Thus, the size of the Cluster element (i.e., the duration of the encoded media in a Cluster element) is typically chosen so that the playback device can respond quickly enough to commands from the user involving changes in streaming conditions and the utilization of trick play tracks. The smaller the Cluster element (i.e., the shorter the duration of the encoded media in each Cluster element), the higher the overhead associated with requesting each Cluster element. Thus, there is a trade-off between the responsiveness of the playback device to changes in streaming conditions and the effective data rate of the adaptive streaming system for a given set of streaming conditions (i.e., the portion of the available bandwidth that is actually utilized to transmit the encoded media). In many embodiments, the size of the Cluster element is chosen so that each Cluster element contains 2 seconds of encoded media. In other embodiments, the duration of the encoded media may be greater than or less than two seconds and/or the duration of the encoded media may vary per Cluster element.
Communication between a playback device or client and an HTTP server during playback of media encoded in separate streams contained within a Matroska container file indexed by a top-level index file according to one embodiment of the invention is illustrated in FIG. 8. In the illustrated embodiment, the playback device 200 begins playback by requesting a top-level index file from a server 202 using an HTTP request or similar protocol to receive the data. The server 202 provides bytes corresponding to the request. The playback device 200 then parses the top-level index file and identifies the URIs of each of the Matroska container files that contain streams of encoded media derived from a particular piece of source media. The playback device can then request, via HTTP or a similar protocol, byte ranges corresponding to one or more headers of the Matroska container files, the byte ranges being determined using information contained in the URI for the associated Matroska container file (see discussion above). In response to the request for byte ranges containing the headers of the Matroska container file, the server:
<math num="11"><img file="JP7692956B2_D0012.tif" /></math>Returns information about.
EBML elements are typically processed by playback devices to ensure that they correspond to the file version. The SeekHead element is parsed to locate the Matroska index element, and the SegmentInfo element contains two important elements utilized in playback: TimecodeScale and Duration. TimecodeScale specifies the timecode scale for all timecodes within a Segment of a Matroska container file, and Duration specifies the duration of a Segment based on the TimecodeScale. The Tracks element contains information used by playback devices to decode the encoded media contained within the Clusters element of a Matroska file. As previously mentioned, an adaptive bitrate streaming system according to an embodiment of the present invention can accommodate different streams encoded using different encoding parameters, including but not limited to frame rate and resolution. Thus, playback devices can use the information contained within the header of a Matroska container file to configure the decoder whenever a transition is made between encoded streams.
In many embodiments, the playback device does not receive headers for all of the Matroska container files indexed in the top-level index file. Instead, the playback device first determines the stream that will be used to begin playback and requests the headers from the corresponding Matroska container file. Depending on the structure of the URI contained in the top-level index file, the playback device can use either information from the URI or information from the Matroska container file header to request a byte range from the server that contains at least a portion of the index from the associated Matroska container file. The byte range can correspond to the entire index. The server provides the playback device with the associated byte range that contains the index information, and the playback device can use this information to request the byte range of the Cluster element that contains the encoded media. Once the Cluster element is received, the playback device can extract the encoded media from the Block elements in the Cluster element and can decode and play the media in the Block element according to its associated Timecode attribute.
In the illustrated embodiment, the playback device 200 requests enough index information from the HTTP server prior to the start of playback so that the playback device can use the index information to stream each selected stream in its entirety. In other embodiments, the playback device reads the index information continuously as the media is played. In some embodiments, the entire index information for the lowest bitrate stream is requested prior to playback so that index information for the lowest bitrate stream is available to the playback device in case streaming conditions suddenly deteriorate during playback.
Switching Between Streams The communication illustrated in Figure 8 assumes that the playback device continues to request media from the same stream (i.e., the Matroska container file) throughout the playback of the media. In practice, the streaming conditions experienced by the playback device are likely to change during playback of the streaming media, and the playback device may request media from an alternative stream (i.e., a different Matroska container file) to provide the best picture quality for the streaming conditions experienced by the playback device. In addition, the playback device may switch streams to perform trick play functions that utilize trick play track streams.
The communication between the playback device and the server when the playback device switches to a new stream according to an embodiment of the present invention is illustrated in FIG. 9a. The communication illustrated in FIG. 9a assumes that index information for the new stream has not been previously requested by the playback device and that downloading of Cluster elements from the old stream proceeds while information is obtained for the Matroska container file containing the new stream. When the playback device 200 detects a change in streaming conditions and determines that a higher bitrate stream is available in this streaming condition or receives a trick play command from the user, the playback device can use the top-level index file to identify a URI for an alternative stream that is more suitable for at least one of the video, audio, or subtitle streams for which the playback device is currently requesting encoded media. The playback device can save information about the current stream and use the parameters of the corresponding URI to request the byte range of the header for the Matroska container file containing the new stream. Caching information in this way can be beneficial when the playback device is trying to adapt the bitrate of a stream downward. When the playback device experiences a decrease in available bandwidth, the playback device would ideally switch quickly to a lower bitrate stream. Due to the bandwidth reduction experienced by the playback device, it is unlikely that the playback device will have the additional bandwidth to request the header and index information. Ideally, the playback device will utilize the entire available bandwidth to download the higher rate Cluster elements already requested and then use the locally cached index information to begin requesting Cluster elements from the Matroska container file containing the lower bitrate streams.
The byte range for the index information for the Matroska container file containing the new stream can be requested from the HTTP server 202 as described above in relation to Figure 8. At that point, the playback device can stop downloading the Cluster elements from the previous stream and begin requesting the byte range of the appropriate Cluster element from the Matroska container file containing the new stream from the HTTP server, using the index information from the Matroska container file to identify the Cluster element that contains the encoded media that follows the encoded media in the last Cluster element read by the playback device. As described above, smooth transitions from one stream to another are facilitated by encoding each of the alternative streams such that corresponding Cluster elements start at the same Timecode element and IDR frame.
If the playback device caches the entire header and index for each stream used in playing the media, it can simplify the process of switching back to a previously used stream. The playback device already has the header and index information for the Matroska file containing the previously used stream, and the playback device can simply use this information to initiate a request, via HTTP, for the Cluster element from the Matroska container file of the previously used stream. The communication between the playback device and the HTTP server when the playback device switches back to a stream for which it has cached header and index information, according to an embodiment of the invention, is illustrated in FIG. 9b. The process illustrated in FIG. 9b is ideally performed when adapting the bitrate downward, since the reduction in available resources may be exacerbated by the need to download index information in addition to the media. The likelihood of playback interruptions is reduced by increasing the speed at which the playback device switches between streams and reducing the amount of overhead data downloaded to accomplish the switch.
While the present invention has been described in certain specific aspects, many additional modifications and variations will become apparent to those skilled in the art. It should thus be understood that the present invention may be practiced otherwise than as specifically described, including, for example, various changes in implementation utilizing encoders and decoders that accommodate features other than those specified within the particular standard to which they comply, without departing from the scope and spirit of the present invention. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive.
27 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| WO2009065137A1 | Cites | World Intellectual Property Organization (WIPO) |
| WO2010147878A1 | Cites | World Intellectual Property Organization (WIPO) |
| US20090328124A1 | Cites | United States of America |
| US20090150557A1 | Cites | United States of America |
| US20030061369A1 | Cites | United States of America |
| IIS Smooth Streaming Technical Overview,Microsoft Corporation,2009年03月 | Non-patent | – |
| Specifications Matroska,[online],2010年12月17日,https://web.archive.org/web/20101217110959/http://matroska.org/technical/specs/index.html | Non-patent | – |
| Silvia,adaptive HTTP streaming for open codecs,[online],2010年10月09日,https://gingertech.net/2010/10/09/adaptive-http-streaming-for-open-codecs/ | Non-patent | – |
90 members in 7 offices
Members90
| Document | Office | Kind | |
|---|---|---|---|
| US2012170642A1 | United States of America | A1 | |
| US2012170643A1 | United States of America | A1 | |
| US2012170906A1 | United States of America | A1 | |
| US2012170915A1 | United States of America | A1 | |
| US2012173751A1 | United States of America | A1 | |
| CA2823829A1 | Canada | A1 | |
| WO2012094171A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2012094181A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2012094189A1 | World Intellectual Property Organization (WIPO) | A1 | |
| US2013044821A1 | United States of America | A1 | |
| EP2661696A1 | European Patent Office (EPO) | A1 | |
| EP2661875A1 | European Patent Office (EPO) | A1 | |
| EP2661895A2 | European Patent Office (EPO) | A2 | |
| KR20130133266A | Republic of Korea | A | |
| KR20130133830A | Republic of Korea | A | |
| US8649669B2 | United States of America | B2 | |
| JP2014506430A | Japan | A | |
| KR20140035881A | Republic of Korea | A | |
| WO2012094181A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP2661696A4 | European Patent Office (EPO) | A4 | |
| EP2661875A4 | European Patent Office (EPO) | A4 | |
| US2014250473A1 | United States of America | A1 | |
| US8914534B2 | United States of America | B2 | |
| US9025659B2 | United States of America | B2 | |
| US9210481B2 | United States of America | B2 | |
| US9247312B2 | United States of America | B2 | |
| US2016219303A1 | United States of America | A1 | |
| JP6038805B2 | Japan | B2 | |
| JP2017063453A | Japan | A | |
| US9883204B2 | United States of America | B2 | |
| KR101874907B1 | Republic of Korea | B1 | |
| KR20180081621A | Republic of Korea | A | |
| US2018220153A1 | United States of America | A1 | |
| JP2018160923A | Japan | A | |
| KR20180123182A | Republic of Korea | A | |
| CA2823829C | Canada | C | |
| JP6453291B2 | Japan | B2 | |
| KR101917763B1 | Republic of Korea | B1 | |
| US2019045219A1 | United States of America | A1 | |
| US2019045220A1 | United States of America | A1 | |
| US10368096B2 | United States of America | B2 | |
| US10382785B2 | United States of America | B2 | |
| KR101988877B1 | Republic of Korea | B1 | |
| US2019356928A1 | United States of America | A1 | |
| EP2661875B1 | European Patent Office (EPO) | B1 | |
| KR102072839B1 | Republic of Korea | B1 | |
| KR20200012048A | Republic of Korea | A | |
| KR20200012049A | Republic of Korea | A | |
| KR20200013095A | Republic of Korea | A | |
| JP6657313B2 | Japan | B2 | |
| EP2661696B1 | European Patent Office (EPO) | B1 | |
| JP2020080551A | Japan | A | |
| ES2767260T3 | Spain | T3 | |
| KR102122189B1 | Republic of Korea | B1 | |
| EP3697096A1 | European Patent Office (EPO) | A1 | |
| EP3700219A1 | European Patent Office (EPO) | A1 | |
| EP3742740A1 | European Patent Office (EPO) | A1 | |
| KR102191317B1 | Republic of Korea | B1 | |
| KR102195414B1 | Republic of Korea | B1 | |
| KR20200144586A | Republic of Korea | A | |
| ES2807884T3 | Spain | T3 | |
| US10992955B2 | United States of America | B2 | |
| KR102274290B1 | Republic of Korea | B1 | |
| KR20210084700A | Republic of Korea | A | |
| US2021250608A1 | United States of America | A1 | |
| JP2021158694A | Japan | A | |
| KR102352043B1 | Republic of Korea | B1 | |
| JP7000475B2 | Japan | B2 | |
| KR20220009503A | Republic of Korea | A | |
| EP3697096B1 | European Patent Office (EPO) | B1 | |
| EP3975574A1 | European Patent Office (EPO) | A1 | |
| ES2911672T3 | Spain | T3 | |
| EP3742740B1 | European Patent Office (EPO) | B1 | |
| KR102408120B1 | Republic of Korea | B1 | |
| KR20220082942A | Republic of Korea | A | |
| ES2917700T3 | Spain | T3 | |
| KR102445689B1 | Republic of Korea | B1 | |
| EP4124048A1 | European Patent Office (EPO) | A1 | |
| US11638033B2 | United States of America | B2 | |
| JP7332655B2 | Japan | B2 | |
| US2023300372A1 | United States of America | A1 | |
| JP2023138806A | Japan | A | |
| EP3700219B1 | European Patent Office (EPO) | B1 | |
| US2024414369A1 | United States of America | A1 | |
| ES2992853T3 | Spain | T3 | |
| US12250404B2 | United States of America | B2 | |
| US12262051B2 | United States of America | B2 | |
| US2025168400A1 | United States of America | A1 | |
| JP7692956B2This record | Japan | B2 | |
| JP2025105849A | Japan | A |
9 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 7692956
- Application
- 130932
Titles2
- Japanese
- ハイパーテキスト転送プロトコルを使用してMatroskaコンテナファイル中に記憶されるメディアの適応型ビットレートストリーミング
- English
- Adaptive Bitrate Streaming of Media Stored in Matroska Container Files Using the Hypertext Transfer Protocol
Classification
- CPC, 29
- G11B27/005
- H04N21/4621
- H04N19/593
- G11B27/11
- G11B27/322
- H04N21/2387
- H04N21/85406
- H04N21/23439
- H04N21/26258
- H04N21/2662
- H04N21/44209
- H04N21/8455
- H04N21/8456
- H04N21/8543
- H04N21/6587
- H04L65/613
- H04L65/612
- H04L65/70
- H04N21/236
- H04N21/440281
- H04N21/643
- H04N21/42607
- H04N21/435
- H04N21/44004
- H04N21/44008
- H04N19/172
- H04N19/177
- H04N19/40
- H04N21/234345
- IPC, 2
- H04N21 438
- H04N21 238
