JP6342457B2

JP6342457B2 - コード化ビデオデータのネットワークストリーミング

Info

Publication number: JP6342457B2
Application number: JP2016153605A
Authority: JP
Inventors: タディ・エム・ナガラジ; ラルフ・エー・ゴルミエ
Original assignee: クアルコム，インコーポレイテッド
Priority date: 2011-09-06
Filing date: 2016-08-04
Publication date: 2018-06-13
Anticipated expiration: 2032-08-31
Also published as: KR20140054418A; US9900363B2; WO2013036450A1; CN106878804A; EP2754302A1; US20130060956A1; CN103765914B; US20160255133A1; CN106878804B; KR101784051B1; JP2017022715A; CN103765914A; US9357275B2; KR101838789B1; KR20150088899A; JP6049728B2; JP2014529258A; EP2754302B1

Description

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

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

デジタルビデオ機能は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(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)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。そのようなパケット化されたビデオデータは、ネットワークストリーミングを使用したコンピュータネットワークを介した送信のような、種々の方法で転送され得る。

一般に、本開示は、ネットワークを通じてメディアデータをストリーミングするための技法について説明する。より詳細には、本開示の態様は、たとえば、動的適応ストリーミングオーバーHTTP(DASH)に従って、ネットワークを通じてメディアデータをストリーミングすることに関連するレイテンシを低減することに関する。一例では、本開示の技法は、メディアデータのセグメントの送信を最適化することを含む。すなわち、本開示の態様によれば、メディアデータを提供する役割を担うデバイス(たとえば、サーバデバイス)は、メディアデータのセグメントを、ネットワーク設定における送信に適した複数のサブセグメントに分割することができる。この例では、サーバデバイスは、メディアデータのサブセグメントを、サブセグメントが形成されるとすぐに送信することができる。

一例では、方法が、マルチメディアデータのセグメントの第1のサブセグメントを受信するステップであって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、ステップを含む。本方法はまた、第1のサブセグメントを受信した後、第2のサブセグメントを受信するステップであって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、ステップと、第1のサブセグメントおよび第2のサブセグメントを受信した後、セグメントの少なくとも一部分を処理するステップとを含む。

別の例では、マルチメディアデータを受信するための装置が、1つまたは複数のプロセッサを含む。1つまたは複数のプロセッサは、マルチメディアデータのセグメントの第1のサブセグメントを受信するステップであって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、ステップを行うように構成される。1つまたは複数のプロセッサはまた、第1のサブセグメントを受信した後、第2のサブセグメントを受信するステップであって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、ステップを行うように構成される。1つまたは複数のプロセッサはまた、第1のサブセグメントおよび第2のサブセグメントを受信した後、セグメントの少なくとも一部分を処理するステップを行うように構成される。

別の例では、マルチメディアデータを受信するための装置が、マルチメディアデータのセグメントの第1のサブセグメントを受信するための手段であって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、手段を含む。本装置はまた、第1のサブセグメントを受信した後、第2のサブセグメントを受信するための手段であって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、手段を含む。本装置はまた、第1のサブセグメントおよび第2のサブセグメントを受信した後、セグメントの少なくとも一部分を処理するための手段を含む。

別の例では、コンピュータプログラム製品が、命令を記憶したコンピュータ可読媒体を含み、命令は、実行されると、1つまたは複数のプロセッサに、マルチメディアデータのセグメントの第1のサブセグメントを受信するステップであって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、ステップを行わせる。命令はまた、1つまたは複数のプロセッサに、第1のサブセグメントを受信した後、第2のサブセグメントを受信するステップであって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、ステップを行わせる。命令はまた、1つまたは複数のプロセッサに、第1のサブセグメントおよび第2のサブセグメントを受信した後、セグメントの少なくとも一部分を処理するステップを行わせる。

別の例では、方法が、マルチメディアデータのセグメントの第1のサブセグメントを送るステップであって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、ステップを含む。本方法はまた、第1のサブセグメントを送った後、第2のサブセグメントを送るステップであって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、ステップを含む。

別の例では、マルチメディアデータを送るための装置が、1つまたは複数のプロセッサを含む。1つまたは複数のプロセッサは、マルチメディアデータのセグメントの第1のサブセグメントを送るステップであって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、ステップを行うように構成される。1つまたは複数のプロセッサはまた、第1のサブセグメントを送った後、第2のサブセグメントを送るステップであって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、ステップを行うように構成される。

別の例では、マルチメディアデータを送るための装置が、マルチメディアデータのセグメントの第1のサブセグメントを送るための手段であって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、手段を含む。本装置はまた、第1のサブセグメントを送った後、第2のサブセグメントを送るための手段であって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、手段を含む。

別の例では、コンピュータプログラム製品が、命令を記憶したコンピュータ可読媒体を含み、命令は、実行されると、1つまたは複数のプロセッサに、マルチメディアデータのセグメントの第1のサブセグメントを送るステップであって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、ステップを行わせる。命令はまた、1つまたは複数のプロセッサに、第1のサブセグメントを送った後、第2のサブセグメントを送るステップであって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、ステップを行わせる。

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

ネットワークを通じてメディアデータをストリーミングするための技法を実施する、例示的なシステムを示すブロック図である。本開示の態様による、例示的な取出しユニットを示すブロック図である。例示的なマルチディアコンテンツの要素を示す概念図である。本開示の態様による、ビデオデータの例示的なセグメントを示すブロック図である。本開示の技法を実行するための例示的な方法を示すフローチャートである。

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

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

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

コンテンツ準備デバイスは、3GPP(Third Generation Partnership Project)によって規定されたフォーマットによるメディアプレゼンテーション記述(MPD)ファイルなどのマニフェストファイルの様々な部分に別個のネットワークロケーションを提供することもできる。すなわち、マニフェストファイルの様々な部分は、たとえば、ユニフォームリソースロケータ(URL)などの様々なユニフォームリソース識別子(URI)によって独立してアドレス可能であり得る。マニフェストファイルの最初の部分は、マニフェストファイルの別の部分のURI、URL、または他のロケーション識別子を含み得る。たとえば、マニフェストファイルの第1の部分は、上記で説明したように適応セットの共通の特性の説明を含み得る。

適応セットの各々は、それぞれの適応セットにおける表現のメディアデータのロケーションを示すデータを含み得る、マニフェストファイルのそれぞれの異なる部分に関連付けられ得る。このようにして、クライアントデバイスは、マニフェストファイルの第1の部分を受信し、適切な適応セットを選択し、選択された適応セットに関するマニフェストファイルの別の部分を取り出し、選択されたグループの表現を選択し、マニフェストファイルの他の部分を使用して、選択された表現のデータを取り出すことができる。さらに、クライアントデバイスは、マニフェストファイルの他の部分、すなわち、選択された適応セットに固有の部分を使用して、変化するネットワーク帯域幅に適応することができる。

メディアコンテンツの表現のセグメントのようなビデオファイルは、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-4 AVCビデオ圧縮のサポートを定義される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つの表現内の連続的なメディアセグメントの境界にわたって、時間的に連続的であり得る。

典型的には、DASH規格に準拠するセグメントは一般に、(1)固定ヘッダ、(2)データユニットへのポインタのテーブル、および(3)データユニット自体を含む3つの部分を有する。一例では、セグメントは、下に示すTable 1(表1)に従って形成され得る。

一般に、セグメントを送信する役割を担うデバイス(たとえば、サーバデバイス)は、デバイスがポインタのテーブルを適切に構築できるように、データユニットのすべてのサイズがわかるまでセグメントヘッダを送信することができない。したがって、サーバデバイスは一般に、データユニットおよびポインタを組み立て、ヘッダを生成し、単一のユニットとして完全に形成されたセグメントを送信する。代替として、部分GET要求に応答して、サーバは、セグメントの部分(たとえば、指定されたバイト範囲)を送信することができる。しかしながら、本開示の技法の範囲外では、サーバデバイスは、セグメントが完全に形成された後、たとえば、一般にセグメントの最後に配置されるメディアフラグメントランダムアクセス(MFRA)ボックスが構築された後、部分GET要求を受信する。すなわち、クライアントデバイスが部分GET要求を提出するためには、クライアントデバイスは、MFRAボックス、またはセグメントの特定の部分のロケーションのインジケータ、たとえば瞬時デコーダリフレッシュ(IDR:instantaneous decoder refresh)ピクチャなどの特定のタイプのネットワーク抽象化層(NAL)ユニットのバイトロケーションの指示を有する同様のデータ構造のデータにアクセスする必要がある。

さらに、メディアデータのセグメントを受信するデバイス(たとえば、クライアントデバイス)は一般に、セグメントヘッダおよびデータユニットのすべてが受信されるまでセグメントを処理することができない。したがって、クライアントデバイスは一般に、(たとえば、ヘッダ全体、ポインタのテーブル、およびデータユニットを備えた)完全に形成されたセグメントを、セグメントを復号し表示する前に受信する。あるいは、クライアントデバイスは、上記で説明したように、MFRAボックスのデータを使用して、セグメントの部分(たとえば、1つまたは複数の指定されたバイト範囲)を取り出すことができる。しかしながら、この場合も、本開示の技法の範囲外において、クライアントデバイスによってセグメントの特定のバイト範囲にアクセスすることは、セグメントが完全に形成された後にのみ実行される。

セグメント全体がネットワークを通じてセグメントを送信する前に形成される(また、復号する前に受信される)例では、セグメントの送信とセグメントの復号/再生との間にセグメント1個分のレイテンシがもたらされる。すなわち、サーバデバイスは、セグメント全体を完全に形成し、セグメントをクライアントデバイスに送信する。クライアントデバイスは、完全に形成されたセグメントを受信し、ヘッダデータおよびポインタを使用して、完全なセグメントを復号し表示する。したがって、サーバデバイスが完全なセグメントを形成し、クライアントデバイスが再生前に完全なセグメントを受信するので、完全なセグメント1個分のレイテンシがもたらされる。

一例では、説明のために、セグメントが再生時間においてビデオデータの1秒を含み得る。すなわち、サーバデバイスは、セグメントにビデオデータの丸々1秒をパッケージ化(たとえば、符号化)し、1秒の長さのセグメントをクライアントデバイスに送信することができる。次いでクライアントデバイスは、1秒の長さのセグメントのヘッダおよびデータユニットのすべてを受信し、セグメントを表示する前にセグメント全体を復号する。したがって、クライアントデバイスが、完全なセグメントが受信されるまで復号/再生を開始しないので、1秒のレイテンシがもたらされ得る。

本開示の態様は一般に、メディアデータの1つまたは複数のセグメントをストリーミングすることに関連するレイテンシを低減することを対象とする。一例では、本開示の技法は、メディアデータのセグメントの送信スケジュールを最適化することを含む。すなわち、本開示の態様によれば、ネットワークを通じてセグメントを送信する役割を担うデバイス(たとえば、以下で図1に関してより詳細に説明するサーバデバイス)が、メディアデータのセグメントを、ネットワークを通じて送信するのに適した複数のサブセグメントに分割することができる。この例では、サーバデバイスは、メディアデータのサブセグメントを、サブセグメントが形成されるとすぐに送信することができる。すなわち、サーバデバイスは、サブセグメントを送信する前に、複数のサブセグメントが形成されるのを待つ必要がない。さらに、サーバデバイスは、サブセグメントを送信する前に、サブセグメントのすべてに関するヘッダデータが生成されるのを待つ必要がない。

いくつかの例では、そのようなサブセグメントは、独立して復号可能ではないことがある。すなわち、あるサブセグメントは必ずしも、当該先行サブセグメントに続くサブセグメントに対応し得る別のサブセグメントに含まれる参照情報なしに復号可能であるとは限らない。言い換えれば、サブセグメントは将来のサブセグメントを参照することがある。しかしながら、サブセグメントは、独立して復号可能な一定の情報を含んでいることがある。たとえば、サブセグメントは、独立して復号可能なビデオデータの1つまたは複数のIフレームを含んでいることがある。

本開示の態様によれば、サブセグメントは、サブセグメントヘッダおよび1つまたは複数のデータユニットを含み得る。サブセグメントヘッダは、サブセグメントのデータユニットを指すポインタのテーブルを含み得る。しかしながら、上記のように、サブセグメントのデータユニットは、先行するサブセグメントまたは将来のサブセグメントを参照することがある。たとえば、サブセグメントのデータユニットは、先行するサブセグメントまたは将来のサブセグメントのフレーム(あるいはスライス)を参照するPまたはBフレーム(あるいはPまたはBスライス)を含み得る。すなわち、サブセグメントのデータユニットは、同じセグメントの後続のサブセグメントのデータユニットに関連して予測され得る。このタイプの予測関係は、セグメントの第2のサブセグメントを参照するセグメントの第1のサブセグメントのデータユニットの一例を表し、この場合、第1のサブセグメントはクライアントデバイスによって、第2のサブセグメントの前に受信され得る。

いくつかの例では、各サブセグメントは、サブセグメントヘッダを含み得る。たとえば、サブセグメントヘッダは、ビデオ/オーディオ符号化フォーマット、品質レベルなどのような「固定」部分を含み得る。場合によっては、セグメントのヘッダデータ、ならびにサブセグメントヘッダのデータは、セグメント間および/またはサブセグメント間で変化しないことがある。したがって、本開示のいくつかの態様では、ヘッダデータが変化しているかどうかを示すフラグの値を、サーバデバイスは設定することができ、クライアントデバイスは解釈することができる。たとえば、サーバデバイスは、セグメントまたはサブセグメントヘッダが先行セグメントまたは先行サブセグメントと実質的に同様のデータまたは同じデータを含むことを示す「0」にフラグを設定し得る。サーバデバイスは、セグメントまたはサブセグメントヘッダが変化していることを示す「1」にフラグを設定し得る。さらに、クライアントデバイスは、フラグを受信し、あるセグメントから別のセグメントにかけてヘッダデータが変化しているかどうかを解釈することができる。

ビデオデータの複数のサブセグメントを生成し、サブセグメントが形成/符号化されるとそれらをすぐに送信することにより、レイテンシ(たとえば、ストリーミング環境におけるメディアデータの送信、受信、復号、および/または表示に関連するレイテンシ)を低減することができる。たとえば、クライアントデバイスは、サブセグメントの少なくとも一部分を、サブセグメントを受信すると直ちに復号し始めることができる。すなわち、サブセグメントのいくつかのデータユニットは、まだ受信されていない他のサブセグメントのデータユニットを参照し得るが、クライアントデバイスは、データユニットのうちのいくつか(たとえば、サブセグメントに含まれるIフレーム)を直ちに復号し始めることができる。さらに、クライアントデバイスは、一般にサブセグメントに続いてセグメントに関するヘッダを受信すると、セグメント全体を復号し、プレイアウトする準備ができる。

いくつかの例では、本開示の態様に従って複数のサブセグメントを生成し、1つのサブセグメントが形成されるとそれをすぐに送信することは、単にセグメント持続時間全体を短縮するよりも効率的であり得る。すなわち、説明のために上記で提供した例では、セグメントはビデオデータの1秒を含むことができ、これは丸々1秒のレイテンシをもたらし得る。すなわち、セグメントが送信前に完全に形成され、セグメントが再生前に完全に受信され、復号される場合に、丸々1秒のレイテンシがもたらされ得る。レイテンシを低減する1つの方法として、セグメントの持続時間全体を減らすことが考えられる。すなわち、サーバデバイスは、1秒のセグメントを符号化し、送信するのではなく、500ミリ秒のセグメントを符号化し、送信することができる。したがって、この例では、エンドツーエンドレイテンシが1秒から500ミリ秒に低減され得る。

しかしながら、セグメント持続時間を短縮することによってレイテンシを低減すると、ビットストリームにおけるオーバーヘッドデータの割合が増大する(たとえば、それにより効率性が低下する)ことがある。たとえば、上記のように、各セグメントは、セグメント持続時間に生成されるビデオ/オーディオサンプルの数とともにサイズが拡大する部分のほか、固定部分を含むヘッダを含む。セグメント持続時間の減少に伴い、ヘッダの固定部分がもたらす、データを送信することに関連するオーバーヘッドの部分が(比例して)大きくなり始める。一定のビットレートを仮定すれば、オーバーヘッドが増大するのに伴って、実際のメディアデータに使用されるビットが少なくなり得るので、総合効率が低下する。

さらに、いくつかの例では、メディアデータのセグメントは、別のセグメントを参照するのを回避するように構築され得る。すなわち、マルチメディアコンテンツの各セグメントは、いくつかの例では、他のセグメントのデータを参照せず(たとえば、あるセグメントのPフレームまたはBフレームは、別のセグメントのフレームを参照しない)、したがって独立して復号可能であり得る。したがって、そのような例では、セグメント持続時間を短縮するとき、Iフレームの数が増加する一方で、PフレームおよびBフレームの数が減少する。Iフレームが比例的に増加しているビデオデータは、たとえば、Pフレームおよび/またはBフレームの割合が大きくなっているビデオデータほどには、時間的冗長性を利用しない。したがって、所与の平均レートでは、Iフレームの数と表示されるビデオデータの知覚品質との間には反比例関係があり得る。すなわち、可変ビットレートを使用してコード化されているビデオデータは一般に、より固定的なビットレートを使用してコード化されているビデオデータの場合よりも、高い知覚品質を示す。

したがって、本開示の態様を使用して、(所与のレートを有する)所与のセグメントの持続時間を維持しつつ、レイテンシを低減することもできる。すなわち、上記の1秒のセグメント持続時間の例において、本開示の態様は、1秒のセグメント持続時間を維持しつつ、セグメントの送信および復号/表示に関連するレイテンシを1秒未満に低減することに関係する。このようにして、メディアデータの知覚品質を維持しつつ、レイテンシを低減することもできる。

本開示の技法は、ブロードキャストネットワーク送信を介したDASHまたは他のストリーミングネットワークプロトコルによるマルチメディアデータの送信に使用され得る。たとえば、サーバデバイスは、ブロードキャストを介した1つまたは複数のクライアントデバイスへの送信に向けて、複数のサブセグメントを有するセグメントを準備することができる。クライアントデバイスは、いくつかの例では、上記で説明したようにセグメントのサブセグメントを含むブロードキャストネットワーク送信を受信することができる。

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

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

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

オーディオエンコーダ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規格はさらに実現する。

プロファイルに準拠するデコーダは普通、プロファイル中で定義されるすべての機能をサポートする。たとえば、コーディング機能として、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ユニットであり得る。いくつかの例では、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に送信することができる。図1の例では、サーバデバイス60は、各々がそれぞれのマニフェストファイル66および1つまたは複数の表現68A〜68N(表現68)を含む様々なマルチメディアコンテンツ64を記憶する、記憶媒体62を含む。いくつかの例では、出力インターフェース32はネットワーク74にデータを直接送ることもできる。

いくつかの例では、本開示のいくつかの態様によれば、カプセル化ユニット30は、本明細書で説明する技法に従ってデータのサブセグメントを形成するように構成され得る。すなわち、たとえば、カプセル化ユニット30は、メディアデータのセグメントを複数のサブセグメントに分割するように構成され得る。カプセル化ユニット30はサブセグメントを、サブセグメントが形成されるとすぐに出力インターフェース32に提供することができる。次いで、出力インターフェース32はサブセグメントを、ネットワーク74を介してクライアントデバイス40に送ることができる。

そのような例では、カプセル化ユニット30は、独立して復号可能ではないサブセグメントを生成し得る。すなわち、カプセル化ユニット30は、サブセグメントであって、当該先行サブセグメントに続くサブセグメントに対応し得る別のサブセグメントに含まれる参照情報(たとえば、予測情報)なしに復号できるとは限らないサブセグメントを生成し得る。後続サブセグメントの予測情報は、この例では、先行サブセグメントを予測するために使用される後続サブセグメントのブロックまたはスライスのピクセルデータを含むことができる。言い換えれば、カプセル化ユニット30は、将来のサブセグメントを参照するサブセグメントを形成することができる。

カプセル化ユニット30は、セグメントのすべてのサブセグメントに適用されるセグメントヘッダ、ならびにセグメントに含まれるサブセグメントの各々に関するサブセグメントヘッダを生成することができる。以下でより詳細に説明するように、サブセグメントヘッダは、サブセグメント内におけるデータユニットのロケーションを識別するポインタのテーブルを含み得る。さらに、カプセル化ユニット30は、セグメントヘッダデータが変化しているかどうか(たとえば、セグメントヘッダデータが、以前生成されたセグメントと異なるかどうか)を示すフラグを設定することができる。

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

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

サーバデバイス60は、要求処理ユニット70およびネットワークインターフェース72を含む。いくつかの例では、サーバデバイス60は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス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要求を含む。要求処理ユニット70はさらに、表現68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成され得る。いずれの場合でも、要求処理ユニット70は、クライアントデバイス40のような要求デバイスに、要求されたデータを提供するために、要求を処理するように構成され得る。

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

特に、取出しユニット52は、クライアントデバイス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の変化するネットワーク帯域幅の利用可能性に適応することもできる。

ネットワークインターフェース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を含む装置は、集積回路、マイクロプロセッサ、および/または携帯電話のようなワイヤレス通信デバイスを含み得る。

本開示の態様は一般に、ネットワーク74を通じてサーバデバイス60からクライアントデバイス40にメディアデータの1つまたは複数のセグメントをストリーミングすることに関連するレイテンシを最小化することを対象とする。すなわち、本開示の態様によれば、サーバデバイス60は、メディアデータのセグメントを、ネットワーク74を通じた送信に適した複数のサブセグメントに分割することができる。この例では、サーバデバイス60はサブセグメントを、サブセグメントが形成されるとすぐに送信することができる。すなわち、サーバデバイス60は、サブセグメントを送信する前に、2つ以上のサブセグメントが形成されるのを待つ必要がない。さらに、サーバデバイス60は、サブセグメントを送信する前に、サブセグメントのすべてに関するヘッダデータが生成されるのを待つ必要がない。

サブセグメントの形成および/または送信など、サーバデバイス60に起因するいくつかの機能が、1つまたは複数の他の構成要素またはデバイスによって実行され得ることを理解されたい。すなわち、別の例では、コンテンツ準備デバイス20は、ネットワーク74を通じてサブセグメントを形成し、送る役割を担い得る。追加または代替として、いくつかの例によれば、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスに高度に統合されるか、または組み込まれ得る。したがって、コンテンツ準備デバイス20、サーバデバイス60、またはそのようなデバイスの組合せはサブセグメントを準備し、サブセグメントが形成されるとそれらをすぐにクライアントデバイス40などのクライアントデバイスに送ることができる。さらに、そのようなデバイスは、ブロードキャストまたはマルチキャストネットワーク送信でサブセグメントを送ることができる。

クライアントデバイス40は、本開示の態様に従って形成されたサブセグメントを受信し、サブセグメントの少なくとも一部分を直ちに復号し始めるように構成され得る。すなわち、サブセグメントのいくつかのデータユニットは、まだ受信されていない他のサブセグメントのデータユニットを参照し得るが、クライアントデバイス40は、データユニットのうちのいくつか(たとえば、サブセグメントに含まれるIフレーム)を直ちに復号し始めることができる。いくつかの例では、1つのサブセグメントのデータユニットは、後続サブセグメントの後続データユニットを、後続データユニットを指す運動ベクトルをブロックが含み得るので、参照することができる。さらに、クライアントデバイス40は、一般にサブセグメントに続いてセグメントに関するヘッダを受信すると、セグメント全体を復号し、プレイアウトする準備ができる。すなわち、クライアントデバイス40は一般に、セグメントに関するヘッダを受信する前に、セグメントのサブセグメントのすべてを受信する。

ビデオデータの複数のサブセグメントを生成し、サブセグメントが符号化されるとそれらをすぐに送信することで、サーバデバイス60によるセグメントの送信、ならびにクライアントデバイス40によるセグメントの受信、復号、および/または表示に関連するレイテンシを低減することができる。

図2は、取出しユニット52に関連する例示的な構成要素を示すブロック図である。図2の取出しユニット52は、取出しユニット52(図1)に対応するか、または別の異なる取出しデバイスに含まれ得る。この例では、取出しユニット52は、ストリーム管理ユニット80およびソース構成要素90を含む。ソース構成要素90は、メディアファイル記憶処理ユニット92、MPDパーシングユニット94、メディアファイル逆多重化(demux)ユニット96および適応ユニット98およびHTTPコントローラ100を含む。

一般に、取出しユニット52は、特定の通信プロトコルを使用して通信するか、または特定の物理媒体と対話するためのハードウェアおよび/またはソフトウェアを含むことができる。たとえば、取出しユニット52は、HTTPを実装し、HTTPスタックを使用してデータを受信することができ、このHTTPスタックは、TCP/IPならびにネットワークの他の層に関する他の通信プロトコルを含み得る。取出しユニット52は、たとえばサーバデバイス60に対しセグメント(またはセグメントの部分)を求めるHTTP Get要求または部分Get要求をさらに生成することができる。取出しユニット52はまた、ブロードキャストまたはマルチキャストネットワーク送信からデータを受信するために、ブロードキャストまたはマルチキャストプロトコル、たとえばeMBMSまたはIPマルチキャストを実装することができる。取出しユニット52は、送信のデータを取り出すために、ブロードキャストまたはマルチキャストネットワーク送信に加入するように構成され得る。

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

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

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

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

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

図2の例では、ソース構成要素90はメディアファイル逆多重化(demux)ユニット96を含み、これは受信されたデータを、たとえばそれぞれのオーディオストリームおよびビデオストリームに逆多重化することができる。メディアファイル記憶処理ユニット92は、受信されたデータを、取出しユニット52を含むデバイスのメモリ(図示せず)にバッファリングすることができる。メディアファイル記憶処理ユニット92は、逆多重化されたデータを、たとえば、オーディオデコーダ46およびビデオデコーダ48(図1)に提供することもできる。あるいは、メディアファイル記憶処理ユニット92は、取り出されたメディアデータを、データを逆多重化せずにクライアントデバイス40に提供することができる。

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

取出しユニット52がHTTPに従ってデータを受信している例では、適応ユニット98がHTTPコントローラ100と通信して、帯域幅適応を実行することができる。たとえば、適応ユニット98は、HTTPコントローラ100と通信し、マルチメディアコンテンツに関するマニフェストファイルから、マルチメディアコンテンツのマルチメディアデータの取出し元になる表現を選択することができる。マニフェストファイルは、マルチメディアコンテンツの複数の表現を示す情報を含むことができ、複数の表現は、選択された表現を含むことができる。特に、マニフェストファイルは、表現のビットレートを記述している情報を含むことができ、それにより適応ユニット98は、ネットワーク帯域幅の現在利用可能な量を踏まえ、表現のビットレートに基づいて適切な表現を選択することができる。当然のこととして、上記で説明したように、ソース構成要素ではなくストリーム管理ユニットが表現を選択するように構成されてもよいことを理解されたい。さらに、いくつかの例では、ソース構成要素およびストリーム管理ユニットは機能的に統合され得る。

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

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

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

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

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

本開示の態様によれば、セグメント114、124の各々は、図4に関して図示し説明するように、複数のサブセグメントにさらに分割され得る。マルチメディアコンテンツ102が完全に形成された後、ヘッダデータ112、122は、いくつかの例では、上記で説明したようにIDR NALユニットなどの特定のNALユニットへのポインタを含み得る。しかしながら、本開示の技法に従って、表現110、120のサブセグメントが準備され次第送信されるとき、ヘッダデータ112、122は、セグメント114、124が完全に形成されるまで利用できない場合があることを理解されたい。それでも、本開示で論じるように、セグメント114、124のサブセグメントのデータは、ヘッダデータ112、122が利用可能になる前に送信され得る。

図4は、本開示の態様による、例示的なセグメント200を示す概念図である。セグメント200は、図3に示すセグメント114および/または124に対応することができ、マルチメディアコンテンツ64(図1)、またはメモリ62に記憶された別のマルチメディアコンテンツの少なくとも一部分を含み得る。図4のいくつかの態様は、図1に示す構成要素に関して説明されることがあるが、セグメント200は、いくつかの異なる構成要素を有するいくつかの異なる環境で実装され得ることを理解されたい。

図4の例では、セグメント200は、セグメントヘッダ202、サブセグメント204A、サブセグメント204B(まとめてサブセグメント204と呼ぶ)、ならびに(省略記号によって示される)潜在的にいくつかの追加のサブセグメントを含む。本開示の態様によれば、セグメントヘッダ202は、セグメント200のすべてのサブセグメント204に共通する情報を含むことができる。たとえば、セグメントヘッダ202は、クライアントデバイス40などのデバイスがセグメント200を復号および/またはレンダリングするのを支援する一定の情報を含むことができる。すなわち、セグメントヘッダ202は、セグメント200のオーディオデータに関する符号化フォーマット、セグメント200のビデオデータに関する符号化フォーマット、セグメント200に関するビットレート、セグメント200に関する品質レベル、セグメント200のビデオデータの解像度、セグメント200のビデオデータのフレームレートなどを示すデータを含むことができる。本開示のいくつかの態様によれば、そのようなデータの一部分は、後述のようにサブセグメントヘッダに含まれ得る。いくつかの例では、セグメントヘッダ202は、すべてのサブセグメント204が送信された後に送信される。他の例では、セグメントヘッダ202は、サブセグメント204が送信される前に送信される。

いくつかの例では、本開示の態様によれば、セグメントヘッダ202は、セグメントヘッダ202のデータが変化しているかどうかを示すフラグを含み得る。すなわち、セグメントヘッダフラグは、セグメントヘッダ202のデータが以前受信され復号されたセグメントヘッダから変化しているかどうかを示すことができる。サーバデバイス60などのデバイスは、セグメントヘッダ202のデータが変化していないことを示す「0」にセグメントヘッダフラグを設定することができ、セグメントヘッダのデータが変化していることを示す「1」にセグメントヘッダフラグを設定することができる。ヘッダデータが変化していない場合(フラグ=0)、サーバデバイス60は、セグメントヘッダ202に追加情報を含めることを省略することができる。一方、ヘッダデータが変化している場合(フラグ=1)、サーバデバイス60は、セグメントヘッダフラグの後、ヘッダデータを含めることができる。

図4に示す例では、サブセグメント204Aは、それぞれデータユニット210Aおよび210B(まとめてデータユニット210)の相対ロケーションを識別するデータユニットポインタ208Aおよび208B(まとめてデータユニットポインタ208)を有するサブセグメントヘッダ206を含む。いくつかの例では、サブセグメントヘッダ206は、セグメントヘッダ202に関して上述したデータの一部分を含み得る。ただし、(たとえば、符号化フォーマットなどの)頻繁には変化しないデータは通常、サブセグメントヘッダ206に含まれない。

本開示のいくつかの態様によれば、サブセグメントヘッダ206は、サブセグメント204A内のデータユニット210の各々のオフセットを識別するデータユニットポインタ208のテーブルを含む。たとえば、オフセットは、サブセグメント204A内のデータユニットの相対位置を提供し得る。オフセットはまた、データユニットの復号されたデータを提示する際の適切な順序の指示を提供し得る(ただし、いくつかの例では、データユニットは、提示/表示順序では符号化されず、送信されないことがある)。

データユニット210は一般に、非VCL NALユニットまたはVCL NALユニットを含み、これらは符号化メディアデータを含み得る。メディアデータがビデオデータである例では、データユニット210は、ビデオデータのフレームまたはスライスを含むことができる。本開示の態様によれば、サブセグメント204Aなどのサブセグメントは、独立して復号可能ではないことがある。たとえば、データユニット210のうちの1つまたは複数は、1つまたは複数の他のサブセグメントに含まれる1つまたは複数のデータユニット(たとえば、サブセグメント204Bのデータユニット216など)を参照し得る。すなわち、データユニット210がビデオデータを含む例では、データユニット210のうちの1つまたは複数は、たとえば、他のサブセグメントの予測データを識別する運動ベクトルを使用して、1つまたは複数の他のサブセグメントに含まれる1つまたは複数のデータユニットのビデオデータを参照するPフレームまたはBフレームとして符号化され得る。このようにして、運動ベクトルは、あるサブセグメントのデータユニットから別のサブセグメントのデータユニットへの参照の例を表す。変位ベクトル、スケーラブルビデオコーディング(SVC)技法、シンタックス要素を予測するためのシンタクティック予測、または他のそのような参照など、他のタイプの参照もあり得る。したがって、いくつかの例では、データユニット210のうちの1つまたは複数は、将来のサブセグメント(たとえば、Bフレーム)を参照し得る。ただし、データユニット210は、(たとえば、他のサブセグメントを参照せずに)独立して復号可能な一定の情報を含むこともできる。たとえば、データユニット210のうちの1つまたは複数は、独立して復号可能なビデオデータのIフレームであり得る。

図4に示す例では、サブセグメント204Bは、サブセグメント204Aと同様に構成される。すなわち、サブセグメント204Bは、データユニット216Aおよび216Bを識別するデータユニットポインタ214Aおよび214Bを有するサブセグメントヘッダ212を含む。いくつかの例では、本開示の態様によれば、上述のセグメントヘッダ202と同様に、サブセグメント204は、サブセグメントヘッダ206、212のデータが変化しているかどうかを示すフラグを含み得る。図4に示す例では、サブセグメントヘッダ212は、以前に受信されたサブセグメントヘッダ206のデータが変化しているかどうかを示すフラグ(たとえば、フラグ=0の場合、データは変化しておらず、フラグ=1の場合、データは変化している)を含むことができる。したがって、サブセグメントヘッダデータが変化しない例では、ヘッダデータによって消費されるビットの数が減少し得る。

本明細書で説明する技法に従ってセグメント200を利用することで、(たとえば、複数のサブセグメントを含まないセグメントと比較して)レイテンシを低減することができる。すなわち、本開示の態様によれば、サーバデバイス60またはコンテンツ準備デバイス20など、ネットワークを通じてセグメントを送信する役割を担うデバイス(あるいはサーバデバイス60とコンテンツ準備デバイス20の両方の機能を実装しているデバイス)はサブセグメント204Aを、サブセグメント204Aが形成されるとすぐに(たとえば、サブセグメント204Aの最後のデータユニットが受信/符号化されるとすぐに)送信することができる。すなわち、サーバデバイス60は、サブセグメント204Aを送信する前に、複数のサブセグメントが形成されるのを待つ必要がない。さらに、サーバデバイス60は、サブセグメント204Aを送信する前に、セグメントヘッダ202が完成するのを待つ必要がない。

サブセグメント204が形成/符号化されるとすぐにサブセグメント204を送信することで、クライアントデバイス40などのクライアントデバイスは、サブセグメント204を受信するとサブセグメント204の少なくとも一部分を直ちに復号し始めることができるので、レイテンシが低減され得る。すなわち、図4に示す例では、サブセグメント204Aのいくつかのデータユニット210は、サブセグメント204Bのデータユニット216のうちの1つまたは複数を参照することができる一方、クライアントデバイスはサブセグメント204Aのデータユニット210のうちのいくつか(たとえば、サブセグメント204Aに含まれるIフレーム)を直ちに復号し始めることができる。さらに、クライアントデバイス40は、一般にサブセグメント204A、204Bに続いてセグメント200に関するセグメントヘッダ202を受信すると、セグメント200全体を復号し、プレイアウトする準備ができる。すなわち、クライアントデバイス40は、サブセグメント204Aおよび204Bをすでに受信しており、セグメントヘッダ202を受信すると直ちに復号し始める準備ができる。

本開示の技法によれば、一例では、セグメント200は、下に示すTable 2(表2)に従って構成され得る。

本開示のいくつかの態様によれば、セグメント200は、ブロードキャストネットワーク送信を介してDASHまたは他のストリーミングネットワークプロトコルに従ってマルチメディアデータを送信するように構成され得る。たとえば、サーバデバイス60は、ブロードキャストを介した1つまたは複数のクライアントデバイス40への送信に向けて、複数のサブセグメント204を有するセグメント200を準備することができる。クライアントデバイス40は、いくつかの例では、上記で説明したようにセグメント200のサブセグメント204を含むブロードキャストネットワーク送信を受信することができる。

図4は、サブセグメント204Aおよび204Bが同様に構成されるものとして示しているが、いくつかの例では、表現のセグメントは同様に構成されたセグメントを含まない場合があることを理解されたい。たとえば、表現は、サブセグメントに分割されている1つまたは複数のセグメント、ならびに分割されない1つまたは複数のサブセグメントを含むことができる。

図5は、本開示で説明する技法による、例示的な方法を示すフローチャートである。図5の方法は、コンテンツ準備デバイス20およびクライアントデバイス40(図1)に関して説明しているが、他のデバイスが図5の方法の技法と同様の技法を実施できることを理解されたい。たとえば、サーバデバイス60またはコンテンツ配信ネットワークの1つもしくは複数のネットワークデバイスは、サーバデバイス60に起因する機能の一部または全部を実行することができる。

コンテンツ準備デバイス20(これは、クライアントデバイスにコンテンツを提供できるので、一般に「サーバデバイス」と呼ばれることがある)は最初に、マルチメディアコンテンツの表現に関するデータを取得する(260)ことができる。より具体的には、コンテンツ準備デバイス20は、マルチメディアコンテンツの所与の表現に関するメディアデータのセグメントを取得することができる。本開示のいくつかの態様によれば、コンテンツ準備デバイス20は、メディアデータのセグメントに関連するヘッダデータが変化しているかどうかを示すフラグを生成する(261)ことができる。すなわち、コンテンツ準備デバイス20は、セグメントのヘッダデータが以前に符号化されたセグメント(そのようなセグメントが存在する場合)のヘッダデータとは異なるかどうかを示すことができる。コンテンツ準備デバイス20は、ヘッダデータが変化していないことを示す「0」の値に、セグメントヘッダフラグを設定することができ、またはヘッダデータが異なる(たとえば、しかるべきヘッダデータが後に続く)ことを示す「1」の値に、セグメントヘッダフラグを設定することができる。

次いでコンテンツ準備デバイス20は、第1のサブセグメントを形成する(262)ことができる。たとえば、コンテンツ準備デバイス20は、第1のサブセグメントに含まれる1つまたは複数のデータユニットを識別するデータユニットポインタを含むサブセグメントヘッダを有する、図4に示すサブセグメント204と同様のサブセグメントを形成することができる。さらに、上記のように、サブセグメントは独立して復号可能ではないことがある。すなわち、第1のサブセグメントは、1つまたは複数の他のサブセグメント(ならびに、後述する第2のサブセグメントなどの将来のサブセグメント)の1つまたは複数のデータユニットを参照する1つまたは複数のデータユニットを含むことができる。

形成されると、コンテンツ準備デバイス20はクライアントデバイス40に第1のサブセグメントを送る(264)。本開示の態様によれば、コンテンツ準備デバイス20は、第1のサブセグメント(ならびに後続のサブセグメント)をブロードキャストすることができる。コンテンツ準備デバイス20が第1のサブセグメントを送信した後、クライアントデバイス40は、第1のサブセグメントを受信する(266)。いくつかの例では、クライアントデバイス40は、第1のサブセグメントを復号に向けて準備する(268)ことができる。たとえば、クライアントデバイス40は第1のサブセグメントを、セグメントヘッダデータを受信すると第1のセグメントが直ちに復号され得るように、復号に向けてバッファリングあるいは準備することができる。

さらに、コンテンツ準備デバイス20は、第2のサブセグメントを形成する(272)。第2のサブセグメントは、上述の第1のサブセグメントと同様の方法で形成され得る。形成後、コンテンツ準備デバイス20は、第2のサブセグメントを(サブセグメントヘッダデータとともに)クライアントデバイス40に送る(274)ことができる。次いでクライアントデバイス40は、第2のサブセグメントを受信する(276)。いくつかの例では、クライアントデバイス40は第2のサブセグメントを、第1のサブセグメントに関して上述した方法と同様の方法による復号に向けて準備する(278)ことができる。

第2のサブセグメントを形成し送信した後、コンテンツ準備デバイス20は、サブセグメントのすべて(たとえば、図5の例では、第1のサブセグメントおよび第2のサブセグメント)に適用可能なセグメントヘッダを形成する(280)ことができる。コンテンツ準備デバイス20はまた、クライアントデバイス40にセグメントヘッダを送る(282)ことができる。次いでクライアントデバイス40は、セグメントヘッダを受信し(284)、第1のサブセグメントおよび第2のサブセグメントを復号する(286)ことができる。すなわち、クライアントデバイス40は、以前に受信されたサブセグメントの各々を復号することができる。

このようにして、図5の方法は、マルチメディアデータのセグメントの第1のサブセグメントを受信するステップであって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、ステップを含む方法の例を表す。本方法はまた、第1のサブセグメントを受信した後、第2のサブセグメントを受信するステップであって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、ステップと、第1のサブセグメントおよび第2のサブセグメントを受信した後、セグメントを処理するステップとを含む。

さらに、図5の方法は、マルチメディアデータのセグメントの第1のサブセグメントを送るステップであって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、ステップを含む方法の例を表す。本方法はまた、第1のサブセグメントを送った後、第2のサブセグメントを送るステップであって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、ステップを含む。

図5に関して図示し説明したステップは、単に一例として提供されていることも理解されたい。すなわち、図5の方法のステップは、必ずしも図5に示す順序で実行される必要はなく、より少ない、追加の、または代替的なステップが実行されてよい。一例では、図5に関して図示し説明した方法は、第1のサブセグメントおよび第2のサブセグメントを含む。ただし、他の例では、メディアデータの3つ以上のサブセグメントを、サーバデバイスは準備することができる(また、クライアントデバイスは受信することができる)。

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 システム
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 ネットワーク
80 ストリーム管理ユニット
90 ソース構成要素
92 メディアファイル記憶処理ユニット
94 MPDパーシングユニット
96 メディアファイル逆多重化(demux)ユニット
98 適応ユニット
100 HTTPコントローラ
102 マルチメディアコンテンツ
104 メディアプレゼンテーション記述、MPD
110 表現
112 ヘッダデータ
114 セグメント
114A セグメント
114N セグメント
120 表現
122 ヘッダデータ
124 セグメント
124A セグメント
124N セグメント
200 セグメント
202 セグメントヘッダ
204 サブセグメント
204A サブセグメント
204B サブセグメント
206 サブセグメントヘッダ
208 データユニットポインタ
208A データユニットポインタ
208B データユニットポインタ
210 データユニット
210A データユニット
210B データユニット
212 サブセグメントヘッダ
214A データユニットポインタ
214B データユニットポインタ
216 データユニット
216A データユニット
216B データユニット

Claims

動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に、前記動的適応ストリーミングオーバーHTTPセグメントの第1のサブセグメントを送信するステップであって、前記第1のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第1のセットを含む、ステップと、
前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に、前記動的適応ストリーミングオーバーHTTPセグメントの第2のサブセグメントを送信するステップであって、前記第2のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第2のセットを含む、ステップと、
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを送信するステップであって、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダは、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含む、ステップと
を含み、
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの少なくとも1つのコード化されたメディアサンプルが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの少なくとも1つのコード化されたメディアサンプルを参照する、方法。
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの前記少なくとも1つのコード化されたメディアサンプルを、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの前記少なくとも1つのコード化されたメディアサンプルに関連して符号化するステップをさらに含み、
前記第1のサブセグメントを送信するステップが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットを符号化するのを終える前に、前記第1のサブセグメントを送信するステップを含む、請求項1に記載の方法。
前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含むように前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを生成するステップであって、前記情報が、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット、および
前記1つまたは複数のコード化されたメディアサンプルの第2のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット
のうちの少なくとも1つを示す情報を含む、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される、ステップをさらに含む、請求項1に記載の方法。
前記セグメントのオーディオデータのための符号化フォーマット、前記セグメントのビデオデータのための符号化フォーマット、前記セグメントのためのビットレート、前記セグメントのための品質レベル、前記セグメントのビデオデータの解像度、および前記セグメントのビデオデータのフレームレートのうちの少なくとも1つを示す情報を含むように、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを生成するステップをさらに含む、請求項1に記載の方法。
1つまたは複数のプロセッサを含む装置であって、
動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に、前記動的適応ストリーミングオーバーHTTPセグメントの第1のサブセグメントを送信することであって、前記第1のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第1のセットを含む、ことと、
前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に、前記動的適応ストリーミングオーバーHTTPセグメントの第2のサブセグメントを送信することであって、前記第2のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第2のセットを含む、ことと、
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを送信することであって、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダは、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含む、こと
を行うように構成され、
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの少なくとも1つのコード化されたメディアサンプルが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの少なくとも1つのコード化されたメディアサンプルを参照する、装置。
前記1つまたは複数のプロセッサが、
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの前記少なくとも1つのコード化されたメディアサンプルを、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの前記少なくとも1つのコード化されたメディアサンプルに関連して符号化するようにさらに構成され、
前記第1のサブセグメントを送信することが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットを符号化するのを終える前に、前記第1のサブセグメントを送信することを含む、請求項5に記載の装置。
前記1つまたは複数のプロセッサが、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含むように前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを生成するようにさらに構成され、前記情報が、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット、および
前記1つまたは複数のコード化されたメディアサンプルの第2のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット
のうちの少なくとも1つを示す情報を含む、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される、請求項5に記載の装置。
前記1つまたは複数のプロセッサが、
前記セグメントのオーディオデータのための符号化フォーマット、前記セグメントのビデオデータのための符号化フォーマット、前記セグメントのためのビットレート、前記セグメントのための品質レベル、前記セグメントのビデオデータの解像度、および前記セグメントのビデオデータのフレームレートのうちの少なくとも1つを示す情報を含むように、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを生成するようにさらに構成される、請求項5に記載の装置。
実行時に1つまたは複数のプロセッサに動作を行わせる命令を記録するコンピュータ可読記録媒体であって、前記動作が、
動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に、前記動的適応ストリーミングオーバーHTTPセグメントの第1のサブセグメントを送信するステップであって、前記第1のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第1のセットを含む、ステップと、
前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に、前記動的適応ストリーミングオーバーHTTPセグメントの第2のサブセグメントを送信するステップであって、前記第2のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第2のセットを含む、ステップと、
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを送信するステップであって、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダは、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含む、ステップと
を含み、
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの少なくとも1つのコード化されたメディアサンプルが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの少なくとも1つのコード化されたメディアサンプルを参照する、コンピュータ可読記録媒体。
前記動作が、
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの前記少なくとも1つのコード化されたメディアサンプルを、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの前記少なくとも1つのコード化されたメディアサンプルに関連して符号化するステップをさらに含み、
前記第1のサブセグメントを送信するステップが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットを符号化するのを終える前に、前記第1のサブセグメントを送信するステップを含む、請求項9に記載のコンピュータ可読記録媒体。
前記動作が、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含むように前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを生成するステップであって、前記情報が、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット、および
前記1つまたは複数のコード化されたメディアサンプルの第2のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット
のうちの少なくとも1つを示す情報を含む、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される、請求項9に記載のコンピュータ可読記録媒体。
前記動作が、
前記セグメントのオーディオデータのための符号化フォーマット、前記セグメントのビデオデータのための符号化フォーマット、前記セグメントのためのビットレート、前記セグメントのための品質レベル、前記セグメントのビデオデータの解像度、および前記セグメントのビデオデータのフレームレートのうちの少なくとも1つを示す情報を含むように、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを生成するステップをさらに含む、請求項9に記載のコンピュータ可読記録媒体。
動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に、前記動的適応ストリーミングオーバーHTTPセグメントの第1のサブセグメントを送信するための手段であって、前記第1のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第1のセットを含む、手段と、
前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に、前記動的適応ストリーミングオーバーHTTPセグメントの第2のサブセグメントを送信するための手段であって、前記第2のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第2のセットを含む、手段と、
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを送信するための手段であって、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダは、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含む、手段と
を含み、
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの少なくとも1つのコード化されたメディアサンプルが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの少なくとも1つのコード化されたメディアサンプルを参照する、装置。
動的適応ストリーミングオーバーHTTPセグメントの第1のサブセグメントを受信するステップであって、前記第1のサブセグメントは、前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に送信され、前記第1のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第1のセットを含む、ステップと、
前記動的適応ストリーミングオーバーHTTPセグメントの第2のサブセグメントを受信するステップであって、前記第2のサブセグメントは、前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に送信され、前記第2のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第2のセットを含む、ステップと、
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを受信するステップであって、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダは、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含む、ステップと、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するステップと
を含み、
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの少なくとも1つのコード化されたメディアサンプルが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの少なくとも1つのコード化されたメディアサンプルに関連して符号化された、方法。
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダの前記情報が、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット、および
前記1つまたは複数のコード化されたメディアサンプルの第2のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット
のうちの少なくとも1つを示す情報を含む、請求項14に記載の方法。
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダの前記情報が、前記セグメントのオーディオデータのための符号化フォーマット、前記セグメントのビデオデータのための符号化フォーマット、前記セグメントのためのビットレート、前記セグメントのための品質レベル、前記セグメントのビデオデータの解像度、および前記セグメントのビデオデータのフレームレートのうちの少なくとも1つを示す情報を含む、請求項14に記載の方法。
1つまたは複数のプロセッサを含む装置であって、
動的適応ストリーミングオーバーHTTPセグメントの第1のサブセグメントを受信することであって、前記第1のサブセグメントは、前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に送信され、前記第1のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第1のセットを含む、ことと、
前記動的適応ストリーミングオーバーHTTPセグメントの第2のサブセグメントを受信することであって、前記第2のサブセグメントは、前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に送信され、前記第2のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第2のセットを含む、ことと、
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを受信することであって、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダは、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含む、ことと、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号することと
を行うように構成され、
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの少なくとも1つのコード化されたメディアサンプルが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの少なくとも1つのコード化されたメディアサンプルに関連して符号化された、装置。
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダの前記情報が、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット、および
前記1つまたは複数のコード化されたメディアサンプルの第2のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット
のうちの少なくとも1つを示す情報を含む、請求項17に記載の装置。
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダの前記情報が、前記セグメントのオーディオデータのための符号化フォーマット、前記セグメントのビデオデータのための符号化フォーマット、前記セグメントのためのビットレート、前記セグメントのための品質レベル、前記セグメントのビデオデータの解像度、および前記セグメントのビデオデータのフレームレートのうちの少なくとも1つを示す情報を含む、請求項17に記載の装置。
実行時に1つまたは複数のプロセッサに動作を行わせる命令を記録したコンピュータ可読記録媒体であって、前記動作は、
動的適応ストリーミングオーバーHTTPセグメントの第1のサブセグメントを受信するステップであって、前記第1のサブセグメントは、前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に送信され、前記第1のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第1のセットを含む、ステップと、
前記動的適応ストリーミングオーバーHTTPセグメントの第2のサブセグメントを受信するステップであって、前記第2のサブセグメントは、前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に送信され、前記第2のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第2のセットを含む、ステップと、
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを受信するステップであって、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダは、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含む、ステップと、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するステップと
を含み、
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの少なくとも1つのコード化されたメディアサンプルが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの少なくとも1つのコード化されたメディアサンプルに関連して符号化された、コンピュータ可読記録媒体。
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダの前記情報が、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット、および
前記1つまたは複数のコード化されたメディアサンプルの第2のセットの少なくとも1つのコード化されたメディアサンプルに対するオフセット
のうちの少なくとも1つを示す情報を含む、請求項20に記載のコンピュータ可読記録媒体。
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダの前記情報が、前記セグメントのオーディオデータのための符号化フォーマット、前記セグメントのビデオデータのための符号化フォーマット、前記セグメントのためのビットレート、前記セグメントのための品質レベル、前記セグメントのビデオデータの解像度、および前記セグメントのビデオデータのフレームレートのうちの少なくとも1つを示す情報を含む、請求項20に記載のコンピュータ可読記録媒体。
動的適応ストリーミングオーバーHTTPセグメントの第1のサブセグメントを受信するための手段であって、前記第1のサブセグメントは、前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に送信され、前記第1のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第1のセットを含む、手段と、
前記動的適応ストリーミングオーバーHTTPセグメントの第2のサブセグメントを受信するための手段であって、前記第2のサブセグメントは、前記動的適応ストリーミングオーバーHTTPセグメントが完全に形成される前に送信され、前記第2のサブセグメントは、1つまたは複数のコード化されたメディアサンプルの第2のセットを含む、手段と、
前記動的適応ストリーミングオーバーHTTPセグメントのヘッダを受信するための手段であって、前記動的適応ストリーミングオーバーHTTPセグメントのヘッダは、前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するのを支援するように構成される情報を含む、手段と、
前記1つまたは複数のコード化されたメディアサンプルの第1のセットおよび前記1つまたは複数のコード化されたメディアサンプルの第2のセットを復号するための手段と
を含み、
前記第1のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第1のセットのうちの少なくとも1つのコード化されたメディアサンプルが、前記第2のサブセグメントの前記1つまたは複数のコード化されたメディアサンプルの第2のセットのうちの少なくとも1つのコード化されたメディアサンプルに関連して符号化された、装置。