JP2016538752A - メディアストリーミング中の適応セット間の切替え - Google Patents

Abstract

メディアデータを取り出すためのデバイスは、第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すことと、第1の適応セットからのメディアデータを提示することと、第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、第2の適応セットの切替えポイントを含む第2の適応セットからメディアデータを取り出すことと、実際のプレイアウト時間が切替えポイントのプレイアウト時間以上になった後、第2の適応セットからのメディアデータを提示することとを行うように構成される1つまたは複数のプロセッサを含む。

Description

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

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

ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化されてもよい。ビデオデータは、国際標準化機構(ISO:International Organization for Standardization)ベースメディアファイルフォーマットおよびその拡張、たとえば、MP4ファイルフォーマットおよびadvanced video coding(AVC)ファイルフォーマットなどの、種々の規格のいずれかに準拠するビデオファイルへと組み立てられる場合がある。そのようなパケット化されたビデオデータは、ネットワークストリーミングを使用したコンピュータネットワークを介した送信のような、種々の方法で転送されてもよい。

R. Fielding他，RFC 2616，"Hypertext Transfer Protocol-HTTP/1.1"，Network Working Group，IETF，1999年6月

一般に、本開示は、たとえばネットワークを介したメディアデータのストリーミング中の適応セット間の切替えに関する技法について説明する。一般に、適応セットは、特定のタイプのメディアデータ、たとえば、ビデオ、オーディオ、タイムドテキスト(timed text)などを含む場合がある。従来、ネットワークを介したメディアストリーミングにおいて、適応セット内の表現間で切り替えるための技法が提供されてきたが、本開示の技法は一般に、適応セット自体の間で切り替えることを対象とする。

一例では、メディアデータを取り出す方法は、第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すステップと、第1の適応セットからのメディアデータを提示するステップと、第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、第2の適応セットの切替えポイントを含む第2の適応セットからのメディアデータを取り出すステップと、実際のプレイアウト時間が切替えポイントのプレイアウト時間以上になった後、第2の適応セットからのメディアデータを提示するステップとを含む。

別の例では、メディアデータを取り出すためのデバイスは、第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すことと、第1の適応セットからのメディアデータを提示することと、第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、第2の適応セットの切替えポイントを含む第2の適応セットからのメディアデータを取り出すことと、実際のプレイアウト時間が切替えポイントのプレイアウト時間以上になった後、第2の適応セットからのメディアデータを提示することとを行うように構成される1つまたは複数のプロセッサを含む。

別の例では、メディアデータを取り出すためのデバイスは、第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すための手段と、第1の適応セットからのメディアデータを提示するための手段と、第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、第2の適応セットの切替えポイントを含む第2の適応セットからのメディアデータを取り出すための手段と、要求に応答して、実際のプレイアウト時間が切替えポイントのプレイアウト時間以上になった後、第2の適応セットからのメディアデータを提示するための手段とを含む。

別の例では、コンピュータ可読記憶媒体は、実行されたときにプロセッサに、第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すことと、第1の適応セットからのメディアデータを提示することと、第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、第2の適応セットの切替えポイントを含む第2の適応セットからのメディアデータを取り出すことと、実際のプレイアウト時間が切替えポイントのプレイアウト時間以上になった後、第2の適応セットからのメディアデータを提示することとを行わせる命令を記憶している。

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

ネットワークを介してメディアデータをストリーミングするための技法を実施する例示的なシステムを示すブロック図である。 例示的なマルチディアコンテンツの要素を示す概念図である。 マルチメディアコンテンツの表現のセグメントに対応し得る例示的なビデオファイルの要素を示すブロック図である。 本開示の技法による、再生中に適応セット間で切り替えるための例示的な方法を示すフローチャートである。 本開示の技法による、再生中に適応セット間で切り替えるための例示的な方法を示すフローチャートである。 本開示の技法による、適応セット間で切り替えるための別の例示的な方法を示すフローチャートである。

一般に、本開示は、ネットワークを介した、オーディオデータおよびビデオデータのようなマルチメディアデータのストリーミングに関する技法について説明する。本開示の技法は、動的適応ストリーミングオーバーHTTP(DASH)に関連して使用されてもよい。本開示は、ネットワークストリーミングに関連して実行され得る様々な技法について説明し、それらの技法のいずれかまたはすべては、単独で、または任意の組合せで実施される場合がある。以下でより詳細に説明するように、ネットワークストリーミングを実行する様々なデバイスが、本開示の技法を実施するように構成されてもよい。

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

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

場合によっては、適応セットは、特定のタイプの含まれるコンテンツのために構成されることがある。たとえば、シーンのカメラアングルまたはカメラ視点ごとに少なくとも1つの適応セットが存在するように、ビデオデータの適応セットが形成される場合がある。別の例として、オーディオデータおよび/またはタイムドテキスト(たとえば、サブタイトルテキストデータ)の適応セットが様々な言語向けに提供される場合がある。すなわち、所望の言語ごとにオーディオ適応セットおよび/またはタイムドテキスト適応セットが存在してもよい。これにより、クライアントデバイスは、ユーザ選好、たとえば、オーディオおよび/またはビデオの言語選好に基づいて、適切な適応セットを選択することが可能になる場合がある。別の例として、クライアントデバイスは、ユーザ選好に基づいて1つまたは複数のカメラアングルを選択する場合がある。たとえば、ユーザは、特定のシーンの代替のカメラアングルを見たいと思う場合がある。別の例として、ユーザは、3次元(3D)ビデオにおいて比較的深い深度または比較的浅い深度を見たいと思う場合があり、その場合にユーザは、比較的近いカメラ視点または比較的遠いカメラ視点を有する2つ以上のビューを選択してもよい。

表現のためのデータは、一般にセグメントと呼ばれる個々のファイルに分割されてもよい。ファイルの各々は、特定のユニフォームリソースロケータ(URL)によってアドレス指定可能であってもよい。クライアントデバイスは、特定のURLにあるファイルを求めるGET要求を出して、ファイルを取り出す場合がある。本開示の技法によれば、クライアントデバイスは、たとえば、対応するサーバデバイスによって提供されたURLテンプレートに従って、URL経路自体の中に所望のバイト範囲の指示を含めることによって、GET要求を変更してもよい。

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

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

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

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

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

本開示は、たとえばDASHの技法を使用して、ストリーミングを介して取り出されているメディアデータの再生(プレイアウトとも呼ばれる)中に適応セット間で切り替えるための技法について説明する。たとえば、ストリーミング中に、ユーザは、オーディオおよび/もしくはサブタイトルの言語を切り替えること、代替のカメラアングルを見ること、または3Dビデオデータの深度の相対量を拡大もしくは縮小することを望む場合がある。ユーザに対応するために、クライアントデバイスは、第1の適応セットから一定量のメディアデータをすでに取り出した後、第1の適応セットと同じタイプのメディアデータを含む第2の異なる適応セットに切り替える場合がある。クライアントデバイスは、少なくとも、第2の適応セットの切替えポイントが復号されるまで、第1の適応セットから取り出されたメディアデータをプレイアウトし続けてもよい。たとえば、ビデオデータの場合、切替えポイントは、瞬時デコーダリフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA:clean random access)ピクチャ、または他のランダムアクセスポイント(RAP)ピクチャに対応する場合がある。

本開示の技法が特に、適応セット内の表現間にとどまらず、適応セット間で切り替えることを対象とすることを理解されたい。先行技法により、クライアントデバイスは、たとえば、利用可能なネットワーク帯域幅の変動に適応するために、共通の適応セットの表現間で切り替えることができるが、本開示の技法は、適応セット自体の間で切り替えることを対象とする。この適応セット切替えにより、ユーザは、後述するように、たとえば中断のない再生体験のおかげで、より快適な体験を享受することができる。従来、ユーザが異なる適応セットに切り替えたいと思った場合、メディアデータの再生を中断することが必要となり、不快なユーザエクスペリエンスが生じることになる。すなわち、ユーザは、再生を完全に停止し、異なる適応セット(たとえば、カメラアングルおよび/またはオーディオもしくはタイムドテキストの言語)を選択し、次いでメディアコンテンツの最初から再生を再開することが必要となる。以前のプレイ位置(すなわち、適応セットを切り替えるためにメディア再生が中断されたときの再生位置)に戻るために、ユーザは、トリックモードに入り(たとえば、早送りし)、以前のプレイ位置を手動で見つけることが必要となる。

その上、メディアデータの再生を中断することは、以前取り出されたメディアデータの放棄につながる。すなわち、ストリーミングメディアの取出しを実行するために、クライアントデバイスは通常、現在の再生位置にかなり先んじてメディアデータをバッファリングする。このようにして、適応セットの表現間の切替えが(たとえば、帯域幅の変動に起因して)発生する必要がある場合、再生を中断することなく切替えが発生するようにバッファに記憶された十分なメディアデータがある。しかしながら、上述のシナリオでは、バッファリングされたメディアデータは完全に廃棄されることになる。特に、現在の適応セットのバッファリングされたメディアデータが処分されることになるだけではなく、切り替えられていない他の適応セットのバッファリングされたメディアデータも処分されることになる。たとえば、ユーザが英語のオーディオからスペイン語のオーディオに切り替えたいと思った場合、再生が中断されることになり、英語のオーディオと対応するビデオデータの両方が処分されることになる。次いで、スペイン語のオーディオの適応セットに切り替えた後、クライアントデバイスは、まさに以前処分されたビデオデータを再び取り出すことになる。

本開示の技法は、一方で、たとえば、再生を中断することのない、メディアストリーミング中の適応セット間の切替えを可能にする。たとえば、クライアントデバイスは、第1の適応セット(およびより詳細には、第1の適応セットの表現)からのメディアデータを取り出した場合があり、第1の適応セットからのメディアデータを提示している場合がある。第1の適応セットからのメディアデータを提示している間、クライアントデバイスは、第2の異なる適応セットに切り替える要求を受信する場合がある。この要求は、ユーザからの入力に応答して、クライアントデバイスによって実行されたアプリケーションから発生する場合がある。

たとえば、ユーザは、異なる言語のオーディオに切り替えたいと思う場合があり、その場合にユーザは、オーディオ言語を変更する要求を出すことがある。別の例として、ユーザは、異なる言語のタイムドテキストに切り替えたいと思う場合があり、その場合にユーザは、タイムドテキスト(たとえば、サブタイトル)言語を変更する要求を出すことがある。また別の例として、ユーザは、カメラアングルを切り替えたいと思う場合があり、その場合にユーザは、カメラアングルを変更する要求を出すことがある(そして各適応セットは、特定のカメラアングルに対応することがある)。カメラアングルを切り替えることは、単に異なる視点からビデオを見ること、または、たとえば3D再生中に表示される相対深度を拡大もしくは縮小するために、第2の(もしくは他の追加の)ビューアングルを変更することである場合がある。

要求に応答して、クライアントデバイスは、第2の適応セットからのメディアデータを取り出してもよい。特に、クライアントデバイスは、第2の適応セットからの表現からのメディアデータを取り出してもよい。取り出されたメディアデータは、切替えポイント(たとえば、ランダムアクセスポイント)を含む場合がある。クライアントデバイスは、実際のプレイアウト時間が第2の適応セットの切替えポイントのプレイアウト時間以上になるまで、第1の適応セットからのメディアデータを提示するのを続けてもよい。このようにして、クライアントデバイスは、第1の適応セットのバッファリングされたメディアデータを利用するとともに、第1の適応セットから第2の適応セットへの切替え中に再生を中断するのを回避してもよい。言い換えれば、クライアントデバイスは、実際のプレイアウト時間が第2の適応セットの切替えポイントのプレイアウト時間以上になった後、第2の適応セットからのメディアデータを提示するのを開始してもよい。

適応セット間で切り替えるとき、クライアントデバイスは、第2の適応セットの切替えポイントの位置を判断してもよい。たとえば、クライアントデバイスは、メディアプレゼンテーション記述(MPD)などの、第2の適応セットにおける切替えポイントの位置を規定しているマニフェストファイルを参照する場合がある。通常、共通の適応セットの表現は、共通の適応セットの表現の各々におけるセグメント境界が同じ再生時間に発生するように、時間的に合わせられる。しかしながら、そのようなことは、異なる適応セットには当てはまらない。すなわち、共通の適応セットの表現のセグメントは時間的に合わせられてもよいが、異なる適応セットの表現のセグメントは、必ずしも時間的に合わせられるとは限らない。したがって、ある適応セットの表現から別の適応セットの表現に切り替えるときに、切替えポイントの位置を判断することは困難であり得る。

したがって、クライアントデバイスは、第1の適応セットの表現(たとえば、現在の表現)と第2の適応セットの表現の両方についてのセグメント境界を判断するためにマニフェストファイルを参照してもよい。セグメント境界は一般に、セグメントに含まれるメディアデータの再生時間の開始および終了を指す。セグメントは必ずしも異なる適応セット間で時間的に合わせられるとは限らないので、クライアントデバイスは、異なる適応セットの表現からの、時間的に重複する2つのセグメントのメディアデータを取り出す必要がある場合がある。

クライアントデバイスは、第2の適応セットに切り替える要求が受信されたときの再生時間に最も近い切替えポイントを第2の適応セット中に見つけようと試みる場合もある。通常、クライアントデバイスは、第2の適応セットに切り替える要求が受信されたときよりも再生時間の点で後ろにある切替えポイントを第2の適応セット中に見つけようと試みる場合がある。しかしながら、場合によっては、切替えポイントは、適応セット間で切り替える要求が受信されたときの再生時間から容認できないほど遠い位置で生じることがあり、これは通常、切り替えられる適応セットが(たとえば、サブタイトルの)タイムドテキストを含むときのみである。そのような場合、クライアントデバイスは、切り替える要求が受信されたときよりも再生時間の点で前にある切替えポイントを要求してもよい。

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

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

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

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

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

各表現はまた、1つまたは複数のメディア構成要素を含んでもよく、各メディア構成要素は、オーディオ、ビデオ、および/またはタイムドテキスト(たとえば、クローズドキャプションのための)のような、1つの個々のメディアタイプの符号化バーションに相当する場合がある。メディア構成要素は、1つの表現内の連続的なメディアセグメントの境界にわたって、時間的に連続的である場合がある。したがって、表現は、個々のファイルまたはセグメントのシーケンスに対応してもよく、その各々が、同じコーディングおよびレンダリングの特性を含んでもよい。

本開示の技法は、いくつかの例では、1つまたは複数の利益を提供する場合がある。たとえば、本開示の技法は、適応セット間の切替えを可能にし、それによりユーザは、オンザフライで同じタイプのメディア間で切り替えることができる場合がある。すなわち、適応セット間で変更するために再生を停止するのではなく、ユーザは、あるタイプのメディア(たとえば、オーディオ、タイムドテキスト、またはビデオ)の適応セット間で切り替えるよう要求する場合があり、クライアントデバイスはシームレスに切替えを実行する場合がある。これにより、バッファリングされたメディアデータを廃棄することを回避する一方で、再生中の隙間または休止も回避する場合がある。したがって、本開示の技法は、より満足できるユーザエクスペリエンスをもたらす一方で、ネットワーク帯域幅の過剰な消費を回避する場合もある。

図1は、ネットワークを介してメディアデータをストリーミングするための技法を実施する例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40を含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74もしくは別のネットワークによって結合されてもよく、または直接通信可能に結合されてもよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを構成してもよい。いくつかの例では、コンテンツ準備デバイス20は、サーバデバイス60を含む複数のサーバデバイスに、準備されたコンテンツを配信する場合がある。同様に、いくつかの例では、クライアントデバイス40は、サーバデバイス60を含む複数のサーバデバイスと通信する場合がある。

以下でより詳しく説明するように、クライアントデバイス40は、本開示のいくつかの技法を実行するように構成されてもよい。たとえば、クライアントデバイス40は、メディアデータの再生中に適応セット間で切り替えるように構成されてもよい。クライアントデバイス40は、ユーザが特定のタイプのメディア、たとえばオーディオ、ビデオおよびまたはタイムドテキストの適応セット間で切り替える要求を出すことができるユーザインターフェースを提供してもよい。このようにして、クライアントデバイス40は、同じタイプのメディアデータの適応セット間で切り替える要求を受信する場合がある。たとえば、ユーザは、第1の言語のオーディオデータまたはタイムドテキストデータを含む適応セットから、第2の異なる言語のオーディオデータまたはタイムドテキストデータを含む適応セットに切り替えるよう要求する場合がある。別の例として、ユーザは、第1のカメラアングルのビデオデータを含む適応セットから、第2の異なるカメラアングルのビデオデータを含む適応セットに切り替えるよう要求する場合がある。

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

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

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

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

多くのビデオコーディング規格のように、H.264/AVCは、シンタックス、セマンティクス、エラーのないビットストリームのための復号処理を定義し、これらのいずれもが、あるプロファイルまたはレベルに準拠する。H.264/AVCはエンコーダを規定しないが、エンコーダは、生成されたビットストリームがデコーダのための規格に準拠するのを保証する役割を課される。ビデオコーディング規格の文脈では、「プロファイル」は、アルゴリズム、機能、またはツールのサブセット、およびこれらに適用される制約に相当する。H.264規格によって定義されるように、たとえば、「プロファイル」は、H.264規格によって規定される全体のビットストリームシンタックスのサブセットである。「レベル」は、たとえば、デコーダメモリおよび計算のような、デコーダのリソース消費の制限に相当し、これは、ピクチャの解像度、ビットレート、およびマクロブロック(MB)処理速度に関連する。プロファイルは、profile_idc(プロファイルインジケータ)値によってシグナリングされてもよいが、レベルは、level_idc(レベルインジケータ)値によってシグナリングされてもよい。

たとえば、所与のプロファイルのシンタックスによって課される範囲内で、復号されるピクチャの規定されたサイズのようなビットストリーム中のシンタックス要素のとる値に応じて、エンコーダおよびデコーダの性能に大きい変動を要求することが依然として可能であることを、H.264規格は認める。多くの用途において、特定のプロファイル内でのシンタックスのすべての仮想的な使用を扱うことが可能なデコーダを実装するのは、現実的でも経済的でもないことを、H.264規格はさらに認める。したがって、H.264規格は、ビットストリーム中のシンタックス要素の値に課される制約の規定されたセットとして、「レベル」を定義する。これらの制約は、値に対する単純な制限であってもよい。あるいは、これらの制約は、値の算術的な組合せの制約の形式(たとえば、1秒当たりに復号されるピクチャの数と、ピクチャの高さと、ピクチャの幅との積)をとってもよい。個々の実装形態が、サポートされるプロファイルごとに異なるレベルをサポートしてもよいことを、H.264規格はさらに規定する。マルチメディアコンテンツの様々な表現が、H.264内の様々なプロファイルおよびコーディングのレベルに対応するために、さらに、来るべきHigh Efficiency Video Coding(HEVC)規格のような他のコーディング規格に対応するために、提供されてもよい。

プロファイルに準拠するデコーダは普通、プロファイル中で定義されるすべての機能をサポートする。たとえば、コーディング機能として、Bピクチャコーディングは、H.264/AVCのベースラインプロファイルではサポートされないが、H.264/AVCの他のプロファイルではサポートされる。特定のレベルに準拠するデコーダは、レベル中で定義された制限を超えるリソースを要求しない、あらゆるビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、互換性のために有用である場合がある。たとえば、ビデオ送信の間、プロファイルとレベルの定義のペアが、送信セッション全体に対して取り決められ合意されてもよい。より具体的には、H.264/AVCにおいて、レベルは、たとえば、処理される必要があるブロックの数、復号されたピクチャバッファ(DPB:decoded picture buffer)のサイズ、コード化ピクチャバッファ(CPB:coded picture buffer)のサイズ、垂直方向の運動ベクトルの範囲、2つの連続するMB当たりの運動ベクトルの最大の数に対する制限、および、Bブロックが8×8ピクセルよりも小さいサブブロック区画を有することができるかどうかを定義してもよい。このようにして、デコーダは、デコーダがビットストリームを適切に復号することが可能であるかどうかを判断する場合がある。

ITU-T H.261、H.262、H.263、MPEG-1、MPEG-2、H.264/MPEG-4 part 10、および来るべきHigh Efficiency Video Coding(HEVC)規格のようなビデオ圧縮規格は、時間的冗長性を低減するために、運動補償時間的予測を利用する。ビデオエンコーダ28のようなエンコーダは、いくつかの以前に符号化されたピクチャ(本明細書ではフレームとも呼ばれる)からの運動補償予測を使用して、運動ベクトルに従って現在のコード化ピクチャを予測する場合がある。通常のビデオコーディングには、3つの主要なピクチャタイプがある。それらは、イントラコード化ピクチャ(「Iピクチャ」または「Iフレーム」)、予測されたピクチャ(「Pピクチャ」または「Pフレーム」)、および双方向予測されたピクチャ(「Bピクチャ」または「Bフレーム」)である。Pピクチャは、時間的順序で現在のピクチャの前にある参照ピクチャを使用してもよい。Bピクチャでは、Bピクチャの各ブロックは、1つまたは2つの参照ピクチャから予測される場合がある。これらの参照ピクチャは、時間的順序で現在のピクチャの前または後に位置し得る。

パラメータセットは一般に、シーケンスパラメータセット(SPS)中にシーケンス層ヘッダ情報を含み、ピクチャパラメータセット(PPS)中に頻繁には変化しないピクチャ層ヘッダ情報を含む。パラメータセットがあれば、この頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要がなく、したがってコーディング効率が向上する場合がある。さらに、パラメータセットの使用が、ヘッダ情報の帯域外送信を可能にする場合があり、エラーの復元を達成するための冗長な送信の必要がなくなる。帯域外送信では、パラメータセットのNALユニットが、他のNALユニットとは異なるチャネルで送信される。

図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ユニットであってもよい。

カプセル化ユニット30は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数の表現のためのデータを、出力インターフェース32に提供してもよい。出力インターフェース32は、ユニバーサルシリアルバス(USB)インターフェースのような記憶媒体へ書き込むためのネットワークインターフェースもしくはインターフェース、CDもしくはDVDのライターもしくはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを含んでもよい。カプセル化ユニット30は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース32に提供してもよく、出力インターフェース32は、ネットワーク送信、直接送信または記憶媒体を介してデータをサーバデバイス60に送信してもよい。図1の例では、サーバデバイス60は、各々がそれぞれのマニフェストファイル66および1つまたは複数の表現68A〜68N(表現68)を含む様々なマルチメディアコンテンツ64を記憶する、記憶媒体62を含む。本開示の技法によれば、マニフェストファイル66の一部分は、別個の位置、たとえば、記憶媒体62または別の記憶媒体の位置、場合によってはプロキシデバイスのようなネットワーク74の別のデバイスの位置に記憶されてもよい。

表現68は、適応セットへと分割されてもよい。すなわち、表現68の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、表示の数、セグメントのファイルフォーマット、たとえば話者による、復号され提示されるべき表現および/またはオーディオデータとともに表示されるべきテキストの言語または他の特性を特定し得るテキストタイプ情報、カメラアングルまたは適応セット中の表現のシーンの現実世界のカメラ視点を表し得るカメラアングル情報、特定の視聴者に対するコンテンツの適切性を表すレーティング情報などのような、特性のそれぞれの共通のセットを含んでもよい。

マニフェストファイル66は、特定の適応セットに対応する表現68のサブセットを示すデータ、さらには、適応セットの共通の特性を含んでもよい。マニフェストファイル66はまた、適応セットの個々の表現のための、ビットレートのような個々の特性を表すデータを含んでもよい。このようにして、適応セットは、簡略化されたネットワーク帯域幅の適応を行ってもよい。適応セット中の表現は、マニフェストファイル66の適応セット要素の子要素を使用して示されてもよい。

サーバデバイス60は、要求処理ユニット70およびネットワークインターフェース72を含む。いくつかの例では、サーバデバイス60は、ネットワークインターフェース72を含む、複数のネットワークインターフェースを含んでもよい。さらに、サーバデバイス60の機能のいずれかまたはすべてが、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスのような、コンテンツ配信ネットワークの他のデバイス上で実装されてもよい。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ64のデータをキャッシュし、サーバデバイス60の構成要素に実質的に準拠する構成要素を含む場合がある。一般に、ネットワークインターフェース72は、ネットワーク74を介してデータを送信および受信するように構成される。

要求処理ユニット70は、記憶媒体62のデータに対するネットワーク要求を、クライアントデバイス40のようなクライアントデバイスから受信するように構成される。たとえば、要求処理ユニット70は、R. Fielding他による、RFC 2616，“Hypertext Transfer Protocol-HTTP/1.1”，Network Working Group，IETF，1999年6月で説明されるような、ハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装する場合がある。すなわち、要求処理ユニット70は、HTTP GET要求または部分GET要求を受信して、それらの要求に応答してマルチメディアコンテンツ64のデータを提供するように構成されてもよい。要求は、たとえば、セグメントのURLを使用して、表現68のうちの1つのセグメントを指定してもよい。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を指定する場合がある。いくつかの例では、セグメントのバイト範囲は、部分GET要求を使用して指定される場合がある。他の例では、本開示の技法によれば、セグメントのバイト範囲は、たとえば、一般的なテンプレートに従って、セグメントのURLの一部として指定される場合がある。

要求処理ユニット70はさらに、表現68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成されてもよい。いずれの場合でも、要求処理ユニット70は、要求されたデータをクライアントデバイス40のような要求側デバイスに提供するために、要求を処理するように構成されてもよい。さらに、要求処理ユニット70は、バイト範囲を指定するURLを構成するためのテンプレートを生成し、テンプレートが必須であるか、それとも任意選択であるかを示す情報を提供し、任意のバイト範囲が受け入れられるか、それとも指定のバイト範囲セットのみが許容されるかを示す情報を提供するように構成されてもよい。指定のバイト範囲のみが許容されるとき、要求処理ユニット70は、許容されたバイト範囲の指示を提供してもよい。

図1の例で示されるように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応し得るマニフェストファイル66を含む。マニフェストファイル66は、様々な代替の表現68(たとえば、品質が異なるビデオサービス)の説明を含んでもよく、この説明は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の説明のための特性を含んでもよい。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、表現68のセグメントにどのようにアクセスするかを決定してもよい。

クライアントデバイス40のウェブアプリケーション52は、クライアントデバイス40のハードウェアに基づく処理ユニットによって実行されるウェブブラウザ、または、そのようなウェブブラウザへのプラグインを含んでもよい。ウェブアプリケーション52への言及は、ウェブブラウザ、スタンドアロンのビデオプレーヤ、またはウェブブラウザへの再生プラグインを組み込むウェブブラウザなどのウェブアプリケーションのいずれかを含むものとして、全般に理解されるべきである。ウェブアプリケーション52は、クライアントデバイス40の構成データ(図示せず)を検索して、クライアントデバイス40のビデオデコーダ48の復号能力およびビデオ出力44のレンダリング能力を判断する場合がある。

構成データはまた、クライアントデバイス40のユーザによって選択されるデフォルト言語選好、たとえば、クライアントデバイス40のユーザによって設定される深度の選好に対する1つもしくは複数のデフォルトカメラ視点、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含んでもよい。ウェブアプリケーション52は、たとえば、HTTP GET要求および部分GET要求を出すように構成されたウェブブラウザまたはメディアクライアントを含んでもよい。ウェブアプリケーション52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応する場合がある。いくつかの例では、ウェブアプリケーション52に関して説明した機能のすべてまたは一部分は、ハードウェア、もしくはハードウェアの組合せ、ソフトウェア、および/またはファームウェアで実装されてよく、必須のハードウェアが、ソフトウェアまたはファームウェアのための命令を実行するために提供される場合がある。

ウェブアプリケーション52は、クライアントデバイス40の復号能力およびレンダリング能力を、マニフェストファイル66の情報によって示される表現68の特性と比較してもよい。ウェブアプリケーション52は最初に、マニフェストファイル66の少なくとも一部分を検索し、表現68の特性を判断してもよい。たとえば、ウェブアプリケーション52は、1つまたは複数の適応セットの特性を説明する、マニフェストファイル66の一部分を要求する場合がある。ウェブアプリケーション52は、クライアントデバイス40のコーディング能力およびレンダリング能力によって満たされ得る特性を有する、表現68のサブセット(たとえば、適応セット)を選択してもよい。ウェブアプリケーション52は次いで、適応セット中の表現のビットレートを判断し、ネットワーク帯域幅の現在利用可能な量を判断し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの1つからセグメント(またはバイト範囲)を取り出してもよい。

一般に、表現のビットレートが高くなると、ビデオ再生の品質が高くなる一方、表現のビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、ビデオ再生の品質が十分なものになる場合がある。したがって、利用可能なネットワーク帯域幅が比較的高いときには、ウェブアプリケーション52は、ビットレートが比較的高い表現からデータを取り出してもよく、利用可能なネットワーク帯域幅が低いときには、ウェブアプリケーション52は、ビットレートが比較的低い表現からデータを取り出してもよい。このようにして、クライアントデバイス40は、ネットワーク74を介してマルチメディアデータをストリーミングする一方で、ネットワーク74の変化するネットワーク帯域幅の利用可能性に適応する場合もある。

上述のように、いくつかの例では、クライアントデバイス40は、ユーザ情報を、たとえば、サーバデバイス60またはコンテンツ配信ネットワークの他のデバイスに提供する場合がある。ユーザ情報は、ブラウザのクッキーの形式であってもよく、または他の形式であってもよい。ウェブアプリケーション52は、たとえば、ユーザ識別子、ユーザ選好、および/またはユーザの人口統計学的な情報を収集し、そのようなユーザ情報をサーバデバイス60に提供する場合がある。ウェブアプリケーション52は次いで、ターゲティング広告のメディアコンテンツからのデータを再生中に要求されたメディアコンテンツのメディアデータへと挿入するために使用すべき、ターゲティング広告のメディアコンテンツに関連付けられるマニフェストファイルを受信する場合がある。このデータは、マニフェストファイル、またはマニフェストサブファイルに対する要求の結果として直接受信されてよく、あるいは、このデータは、代替的なマニフェストファイルまたはサブファイルへのHTTPリダイレクトを介して(ユーザの人口統計学的な情報および他のターゲティング情報を記憶するために使用される、提供されたブラウザのクッキーに基づいて)受信され得る。

時々、クライアントデバイス40のユーザは、キーボード、マウス、スタイラス、タッチスクリーンインターフェース、ボタン、または他のインターフェースのような、クライアントデバイス40のユーザインターフェースを使用してウェブアプリケーション52と対話して、マルチメディアコンテンツ64のようなマルチメディアコンテンツを要求する場合がある。ユーザからのそのような要求に応答して、ウェブアプリケーション52は、たとえば、クライアントデバイス40の復号能力およびレンダリング能力に基づいて、表現68のうちの1つを選択してもよい。表現68のうちの選択された1つのデータを取り出すために、ウェブアプリケーション52は続いて、表現68のうちの選択された1つの具体的なバイト範囲を要求してもよい。このようにして、1つの要求を通じて完全なファイルを受信するのではなく、ウェブアプリケーション52は、複数の要求を通じてファイルの一部分を順次受信してもよい。

いくつかの例では、サーバデバイス60は、クライアントデバイス40などのクライアントデバイスによるURLのための一般的なテンプレートを指定する場合がある。そして、クライアントデバイス40はテンプレートを使用して、HTTP GET要求のためのURLを構成してもよい。DASHプロトコルでは、URLは、各セグメント内でそれらを明記すること、またはURLTemplateを与えること、のいずれかによって形成され、URLTemplateは、(DASHの現在のドラフトのTable 9によって説明されている)$$、$RepresentationID$、$Index$、$Bandwidth$、または$Time$など、1つまたは複数の周知のパターンを含むURLである。URL要求を行う前に、クライアントデバイス40は、取り出されるべき最終URLを生成するために、“$$”などのテキスト列、表現id、セグメントのインデックスなどを、URLTemplateに置き換えてもよい。本開示は、DASHファイルのSegmentInfoDefault要素に追加され得るいくつかの追加のXMLフィールドを、たとえば、マルチメディアコンテンツ64のマニフェストファイル66などのマルチメディアコンテンツのMPDにおいて定義する。

ウェブアプリケーション52によってサーバデバイス60に出された要求に応答して、ネットワークインターフェース54は、選択された表現の受信されたセグメントのデータを受信して、ウェブアプリケーション52に提供してもよい。ウェブアプリケーション52は次いで、セグメントをカプセル化解除ユニット50に提供してもよい。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送信してもよい。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送信し、一方でビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号したビデオデータを、ビデオ出力44に送信する。

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

このようにして、クライアントデバイス40は、メディアデータを取り出すためのデバイスの一例を表し、このデバイスは、第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すことと、第1の適応セットからのメディアデータを提示することと、第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、第2の適応セットの切替えポイントを含む第2の適応セットからのメディアデータを取り出すことと、実際のプレイアウト時間が切替えポイントのプレイアウト時間以上になった後、第2の適応セットからのメディアデータを提示することとを行うように構成された1つまたは複数のプロセッサを含んでもよい。

本開示の技法は、以下の文脈において、すなわち、期間P1についてデータが完全にダウンロードされており、次の期間P2においてダウンロードが開始されている場合に適用されてもよい。一例では、データバッファは、P1についてのデータに相当する約20秒の再生およびP2についてのデータに相当する約5秒の再生を含み、ユーザは現在、P1のコンテンツを見ている。このときに、ユーザは、適応セット変更、たとえば、英語からフランス語へのオーディオの変更を開始する。従来の技法では、ソース構成要素(たとえば、ウェブアプリケーション52)がこの変更をP2についてのみ反映した場合に、ユーザが変更を約20秒後に観測することになり、好ましくないユーザエクスペリエンスとなるという点で、問題が生じることがある。一方、変更がP1とP2の両方において反映された場合、P2における変更がP2の開始時に正確に反映されてはいない可能性がある。本開示の技法は、(サーバデバイス60の要求処理ユニット70などの)ソース構成要素が変更を期間P1と期間P2の両方において反映してもよく、P2の開始から変更を反映するために、ソース構成要素がP2の開始時間に対してP2においてSEEKイベントを出してもよいという点で、解決策を提供する場合がある。そのようなSEEKイベントは、ソース構成要素の側に追加の同期論理を伴ってもよい。

本開示の技法はまた、以下の文脈、すなわち、ユーザが適応セット変更を急速に開始し、特に、適応セットAを適応セットBに置き換え、次いで間断なく適応セットCに置き換える場合に適用されてもよい。AからBへの変更が処理されるときに、適応セットAがクライアントデバイスの内部状態から除去されるという点で問題が生じる場合がある。そのため、BからCへの変更が出されたとき、Bのダウンロードされた位置に対して変更が実行される。適応セットタイプ(AUDIO、VIDEOなど)を示す引数として「タイプ」を受け入れ、(たとえば、再生時間の点で)その適応セットの再生位置を提供する新しいAPI、たとえばGetCurrentPlaybackTime(タイプ)をソース構成要素が提供してもよいという点で、本開示の技法は解決策を提供する場合がある。この新しいAPIは、切替え時間を決定するために使用されてもよい。切替え時間は、適応セットのプレイ開始時間の前であってもよい。たとえば、Bの開始時間は、再生時間(p-time)10秒であってもよいが、タイプに基づく再生位置は時間7秒であってもよい。バッファ計算論理が影響を受ける場合があるので、PKERコアアルゴリズムが変更されてもよい。

あるいは、ソース構成要素は、適応セットが置き換えられたときに適切なサンプルを与えるための論理をすでに含んでいる場合がある。たとえば、クライアントデバイスは、適応セットBからのサンプルを時間10秒後にのみ与え、その前には与えないように構成されてもよい。置き換え動作が行われたとき、ソース構成要素は、置き換えられている適応セットについて再生が開始されたかどうかを確認してもよい。BからCへの適応セット切替えの場合、適応セットBについての再生はまだ開始されていない場合がある。再生が開始されていない場合、ソース構成要素は、古い適応セットについてレンダラにいかなるデータサンプルも与えるのを回避し、以下のコマンドを出してもよい。REMOVE(古い適応セット)[この場合、REMOVE B]、およびADD(新しい適応セット)[この場合、ADD C]。ソース構成要素への影響は最小限とすべきである。ソース構成要素は、レンダラ(たとえば、オーディオ出力42またはビデオ出力44)が適応セットBの切替えポイントで/切替えポイントを越えてサンプルを要求した場合に、適応セットAの再生が進むようにしてもよい。ソース構成要素はまた、Aに対するCの開始位置を確認してもよい。

また別の例示的な文脈では、ユーザは、適応セットAから適応セットBに切り替え、次いで急速に適応セットAに戻る場合がある。この場合、クライアントデバイス40は、ユーザに適応セットBのサンプルを提示するのを回避してもよい。本開示の技法によれば、ソース構成要素は、再生がBにおいて開始されていないことを検出し、上述のシナリオと同様に、Bのサンプルがレンダラに到着するのを阻止してもよい。このようにして、ソース構成要素は以下のコマンドを出してもよい。REMOVE B、そして直ちにADD A。Aが追加されたとき、Aの開始時間を再び決定するために全体的再生統計が使用されてもよく、この開始時間は、すでに存在するデータ内に入る可能性がある。このシナリオでは、ソース構成要素は、現在利用可能な時間まで、SELECT要求を拒否してもよい。

たとえば、Aのデータが時間30秒までダウンロードされた(そして、再生は現在、0秒にある)と仮定する。ユーザは、適応セットAを適応セットBに置き換える場合があり、切替え時間は2秒にあった場合がある。2〜30秒のAのデータが取り除かれる場合がある。しかしながら、Aが再び追加されたとき、時間0において開始し、SELECT要求を出すことになる。ソース構成要素は、このSELECT要求を拒否してもよい。次いで、時間2秒において開始し、メタデータが要求されてもよい。ソース構成要素は、時間2秒において選択を承認することになる。

図2は、例示的なマルチメディアコンテンツ100の要素を示す概念図である。マルチメディアコンテンツ100は、マルチメディアコンテンツ64(図1)、または記憶媒体62に記憶された別のマルチメディアコンテンツに対応する場合がある。図2の例では、マルチメディアコンテンツ100は、メディアプレゼンテーション記述(MPD)102および適応セット104、120を含む。適応セット104、120は、それぞれの複数の表現を含む。この例では、適応セット104は、表現106A、106Bなど(表現106)を含み、一方で適応セット120は、表現122A、122Bなど(表現122)を含む。表現106Aは、任意選択のヘッダデータ110およびセグメント112A〜112N(セグメント112)を含み、一方で表現106Bは、任意選択のヘッダデータ114およびセグメント116A〜116N(セグメント116)を含む。同様に、表現122は、それぞれの任意選択のヘッダデータ124、128を含む。表現122Aは、セグメント126A〜126M(セグメント126)を含み、一方で表現122Bは、セグメント130A〜130M(セグメント130)を含む。文字Nが、便宜的に、表現106の各々における最後のセグメントを指定するために使用される。文字Mが、表現122の各々における最後のセグメントを指定するために使用される。MおよびNは、異なる値または同じ値を有する場合がある。

同じ適応セットのセグメントが時間的に合わせられてもよいことを示すために、セグメント112、116は、同じ長さを有するものとして示されている。同様に、セグメント126、130は、同じ長さを有するものとして示されている。しかしながら、異なる適応セットのセグメントは必ずしも時間的に合わせられるとは限らないことを示すために、セグメント112、116は、セグメント126、130とは異なる長さを有する。

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

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

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

セグメント112、116の各々は、固有のユニフォームリソース識別子(URI)、たとえばユニフォームリソースロケータ(URL)に関連付けられてもよい。したがって、セグメント112、116の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能である場合がある。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント112または116を取り出してもよい。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント112または116の特定のバイト範囲を取り出す場合がある。

本開示の技法によれば、2つ以上の適応セットが同じタイプのメディアコンテンツを含む場合がある。しかしながら、適応セットの実際のメディアは異なる場合がある。たとえば、適応セット104、120はオーディオデータを含む場合がある。すなわち、セグメント112、116、126、130は、符号化オーディオデータを表すデータを含む場合がある。しかしながら、適応セット104が英語のオーディオデータに対応する場合があるのに対して、適応セット120はスペイン語のオーディオデータに対応する場合がある。別の例として、適応セット104、120は、符号化ビデオデータを表すデータを含む場合があるが、適応セット104が第1のカメラアングルに対応する場合があるのに対して、適応セット120は第2の異なるカメラアングルに対応する場合がある。また別の例として、適応セット104、120は、(たとえば、サブタイトルの)タイムドテキストを表すデータを含む場合があるが、適応セット104が英語のタイムドテキストを含む場合があるのに対して、適応セット120はスペイン語のタイムドテキストを含む場合がある。もちろん、英語およびスペイン語は単に例として提供されており、一般に、オーディオデータおよび/またはタイムドテキストデータを含む適応セットに任意の言語が含まれてもよく、2つ以上の代替の適応セットが提供されてもよい。

本開示の技法によれば、ユーザが最初に適応セット104を選択してもよい。あるいは、クライアントデバイス40が、たとえば、デフォルトユーザ選好などの構成データに基づいて、適応セット104を選択してもよい。いずれの場合も、クライアントデバイス40は最初に、適応セット104の表現106のうちの1つからデータを取り出してもよい。特に、クライアントデバイス40は、表現106のうちの1つの表現の1つまたは複数のセグメントからデータを取り出すよう求める要求を出してもよい。たとえば、利用可能なネットワーク帯域幅の量が表現106Aのビットレートと最もよく対応すると仮定すると、クライアントデバイス40は、セグメント112のうちの1つまたは複数からデータを取り出してもよい。帯域幅の変動に応答して、クライアントデバイス40は、表現106のうちの別のもの、たとえば表現106Bに切り替えてもよい。すなわち、利用可能なネットワーク帯域幅の拡大または縮小の後、クライアントデバイス40は帯域幅適応技法を利用して、セグメント116のうちの1つまたは複数からデータを取り出し始めてもよい。

表現106Aが現在の表現であり、クライアントデバイス40が表現106Aの最初から開始すると仮定すると、クライアントデバイス40は、セグメント112Aのデータを取り出すための1つまたは複数の要求を出してもよい。たとえば、クライアントデバイス40は、セグメント112Aのデータを取り出すためのHTTP GET要求、またはセグメント112Aの連続部分を取り出すためのいくつかのHTTP部分GET要求を出してもよい。セグメント112Aのデータを取り出すための1つまたは複数の要求を出した後、クライアントデバイス40は、セグメント112Bのデータを取り出すための1つまたは複数の要求を出してもよい。特に、クライアントデバイス40は、表現106Aのデータを、この例では、クライアントデバイス40がバッファ内のデータの復号および提示を開始できるほどの十分な量のデータがバッファリングされるまで、蓄積してもよい。

上記で説明したように、クライアントデバイス40は、ネットワーク帯域幅の利用可能量を周期的に判断し、必要ならば、適応セット104の表現106間の帯域幅適応を実行してもよい。通常、表現106のセグメントが時間的に合わせられるので、そのような帯域幅適応は簡略化される。たとえば、セグメント112Aおよびセグメント116Aは、同じ相対再生時間に開始し終了するデータを含む。したがって、利用可能なネットワーク帯域幅の変動に応答して、クライアントデバイス40は、セグメント境界において表現106間で切り替えてもよい。

本開示の技法によれば、クライアントデバイス40は、適応セットを、たとえば適応セット104から適応セット120に切り替える要求を受信する場合がある。たとえば、適応セット104が英語によるオーディオデータまたはタイムドテキストデータを含み、適応セット120がスペイン語によるオーディオデータまたはタイムドテキストデータを含む場合、クライアントデバイス40は、特定の時間には英語よりもスペイン語の方が好ましいとユーザが判断した後に、適応セット104から適応セット120に切り替える要求をユーザから受信する場合がある。別の例として、適応セット104が第1のカメラアングルからのビデオデータを含み、適応セット120が第2の異なるカメラアングルからのビデオデータを含む場合、クライアントデバイス40は、特定の時間には第1のカメラアングルよりも第2のカメラアングルの方が好ましいとユーザが判断した後に、適応セット104から適応セット120に切り替える要求をユーザから受信する場合がある。

適応セット104から適応セット120への切替えをもたらすために、クライアントデバイス40は、MPD102のデータを参照してもよい。MPD102のデータは、表現122のセグメントの開始および終了の再生時間を示す場合がある。クライアントデバイス40は、適応セット間で切り替える要求が受信されたときの再生時間を判断し、この判断された再生時間を、適応セット120の次の切替えポイントの再生時間と比較してもよい。次の切替えポイントの再生時間が、切替え要求が受信されたときの判断された再生時間に十分に近い場合、クライアントデバイス40は、ネットワーク帯域幅の利用可能量を判断し、ネットワーク帯域幅の利用可能量によってサポートされるビットレートを有する表現122のうちの1つを選択し、次いで、切替えポイントを含む表現122のうちの選択された1つのデータを要求してもよい。

たとえば、クライアントデバイス40がセグメント112Bの再生中に適応セット104と適応セット120との間で切り替える要求を受信すると仮定する。クライアントデバイス40は、表現122Aにおけるセグメント126Bの直後にくるセグメント126Cが、セグメント126Cの(時間的な再生時間の点で)最初に切替えポイントを含むと判断する場合がある。特に、クライアントデバイス40は、MPD102のデータから、セグメント126Cの切替えポイントの再生時間を判断してもよい。その上、クライアントデバイス40は、セグメント126Cの切替えポイントが、適応セット間で切り替える要求が受信されたときの再生時間の後にくると判断する場合がある。さらに、クライアントデバイス40は、表現122Aが、ネットワーク帯域幅の判断された量に最も適した(たとえば、利用可能なネットワーク帯域幅の判断された量を上回らない、適応セット120中のすべての他の表現122のビットレートよりも高い)ビットレートを有すると判断する場合がある。

上述の例では、クライアントデバイス40は、適応セット104の表現106Aのセグメント112Bのバッファリングされたデータを有している場合がある。しかしながら、適応セット間で切り替える要求に鑑みて、クライアントデバイス40は、セグメント126Cのデータを要求してもよい。クライアントデバイス40は、セグメント126Cのデータを取り出すのと実質的に同時にセグメント112Bのデータを取り出してもよい。すなわち、図2の例に示すように、セグメント112Bとセグメント126Cとは再生時間の点で重複するので、セグメント112Bのデータを取り出すのと実質的に同時にセグメント126Cのデータを取り出すことが必要となる場合がある。したがって、少なくとも、異なる適応セットの2つのセグメントのデータが、(たとえば帯域幅適応のために、同じ適用セットの表現間で切り替える場合のように)連続的にではなく実質的に同時に取り出されてもよいという点で、適応セット間で切り替えるためにデータを取り出すことは、同じ適応セットの2つの表現間で切り替えるためにデータを取り出すこととは異なる場合がある。

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

ビデオファイル150は一般に、表現106、122(図2)のうちの1つに含まれ得る、マルチメディアコンテンツのセグメントの一例を表す。このようにして、ビデオファイル150は、セグメント112のうちの1つ、セグメント116のうちの1つ、セグメント126のうちの1つ、セグメント130のうちの1つ、または別の表現のセグメントに対応する場合がある。

図3の例では、ビデオファイル150は1つのセグメントインデックス(SIDX)ボックス161を含む。いくつかの例では、ビデオファイル150は、たとえば複数の動画フラグメント162の間に、追加のSIDXボックスを含む場合がある。一般に、SIDXボックス161のようなSIDXボックスは、動画フラグメント162のうちの1つまたは複数のバイト範囲を表す情報を含む。他の例では、SIDXボックス161および/または他のSIDXボックスは、MOOVボックス154内で、後のMOOVボックス154内で、前のもしくは後のMFRAボックス164内で、またはビデオファイル150内の他の場所で、提供される場合がある。

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

図3の例では、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つ以上のトラックを含む場合があるが、これはDASHプロトコルが動作するのに必須ではない。したがって、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、図3には示されない)を含んでもよい。MFHDボックスは、動画フラグメントのシーケンス番号のような、対応する動画フラグメントの特性を表してもよい。動画フラグメント162は、ビデオファイル150の中で、シーケンス番号の順番に含まれてもよい。

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

図4Aおよび図4Bは、本開示の技法による、再生中に適応セット間で切り替えるための例示的な方法を示すフローチャートである。図4Aおよび図4Bの方法は、サーバデバイス60(図1)およびクライアントデバイス40(図1)に関して説明される。しかしながら、他のデバイスが同様の技法を実行するように構成されてもよいことを理解されたい。たとえば、クライアントデバイス40は、いくつかの例では、コンテンツ準備デバイス20からデータを取り出す場合がある。

最初に、図4Aの例では、サーバデバイス60はクライアントデバイス40に、適応セットおよび適応セットの表現の指示を提供する(200)。たとえば、サーバデバイス60はクライアントデバイス40に、MPDなどのマニフェストファイルのデータを送信してもよい。図4Aに示されていないが、サーバデバイス60は、クライアントデバイス40からの指示を求める要求に応答して、クライアントデバイス40に指示を送信してもよい。(たとえば、マニフェストファイル内に含まれる)指示は、表現内のセグメントの開始および終了の再生時間、ならびにセグメント内の様々なタイプのデータのバイト範囲を規定するデータをさらに含んでもよい。特に、指示は、適応セットの各々の中に含まれるデータのタイプ、ならびにそのデータタイプの特性を示してもよい。たとえば、ビデオデータを含む適応セットの場合、指示は、ビデオ適応セットの各々の中に含まれるビデオデータのカメラアングルを規定してもよい。別の例として、オーディオデータおよび/またはタイムドテキストデータを含む適応セットの場合、指示は、オーディオデータおよび/またはタイムドテキストデータの言語を規定してもよい。

クライアントデバイス40はサーバデバイス60から、適応セットおよび表現の指示を受信する(202)。クライアントデバイス40は、たとえば、言語選好および/またはカメラアングル選好のいずれかまたはすべてに関して、ユーザのためにデフォルト選好により構成されてもよい。したがって、クライアントデバイス40は、ユーザ選好に基づいて、メディアデータの様々なタイプの適応セットを選択してもよい(204)。たとえば、ユーザが言語選好を選択した場合、クライアントデバイス40は、言語選好(ならびにクライアントデバイス40の復号能力およびレンダリング能力、および適応セットのコーディング特性およびレンダリング特性などの他の特性)に少なくとも部分的に基づいてオーディオ適応セットを選択してもよい。クライアントデバイス40は同様に、オーディオデータとビデオデータの両方の適応セット、ならびにユーザがサブタイトルを表示することを選択した場合にタイムドテキストの適応セットを選択してもよい。あるいは、クライアントデバイス40は、適応セットを選択するために、ユーザ選好を使用するのではなく、初期ユーザ選択またはデフォルト構成を受信する場合がある。

特定の適応セットを選択した後、クライアントデバイス40は、ネットワーク帯域幅の利用可能量(206)、ならびに適応セットにおける表現のビットレート(208)を判断してもよい。たとえば、クライアントデバイス40は、メディアコンテンツのマニフェストファイルを参照してもよく、このマニフェストファイルは、表現のビットレートを規定している場合がある。次いで、クライアントデバイス40は、たとえば、適応セットの表現のビットレートに基づいて、かつ利用可能なネットワーク帯域幅の判断された量に基づいて、適応セットから表現を選択してもよい(210)。たとえば、クライアントデバイス40は、利用可能なネットワーク帯域幅の量を上回らない適応セットの最高ビットレートを有する表現を選択してもよい。

クライアントデバイス40は同様に、選択された適応セット(選択された適応セットは、異なるタイプのメディアデータ、たとえばオーディオ、ビデオ、および/またはタイムドテキストにそれぞれ対応する場合がある)の各々から表現を選択してもよい。場合によっては、同じタイプのメディアデータ、たとえば、ステレオまたはマルチビュービデオデータ、様々なレベルのサラウンド音声または3次元オーディオ配列をサポートするための複数のオーディオチャネルなどについて、複数の適応セットが選択されてもよいことを理解されたい。クライアントデバイス40は、提示されるべき各タイプのメディアデータについて、少なくとも1つの適応セットを選択し、選択された各適応セットから1つの表現を選択してもよい。

クライアントデバイス40は次いで、選択された表現のデータを要求してもよい(212)。たとえば、クライアントデバイス40は、たとえば、HTTP GET要求または部分GET要求を使用して、選択された表現の各々からのセグメントを要求してもよい。一般に、クライアントデバイス40は、実質的に同時である再生時間を有する表現の各々からのセグメントのデータを要求してもよい。それに応答して、サーバデバイス60はクライアントデバイス40に、要求されたデータを送信してもよい(214)。クライアントデバイス40は、受信されたデータをバッファリングし、復号し、提示してもよい(216)。

その後、クライアントデバイス40は、異なる適応セットを求める要求を受信する場合がある(220)。たとえば、ユーザは、オーディオデータもしくはタイムドテキストデータについて異なる言語に切り替えること、あるいは、たとえば、3Dビデオプレゼンテーションの深度を拡大もしくは縮小するために、または2Dビデオプレゼンテーションの代替アングルからビデオを見るために、異なるカメラアングルに切り替えることを選択する場合がある。もちろん、3Dビデオプレゼンテーションに代替ビューアングルがもたらされる場合、クライアントデバイス40は、代替ビューアングルから3Dプレゼンテーションを提供するために、たとえば、2つ以上のビデオ適応セットを切り替えてもよい。

いずれの場合も、異なる適応セットを求める要求を受信した後、クライアントデバイス40は、要求に基づいて適応セットを選択してもよい(222)。この選択プロセスは、ステップ204に関して上述した選択プロセスと実質的に同様であってもよい。たとえば、クライアントデバイス40は、ユーザによって要求された特性(たとえば、言語またはカメラアングル)ならびにクライアントデバイス40のコーディング能力およびレンダリング能力に準拠するデータを新しい適応セットが含むように、新しい適応セットを選択してもよい。クライアントデバイス40はまた、ネットワーク帯域幅の利用可能量を判断し(224)、新しい適応セットにおける表現のビットレートを判断し(226)、表現のビットレートおよびネットワーク帯域幅の利用可能量に基づいて新しい適応セットから表現を選択してもよい(228)。この表現選択プロセスは、ステップ206〜210に関して上述した表現選択プロセスに実質的に準拠してもよい。

クライアントデバイス40は次いで、選択された表現のデータを要求してもよい(230)。特に、クライアントデバイス40は、新しい適応セットに切り替える要求が受信されたときの再生時間よりも後にある、当該再生時間に最も近い再生時間を有する切替えポイントを含むセグメントを判断してもよい。新しい適応セットの表現のセグメントのデータを要求することと、以前の適応セットの表現のセグメントのデータを要求することとは、これらの適応セット間のセグメントが時間的に合わせられていないと仮定すると、実質的に同時に発生する場合がある。さらに、クライアントデバイス40は、切り替えられていない他の適応セットの表現からのデータを要求し続けてもよい。

場合によっては、新しい適応セットの表現は、容認できないほど長い時間期間(たとえば、いくらかの秒数またはいくらかの分数)のために切替えポイントを有しないことがある。そのような場合、クライアントデバイス40は、適応セットを切り替える要求が受信されたときの再生時間よりも前にある再生時間を有する切替えポイントを含む新しい適応セットの表現のデータを要求することを選択してもよい。通常、これは、ビデオデータおよびオーディオデータと比較して相対的に低いビットレートを有するタイムドテキストデータの場合にのみ発生することになるので、より前にある切替えポイントを取り出しても、データの取出しまたは再生に悪影響が生じない。

いずれの場合も、サーバデバイス60はクライアントデバイス40に、要求されたデータを送信してもよく(232)、クライアントデバイス40は、受信されたデータを復号し、提示してもよい(234)。詳細には、クライアントデバイス40は、新しい適応セットの表現の切替えポイントを含む受信されたデータを、実際の再生時間が切替えポイントの再生時間以上になるまで、バッファリングしてもよい。次いでクライアントデバイス40は、以前の適応セットのデータの提示から新しい適応セットのデータの提示に切り替えてもよい。同時に、クライアントデバイス40は、他のメディアタイプを有する他の適応セットのデータの復号および提示を続けてもよい。

第1の適応セットの表現を選択した後、かつ新しい適応セットに切り替える要求を受信する前に、クライアントデバイス40は、帯域幅推定を周期的に実行し、必要な場合に、ネットワーク帯域幅の再評価された量に基づいて、第1の適応セットの異なる表現を選択してもよいことを理解されたい。同様に、新しい適応セットの表現を選択した後、クライアントデバイス40は、後続の適応セットを決定するために帯域幅推定を周期的に実行してもよい。

このようにして、図4Aおよび図4Bの方法は、第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すステップと、第1の適応セットからのメディアデータを提示するステップと、第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、第2の適応セットの切替えポイントを含む第2の適応セットからのメディアデータを取り出すステップと、実際のプレイアウト時間が切替えポイントのプレイアウト時間以上になった後、第2の適応セットからのメディアデータを提示するステップとを含む方法の一例を表す。

図5は、本開示の技法による、適応セット間で切り替えるための別の例示的な方法を示すフローチャートである。この例では、クライアントデバイス40は、MPDファイル(または他のマニフェストファイル)を受信する(250)。次いでクライアントデバイス40は、特定のタイプのメディアデータ(たとえば、オーディオ、タイムドテキスト、またはビデオ)を含む、第1の適応セットの選択を受信する(252)。次いでクライアントデバイス40は、第1の適応セットの表現からのデータを取り出し(254)、取り出されたデータの少なくとも一部を提示する(256)。

第1の適応セットからのメディアデータの再生中に、クライアントデバイス40は、第2の適応セットの選択を受信する(258)。したがって、クライアントデバイス40は、第2の適応セットの表現からのデータを取り出してもよく(260)、取り出されたデータは、第2の適応セットの表現内の切替えポイントを含んでもよい。このようにして、クライアントデバイス40は、第2の適応セットの切替えポイントの再生時間まで、第1の適応セットからのデータを提示し続けてもよい(262)。次いでクライアントデバイス40は、切替えポイントの後にくる第2の適応セットのメディアデータを提示し始めてもよい。

したがって、図5の方法は、第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すステップと、第1の適応セットからのメディアデータを提示するステップと、第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、第2の適応セットの切替えポイントを含む第2の適応セットからのメディアデータを取り出すステップと、実際のプレイアウト時間が切替えポイントのプレイアウト時間以上になった後、第2の適応セットからのメディアデータを提示するステップとを含む方法の一例を表す。

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

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

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

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

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

10 システム
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
42 オーディオ出力
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 ウェブアプリケーション
54 ネットワークインターフェース
60 サーバデバイス
62 記憶媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68 表現
68A 表現
68N 表現
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
100 マルチメディアコンテンツ
102 メディアプレゼンテーション記述(MPD)
104 適応セット
106 表現
106A 表現
106B 表現
110 ヘッダデータ
112 セグメント
112A セグメント
112N セグメント
112B セグメント
114 ヘッダデータ
116 セグメント
116A セグメント
116N セグメント
120 適応セット
122 表現
122A 表現
122B 表現
124 ヘッダデータ
126 セグメント
126A セグメント
126M セグメント
126B セグメント
126C セグメント
128 ヘッダデータ
130 セグメント
130A セグメント
130M セグメント
150 ビデオファイル
152 ファイルタイプ(FTYP)ボックス
154 動画(MOOV)ボックス
156 動画ヘッダ(MVHD)ボックス
158 トラック(TRAK)ボックス
160 動画延長(MVEX)ボックス
161 セグメントインデックス(SIDX)ボックス
162 動画フラグメント
164 動画フラグメントランダムアクセス(MFRA)ボックス

Claims (40)

1. メディアデータを取り出す方法であって、
   第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すステップと、
   前記第1の適応セットからのメディアデータを提示するステップと、
   前記第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、
   前記第2の適応セットの切替えポイントを含む前記第2の適応セットからのメディアデータを取り出すステップと、
   実際のプレイアウト時間が前記切替えポイントのプレイアウト時間以上になった後、前記第2の適応セットからのメディアデータを提示するステップと
   を含む方法。
2. 前記第1のタイプは、オーディオデータおよびサブタイトルデータのうちの少なくとも1つを含み、前記第1の適応セットは、第1の言語による前記第1のタイプのメディアデータを含む第1の複数の表現を含み、前記第2の適応セットは、前記第1の言語とは異なる第2の言語による前記第1のタイプのメディアデータを含む第2の複数の表現を含む、請求項1に記載の方法。
3. 前記第1のタイプは、ビデオデータを含み、前記第1の適応セットは、第1のカメラアングルのビデオデータを含む第1の複数の表現を含み、前記第2の適応セットは、前記第1のカメラアングルとは異なる第2のカメラアングルのビデオデータを含む第2の複数の表現を含む、請求項1に記載の方法。
4. 前記第2の適応セットに切り替える前記要求が受信されたときに、前記切替えポイントの前記プレイアウト時間が、切り替える前記要求が受信されたときの前記実際のプレイアウト時間としきい値との合計よりも少ない、請求項1に記載の方法。
5. 前記第2の適応セットに切り替える前記要求が受信されたときに、前記切替えポイントの前記プレイアウト時間が、切り替える前記要求が受信されたときの前記実際のプレイアウト時間よりも多く、前記方法は、前記第2の適応セットから取り出されたメディアデータのプレイアウト時間が前記実際のプレイアウト時間以上になるまで、前記第1の適応セットおよび前記第2の適応セットからのデータを取り出すステップをさらに含む、請求項1に記載の方法。
6. 前記第1の適応セットおよび前記第2の適応セットのマニフェストファイルを取得するステップと、
   前記マニフェストファイルのデータを使用して前記切替えポイントのプレイアウト時間を判断するステップと
   をさらに含み、
   前記メディアデータを取り出すステップは、前記第2の適応セットに切り替える前記要求が受信されたときの前記実際のプレイアウト時間と前記切替えポイントの前記プレイアウト時間との比較に少なくとも部分的に基づいて、前記メディアデータを取り出すステップを含む、請求項1に記載の方法。
7. 前記第1の適応セットおよび前記第2の適応セットのマニフェストファイルを取得するステップと、
   前記マニフェストファイルのデータを使用して、前記第2の適応セットの表現における前記切替えポイントの位置を判断するステップと
   をさらに含む、請求項1に記載の方法。
8. 前記位置は、前記第2の適応セットの前記表現のセグメントにおける開始バイトによって少なくとも部分的に規定される、請求項7に記載の方法。
9. 前記第2の適応セットからの前記メディアデータを取り出すステップは、少なくとも前記切替えポイントの前記位置を含む前記第2の適応セットからの前記表現のデータを取り出すステップを含む、請求項7に記載の方法。
10. 前記表現は、選択される表現を含み、前記方法は、
    前記マニフェストファイルを使用して、前記第2の適応セットにおける複数の表現のビットレートを判断するステップと、
    ネットワーク帯域幅の現在の量を判断するステップと、
    前記選択される表現の前記ビットレートがネットワーク帯域幅の前記現在の量を上回らないように、前記複数の前記表現から前記選択される表現を選択するステップと
    をさらに含む、請求項7に記載の方法。
11. メディアデータを取り出すためのデバイスであって、第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すことと、前記第1の適応セットからのメディアデータを提示することと、前記第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、
    前記第2の適応セットの切替えポイントを含む前記第2の適応セットからのメディアデータを取り出すことと、
    実際のプレイアウト時間が前記切替えポイントのプレイアウト時間以上になった後、前記第2の適応セットからのメディアデータを提示することと
    を行うように構成される1つまたは複数のプロセッサを含むデバイス。
12. 前記第1のタイプは、オーディオデータおよびサブタイトルデータのうちの少なくとも1つを含み、前記第1の適応セットは、第1の言語による前記第1のタイプのメディアデータを含む第1の複数の表現を含み、前記第2の適応セットは、前記第1の言語とは異なる第2の言語による前記第1のタイプのメディアデータを含む第2の複数の表現を含む、請求項11に記載のデバイス。
13. 前記第1のタイプは、ビデオデータを含み、前記第1の適応セットは、第1のカメラアングルのビデオデータを含む第1の複数の表現を含み、前記第2の適応セットは、前記第1のカメラアングルとは異なる第2のカメラアングルのビデオデータを含む第2の複数の表現を含む、請求項11に記載のデバイス。
14. 前記第2の適応セットに切り替える前記要求が受信されたときに、前記切替えポイントの前記プレイアウト時間が、切り替える前記要求が受信されたときの前記実際のプレイアウト時間としきい値との合計よりも少ない、請求項11に記載のデバイス。
15. 前記第2の適応セットに切り替える前記要求が受信されたときに、前記切替えポイントの前記プレイアウト時間が、切り替える前記要求が受信されたときの前記実際のプレイアウト時間よりも多く、前記1つまたは複数のプロセッサは、前記第2の適応セットから取り出されたメディアデータのプレイアウト時間が前記実際のプレイアウト時間以上になるまで、前記第1の適応セットおよび前記第2の適応セットからのデータを取り出すようにさらに構成される、請求項11に記載のデバイス。
16. 前記1つまたは複数のプロセッサは、前記第1の適応セットおよび前記第2の適応セットのマニフェストファイルを取得することと、前記マニフェストファイルのデータを使用して前記切替えポイントのプレイアウト時間を判断することと、前記第2の適応セットに切り替える前記要求が受信されたときの前記実際のプレイアウト時間と前記切替えポイントの前記プレイアウト時間との比較に少なくとも部分的に基づいて、前記メディアデータを取り出すこととを行うようにさらに構成される、請求項11に記載のデバイス。
17. 前記1つまたは複数のプロセッサは、前記第1の適応セットおよび前記第2の適応セットのマニフェストファイルを取得することと、前記マニフェストファイルのデータを使用して、前記第2の適応セットの表現における前記切替えポイントの位置を判断することとを行うようにさらに構成される、請求項11に記載のデバイス。
18. 前記位置は、前記第2の適応セットの前記表現のセグメントにおける開始バイトによって少なくとも部分的に規定される、請求項17に記載のデバイス。
19. 前記1つまたは複数のプロセッサは、少なくとも前記切替えポイントの前記位置を含む前記第2の適応セットの前記表現のデータを取り出すように構成される、請求項17に記載のデバイス。
20. 前記表現は、選択される表現を含み、前記1つまたは複数のプロセッサは、前記マニフェストファイルを使用して、前記第2の適応セットにおける複数の表現のビットレートを判断することと、ネットワーク帯域幅の現在の量を判断することと、前記選択される表現の前記ビットレートがネットワーク帯域幅の前記現在の量を上回らないように、前記複数の前記表現から前記選択される表現を選択することとを行うようにさらに構成される、請求項17に記載のデバイス。
21. メディアデータを取り出すためのデバイスであって、
    第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すための手段と、
    前記第1の適応セットからのメディアデータを提示するための手段と、
    前記第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、前記第2の適応セットの切替えポイントを含む前記第2の適応セットからのメディアデータを取り出すための手段と、
    前記要求に応答して、実際のプレイアウト時間が前記切替えポイントのプレイアウト時間以上になった後、前記第2の適応セットからのメディアデータを提示するための手段と
    を含むデバイス。
22. 前記第1のタイプは、オーディオデータおよびサブタイトルデータのうちの少なくとも1つを含み、前記第1の適応セットは、第1の言語による前記第1のタイプのメディアデータを含む第1の複数の表現を含み、前記第2の適応セットは、前記第1の言語とは異なる第2の言語による前記第1のタイプのメディアデータを含む第2の複数の表現を含む、請求項21に記載のデバイス。
23. 前記第1のタイプは、ビデオデータを含み、前記第1の適応セットは、第1のカメラアングルのビデオデータを含む第1の複数の表現を含み、前記第2の適応セットは、前記第1のカメラアングルとは異なる第2のカメラアングルのビデオデータを含む第2の複数の表現を含む、請求項21に記載のデバイス。
24. 前記第2の適応セットに切り替える前記要求が受信されたときに、前記切替えポイントの前記プレイアウト時間が、切り替える前記要求が受信されたときの前記実際のプレイアウト時間としきい値との合計よりも少ない、請求項21に記載のデバイス。
25. 前記第2の適応セットに切り替える前記要求が受信されたときに、前記切替えポイントの前記プレイアウト時間が、切り替える前記要求が受信されたときの前記実際のプレイアウト時間よりも多く、前記デバイスは、前記第2の適応セットから取り出されたメディアデータのプレイアウト時間が前記実際のプレイアウト時間以上になるまで、前記第1の適応セットおよび前記第2の適応セットからのデータを取り出すための手段をさらに含む、請求項21に記載のデバイス。
26. 前記第1の適応セットおよび前記第2の適応セットのマニフェストファイルを取得するための手段と、
    前記マニフェストファイルのデータを使用して前記切替えポイントのプレイアウト時間を判断するための手段と
    をさらに含み、
    前記メディアデータを取り出すための前記手段は、前記第2の適応セットに切り替える前記要求が受信されたときの前記実際のプレイアウト時間と前記切替えポイントの前記プレイアウト時間との比較に少なくとも部分的に基づいて、前記メディアデータを取り出すための手段を含む、請求項21に記載のデバイス。
27. 前記第1の適応セットおよび前記第2の適応セットのマニフェストファイルを取得するための手段と、
    前記マニフェストファイルのデータを使用して、前記第2の適応セットの表現における前記切替えポイントの位置を判断するための手段と
    をさらに含む、請求項21に記載のデバイス。
28. 前記位置は、前記第2の適応セットの前記表現のセグメントにおける開始バイトによって少なくとも部分的に規定される、請求項27に記載のデバイス。
29. 前記第2の適応セットからの前記メディアデータを取り出すための前記手段は、少なくとも前記切替えポイントの前記位置を含む前記第2の適応セットからの前記表現のデータを取り出すための手段を含む、請求項27に記載のデバイス。
30. 前記表現は、選択される表現を含み、前記デバイスは、
    前記マニフェストファイルを使用して、前記第2の適応セットにおける複数の表現のビットレートを判断するための手段と、
    ネットワーク帯域幅の現在の量を判断するための手段と、
    前記選択される表現の前記ビットレートがネットワーク帯域幅の前記現在の量を上回らないように、前記複数の前記表現から前記選択される表現を選択するための手段と
    をさらに含む、請求項27に記載のデバイス。
31. 実行されたときにプロセッサに、
    第1のタイプのメディアデータを含む第1の適応セットからのメディアデータを取り出すことと、
    前記第1の適応セットからのメディアデータを提示することと、
    前記第1のタイプのメディアデータを含む第2の適応セットに切り替える要求に応答して、
    前記第2の適応セットの切替えポイントを含む前記第2の適応セットからのメディアデータを取り出すことと、
    実際のプレイアウト時間が前記切替えポイントのプレイアウト時間以上になった後、前記第2の適応セットからのメディアデータを提示することと
    を行わせる命令を記憶したコンピュータ可読記憶媒体。
32. 前記第1のタイプは、オーディオデータおよびサブタイトルデータのうちの少なくとも1つを含み、前記第1の適応セットは、第1の言語による前記第1のタイプのメディアデータを含む第1の複数の表現を含み、前記第2の適応セットは、前記第1の言語とは異なる第2の言語による前記第1のタイプのメディアデータを含む第2の複数の表現を含む、請求項31に記載のコンピュータ可読記憶媒体。
33. 前記第1のタイプは、ビデオデータを含み、前記第1の適応セットは、第1のカメラアングルのビデオデータを含む第1の複数の表現を含み、前記第2の適応セットは、前記第1のカメラアングルとは異なる第2のカメラアングルのビデオデータを含む第2の複数の表現を含む、請求項31に記載のコンピュータ可読記憶媒体。
34. 前記第2の適応セットに切り替える前記要求が受信されたときに、前記切替えポイントの前記プレイアウト時間が、切り替える前記要求が受信されたときの前記実際のプレイアウト時間としきい値との合計よりも少ない、請求項31に記載のコンピュータ可読記憶媒体。
35. 前記第2の適応セットに切り替える前記要求が受信されたときに、前記切替えポイントの前記プレイアウト時間が、切り替える前記要求が受信されたときの前記実際のプレイアウト時間よりも多く、前記コンピュータ可読記憶媒体は、前記プロセッサに、前記第2の適応セットから取り出されたメディアデータのプレイアウト時間が前記実際のプレイアウト時間以上になるまで、前記第1の適応セットおよび前記第2の適応セットからのデータを取り出すことを行わせる命令をさらに含む、請求項31に記載のコンピュータ可読記憶媒体。
36. 前記プロセッサに、
    前記第1の適応セットおよび前記第2の適応セットのマニフェストファイルを取得することと、
    前記マニフェストファイルのデータを使用して前記切替えポイントのプレイアウト時間を判断することと
    を行わせる命令をさらに含み、
    前記プロセッサに、前記メディアデータを取り出すことを行わせる前記命令は、前記プロセッサに、前記第2の適応セットに切り替える前記要求が受信されたときの前記実際のプレイアウト時間と前記切替えポイントの前記プレイアウト時間との比較に少なくとも部分的に基づいて、前記メディアデータを取り出すことを行わせる命令を含む、請求項31に記載のコンピュータ可読記憶媒体。
37. 前記プロセッサに、
    前記第1の適応セットおよび前記第2の適応セットのマニフェストファイルを取得することと、
    前記マニフェストファイルのデータを使用して、前記第2の適応セットの表現における前記切替えポイントの位置を判断することと
    を行わせる命令をさらに含む、請求項31に記載のコンピュータ可読記憶媒体。
38. 前記位置は、前記第2の適応セットの前記表現のセグメントにおける開始バイトによって少なくとも部分的に規定される、請求項37に記載のコンピュータ可読記憶媒体。
39. 前記プロセッサに、前記第2の適応セットからの前記メディアデータを取り出すことを行わせる前記命令は、前記プロセッサに、少なくとも前記切替えポイントの前記位置を含む前記第2の適応セットからの前記表現のデータを取り出すことを行わせる命令を含む、請求項37に記載のコンピュータ可読記憶媒体。
40. 前記表現は、選択される表現を含み、前記コンピュータ可読記憶媒体は、前記プロセッサに、
    前記マニフェストファイルを使用して、前記第2の適応セットにおける複数の表現のビットレートを判断することと、
    ネットワーク帯域幅の現在の量を判断することと、
    前記選択される表現の前記ビットレートがネットワーク帯域幅の前記現在の量を上回らないように、前記複数の前記表現から前記選択される表現を選択することと
    を行わせる命令をさらに含む、請求項37に記載のコンピュータ可読記憶媒体。

Images