JP5964972B2 - 複数のソースからのマルチメディアデータのストリーミング - Google Patents

Description

本出願は、参照によって全体が本明細書に組み込まれている、2011年9月7日に出願された米国仮出願第61/531,879号の利益を主張するものである。

本開示は、符号化マルチメディアデータの転送に関する。

デジタルビデオ機能は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込まれ得る。デジタルビデオデバイスは、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、Advanced Video Coding(AVC)、およびそのような規格の拡張によって定義される規格に記載されるような、ビデオ圧縮技法を実装して、デジタルビデオ情報をより効率的に送信および受信する。

ビデオ圧縮技法は、空間的予測および/または時間的予測を実行して、ビデオシーケンスに固有の冗長性を低減または除去する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスがマクロブロックに区分され得る。各マクロブロックはさらに区分され得る。イントラコード化(I)フレームまたはスライスにおけるマクロブロックは、近接マクロブロックに関する空間的予測を使用して符号化される。インターコード化(PまたはB)フレームまたはスライスにおけるマクロブロックは、同じフレームもしくはスライスにおける近接マクロブロックに関する空間的予測または他の参照フレームに関する時間的予測を使用し得る。

ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化され得る。ビデオデータは、ITU-T H.264/AVCのような、国際標準化機構(ISO)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。そのようなパケット化されたビデオデータは、ネットワークストリーミングを使用したコンピュータネットワークを介した送信のような、種々の方法で転送もしくは記憶されるか、またはDVDもしくはブルーレイディスクなどのローカルデータ記憶媒体上に記憶される場合がある。

一般に、本開示は、メディアデータのストリーミングを改善するための技法について説明する。本開示は、ハイパーテキスト転送プロトコル(HTTP)を使用してネットワークストリーミングを提供するソースに対する追加としてのソースにメディアデータのストリーミングを広げるための技法を提供する。たとえば、メディアデータは、動的適応ストリーミングオーバーHTTP(DASH)に従うが、ブロードキャストネットワーク送信ソース、オーバージエアブロードキャストソース、およびローカル記憶媒体など、HTTPサーバに対する追加または代替としてのソースから転送される場合がある。メディアデータおよび関連するデータ構造は概ね、DASHの仕様に準拠し得るが、メディアデータは実際には、HTTPを実装しているネットワークサーバ以外のソースから取り出され得る。

一例では、ビデオデータを取り出す方法が、マルチメディアコンテンツに関するマニフェストファイルを使用して、マルチメディアコンテンツのマルチメディアデータの取出し元になる複数の表現のうちの1つを選択するステップであって、マニフェストファイルは、マルチメディアコンテンツの複数の表現を示す情報を含み、複数の表現は、表現のうちの選択された1つを含み、表現に関するマルチメディアデータは、複数のソースから入手可能である、ステップと、選択された表現に関するマルチメディアデータの取出し元になるソースのうちの1つを選択するステップと、選択された表現に関するマルチメディアデータの少なくとも一部分を選択されたソースから取り出すステップとを含む。

別の例では、デバイスが、各々が複数のソースのそれぞれに通信可能に結合された複数のインターフェースと、マルチメディアコンテンツに関するマニフェストファイルを使用して、マルチメディアコンテンツのマルチメディアデータの取出し元になる複数の表現のうちの1つを選択するように構成されたストリーム管理ユニットであって、マニフェストファイルは、マルチメディアコンテンツの複数の表現を示す情報を含み、複数の表現は、表現のうちの選択された1つを含み、表現に関するマルチメディアデータは、複数のソースから入手可能であり、ストリーム管理ユニットは、選択された表現に関するマルチメディアデータの取出し元になるソースのうちの1つを選択するように構成されたストリーム管理ユニットと、選択されたソースに通信可能に結合されたインターフェースのうちの1つを介して、選択された表現に関するマルチメディアデータを選択されたソースから取り出すように構成されたソース構成要素とを含む。

別の例では、マルチメディアデータを取り出すためのデバイスが、マルチメディアコンテンツに関するマニフェストファイルを使用して、マルチメディアコンテンツのマルチメディアデータの取出し元になる複数の表現のうちの1つを選択するための手段であって、マニフェストファイルは、マルチメディアコンテンツの複数の表現を示す情報を含み、複数の表現は、表現のうちの選択された1つを含み、表現に関するマルチメディアデータは、複数のソースから入手可能である、手段と、選択された表現に関するマルチメディアデータの取出し元になるソースのうちの1つを選択するための手段と、選択された表現に関するマルチメディアデータの少なくとも一部分を選択されたソースから取り出すための手段とを含む。

別の例では、コンピュータプログラム製品が、実行されると、プロセッサに、マルチメディアコンテンツに関するマニフェストファイルを使用して、マルチメディアコンテンツのマルチメディアデータの取出し元になる複数の表現のうちの1つを選択させる命令であって、マニフェストファイルは、マルチメディアコンテンツの複数の表現を示す情報を含み、複数の表現は、表現のうちの選択された1つを含み、表現に関するマルチメディアデータは、複数のソースから入手可能である命令と、選択された表現に関するマルチメディアデータの取出し元になるソースのうちの1つを選択させる命令と、選択された表現に関するマルチメディアデータの少なくとも一部分を選択されたソースから取り出させる命令とを記憶したコンピュータ可読記憶媒体を含む。

1つまたは複数の例の詳細が、以下の添付の図面および説明において述べられる。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかになるであろう。

様々なソースからメディアデータをストリーミングするための技法を実施する、例示的なシステムを示すブロック図である。 様々なソースからメディアデータをストリーミングするための技法を実施する、別の例示的なシステムを示すブロック図である。 マルチソース取出しユニットの構成要素の例示的なセットを示すブロック図である。 例示的なマルチメディアコンテンツの要素を示す概念図である。 マルチメディアコンテンツの表現のセグメントに対応し得る、例示的なビデオファイルの要素を示すブロック図である。 多種多様なソースのうちの1つまたは複数からマルチメディアデータを取り出すための例示的な方法を示すフローチャートである。 様々なソースのうちの1つまたは複数からマルチメディアコンテンツのデータを取り出すための例示的な方法をより詳細に示すフローチャートである。 それぞれのソースに通信可能に結合された様々なインターフェースからソース通知をストリーミングマネージャが受信する概念タイミング図を示すフローチャートである。 本開示の技法に従って1つまたは複数の様々なソースからのストリームを初期化するために適用され得る、動的適応ストリーミングオーバーHTTP(DASH)に従ってストリームを初期化するための例示的な方法を示すフローチャートである。 マルチメディアコンテンツの表現のデータユニット(たとえば、セグメント)に関する情報を取り出すための例示的な方法を示すフローチャートである。 たとえば、レート再選択を実行するための、利用可能なネットワーク帯域幅の変化に適応するための例示的な方法を示すフローチャートである。

一般に、本開示は、オーディオデータおよびビデオデータのようなマルチメディアデータを転送するための技法について説明する。本開示の技法は、動的適応ストリーミングオーバーHTTP(DASH)に関連して使用され得る。本開示は、ネットワークストリーミングに関連して実行され得る様々な技法について説明する。以下でより詳しく説明されるように、ネットワークストリーミングを実行する様々なデバイスは、本開示の技法を実施するように構成され得る。

DASHとマルチメディアデータをストリーミングするための同様の技法とに従って、(テキスト重畳または他のデータも含み得る、動画または他のオーディオ/ビデオコンテンツなどの)マルチメディアコンテンツが、種々の方法で、かつ種々の特性とともに符号化され得る。コンテンツ準備デバイスは、同じマルチメディアコンテンツの複数の表現を形成し得る。各表現は、コーディング特性およびレンダリング特性のような、特性の特定のセットに対応して、様々なコーディング能力およびレンダリング能力を有する種々の異なるクライアントデバイスによって使用可能なデータを提供することができる。その上、様々なビットレートを有する表現は、帯域幅の適応を可能にし得る。すなわち、クライアントデバイスは、現在利用可能な帯域幅の量を判定し、利用可能な帯域幅の量とともにクライアントデバイスのコーディング能力およびレンダリング能力に基づいて、表現を選択することができる。

いくつかの例では、コンテンツ準備デバイスは、表現のセットが共通の特性のセットを有することを示すことができる。コンテンツ準備デバイスは次いで、セット中の表現が帯域幅の適応に使用され得るので、セット中の表現が表現グループを形成することを示すことができる。すなわち、セット中の表現は、ビットレートが異なり得るが、それ以外は、実質的に同じ特性を共有し得る。このようにして、クライアントデバイスは、マルチメディアコンテンツの表現グループに関する共通の特性の様々なセットを判定し、クライアントデバイスのコーディング能力およびレンダリング能力に基づいて、表現グループを選択することができる。次いで、クライアントデバイスは、帯域幅の利用可能性に基づいて、選択された表現グループ中の複数の表現を適応的に切り替えることができる。

本開示の技法によれば、コンテンツ準備デバイスは、HTTPサーバデバイス以外のデバイスにマルチメディアコンテンツに関するデータを提供し得る。たとえば、コンテンツ準備デバイスは、ブロードキャストネットワークサーバデバイス、DVD、ブルーレイディスク、およびフラッシュドライブ、または他のデバイスなどの物理コンピュータ可読記憶媒体を製造するためのデバイスまたはシステムに、マルチメディアコンテンツに関するデータを提供し得る。最終的に、コンテンツ配信ネットワークのルータまたはクライアントデバイスなどの受信デバイスは、本開示の技法を使用して、ソースのうちのいずれかからデータを取り出すことができる。

受信デバイスは、利用可能なソースのうちの1つまたは複数からデータを取り出すことができる。たとえば、受信デバイスは、ソースのうちのどれが特定の表現を提供することが可能であるかを判定し、その表現を最も効率的に提供できるソースを選択することができる。このようにして、様々なタイプの複数のソースは、互いに冗長性をもたらすことができ、それにより、ソースのうちの1つが利用可能でない場合でもなお、受信デバイスは異なるソースからのマルチメディアコンテンツにアクセスすることができる。

代替として、受信デバイスは、たとえば、あるソースから取り出されたデータを別のソースによって取り出されたデータにより増補するために、ほぼ同時にまたは順々に2つ以上のソースからデータを取り出すことができる。たとえば、DVDは、呼び物のプレゼンテーションの表示前に、広告またはプレビューを提示すべきであることを指定し得る。広告またはプレビューのデータをDVD自体に記憶するのではなく、DVDは、HTTPサーバデバイスまたはブロードキャストサーバデバイスなどの外部ソースから広告またはプレビューのデータを取り出すための情報を含むことができる。このようにして、広告またはプレビューは、いつDVDが再生されるかに関係なく、比較的最新の状態に維持され得る。同様の技法を使用して、ブロードキャストネットワーク送信の広告を追加または変更することができる。たとえば、ブロードキャストネットワーク送信を使用して一次マルチメディアコンテンツが転送され得る一方で、HTTPサーバデバイスから広告が取り出され得る。クライアントデバイスは、クライアントデバイスのユーザにターゲットを定めた広告を、たとえば、ユーザに関する人口統計学的情報および/またはユーザのインターネットブラウジング行動に基づいて、人口統計学的情報および/またはインターネットブラウジング行動を外部デバイスと共有することを認める許可をユーザが出したときに、取り出すように命令され得る。

別の例として、DVDは、特定のレーティングを有する表現を含むことができる。レーティングは、特定の視聴者に対するコンテンツ適合性を記述し得る。たとえば、米国では、アメリカ映画協会が、G、PG、PG-13、R、およびNC-17を含むレーティングを定義している。別の例として、英国では、全英映像等級審査機構が、U、PG、12A、12、15、18、およびR18を含むレーティングを定義している。さらに別の例として、中華民国(台湾)では、映画のカテゴリは、一般視聴者カテゴリ、保護対象カテゴリ、親同伴カテゴリ、制限対象カテゴリを含む。いくつかの場合には、DVDのレーティングは、現在の視聴者には適していない、または望ましくないと判定され得る。しかしながら、たとえば、HTTPストリーミングまたはブロードキャストネットワーク送信を使用して取り出されたデータを使用してDVDのコンテンツを変更することで、変更されたコンテンツが現在の視聴者に受け入れられるように、DVDのコンテンツを増補することができる。同様の技法を使用して、ブロードキャストネットワーク送信のマルチメディアコンテンツのレーティングを変更することができる。

さらに別の例として、DVDは、2次元ビデオコンテンツを有する表現を含むことができる。ユーザは、3次元ビデオ再生を希望する場合がある。ユーザは、第2のDVDを購入するのではなく、3次元ビデオを視聴したいという希望を示す場合がある。本開示の技法を使用して、DVD上に含まれるビデオデータのビューとのステレオビューペアを形成し得る第2のビューを取り出し、DVDのデータとほぼ同時に再生して、3次元ビデオ再生を生成することができる。同様の技法を使用して、マルチメディアコンテンツの表現のブロードキャストネットワーク送信のために3次元ビデオを提供することができる。たとえば、ステレオビューペアを形成する第2のビューが、HTTPストリーミングを使用して、または第2のブロードキャストから取り出され得る。

さらに別の例として、データのローカル記憶バージョンが、特定の品質レベルを有し得る。たとえば、データのローカル記憶バージョンは、スケーラブルビデオコーディング(SVC)データのベースレイヤに対応し得る。データを記憶しているクライアントデバイスは、記憶容量が比較的限られているモバイルデバイスを含み得る。したがって、クライアントデバイスは、マルチメディアコンテンツの完全な高品質表現を記憶するのではなく、ベースレイヤのコピーを記憶するだけでよい。ネットワーク接続が利用可能なとき、クライアントデバイスは、ベースレイヤに対応する1つまたは複数のエンハンスメントレイヤを要求することができる。一方、ネットワーク接続が利用可能でないとき、クライアントデバイスは、ベースレイヤに対応するデータを表示するだけでよい。

さらなる例として、ブロードキャストサーバデバイスは、表現において特定の頻度を有するランダムアクセスポイント(RAP)を有するマルチメディアコンテンツの表現に関するデータをブロードキャストすることができる。しかしながら、クライアントデバイスは、ブロードキャストされている表現のデータを直ちに取り出すのではなく、最初に、HTTP要求を使用してサーバデバイスから、マルチメディアコンテンツの異なる表現であって、比較的高い頻度のRAPを有し得る異なる表現のデータを取り出し始めることができる。クライアントデバイスは、異なる表現から十分な量のデータをバッファリングした後、ブロードキャストサーバデバイスによってブロードキャストされている表現に切り替えることができる。

その上、本開示の技法を使用して、マルチメディアコンテンツの他の要素も増補することができる。たとえば、クライアントデバイスは、たとえば、ブロードキャストネットワーク送信またはDVDからビデオデータを取り出し、復号し、表示するように構成され得る。クライアントデバイスはオーディオデータを、たとえば、クライアントデバイスのユーザが希望する言語によるオーディオデータがブロードキャストネットワーク送信に含まれていないときに、異なるソースから取り出すことができる。別の例として、クライアントデバイスは、クローズドキャプションなどのテキスト重畳を、たとえば、クローズドキャプションテキストがブロードキャストネットワーク送信の表現データで提供されないとき、または希望言語のクローズドキャプションテキストがブロードキャストネットワーク送信内で利用可能でないときに、異なるソースから取り出すように構成され得る。

メディアコンテンツの表現のセグメントのようなビデオファイルは、ISOベースメディアファイルフォーマット、Scalable Video Coding(SVC)ファイルフォーマット、Advanced Video Coding(AVC)ファイルフォーマット、Third Generation Partnership Project(3GPP)ファイルフォーマット、および/またはMultiview Video Coding(MVC)ファイルフォーマット、または他の同様のビデオファイルフォーマットのうちのいずれかに従ってカプセル化されたビデオデータに、準拠し得る。

ISOベースメディアファイルフォーマットは、メディアの交換、管理、編集、および提示を支援するフレキシブルで拡張可能なフォーマットで提示するための、時限のメディア情報を格納するように設計される。ISOベースメディアファイルフォーマット(ISO/IEC14496-12:2004)は、時間に基づくメディアファイルのための一般的な構造を定義する、MPEG-4 Part-12で規定される。ISOベースメディアファイルフォーマットは、H.264/MPEG-4AVCビデオ圧縮のサポートを定義されるAVCファイルフォーマット(ISO/IEC14496-15)、3GPPファイルフォーマット、SVCファイルフォーマット、およびMVCファイルフォーマットのようなファミリ中の、他のファイルフォーマットの基礎として使用される。3GPPファイルフォーマットおよびMVCファイルフォーマットは、AVCファイルフォーマットの拡張である。ISOベースメディアファイルフォーマットは、オーディオビジュアルプレゼンテーションのような、メディアデータの時限のシーケンスの、タイミング、構造、およびメディア情報を含む。ファイル構造は、オブジェクト指向であってよい。ファイルは、非常に簡単に基本的なオブジェクトに分解することができ、オブジェクトの構造はオブジェクトのタイプから示唆される。

ISOベースメディアファイルフォーマット(およびその拡張)に準拠するファイルは、「ボックス」と呼ばれる一連のオブジェクトとして形成され得る。ISOベースメディアファイルフォーマットにおけるデータがボックスに格納され得るので、ファイル内に他のデータが格納される必要はなく、ファイル内のボックスの外側にデータがある必要はない。これは、特定のファイルフォーマットによって要求される任意の最初の特徴を含む。「ボックス」は、一意のタイプの識別子および長さによって定義されたオブジェクト指向のビルディングブロックであり得る。通常は、1つのプレゼンテーションが1つのファイルに格納され、メディアプレゼンテーションは自己完結型である。動画コンテナ(動画ボックス)は、メディアのメタデータを格納することができ、ビデオおよびオーディオフレームは、メディアデータコンテナに格納されてよく、他のファイル中にあってもよい。

表現(運動シーケンス)は、セグメントと呼ばれることがあるいくつかのファイルに格納され得る。タイミング情報およびフレーミング(位置およびサイズの)情報は一般に、ISOベースメディアファイル中にあり、補助ファイルは基本的にあらゆるフォーマットを使用することができる。このプレゼンテーションは、プレゼンテーションを格納するシステムに対して「ローカル」であってよく、またはネットワークもしくは他のストリーム配信機構を介して提供されてよい。

随意のメタデータトラックを使用して、各トラックが有する「興味深い特性」のタグを各トラックにつけることができ、興味深い特性に関する各トラックの値(たとえば、各トラックのビットレート、画面サイズ、または言語)は、グループの他のメンバーとは異なり得る。トラック内のいくつかのサンプルは、特別な特性を有し得るか、または個々に識別され得る。その特性の一例は、同期ポイントである(ビデオIフレームであることが多い)。これらのポイントは、各トラックにおける特別なテーブルによって識別され得る。より一般的には、トラックサンプル間の依存性も、メタデータを使用して文書化され得る。メタデータは、ビデオトラックのように一連のファイルフォーマットサンプルとして構造化され得る。そのようなトラックは、メタデータトラックと呼ばれることがある。各メタデータサンプルは、メタデータステートメントとして構造化され得る。対応するファイルフォーマットサンプルまたはその構成要素であるサンプルについて尋ねられる可能性のある様々な質問に対応する様々な種類のステートメントがある。

メディアがストリーミングプロトコルを通じて配信されるとき、メディアをファイル内での表現方法から変更する必要があり得る。このことの一例は、メディアがリアルタイムトランスポートプロトコル(RTP)を通じて送信される場合である。ファイルにおいて、たとえば、各ビデオフレームは、ファイルフォーマットサンプルとして連続して記憶される。RTPにおいて、これらのフレームをRTPパケットに配置するには、使用されるコーデックに固有のパケット化ルールに従わなければならない。実行時にそのようなパケット化を計算するように、ストリーミングサーバが構成され得る。ただし、ストリーミングサーバの支援のためのサポートがある。

本開示の技法は、たとえば、動的適応ストリーミングオーバーHTTP(DASH)による、HTTPストリーミングなどのネットワークストリーミングプロトコルに適用可能であり得る。HTTPストリーミングにおいて、頻繁に使用される動作には、GETおよび部分GETがある。GET動作は、所与のユニフォームリソースロケータ(URL)または他の識別子、たとえばURIに関連付けられるファイル全体を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルのうちの、受信されたバイト範囲に対応する連続した数のバイトを取り出す。したがって、部分GET動作は、1つまたは複数の個々の動画フラグメントを取得できるので、動画フラグメントはHTTPストリーミングのために提供され得る。動画フラグメントにおいて、異なるトラックのいくつかのトラックフラグメントが存在し得ることに留意されたい。HTTPストリーミングでは、メディア表現は、クライアントにとってアクセス可能なデータの構造化された集合体であり得る。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示することができる。

HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオデータおよび/またはオーディオデータに関して複数の表現が存在し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD)データ構造において定義され得る。メディア表現は、HTTPストリーミングクライアントデバイスにとってアクセス可能なデータの構造化された集合体に相当し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。メディア表現は、MPDの更新を含み得るMPDデータ構造で記述され得る。

マルチメディアコンテンツは、1つまたは複数の期間のシーケンスを格納し得る。期間は、MPDにおいてPeriod要素によって画定され得る。各期間は、MPDにおいて属性startを有し得る。MPDは、期間ごとにstart属性およびavailableStartTime属性を含み得る。ライブサービスの場合、期間のstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによる期間の利用可能時間、特に、対応する期間における各表現の第1のメディアセグメントを指定し得る。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間では、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。期間開始時間は、正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。

各期間は、同じメディアコンテンツのための1つまたは複数の表現を格納し得る。表現は、オーディオデータまたはビデオデータの、多数の符号化バージョンの選択肢の1つであり得る。表現は、符号化のタイプなどの様々な特性によって、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツのある特定の期間に対応し、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指すために使用され得る。

特定の期間の表現が、MPDにおいてgroup属性によって示され得るグループに割り当てられ得る。同じグループ中の表現は一般に、互いに代替物であると考えられる。たとえば、ある特定の期間のビデオデータの各表現は、同じグループに割り当てられ得るので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツのビデオデータを表示するための復号のために、選択され得る。いくつかの例では、1つの期間内のメディアコンテンツは、存在する場合にはグループ0からの1つの表現、または各々の非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表され得る。ある期間の各表現のタイミングデータは、期間の開始時間に対して表され得る。

表現は、1つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含んでよく、または表現の各セグメントは、自己初期化するものであってよい。初期化セグメントは、存在する場合、表現にアクセスするための初期化情報を格納し得る。一般に、初期化セグメントは、メディアデータを格納しない。セグメントは、ユニフォームリソースロケータ(URL)などの識別子によって一意に参照され得る。MPDは、セグメントごとに識別子を提供することができる。いくつかの例では、MPDはまた、URLまたはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。

各表現はまた、1つまたは複数のメディア構成要素を含んでよく、各メディア構成要素は、オーディオ、ビデオ、および/または時限のテキスト(たとえば、クローズドキャプションのための)のような、1つの個々のメディアタイプの符号化バーションに相当し得る。メディア構成要素は、1つの表現内の連続的なメディアセグメントの境界にわたって、時間的に連続的であり得る。

図1は、様々な異なるソースからメディアデータをストリーミングするための技法を実施する、例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20、サーバデバイス60、ブロードキャストサーバデバイス62、物理媒体製造施設64、ネットワーク14、およびクライアントデバイス40Aを含む。クライアントデバイス40Aおよびサーバデバイス60は、インターネットを含み得るネットワーク14によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20、サーバデバイス60、ブロードキャストサーバデバイス62、および物理媒体製造施設64も、ネットワーク14もしくは別のネットワークによって結合されてよく、または直接通信可能に結合されてよい。いくつかの例では、コンテンツ準備デバイス20、サーバデバイス60、ブロードキャストサーバデバイス62、および物理媒体製造施設64のいずれかまたはすべては、同じデバイスまたは施設を含み得る。その上、コンテンツ準備デバイス20は必ずしも、すべての例においてサーバデバイス60、ブロードキャストサーバデバイス62、および/または物理媒体製造施設64に通信可能に結合されるとは限らないが、サーバデバイス60、ブロードキャストサーバデバイス62、および/または物理媒体製造施設64のいずれかまたはすべてによって読み取られる別個の媒体に、マルチメディアコンテンツを記憶することができる。

図1の例では、コンテンツ準備デバイス20は、オーディオソース22およびビデオソース24を含む。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成する、マイクロフォンを含み得る。あるいは、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを含み得る。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを含み得る。

生のオーディオデータおよびビデオデータは、アナログデータまたはデジタルデータを含み得る。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化され得る。オーディオソース22は、話している参加者から、その参加者が話している間オーディオデータを取得することができ、ビデオソース24は、話している参加者のビデオデータを同時に取得することができる。他の例では、オーディオソース22は、記憶されたオーディオデータを含むコンピュータ可読記憶媒体を含んでよく、ビデオソース24は、記憶されたビデオデータを含むコンピュータ可読記憶媒体を含み得る。このようにして、本開示で説明される技法は、生の、ストリーミングの、リアルタイムのオーディオデータおよびビデオデータに、または、保管された、以前に記録されたオーディオデータおよびビデオデータに、適用され得る。

ビデオフレームに対応するオーディオフレームは一般に、ビデオフレーム内に格納されたビデオソース24によってキャプチャされたビデオデータと同じときに、オーディオソース22によってキャプチャされたオーディオデータを格納する、オーディオフレームである。たとえば、話している参加者が一般に話すことによってオーディオデータを生成している間、オーディオソース22はオーディオデータをキャプチャし、ビデオソース24は同時に、すなわちオーディオソース22がオーディオデータをキャプチャしている間に、話している参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応し得る。したがって、ビデオフレームに対応するオーディオフレームは一般に、オーディオデータおよびビデオデータが同時にキャプチャされた状況に対応し、その状況に対して、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを含む。

いくつかの例では、オーディオエンコーダ26は、各符号化オーディオフレームにおいて、符号化オーディオフレームのオーディオデータが記録された時間を表すタイムスタンプを符号化することができ、同様に、ビデオエンコーダ28は、各符号化ビデオフレームにおいて、符号化ビデオフレームのビデオデータが記録された時間を表すタイムスタンプを符号化することができる。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを含むオーディオフレームおよび同じタイムスタンプを含むビデオフレームを含み得る。コンテンツ準備デバイス20は、オーディオエンコーダ26および/またはビデオエンコーダ28がタイムスタンプを生成する場合に依拠するか、またはオーディオソース22およびビデオソース24がそれぞれオーディオデータおよびビデオデータをタイムスタンプに関連付けるために使用し得る、内部クロックを含むことができる。

いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ26に送ることができ、ビデオソース24は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ28に送ることができる。いくつかの例では、オーディオエンコーダ26は、符号化オーディオデータにおいて、符号化オーディオデータの相対時間的順序を示すが、オーディオデータが記録された絶対時間を必ずしも示すとは限らないシーケンス識別子を符号化することができ、同様に、ビデオエンコーダ28も、符号化ビデオデータの相対時間的順序を示すシーケンス識別子を使用することができる。同様に、いくつかの例では、シーケンス識別子がタイムスタンプにマップされるか、あるいはタイムスタンプと相関することがある。

オーディオエンコーダ26は一般に、符号化オーディオデータのストリームを生成する一方、ビデオエンコーダ28は、符号化ビデオデータのストリームを生成する。データの個別の各ストリーム(オーディオかビデオかにかかわらず)は、エレメンタリストリームと呼ばれ得る。エレメンタリストリームは、表現の、単一のデジタル的にコード化された(場合によっては圧縮された)構成要素である。たとえば、表現のコード化されたビデオまたはオーディオの部分は、エレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム(PES:packetized elementary stream)に変換され得る。同じ表現内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。したがって、コード化ビデオデータは一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。

図1の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からのコード化ビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からのコード化オーディオデータを含むエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのパケタイザを含み得る。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのそれぞれのパケタイザとインターフェースをとり得る。さらに他の例では、カプセル化ユニット30は、符号化オーディオデータおよび符号化ビデオデータからPESパケットを形成するためのパケタイザを含み得る。

ビデオエンコーダ28は、種々の方法でマルチメディアコンテンツのビデオデータを符号化して、ピクセル解像度、フレームレート、様々なコーディング規格に対する準拠、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルに対する準拠、1つもしくは複数の表示を有する表現(たとえば、2次元または3次元の再生用)、または他のそのような特性のような、様々な特性を有する様々なビットレートのマルチメディアコンテンツの様々な表現を生成することができる。本開示で使用されるような表現は、オーディオデータとビデオデータとの組合せ、たとえば、1つまたは複数のオーディオエレメンタリストリームと1つまたは複数のビデオエレメンタリストリームとを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを特定する、stream_idを含み得る。カプセル化ユニット30は、様々な表現のビデオファイルへとエレメンタリストリームを組み立てる役割を担う。

カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28からの表現のエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化層(NAL)ユニットを形成する。H.264/AVC(Advanced Video Coding)の例では、コード化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用(addressing application)を実現する。NALユニットは、ビデオ符号化層(VCL)NALユニットおよび非VCL NALユニットと分類され得る。VCLユニットは、コア圧縮エンジンを格納してよく、ブロック、マクロブロックおよび/またはスライスレベルのデータを含んでよい。他のNALユニットは、非VCL NALユニットであり得る。いくつかの例では、1つの時間インスタンスにおけるコード化ピクチャは、通常は一次コード化ピクチャとして提示され、1つまたは複数のNALユニットを含み得るアクセスユニットに格納され得る。

非VCL NALユニットは特に、パラメータセットのNALユニットおよびSEI NALユニットを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)中に)シーケンスレベルヘッダ情報を含み、(ピクチャパラメータセット(PPS)中に)頻繁には変化しないピクチャレベルヘッダ情報を含み得る。パラメータセット(たとえば、PPSおよびSPS)があれば、この頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要がなく、したがってコーディング効率が向上し得る。さらに、パラメータセットの使用が、重要なヘッダ情報の帯域外送信を可能にでき、エラーの復元のための冗長な送信の必要がなくなる。帯域外送信の例では、パラメータセットのNALユニットが、SEI NALユニットなどの他のNALユニットとは異なるチャネルで送信され得る。

補足エンハンスメント情報(SEI)は、VCL NALユニットからコード化ピクチャサンプルを復号するために必要ではない情報を含み得るが、復号、表示、エラーの復元、および他の目的に関係するプロセスを支援し得る。SEIメッセージは、非VCL NALユニットに含まれ得る。SEIメッセージは、いくつかの標準仕様の規範的部分(normative part)であり、したがって、規格に準拠するデコーダの実装において常に必須であるわけではない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。いくつかのシーケンスレベル情報は、SVCの例におけるスケーラビリティ情報SEIメッセージおよびMVCにおける表示スケーラビリティ情報SEIメッセージなどのSEIメッセージに含まれ得る。これらの例示的なSEIメッセージは、たとえば動作点の抽出および動作点の特性に関する情報を伝達することができる。さらに、カプセル化ユニット30は、表現の特性を記述するメディアプレゼンテーション記述子(MPD)などのマニフェストファイルを形成することができる。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットすることができる。

カプセル化ユニット30は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数の表現のためのデータを、出力インターフェース32に提供することができる。出力インターフェース32は、ユニバーサルシリアルバス(USB)インターフェースのような記憶媒体へ書き込むためのネットワークインターフェースもしくはインターフェース、CDもしくはDVDのライターもしくはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを含み得る。カプセル化ユニット30は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース32に提供することができ、出力インターフェース32は、ネットワーク送信または記憶媒体を介してデータをサーバデバイス60、ブロードキャストサーバデバイス62、および/または物理媒体製造施設64に送ることができる。

MPDは、たとえば、追加または代替のマルチメディアデータに関するMPD更新、MPD拡張、または外部期間の外部ロケーション、たとえば、サーバデバイス60によってホストされるネットワークロケーションを指し得る。たとえば、物理媒体製造施設64によって製造された物理媒体上に記憶され、ブロードキャストサーバデバイス62によって送信され、サーバデバイス60によって提供され、または別のソースによって提供されたマルチメディアデータは、一次マルチメディアデータに対応し得る。外部期間は、一次マルチメディアデータを改良、変更、置換、あるいは増補するために使用され得る代替ソースのデータに対応し得る。以下でより詳細に説明するように、外部期間は、広告マルチメディアデータまたは他の追加のマルチメディアデータ、たとえば記憶されたマルチメディアデータのレーティングを適応させるための、または他の代替コンテンツ(たとえば、代替エンディングもしくはディレクターズカット)を提供するための交換マルチメディアデータを含み得る。

外部期間は追加または代替として、一次マルチメディアデータに対する拡張または改良を提供し得る。たとえば、スケーラブルビデオコーディング(SVC)の文脈では、一次マルチメディアデータは、SVCのベースレイヤに対応することができ、外部期間は、ベースレイヤに対応するエンハンスメントレイヤに関するデータを含むことができる。別の例として、マルチビュービデオコーディング(MVC)の文脈では、一次マルチメディアデータは、1つまたは複数のビューを含むことができ、外部期間は、1つまたは複数の追加ビューに関するデータを含むことができる。代替として、一次マルチメディアデータは、少なくとも1つのビューに関するデータを含むことができ、外部期間は、一次マルチメディアデータのビューに対応する深度マップに関するデータを含むことができる。

このようにして、コンテンツ準備デバイス20は、DASHに準拠するマルチメディアコンテンツを準備し、マルチメディアコンテンツの表現に関するデータを、データを転送あるいは出力することができるソースの中でも、サーバデバイス60、ブロードキャストサーバデバイス62、および物理媒体製造施設64に提供することができる。したがって、以下でより詳細に説明するように、HTTPサーバ(たとえば、サーバデバイス60)以外のソースによって出力されるデータはDASHに準拠することができる。DASHの技法は一般に、HTTPを実装しているデバイスによって実行されるが、本開示は、クライアントデバイス40AなどのクライアントデバイスがDASHに準拠するマルチメディアデータを取り出す場合に取出し元になる、HTTPサーバ以外のソースを提供するための技法を提供する。

図1の例では、サーバデバイス60は、クライアントデバイス40AなどのクライアントデバイスからHTTP Get要求および部分Get要求を受信し、要求されたデータを要求側クライアントデバイスに提供するために、HTTP/1.1を実装することができる。このようにして、サーバデバイス60は、クライアントデバイス40Aなどの1つまたは複数のクライアントデバイスにユニキャストサービスを提供することができる。サーバデバイス60からデータを取り出すために、クライアントデバイス40Aはサーバデバイス60にHTTP Get要求または部分Get要求を出すことができる。インターフェース54は、サーバデバイス60と通信するためのHTTPスタックを実装しているネットワークインターフェースカード(NIC)を含み得る。インターフェース54のNICは、ワイヤードNIC、1つもしくは複数のIEEE 802.11プロトコルなどのワイヤレスプロトコルを実装しているワイヤレスNIC、および/またはセルラーパケット無線インターフェースを含み得る。

ブロードキャストサーバデバイス62は、メディアデータをブロードキャストするために、クライアントデバイス40Aなどの1つまたは複数のクライアントデバイスにパケットを送ることができる。たとえば、ブロードキャストサーバデバイス62は、ブロードキャストまたはマルチキャストのいずれかを使用して、クライアントデバイス40Aなどの1つまたは複数のクライアントデバイスにマルチメディアデータを配信するための発展型マルチメディアブロードキャストマルチキャストサービス(eMBMS:Evolved Multimedia Broadcast Multicast Service)を実装することができる。このようにして、クライアントデバイス40Aは、eMBMSを使用してDASHに準拠するマルチメディアデータを受信することができる。代替として、ブロードキャストサーバデバイス62は、クライアントデバイス40Aなどの1つまたは複数のクライアントデバイスにマルチメディアデータを送るためにインターネットプロトコル(IP)マルチキャストを実装することができる。このようにして、ブロードキャストサーバデバイス62は、DASHに準拠するマルチメディアデータが取り出される場合に取出し元になる、HTTPサーバ以外のソースの一例を表している。ブロードキャストサーバデバイス62からマルチキャストデータを取り出すために、クライアントデバイス40Aは、マルチキャストに関連するマルチキャストグループアドレスを判定し、たとえばインターネットグループ管理プロトコル(IGMP:Internet Group Management Protocol)に従ってIPマルチキャストグループアドレスに参加することができる。インターフェース54は、eMBMSを実装するネットワークインターフェースカード(NIC)、および/またはブロードキャストサーバデバイス62に関連するIPマルチキャストグループに参加するためにIPスタックを実装するNICを含むことができる。

物理媒体製造施設64は、DVD、ブルーレイディスク、フラッシュドライブなどの物理媒体、またはマルチメディアデータを記憶するための他の物理媒体を製造することができる。記憶媒体は、発送され、最終的にクライアントデバイス40Aの物理的ロケーションに到着し得る。上記で説明したように、物理媒体製造施設64が物理媒体に記憶するマルチメディアデータは、DASHに従ってフォーマットされ得る。たとえば、物理媒体は、メディアプレゼンテーション記述(MPD)または他のマニフェストファイルを含み得る。このようにして、物理媒体製造施設64によって製造される物理媒体は、DASHに準拠するマルチメディアデータが取り出される場合に取出し元になる、HTTPサーバ以外のソースの一例を表している。クライアントデバイス40Aのユーザは、たとえば、対応する光学式読取り装置にディスクを挿入すること、またはユニバーサルシリアルバス(USB)ポートにフラッシュドライブを接続することによって、クライアントデバイス40Aに物理媒体を結合することができ、光学式読取り装置およびUSBポートの一方または両方は、クライアントデバイス40Aのインターフェース54内に含まれ得る。

図1の例では、クライアントデバイス40Aは、マルチソース取出しユニット50Aおよびインターフェース54を含む。上記で説明したように、インターフェース54は、サーバデバイス60、ブロードキャストサーバデバイス62、物理媒体製造施設64によって製造された物理記憶媒体、または他のソースのいずれかまたはすべてから、マルチメディアデータを取り出すように構成され得る。たとえば、インターフェース54は追加または代替として、オーバージエアテレビジョン放送信号を受信するためのチューナーカードを含むことができる。

マルチソース取出しユニット50Aは一般に、マルチメディアデータの取出し元になる1つまたは複数のソースを判定するように、またマルチメディアコンテンツの1つまたは複数の表現を選択するように構成され得る。たとえば、マルチソース取出しユニット50Aは、クライアントデバイス40Aの構成データ(図示せず)を取り出して、ビデオデコーダ48の復号能力およびビデオ出力44のレンダリング能力を判定することができる。構成データはまた、クライアントデバイス40Aのユーザによって選択される言語の選好、クライアントデバイス40Aのユーザによって設定される深さの選好に対応する1つもしくは複数のカメラ視野、および/または、クライアントデバイス40Aのユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。マルチソース取出しユニット50Aは、クライアントデバイス40Aの1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行される、ソフトウェア命令に対応し得る。いくつかの例では、マルチソース取出しユニット50Aに関して説明された機能のすべてまたは一部は、ハードウェア、ハードウェアの組合せ、ソフトウェア、および/またはファームウェアで実装されてよく、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。

マルチソース取出しユニット50Aは、クライアントデバイス40Aの復号能力およびレンダリング能力を、マルチメディアコンテンツに関する(メディアプレゼンテーション記述(MPD)ファイルなどの)マニフェストファイルの情報によって示されるマルチメディアコンテンツの表現の特性と比較することができる。マルチソース取出しユニット50Aは最初にマニフェストファイルを取り出して、マルチメディアコンテンツの表現の特性を判定することができる。たとえば、マルチソース取出しユニット50Aは、1つまたは複数の適応セットの特性を記述し得るマニフェストファイルを要求することができる。マニフェストファイルはさらに、マルチメディアコンテンツに関するデータが入手可能であるソースを記述し得る。代替として、別個のデータ構造が、マルチメディアコンテンツに関するデータが入手可能であるソースの指示を提供し得る。

マルチソース取出しユニット50Aは、クライアントデバイス40Aのコーディング能力およびレンダリング能力によって満たされ得る特性を有する、マルチメディアコンテンツの表現のサブセット(たとえば、適応セット)を選択することができる。マルチソース取出しユニット50Aは次いで、適応セット中の表現に対するビットレートを判定し、HTTPストリーミングを使用してデータを取り出すためにネットワーク帯域幅の現在利用可能な量を判定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの1つからセグメントを取り出すことができる。代替として、マルチソース取出しユニット50Aは、ブロードキャストサーバデバイス62またはローカルストレージ、たとえば、物理媒体製造施設64によって製造されたフラッシュドライブ、DVDもしくはブルーレイディスクからマルチメディアコンテンツに関するデータを取り出すかどうかを判定することができる。

マルチソース取出しユニット50Aはインターフェース54と通信して、サーバデバイス60およびブロードキャストサーバデバイス62などのいくつかのソースとの通信が利用可能であるかどうかを判定することができる。同様に、マルチソース取出しユニット50Aは、特定の表現が入手可能であるソースを判定するように構成され得る。本開示の技法によれば、マルチソース取出しユニット50Aは、1つまたは複数のソースからマルチメディアコンテンツの1つまたは複数の表現からのデータを取り出すように構成可能であり、この場合にソースは、異なる方法で、たとえば互いに異なる技法または異なるプロトコルを使用して、クライアントデバイス40Aにデータを提供することができる。

マルチソース取出しユニット50Aはさらに、これらの技法を使用して、ネットワーク帯域幅の変動する利用可能性に応答して、ネットワーク14を介したデータの取出しを適応させることができる。一般に、表現のビットレートが高くなると、ビデオ再生の品質が高くなる一方、表現のビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、ビデオ再生の品質が十分なものになり得る。したがって、利用可能なネットワーク帯域幅が比較的高いときには、マルチソース取出しユニット50Aは、ビットレートが比較的高い表現からデータを取り出すことができ、利用可能なネットワーク帯域幅が低いときには、マルチソース取出しユニット50Aは、ビットレートが比較的低い表現からデータを取り出すことができる。その上、本開示の技法によれば、マルチソース取出しユニット50Aは、様々なソースからのマルチメディアコンテンツに関するデータの取出しの間で、たとえば、サーバデバイス60とブロードキャストサーバデバイス62との間で、ネットワーク14の帯域幅の利用可能性に基づいて、適応的に切り替えることができる。このようにして、クライアントデバイス40Aは、ネットワーク14を通じてマルチメディアデータをストリーミングすることができる一方、ネットワーク14の変化するネットワーク帯域幅の利用可能性に適応することもできる。

いくつかの例では、マルチソース取出しユニット50Aは、マルチメディアコンテンツに関するMPDファイルなど、マニフェストファイルの一部分を更新すべきかどうかを判定することができる。マルチソース取出しユニット50Aは、セグメントのヘッダ部分または他の最初の部分など、各セグメントの特定の部分を分析して、マニフェストファイルを更新すべきであることをセグメントが示しているかどうかを判定するように構成され得る。マニフェストファイルを更新すべきであるとき、マルチソース取出しユニット50Aは、セグメントのデータを使用して、またはリモートロケーションから、たとえばサーバ60からマニフェストファイルを更新するためのデータを取り出すことによって、マニフェストファイルのローカルに記憶されたコピーを更新することができる。マニフェストファイルを更新した後、マルチソース取出しユニット50Aは、更新されたマニフェストファイルのデータに基づいて、表現のデータに関する将来の要求を提出することができる。

一例として、コンテンツ準備デバイス20は、生のスポーツイベント、政治イベント、またはあらかじめ記録されるのではなく、一般に生またはほぼ生でブロードキャストされる他の注目すべきイベントなどの生のメディアデータを符号化することができる。そのような場合、特定の時間までのメディアデータに対応するセグメントは、最初のマニフェストファイルに含まれるURLなどの識別子を割り当てられ得る。ただし、時間が経過した後、特定の時間に続くセグメントが符号化され、URLなどの識別子を割り当てられ得る。コンテンツ準備デバイス20のカプセル化ユニット30は、更新されたマニフェストファイルに、特定の時間に続くセグメントに関するURLを提供することができる。したがって、特定の時間に続くセグメントの取出し方を判定するにあたり、クライアントデバイス40Aは、特定の時間に続くセグメントを取り出すことを求める要求を作成するために、更新されたマニフェストファイルを示す情報を受信することができる。同様に、コンテンツ準備デバイス20は、マルチメディアコンテンツに関するデータが他のソース、たとえばブロードキャストサーバデバイス62から入手可能であることを示すデータを提供することができる。

インターフェース54は、選択された表現のセグメントのデータを受信し、マルチソース取出しユニット50Aに提供することができる。マルチソース取出しユニット50Aは、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送信するカプセル化解除を含むことができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号されたオーディオデータをオーディオ出力42に送信し、一方でビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号されたビデオデータを、ビデオ出力44に送信する。ビデオデコーダ48、オーディオデコーダ46、オーディオ出力42およびビデオ出力44は、まとめてマルチメディアフレームワークと呼ぶことができ、一般に、オーディオデータおよびビデオデータのマルチメディア復号およびレンダリングを実施する役割を担い得る。

ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、およびマルチソース取出しユニット50Aは各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組合せのような、種々の適切な処理回路のいずれかとして、適宜実装され得る。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたコーデックの一部として統合され得る。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、および/またはマルチソース取出しユニット50Aを含む装置は、集積回路、マイクロプロセッサ、および/または携帯電話のようなワイヤレス通信デバイスを含み得る。

図2は、様々な異なるソースからメディアデータをストリーミングするための技法を実施する、別の例示的なシステム12を示すブロック図である。この例では、システム12は、図1の同じ番号の要素にほぼ合致するコンテンツ準備デバイス20、サーバデバイス60、ブロードキャストサーバデバイス62、および物理媒体製造施設64を含む。システム12はまた、クライアントデバイス40Bおよび取出しデバイス70を含む。

クライアントデバイス40Bがインターフェース58および逆多重化ユニット56を含むことを除いて、クライアントデバイス40Bは、図1のクライアントデバイス40Aにほぼ合致する。クライアントデバイス40Bは、マルチソース取出しユニットを含むのではなく、1つまたは複数の様々なソースからマルチメディアデータを取り出すように構成された取出しデバイス70と対話する。図2の例では、取出しデバイス70は、図1のマルチソース取出しユニット50Aにほぼ合致するマルチソース取出しユニット50Bを含む。取出しデバイス70はまた、図1のインターフェース54にほぼ合致するインターフェース72を含む。

この例では、取出しデバイス70は、図1のクライアントデバイス40Aに関して説明した方法と同様の方法でマルチメディアデータを取り出す。ただし、図2の例では、取出しユニット70は、取り出された符号化マルチメディアデータを、逆多重化する前にクライアントデバイス40Bに提供する。取出しデバイス70は、たとえば、コンテンツ配信ネットワークのルーティングデバイスを含み得る。クライアントデバイス40Bのインターフェース58は、取出しデバイス70から符号化マルチメディアデータを受信し、そのデータを逆多重化ユニット56に渡すことができる。代替として、マルチソース取出しユニット50Bは、データを逆多重化し、符号化マルチメディアデータ(たとえば、オーディオデータおよびビデオデータ)の個々のストリームを、インターフェース58を介してクライアントデバイス40Bに渡すことができ、この場合にインターフェース58は、オーディオデコーダ46およびビデオデコーダ48にデータを直接提供することができる。

図3は、マルチソース取出しユニット50の構成要素の例示的なセットを示すブロック図である。図3のマルチソース取出しユニット50は、マルチソース取出しユニット50A(図1)もしくはマルチソース取出しユニット50B(図2)に対応するか、または別の異なる取出しデバイスに含まれ得る。この例では、マルチソース取出しユニット50は、ストリーム管理ユニット80およびソース構成要素90を含む。ストリーム管理ユニット80は、取出し制御ユニット82およびソースインターフェース84を含み、一方でソース構成要素90は、メディアファイル記憶処理ユニット92、MPDパーシングユニット94、メディアファイル逆多重化(DEMUX)ユニット96およびソースインターフェース98を含む。

図3の例では、ソースインターフェース84およびソースインターフェース98は、HTTP受信機/スタック74、ブロードキャスト受信機/スタック76、およびローカルストレージ78を含むインターフェース73と通信する。インターフェース73は一般に、インターフェース54(図1)またはインターフェース72(図2)に対応し得る。省略記号によって示されるように、インターフェース73は、サーバデバイス60、ブロードキャストサーバデバイス62、および物理媒体製造施設64によって製造される物理媒体に対する追加または代替としての他のソースからマルチメディアデータを取り出すための追加インターフェースを含み得る。

インターフェース73の各々は、特定の通信プロトコルを使用して通信するか、または特定の物理媒体と対話するためのハードウェアおよび/またはソフトウェアを含むことができる。たとえば、HTTP受信機/スタック74は、HTTPを実装し、HTTPスタックを使用してデータを受信することができ、このHTTPスタックは、TCP/IPならびにネットワークの他の層に関する他の通信プロトコルを含み得る。HTTP受信機/スタック74は、たとえばサーバデバイス60に対しセグメント(またはセグメントの部分)を求めるHTTP Get要求または部分Get要求をさらに生成することができる。ブロードキャスト受信機/スタック76は、ブロードキャストまたはマルチキャストネットワーク送信からデータを受信するために、ブロードキャストまたはマルチキャストプロトコル、たとえばeMBMSまたはIPマルチキャストを実装することができる。ブロードキャスト受信機/スタック76は、送信のデータを取り出すために、ブロードキャストまたはマルチキャストネットワーク送信に加入するように構成され得る。ローカルストレージ78は、メモリ、ソリッドステートもしくはフラッシュドライブ、DVD、ブルーレイディスク、またはたとえばクライアントデバイス40A(図1)もしくは取出しデバイス70(図2)の他の物理媒体上のローカルに記憶されたデータへのインターフェースに対応し得る。

ソース構成要素90は、ソースインターフェース98を介して1つまたは複数のソースからマルチメディアコンテンツのデータを受信することができ、この場合、ソースインターフェース98は、インターフェース73のうちの1つまたは複数からデータを受信することができる。最初に、ソース構成要素90は、MPDファイルなどのマニフェストファイルを受信することができる。MPDパーシングユニット94は、MPDファイルをパースして、マルチメディアコンテンツの利用可能な表現、ならびに共通の特性を備える表現のグループを含む適応セットおよび表現の特性を判定することができる。時々、ソース構成要素90は、現在のマルチメディアコンテンツに関する更新されたMPDを受信することがあり、この場合、MPDパーシングユニット94は、更新されたMPDをパースし、更新された情報をストリーム管理ユニット80に提供することができる。いくつかの例では、ソース構成要素90は、表現のうちの少なくとも1つを選択することができる一方、他の例では、ソース構成要素90は表現情報をストリーム管理ユニット80に提供することができる。そのような例では、ストリーム管理ユニット80は、表現のうちの少なくとも1つを選択することができる。いずれの場合も、ソース構成要素90はストリーム管理ユニット80に、マルチメディアコンテンツに関するデータを取り出すためのダウンロード情報を送るよう求める要求を送ることができる。

ストリーム管理ユニット80は、選択された表現のデータの取出し元になるソース73のうちの1つを選択するように構成され得る。インターフェース73の各々は、ストリーム管理ユニット80がデータの取出し元になる特定のソースを選択するように、ストリーム管理ユニット80にソース通知を提供することができる。たとえば、HTTP受信機/スタック74は、HTTP送信のためにストリーム管理ユニット80に利用可能なネットワーク帯域幅の推定量を提供し得る。ブロードキャスト受信機/スタック76は、選択された表現に対応するブロードキャスト送信のためのURLが利用可能であるかどうか、またブロードキャストがカバレージ内にあるかどうかの指示を提供することができる。ローカルストレージ78は、選択された表現に対応するローカルに記憶されたデータにURLが利用可能であるかどうかの指示を提供することができる。ソースインターフェース84は、ソースに通信可能に結合された様々なインターフェースからソース通知を受信するためのストリーム管理ユニット80の1つまたは複数のインターフェースを表す。さらに、ストリーム管理ユニット80は、たとえば、ネットワークデータを受信するために、無線信号の強度を判定するために、クライアントデバイス40Aなどのワイヤレスデバイスの1つまたは複数の無線から無線信号強度情報(RSSI)を受信することができる。

ストリーム管理ユニット80の取出し制御ユニット82は、ソースインターフェース84を介して受信されたソース通知を分析して、マルチメディアコンテンツに関するデータの取出し元になるソースのうちの1つまたは複数を選択する。いくつかの例では、取出し制御ユニット82は、マルチメディアコンテンツの表現も選択する。取出し制御ユニット82はソース構成要素90から、MPDファイルから抽出された表現特性および表現のセグメントに関するURLなどの情報を受信することができる。情報は、バッファ占有および/または利用可能なスペースの指示、ならびにマルチメディアコンテンツの現在の再生時間をさらに含むことができる。インターフェース73から受信されたソース通知とともにこの情報を使用して、取出し制御ユニット82は、マルチメディアコンテンツに関するデータ、たとえば、現在選択された表現のデータの取出し元になるソースを選択することができる。取出し制御ユニット82は、同じマルチメディアコンテンツについて時間とともに、表現および/または表現に関するデータの取出し元になるソースを適応的に切り替えることができる。

取出し制御ユニット82は、選択されたソース(および場合によっては、選択された表現)の指示をソース構成要素90に提供することができる。さらに、取出し制御ユニット82は、選択された表現のデータを選択されたソースから取り出すための情報を含むダウンロードコマンドを作成することができる。たとえば、ダウンロードコマンドは、ソースタイプの指示およびソース固有の情報を含み得る。たとえば、HTTP/1.1の場合、ダウンロードコマンドは、Getコマンドまたは部分Getコマンドに含まれる選択された表現のセグメントのURLの全経路を指定することができる。別の例として、ブロードキャストまたはマルチキャストネットワーク送信の場合、ダウンロードコマンドは、選択された表現のセグメントを受信するためにブロードキャストまたはマルチキャストグループのネットワークアドレスを指定することができる。このようにして、ストリーム管理ユニット80は、データの取出し元になる適切なソース、ならびに受信する表現の適切なセグメントを、ソース構成要素90およびインターフェース73(ソース受信機とも呼ばれる)から受信された情報に基づいて判定することができる。

ソース構成要素90は、ストリーム管理ユニット80から受信されたダウンロードコマンド情報に基づいて、選択された表現のデータを選択されたソースから取り出すための適切なコマンドを作成することができる。たとえば、ソース構成要素90は、HTTP Get要求もしくは部分Get要求、ブロードキャストもしくはマルチキャストグループに参加することを求める要求、またはローカル記憶媒体のデータを取り出すことを求める要求を生成することができる。ソース構成要素90はさらに、ソースインターフェース98を介してインターフェース73のうちの適切な1つにコマンドを出すことができる。すなわち、ソース構成要素90は、ストリーム管理ユニット80によって選択されたソースに通信可能に結合されたインターフェース73のうちの1つにコマンドを送ることができる。

コマンドに応答して、コマンドを出したインターフェース73のうちの1つは、選択された表現の要求されたマルチメディアデータを選択されたソースから受信することができる。インターフェース73は、取り出されたデータをソース構成要素90に転送するように構成され得る。図3の例では、ソース構成要素90はメディアファイルdemuxユニット96を含み、これは受信されたデータを、たとえばそれぞれのオーディオストリームおよびビデオストリームに逆多重化することができる。メディアファイル記憶処理ユニット92は、受信されたデータを、マルチソース取出しユニット50を含むデバイスのメモリ(図示せず)にバッファリングすることができる。メディアファイル記憶処理ユニット92は、逆多重化されたデータを、たとえば、オーディオデコーダ46およびビデオデコーダ48(図1)に提供することもできる。あるいは、メディアファイル記憶処理ユニット92は、取り出されたメディアデータを、データを逆多重化せずにクライアントデバイス40Bに提供することができる。

このようにして、クライアントデバイス40A(図1)および取出しデバイス70(図2)は、1つまたは複数の様々なソースからDASHに準拠するマルチメディアデータを取り出すように構成されたデバイスの例を表している。これらの例では、デバイスは各々、複数のインターフェースを含み、インターフェースの各々は、複数のソースのそれぞれに通信可能に結合される。たとえば、クライアントデバイス40Aは、サーバデバイス60、ブロードキャストサーバデバイス62、および物理媒体製造施設64によって製造された記憶媒体に通信可能に結合されたインターフェース54を含む。上記で説明したように、インターフェースは、オーバージエアブロードキャストソースなどの他のソースにも通信可能に結合され得る。

したがって、インターフェースは、様々な通信プロトコルに従って動作するように構成され得る。たとえば、インターフェースのうちの1つは、伝送制御プロトコル/インターネットプロトコル(TCP/IP)に従って動作するように構成されたネットワークインターフェースを含み得る。同じネットワークインターフェース(たとえば、ネットワークインターフェースの異なる要素)、または異なるインターフェースは、IPマルチキャストもしくはeMBMS、または他のブロードキャストもしくはマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。別のインターフェースは、物理媒体からデータを受信するように構成され得る。そのようなインターフェースは、ユニバーサルシリアルバス(USB)インターフェース、DVDリーダ、ブルーレイプレーヤ、または物理媒体からデータを取り出すための他のそのようなインターフェースを含み得る。

クライアントデバイス40A(図1)および取出しデバイス70(図2)はまた、マルチメディアコンテンツに関するマニフェストファイルを使用して、マルチメディアコンテンツのマルチメディアデータの取出し元になる複数の表現のうちの1つを選択するように構成されたソース構成要素(たとえば、図3のソース構成要素90)を含むデバイスの例を表している。マニフェストファイルは、マルチメディアコンテンツの複数の表現を示す情報を含むことができ、複数の表現は、表現のうちの選択された1つを含むことができる。当然のこととして、上記で説明したように、ソース構成要素ではなくストリーム管理ユニットが表現を選択するように構成されてもよいことを理解されたい。さらに、いくつかの例では、ソース構成要素およびストリーム管理ユニットは機能的に統合され得る。表現に関するマルチメディアデータは、サーバデバイス60、ブロードキャストサーバデバイス62、および物理媒体製造施設64によって製造された物理媒体などの複数のソースから入手可能であり得る。

クライアントデバイス40A(図1)および取出しデバイス70(図2)はまた、選択された表現に関するマルチメディアデータの取出し元になるソースのうちの1つを選択するように構成されたストリーム管理ユニットを含むデバイスの例を表している。上記で説明したように、ストリーム管理ユニット80は、インターフェース73から受信されたソース通知、モバイルデバイスのワイヤレス無線からのRSSI情報、表現の特性、表現のセグメントに関するセグメント情報および他のそのような情報を分析して、マルチメディアコンテンツの選択された表現に関するデータの取出し元になるソースを選択することができる。

最終的に、ソース構成要素は、選択されたソースに通信可能に結合されたインターフェースのうちの1つを介して、選択された表現に関するマルチメディアデータを選択されたソースから取り出すように構成され得る。たとえば、ストリーム管理ユニット80がマルチメディアデータのソースとしてサーバデバイス60を選択した場合、ソース構成要素90はHTTP受信機/スタック74を介してマルチメディアデータを取り出すことができる。別の例として、ストリーム管理ユニット80がマルチメディアデータのソースとしてブロードキャストサーバデバイス62を選択した場合、ソース構成要素90はブロードキャスト受信機/スタック76を介してマルチメディアデータを取り出すことができる。さらに別の例として、ストリーム管理ユニット80がマルチメディアデータのソースとしてローカル記憶媒体を選択した場合、ソース構成要素90はローカルストレージ78を介してマルチメディアデータを取り出すことができる。

このようにして、クライアントデバイス40Aおよび取出しデバイス70は、DASHに準拠し得る同じマルチメディアコンテンツのマルチメディアデータを多種多様なソースから取り出すための本開示の技法を実施し得るデバイスの例を表している。マルチメディアコンテンツに関するデータを様々なソースから取り出す能力は、様々なシナリオにおいて有利であり得る。一例として、別のソースが利用可能でないときに特定のソースが利用可能であるかどうかをクライアントデバイスが判定できるように、同じコンテンツに関する複数のソースが冗長性をもたらし得る。

別の例として、いくつかの表現がいくつかのソースによってのみ記憶され得る。 たとえば、比較的高い品質の表現が、ブロードキャストを介して入手可能であり得る一方、比較的低い品質の表現が、ユニキャストを介して入手可能であり得る。クライアントデバイスは、最初に、ユニキャストを介して比較的低い品質の表現のデータを取り出し、次いで、ブロードキャスト表現のランダムアクセスポイント(RAP)に達するために十分な量のユニキャスト表現データをバッファリングした後、ブロードキャスト送信またはマルチキャスト送信に切り替えることができる。

いくつかの場合には、クライアントデバイスは、あるソースから受信されたデータを、別のソースからデータを取り出すことによって改良することができる。たとえば、クライアントデバイスは、マルチメディアデータを第1のソースから取り出し、共通する時間の再生期間における追加のマルチメディアデータを第2の異なるソースから取り出すことができる。クライアントデバイスは、特定のソースから受信されたデータを置換または補完するための代替または追加のデータを取り出すことができる。一例として、DVDは通常、DVDが製造された時点における次回の動画のプレビューを含む。本開示の技法によれば、クライアントデバイスは、プレビューが比較的最新のものであるように、DVD自体からではなくサーバデバイスからプレビューのマルチメディアデータを取り出すことができる。同様に、DVDまたは他のローカルにアクセスされるデータ記憶媒体のコンテンツを、これらの技法を使用して代替エンディング、ディレクターズカット、特別な呼び物、削除されたシーン、またはDVDのビデオデータへの他の追加もしくは変更を提供することで、増補することができる。

別の例として、DVDまたは他の記憶媒体は、特定の品質を有するデータ、たとえば、スケーラブルビデオコーディング(SVC)データのベースレイヤを記憶し得る。クライアントデバイスは、ネットワークソースなどの追加ソースが、ベースレイヤを改良するために1つまたは複数のエンハンスメントレイヤを取り出す際に利用可能であるかどうかを判定し得る。ネットワーク接続が利用可能でない場合でもなお、クライアントデバイスはてベースレイヤを復号し、レンダリングすることができる。一方、ネットワーク接続が利用可能である場合には、クライアントデバイスは1つまたは複数のエンハンスメントレイヤに関するデータを取り出すことができる。

さらに別の例として、DVDまたは他の記憶媒体は、たとえば2次元(2D)ビデオ再生をサポートするビデオデータの単一のビューを含み得る。3次元(3D)ビデオ再生をサポートする別個のDVDを購入するのではなく、本開示の態様によれば、クライアントデバイスは、たとえばネットワークソースから代替ビューを取り出し、3次元ビデオ再生をもたらすステレオビューペアとして2つのビューを表示することができる。もちろん、クライアントデバイスは、マルチビュービデオコーディング(MVC)に従って、マルチビュービデオ再生のための追加ビューを取り出すこともできる。

さらに別の例として、DVDは特定のレーティング(たとえば、G、PG、PG-13、R)を有する動画を含むことができ、この場合にレーティングは、特定の視聴者に対するコンテンツ適合性を記述する。本開示の技法は、親のコントロールを実施するために使用され得る。たとえば、DVD上の動画が現在の視聴者に適していない場合、親または他の保護者は、不適切なシーンを置き換えるために代替のオーディオデータおよび/またはビデオデータを取り出すようにクライアントデバイスを構成することができる。代替として、DVDは、比較的無難なビデオコンテンツを記憶することができ、クライアントデバイスは、場合によっては特定の視聴者には不適切であり得るネットワークソースから、補完的なオーディオデータおよび/またはビデオデータを取り出すように構成され得る。

図4は、例示的なマルチメディアコンテンツ100の要素を示す概念図である。図4の例では、マルチメディアコンテンツ100は、メディアプレゼンテーション記述(MPD)102および複数の表現110〜120を含む。表現110は、任意選択のヘッダデータ112およびセグメント114A〜114N(セグメント114)を含み、一方で表現120は、任意選択のヘッダデータ122およびセグメント124A〜124N(セグメント124)を含む。文字Nが、便宜的に、表現110、120の各々の最後の動画フラグメントを指定するために使用される。いくつかの例では、表現110、120の間に、異なる数の動画フラグメントがあり得る。

MPD102は、表現110〜120とは別個のデータ構造を含み得る。MPD102は、図1のマニフェストファイル66に対応し得る。一般に、MPD102は、コーディングおよびレンダリングの特性、表現グループ、MPD102が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を検索するための情報(たとえば、再生中のメディアコンテンツへの、ターゲットを定めた広告の挿入)のような、表現110〜120の特性を一般に表す、データを含み得る。離れた期間は、外部期間とも呼ばれ得る。

ヘッダデータ112は、存在する場合、セグメント114の特性、たとえば、ランダムアクセスポイントの時間ロケーション、セグメント114のいずれがランダムアクセスポイントを含むか、セグメント114内のランダムアクセスポイントに対するバイトオフセット、セグメント114のユニフォームリソースロケータ(URL)、またはセグメント114の他の側面を表すことができる。ヘッダデータ122は、存在する場合、セグメント124の同様の特性を表すことができる。加えて、または代替的に、そのような特性はMPD102内に完全に含まれ得る。

セグメント114は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント114のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。そのような特性は、MPD102のデータによって表され得るが、そのようなデータは図4の例には示されない。MPD102は、本開示で説明されるシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって表されるような特性を含み得る。

セグメント114、124の各々は、固有のユニフォームリソース識別子(URI)、たとえばユニフォームリソースロケータ(URL)に関連付けられ得る。したがって、セグメント114、124の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP Get要求を使用して、セグメント114または124を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分Get要求を使用して、セグメント114または124の特定のバイト範囲を取り出すことができる。たとえば、ブロードキャストの、またはローカル記憶媒体からの何らかのデータが消滅または破損した場合、クライアントデバイス40は、ブロードキャストまたはローカル記憶媒体からできるだけ多くの破損していないデータを取り出し、いくつかの例では、HTTP部分Get要求を使用して、破損したデータに代わる交換データを取り出すことができる。

いくつかの例では、MPD102は(離れた期間とも呼ばれる)外部期間のデータを指し得る。期間は一般に、マルチメディアコンテンツの特定の時間セクションに対応する。各期間は、表現110〜120などの1つまたは複数の表現を含み得る。ただし、外部期間は、マルチメディアコンテンツ100の期間の中または間に挿入され得る。外部期間は、マルチメディアコンテンツのマルチメディアデータに対する追加としてのマルチメディアデータを含むことができる。たとえば、外部期間は広告データを含むことができる。

期間は、それらの持続時間によって定義され得る。すなわち、期間の開始時間は先行期間の持続時間に依存し得る。クライアントデバイスは、MPD構造に外部期間をマッピングすることができる。ライブサービスの場合、MPDの連結は、適切な更新手順によるサーバデバイス60などのサーバ上でのMPDの動的作成によって達成され得る。他のウェブ技術が使用されてもよい。外部的に定義された期間のURLをリアルタイムで処理して、クライアントデバイス40のユーザにターゲットを定めた広告を含む新しい期間を生成することができる。クライアントデバイス40は要求に伴い、広告ターゲッティングに使用され得る追加情報、たとえば、ユーザ識別子、ユーザ選好、ユーザ人口統計学的情報、または他の情報を供給することができる。

下のTable 1(表1)は、マルチメディアコンテンツの1つまたは複数の期間を記述するために、また外部期間の存在を示すために、MPD102において提供され得る情報の例示的なセットを示している。

このようにして、MPD102の期間要素は、たとえば期間リストURIを使用して、外部(または離れた)期間を指し得る。オンデマンドコンテンツの場合、期間持続時間の指示が、クライアントデバイス40などのクライアントデバイスにとって、外部期間をサポートする開始時間よりも有益であり得る。MPDは、一連の期間を含むことができ、期間は内部的または外部的であり得る。ユーザ固有情報とともに、そのような離れた期間を使用することで、ユーザにターゲットを定めた広告が可能になり得る。サーバデバイス60および/またはコンテンツ準備デバイス20は、ユーザごとに、またはクライアントデバイスごとに別個のMPDを動的に生成するように構成され得る。クライアントデバイス40または別のデバイスは、たとえば、動的に作成されたMPDを使用して、ターゲットを定めた広告のプレイアウトおよびライブサービスを連結することができる。

このようにして、本開示の技法は、サービスプロバイダが3GPP AHSを通じてオンデマンドコンテンツを提供する状況をサポートすることができる。コンテンツはいくつかのシーンを含むことができ、各シーンの間に、広告が追加され得る。広告はユーザごとに異なり得る。すなわち、ターゲットを定めた広告が追加され得る。さらに、各広告は持続時間が異なり得る。同様に、サービスプロバイダは特定のライブサービス(たとえば、フリーサービス)を提供し得る。ライブサービスにアクセスするとき、サービスプロバイダは、あるユーザにターゲットを定めているか、または定めていない広告を追加することができる。広告の持続時間は、アクセス時間、アクセスロケーション、ユーザなどに応じて異なり得る。

追加または代替として、外部期間は、マルチメディアデータに関する共通する時間の再生期間に対応する追加データまたは交換データを含むことができる。上記で説明したように、そのような追加データまたは交換データを使用して、マルチメディアデータを変更すること、たとえば、マルチメディアデータのレーティング、筋、または他の特性を変更するためにマルチメディアデータの実際のコンテンツを変更することができる。その上、外部期間は、SVCのエンハンスメントレイヤデータ、MVCの1つもしくは複数の追加ビュー、または1つもしくは複数の既存ビューに適用されるときに追加ビューが生成される場合に生成元になる深度マップなどの補足データを含み得る。

図5は、図4のセグメント114、124のうちの1つのような表現のセグメントに対応し得る、例示的なビデオファイル150の要素を示すブロック図である。セグメント114、124の各々は、図5の例で示されるデータの構成に実質的に準拠するデータを含み得る。同様に、後述の図6〜図7のセグメントも、ビデオファイル150の構造に実質的に準拠し得る。上で説明されたように、ISOベースメディアファイルフォーマットおよびその拡張に従ったビデオファイルは、「ボックス」と呼ばれる一連のオブジェクトにデータを記憶する。図5の例では、ビデオファイル150は、ファイルタイプ(FTYP)ボックス152、動画(MOOV)ボックス154、動画フラグメント(MOOF)ボックス162、および動画フラグメントランダムアクセス(MFRA)ボックス164を含む。

ファイルタイプ(FTYP)ボックス152は一般に、ビデオファイル150のファイルタイプを表す。ファイルタイプボックス152は、ビデオファイル150の最良の使用法を表す仕様を特定する、データを含み得る。ファイルタイプボックス152は、MOOVボックス154、動画フラグメントボックス162、およびMFRAボックス164の前に配置され得る。

いくつかの例では、ビデオファイル150などのセグメントは、FTYPボックス152の前にMPD更新ボックス(図示せず)を含み得る。MPD更新ボックスは、ビデオファイル150を含む表現に対応するMPDが更新されるべきであることを示す情報を、MPDを更新するための情報とともに含み得る。たとえば、MPD更新ボックスは、MPDを更新するために使用されるリソースのURIまたはURLを提供することができる。別の例として、MPD更新ボックスは、MPDを更新するためのデータを含み得る。いくつかの例では、MPD更新ボックスは、ビデオファイル150のセグメントタイプ(STYP)ボックス(図示せず)の直後にくることがあり、このSTYPボックスは、ビデオファイル150のセグメントタイプを定義し得る。

図5の例では、MOOVボックス154は、動画ヘッダ(MVHD)ボックス156、トラック(TRAK)ボックス158、および1つまたは複数の動画延長(MVEX:movie extends)ボックス160を含む。一般に、MVHDボックス156は、ビデオファイル150の一般的な特性を表し得る。たとえば、MVHDボックス156は、ビデオファイル150がいつ最初に作成されたかを表すデータ、ビデオファイル150がいつ最後に修正されたかを表すデータ、ビデオファイル150のタイムスケールを表すデータ、ビデオファイル150の再生の長さを表すデータ、または、ビデオファイル150を全般に表す他のデータを含み得る。

TRAKボックス158は、ビデオファイル150のトラックのデータを含み得る。TRAKボックス158は、TRAKボックス158に対応するトラックの特性を表す、トラックヘッダ(TKHD)ボックスを含み得る。いくつかの例では、TRAKボックス158は、コード化ビデオピクチャを含み得るが、他の例では、トラックのコード化ビデオピクチャは動画フラグメント162に含まれてよく、動画フラグメント162はTRAKボックス158のデータによって参照され得る。

いくつかの例では、ビデオファイル150は、2つ以上のトラックを含み得る。したがって、MOOVボックス154は、ビデオファイル150中のトラックの数と等しい数のTRAKボックスを含み得る。TRAKボックス158は、ビデオファイル150の対応するトラックの特性を表し得る。たとえば、TRAKボックス158は、対応するトラックの時間情報および/または空間情報を表し得る。MOOVボックス154のTRAKボックス158と同様のTRAKボックスは、カプセル化ユニット30(図1)がビデオファイル150のようなビデオファイル中にパラメータセットトラックを含める場合、パラメータセットトラックの特性を表し得る。カプセル化ユニット30は、パラメータセットトラックを表すTRAKボックス内で、パラメータセットトラックにシーケンスレベルSEIメッセージが存在することをシグナリングすることができる。

MVEXボックス160は、たとえば、ビデオファイル150が、もしあれば、MOOVボックス154内に含まれるビデオデータに加えて、動画フラグメント162を含むことをシグナリングするために、対応する動画フラグメント162の特性を表すことができる。ストリーミングビデオデータの文脈では、コード化ビデオピクチャは、MOOVボックス154の中ではなく動画フラグメント162の中に含まれ得る。したがって、すべてのコード化ビデオサンプルは、MOOVボックス154の中ではなく動画フラグメント162の中に含まれ得る。

MOOVボックス154は、ビデオファイル150の中の動画フラグメント162の数と等しい数のMVEXボックス160を含み得る。MVEXボックス160の各々は、動画フラグメント162のうちの対応する1つに関する特性を表し得る。たとえば、各MVEXボックスは、動画フラグメント162のうちの対応する1つに関する時間長を表す動画延長ヘッダ(MEHD)ボックスを含み得る。

上で述べられたように、カプセル化ユニット30は、実際のコード化ビデオデータを含まないビデオサンプルに、シーケンスデータセットを記憶することができる。ビデオサンプルは、一般にアクセスユニットに対応してよく、アクセスユニットは、特定の時間インスタンスにおけるコード化ピクチャの表現である。AVCの文脈では、アクセスユニットと、SEIメッセージのような他の関連する非VCL NALユニットとのすべてのピクセルを構築するための情報を格納する、1つまたは複数のVCL NALユニットを、コード化ピクチャは含む。したがって、カプセル化ユニット30は、シーケンスレベルSEIメッセージを含み得るシーケンスデータセットを、動画フラグメント162のうちの1つの中に含め得る。カプセル化ユニット30はさらに、シーケンスデータセットおよび/またはシーケンスレベルSEIメッセージの存在を、動画フラグメント162のうちの1つに対応するMVEXボックス160のうちの1つの中で、動画フラグメント162のうちの1つの中に存在するものとして、シグナリングすることができる。

動画フラグメント162は、1つまたは複数のコード化ビデオピクチャを含み得る。いくつかの例では、動画フラグメント162は、1つまたは複数のピクチャグループ(GOP)を含んでよく、GOPの各々は、多数のコード化ビデオピクチャ、たとえばフレームまたはピクチャを含み得る。加えて、上で説明されたように、動画フラグメント162は、いくつかの例ではシーケンスデータセットを含み得る。動画フラグメント162の各々は、動画フラグメントヘッダボックス(MFHD、図5には示されない)を含み得る。MFHDボックスは、動画フラグメントのシーケンス番号のような、対応する動画フラグメントの特性を表し得る。動画フラグメント162は、ビデオファイル150の中で、シーケンス番号の順番に含まれ得る。

MFRAボックス164は、ビデオファイル150の動画フラグメント162内のランダムアクセスポイントを表し得る。これは、トリックモードを実行すること、たとえば、ビデオファイル150内の特定の時間ロケーションへの探索を実行することを支援することができる。MFRAボックス164は、いくつかの例では、一般に任意選択であり、ビデオファイル中に含まれる必要はない。同様に、クライアントデバイス40のようなクライアントデバイスは、ビデオファイル150のビデオデータを正確に復号し表示するために、MFRAボックス164を必ずしも参照する必要はない。MFRAボックス164は、ビデオファイル150のトラックの数と等しい数のトラックフラグメントランダムアクセス(TFRA)ボックス(図示せず)を含んでよく、またはいくつかの例では、ビデオファイル150のメディアトラック(たとえば、ノンヒントトラック)の数と等しい数のTFRAボックスを含んでよい。

セグメント114、124は各々、ビデオファイル150と同様にフォーマットされ得る。その上、セグメント114、124の各々は、それぞれのURLに関連付けられ得る。セグメント114、124は、異なるソースに記憶され得るので、URLの経路部分は、対応するセグメントが入手可能であるソースを指定することができる。たとえば、ローカル記憶媒体上に記憶されたデータの場合、URL経路部分は、ネットワークアドレスではなく、ローカルストレージ上にファイルとしてURLのデータが記憶されていることを示す「file://」で始まり得る。

図6は、多種多様なソースのうちの1つまたは複数からマルチメディアデータを取り出すための例示的な方法を示すフローチャートである。図1の例のデバイスに関して説明されるが、他のデバイスが、図6の方法のステップを実行するように構成されてもよいことを理解されたい。たとえば、図2の取出しデバイス70は、図6の取出しデバイスに起因するステップを実行するように構成され得る。図6の方法のステップは、マルチメディアコンテンツのセグメントまたは期間ごとに反復して実行され得る。いくつかのステップは省略されてよく、さらなるステップが追加されてよい。その上、いくつかのステップは並行して実行され得る。

図6の例では、最初に、ソースデバイスがクライアントデバイス40Aなどの取出しデバイスにMPDファイルを送る(180)。MPDファイルは一般に、特定のマルチメディアコンテンツに対応する。次いで(取出しデバイスの一例を表す)クライアントデバイス40Aは、MPDファイルを受信する(182)ことができる。ソース構成要素90がMPDファイルを受信し、パースして、表現、表現の特性、表現のセグメントに関するURLおよび他のそのような情報を示す情報をMPDファイルから抽出することができる。ソース構成要素90は、この情報をストリーム管理ユニット80に提供することができる。

ストリーム管理ユニット80は、ソース構成要素90から受信された情報を使用して、マルチメディアコンテンツの利用可能な表現を判定する(184)ことができる。ストリーム管理ユニット80はまた、マルチメディアコンテンツのデータが取り出される場合の取出し元になる利用可能なソースを判定する(186)ことができる。

ストリーム管理ユニット80はさらに、クライアントデバイス40Aの復号能力およびレンダリング能力を判定する(188)ことができる。たとえば、ストリーム管理ユニット80は、ビデオデコーダ48が準拠するプロファイルおよび/もしくはレベル、ビデオ出力44の画面サイズ、ビデオ出力44のリフレッシュ速度、ほぼ同時にビデオ出力44によって表示され得るビューの数、または他のそのような能力を判定することができる。

さらに、ストリーム管理ユニット80は、様々なソースの接続性およびデータを判定する(190)ことができる。たとえば、ストリーム管理ユニット80は、ワイヤレス無線に関するRSSI情報、HTTPトラフィックの予測される利用可能な帯域幅(サーバデバイス60の利用可能性に関係する)、マルチメディアコンテンツのブロードキャストもしくはマルチキャストが受信され得るかどうか、またブロードキャストもしくはマルチキャストのURLが利用可能であるかどうか(ブロードキャストサーバデバイス62の利用可能性に関係する)、および/またはマルチメディアコンテンツのデータを記憶しているローカル物理媒体にURLが利用可能であるかどうか(物理媒体製造施設64によって製造されるローカル記憶媒体の利用可能性に関係する)などのソース通知を受信し、分析することができる。

上述の情報を使用して、ストリーム管理ユニット80は、マルチメディアコンテンツの表現(192)、ならびに選択された表現のデータ(たとえば、セグメント)の取出し元になるソース(194)を選択することができる。次いでストリーム管理ユニット80は、選択された表現およびソースの指示をソース構成要素90に提供することができる。そしてソース構成要素90は選択されたソースに対し、表現のデータを要求する(196)ことができる。

たとえば、サーバデバイス60が選択されたとき、ソース構成要素90は、表現のセグメントに関連するURLを指定するHTTP Getまたは部分Getを使用して、サーバデバイス60に対しデータを要求することができる。別の例として、ブロードキャストサーバデバイス62が選択されたとき、ソース構成要素90は、選択されたセグメントのデータをブロードキャストサーバデバイス62から受信するためにブロードキャストまたはマルチキャストグループに参加することを求める要求を生成することができる。さらに別の例として、ローカルストレージが選択されたとき、ソース構成要素90は、ローカルストレージからデータを取り出すことを求める要求を生成することができる。これは、ローカル記憶媒体によって記憶されたセグメントに関連するURLを指定し得る。

次いで対応するソースデバイスは、取出しデバイス、たとえばクライアントデバイス40Aに、要求されたデータを送る(198)ことができる。クライアントデバイス40Aは、要求されたデータを受信した後、受信されたデータを逆多重化して、対応するオーディオストリームおよびビデオストリームを形成することができる。次いでクライアントデバイス40Aは、たとえば、逆多重化されたオーディオストリームおよびビデオストリームを復号し、提示する(たとえば、レンダリングする)ことによって、受信されたデータを復号し、提示する(200)ことができる。他の例では、たとえば、取出しデバイス70(図2)が図6の方法の技法を実施するとき、取出しデバイス70は、取り出されたデータをクライアントデバイス40Bに提供することができ、クライアントデバイス40Bは、取り出されたメディアデータを復号し、レンダリングすることができる。

このようにして、図6の方法は、マルチメディアコンテンツに関するマニフェストファイルを使用して、マルチメディアコンテンツのマルチメディアデータの取出し元になる複数の表現のうちの1つを選択するステップを含む方法の一例を表している。マニフェストファイルは、マルチメディアコンテンツの複数の表現を示す情報を含むことができ、複数の表現は、表現のうちの選択された1つを含むことができ、表現に関するマルチメディアデータは、複数のソースから入手可能であり得る。本方法は、選択された表現に関するマルチメディアデータの取出し元になるソースのうちの1つを選択するステップをさらに含み得る。その上、本方法は、選択された表現に関するマルチメディアデータの少なくとも一部分を選択されたソースから取り出すステップを含むことができる。

図7は、様々なソースのうちの1つまたは複数からマルチメディアコンテンツのデータを取り出すための例示的な方法をより詳細に示すフローチャートである。図7の方法は、例および説明の目的上、図3の構成要素に関して説明している。図3のマルチソース取出しユニット50と同様の構成要素を含むデバイスが、図7の方法と同様の方法を実行するように構成され得ることを理解されたい。ここでも、図7の方法のステップは、異なる順序で、または並行して実行されてよく、追加のステップが実行されてよく、またはいくつかのステップが省略されてよい。

この例では、ソース構成要素90は、たとえば、受信されたMPDファイルを使用して、マルチメディアコンテンツに関する表現情報を判定する(210)ことができる。上記で説明したように、表現情報は、復号特性およびレンダリング特性、セグメントに関するURL、またはマルチメディアコンテンツに関する他のそのような情報を含むことができる。ソース構成要素90は、ストリーム管理ユニット80に表現情報を送る(212)ことができ、ストリーム管理ユニット80は、表現情報を受信する(214)ことができる。さらに、いくつかの例では、ストリーム管理ユニット80は、表現情報を使用して、表現のうちの1つを選択することができる。

ソース構成要素90はまた、ストリーム管理ユニット80に対してダウンロードコマンドを要求する(216)ことができる。次いでストリーム管理ユニット80は、ダウンロードコマンドを求める要求をソース構成要素90から受信する(218)ことができる。応答して、ストリーム管理ユニット80は、選択された表現のデータの取出し元になるソースを判定する(220)ことができる。次いでストリーム管理ユニット80は、選択されたソースおよび選択された表現のデータ(たとえば、セグメント)に関するダウンロードコマンドを作成する(222)ことができる。したがって、ダウンロードコマンドは、たとえば、選択されたソースによって実装されるプロトコルに従ってフォーマットされ得る。次いでストリーム管理ユニット80は、ダウンロードコマンドをソース構成要素90に送る(224)ことができる。

ソース構成要素90はダウンロードコマンドを使用して、示されたソース、すなわち、ストリーム管理ユニット80によって選択されたソースに対して、マルチメディアデータを要求する(226)ことができる。要求を受信した(228)ことに応答して、ソースデバイスは、要求されたマルチメディアデータを送る(230)ことができる。ソース構成要素90は、要求されたマルチメディアデータを受信し、バッファリングする(232)ことができる。次いでソース構成要素90は、バッファリングされたデータを逆多重化すること、またはそのデータを、逆多重化するために別のデバイスに送ることができる。

図8は、それぞれのソースに通信可能に結合された様々なインターフェースからソース通知をストリーミングマネージャ(たとえば、ストリーム管理ユニット80)が受信する概念タイミング図を示すフローチャートである。この例では、ストリーム管理ユニット80は、プラットフォーム(たとえば、モバイルデバイスのオペレーティングシステム)から、3G(Third Generation Partnership Project)ワイヤレス無線、ワイヤレスネットワーク(たとえば、しばしば「WiFi」と呼ばれるIEEE802.11x)、およびLong Term Evolution(LTE)無線などのプラットフォームの様々な無線に関する受信信号強度情報を示す情報を受信することができる。

ストリーム管理ユニット80はまた、HTTP受信機/スタック74(図3)などのHTTP受信機から、予測される帯域幅情報を受信することができる。さらに、ストリーム管理ユニット80は、ブロードキャストネットワークがカバレージ内(たとえば、モバイルデバイスが通信可能に結合された無線アクセスネットワーク(RAN)内)にあるかどうかの指示のほか、ブロードキャストネットワークがRANのカバレージ内にあるときにはブロードキャストのURLを受信することができる。その上、ストリーム管理ユニット80は、表現のデータのURLが、ローカルストレージ78(図3)などのローカルストレージによって記憶されたデータに利用可能であるかどうかの指示を受信することができる。

図9は、本開示の技法に従って1つまたは複数の様々なソースからのストリームを初期化するために適用され得る、DASHに従ってストリームを初期化するための例示的な方法を示すフローチャートである。最初に、ソース構成要素90は、ストリームインスタンスを作成する(250)ことができる。ストリーム管理ユニット80は、作成されたストリームインスタンスで応答する(252)することができる。ストリーム管理ユニット80はまた、作成されたストリームインスタンスに関するストリーム管理スレッドを作成し、初期化する(254)ことができる。ストリーム管理ユニット80は、ソース構成要素90に対してストリームソース能力を要求する(256)ことができる。ソース構成要素90は、判定されたストリームソース能力で応答する(258)ことができる。

次いでソース構成要素90は、ストリーム管理ユニット80に再生要求を出す(260)ことができ、ストリーム管理ユニット80は、確認応答する(262)ことができる。マルチメディアコンテンツを再生し始めるために、ストリーム管理ユニット80は、マルチメディアコンテンツの表現グループ(たとえば、適応セット)に関するグループ情報を要求する(264)ことができる。ソース構成要素90は、利用可能な適応セットおよび適応セットに対応する表現に関する共通の特性を判定し、この情報をストリーム管理ユニット80に提供する(266)ことができる。

適応セットごとに、ストリーム管理ユニット80は、適応セットにおける表現の特性を記述している情報を要求する(268A〜268N)ことができる。ソース構成要素90は、適応セットにおける表現の特性を記述している、要求された情報で応答する(270A〜270N)ことができる。次いでストリーム管理ユニット80は、周期的に、たとえばXミリ秒(ms)ごとに判定された利用可能な帯域幅を要求するために使用され得るタイマーを開始する(276)ことができる。したがって、タイマーが終了したとき、ストリーム管理ユニット80は、観察された帯域幅を要求する(278)ことができ、ソース構成要素90は、判定された帯域幅量で応答する(280)ことができる。代替として、インターフェース73のうちの1つが、判定された帯域幅量で応答することができる。同様に、追加または代替として、ストリーム管理ユニット80は、ブロードキャストサーバデバイス62および物理媒体製造施設64によって製造された物理記憶媒体などの他のソースとの通信セッションの特性を要求することもできる。ストリーム管理ユニット80は、ソース構成要素90に対して占有バッファスペース量を要求する(282)こともでき、これに応答してソース構成要素90は、たとえば、メディアファイル記憶処理ユニット92によって判定された、現在占有されているバッファスペース量の指示を提供することができる。

図10は、マルチメディアコンテンツの表現のデータユニット(たとえば、セグメント)に関する情報を取り出すための例示的な方法を示すフローチャートである。本開示の技法によれば、マルチメディアコンテンツのセグメントは、たとえば、様々な通信プロトコルに従って、1つまたは複数の様々なソースから取り出され得る。図10の例では、ストリーム管理ユニット80は最初に、ビットレートおよび表現を選択する(290)ことができる。ストリーム管理ユニット80は、図9のステップ278および280で判定された、利用可能なネットワーク帯域幅の量に基づいてビットレートを判定することができる。次いでストリーム管理ユニット80は、ビットレートならびにクライアントデバイスの復号能力およびレンダリング能力などの他の要素に基づいて、表現を選択することができる。その上、図10の方法におけるステップは、適応セットごとに(たとえば、表現のグループごとに)反復して繰り返され得る。

表現を選択した後、ストリーム管理ユニット80はデータユニット情報、たとえばセグメント情報を要求する(292)ことができる。ソース構成要素90は、要求に確認応答し(294)、要求されたセグメント情報を、MPDファイルまたはマルチメディアコンテンツに関する別のデータ構造、たとえばセグメントインデックスボックス(SIDX)から判定することができる。次いでソース構成要素90は、利用可能なデータユニット(たとえば、セグメント)の指示を含む判定された情報をストリーム管理ユニット80に送る(296)ことができる。次いでストリーム管理ユニット80は、利用可能なデータユニットに関する情報に確認応答する(298)ことができる。

ソース構成要素90から受信された情報を分析することを通じて、ストリーム管理ユニット80は、ランダムアクセスポイント(RAP)を含むデータユニット(たとえば、セグメント)を判定する(300)ことができる。上記で説明したように、RAPは、Iフレームまたは同じフレームに対応するIスライスのセットに対応し得る。次いでストリーム管理ユニット80は、RAPを含むデータユニット(たとえば、セグメント)を取り出すコマンドをソース構成要素90に出す(302)ことができる。次いでソース構成要素90は、RAPを含むデータユニットを取り出し、受信を確認する(304)ことができる。

ストリーム管理ユニット80はさらに、ダウンロード要求が最大数に至るまで要求するコマンドを作成し、コマンドの各々をソース構成要素90に出すことができ、ソース構成要素90はコマンドを使用して、対応するデータを取り出す(304〜308)ことができる。次いでストリーム管理ユニット80は、ソース構成要素90に示される表現を選択する(310)ことができ、ソース構成要素90は、選択を確認する(312)ことができる。ソース構成要素90は、いつ表現の選択が終了したかを示す(314)ことができ、ストリーム管理ユニット80は、受信を確認する(316)ことができる。このようにして、マルチソース取出しユニット50は、表現に関するランダムアクセスポイントのロケーションなど、マルチメディアコンテンツの様々な表現を記述している情報を取得することができる。

図11は、たとえば、レート再選択を実行するための、利用可能なネットワーク帯域幅の変化に適応するための例示的な方法を示すフローチャートである。図11の方法は、データユニット、たとえばセグメントの取出しに続くものであり得る。したがって、ソース構成要素90は、データユニットがダウンロードされたことを示す(320)ことができ、ストリーム管理ユニット80はそれを確認する(322)ことができる。ステップ324〜326は、図9のステップ282〜284にほぼ合致することができる。この例では、ストリーム管理ユニット80は、利用可能なネットワーク帯域幅の量が変化したと判定し、同様に、異なる表現を選択する(328)ことがある。異なる表現を選択した後、ストリーム管理ユニット80は、ソース構成要素90に対し、現在のデータユニットの取出しをキャンセルするように命令する(330)ことができ、したがって、ソース構成要素90は、現在のセグメントの取出しをキャンセルする(332)ことができる。これの後にくるステップ334〜358は、それぞれのステップ292〜316(図10)にほぼ合致する。

1つまたは複数の例では、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶され、あるいはコンピュータ可読媒体を介して送信されてよく、かつハードウェアに基づく処理ユニットによって実行されてよい。コンピュータ可読媒体は、データ記憶媒体のような有形媒体、または、たとえば通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を支援する任意の媒体を含む通信媒体に相当する、コンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は一般に、(1)非一時的な有形コンピュータ可読記憶媒体または(2)信号波もしくは搬送波のような通信媒体に相当し得る。データ記憶媒体は、本開示で説明される技法を実装するための、命令、コード、および/またはデータ構造を取り出すために、1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であってよい。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。

限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態の所望のプログラムコードを記憶するために使用され、コンピュータによってアクセスされ得る任意の他の媒体を含み得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的な有形記憶媒体を指すことを理解されたい。本明細書で使用される場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー（登録商標）ディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。

命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または他の等価の集積論理回路もしくはディスクリート論理回路のような、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または、本明細書で説明される技法の実装に適した任意の他の構造の、いずれをも指し得る。加えて、いくつかの態様では、本明細書で説明される機能は、符号化および復号のために構成された、専用のハードウェアモジュールおよび/またはソフトウェアモジュール内で提供されてよく、または、組み合わされたコーデックに組み込まれてよい。また、技法は、1つまたは複数の回路素子または論理素子において完全に実装されてもよい。

本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、またはICのセット(たとえば、チップセット)を含む、多様なデバイスまたは装置において実装され得る。様々な構成要素、モジュール、またはユニットが、開示される技法を実行するように構成されるデバイスの機能的な側面を強調するために、本開示において説明されるが、必ずしも異なるハードウェアユニットによる実現を必要としない。むしろ上で説明されたように、様々なユニットは、コーデックハードウェアユニットへと組み合わされてよく、または、適切なソフトウェアおよび/またはファームウェアとともに、上で説明されたような1つまたは複数のプロセッサを含む相互動作可能なハードウェアユニットの集合によって与えられてよい。

様々な例が説明されてきた。これらの例および他の例は、以下の特許請求の範囲内にある。

10 システム
14 ネットワーク
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
40A クライアントデバイス
40B クライアントデバイス
42 オーディオ出力
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 マルチソース取出しユニット
50A マルチソース取出しユニット
50B マルチソース取出しユニット
54 インターフェース
56 逆多重化ユニット
58 インターフェース
60 サーバデバイス
62 ブロードキャストサーバデバイス
64 物理媒体製造施設

Claims (37)

1. マルチメディアデータを取り出す方法であって、
   マルチメディアコンテンツに関するマニフェストファイルを使用して、前記マルチメディアコンテンツのマルチメディアデータの取出し元になる複数の表現のうちの1つを選択するステップであって、
   前記表現は、前記マルチメディアコンテンツのある特定の期間に対応するとともに、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指し、
   前記マニフェストファイルは、前記マルチメディアコンテンツの前記複数の表現を示す情報を含み、
   前記複数の表現は、前記表現のうちの前記選択された1つを含む、ステップと、
   前記マニフェストファイルにより示される複数のソースが前記選択された表現の１つを含むことを、前記マニフェストファイルから判定するステップであって、前記複数のソースがブロードキャストソースおよびユニキャストソースを含む、ステップと、
   前記選択された表現に関するマルチメディアデータの取出し元になる前記ソースのうちの1つを選択するステップと、
   前記選択された表現に関する前記マルチメディアデータの少なくとも一部分を前記選択されたソースから取り出すステップとを含む方法。
2. 前記複数のソースは、ユニキャストサーバデバイス、ブロードキャストサーバデバイス、およびローカル記憶媒体のうちの1つまたは複数を含む、請求項1に記載の方法。
3. 前記マニフェストファイルは、拡張可能マークアップ言語(XML)に従ってフォーマットされたメディアプレゼンテーション記述(MPD)ファイルを含み、前記MPDファイルは、前記表現のセグメントのユニフォームリソースロケータ(URL)および前記表現の特性を示す情報を含む、請求項1に記載の方法。
4. 前記選択されたソース以外の前記ソースの第2のソースから追加マルチメディアデータを取り出すステップをさらに含み、前記マルチメディアデータおよび前記追加マルチメディアデータは、共通する時間の再生期間に対応する、請求項1に記載の方法。
5. 前記表現のうちの前記選択された1つに関する前記マルチメディアデータは、ベースビューに対応するビデオデータを含み、前記追加マルチメディアデータは、エンハンスメントレイヤのビデオデータを含む、請求項4に記載の方法。
6. 前記追加マルチメディアデータは、メディアコンテンツに関連する外部期間を含む、請求項4に記載の方法。
7. 前記追加マルチメディアデータは、広告マルチメディアデータを含む、請求項4に記載の方法。
8. 前記マニフェストファイルのデータを使用して、前記表現の利用可能性を判定するステップと、
   前記マニフェストファイルから、前記表現のコーディング特性、表示特性、およびビットレートを判定するステップとをさらに含み、
   複数の表現のうちの1つを選択するステップは、前記表現の前記コーディング特性、前記表現の前記表示特性、および前記表現の前記ビットレートに基づいて前記表現を選択するステップを含む、請求項1に記載の方法。
9. クライアントデバイスのコーディング能力を判定するステップと、
   前記クライアントデバイスのレンダリング能力を判定するステップとをさらに含み、
   複数の表現のうちの1つを選択するステップは、前記クライアントデバイスの前記コーディング能力が前記表現の前記コーディング特性を満たすように、また前記クライアントデバイスの前記レンダリング能力が前記表現の前記表示特性を満たすように、前記表現を選択するステップを含む、請求項8に記載の方法。
10. 前記ソースから受信された情報に基づいて、前記ソースの利用可能性を判定するステップをさらに含み、前記ソースのうちの1つを選択するステップは、利用可能なソースのうちの1つを選択するステップを含む、請求項1に記載の方法。
11. 各々が複数のソースのそれぞれに通信可能に結合された複数のインターフェースであって、前記複数のソースは、ブロードキャストソースおよびユニキャストソースを含む、インターフェースと、
    マルチメディアコンテンツに関するマニフェストファイルを使用して、前記マルチメディアコンテンツのマルチメディアデータの取出し元になる複数の表現のうちの1つを選択するように構成されたストリーム管理ユニットであって、
    前記表現は、前記マルチメディアコンテンツのある特定の期間に対応するとともに、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指し、
    前記マニフェストファイルは、前記マルチメディアコンテンツの前記複数の表現を示す情報を含み、
    前記複数の表現は、前記表現のうちの前記選択された1つを含み、
    前記ストリーム管理ユニットは、
    前記ブロードキャストソースおよびユニキャストソースを含む前記複数のソースが前記選択された表現の１つを含むことを、前記マニフェストファイルから判定し、
    前記選択された表現に関するマルチメディアデータの取出し元になる前記ソースのうちの1つを選択するように構成された、ストリーム管理ユニットと、
    前記選択されたソースに通信可能に結合された前記インターフェースのうちの1つを介して、前記選択された表現に関するマルチメディアデータを前記選択されたソースから取り出すように構成されたソース構成要素とを含むデバイス。
12. 前記ソース構成要素および前記ストリーム管理ユニットに起因する機能に関する命令を含むコンピュータ可読記憶媒体と、
    前記ソース構成要素および前記ストリーム管理ユニットに関する前記命令を実行するように構成された1つまたは複数のプロセッサとをさらに含む、請求項11に記載のデバイス。
13. 前記複数のインターフェースは、ハイパーテキストトランスポートプロトコル(HTTP)スタックを実装している第1のネットワークインターフェース、ブロードキャストネットワーク送信を受信するためのブロードキャストスタックを実装している第2のネットワークインターフェース、およびコンピュータ可読記憶媒体からデータを取り出すためのコンピュータ可読記憶媒体インターフェースのうちの1つまたは複数を含む、請求項11に記載のデバイス。
14. 前記コンピュータ可読記憶媒体は、デジタルビデオディスク(DVD)またはブルーレイディスクを含む、請求項13に記載のデバイス。
15. 前記ストリーム管理ユニットは、ネットワーク接続が利用可能であるかどうかを判定し、前記ネットワーク接続が利用可能であると判定されたときに、前記第1のネットワークインターフェースまたは前記第2のネットワークインターフェースに通信可能に結合された前記ソースのうちの1つを選択し、前記ネットワーク接続が利用可能でないと判定されたときに、前記コンピュータ可読記憶媒体インターフェースに通信可能に結合された前記ソースのうちの1つを選択するように構成される、請求項13に記載のデバイス。
16. 前記ストリーム管理ユニットは、予測される帯域幅情報であって、ブロードキャストが利用可能であるかどうか、また前記ブロードキャストのURLが前記第2のネットワークインターフェースから利用可能であるかどうか、また前記マルチメディアデータのURLが前記コンピュータ可読記憶媒体インターフェースから利用可能であるかどうかを示す情報を、前記第1のネットワークインターフェースから受信するように構成され、前記ストリーム管理ユニットは、前記受信された情報に少なくとも部分的に基づいて前記ソースのうちの前記1つを選択するように構成される、請求項13に記載のデバイス。
17. 前記ストリーム管理ユニットは、前記選択されたソース以外の前記ソースの第2のソースから追加マルチメディアデータを選択するように構成され、前記マルチメディアデータおよび前記追加マルチメディアデータは、共通する時間の再生期間に対応し、
    前記ソース構成要素は、前記第2のソースに通信可能に結合された前記インターフェースを介して前記追加マルチメディアデータを取り出すように構成される、請求項11に記載のデバイス。
18. マルチメディアデータを取り出すためのデバイスであって、
    マルチメディアコンテンツに関するマニフェストファイルを使用して、前記マルチメディアコンテンツのマルチメディアデータの取出し元になる複数の表現のうちの1つを選択するための手段であって、
    前記表現は、前記マルチメディアコンテンツのある特定の期間に対応するとともに、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指し、
    前記マニフェストファイルは、前記マルチメディアコンテンツの前記複数の表現を示す情報を含み、
    前記複数の表現は、前記表現のうちの前記選択された1つを含む、手段と、
    前記マニフェストファイルにより示される複数のソースが前記選択された表現の１つを含むことを、前記マニフェストファイルから判定する手段であって、前記複数のソースがブロードキャストソースおよびユニキャストソースを含む、手段と、
    前記選択された表現に関するマルチメディアデータの取出し元になる前記ソースのうちの1つを選択するための手段と、
    前記選択された表現に関する前記マルチメディアデータの少なくとも一部分を前記選択されたソースから取り出すための手段とを含むデバイス。
19. 前記複数のソースは、ユニキャストサーバデバイス、ブロードキャストサーバデバイス、およびローカル記憶媒体のうちの1つまたは複数を含む、請求項18に記載のデバイス。
20. 前記マニフェストファイルは、拡張可能マークアップ言語(XML)に従ってフォーマットされたメディアプレゼンテーション記述(MPD)ファイルを含み、前記MPDファイルは、前記表現のセグメントのユニフォームリソースロケータ(URL)および前記表現の特性を示す情報を含む、請求項18に記載のデバイス。
21. 前記選択されたソース以外の前記ソースの第2のソースから追加マルチメディアデータを取り出すための手段をさらに含み、前記マルチメディアデータおよび前記追加マルチメディアデータは、共通する時間の再生期間に対応する、請求項18に記載のデバイス。
22. 前記表現のうちの前記選択された1つに関する前記マルチメディアデータは、ベースビューに対応するビデオデータを含み、前記追加マルチメディアデータは、エンハンスメントレイヤのビデオデータを含む、請求項21に記載のデバイス。
23. 前記追加マルチメディアデータは、メディアコンテンツに関連する外部期間を含む、請求項21に記載のデバイス。
24. 前記追加マルチメディアデータは、広告マルチメディアデータを含む、請求項21に記載のデバイス。
25. 前記マニフェストファイルのデータを使用して、前記表現の利用可能性を判定するための手段と、
    前記マニフェストファイルから、前記表現のコーディング特性、表示特性、およびビットレートを判定するための手段とをさらに含み、
    複数の表現のうちの1つを選択するための前記手段は、前記表現の前記コーディング特性、前記表現の前記表示特性、および前記表現の前記ビットレートに基づいて前記表現を選択するための手段を含む、請求項18に記載のデバイス。
26. 前記デバイスのコーディング能力を判定するための手段と、
    前記デバイスのレンダリング能力を判定するための手段とをさらに含み、
    複数の表現のうちの1つを選択するための前記手段は、前記デバイスの前記コーディング能力が前記表現の前記コーディング特性を満たすように、また前記デバイスの前記レンダリング能力が前記表現の前記表示特性を満たすように、前記表現を選択するための手段を含む、請求項25に記載のデバイス。
27. 前記ソースから受信された情報に基づいて、前記ソースの利用可能性を判定するための手段をさらに含み、前記ソースのうちの1つを選択するための前記手段は、利用可能なソースのうちの1つを選択するための手段を含む、請求項18に記載のデバイス。
28. 実行されると、プロセッサに、
    マルチメディアコンテンツに関するマニフェストファイルを使用して、前記マルチメディアコンテンツのマルチメディアデータの取出し元になる複数の表現のうちの1つを選択させる命令であって、
    前記表現は、前記マルチメディアコンテンツのある特定の期間に対応するとともに、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指し、
    前記マニフェストファイルは、前記マルチメディアコンテンツの前記複数の表現を示す情報を含み、
    前記複数の表現は、前記表現のうちの前記選択された1つを含む、命令と、
    前記マニフェストファイルにより示される複数のソースが前記選択された表現の１つを含むことを、前記マニフェストファイルから判定する命令であって、前記複数のソースがブロードキャストソースおよびユニキャストソースを含む、命令と、
    前記選択された表現に関するマルチメディアデータの取出し元になる前記ソースのうちの1つを選択させる命令と、
    前記選択された表現に関する前記マルチメディアデータの少なくとも一部分を前記選択されたソースから取り出させる命令とを記憶したコンピュータ可読記憶媒体。
29. 前記複数のソースは、ユニキャストサーバデバイス、ブロードキャストサーバデバイス、およびローカル記憶媒体のうちの1つまたは複数を含む、請求項28に記載のコンピュータ可読記憶媒体。
30. 前記マニフェストファイルは、拡張可能マークアップ言語(XML)に従ってフォーマットされたメディアプレゼンテーション記述(MPD)ファイルを含み、前記MPDファイルは、前記表現のセグメントのユニフォームリソースロケータ(URL)および前記表現の特性を示す情報を含む、請求項28に記載のコンピュータ可読記憶媒体。
31. 前記プロセッサに、前記選択されたソース以外の前記ソースの第2のソースから追加マルチメディアデータを取り出させる命令をさらに含み、前記マルチメディアデータおよび前記追加マルチメディアデータは、共通する時間の再生期間に対応する、請求項28に記載のコンピュータ可読記憶媒体。
32. 前記表現のうちの前記選択された1つに関する前記マルチメディアデータは、ベースビューに対応するビデオデータを含み、前記追加マルチメディアデータは、エンハンスメントレイヤのビデオデータを含む、請求項31に記載のコンピュータ可読記憶媒体。
33. 前記追加マルチメディアデータは、メディアコンテンツに関連する外部期間を含む、請求項31に記載のコンピュータ可読記憶媒体。
34. 前記追加マルチメディアデータは、広告マルチメディアデータを含む、請求項31に記載のコンピュータ可読記憶媒体。
35. 前記プロセッサに、
    前記マニフェストファイルのデータを使用して、前記表現の利用可能性を判定させ、
    前記マニフェストファイルから、前記表現のコーディング特性、表示特性、およびビットレートを判定させる命令をさらに含み、
    前記プロセッサに、複数の表現のうちの1つを選択させる前記命令は、前記プロセッサに、前記表現の前記コーディング特性、前記表現の前記表示特性、および前記表現の前記ビットレートに基づいて前記表現を選択させる命令を含む、請求項28に記載のコンピュータ可読記憶媒体。
36. 前記プロセッサに、
    クライアントデバイスのコーディング能力を判定させる命令と、
    前記クライアントデバイスのレンダリング能力を判定させる命令とをさらに含み、
    前記プロセッサに、複数の表現のうちの1つを選択させる前記命令は、前記プロセッサに、前記クライアントデバイスの前記コーディング能力が前記表現の前記コーディング特性を満たすように、また前記クライアントデバイスの前記レンダリング能力が前記表現の前記表示特性を満たすように、前記表現を選択させる命令を含む、請求項35に記載のコンピュータ可読記憶媒体。
37. 前記プロセッサに、前記ソースから受信された情報に基づいて、前記ソースの利用可能性を判定させる命令をさらに含み、前記プロセッサに、前記ソースのうちの1つを選択させる前記命令は、前記プロセッサに、利用可能なソースのうちの1つを選択させる命令を含む、請求項28に記載のコンピュータ可読記憶媒体。

Images