JP6254291B2 - Ｄａｓｈのロバストなライブ動作 - Google Patents

Description

本出願は、その内容全体が参照により本明細書に組み込まれている、2014年1月16日に出願した米国仮出願第61/928,381号の利益を主張するものである。

本開示は、コード化されたメディアの移送に関する。

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

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

ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化され得る。ビデオデータは、Carriage of NAL Unit structured Videoのような、国際標準化機構(ISO)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。

一般に、本開示は、動的適応ストリーミングオーバーHTTP(DASH)のロバストネスを改善するために使用され得る技法を説明する。具体的には、DASHストリーミングサーバ、または他のそのようなストリーミングサーバが1つもしくは複数のクライアントデバイスにストリーミングされるべきライブメディアデータを受信する場合が存在し得る。たとえば、DASHストリーミングサーバは、ライブベースで、たとえば、オンザフライでリアルタイムにコンテンツ製作者からメディアデータを受信することができる。コンテンツ製作者とDASHストリーミングサーバとの間の通信セッションは、信頼できない場合があり、たとえば、メディアデータを損失させる場合がある。本開示の技法は、サーバによって、その損失に対応するメディアデータが利用可能でないことを示すデータをシグナリングするステップを含む。このようにして、クライアントデバイスは、シグナリングされたデータを受信し、欠落しているメディアデータに対する要求を送ることを省くことができる。これらの技法は、サーバが利用可能でないと決定したデータに対する要求を回避することによって帯域幅消費を削減することができる。これらの技法はまた、要求されたメディアデータが利用可能でないことを示す、クライアントからのメディアデータに対する要求に応答した、サーバからの過剰な誤り応答による接続終了を防止することができる。

一例では、ストリーミングメディアデータに関するデータを受信する方法は、メディアコンテンツの第1の期間およびそのメディアコンテンツの第2の期間に対するデータを受信するステップであって、第1の期間に対するデータが、第1の期間の少なくとも一部のメディアデータが利用可能でないことを示し、第2の期間に対するデータが、第2の期間に対して利用可能なメディアデータを示す、受信するステップと、第1の期間および第2の期間に対するデータに基づいて、第1の期間に対するデータが利用可能でないことを示す第1の期間のメディアデータに対する要求を省き、第2の期間のメディアデータに対する1つまたは複数の要求を送るステップとを含む。

別の例では、ストリーミングメディアデータに関するデータを受信するためのデバイスは、ネットワークを介して、データを送受信するように構成された1つまたは複数のネットワークインターフェースと、そのネットワークインターフェースを介して、メディアコンテンツの第1の期間およびそのメディアコンテンツの第2の期間に対するデータを受信することであって、第1の期間に対するデータが、第1の期間の少なくとも一部のメディアデータが利用可能でないことを示し、第2の期間に対するデータが、第2の期間に対して利用可能なメディアデータを示す、受信することと、第1の期間および第2の期間に対するデータに基づいて、第1の期間に対するデータが利用可能でないことを示す第1の期間のメディアデータに対する要求を省き、第2の期間のメディアデータに関する1つまたは複数の要求を送ることとを行うように構成された、1つまたは複数のプロセッサとを含む。

別の例では、ストリーミングメディアデータに関するデータをシグナリングする方法は、メディアコンテンツの第1の部分が損失していること、およびそのメディアコンテンツの第2の部分が受信されていることを決定するステップと、メディアコンテンツの第1の期間の少なくとも一部のメディアデータが第1の期間に対して利用可能でないことを示す、少なくとも第1の部分を含む、第1の期間に対するデータをシグナリングし、メディアデータがそのメディアコンテンツの第2の期間に対して利用可能であることを示す、第2の部分に対応する、第2の期間に対するデータをシグナリングするステップと、そのデータをシグナリングした後、第2の期間のメディアデータに対する1つまたは複数の要求を受信するステップと、それらの要求に応答して、第2の期間の要求されたメディアデータを送るステップとを含む。

別の例では、ストリーミングメディアデータに関するデータをシグナリングするためのデバイスは、ネットワークを介して、データを送受信するように構成された1つまたは複数のネットワークインターフェースと、メディアコンテンツの第1の部分が損失していること、およびそのメディアコンテンツの第2の部分が受信されていることを決定することと、ネットワークインターフェースを介して、メディアコンテンツの第1の期間の少なくとも一部のメディアデータが第1の期間に対して利用可能でないことを示す、少なくとも第1の部分を含む、第1の期間に対するデータをシグナリングし、メディアデータがそのメディアコンテンツの第2の期間に対して利用可能であることを示す、第2の部分に対応する、第2の期間に対するデータをシグナリングすることと、そのデータをシグナリングした後、ネットワークインターフェースを介して、第2の期間のメディアデータに対する1つまたは複数の要求を受信することと、それらの要求に応答して、ネットワークインターフェースを介して、第2の期間の要求されたメディアデータを送ることとを行うように構成された、1つまたは複数のプロセッサとを含む。

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

ネットワークを通じてメディアデータをストリーミングするための技法を実施する、例示的なシステムを示すブロック図である。 例示的なマルチディアコンテンツの要素を示す概念図である。 本開示の技法を実行するためのシステムを示すブロック図である。 そのメディアデータがあるメディアコンテンツ期間に対して利用可能でないことを示す情報を交換するための例示的な方法を示すフローチャートである。

一般に、本開示は、動的適応ストリーミングオーバーHTTP(DASH)に関する技法、または他のHTTPストリーミングベース技法を説明する。ライブストリーミングの場合、DASH動作のロバストネスは以下の理由により被害を受ける場合がある。1.たとえば、クライアントクロックがシステムクロックに対してドリフトし、クライアントがタイムソース(time-source)に対して十分頻繁に同期していないときの不正確な時間同期クライアント。2.メディアプレゼンテーション記述(MPD)およびセグメント生成がDASHクライアントとは異なるタイムソースに対して同期される可能性があること。3.エンコーダまたはDASHメディアプレゼンテーションが同期を損失した可能性があるか、またはコンテンツを取得しないこと。例は、a.同期の損失(たとえば、入力ストリーム上の巡回冗長検査(CRC)の失敗)、b.ソース上の電力グリッチ、c.誰かがケーブルを引っ張ったこと。4.たとえば、エンコーダクロック許容差による、送信側と受信側との間にエンコーダクロックドリフトが発生した場合(期間がより長い問題)。

上記の問題は、以下の3つの技法のうちのいずれか1つまたは複数によって、本開示の技法に従って対処され得る。1.参照によりその全体が本明細書に組み込まれている、2014年1月2日に出願した米国特許出願第14/146,536号、Stockhammerら、「LIVE TIMING FOR DYNAMIC ADAPTIVE STREAMING OVER HTTP(DASH)」で定義されたRESTfulアプリケーションプログラミングインターフェース(API)を提供することによって。2.HTTP404応答の場合、具体的にフォーマットされたタイムコードを用いてサーバの時間を示すパラメータを含む特定のHTTP応答で応答することによって。このパラメータはメッセージ本体に追加されてよい。クライアントは、その時間基準を調整して、提供メディアプレゼンテーションに対して同期するために、この情報を使用することができる。これは上記の問題1、2、および4に対処し得る。3.停止(outage)の最小持続時間をシグナリングする空の「期間」を加算する。この持続時間は、新しいメディアが提供されるまでMPD更新において拡張され得る。クライアントは、この時間のシーケンスの間に何のメディアも生成されなかった(または、利用可能でない)ことがクライアントに知らされるように、この情報を使用して何らかのブラックアウトを示すことができる。4.その「期間」に関する持続時間を加算し、前の「期間」の開始と前の「期間」の持続時間の和よりも大きい開始時間を有する新しい「期間」を開始して、それによって、前の「期間」の終了と新しい「期間」の開始との間の部分は、何のメディアも有しない空の「期間」と呼ばれることが可能であり、持続時間属性を含む「期間」は、この「期間」の開始とこの「期間」の持続時間の和が次の「期間」の開始よりも小さくなるようにしてあり、早期終了「期間」と呼ばれる。

本開示の技法によれば、上で論じたように、DASHストリーミングサーバなどのストリーミングサーバは、何のメディアデータも利用可能でないメディアコンテンツ期間をシグナリングすることができる。たとえば、ストリーミングサーバは、その期間に対して何の他の要素もシグナリングせずに、その期間に対する開始時間と持続時間とをシグナリングすることができる。次に、その期間に対して開始要素および持続時間要素だけがシグナリングされるため、クライアントデバイスは、その期間のメディアデータが利用不可能であることを決定することができる。別のバージョンでは、サーバは、その「期間」内のメディアの終了にその「期間」の持続時間を加算したものをシグナリングすることができ、前の「期間」の開始と前の「期間」の持続時間の和よりも大きい開始時間の後、新しい「期間」だけを開始することができる。前の「期間」内のメディアの終了と新しい「期間」の開始との間の時間は空の「期間」とも呼ばれ、持続時間属性を含む「期間」は、この「期間」の開始とこの「期間」の持続時間の和が次の「期間」の開始よりも小さいようにしてあり、早期終了「期間」呼ばれる。したがって、クライアントデバイスは、その期間のメディアデータに対する要求を送るのを回避し、代わりに、たとえば、後続期間に対して利用可能なメディアデータを記述するメディアコンテンツに関して更新されたMPDに応答して、後続期間のメディアデータに対する要求を送ることができる。

本開示の技法のうちのいずれかまたはすべては、DASH規格、またはライブストリーミングに関する他のそのような規格の中に組み込まれ得る。

HTTPストリーミングにおいて、頻繁に使用される動作には、HEAD、GETおよび部分GETがある。HEAD動作は、所与のユニフォームリソースロケータ(URL)またはユニフォームリソース名(URN)と関連付けられたファイルのヘッダを取り出し、この場合、URLまたはURNと関連付けられたペイロードを取り出すことはない。GET動作は、所与のURLまたはURNと関連付けられたファイル全体を取り出す。部分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のメディアセグメントのシグナリングされた持続時間とによって指定される。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間では、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。しかしながら、早期終了「期間」の場合、この「期間」内のメディアは、新しい「期間」の開始よりも早く終了し得、コンテンツ提供におけるギャップを示す。期間開始時間は、正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。

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

ある特定の期間の表現は、表現が属する適応セットを示すMPD中の属性によって示されるグループに割り当てられ得る。同じ適応セット内の表現は、一般に、クライアントデバイスが、たとえば帯域幅に適応するためにこれらの表現の間で動的かつシームレスに切り替わることができる点で、互いに対する代替物と見なされる。たとえば、ある特定の期間のビデオデータの各表現は、同じ適応セットに割り当てられ得るので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために、選択され得る。いくつかの例では、1つの期間内のメディアコンテンツは、存在する場合にはグループ0からの1つの表現、または各々の非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表され得る。ある期間の各表現のタイミングデータは、期間の開始時間に対して表され得る。

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

異なるタイプのメディアデータに関して実質的に同時に取り出すために異なる表現を選択することができる。たとえば、クライアントデバイスは、そこからセグメントを取り出すオーディオ表現、ビデオ表現、および時限のテキスト表現を選択することができる。いくつかの例では、クライアントデバイスは、帯域幅に適応するために特定の適応セットを選択することができる。すなわち、クライアントデバイスは、ビデオ表現を含む適応セット、オーディオ表現を含む適応セット、および/または時限のテキストを含む適応セットを選択することができる。代替として、クライアントデバイスは、あるタイプのメディア(たとえば、ビデオ)に関する適応セットを選択し、他のタイプのメディア(たとえば、オーディオおよび/または時限のテキスト)に関する表現を直接選択することができる。

図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つまたは複数のそれぞれのエレメンタリストリームに対応する。

ITU-T H.264/AVCおよび高効率ビデオコーディング(HEVC)規格など、多くのビデオコーディング規格は、エラーのないビットストリームのためのシンタックス、意味論、および復号プロセスを定義し、それらのいずれもが、一定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は、一般的にエンコーダを規定しないが、エンコーダは、生成されたビットストリームがデコーダのための規格に準拠することを保証する役割を課される。ビデオコーディング規格の文脈では、「プロファイル」は、アルゴリズム、機能、またはツールのサブセット、およびこれらに適用される制約に相当する。H.264およびH.265規格によって定義されるように、たとえば、「プロファイル」は、H.264またはH.265規格によって規定される全体のビットストリームシンタックスのサブセットである。「レベル」は、たとえば、デコーダメモリおよび計算のような、デコーダのリソース消費の制限に相当し、これは、ピクチャの解像度、ビットレート、およびブロック処理速度に関連する。プロファイルは、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ピクセルよりも小さいサブマクロブロック区画を有し得るかどうかを定義することができる。このようにして、デコーダは、デコーダが適切にビットストリームを復号できるかどうかを判定することができる。

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

ビデオエンコーダ28は、種々の方法でマルチメディアコンテンツのビデオデータを符号化して、ピクセル解像度、フレームレート、様々なコーディング規格に対する準拠、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルに対する準拠、1つもしくは複数の表示を有する表現(たとえば、2次元または3次元の再生用)、または他のそのような特性などの、様々な特性を有する様々なビットレートのマルチメディアコンテンツの様々な表現を生成することができる。本開示で使用される場合、表現は、オーディオデータ、ビデオデータ、(たとえば、クローズドキャプション用の)テキストデータ、または他のそのようなデータのうちの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メッセージは、いくつかの標準仕様の規範的部分であり、したがって、規格に準拠するデコーダの実装において常に必須であるとは限らない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。いくつかのシーケンスレベル情報は、SVCの例におけるスケーラビリティ情報SEIメッセージおよびMVCにおける表示スケーラビリティ情報SEIメッセージなどのSEIメッセージに含まれ得る。これらの例示的なSEIメッセージは、たとえば動作点の抽出および動作点の特性に関する情報を伝達することができる。加えて、カプセル化ユニット30は、表現の特性を記述するmedia presentation descriptor (MPD)などのマニフェストファイルを形成することができる。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットすることができる。

カプセル化ユニット30は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数の表現のためのデータを、出力インターフェース32に提供することができる。出力インターフェース32は、ユニバーサルシリアルバス(USB)インターフェースのような記憶媒体へ書き込むためのネットワークインターフェースもしくはインターフェース、CDもしくはDVDのライターもしくはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを含み得る。カプセル化ユニット30は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース32に提供することができ、出力インターフェース32は、ネットワーク送信または記憶媒体を介してデータをサーバデバイス60に送信することができる。同様に、サーバデバイス60は、入力インターフェース76を介して、コンテンツ準備デバイス20からデータを受信することができる。図1の例では、サーバデバイス60は、各々がそれぞれのマニフェストファイル66および1つまたは複数の表現68A〜68N(表現68)を含む様々なマルチメディアコンテンツ64を記憶する、記憶媒体62を含む。

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

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

サーバデバイス60は、入力インターフェース76、要求処理ユニット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のような要求デバイスに、要求されたデータを提供するために、要求を処理するように構成され得る。

追加または代替として、要求処理ユニット70は、ブロードキャストまたはマルチキャストのプロトコル、たとえばeMBMSを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、DASHセグメントおよび/またはサブセグメントを、説明したものと実質的に同じ方法で作成することができるが、サーバデバイス60は、これらのセグメントまたはサブセグメントを、eMBMSまたは別のブロードキャストもしくはマルチキャストのネットワークトランスポートプロトコルを使用して配信することができる。たとえば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ参加要求を受信するように構成され得る。すなわち、サーバデバイス60は、マルチキャストグループに関連するインターネットプロトコル(IP)アドレスを、クライアントデバイス40を含む、特定のメディアコンテンツ(たとえば、生の事象のブロードキャスト)に関連するクライアントデバイスに通知することができる。次にクライアントデバイス40は、マルチキャストグループに参加することを求める要求を提出することができる。この要求は、ネットワーク74、たとえばネットワーク74を構成するルータを通じて伝搬され、それによりルータに、マルチキャストグループに関連するIPアドレス宛のトラフィックを、クライアントデバイス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の変化するネットワーク帯域幅の利用可能性に適応することもできる。

追加または代替として、取出しユニット52は、ブロードキャストまたはマルチキャストのネットワークプロトコル、たとえばeMBMSまたはIPのマルチキャストに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツに関連するマルチキャストネットワークグループに参加することを求める要求を提出することができる。取出しユニット52はマルチキャストグループに参加した後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を出すことなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、マルチキャストグループのデータが必要ではなくなったときにマルチキャストグループを離れること、たとえば再生を止めること、または異なるマルチキャストグループにチャネルを変えることを求める要求を出すことができる。

ネットワークインターフェース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、サーバデバイス60、および/またはコンテンツ準備デバイス20は、本開示の技法に従って動作するように構成され得る。例として、本開示は、クライアントデバイス40およびサーバデバイス60に関するこれらの技法を説明する。しかしながら、コンテンツ準備デバイス20は、サーバデバイス60の代わりに(またはそれに加えて)これらの技法を実行するように構成され得ることを理解されたい。

カプセル化ユニット30は、NALユニットが属するプログラム、ならびにペイロード、たとえばオーディオデータ、ビデオデータ、またはNALユニットが対応するトランスポートまたはプログラムストリームの記述データを特定するヘッダを含むNALユニットを形成することができる。たとえば、H.264/AVCにおいて、NALユニットは、1バイトのヘッダおよび可変サイズのペイロードを含む。そのペイロード内にビデオデータを含むNALユニットは、ビデオデータの様々な粒度レベルを含むことができる。たとえば、NALユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータの全ピクチャを含むことができる。カプセル化ユニット30は、ビデオエンコーダ28からの符号化ビデオデータをエレメンタリストリームのPESパケットの形で受信することができる。カプセル化ユニット30は、各エレメンタリストリームを対応するプログラムと関連付けることができる。

カプセル化ユニット30はまた、複数のNALユニットからアクセスユニットを組み立てることができる。一般に、アクセスユニットは、ビデオデータのフレームならびにそのようなオーディオデータが利用可能であるときにそのフレームに対応するオーディオデータを表すために1つまたは複数のNALユニットを含むことができる。アクセスユニットは、一般に、1つの出力時間インスタンスに対するすべてのNALユニット、たとえば1つの時間インスタンスに対するすべてのオーディオデータおよびビデオデータを含む。たとえば、各ビューが20フレーム毎秒(fps)のフレームレートを有する場合、各時間インスタンスは、0.05秒の時間間隔に対応することができる。この時間間隔の間、同じアクセスユニット(同じ時間インスタンス)のすべてのビューに対する特定のフレームは、同時にレンダリングされ得る。一例では、アクセスユニットは、一次コード化ピクチャとして提示され得る、1つの時間インスタンス内のコード化ピクチャを含むことができる。

したがって、アクセスユニットは、共通の時間インスタンスのすべてのオーディオフレームおよびビデオフレーム、たとえば時刻Xに対応するすべてのビューを含むことができる。本開示はまた、特定のビューの符号化ピクチャを「ビューコンポーネント(view component)」と呼ぶ。すなわち、ビューコンポーネントは、特定の時刻における特定のビューに対する符号化ピクチャ(またはフレーム)を含むことができる。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビューコンポーネントを含むものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示の順序と同じである必要はない。

メディアプレゼンテーションは、異なる代替表現(たとえば、異なる品質を有するビデオサービス)の記述を含み得るメディアプレゼンテーション記述(MPD)を含むことができ、記述は、たとえばコーデック情報、プロファイル値、およびレベル値を含むことができる。MPDは、マニフェストファイル66など、マニフェストファイルの一例である。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、様々なプレゼンテーションの動画フラグメントにどのようにアクセスするかを決定することができる。動画フラグメントは、ビデオファイルの動画フラグメントボックス(ムーフボックス(moof box))内に配置され得る。

マニフェストファイル66(たとえば、MPDを含むことができる)は、表現68のセグメントの利用可能性を広告することができる。すなわち、MPDは、表現68のうちの1つの第1のセグメントが利用可能になる壁時計時刻を示す情報、ならびに表現68内のセグメントの持続時間を示す情報を含むことができる。このようにして、クライアントデバイス40の取出しユニット52は、開始時刻ならびに特定のセグメントに先行するセグメントの持続時間に基づいて、各セグメントが利用可能になる時を判定することができる。

カプセル化ユニット30が、受信されたデータに基づいてNALユニットおよび/またはアクセスユニットをビデオファイルに統合した後、カプセル化ユニット30は、ビデオファイルを出力のために出力インターフェース32に渡す。いくつかの例では、カプセル化ユニット30は、ビデオファイルをローカルに記憶するかまたはビデオファイルを出力インターフェース32を介して、サーバデバイス60などのリモートサーバに送信することができる。出力インターフェース32は、たとえば、送信機、トランシーバ、たとえばオプティカルドライブ、磁気媒体ドライブ(たとえば、フロッピー（登録商標）ドライブ)などのコンピュータ可読媒体にデータを書き込むためのデバイス、ユニバーサルシリアルバス(USB)ポート、ネットワークインターフェース、または他の出力インターフェースを含むことができる。出力インターフェース32は、たとえば送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体など、コンピュータ可読媒体34にビデオファイルを出力する。

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

上で論じたように、コンテンツ準備デバイス20は、メディアデータ、たとえば、ライブメディアデータをサーバデバイス60に提供する。たとえば、コンテンツ準備デバイス20は、メディアデータがキャプチャされ、符号化されると、出力インターフェース32を介して、メディアデータを入力インターフェース76に送信することができる。場合によっては、メディアデータの損失が発生し得る。したがって、本開示の技法によれば、サーバデバイス60は、何のメディアデータも利用可能でないマルチメディアコンテンツ64など、メディアコンテンツの1つまたは複数の期間に対するデータをシグナリングすることができる。

たとえば、サーバデバイス60は、何のメディアデータも利用可能でない再生時間を表す期間要素を含めるために、マニフェストファイル66(たとえば、MDP)を作成または修正することができる。期間要素は、その期間に対する開始時間と持続時間とを表すデータを含み得る。持続時間は、何のメディアデータも利用可能でない期間に対する開始時間からの最小時間量に対応し得る。サーバデバイス60は、ネットワーク74を介して、マニフェストファイル66をクライアントデバイス40に提供することができる。MPDのそのような期間要素は、その期間に対して何のメディアデータも利用可能でないことを示すデータの一例である。

クライアントデバイス40の取出しユニット52は、マニフェストファイル66を使用して、何のメディアデータも利用可能でない期間を決定することができる。そのような期間が発見されたとき、取出しユニット52は、その期間内にメディアデータに対する要求を提出するのを回避することができる。いくつかの例では、取出しユニット52は、開始時間に、マニフェストファイル66内に示された持続時間を加算した時間に続いて、メディアデータに対する1つまたは複数の要求を提出することができる。サーバデバイス60が、何のメディアデータも利用可能でない期間に続いて、メディアデバイスが利用可能であると決定した場合、サーバデバイス60は、利用可能なメディアデータをクライアントデバイス40に送ることができる。

しかしながら、上述のように、持続時間は、何のメディアデータも利用可能でない、開始時間からの最小時間量を表し得る。したがって、サーバデバイス60は、代わりに、HTTP404「利用不可能」エラーを用いて、メディアデータに対する要求に応答することができる。エラーは、たとえば、HTTPヘッダの拡張内に、メディアデータがいつ利用可能になるかの表示をさらに含み得る。メディアデータがいつ利用になるかの表示は、ネットワークタイムプロトコル(NTP)、国際標準化機関(ISO)時間フォーマットなどで表現された同期時間に対応し得る。加えて、または代替として、サーバデバイス60は、メディアデータが利用可能である後続期間の表示を含む、更新されたマニフェストファイルをクライアントデバイス40に送ることができる。

さらに、本開示は、場合によっては、クライアントデバイス40の内部クロックが、メディアデータがMPD内で利用可能であるとして広告される「壁時計」時間に関して、サーバデバイス60のクロックに対して非同期になる場合があることを認識している。したがって、本開示の技法は、クライアントデバイス40の内部クロックがサーバデバイス60のクロックに対してドリフトしたときにも使用され得る。上述のように、サーバデバイス60は、クライアントデバイス40からの利用不可能なメディアデータに対する要求に対してHTTP404エラー応答を送ることができる。加えて、エラー応答は、後続のメディアデータが利用可能になる時間、ならびに/または同期方法および/もしくはサーバを示し得る。したがって、クライアントデバイス40は、このデータを使用して、サーバデバイス60のクロックと再同期すること、および/またはある期間のメディアデータが取出しのために利用可能になる壁時計時間を決定することができる。そのようなエラー応答は、ある期間のメディアデータが利用不可能であること(すなわち、その期間の何のメディアデータも利用可能でないこと)を示すデータの別の例である。

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

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

本開示の技法によれば、MPD104は、何のメディアデータも利用可能でない期間要素を含み得る。たとえば、MPD104は、何の他の要素も伴わない、Period@start要素とPeriod@duration要素とを含む期間要素を含み得る。クライアントデバイス40などのクライアントデバイスは、MPD104のこのデータからそのような期間に対して何のメディアデータも利用可能でないことを決定し、それによって、利用可能でないメディアデータに対する要求の提出を回避することができ、これはネットワーク帯域幅を保存し、サーバとクライアントの両方によって実行される処理電力を低減することができる。

本開示の技法を用いた別の例では、MPD104は、終了時ではなく、第1の部分に関してだけメディアデータが利用可能である期間要素を含み得る。たとえば、MPD104は、Period@start要素とPeriod@duration要素とを含む期間要素と、第1の「期間」のPeriod@startとPeriod@durationの和よりも大きいPeriod@startを有する新しい「期間」要素とを含み得る。クライアントデバイス40などのクライアントデバイスは、第1の期間の2つの要素の和と次の期間の開始との間の時間に対して何のメディアデータも利用可能でないことを決定し、それによって、利用可能でないメディアデータに対する要求の提出を回避することができ、これはネットワーク帯域幅を保存し、サーバとクライアントの両方によって実行される処理電力を低減することができる。

単一のMPD104が図2に示されているが、MPD104は、実際に、複数のデータセット、すなわち、初期MPDと初期MPDに対する1つまたは複数の更新によって実現され得ることを理解されたい。たとえば、初期(または、前の)MPDに対する更新は、マルチメディアコンテンツ102に関する新しい期間要素を含み得る。いくつかの例では、期間は、表現110のうちのただ1つに対応し得るのに対して、他の例では、期間は複数の表現110(たとえば、そのすべてのまたはサブセット)に対応し得る。

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

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

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

図3は、本開示の技法を実行し得るシステム150を示すブロック図である。図3のシステムは、DASHメディアプレゼンテーションサーバ152とDASHクライアント154とを含む。DASHメディアプレゼンテーションサーバ152は、図1のサーバデバイス60に対応し得るのに対して、DASHクライアント154は、図1のクライアントデバイス40に対応し得る。DASHメディアプレゼンテーションサーバ152は、停止を伴うライブビデオストリーム156を受信することができる。DASHメディアプレゼンテーションサーバ152は、本開示の技法に従って、DASHクライアント154に停止をシグナリングすることができる(158)。

たとえば、DASHメディアプレゼンテーションサーバ152は、HTTP404応答の場合、具体的にフォーマットされた時間コードを有するサーバの時間を含む特定のHTTP応答で要求(たとえば、DASHクライアント154からのHTTP GETまたは部分的なGET要求)に応答することができる。このパラメータはメッセージ本体に追加されてよい。DASHクライアント154は、その時間基準(たとえば、DASHクライアント154のローカルクロック)を調整し、メディアプレゼンテーションの提供に対してクロックを同期させるために、この情報を使用することができる。

加えて、または代替で、DASHメディアプレゼンテーションサーバ152は、停止の最小持続時間をシグナリングする空の「期間」を表現のデータに加算することができる。この持続時間は、新しいメディアが提供されるまで、メディアプレゼンテーション記述(MPD)更新において拡張され得る。DASHクライアント154は、この情報を使用して、何らかのブラックアウトを示すことができるが、この時間のシーケンスの間、何のメディアも生成されなかったことがDASHクライアント154に知らされる。このようにして、DASHメディアプレゼンテーションサーバ152によって受信されたビデオデータ内に停止が提示されたとき、DASHクライアント154は、その間に停止が発生した時間に対して何のメディアデータも存在しないことを決定し、したがって、たとえば、DASHメディアプレゼンテーションサーバ152と一時的に同期された状態に留まることができる。

図4は、そのメディアデータがあるメディアコンテンツ期間に対して利用可能でないことを示す情報を交換するための例示的な方法を示すフローチャートである。図4の方法は、図1のクライアントデバイス40およびサーバデバイス60に関して説明される。しかしながら、他のデバイスはこの方法または同様の方法を実行するように構成され得ることを理解されたい。

最初に、図4の例では、クライアントデバイス40は、サーバデバイス60からメディアコンテンツに関するMPDを要求する(160)。サーバデバイス60は、MPDに対する要求を受信し(162)、何のメディアデータも有しない期間を示す初期MPDを送る(164)。図4に示されていないが、サーバデバイス60は、メディアデータの一部が、たとえば、コンテンツ準備デバイス20から受信されなかったことを決定することができる。受信されなかったメディアデータの再送信を待つのではなく、後続メディアデータの遅延を回避するために、サーバデバイス60は、受信されなかったメディアデータに対応する期間が利用可能なメディアデータを有しないことを示すように初期MPDを準備することができる。たとえば、初期MPDは、メディアデータがその期間に対して利用可能でないことを示すために、その期間に対してシグナリングされる何の他の要素も伴わずに、その期間に対する期間開始時間(Period@start)と持続時間(Period@duration)をシグナリングすることができる。別の例として、MPDは、和が次の「期間」のPeriod@startよりも小さい第1の「期間」に関するPeriod@startとPeriod@durationとをシグナリングすることができる。その間の時間ギャップの間、何のメディアも利用可能でない。「初期MPD」という用語は、MPDの通常の第1のインスタンス、またはMPDの更新バージョンを指す場合がある。

クライアントデバイス40は初期MPDを受信することができる(166)。何のメディアデータも利用可能でない期間に先立って、1つまたは複数の期間が存在すると仮定して、クライアントデバイス40は、初期MPDを使用して、何のメディアデータも有しない期間に先立つ期間のメディアデータを要求することができる(168)。たとえば、そのような要求は、HTTP GET要求または部分的なGET要求を含み得る。サーバデバイス60はメディアデータに対する要求を受信し(170)、それらの要求に応答して、要求されたメディアデータを送ることができる(172)。クライアントデバイス40は、たとえば、メディアデータを復号し、そのメディアデータをユーザに提示することによって、受信したメディアデータを処理することができる(174)。

図4の例では、サーバデバイス60は、後の期間、すなわち、何のメディアデータも利用可能でない期間に続く期間に対して利用可能なメディアデータを示す、更新されたMPDを送る(176)。いくつかの例では、サーバデバイス60は更新されたMPDを自動的に送ることができるのに対して、他の例では、サーバデバイス60は、クライアントデバイス40からの要求に応答して、更新されたMPDを送ることができる(図示せず)。いずれの場合も、クライアントデバイス40は、更新されたMPDを受信し(178)、更新されたMPDを使用して、何のメディアデータも有しない期間に続く期間のメディアデータを要求する(180)。このようにして、クライアントデバイス40は、何のメディアデータも利用可能でない期間のメディアデータに対する要求を送ることを省く。サーバデバイス60は、クライアントデバイス40からメディアデータに対する要求を受信し(182)、それらの要求に応答して、要求されたメディアデータをクライアントデバイス40に送る(184)。クライアントデバイス40は、たとえば、受信したメディアデータを復号および提示することによって、受信したメディアデータを処理する(186)。

このようにして、図4の方法は、メディアコンテンツの第1の期間およびそのメディアコンテンツの第2の期間に対するデータを受信するステップであって、第1の期間に対するデータが、第1の期間に対して何のメディアデータも利用可能でないことを示し、第2の期間に対するデータが、第2の期間に対して利用可能なメディアデータを示す、受信するステップと、第1の期間および第2の期間に対するデータに基づいて、第1の期間のメディアデータに対する要求を省き、第2の期間のメディアデータに対する1つまたは複数の要求を送るステップとを含む方法の一例を表す。

図4の方法は、メディアコンテンツの第1の部分が損失していること、およびそのメディアコンテンツの第2の部分が受信されていることを決定するステップと、メディアコンテンツの第1の期間に対してメディアデータが利用可能でないことを示す、第1の部分に対応する、第1の期間に対するデータをシグナリングし、メディアデータがそのメディアコンテンツの第2の期間に対して利用可能であることを示す、第2の部分に対応する、第2の期間に対するデータをシグナリングするステップと、そのデータをシグナリングした後、第2の期間のメディアデータに対する1つまたは複数の要求を受信するステップと、それらの要求に応答して、第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 ネットワーク
76 入力インターフェース
102 マルチメディアコンテンツ
104 メディアプレゼンテーション記述(MPD)
110 表現
110A 表現
110N 表現
112 任意選択のヘッダデータ
114 セグメント
114A セグメント
114B セグメント
114N セグメント
122 任意選択のヘッダデータ
124 セグメント
124A セグメント
124B セグメント
124N セグメント
150 システム
152 DASHプレゼンテーションサーバ
154 DASHクライアント

Claims (28)

1. ストリーミングメディアデータに関するデータを受信する方法であって、
   メディアコンテンツの第1の期間および前記メディアコンテンツの第2の期間に対するデータを受信するステップであって、前記第1の期間に対する前記データが、前記第1の期間に対する第1のPeriod@start要素および前記第1の期間に対する第1のPeriod@duration要素を含み、前記第1のPeriod@duration要素が、前記第1の期間の少なくとも一部のメディアデータが利用可能でないことを示し、前記第2の期間に対する前記データが、前記第1のPeriod@start要素と前記第1のPeriod@duration要素の和よりも大きい値を有する第2のPeriod@start要素を含み、前記第2の期間に対する前記データが、前記第2の期間に対して利用可能なメディアデータを示す、受信するステップと、
   前記第1の期間および前記第2の期間に対する前記データに基づいて、前記第1の期間に対する前記データが利用可能でないことを示す前記第1の期間のメディアデータに対する要求を省き、前記第2の期間の前記メディアデータに対する1つまたは複数の要求を送るステップと
   を含む、方法。
2. 前記第1の期間に対する前記データが、何のメディアデータも利用可能でない、前記第1の期間からの持続時間を示し、前記省くステップが、前記第1の期間の前記持続時間内のメディアデータに対する要求を省くステップを含む、請求項1に記載の方法。
3. 前記第1の期間に対する前記データを前記受信するステップが、前記第1の期間のメディアデータに対する要求に応答したHTTP404エラーを受信するステップを含み、前記データが、壁時計時間を同期させるための同期データをさらに示し、前記方法が、壁時計時間を同期させるために、前記データに従って内部クロックを同期させるステップをさらに含む、請求項1に記載の方法。
4. 前記データを前記受信するステップが、
   初期メディアプレゼンテーション記述(MPD)内で前記第1の期間に対する前記データを受信するステップと、
   前記初期MPDに対応する更新されたMPD内で前記第2の期間に対する前記データを受信するステップと
   を含む、請求項1に記載の方法。
5. 前記第1のPeriod@start要素が、前記第1の期間の開始に関する再生時間を表し、前記第1のPeriod@duration要素が、前記第1の期間の前記開始から前記第1の期間の利用可能なメディアデータの終了までの再生時間の持続時間を表す、請求項1に記載の方法。
6. 前記第2のPeriod@start要素によって示された時間まで、前記第1のPeriod@startと前記第1のPeriod@durationの前記和によって示された時間から開始する前記第1の期間に対するメディアデータの再生を省くステップと、
   前記第2のPeriod@start要素によって示された前記時間において前記第2の期間の前記メディアデータの再生を開始するステップと
   をさらに含む、請求項5に記載の方法。
7. ストリーミングメディアデータに関するデータを受信するためのデバイスであって、
   ネットワークを介して、データを送受信するように構成された1つまたは複数のネットワークインターフェースと、
   回路で実装される1つまたは複数のプロセッサであって、
   前記ネットワークインターフェースを介して、メディアコンテンツの第1の期間および前記メディアコンテンツの第2の期間に対するデータを受信することであって、前記第1の期間に対する前記データが、前記第1の期間に対する第1のPeriod@start要素および前記第1の期間に対する第1のPeriod@duration要素を含み、前記第1のPeriod@duration要素が、前記第1の期間の少なくとも一部のメディアデータが利用可能でないことを示し、前記第2の期間に対する前記データが、前記第1のPeriod@start要素と前記第1のPeriod@duration要素の和よりも大きい値を有する第2のPeriod@start要素を含み、前記第2の期間に対する前記データが、前記第2の期間に対して利用可能なメディアデータを示す、受信することと、
   前記第1の期間および前記第2の期間に対する前記データに基づいて、前記第1の期間に対する前記データが利用可能でないことを示す前記第1の期間のメディアデータに対する要求を省き、前記第2の期間の前記メディアデータに対する1つまたは複数の要求を送ることと
   を行うように構成された、1つまたは複数のプロセッサと
   を含む、デバイス。
8. 前記第1の期間に対する前記データが、何のメディアデータも利用可能でない前記第1の期間からの持続時間を示し、前記省くことが、前記第1の期間の前記持続時間内のメディアデータに対する要求を省くことを含む、請求項7に記載のデバイス。
9. 内部クロックをさらに含み、前記第1の期間に対する前記データが、前記第1の期間のメディアデータに対する要求に応答したHTTP404エラーを含み、前記データが、壁時計時間を同期させるための同期データをさらに示し、前記1つまたは複数のプロセッサが、壁時計時間を同期させるために、前記データに従って前記内部クロックを同期させるようにさらに構成される、請求項7に記載のデバイス。
10. 前記1つまたは複数のプロセッサが、初期メディアプレゼンテーション記述(MPD)内で前記第1の期間に対する前記データを受信し、前記初期MPDに対応する更新されたMPD内で前記第2の期間に対する前記データを受信するように構成される、請求項7に記載のデバイス。
11. 前記第1のPeriod@start要素が、前記第1の期間の開始に関する再生時間を表し、前記第1のPeriod@duration要素が、前記第1の期間の前記開始から前記第1の期間の利用可能なメディアデータの終了までの再生時間の持続時間を表す、請求項7に記載のデバイス。
12. 前記1つまたは複数のプロセッサが、前記第2のPeriod@start要素によって示された時間まで、前記第1のPeriod@startと前記第1のPeriod@durationの前記和によって示された時間から開始する前記第1の期間に対するメディアデータの再生を省き、前記第2のPeriod@start要素によって示された前記時間において前記第2の期間の前記メディアデータの再生を開始するようにさらに構成される、請求項11に記載のデバイス。
13. ストリーミングメディアデータに関するデータをシグナリングする方法であって、
    メディアコンテンツの第1の部分が損失していること、および前記メディアコンテンツの第2の部分が受信されていることを決定するステップと、
    前記メディアコンテンツの第1の期間に対するデータをシグナリングするステップであって、前記第1の期間が少なくとも前記第1の部分を含み、前記第1の期間に対する前記データをシグナリングするステップが、前記第1の期間に対する第1のPeriod@start要素および前記第1の期間に対する第1のPeriod@duration要素をシグナリングするステップを含み、前記第1のPeriod@duration要素は、前記メディアコンテンツの第1の期間の少なくとも一部のメディアデータが前記第1の期間に対して利用可能でないことを示す、ステップと、
    前記メディアコンテンツの第2の期間に対するデータをシグナリングするステップであって、前記第2の期間が第2の部分に対応し、前記第2の期間に対する前記データをシグナリングするステップが、前記第1のPeriod@start要素と前記第1のPeriod@duration要素の和よりも大きい値を有する第2のPeriod@start要素をシグナリングするステップを含み、第2の期間のための前記データは、メディアデータが前記第2の期間に対して利用可能であることを示す、ステップと、
    前記第1の期間に対する前記データと前記第2の期間に対する前記データとをシグナリングした後、前記第2の期間の前記メディアデータに対する1つまたは複数の要求を受信するステップと、
    前記要求に応答して、前記第2の期間の前記要求されたメディアデータを送るステップと
    を含む、方法。
14. 前記第1の期間に対する前記データが、何のメディアデータも利用可能でない、前記第1の期間からの持続時間を示す、請求項13に記載の方法。
15. 前記シグナリングするステップが、
    初期メディアプレゼンテーション記述(MPD)内で前記第1の期間に対する前記データをシグナリングするステップと、
    前記初期MPDに対応する更新されたMPD内で前記第2の期間に対する前記データをシグナリングするステップと
    を含む、請求項13に記載の方法。
16. 前記第2の期間の前記メディアデータが利用可能である同期時間を示すデータを送るステップをさらに含む、請求項13に記載の方法。
17. 前記データを送るステップが、拡張ヘッダを使用して、前記データをHTTPヘッダ内に含めるステップを含む、請求項16に記載の方法。
18. 前記データを送るステップが、HTTP404エラーコードとともに前記データを送るステップを含む、請求項16に記載の方法。
19. 前記データを送るステップが、ネットワークタイムプロトコル(NTP)フォーマットに従って前記同期時間を示す前記データを送るステップを含む、請求項16に記載の方法。
20. 前記データを送るステップが、国際標準化機構(ISO)時間フォーマットに従って前記同期時間を示す前記データを送るステップを含む、請求項16に記載の方法。
21. ストリーミングメディアデータに関するデータをシグナリングするためのデバイスであって、
    ネットワークを介して、データを送受信するように構成された1つまたは複数のネットワークインターフェースと、
    回路で実装される1つまたは複数のプロセッサであって、
    メディアコンテンツの第1の部分が損失していること、および前記メディアコンテンツの第2の部分が受信されていることを決定することと、
    前記ネットワークインターフェースを介して、前記メディアコンテンツの第1の期間に対するデータをシグナリングすることであって、前記第1の期間が、少なくとも前記第1の部分を含み、前記1つまたは複数のプロセッサが、前記第1の期間に対する第1のPeriod@start要素および前記第1の期間に対する第1のPeriod@duration要素をシグナリングするように構成され、前記第1のPeriod@duration要素は、前記第1の期間の少なくとも一部のメディアデータが前記第1の期間に対して利用可能でないことを示す、ことと、
    前記メディアコンテンツの第2の期間に対するデータをシグナリングすることであって、前記第2の期間が前記第2の部分に対応し、前記1つまたは複数のプロセッサが、前記第1のPeriod@start要素と前記第1のPeriod@duration要素の和よりも大きい値を有する第2のPeriod@start要素をシグナリングするように構成され、第2の期間に対する前記データは、メディアデータが前記第2の期間に対して利用可能であることを示す、ことと、
    前記第1の期間に対する前記データと前記第2の期間に対する前記データとをシグナリングした後、前記ネットワークインターフェースを介して、前記第2の期間の前記メディアデータに対する1つまたは複数の要求を受信することと、
    前記要求に応答して、前記ネットワークインターフェースを介して、前記第2の期間の前記要求されたメディアデータを送ることと
    を行うように構成された、1つまたは複数のプロセッサと
    を含む、デバイス。
22. 前記第1の期間に対する前記データが、何のメディアデータも利用可能でない、前記第1の期間からの持続時間を示す、請求項21に記載のデバイス。
23. 前記1つまたは複数のプロセッサが、初期メディアプレゼンテーション記述(MPD)内で前記第1の期間に対する前記データをシグナリングし、前記初期MPDに対応する更新されたMPD内で前記第2の期間に対する前記データをシグナリングするように構成される、請求項21に記載のデバイス。
24. 前記1つまたは複数のプロセッサが、前記ネットワークインターフェースを介して、前記第2の期間の前記メディアデータが利用可能である同期時間を示すデータを送るようにさらに構成される、請求項21に記載のデバイス。
25. 前記1つまたは複数のプロセッサが、拡張ヘッダを使用して、前記同期時間を示す前記データをHTTPヘッダ内に含めるように構成される、請求項24に記載のデバイス。
26. 前記1つまたは複数のプロセッサが、前記同期時間を示す前記データをHTTP404エラーコードと一緒に含めるように構成される、請求項24に記載のデバイス。
27. 前記1つまたは複数のプロセッサが、ネットワークタイムプロトコル(NTP)フォーマットに従って前記同期時間を示す前記データをフォーマットするように構成される、請求項24に記載のデバイス。
28. 前記1つまたは複数のプロセッサが、国際標準化機構(ISO)時間フォーマットに従って前記同期時間を示す前記データをフォーマットするように構成される、請求項24に記載のデバイス。

Images