JP5937275B2 - ネットワークストリーミングのための失われたメディアデータの置換 - Google Patents

Description

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

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

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

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

米国特許出願第13/439,556号

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

全般に、本開示は、ネットワークを通じてメディアデータをストリーミングする状況においてエラーを軽減することに関する技法を説明する。たとえば、これらの技法は、Dynamic Adaptive Streaming over HTTP(DASH)を使用してメディアデータをストリーミングするときに使用され得る。DASHを使用したメディアデータのストリーミングは、たとえば、ユニキャスト(たとえば、TCP/IPを通じたHTTPを使用して)、マルチキャスト、またはブロードキャスト(たとえば、enhanced Multimedia Broadcast Multicast Service(eMBMS)を使用して)を使用して、達成され得る。

メディアデータは一般に、ネットワークを通じたストリーミングのために、セグメントと呼ばれる個々のメディアファイルに区分される。セグメントの各々は、1つまたは複数のネットワークパケットを使用してネットワークを通じて送信され得る。いくつかの場合、たとえば、パケットがまったく到達しない場合、パケットが時間内に到達しない場合、または、パケットのデータが破損した場合には、セグメントのパケットの1つまたは複数が失われることがある。本開示の技法は、失われたデータを、デフォルトのオーディオおよび/またはビデオデータなどのデフォルトデータのセットで置換することによって、そのようなエラーを軽減するステップを含む。たとえば、失われたセグメントのすべてまたは一部が、デフォルトのオーディオおよび/またはビデオデータによって置換され得る。

一例では、メディアデータを提示する方法は、メディアデータのセグメントの少なくとも一部分のデータが失われたことを、セグメントの残りの部分がdynamic adaptive streaming over HTTP(DASH)に従ったネットワーク送信を介して受信された後で判定するステップと、その判定に基づいて、メディアデータを復号する前に、デフォルトデータをセグメントに追加して、失われたと判定されたデータを置換して置換セグメントを形成するステップと、置換セグメントのメディアデータを出力するステップとを含む。

別の例では、メディアデータの情報を提示するためのデバイスは、メディアデータのセグメントの少なくとも一部分のデータが失われたことを、セグメントの残りの部分がdynamic adaptive streaming over HTTP(DASH)に従ったネットワーク送信を介して受信された後で判定し、その判定に基づいて、メディアデータを復号する前に、デフォルトデータをセグメントに追加して、失われたと判定されたデータを置換して置換セグメントを形成し、置換セグメントのメディアデータを出力するように構成される、1つまたは複数のプロセッサを含む。

別の例では、メディアデータの情報を提示するためのデバイスは、メディアデータのセグメントの少なくとも一部分のデータが失われたことを、セグメントの残りの部分がdynamic adaptive streaming over HTTP(DASH)に従ったネットワーク送信を介して受信された後で判定するための手段と、その判定に基づいて、メディアデータを復号する前に、デフォルトデータをセグメントに追加して、失われたと判定されたデータを置換して置換セグメントを形成するための手段と、置換セグメントのメディアデータを出力するための手段とを含む。

別の例では、コンピュータプログラム製品は、命令を含むコンピュータ可読記憶媒体を含み、その命令は、実行されると、1つまたは複数のプロセッサに、メディアデータのセグメントの少なくとも一部分のデータが失われたことを、セグメントの残りの部分がdynamic adaptive streaming over HTTP(DASH)に従ったネットワーク送信を介して受信された後で判定させ、その判定に基づいて、メディアデータを復号する前に、デフォルトデータをセグメントに追加させて、失われたと判定されたデータを置換して置換セグメントを形成させ、置換セグメントのメディアデータを出力させる。

別の例では、メディアデータの情報を送信する方法は、少なくとも1つのクライアントデバイスに送信されるべきメディアコンテンツの表現を決定するステップと、決定された表現に対応するデフォルトデータを決定するステップと、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信して、少なくとも1つのクライアントデバイスに失われたデータをデフォルトデータで置換させるステップと、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信した後に、決定された表現のメディアデータを少なくとも1つのクライアントデバイスに送信するステップとを含む。

別の例では、メディアデータの情報を送信するためのデバイスは、少なくとも1つのクライアントデバイスに送信されるべきメディアコンテンツの表現を決定し、決定された表現に対応するデフォルトデータを決定するように構成される、1つまたは複数のプロセッサと、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信して、少なくとも1つのクライアントデバイスに失われたデータをデフォルトデータで置換させ、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信した後に、決定された表現のメディアデータを少なくとも1つのクライアントデバイスに送信するように構成される、1つまたは複数のネットワークインターフェースとを含む。

別の例では、メディアデータの情報を送信するためのデバイスは、少なくとも1つのクライアントデバイスに送信されるべきメディアコンテンツの表現を決定するための手段と、決定された表現に対応するデフォルトデータを決定するための手段と、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信して、少なくとも1つのクライアントデバイスに失われたデータをデフォルトデータで置換させるための手段と、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信した後に、決定された表現のメディアデータを少なくとも1つのクライアントデバイスに送信するための手段とを含む。

別の例では、コンピュータプログラム製品は、命令を含むコンピュータ可読記憶媒体を含み、その命令は、1つまたは複数のプロセッサに、少なくとも1つのクライアントデバイスに送信されるべきメディアコンテンツの表現を決定させ、決定された表現に対応するデフォルトデータを決定させ、決定されたデフォルトデータを少なくとも1つのクライアントデバイスへ送信させて、少なくとも1つのクライアントデバイスに失われたデータをデフォルトデータで置換させ、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信した後に、決定された表現のメディアデータを少なくとも1つのクライアントデバイスへ送信させる。

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

ネットワークを通じてメディアデータをストリーミングするための技法を実施する、ある例示的なシステムを示すブロック図である。 クライアントデバイスによって受信されるデータを表すグラフ80およびクライアントデバイスによって提示されるデータを表すグラフ86を示す概念図である。 例示的なマルチディアコンテンツの要素を示す概念図である。 マルチメディアコンテンツの表現のセグメントに対応し得る、例示的なビデオファイルの要素を示すブロック図である。 テンプレートデータを提供および使用して失われたデータを置換するための例示的な方法を示すフローチャートである。

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

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

さらに、様々なビットレートを有する表現は、帯域幅適応を可能にし得る。たとえば、クライアントデバイスは、現在利用可能な帯域幅の量を決定し、利用可能な帯域幅の量とともにクライアントデバイスの符号化能力およびレンダリング能力に基づいて、表現を選択することができる。DASHを使用して帯域幅適合を実行するクライアントデバイスは、HTTPなどのユニキャストネットワークプロトコルを使用して、メディアデータを取り出すことができる。代替的に、または追加で、サーバデバイスは、ブロードキャストまたはマルチキャストのために、適切な表現を選択することができる。たとえば、サーバデバイスは、マルチキャストグループと関連付けられるインターネットプロトコル(IP)アドレスに、表現の1つのメディアデータを送信することができ、クライアントデバイスは、メディアデータを受信するために、グループに参加することを要求することができる。

一般に、DASHは、ネットワークを通じてメディアデータをストリーミングするための技法を提供する。たとえば、上で論じられたように、DASHは、ユニキャスト、ブロードキャスト、またはマルチキャストネットワークプロトコルとともに使用され得る。いくつかの例では、メディアデータの喪失をもたらすエラーが発生することがある。メディアデータの喪失は、たとえば、パケットが配信されない場合、またはパケットのデータが破損した場合に発生し得る。ブロードキャストまたはマルチキャストのネットワークセッションでは、サーバデバイスは通常、ブロードキャストセッションのパケットのストリーミングを続けるように構成されるので、クライアントデバイスには、サーバデバイスからの失われたまたは破損したパケットの再送信を要求する機会がないことがある。さらに、再送信されるパケットが到達するまで待つと、再生の遅延を引き起こすことがあり、これは、ユーザエクスペリエンスに悪影響を及ぼし得る。したがって、多くの場合、1つまたは複数のパケットが喪失または破損すると、クライアントデバイスは、単に音声のない空の画面を表示し、そして、エラーを伴わない後続のパケットを受信した後で再生を再開する。

本開示の技法は全般に、DASHまたは同様のストリーミングネットワークプロトコルに従ってメディアデータを送信する(たとえば、ユニキャストする、マルチキャストする、またはブロードキャストする)状況において、ユーザエクスペリエンスを改善することを対象とする。1つまたは複数のパケットが失われたときに、音声のない空の画面を表示するのではなく、クライアントデバイスは、データが失われたときに提示すべき所定の(またはデフォルトの)オーディオおよび/またはビデオデータによって構成され得る。このようにして、クライアントデバイスがパケットの喪失または破損を検出すると、クライアントデバイスは、所定のオーディオおよび/またはビデオデータに切り替えることができる。この所定のオーディオおよび/またはビデオデータは、たとえば、ネットワークのロゴの画面、ネットワークのテーマソング、季節に関連する表示、コンテンツに関連する表示(たとえば、フットボールの試合ではフットボール場)、または他のそのようなデータを含み得る。一般に、本開示は、到達しなかったパケットからのデータ、有用であるには到達が遅すぎたパケットからのデータ、および到達したが破損していたパケットからのデータを含むものとして、「失われた」データに言及する。同様に、所定のオーディオデータは、スポーツイベントに対する群衆のざわめきなどの、コンテンツに関連する音声を含み得る。

いくつかの場合には、ビデオデータの喪失を伴わずにオーディオデータが失われることがあり、この場合、受信されたビデオデータは音声を伴わずに表示され得る。あるいは、音声が受信されていないときに字幕(closed caption)データが受信されている場合、クライアントデバイスは、オーディオデータが失われたときに字幕の表示を自動的に開始することができる。同様に、オーディオデータの喪失を伴わずにビデオデータが失われることがあり、この場合、デフォルトのビデオが表示されてよく、受信されたオーディオデータが提示されてよい。このようにして、これらの技法は、パケット喪失またはパケット破損の場合のユーザエクスペリエンスを改善することができる。

様々な例において、提示されるべきオーディオおよび/またはビデオデータは、クライアントデバイスに(たとえば、クライアントデバイスの構成データに)事前に記憶されてよく、サーバデバイスからクライアントデバイスに(たとえば、ブロードキャストの始めに)最初に送信されてよく、定期的に送信されてよく(定期的に送信される同じデフォルトデータであってよく、または新たなデフォルトデータが各期間に送信されてよい)、ブロードキャストもしくはマルチキャストの間に付随する情報として(すなわち、たとえば、ユニキャスト要求に応答する、別個の送信として)送信されてよく、またはそうでなければ、サーバデバイスからクライアントデバイスに1回または複数回送信されてよい。

通常、メディアデータは、セグメントの系列へと構成される。各セグメントは、メディアデータの特定の時間的な区分に対応してよく、ある特定の長さ、たとえば2秒を有し得る。セグメントは、複数のメディアフラグメントを含んでよく、これは、ビデオデータの個々のフレームまたはスライスに対応し得る。セグメントはまた、メディアフラグメントの位置を記述するヘッダデータ、たとえば、メディアフラグメントに対するバイトオフセットおよびメディアフラグメントの対応する時間的な位置を含み得る。セグメントは、たとえば、2秒から10秒、またはそれよりも長い再生時間の、個々のファイルに対応し得る。ファイルの各々は、ユニキャストのための特定のuniform resource locator(URL)によってアドレス指定可能であり得る。ユニキャストの例において、クライアントデバイスは、特定のURLにあるファイルを求めるHTTP GETリクエストを出して、ファイルを検索することができる。

セグメントのデータは、別個のパケット内にカプセル化され得る。本開示の技法によれば、セグメントのパケットのすべてではなく一部が受信される場合、クライアントデバイスは、可能な限り多くのセグメントを使用し、(失われたデータに対応する)セグメントの残りを、デフォルトのオーディオおよび/またはビデオデータで埋めようと試みることができる。このことは、たとえば、受信されたパケットの破損していないデータを読み取って、破損していないデータのメディアデータの識別情報を決定することを含み得る。

したがって、クライアントデバイスは、デフォルトのオーディオおよびビデオデータに対応するテンプレートによって構成され得る。セグメントの1つまたは複数のパケットからのデータが失われる場合(たとえば、到達しないこと、到達が遅すぎること、または破損が原因で)、クライアントデバイスは、テンプレートを使用して、デフォルトのオーディオおよびビデオデータを失われたデータに対応する位置に挿入することによって、セグメントの残りを構築することができる。テンプレートは、セグメントを再構築するときにクライアントデバイスが埋めることができる、タイミング情報を挿入するフィールドを提供することができる。クライアントデバイスはさらに、セグメントのヘッダデータを修正して、デフォルトデータの追加を反映、たとえば、修正されたセグメントからのデータの適切な取り出しを確実にすることができる。

たとえば、コード化ビデオシーケンスのピクチャは通常、フレーム番号(frame_num)値およびピクチャ順序カウント(POC)値のいずれかまたは両方を使用して識別され、ここでframe_num値は一般にピクチャの復号順序を示し、POC値は一般にピクチャの出力または表示の順序を示す。デフォルトビデオデータを利用するために、クライアントデバイスは、受信されたビデオデータのframe_numおよび/またはPOC値を使用して、デフォルトビデオデータの適切なframe_numおよび/またはPOC値を決定することができる。いくつかの例では、デフォルトビデオデータは、instantaneous decoder refresh(IDR)ピクチャに対応するランダムアクセスポイント(RAP)で開始し得る。関連するビデオコーディング規格に応じて、クライアントデバイスは、それに従ってIDRピクチャのframe_num値を設定することができる。たとえば、ITU-T H.264/AVC(advanced video coding)規格は、IDRピクチャが「0」というframe_num値を有するべきであることを規定する。さらに、挿入されるべきデフォルトデータの量は、喪失または破損したデータの量に依存し得る。したがって、使用すべきPOC値の範囲も、喪失または破損したデータの置換として使用されることになるデフォルトビデオデータのピクチャの数に依存し得る。

上で論じられたように、本開示の技法は、DASHのようなストリーミングネットワークプロトコルとともに使用され得る。DASHは、種々のモバイルネットワークを通じたストリーミングされるコンテンツの配信に有用である。実際には、DASHは、eMBMS(enhanced Multimedia Broadcast Multicast Service)のようなブロードキャストネットワークで効果的に使用されることが可能であり、ここでDASHセグメントは、ネットワークを通じてマルチキャストサービスクライアント(クライアントデバイス上で実装され得る)にブロードキャストされ、次いで、HTTPを使用してDASHクライアントにストリーミングされ得る。マルチキャストネットワークにおいてDASHを使用するための技法の例が、2012年4月4日に出願された、Stockhammer他の、“NETWORK STREAMING OF VIDEO DATA USING BYTE RANGE REQUESTS”、米国特許出願第13/439,556号で説明されている。

それにもかかわらず、上で論じられたように、ブロードキャストネットワークは、他のコンピュータネットワークのように、パケット喪失を被ることがあり、これはセグメントの喪失をもたらし得る。これは、劣悪なユーザエクスペリエンスをもたらし得る。ランダムなエラーの存在下では、マルチキャストサービスクライアントは、セグメントをDASHクライアントに配信することが可能ではないことがあり、DASH HTTPインターフェースは、本開示の技法以外では、そのような喪失をDASHクライアントに示すための機構を何ら有し得ない。したがって、本開示の技法は、パケットおよびセグメントのエラーを克服するための、簡単で巧みな機構を提供し、改善されたユーザエクスペリエンスをエンドユーザに提供するために使用され得る。

具体的には、本開示の技法によれば、ランダムなネットワークエラーの存在下で、マルチキャストサービスクライアントは、DASHセグメント全体ではなく、セグメントのパケットの一部を受信することができる。いくつかの例では、マルチキャストサービスクライアントは、HTTP応答「404」メッセージをDASHクライアントに送信することができ、完全なDASHセグメントが受信されていないことを示す。DASHクライアントおよびマルチメディアプレーヤは次いで、セグメント喪失を克服するために、スキップまたはエラー復元を導入することができる。しかしながら、本開示の技法によれば、マルチキャストサービスクライアントは、種々のステップを実行してパケット喪失を克服することができる。

たとえば、マルチキャストサービスクライアントは、セグメントエラーの場合に非揮発性記憶装置に記憶されているデフォルトセグメントのデータを送信することができる。したがって、DASHクライアントがデフォルトセグメントを受信すると、そのことが、エラー復元の方策を可能にし得る。別の例として、そうされなければ空の画面が長期間にわたり提示されたであろうときに、不揮発性メモリに記憶されるデフォルトセグメントが提示され得る。すなわち、マルチメディアプレーヤは、ある数のフレームの提示のためのメディアデータが受信されていないことを検出することができ、したがって、メディアプレーヤを実行するデバイスのディスプレイに空の画面を提示し続けるのではなく、デフォルトメディアデータの再生を開始することができる。さらに別の例として、DASHセグメントのいくつかの部分が受信されるが欠けている部分がある場合、マルチキャストサービスクライアントは、セグメントの受信されたパケットおよび記憶されたデフォルトセグメントを使用して、置換セグメントとも本明細書では呼ばれる、DASHセグメントの補間されたバージョンを生成することができる。置換セグメントはDASHクライアントに送信されてよく、これにより、置換セグメントのデータがメディアプレーヤによって再生され得る。いくつかの例では、マルチキャストサービスクライアントは、受信されたセグメントの履歴を保持し、DASHセグメントの欠けている部分の補間されたバージョンを生成することができる。

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

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

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

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

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

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

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

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

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

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

各表現はまた、1つまたは複数のメディアコンポーネントを含んでよく、各メディアコンポーネントは、オーディオ、ビデオ、および/または時限のテキスト(たとえば、字幕のための)のような、1つの個々のメディアタイプの符号化バーションに相当し得る。メディアコンポーネントは、1つの表現内の連続的なメディアセグメントの境界にわたって、時間的に連続的であり得る。したがって、表現は、個々のファイルまたはセグメントのシーケンスに対応してよく、その各々が、同じコーディングおよびレンダリングの特性を含み得る。

失われたデータを、テンプレートデータ、たとえば、デフォルトのオーディオおよびビデオデータで置換するための本開示の技法は、メディアセグメントに対して実行されてよく、メディアセグメントは、1つまたは複数のネットワークパケットの形式で送信され得ることを理解されたい。パケットのデータが破損した状態になると、本開示の技法は、破損したパケットの部分のオーディオおよび/またはビデオデータを、テンプレートのデフォルトデータで置換するステップを含み得る。したがって、デフォルトデータは、前方誤り訂正(FEC)などの他の技法を使用して破損または喪失を訂正することを試みるのではなく、別個の独立したオーディオおよび/またはビデオデータであり得る。

さらに、置換データ(すなわち、デフォルトデータ)は、実際に受信され適切に復号可能であった周囲のデータとは比較的無関係であってよく、すなわち、可能性のある一般的な主題の関係(たとえば、メディアコンテンツの主題に基づいてデフォルトデータを決定する)以外のものであってよい。たとえば、1つまたは複数の適切に復号されたピクチャまたは適切に復号されたオーディオサンプルを繰り返しまたは再び再生することによって、喪失または破損したデータを置換するのではなく、失われたメディアデータは、たとえば実際のメディアデータよりも前に別個に送信されたデフォルトデータによって置換され得る。したがって、デフォルトデータは、クライアントデバイスまたは他の相対的に下流のネットワークデバイスによって、セグメント層でデータ喪失の事象が検出された場合にセグメント層において、ビットストリームに挿入され得る。さらに、失われたメディアデータをテンプレートデータで置換することによって、ビデオデコーダまたはオーディオデコーダは、何らかの喪失が発生したことをデコーダ層において判定する必要なく、デフォルトのオーディオまたはビデオデータを正常に復号することができる。

図1は、ネットワークを通じてメディアデータをストリーミングするための技法を実施する、ある例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40を含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74または別のネットワークによって結合されてよく、または直接通信可能に結合されてよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。いくつかの例では、コンテンツ準備デバイス20は、サーバデバイス60を含む複数のサーバデバイスに、準備されたコンテンツを配信することができる。同様に、いくつかの例では、クライアントデバイス40は、サーバデバイス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規格はさらに実現する。マルチメディアコンテンツの様々な表現が、H.264内の様々なプロファイルおよび符号化のレベルに対応するために、さらに、来るべきHigh Efficiency Video Coding(HEVC)規格のような他の符号化規格に対応するために、提供され得る。

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

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

図1の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からの符号化されたビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からの符号化されたオーディオデータを含むエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化されたデータからPESパケットを形成するためのパケタイザを含み得る。
他の例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化されたデータからPESパケットを形成するためのそれぞれのパケタイザとインターフェースをとり得る。さらに他の例では、カプセル化ユニット30は、符号化されたオーディオデータおよびビデオデータからPESパケットを形成するためのパケタイザを含み得る。本開示の技法によれば、ビデオエンコーダ28は、失われたビデオデータの代替物として使用されることになる、デフォルトビデオデータを符号化することができ、オーディオエンコーダ26は、失われたオーディオデータの代替物として使用されることになる、デフォルトオーディオデータを符号化することができる。したがって、以下で説明されるように、メディアデータのセグメントの1つまたは複数のパケットが失われる(たとえば、破損する、または、有用となる時間内に到達しない)場合、クライアントデバイス40は、デフォルトのオーディオおよび/またはビデオデータで失われたオーディオおよび/またはビデオデータを置き換えることができる。

ビデオエンコーダ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ユニットを含み得るアクセスユニットに格納され得る。

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

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

本開示の技法によれば、メディアデータの喪失の場合に提示されることになるデフォルトのオーディオおよび/またはビデオデータを示すために、テンプレートが使用され得る。いくつかの例では、複数のテンプレートが提供され得る。テンプレートデータは、記憶媒体62に記憶され、クライアントデバイス40に(1回または定期的に)送信され得る。いくつかの例では、マニフェストファイル66は、表現68の1つまたは表現68の特定の部分に対して使用すべき関連するテンプレートを示すデータを含み得る。たとえば、マニフェストファイル66のインスタンスを生成するMPDは、1つまたは複数の時間的な期間に対する1つまたは複数のテンプレートを規定し得る。したがって、対応する時間的な期間の1つに対するメディアデータが失われると、クライアントデバイス40は、適切なテンプレートを決定し、そのテンプレートを使用して、失われたメディアデータ、たとえば失われたオーディオデータとビデオデータのいずれかまたは両方を置換することができる。

追加で、または代替的に、PPS、SPS、またはSEIメッセージが、関連するテンプレートデータを示すために使用され得る。たとえば、SEIメッセージは、SEIメッセージに続くビデオデータのシーケンスのためのテンプレートを識別するテンプレートIDを含み得る。テンプレートおよび対応するデフォルトのオーディオおよびビデオデータは、別個の通信で送信されてよく、たとえば、テンプレートデータに特別に割り振られた1つまたは複数の固有のNALユニットによって識別可能であってよい。

いくつかの例では、テンプレートデータは、外部期間として扱われ得る。サーバデバイス60は、表現68の1つのデータをクライアントデバイス40に送信する前に、外部期間のためのデータ(すなわち、オーディオおよび/またはビデオデータをビットストリームにどのように挿入すべきかを示すデフォルトのビデオおよびオーディオデータならびにタイミングデータを含む、テンプレートデータ)をクライアントデバイス40に送信することができる。サーバデバイス60はまた、定期的に、たとえば、期間あたり1回、セグメントあたり1回、N分に1回、N個の期間あたり1回、もしくはN個のセグメントあたり1回(Nは整数または有理数である)、または、他の間隔で、または、他の非定期的な方式で、テンプレートデータを送信することができる。

いくつかの例では、コンテンツ準備デバイス20はテンプレートデータを提供することができ、テンプレートデータは、デフォルトのオーディオおよびビデオデータを含み得る。すなわち、コンテンツ準備デバイス20は、メディアコンテンツに対するデフォルトのオーディオおよび/またはビデオデータを符号化し、デフォルトのオーディオおよびビデオデータを含むテンプレートデータをサーバデバイス60に送信することができる。他の例では、サーバデバイス60は、たとえば、事前に符号化されたデフォルトのオーディオおよび/またはビデオデータから、テンプレートデータを提供することができる。さらに他の例では、コンテンツ準備デバイス20とサーバデバイス60の両方が、テンプレートデータを提供することができる。たとえば、コンテンツ準備デバイス20は、複数の異なるセットのテンプレートデータを生成することができ、サーバデバイス60は、複数のセットのテンプレートデータのうちの適切な1つを選択することができる。いずれの場合でも、サーバデバイス60は、本開示の技法に従って、テンプレートデータをクライアントデバイス40に提供することができる。

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

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

いくつかの例では、クライアントデバイス40は、選択されたマルチメディアコンテンツのためのテンプレートデータ、たとえば、マルチメディアコンテンツ64のためのテンプレートデータを要求するように構成され得る。他の例では、クライアントデバイス40が特にテンプレートデータを要求したかどうかにかかわらず、サーバデバイス60は、テンプレートデータをクライアントデバイス40に、たとえば1回または定期的に送信することができる。たとえば、クライアントデバイス40がユニキャストネットワーク接続を使用して、マルチメディアコンテンツ64のデータを取り出すと仮定すると、マニフェストファイル66は、表現68の1つまたは複数に対するテンプレートデータを示し得る。したがって、セグメントのデータが失われた場合にクライアントデバイス40が失われたデータをテンプレートのデフォルトのオーディオおよび/またはビデオデータで置換できるように、クライアントデバイス40は最初に、テンプレートデータを要求することができる。

あるいは、サーバデバイス60は、マルチメディアコンテンツ64のデータ、たとえば、表現68の1つのデータをブロードキャストまたはマルチキャストするように構成され得る。この例では、サーバデバイス60は、テンプレートデータを定期的に、たとえば、N個のセグメントごとに1回送信することができ、Nは整数値である。いくつかの例では、テンプレートデータは、別個のセグメントとして送信されてよく、他の例では、テンプレートデータは、セグメントの1つに含まれてよい。

テンプレートデータは、上で述べられたように、デフォルトのオーディオおよび/またはビデオデータを含み得る。たとえば、テンプレートデータは、デフォルトビデオデータを含んでよく、デフォルトビデオデータは、失われたビデオデータに対応する時間の期間全体で表示されるべき単一のピクチャを含み得る。あるいは、デフォルトビデオデータは、動画のシーンを含み得る。同様に、テンプレートデータは、音楽などのデフォルトオーディオデータを含み得る。

図1の例で示されるように、マルチメディアコンテンツ64は、media presentation description(MPD)に対応し得る、マニフェストファイル66を含む。マニフェストファイル66は、様々な代替的な表現68(たとえば、品質が異なるビデオサービス)の説明を格納してよく、この説明は、たとえば、表現68のコーデック情報、プロファイル値、レベル値、ビットレート、および他の説明のための特性を含み得る。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、表現68のセグメントにどのようにアクセスするかを決定することができる。従来のDASHには、バイト範囲を特定するための2つの方法がある。第1の方法は、バイト範囲を個々のフラグメントの定義の中に明示的に入れて、そのバイト範囲をMPD XMLに記憶することである。第2の方法は、MPEGファイル中のセグメントインデックス(SIDX)ボックスからバイト範囲情報をフェッチして、そのSIDXバイト範囲情報を使用して、メディアに対するバイト範囲要求を出すことである。

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

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

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

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

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

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

ウェブアプリケーション52によってサーバデバイス60に出された要求に応答して、ネットワークインターフェース54は、選択された表現の受信されたセグメントのデータを受信して、ウェブアプリケーション52に提供することができる。あるいは、サーバデバイス60は、マルチキャストまたはブロードキャストを使用してセグメントをクライアントデバイス40に送信することができ、この場合、ウェブアプリケーション52は、(クライアントデバイス40の1つまたは複数のプロセッサによって実行され得る)DASHクライアントとマルチキャストサービスクライアントの両方を表し得る。この例では、DASHクライアントは、HTTP GET要求を使用して、マルチキャストサービスクライアントからのセグメントを要求することができ、マルチキャストサービスクライアントは、サーバデバイス60からのマルチキャストまたはブロードキャストを介して受信されるセグメントのデータを使用して、これらの要求に応答することができる。

本開示の技法によれば、ウェブアプリケーション52は、1つまたは複数のセグメントまたはそのデータが失われたかどうかを判定することができる。たとえば、ウェブアプリケーション52(またはネットワークインターフェース54の要素)は、セグメントのためのパケットのシーケンス番号を分析して、1つまたは複数のパケットが失われたかどうかを判定することができる。同様に、ウェブアプリケーション52(またはネットワークインターフェース54の要素)は、セグメントのデータが失われたと見なされるべきかどうかを判定するために、パケットのチェックサムを分析して、前方誤り訂正(FEC)を実行する可能性を伴わずにパケットのデータが破損したかどうかを判定することができる。

いくつかの例では、ネットワーク中のパケットが、決してその宛先に届かないことがある。いくつかの例では、パケットはクライアントデバイス40に到達し得るが、到達が遅すぎる、すなわち、パケットが有用である時刻の後に到達することがある。たとえば、クライアントデバイス40は、たとえば、パケットの順序を並べ替えるために、ネットワーク帯域幅の使用量が急増した場合にメディアデータのバッファを構築するために、または他の同様の理由で、受信されたパケットのデータをバッファリングすることがある。バッファが「アンダーフロー」しそうである、すなわち、特定のパケットの点までのすべてのデータをバッファから除去させそうであり、パケットがまだ到達していないとクライアントデバイス40が判定する場合、クライアントデバイス40は、パケットが失われたと判定し、後続のパケットのデータの処理に進むことができる。したがって、パケットがこの点の後で到達する場合、パケットは、有用となるには到達が遅すぎたと見なされ得る。さらに他の例では、パケットのデータは、たとえば、チャネルのノイズ、ネットワーク経路上の動作不良のネットワークデバイス、または他のエラーが原因で、破損し得る。

いずれの場合でも、上記のエラーの1つまたは複数が発生すると、クライアントデバイス40は、セグメントのデータを「失われた」ものと見なし得る。本開示の技法によれば、セグメントデータが失われる場合、クライアントデバイス40は、失われたセグメントデータを、テンプレートデータ、たとえば、デフォルトのオーディオおよび/またはビデオデータで置換することができる。たとえば、ウェブアプリケーション52は、たとえば、ユニキャスト要求に応答して、または特定の要求を伴わずに、テンプレートデータを1回または定期的にサーバデバイス60から受信することができる。ウェブアプリケーション52は、クライアントデバイス40のメモリ(図示せず)にテンプレートデータを記憶することができる。ウェブアプリケーション52が失われたセグメントデータを検出すると、ウェブアプリケーション52は、失われたセグメントデータをテンプレートデータで置換することができる。いくつかの例では、ウェブアプリケーション52は、セグメント全体が失われたと判定することができ、この場合、ウェブアプリケーション52は、セグメント全体をテンプレートデータで置換することができる。

他の例では、ウェブアプリケーション52は、セグメントのある部分は失われたがセグメントの別の部分は受信されたと判定することがある。この場合、ウェブアプリケーション52は、セグメントの失われた部分をテンプレートデータで置換するが、セグメントの受信された部分はそのままにすることができる。いくつかの例では、ウェブアプリケーション52が、デフォルトのオーディオおよび/またはビデオデータをセグメントへと挿入して、セグメントの失われた部分を置換する場合、ウェブアプリケーション52は、データのあるフィールドに対する値を設定する必要があり得る。たとえば、ウェブアプリケーション52は、デフォルトデータに対するヘッダまたはヘッダの一部を構築すること、たとえば、フレーム番号(frame_num)の値および/またはピクチャ順序カウント(POC)値を、デフォルトビデオデータのピクチャに割り当てることが必要であり得る。Frame_num値は一般に、対応するピクチャの復号順序を示し、一方POC値は一般に、対応するピクチャの表示順序を示す。このようにして、クライアントデバイス40は、セグメントの受信された破損していないデータが正常に復号可能であり、テンプレートデータとともに表示可能であることを、確実にすることができる。ウェブアプリケーション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は、メディアデータのセグメントの少なくとも一部分のデータが失われたことを、セグメントの残りの部分がdynamic adaptive streaming over HTTP(DASH)に従ったネットワーク送信を介して受信された後で判定し、その判定に基づいて、メディアデータを復号する前に、デフォルトデータをセグメントに追加して、失われたと判定されたデータを置換して置換セグメントを形成し、置換セグメントのメディアデータを出力するように構成される、1つまたは複数のプロセッサを含む、メディアデータを提示するためのデバイスの例を表す。

さらに、サーバデバイス60は、少なくとも1つのクライアントデバイスに送信されるべきメディアコンテンツの表現を決定し、決定された表現に対応するデフォルトデータを決定するように構成される、1つまたは複数のプロセッサと、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信して、少なくとも1つのクライアントデバイスに失われたデータをデフォルトデータで置換させ、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信した後に、決定された表現のメディアデータを少なくとも1つのクライアントデバイスに送信するように構成される、1つまたは複数のネットワークインターフェースとを含む、ビデオデータのための情報を送信するためのデバイスの例を表す。

図2は、クライアントデバイスによって受信されるデータを表すグラフ80およびクライアントデバイスによって提示されるデータを表すグラフ86を示す概念図である。クライアントデバイスは、クライアントデバイス40(図1)を含み得る。この例では、クライアントデバイス40は、受信データ82A、受信データ82B、および受信データ82Cを受信する。図2に示されるように、クライアントデバイス40が失われたものと判定するデータを表す、欠落部84A、84Bがある。たとえば、受信データ82A、受信データ82B、および受信データ82Cの受信されたパケットのシーケンス番号の分析に基づいて、かつ/または、欠落部84A、84Bに対応するパケットのチェックサムに基づいて、クライアントデバイス40は、たとえば、到達していないこと、または破損したことが原因で、欠落部84A、84Bのデータが失われたと判定することができる。

本開示の技法によれば、受信データ82Aを受信する前に、クライアントデバイス40は、デフォルトのオーディオおよび/またはビデオデータを含み得る、テンプレートデータを受信することができる。したがって、グラフ86に示されるように、クライアントデバイス40は、受信データ82Aに対応する復号データ88A、受信データ82Bに対応する復号データ88B、および受信データ82Cに対応する復号データ88Cを提示することができる。さらに、欠落部84A、84Bに対応する空の画面を提示するのではなく、クライアントデバイス40は、欠落部84A、84Bにそれぞれ対応する、テンプレートデータ90A、90Bを提示することができる。提示されるようなテンプレートデータ90A、90Bは、復号されたデフォルトのオーディオおよび/またはビデオデータ、または、後で復号されることになる、符号化されたオーディオおよび/またはビデオデータを含み得る。デフォルトデータを提示することによって、クライアントデバイス40は、クライアントデバイス40のエンドユーザにより快適なエクスペリエンスを提供することができる。

図3は、例示的なマルチメディアコンテンツ100の要素を示す概念図である。マルチメディアコンテンツ100は、マルチメディアコンテンツ64(図1)、または記憶媒体62に記憶された別のマルチメディアコンテンツに対応し得る。図3の例では、マルチメディアコンテンツ100は、media presentation description(MPD)102および複数の表現110〜120を含む。表現110は、任意選択のヘッダデータ112およびセグメント114A〜114N(セグメント114)を含み、一方表現120は、任意選択のヘッダデータ122およびセグメント124A〜124N(セグメント124)を含む。表現110と120との間の楕円は、それぞれのヘッダデータおよびセグメントを含み得る、図3に示されない追加の表現を表すことが意図されている。文字Nが、便宜的に、表現110〜120の各々の最後のセグメントを指定するために使用される。いくつかの例では、表現110〜120において、異なる数のセグメントがあり得る。

MPD102は、表現110〜120とは別個のデータ構造を含み得る。MPD102は、図1のマニフェストファイル66に対応し得る。同様に、表現110〜120は、図1の表現68に対応し得る。一般に、MPD102は、コーディングおよびレンダリングの特性、適応セット、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報(たとえば、早送りおよび巻き戻しなどのトリックモードのための時間的なサブシーケンスを含む表現を示す情報)、および/またはテンプレートデータを取り出すための情報のような、表現110〜120の特性を一般に表す、データを含み得る。

本開示の技法によれば、テンプレートデータは、失われたメディアデータを置換するために使用されることになる、デフォルトのオーディオおよび/またはビデオデータ、さらには、そのような置換がどのように行われるべきかを示すデータ(たとえば、ビデオデータのピクチャのフレーム番号フィールドおよび/またはPOC値フィールドなどの、クライアントデバイスによって埋められるべきフィールド)を含み得る。MPD102は、表現110〜120の各々に対応するテンプレートを示す、表現110〜120の1つまたは複数の情報を含み得る。以下で説明されるように、表現110〜120の各々が、テンプレートデータの個々のセットを有してよく、異なる表現に対するテンプレートデータは異なっていてよい。あるいは、やはり以下で説明されるように、テンプレートデータの同じセットが、たとえば適応セットの表現の各々に、複数の表現を適用することができる。MPD102はさらに、たとえばユニキャストを介したテンプレートデータの取り出しが可能である場合、テンプレートデータを取り出すための情報を含み得る。いくつかの例では、クライアントデバイス40のようなクライアントデバイスは、クライアントデバイスがブロードキャストまたはマルチキャストを介してメディアデータを受信する場合でも、ユニキャストを介してテンプレートデータを独立に取り出すように構成され得る。

いくつかの例では、異なるデフォルトのオーディオおよび/またはビデオデータが、表現110〜120の各々に対して提供され得る。たとえば、デフォルトビデオデータは、対応する表現の同じコーディングおよびレンダリング特性を有し得る。3次元ビデオデータを有する表現のために、デフォルトビデオデータも3次元ビデオデータを含み得る。デフォルトビデオデータはまた、対応する表現の空間解像度と同じ空間解像度を有し得る。

いくつかの例では、デフォルトのオーディオおよびビデオデータを含むテンプレートデータは、単一の適応セットに対して提供され得る。したがって、各表現に対するデフォルトのオーディオおよびビデオデータの固有のセットを有するのではなく、各適応セットに対するデフォルトのオーディオおよびビデオデータのセットが存在してもよい。デフォルトのオーディオおよびビデオデータは、したがって、対応する適応セットと同じコーディングおよびレンダリング特性を有し得るが、ユニキャスト、ブロードキャスト、またはマルチキャストのために現在選択されている表現などの、適応セット内の表現と同じビットレートを必ずしも有さないことがある。

ヘッダデータ112は、存在する場合、セグメント114の特性、たとえば、ランダムアクセスポイントの時間的な位置、セグメント114のいずれがランダムアクセスポイントを含むか、セグメント114内のランダムアクセスポイントに対するバイトオフセット、セグメント114のuniform resource locator(URL)、またはセグメント114の他の側面を表すことができる。ヘッダデータ122は、存在する場合、セグメント124の同様の特性を表すことができる。加えて、または代替的に、そのような特性はMPD102内に完全に含まれ得る。同様に、本開示の技法によれば、ヘッダデータ112は、セグメント114の1つまたは複数のデータが失われた(たとえば、到達しない、到達が遅すぎる、または送信中に破損した)場合に使用すべき、関連するテンプレートの指示を含み得る。

セグメント114は、1つまたは複数の符号化されたビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント114の符号化されたビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。そのような特性は、MPD102のデータによって表され得るが、そのようなデータは図3の例には示されない。MPD102は、本開示で説明されるシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP規格によって表されるような特性を含み得る。いくつかの例では、本開示の技法によれば、セグメント114の1つまたは複数は、データの喪失の場合、たとえば、到達しない、到達が遅すぎる、または破損したデータを含む1つまたは複数のパケットがある場合、セグメント114のうちの他のセグメントのデータを置換するために使用され得るテンプレートのデフォルトデータを含み得る。同様に、セグメント124の1つまたは複数もテンプレートデータを含み得る。あるいは、デフォルトのオーディオおよびビデオデータは、表現110〜120のデータとは別に、別個の送信で送信されてよい。

セグメント114、124の各々は、固有のuniform resource identifier(URI)、たとえばuniform resource locator(URL)と関連付けられ得る。したがって、セグメント114、124の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立に検索可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP Get要求を使用して、セグメント114または124を検索することができる。いくつかの例では、クライアントデバイス40は、HTTP partial GET要求を使用して、セグメント114または124の特定のバイト範囲を検索することができる。あるいは、サーバデバイス60(図1)のようなサーバデバイスは、クライアントデバイス40がマルチキャストまたはブロードキャストのデータの受信を要求するだけでよいように、たとえばマルチキャストグループに参加することによって、表現のセグメントをマルチキャストまたはブロードキャストすることができる。

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

ビデオファイル150は一般に、表現110〜120(図3)の1つに含まれ得る、マルチメディアコンテンツのセグメントの例を表す。このようにして、ビデオファイル150は、セグメント114の1つ、セグメント124の1つ、または別の表現のセグメントに対応し得る。本開示の技法によれば、失われた、ビデオファイル150のデータのようなメディアデータは、テンプレートメディアデータによって置換され得る。テンプレートデータは、ビデオファイル150に実質的に一致するビデオファイルで送信され得る。ビデオファイル150が選択された表現のメディアデータを表すと仮定すると、ビデオファイル150を表す1つまたは複数のパケットが到達しないことがある、または有用であるには到達が遅すぎることがある、または、動画フラグメント164に対応するデータが破損した状態になることがあるという点で、データは「失われる」ことがある。

ビデオファイル全体などのセグメント全体が失われる場合、クライアントデバイス40は、セグメント全体を、デフォルトのオーディオおよび/またはビデオデータなどのテンプレートデータを含む置換セグメントで置換することができる。動画フラグメント164の1つまたは複数のような、セグメントの一部分が破損した状態になる場合、クライアントデバイス40は、セグメントのその部分のみをテンプレートデータで置換することができる。たとえば、動画フラグメント164のシーケンスが破損している場合、または、動画フラグメント164のシーケンスに対応する1つまたは複数のパケットが失われた場合、本開示の技法によれば、クライアントデバイス40は、動画フラグメント164の喪失または破損したデータを、テンプレートデータ、たとえばデフォルトのオーディオおよび/またはビデオデータで置換することができる。

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

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

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

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

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

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

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

動画フラグメント164は、1つまたは複数のコード化ビデオピクチャ、さらには、コード化オーディオデータ(コード化オーディオサンプルとも呼ばれる)、テキストの重畳(たとえば、字幕のための)、または他のメディアデータを含み得る。いくつかの例では、動画フラグメント164は、1つまたは複数のピクチャのグループ(GOP:groups of pictures)を含んでよく、GOPの各々は、多数の符号化されたビデオピクチャ、たとえばフレームまたはピクチャを含み得る。動画フラグメント164の各々は、動画フラグメントヘッダボックス(MFHD、図4には示されない)を含み得る。MFHDボックスは、動画フラグメントのシーケンス番号のような、対応する動画フラグメントの特性を表し得る。動画フラグメント164は、ビデオファイル150の中で、シーケンス番号の順番に含まれ得る。

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

図5は、テンプレートデータを提供および使用して失われたメディアデータを置換するための例示的な方法を示すフローチャートである。本明細書で述べられるように、テンプレートデータは、デフォルトのビデオおよび/またはオーディオデータを含み得る。図5の例では、クライアントデバイス(たとえば、クライアントデバイス40)およびサーバデバイス(たとえば、サーバデバイス60)が、この方法に参加する。他の例では、追加のまたは代替のデバイスもこの方法に参加してよい。

図5の例では、クライアントデバイス40は最初に、メディアコンテンツのためのマニフェストファイルを要求することができる(200)。この要求は、たとえばユニキャストのためにサーバデバイス60に向けられてよく、または、マルチキャストグループに加入するための間接的な要求であってよい。図5の例に示されるように、サーバデバイス60は、要求に応答してマニフェストファイルをクライアントデバイス40に送信することができる(202)。あるいは、サーバデバイス60は、ネットワークマルチキャストのために最初に、マニフェストファイルをマルチキャストグループに提供することができる。いずれの場合でも、クライアントデバイス40は、マニフェストファイルを受信し(204)、マニフェストファイルに基づいてメディアデータを要求することができる(206)。たとえば、クライアントデバイス40は、コーディングおよびレンダリング特性と、マニフェストファイルによって記述される表現のビットレートとに基づいて表現を選択し、選択された表現のセグメントを要求することができる。あるいは、マルチキャストまたはブロードキャストの状況では、利用可能な1つだけの表現、すなわち、サーバデバイス60によって選択される表現が存在し得る。いくつかの例では、マニフェストファイルは、メディアコンテンツと関連付けられるマルチキャストグループのIPアドレス、または、マルチキャストのデータを受信するための他の情報を含み得る。

この例では、サーバデバイス60は、要求されるメディアデータのためにテンプレートデータを送信することができる(208)。メディアデータがブロードキャストまたはマルチキャストを介して送信される例では、送信されるテンプレートデータは、サーバデバイス60によって選択される表現に対応し得る。テンプレートデータは、デフォルトのオーディオおよびビデオデータ、さらには、デフォルトのオーディオ/ビデオデータを使用するための任意の他の情報を含み得る。たとえば、テンプレートデータは、frame_numおよび/またはPOC値などの、埋められるべきヘッダデータの1つまたは複数のフィールドを示す情報、さらには、テンプレートデータに関連する、PPS、SPS、および/またはSEIメッセージなどの、任意の他の関連情報を含み得る。テンプレートデータは、ビデオファイル150に実質的に一致するテンプレートセグメント(図4)などの、別個のセグメントとしてカプセル化され得る。あるいは、テンプレートデータは、対応するメディアコンテンツのメディアデータを含むセグメントに含まれ得る。

いくつかの例では、マニフェストファイルは、テンプレートデータを含むセグメントのURLを含み得る。そのような例では、クライアントデバイス40はさらに、たとえば、別個のHTTP GET要求または部分GET要求を使用して、テンプレートデータを取り出すための要求を出すことができる。したがって、テンプレートデータは、ユニキャスト、ブロードキャスト、またはマルチキャストネットワーク送信を介して送信されてよく、要求されたメディアデータとともに帯域内で、または、帯域外で、すなわち、物理的または論理的に別個の通信チャネルを介して送信され得る要求されたメディアデータとは別個のネットワーク送信として送信されてよい。いずれの場合でも、クライアントデバイス40は、サーバデバイス60からテンプレートデータを受信することができる(210)。いくつかの例では、クライアントデバイス40は、メディアデータを提供するサーバデバイスとは別個のサーバデバイスからテンプレートデータを受信することができる。図5の例では別個のステップとして示されるが、メディアコンテンツ(たとえば、ステップ208)のためのテンプレートデータの送信および要求されたメディアデータ(たとえば、ステップ212)は並列に行われてよく、または単一のステップとして行われてよいことを理解されたい。たとえば、要求されたメディアデータのセグメント(または、メディアコンテンツの別の部分)が、テンプレートデータを含み得る。

サーバデバイス60はまた、要求されたメディアデータのセグメントを送信することができる(212)。ユニキャスト送信では、サーバデバイス60は、HTTP GET要求またはpartial GET要求で規定されるURLに対応するセグメント(または、セグメントの一部分)を送信することができ、一方でマルチキャストまたはブロードキャスト送信では、サーバデバイス60は、クライアントデバイスからの要求を待機することなく、次の利用可能なセグメントを送信することができる。クライアントデバイス40は次いで、セグメントのデータが失われたかどうかを判定することができる(214)。たとえば、クライアントデバイス40は、受信されたパケットのシーケンス番号を分析して、予想されるセグメントの1つまたは複数のパケットがまったく到達しなかったか、または有用となる時間内に到達しなかったかを判定することができる。別の例として、クライアントデバイス40は、たとえば、パケットのチェックサムを使用して、セグメントの1つまたは複数のパケットが破損したデータを含むかどうかを判定することができる。

いずれの場合でも、セグメントのデータが失われたとクライアントデバイス40が判定する場合(214の“YES”の分岐)、クライアントデバイス40は、失われたデータを、ステップ210で受信されたテンプレートデータに対応するテンプレートデータで置換することによって、置換セグメントを構築することができる(216)。たとえば、パケットのデータのすべてが到達しなかった場合、クライアントデバイス40は、セグメント全体を、テンプレートデータのデフォルトのオーディオおよび/またはビデオデータで置換することができる。あるいは、セグメントの一部分は到達したがセグメントの別の部分は到達しなかった場合、クライアントデバイス40は、到達しなかったセグメントの部分を、テンプレートデータのデフォルトのオーディオおよび/またはビデオデータで置換することができる。

クライアントデバイス40は次いで、置換セグメントをカプセル化解除ユニット50に送信することができ、今度はカプセル化解除ユニット50が、カプセル化解除された符号化オーディオデータをオーディオデコーダ46に、カプセル化解除された符号化ビデオデータをビデオデコーダ48に提供することができる(218)。一方、セグメントのデータが失われていない場合(214の“NO”の分岐)、クライアントデバイス40は、受信セグメントをカプセル化解除ユニット50に送信することができ、今度はカプセル化解除ユニット50が、カプセル化解除された符号化オーディオデータをオーディオデコーダ46に、カプセル化解除された符号化ビデオデータをビデオデコーダ48に提供することができる(220)。セグメントが置換セグメントか修正されていない受信セグメントかにかかわらず、オーディオデコーダ46は符号化オーディオデータを復号することができ、一方、ビデオデコーダ48はセグメントの符号化ビデオデータを復号することができる(222)。したがって、オーディオデコーダ46およびビデオデコーダ48の観点からは、セグメントのデータは、デフォルトデータによって修正または置換されたようには見えない。代わりに、セグメントのデータは、予想される符号化オーディオデータまたはビデオデータに見える。たとえば、置換セグメントのビデオデータに対して、クライアントデバイス40は、frame_num値および/またはPOC値の適切な値を提供して、ビデオデコーダ48がデフォルトビデオデータを適切に復号することが可能となることを確実にできる。

復号の後、クライアントデバイス40は、復号されたオーディオおよびビデオデータを提示することができる(224)。たとえば、オーディオ出力42は復号されたオーディオデータを提示することができ、一方ビデオ出力44は復号されたビデオデータを表示することができる。上で述べられたように、セグメントのデータが失われた場合、送信されるメディアデータと提示されるメディアデータとの間にわずかな不連続部分があることがあるが、この場合に提示されるようなメディアデータは、デフォルトビデオデータの場合、単に空の画面を提示するよりも良好なユーザエクスペリエンスを提供する。

このように、図5は、メディアデータを提示する方法の例を表し、この方法は、メディアデータのセグメントの少なくとも一部分のデータが失われたことを、セグメントの残りの部分がdynamic adaptive streaming over HTTP(DASH)に従ったネットワーク送信を介して受信された後で判定するステップと、その判定に基づいて、メディアデータを復号する前に、デフォルトデータをセグメントに追加して、失われたと判定されたデータを置換して置換セグメントを形成するステップと、置換セグメントのメディアデータを出力するステップとを含む。

図5はまた、メディアデータの情報を送信する方法の例を表し、この方法は、少なくとも1つのクライアントデバイスに送信されるべきメディアコンテンツの表現を決定するステップと、決定された表現に対応するデフォルトデータを決定するステップと、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信して、少なくとも1つのクライアントデバイスに失われたデータをデフォルトデータで置換させるステップと、決定されたデフォルトデータを少なくとも1つのクライアントデバイスに送信した後に、決定された表現のメディアデータを少なくとも1つのクライアントデバイスに送信するステップとを含む。

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 サーバデバイス
64 マルチメディアコンテンツ
66 マニフェストファイル
68 表現
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
80 グラフ
82A 受信データ
82B 受信データ
82C 受信データ
84A 欠落部
84B 欠落部
86 グラフ
88A 復号データ
88B 復号データ
88C 復号データ
90A テンプレートデータ
90B テンプレートデータ
102 MPD
110 表現
112 ヘッダデータ
114 セグメント
150 ビデオファイル
152 ファイルタイプボックス
154 動画ボックス
162 セグメントインデックスボックス
164 動画フラグメント
166 動画フラグメントランダムアクセスボックス

Claims (43)

1. メディアデータを処理する方法であって、前記メディアデータのフレームがデコーダによって復号される前に前記メディアデータを処理する、前記デコーダと別個の処理ユニットによって処理され、
   メディアデータのセグメントの少なくとも一部分のデータが失われたことを、前記セグメントの残りの部分がdynamic adaptive streaming over HTTP(DASH)に従ったネットワーク送信を介して受信された後で判定するステップであって、前記セグメントの前記メディアデータが第1の複数のフレームを含み、前記第1の複数のフレームは、前記セグメントの外部のフレームを参照することなく符号化され、失われた前記データは、前記第1の複数のフレームのサブセットである第2の複数のフレームを含むステップと、
   前記判定に基づいて、前記デコーダが前記セグメントの前記メディアデータの任意の前記フレームを復号する前に、追加されたデフォルトデータの期間が、前記第2の複数のフレームにおけるフレーム数の期間と等しくなるように、前記デフォルトデータを前記セグメントに追加して、失われたと判定された前記データを置換して置換セグメントを形成するステップと、
   前記置換セグメントのメディアデータを前記デコーダに出力するステップとを含む、方法。
2. 前記セグメントの前記少なくとも一部分の前記データが失われたと判定するステップが、前記セグメントの少なくとも1つのパケットが到達しなかった、または破損したと判定するステップを含む、請求項1に記載の方法。
3. デフォルトデータを追加するステップが、デフォルトオーディオデータとデフォルトビデオデータの少なくとも1つを前記セグメントに追加するステップを含む、請求項1に記載の方法。
4. デフォルトデータを追加するステップがデフォルトビデオデータを前記セグメントに追加するステップを含み、前記デフォルトビデオデータが、前記セグメントの前記残りの部分を受信したネットワークのロゴの画面、季節に関連する表示、およびコンテンツに関連する表示のうちの1つを含む、請求項1に記載の方法。
5. デフォルトデータを追加するステップが、コンテンツに関連するオーディオデータを前記セグメントに追加するステップを含む、請求項1に記載の方法。
6. 前記デフォルトデータの前記追加に基づいて、前記セグメントのヘッダを修正するステップをさらに含む、請求項1に記載の方法。
7. 前記デフォルトデータを定義する情報を受信するステップをさらに含む、請求項1に記載の方法。
8. 前記デフォルトデータを定義する前記情報を受信するステップが、前記ネットワーク送信の一部として前記デフォルトデータを定義する前記情報を受信するステップを含む、請求項7に記載の方法。
9. 前記デフォルトデータを定義する前記情報を受信するステップが、付随する情報として前記デフォルトデータを定義する前記情報を受信するステップを含む、請求項7に記載の方法。
10. 前記デフォルトデータを示す構成データを取り出すステップをさらに含む、請求項1に記載の方法。
11. 前記メディアデータがビデオデータを含み、前記デコーダがビデオデコーダを含み、出力するステップが、前記置換セグメントの前記ビデオデータを前記ビデオデコーダに送信するステップを含む、請求項1に記載の方法。
12. 前記デフォルトデータを追加するステップが、フレーム番号とピクチャ順序カウント(POC)値の少なくとも1つの値を、前記デフォルトデータのピクチャに割り当てるステップを含む、請求項11に記載の方法。
13. 前記メディアデータがオーディオデータを含み、前記デコーダがオーディオデコーダを含み、出力するステップが、前記置換セグメントの前記オーディオデータを前記オーディオデコーダに送信するステップを含む、請求項1に記載の方法。
14. 前記デフォルトデータが、前記メディアデータと別個かつ独立したデータを含むとともに、喪失訂正技法または破損訂正技法に起因しない、請求項1に記載の方法。
15. 前記セグメントの任意のデータを受信する前に、前記デフォルトデータを受信するステップをさらに含む、請求項1に記載の方法。
16. メディアデータを処理するためのデバイスであって、
    デコーダと、
    前記メディアデータのフレームの前の前記メディアデータが前記デコーダによって復号される、前記デコーダと別個の1つまたは複数のプロセッサであって、
    メディアデータのセグメントの少なくとも一部分のデータが失われたことを、前記セグメントの残りの部分がdynamic adaptive streaming over HTTP(DASH)に従ったネットワーク送信を介して受信された後で判定することであって、前記セグメントの前記メディアデータが第1の複数のフレームを含み、前記第1の複数のフレームは、前記セグメントの外部のフレームを参照することなく符号化され、失われた前記データは、前記第1の複数のフレームのサブセットである第2の複数のフレームを含む、判定することと、
    前記判定に基づいて、前記デコーダが前記セグメントの前記メディアデータの任意の前記フレームを復号する前に、追加されたデフォルトデータの期間が、前記第2の複数のフレームにおけるフレーム数の期間と等しくなるように、前記デフォルトデータを前記セグメントに追加して、失われたと判定された前記データを置換して置換セグメントを形成することと、
    前記置換セグメントのメディアデータを前記デコーダに出力することと
    を行うように構成される、1つまたは複数のプロセッサを含む、デバイス。
17. 前記セグメントの少なくとも1つのパケットが到達しなかった、または破損したときに、前記1つまたは複数のプロセッサが、前記セグメントの前記少なくとも一部分の前記データが失われたと判定するように構成される、請求項16に記載のデバイス。
18. 前記1つまたは複数のプロセッサが、デフォルトオーディオデータとデフォルトビデオデータの少なくとも1つを前記セグメントに追加するように構成される、請求項16に記載のデバイス。
19. 前記1つまたは複数のプロセッサがさらに、前記デフォルトデータを定義する情報を受信するように構成される、請求項16に記載のデバイス。
20. 前記デコーダがビデオデコーダをさらに含み、前記メディアデータがビデオデータを含み、前記1つまたは複数のプロセッサが、前記置換セグメントの前記ビデオデータを前記ビデオデコーダに送信するように構成される、請求項16に記載のデバイス。
21. 前記1つまたは複数のプロセッサが、フレーム番号とピクチャ順序カウント(POC)値の少なくとも1つの値を、前記デフォルトデータのピクチャに割り当てるように構成される、請求項20に記載のデバイス。
22. 前記デフォルトデータが、前記メディアデータと別個かつ独立したデータを含むとともに、喪失訂正技法または破損訂正技法に起因しない、請求項16に記載のデバイス。
23. 前記1つまたは複数のプロセッサが、前記セグメントの任意のデータを受信する前に、前記デフォルトデータを受信するようにさらに構成される、請求項16に記載のデバイス。
24. メディアデータを処理するためのデバイスであって、
    デコーダと、
    メディアデータのセグメントの少なくとも一部分のデータが失われたことを、前記セグメントの残りの部分がdynamic adaptive streaming over HTTP(DASH)に従ったネットワーク送信を介して受信された後で判定するための、前記メディアデータのフレームがデコーダによって復号される前に前記メディアデータを処理する、前記デコーダと別個の手段であって、前記セグメントの前記メディアデータが第1の複数のフレームを含み、前記第1の複数のフレームは、前記セグメントの外部のフレームを参照することなく符号化され、失われた前記データは、前記第1の複数のフレームのサブセットである第2の複数のフレームを含む手段と、
    前記判定に基づいて、前記デコーダが前記セグメントの前記メディアデータの任意の前記フレームを復号する前に、追加されたデフォルトデータの期間が、前記第2の複数のフレームにおけるフレーム数の期間と等しくなるように、前記デフォルトデータを前記セグメントに追加して、失われたと判定された前記データを置換して置換セグメントを形成するための、前記メディアデータのフレームがデコーダによって復号される前に前記メディアデータを処理する、前記デコーダと別個の手段と、
    前記置換セグメントのメディアデータを前記デコーダに出力するための、前記メディアデータのフレームがデコーダによって復号される前に前記メディアデータを処理する、前記デコーダと別個の手段とを含む、デバイス。
25. 前記セグメントの前記少なくとも一部分の前記データが失われたと判定するための手段が、前記セグメントの少なくとも1つのパケットが到達しなかった、または破損したと判定するための手段を含む、請求項24に記載のデバイス。
26. デフォルトデータを追加するための前記手段が、デフォルトオーディオデータとデフォルトビデオデータの少なくとも1つを前記セグメントに追加するための手段を含む、請求項24に記載のデバイス。
27. 前記デフォルトデータを定義する情報を受信するための手段をさらに含む、請求項24に記載のデバイス。
28. 前記デフォルトデータを定義する前記情報を受信するための前記手段が、前記ネットワーク送信の一部として前記デフォルトデータを定義する前記情報を受信するための手段を含む、請求項27に記載のデバイス。
29. 前記デフォルトデータを定義する前記情報を受信するための前記手段が、付随する情報として前記デフォルトデータを定義する前記情報を受信するための手段を含む、請求項27に記載のデバイス。
30. 前記デコーダがビデオデコーダを含み、前記メディアデータがビデオデータを含み、出力するための前記手段が、前記置換セグメントの前記ビデオデータを、前記ビデオデコーダに送信するための手段を含む、請求項24に記載のデバイス。
31. 前記デフォルトデータを追加するための前記手段が、フレーム番号とピクチャ順序カウント(POC)値の少なくとも1つの値を、前記デフォルトデータのピクチャに割り当てるための手段を含む、請求項30に記載のデバイス。
32. 前記デフォルトデータが、前記メディアデータと別個かつ独立したデータを含むとともに、喪失訂正技法または破損訂正技法に起因しない、請求項24に記載のデバイス。
33. 前記セグメントの任意のデータを受信する前に、前記デフォルトデータを受信するための手段をさらに含む、請求項24に記載のデバイス。
34. 実行されると、メディアデータのフレームがデコーダによって復号される前に前記メディアデータを処理する、前記デコーダと別個の1つまたは複数のプロセッサに、
    メディアデータのセグメントの少なくとも一部分のデータが失われたことを、前記セグメントの残りの部分がdynamic adaptive streaming over HTTP(DASH)に従ったネットワーク送信を介して受信された後で判定することであって、前記セグメントの前記メディアデータが第1の複数のフレームを含み、前記第1の複数のフレームは、前記セグメントの外部のフレームを参照することなく符号化され、失われた前記データは、前記第1の複数のフレームのサブセットである第2の複数のフレームを含む、判定することと、
    前記判定に基づいて、前記デコーダが前記セグメントの前記メディアデータの任意の前記フレームを復号する前に、追加されたデフォルトデータの期間が、前記第2の複数のフレームにおけるフレーム数の期間と等しくなるように、前記デフォルトデータを前記セグメントへ追加して、失われたと判定された前記データを置換して置換セグメントを形成することと、
    前記置換セグメントのメディアデータを前記デコーダに出力することと
    を行わせる命令を記憶した、コンピュータ可読記憶媒体。
35. 前記1つまたは複数のプロセッサに、前記セグメントの前記少なくとも一部分の前記データが失われたと判定させる前記命令が、前記1つまたは複数のプロセッサに、前記セグメントの少なくとも1つのパケットが到達していない、または破損したと判定させる命令を含む、請求項34に記載のコンピュータ可読記憶媒体。
36. 前記1つまたは複数のプロセッサにデフォルトデータを追加させる前記命令が、前記1つまたは複数のプロセッサに、デフォルトオーディオデータとデフォルトビデオデータの少なくとも1つを前記セグメントへ追加させる命令を含む、請求項34に記載のコンピュータ可読記憶媒体。
37. 前記1つまたは複数のプロセッサに、前記デフォルトデータを定義する情報を受信させる命令をさらに含む、請求項34に記載のコンピュータ可読記憶媒体。
38. 前記1つまたは複数のプロセッサに前記デフォルトデータを定義する前記情報を受信させる前記命令が、前記1つまたは複数のプロセッサに、前記デフォルトデータを定義する前記情報を前記ネットワーク送信の一部として受信させる命令を含む、請求項37に記載のコンピュータ可読記憶媒体。
39. 前記1つまたは複数のプロセッサに前記デフォルトデータを定義する前記情報を受信させる前記命令が、前記1つまたは複数のプロセッサに、付随する情報として前記デフォルトデータを定義する前記情報を受信させる命令を含む、請求項37に記載のコンピュータ可読記憶媒体。
40. 前記メディアデータがビデオデータを含み、前記デコーダがビデオデコーダを含み、前記1つまたは複数のプロセッサに出力させる前記命令が、前記1つまたは複数のプロセッサに、前記置換セグメントの前記ビデオデータを前記ビデオデコーダへ送信させる命令を含む、請求項34に記載のコンピュータ可読記憶媒体。
41. 前記1つまたは複数のプロセッサに前記デフォルトデータを追加させる前記命令が、前記1つまたは複数のプロセッサに、フレーム番号とピクチャ順序カウント(POC)値の少なくとも1つの値を前記デフォルトデータのピクチャへ割り当てさせる命令を含む、請求項40に記載のコンピュータ可読記憶媒体。
42. 前記デフォルトデータが、前記メディアデータと別個かつ独立したデータを含むとともに、喪失訂正技法または破損訂正技法に起因しない、請求項34に記載のコンピュータ可読記憶媒体。
43. 前記セグメントの任意のデータを受信する前に、前記デフォルトデータを受信させる命令をさらに含む、請求項34に記載のコンピュータ可読記憶媒体。

Images