特許 5930429 ファイル配信方式を使用したＩＰブロードキャストストリーミングサービスの配信

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5930429

(24)【登録日】2016年5月13日

(45)【発行日】2016年6月8日

(54)【発明の名称】ファイル配信方式を使用したＩＰブロードキャストストリーミングサービスの配信

(51)【国際特許分類】

   H04N 21/238 20110101AFI20160526BHJP

   H04L 12/70 20130101ALI20160526BHJP

   G06F 13/00 20060101ALI20160526BHJP

   H04N 21/64 20110101ALI20160526BHJP

【ＦＩ】

   H04N21/238

   H04L12/70 E

   G06F13/00 540E

   H04N21/64

【請求項の数】58

【全頁数】51

(21)【出願番号】特願2014-504001(P2014-504001)

(86)(22)【出願日】2012年4月5日

(65)【公表番号】特表2014-517558(P2014-517558A)

(43)【公表日】2014年7月17日

(86)【国際出願番号】US2012032399

(87)【国際公開番号】WO2012138909

(87)【国際公開日】20121011

【審査請求日】2013年10月21日

(31)【優先権主張番号】61/472,116

(32)【優先日】2011年4月5日

(33)【優先権主張国】US

(31)【優先権主張番号】13/439,518

(32)【優先日】2012年4月4日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】507364838

【氏名又は名称】クアルコム，インコーポレイテッド

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100163522

【弁理士】

【氏名又は名称】黒田 晋平

(72)【発明者】

【氏名】ドナルド・ダブリュ・ギリース

(72)【発明者】

【氏名】チャールズ・エヌ・ロ

(72)【発明者】

【氏名】マイケル・ジー・ルビー

(72)【発明者】

【氏名】トーマス・ストックハンマー

【審査官】 梅本 達雄

(56)【参考文献】

【文献】 国際公開第２００８／０８４４４１（ＷＯ，Ａ１）

【文献】 特表２００９−５３９３０４（ＪＰ，Ａ）

【文献】 国際公開第２０１１／０３８０２８（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ １９／００ − １９／９８

Ｈ０５Ｎ ２１／００ − ２１／８５８

Ｈ０４Ｈ ２０／００ − ６０／９８

Ｈ０４Ｌ １２／７０ − １２／９５５

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

ビデオデータの情報を検索する方法であって、
ユニキャストプロトコルに従って第1の表現からメディアコンテンツの第1の部分を検索するステップであって、前記メディアコンテンツが、適応ビデオストリーミングネットワークプロトコルに準拠する、ステップと、
ファイル配信サービスを介してブロードキャストプロトコル又はマルチキャストプロトコルに従って第2の表現から前記メディアコンテンツの第2の部分を検索するステップであって、前記第1の部分および前記第2の部分が、前記メディアコンテンツの中で時間的に連続しており、前記第1の部分及び第2の部分に対応する前記第１の表現のセグメントは、第1の時間長を有しており、前記第１の部分及び第2の部分に対応する前記第2の表現のセグメントは、第2の時間長を有しており、前記第2の時間長は、前記第1の時間長よりも長い、ステップと、
を含むことを特徴とする方法。

【請求項2】

前記マルチキャストプロトコルに従って前記第2の部分を検索するステップが、インターネットプロトコル(IP)マルチキャストグループに加わることを要求するステップ、またはブロードキャストファイル配信を受信するために登録するステップのいずれかを含む、請求項1に記載の方法。

【請求項3】

前記第2の部分を検索するステップが、前記IPマルチキャストグループに加わることを要求するステップを含み、
前記方法が、前記IPマルチキャストグループのIPアドレスを受信するステップをさらに含む、請求項2に記載の方法。

【請求項4】

前記第1の部分が、前記第2の部分とは異なる符号化特性を有する、請求項1に記載の方法。

【請求項5】

前記ファイル配信サービスが、File Delivery over Unidirectional Transport(FLUTE)を含み、前記方法が、前記メディアコンテンツの1つまたは複数のユニキャストuniform resource locator(URL)を示すFile Delivery Table(FDT)の属性を受信するステップをさらに含む、請求項1に記載の方法。

【請求項6】

前記第2の部分を検索するステップが、ブロードキャストメディアアクセス制御(MAC)プロトコルを通じてファイルブロードキャストサービスを介して、前記第2の部分を受信するステップを含む、請求項1に記載の方法。

【請求項7】

前記ブロードキャストMACプロトコルが、enhanced Multimedia Broadcast Multicast Service(eMBMS)を含む、請求項6に記載の方法。

【請求項8】

前記ファイル配信サービスに従って受信された前記メディアコンテンツの前記第2の部分のデータを、ローカルメモリにキャッシュするステップをさらに含む、請求項1に記載の方法。

【請求項9】

前記メディアコンテンツのデータの少なくとも前記部分を求める後続の要求に応答して、前記ローカルメモリから、キャッシュされた前記データを検索するステップをさらに含む、請求項8に記載の方法。

【請求項10】

キャッシュするステップが、
前記ファイル配信サービスに従って、1つまたは複数のキャッシングプリミティブの値を受信するステップと、
前記1つまたは複数のキャッシングプリミティブの前記値に従って、少なくとも前記部分の前記データをキャッシュするステップと、
を含む、請求項8に記載の方法。

【請求項11】

前記1つまたは複数のキャッシングプリミティブが、前記メディアコンテンツの少なくとも前記部分が送信された日付を示す日付プリミティブ、前記メディアコンテンツの少なくとも前記部分が失効する時を示す失効プリミティブ、前記メディアコンテンツの具体的なバージョンを特定するエンティティタグ(ETag)、前記メディアコンテンツのデータがキャッシュ可能であることを示すキャッシュ制御ヘッダのうちの、1つまたは複数を含む、請求項10に記載の方法。

【請求項12】

前記メディアコンテンツの前記第1の部分を検索するステップが、
前記メディアコンテンツの前記第1の部分が現在キャッシュに記憶されているかどうかを判定するステップと、
前記メディアコンテンツの前記第1の部分が前記キャッシュに現在記憶されていない場合、前記ユニキャストプロトコルに従って前記メディアコンテンツの前記第1の部分を検索するステップと、
を含む、請求項8に記載の方法。

【請求項13】

前記メディアコンテンツの前記第2の部分が、時間的に連続して、前記メディアコンテンツの前記第1の部分の後に続き、前記メディアコンテンツの前記第1の部分を検索するステップが、
前記メディアコンテンツの前記第1の部分がキャッシュの中に存在するかどうかを判定するために、前記キャッシュにクエリを行うステップと、
前記メディアコンテンツが存在しない場合、
ブロードキャスト転送とユニキャスト転送との間でハンドオーバーが発生したと暗黙的に判定するステップとを含み、
前記ユニキャストプロトコルに従って前記メディアコンテンツの前記第1の部分を検索するステップが、前記メディアコンテンツの前記第1の部分が前記キャッシュの中に存在しないことを前記キャッシュの前記クエリが示す場合、かつ、前記ハンドオーバーが発生したという前記判定に基づいて、
前記ユニキャストプロトコルに従って、前記メディアコンテンツの前記第1の部分を検索するための、ファイルダウンロード要求を提出するステップと、
前記メディアコンテンツの前記第1の部分を前記キャッシュに記憶するステップと、
を含む、請求項1に記載の方法。

【請求項14】

前記ファイルダウンロード要求が、ハイパーテキスト転送プロトコル(HTTP)要求を含む、請求項13に記載の方法。

【請求項15】

前記メディアコンテンツの前記第1の部分が、時間的に連続して、前記メディアコンテンツの前記第2の部分の後に続き、前記メディアコンテンツの前記第2の部分を検索するステップが、
ユニキャスト転送とブロードキャスト転送との間でハンドオーバーが発生したと暗黙的に判定するステップと、
前記ハンドオーバーが発生したと判定したことに応答して、前記ファイル配信サービスに加入して、前記メディアコンテンツの前記第2の部分を検索するステップと、
前記メディアコンテンツの前記第2の部分をキャッシュに記憶するステップと、
を含む、請求項1に記載の方法。

【請求項16】

前記メディアコンテンツが複数の異なるメディアコンテンツの1つを含み、前記複数の異なるメディアコンテンツの各々がそれぞれのビデオチャンネルに対応し、前記方法が、
前記複数の異なるメディアコンテンツの前記第1の部分を検索してキャッシュするステップと、
前記複数の異なるメディアコンテンツの前記1つのユーザ選択を受け取るステップと、
前記メディアコンテンツの前記第1の部分をフェッチするための要求の後で、キャッシュヒットを介して直ちに前記第1のメディアコンテンツを再生するステップと、
をさらに含み、
前記複数の異なるメディアコンテンツの前記1つの前記第2の部分を検索するステップが、前記ユーザ選択に応答して、前記複数の異なるメディアコンテンツの前記1つの前記第2の部分を検索するステップを含む、請求項1に記載の方法。

【請求項17】

前記複数の異なるメディアコンテンツの各々の前記第1の部分からのデータを出力するステップをさらに含む、請求項16に記載の方法。

【請求項18】

前記複数の異なるメディアコンテンツの各々の前記第1の部分の各々からのビデオデータを実質的に同時に表示するステップをさらに含む、請求項17に記載の方法。

【請求項19】

前記メディアコンテンツが複数の異なるメディアコンテンツの第2のメディアコンテンツを含み、前記複数の異なるメディアコンテンツの各々がそれぞれのビデオチャンネルに対応し、前記方法が、
前記複数の異なるメディアコンテンツの第1のメディアコンテンツのデータを検索するステップと、
前記第1のメディアコンテンツの前記データを検索した後で、前記第2のメディアコンテンツに変更するための要求を受信するステップと、
をさらに含み、
前記第2のメディアコンテンツの前記第1の部分および前記第2のメディアコンテンツの前記第2の部分を検索するステップが、ユニキャストを介して前記第2のメディアコンテンツの前記第1の部分を検索し、前記第2のメディアコンテンツに変更するための前記要求に応答して、マルチキャストファイルダウンロードを介して前記第2のメディアコンテンツの前記第2の部分を検索するステップを含む、請求項1に記載の方法。

【請求項20】

前記適応ビデオストリーミングネットワークプロトコルが、HTTP(DASH)を通じた動的な適応ストリーミングを含む、請求項1に記載の方法。

【請求項21】

ビデオデータの情報を検索するためのデバイスであって、ユニキャストプロトコルに従って、第1の表現からメディアコンテンツの第1の部分を検索することであって、前記メディアコンテンツが適応ビデオストリーミングネットワークプロトコルに準拠することと、ファイル配信サービスを介してブロードキャストプロトコル又はマルチキャストプロトコルに従って第2の表現から前記メディアコンテンツの第2の部分を検索することであって、前記第1の部分および前記第2の部分が前記メディアコンテンツ中で時間的に連続しており、前記第1の部分及び第2の部分に対応する前記第１の表現のセグメントは、第1の時間長を有しており、前記第１の部分及び第2の部分に対応する前記第2の表現のセグメントは、第2の時間長を有しており、前記第2の時間長は、前記第1の時間長よりも長いこととを行うように構成された1つまたは複数のプロセッサを含む、デバイス。

【請求項22】

メモリをさらに含み、前記1つまたは複数のプロセッサがさらに、前記ファイル配信サービスに従って受信された前記メディアコンテンツの前記第2の部分のデータを、前記メモリにキャッシュするように構成される、請求項21に記載のデバイス。

【請求項23】

前記メディアコンテンツの前記第1の部分を検索するために、前記1つまたは複数のプロセッサが、前記メディアコンテンツの前記第1の部分が前記メモリに現在記憶されているかどうかを判定し、前記メディアコンテンツの前記第1の部分が前記メモリに現在記憶されていない場合、前記ユニキャストプロトコルに従って、前記メディアコンテンツの前記第1の部分を検索するように構成される、請求項22に記載のデバイス。

【請求項24】

キャッシュを実装するためのメモリをさらに含み、前記メディアコンテンツの前記第2の部分が、時間的に連続して前記メディアコンテンツの前記第1の部分の後に続き、前記メディアコンテンツの前記第1の部分を検索するために、前記1つまたは複数のプロセッサが、前記メディアコンテンツの前記第1の部分が前記キャッシュの中に存在するかどうかを判定するために前記キャッシュにクエリを行い、前記メディアコンテンツが存在しない場合、ブロードキャスト転送とユニキャスト転送との間でハンドオーバーが発生したと暗黙的に判定するように構成され、前記ユニキャストプロトコルに従って前記メディアコンテンツの前記第1の部分を検索するために、前記1つまたは複数のプロセッサが、前記メディアコンテンツの前記第1の部分が前記キャッシュの中に存在しないことを前記キャッシュの前記クエリが示す場合、かつ、前記ハンドオーバーが発生したという前記判定に基づいて、前記ユニキャストプロトコルに従って前記メディアコンテンツの前記第1の部分を検索するためのファイルダウンロード要求を提出し、前記メディアコンテンツの前記第1の部分を前記キャッシュに記憶するように構成される、請求項21に記載のデバイス。

【請求項25】

キャッシュを実装するためのメモリをさらに含み、前記メディアコンテンツの前記第1の部分が、時間的に連続して前記メディアコンテンツの前記第2の部分の後に続き、前記メディアコンテンツの前記第2の部分を検索するために、前記1つまたは複数のプロセッサが、ユニキャスト転送とブロードキャスト転送との間でハンドオーバーが発生したと暗黙的に判定し、前記ハンドオーバーが発生したと判定したことに応答して、前記ファイル配信サービスに加入して前記メディアコンテンツの前記第2の部分を検索し、前記メディアコンテンツの前記第2の部分を前記キャッシュに記憶するように構成される、請求項21に記載のデバイス。

【請求項26】

ビデオデータの情報を検索するためのデバイスであって、
ユニキャストプロトコルに従って第1の表現からメディアコンテンツの第1の部分を検索するための手段であって、前記メディアコンテンツが、適応ビデオストリーミングネットワークプロトコルに準拠する、手段と、
ファイル配信サービスを介してブロードキャストプロトコル又はマルチキャストプロトコルに従って第2の表現から前記メディアコンテンツの第2の部分を検索するための手段であって、前記第1の部分および前記第2の部分が、前記メディアコンテンツの中で時間的に連続しており、前記第1の部分及び第2の部分に対応する前記第１の表現のセグメントは、第1の時間長を有しており、前記第１の部分及び第2の部分に対応する前記第2の表現のセグメントは、第2の時間長を有しており、前記第2の時間長は、前記第1の時間長よりも長い、手段と、
を含むことを特徴とするデバイス。

【請求項27】

前記ファイル配信サービスに従って受信された前記メディアコンテンツの前記第2の部分のデータをキャッシュするための手段をさらに含む、請求項26に記載のデバイス。

【請求項28】

前記メディアコンテンツの前記第1の部分を検索するための前記手段が、
前記メディアコンテンツの前記第1の部分が現在キャッシュするための前記手段に記憶されているかどうかを判定するための手段と、
前記メディアコンテンツの前記第1の部分がキャッシュするための前記手段に現在記憶されていない場合、前記ユニキャストプロトコルに従って前記メディアコンテンツの前記第1の部分を検索するための手段と、
を含む、請求項27に記載のデバイス。

【請求項29】

前記メディアコンテンツの前記第2の部分が、時間的に連続して、前記メディアコンテンツの前記第1の部分の後に続き、前記メディアコンテンツの前記第1の部分を検索するための前記手段が、
前記メディアコンテンツの前記第1の部分がキャッシュの中に存在するかどうかを判定するために、前記キャッシュにクエリを行うための手段と、
前記メディアコンテンツが存在しない場合、ブロードキャスト転送とユニキャスト転送との間でハンドオーバーが発生したと暗黙的に判定するための手段と、
を含み、
前記ユニキャストプロトコルに従って、前記メディアコンテンツの前記第1の部分を検索するための前記手段が、
前記メディアコンテンツの前記第1の部分が前記キャッシュの中に存在しないことを前記キャッシュの前記クエリが示す場合、かつ、前記ハンドオーバーが発生したという前記判定に基づいて、前記ユニキャストプロトコルに従って前記メディアコンテンツの前記第1の部分を検索するためのファイルダウンロード要求を提出するための手段と、
前記メディアコンテンツの前記第1の部分が前記キャッシュの中に存在しないことを前記キャッシュの前記クエリが示す場合、かつ、前記ハンドオーバーが発生したという前記判定に基づいて、前記メディアコンテンツの前記第1の部分を前記キャッシュに記憶するための手段と、
を含む、請求項26に記載のデバイス。

【請求項30】

前記メディアコンテンツの前記第1の部分が、時間的に連続して、前記メディアコンテンツの前記第2の部分の後に続き、前記メディアコンテンツの前記第2の部分を検索するための前記手段が、
ユニキャスト転送とブロードキャスト転送との間でハンドオーバーが発生したと暗黙的に判定するための手段と、
前記ハンドオーバーが発生したと判定したことに応答して、前記ファイル配信サービスに加入して、前記メディアコンテンツの前記第2の部分を検索するための手段と、
前記メディアコンテンツの前記第2の部分をキャッシュに記憶するための手段と、
を含む、請求項26に記載のデバイス。

【請求項31】

実行されると、1つまたは複数のプロセッサに、
ユニキャストプロトコルに従って第1の表現からメディアコンテンツの第1の部分を検索することであって、前記メディアコンテンツが、適応ビデオストリーミングネットワークプロトコルに準拠することと、
ファイル配信サービスを介してブロードキャストプロトコル又はマルチキャストプロトコルに従って第2の表現から前記メディアコンテンツの第2の部分を検索することであって、前記第1の部分および前記第2の部分が、前記メディアコンテンツの中で時間的に連続しており、前記第1の部分及び第2の部分に対応する前記第１の表現のセグメントは、第1の時間長を有しており、前記第１の部分及び第2の部分に対応する前記第2の表現のセグメントは、第2の時間長を有しており、前記第2の時間長は、前記第1の時間長よりも長いことと、
を行わせる命令を記憶した、コンピュータ可読記憶媒体。

【請求項32】

前記1つまたは複数のプロセッサに、前記ファイル配信サービスに従って受信された前記メディアコンテンツの前記第2の部分のデータをローカルメモリへキャッシュさせる命令をさらに含む、請求項31に記載のコンピュータ可読記憶媒体。

【請求項33】

前記1つまたは複数のプロセッサに前記メディアコンテンツの前記第1の部分を検索させる前記命令が、前記1つまたは複数のプロセッサに、
前記メディアコンテンツの前記第1の部分が現在キャッシュに記憶されているかどうかを判定させ、
前記メディアコンテンツの前記第1の部分が前記キャッシュに現在記憶されていない場合、前記ユニキャストプロトコルに従って前記メディアコンテンツの前記第1の部分を検索させる命令を含む、請求項32に記載のコンピュータ可読記憶媒体。

【請求項34】

前記メディアコンテンツの前記第2の部分が、時間的に連続して、前記メディアコンテンツの前記第1の部分の後に続き、前記1つまたは複数のプロセッサに前記メディアコンテンツの前記第1の部分を検索させる前記命令が、前記1つまたは複数のプロセッサに、
前記メディアコンテンツの前記第1の部分がキャッシュの中に存在するかどうかを判定するために、前記キャッシュへクエリを行わせ、
前記メディアコンテンツが存在しない場合、ブロードキャスト転送とユニキャスト転送との間でハンドオーバーが発生したと暗黙的に判定させる命令を含み、
前記メディアコンテンツの前記第1の部分が前記キャッシュの中に存在しないことを前記キャッシュの前記クエリが示す場合、かつ、前記ハンドオーバーが発生したという前記判定に基づいて、前記1つまたは複数のプロセッサに、前記ユニキャストプロトコルに従って前記メディアコンテンツの前記第1の部分を検索させる前記命令が、前記1つまたは複数のプロセッサに、
前記ユニキャストプロトコルに従って、前記メディアコンテンツの前記第1の部分を検索するための、ファイルダウンロード要求を提出させ、
前記メディアコンテンツの前記第1の部分を前記キャッシュに記憶させる命令を含む、請求項31に記載のコンピュータ可読記憶媒体。

【請求項35】

前記メディアコンテンツの前記第1の部分が、時間的に連続して、前記メディアコンテンツの前記第2の部分の後に続き、前記1つまたは複数のプロセッサに前記メディアコンテンツの前記第2の部分を検索させる前記命令が、前記1つまたは複数のプロセッサに、
ユニキャスト転送とブロードキャスト転送との間でハンドオーバーが発生したと暗黙的に判定させ、
前記ハンドオーバーが発生したと判定したことに応答して、前記ファイル配信サービスへ加入させて、前記メディアコンテンツの前記第2の部分を検索させ、
前記メディアコンテンツの前記第2の部分をキャッシュに記憶させる命令を含む、請求項31に記載のコンピュータ可読記憶媒体。

【請求項36】

ビデオデータの情報を出力する方法であって、
適応ビデオストリーミングネットワークプロトコルに準拠するメディアコンテンツを取得するステップであって、前記メディアコンテンツは第１の表現と第２の表現とを含むステップ、
ユニキャストプロトコルに従って前記第1の表現から前記メディアコンテンツの第1の部分を出力するステップと、
ファイル配信サービスに従って前記第2の表現から前記メディアコンテンツの第2の部分を出力するステップと、
を含み、
前記第1の部分および前記第2の部分が、前記メディアコンテンツの中で時間的に連続しており、前記第1の部分及び第2の部分に対応する前記第１の表現のセグメントは、第1の時間長を有しており、前記第１の部分及び第2の部分に対応する前記第2の表現のセグメントは、第2の時間長を有しており、前記第2の時間長は、前記第1の時間長よりも長いことを特徴とする方法。

【請求項37】

前記ファイル配信サービスがFile Delivery over Unidirectional Transport(FLUTE)プロトコルを含む、請求項36に記載の方法。

【請求項38】

前記メディアコンテンツの1つまたは複数のユニキャストuniform resource locator(URL)を示すFile Delivery Table(FDT)の属性を出力するステップをさらに含む、請求項37に記載の方法。

【請求項39】

前記適応ビデオストリーミングネットワークプロトコルが、HTTP(DASH)を通じた動的な適応ストリーミングを含む、請求項36に記載の方法。

【請求項40】

クライアントデバイスから前記メディアコンテンツの前記第1の部分を求める要求を受信するステップであって、前記要求が、前記ユニキャストプロトコルに従った前記メディアコンテンツの前記第1の部分に対する要求を含む、ステップと、
前記ユニキャストプロトコルに従って前記第1の部分のデータを出力するステップと、
をさらに含む、請求項36に記載の方法。

【請求項41】

前記第1の表現が、前記第2の表現と異なる符号化特性と、前記第2の表現と異なるレンダリング特性とのうちの少なくとも1つを有する、請求項36に記載の方法。

【請求項42】

前記メディアコンテンツの前記第2の部分を出力するステップが、インターネットプロトコル(IP)マルチキャストとenhanced Multimedia Broadcast Multicast Service(eMBMS)との少なくとも1つを介して、前記ファイル配信サービスによって前記メディアコンテンツの前記第2の部分を出力するステップを含む、請求項36に記載の方法。

【請求項43】

前記ファイル配信サービスに従って1つまたは複数のキャッシングプリミティブを出力して、クライアントデバイスに、前記メディアコンテンツの前記第1の部分と前記メディアコンテンツの前記第2の部分との少なくとも1つをキャッシュさせるステップをさらに含む、請求項36に記載の方法。

【請求項44】

ネットワークセクタの中の前記ファイル配信サービスへの加入者端末の数を決定するステップと、
前記ネットワークセクタの中の前記ファイル配信サービスへの加入者端末の前記決定された数と、前記メディアコンテンツの表現のビットレートとに基づいて、前記メディアコンテンツの前記第2の表現を選択するステップとをさらに含み、
前記メディアコンテンツのデータを出力するステップが、前記選択された第2の表現のデータを出力するステップを含み、
前記方法が、前記加入者端末に、前記選択された第2の表現の前記ビットレートで、前記選択されたメディアセグメントをダウンロードさせキャッシュさせるステップをさらに含む、請求項36に記載の方法。

【請求項45】

前記ネットワークセクタの中の前記ファイル配信サービスへの加入者端末の前記数を監視するステップと、
前記メディアコンテンツの第3の表現が、前記加入者端末の数が増加した場合はより高いビットレートを、または前記加入者端末の数が減少した場合にはより低いビットレートを有するように、前記ネットワークセクタの中の前記ファイル配信サービスへの加入者端末の前記決定された数と、前記メディアコンテンツの表現のビットレートとに基づいて、前記メディアコンテンツの第3の表現を選択するステップとをさらに含む、請求項44に記載の方法。

【請求項46】

加入者の前記数に基づいて、加入者の前記数によって表される前記ネットワークセクタの中の全体のユーザに対する割合を決定するステップと、
前記ネットワークセクタに割り当てられた帯域幅の量を決定するステップと、
加入者の前記数によって表される、前記全体のユーザに対する前記割合に基づいて、前記ネットワークセクタに割り当てられる前記帯域幅の比例する量を決定するステップと、
をさらに含み、
前記第2の表現を選択するステップは、前記第2の表現が、前記ネットワークセクタに割り当てられた前記帯域幅の前記決定された比例する量が対応し得るビットレートを有する場合に、前記第2の表現を選択するステップを含む、請求項44に記載の方法。

【請求項47】

ビデオデータの情報を出力するためのデバイスであって、適応ビデオストリーミングネットワークプロトコルに準拠するメディアコンテンツを取得し、前記メディアコンテンツは第１の表現と第２の表現とを含み、ユニキャストプロトコルに従って前記第1の表現から前記メディアコンテンツの第1の部分を出力し、ファイル配信サービスに従って前記第2の表現から前記メディアコンテンツの第2の部分を出力するように構成される1つまたは複数のプロセッサを含み、第1の部分および第2の部分が前記メディアコンテンツにおいて時間的に連続しており、前記第1の部分及び第2の部分に対応する前記第１の表現のセグメントは、第1の時間長を有しており、前記第１の部分及び第2の部分に対応する前記第2の表現のセグメントは、第2の時間長を有しており、前記第2の時間長は、前記第1の時間長よりも長いことを特徴とするデバイス。

【請求項48】

前記1つまたは複数のプロセッサがさらに、前記ファイル配信サービスに従って1つまたは複数のキャッシングプリミティブを出力して、クライアントデバイスに、前記メディアコンテンツの前記第1の部分と前記メディアコンテンツの前記第2の部分との少なくとも1つをキャッシュさせるように構成される、請求項47に記載のデバイス。

【請求項49】

前記1つまたは複数のプロセッサがさらに、ネットワークセクタの中の前記ファイル配信サービスへの加入者端末の数を決定し、前記ネットワークセクタの中の前記ファイル配信サービスへの加入者端末の前記決定された数と、前記メディアコンテンツの表現のビットレートとに基づいて、前記メディアコンテンツの前記第2の表現を選択するように構成され、前記メディアコンテンツのデータを出力するために、前記1つまたは複数のプロセッサが、前記選択された第2の表現のデータを出力するように構成され、前記1つまたは複数のプロセッサがさらに、前記加入者端末に、前記選択された第2の表現の前記ビットレートで、前記選択されたメディアセグメントをダウンロードさせキャッシュさせるように構成される、請求項47に記載のデバイス。

【請求項50】

前記1つまたは複数のプロセッサが、加入者の前記数に基づいて、加入者の前記数によって表される前記ネットワークセクタ中の全体のユーザに対する割合を決定し、前記ネットワークセクタに割り当てられた帯域幅の量を決定し、加入者の前記数によって表される前記全体のユーザに対する前記割合に基づいて、前記ネットワークセクタに割り当てられた前記帯域幅の比例する量を決定するように構成され、
前記1つまたは複数のプロセッサは、前記第2の表現が、前記ネットワークセクタに割り当てられた前記帯域幅の前記決定された比例する量が対応し得るビットレートを有する場合に、前記第2の表現を選択するように構成される、請求項49に記載のデバイス。

【請求項51】

ビデオデータの情報を出力するためのデバイスであって、
適応ビデオストリーミングネットワークプロトコルに準拠するメディアコンテンツを取得するための手段であって、前記メディアコンテンツは第１の表現と第２の表現とを含む手段、と、
ユニキャストプロトコルに従って前記第1の表現から前記メディアコンテンツの第1の部分を出力するための手段と、
ファイル配信サービスに従って前記第2の表現から前記メディアコンテンツの第2の部分を出力するための手段と、
を含み、
前記第1の部分および前記第2の部分が、前記メディアコンテンツの中で時間的に連続しており、前記第1の部分及び第2の部分に対応する前記第１の表現のセグメントは、第1の時間長を有しており、前記第１の部分及び第2の部分に対応する前記第2の表現のセグメントは、第2の時間長を有しており、前記第2の時間長は、前記第1の時間長よりも長いことを特徴とするデバイス。

【請求項52】

前記ファイル配信サービスに従って1つまたは複数のキャッシングプリミティブを出力して、クライアントデバイスに、前記メディアコンテンツの前記第1の部分と前記メディアコンテンツの前記第2の部分との少なくとも1つをキャッシュさせるための手段をさらに含む、請求項51に記載のデバイス。

【請求項53】

ネットワークセクタの中の前記ファイル配信サービスへの加入者端末の数を決定するための手段と、
前記ネットワークセクタの中の前記ファイル配信サービスへの加入者端末の前記決定された数と、前記メディアコンテンツの前記第2の表現のビットレートとに基づいて、前記メディアコンテンツの表現を選択するための手段とをさらに含み、
前記メディアコンテンツのデータを出力するための手段が、前記選択された第2の表現のデータを出力するための手段を含み、前記デバイスが、
前記加入者端末に、前記選択された第2の表現の前記ビットレートで、前記選択されたメディアセグメントをダウンロードさせキャッシュさせるための手段をさらに含む、請求項51に記載のデバイス。

【請求項54】

加入者の前記数に基づいて、加入者の前記数によって表される前記ネットワークセクタの中の全体のユーザに対する割合を決定するための手段と、
前記ネットワークセクタに割り当てられた帯域幅の量を決定するための手段と、
加入者の前記数によって表される前記全体のユーザに対する前記割合に基づいて、前記ネットワークセクタに割り当てられる前記帯域幅の比例する量を決定するための手段と、
をさらに含み、
前記第2の表現を選択するための前記手段が、前記ネットワークセクタに割り当てられた前記帯域幅の前記決定された比例する量が対応し得るビットレートを有する場合に、前記第2の表現を選択するための手段を含む、請求項53に記載のデバイス。

【請求項55】

実行されると、1つまたは複数のプロセッサに、
適応ビデオストリーミングネットワークプロトコルに準拠するメディアコンテンツを取得させ、前記メディアコンテンツは第１の表現と第２の表現とを含み、
ユニキャストプロトコルに従って前記第1の表現から前記メディアコンテンツの第1の部分を出力させ、
ファイル配信サービスに従って前記第2の表現から前記メディアコンテンツの第2の部分を出力させる命令を記憶した、コンピュータ可読記憶媒体であって、前記第1の部分および前記第2の部分が前記メディアコンテンツにおいて時間的に連続しており、前記第1の部分及び第2の部分に対応する前記第１の表現のセグメントは、第1の時間長を有しており、前記第１の部分及び第2の部分に対応する前記第2の表現のセグメントは、第2の時間長を有しており、前記第2の時間長は、前記第1の時間長よりも長いことを特徴とするコンピュータ可読記憶媒体。

【請求項56】

前記1つまたは複数のプロセッサに、前記ファイル配信サービスに従って1つまたは複数のキャッシングプリミティブを出力させて、クライアントデバイスに、前記メディアコンテンツの前記第1の部分と前記メディアコンテンツの前記第2の部分との少なくとも1つをキャッシュさせる命令をさらに含む、請求項55に記載のコンピュータ可読記憶媒体。

【請求項57】

前記1つまたは複数のプロセッサに、
ネットワークセクタの中の前記ファイル配信サービスへの加入者端末の数を決定させ、
前記ネットワークセクタの中の前記ファイル配信サービスへの加入者端末の前記決定された数と、前記メディアコンテンツの表現のビットレートとに基づいて、前記メディアコンテンツの前記第2の表現を選択させる命令をさらに含み、
前記1つまたは複数のプロセッサに前記メディアコンテンツのデータを出力させる前記命令が、前記1つまたは複数のプロセッサに、前記選択された第2の表現のデータを出力させる命令を含み、前記コンピュータ可読記憶媒体が、
前記加入者端末に、前記選択された第2の表現の前記ビットレートで、前記選択されたメディアセグメントをダウンロードさせキャッシュさせることを、前記1つまたは複数のプロセッサに行わせる命令をさらに含む、請求項55に記載のコンピュータ可読記憶媒体。

【請求項58】

前記1つまたは複数のプロセッサに、
加入者の前記数に基づいて、加入者の前記数によって表される前記ネットワークセクタの中の全体のユーザに対する割合を決定させ、
前記ネットワークセクタに割り当てられる帯域幅の量を決定させ、
加入者の前記数によって表される前記全体のユーザに対する前記割合に基づいて、前記ネットワークセクタに割り当てられる前記帯域幅の比例する量を決定させる命令をさらに含み、
前記1つまたは複数のプロセッサに前記第2の表現を選択させる前記命令が、前記1つまたは複数のプロセッサに、前記ネットワークセクタに割り当てられる前記帯域幅の前記決定された比例する量が対応し得るビットレートを有する場合に、前記第2の表現を選択させる命令を含む、請求項57に記載のコンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、符号化されたビデオデータの転送に関する。

【0002】

本出願は、全体が参照によって本明細書に組み込まれる、2011年4月5日に出願された米国仮特許出願第61/472,116号の利益を主張する。

【背景技術】

【0003】

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

【0004】

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

【0005】

2000年代の半ば、インターネットリアルタイム転送プロトコル(RTP)を介したビデオおよびオーディオのトラフィックの増大によって、大量のネットワークトラフィックがインターネットに流れ込み始め、これらのプロトコルに対する輻輳制御は存在しなかった。このことで、企業の情報技術(IT)管理者は、企業においてゲートウェイを詰まらせていたビデオストリームおよびオーディオストリームを含むRTPパケットを遮断するように、ファイヤウォールをプログラムするようになった。

【0006】

ファイヤウォールは、ビデオおよびオーディオのストリーミングサービスの存在を脅かした。したがって、サービス提供者は、TCP(より具体的には、TCPのHTTPポート)仮想回路を通じてコンテンツを提供し始めた。サービス提供者は、自身のビデオおよびオーディオのトラフィックを、有用なHTTPトラフィックであるかのように偽装するために、これを行った。ITファイヤウォールの管理者は、HTTP/TCPを介したビデオおよびオーディオを簡単には遮断できなかったので、しばらくは、TCP上のHTTPを介したビデオおよびオーディオが普及した。

【0007】

最初は、「プログレッシブダウンロード」方式が、大半のビデオのダウンロードに使用された。この機構では、単一のHTTP接続および転送が、ビデオファイル全体をダウンロードするために使用される。ユーザはダウンロードが行われるのを見て、ストリーミング視聴の体験の全体をサポートするのに十分なデータがバッファリングされると、再生者とユーザのいずれかが「再生」を押して、ビデオ再生が開始する。しかしながら、この方法は、特に小容量のリンクでユーザがビデオをすぐに見るのを望む場合、問題があった。別の問題は、変化しているワイヤレス環境では、適応的なダウンロードが突然非常に低速な状態へと切り替わることがあり、ビデオの途中での停止を引き起こすということであった。

【0008】

これらの問題に対処することを試みる、HTTPを通じたアダプティブストリーミングを実装するための研究が進行中である。アダプティブストリーミングプロトコルの例には、Microsoft Smooth Streaming(MSS)、Apple HTTP Live Streaming(HLS)、Adobe HTTP Dynamic Streaming(AHDS)、および3GPP規格であるDynamic Adaptive Streaming over HTTP(DASH)がある。2011年には、Netflixによるビデオストリーミングサービス(MSSに基づく)が、ピーク時の夕方において、北米のインターネットバックホールの30%を消費し、顧客の自宅にビデオパケットを配信していた。

【0009】

アダプティブストリーミング方式は一般に、HTMLウェブページとよく似た方法でビデオデータを編成する。たとえば、DASHでは、「ビデオウェブページ」が、ビデオデータに対応する「フラグメント」(サブファイル)のすべてを参照するように定義される。フラグメントは通常、2秒のリアルタイムのビデオまたはオーディオであり、ビデオの場合は通常、MPEG Iのフレーム(基本的には完全にJPEGで符号化されたピクチャ)で開始する。DASHでは、「ビデオウェブページ」は、「Media Presentation Description」(MPD)と呼ばれる。2時間のビデオのMPDは、3600個のビデオのuniform resource locator(URL)と、3600個のオーディオのURLとを参照し、これらの各々が、再生される時のメディアの2秒に対応し得る。また、3600個のビデオのURLは、ビデオが符号化される各ビットレートに対して提供され得ることに留意されたい。

【0010】

DASHの1つの改善は、同じビデオをいくつかの異なるビットレートで表現することができ、再生者がビットレートを切り替えられる(たとえば、2秒ごとに)ということである。MPDは一般に、表現と呼ばれる、同じビデオの3〜8個の異なるレンダリングを表す。インターネットが混雑している場合、または最初の起動の間、または端末が小容量のリンク上にある場合、低ビットレートのフラグメントがフェッチされ得る。インターネットが混雑しておらず、端末が大容量のリンクを有する場合、高ビットレートのフラグメントがフェッチされ得る。

【先行技術文献】

【特許文献】

【0011】

【特許文献1】米国特許出願第13/206,418号

【非特許文献】

【0012】

【非特許文献1】Roca、「FCAST: Scalable Object Delivery for the ALC and NORM protocols」、IETF RMT Working Group、2011年10月

【非特許文献2】Luby他、「Asynchronous Layered Coding(ALC) Protocol Instantiation」、RFC5775、2010年4月

【非特許文献3】Luby他、「Layered Coding Transport(LCT) Building Block」、RFC5651、2009年10月

【非特許文献4】R. Fielding他、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、Network Working Group、IETF、1999年6月

【非特許文献5】Cain他、「Internet Group Management Protocol, Version 3」、Internet Engineering Task Force、Network Working Group、RFC3376、2002年12月

【非特許文献6】Vida他、「Multicast Listener Discovery Version 2(MLDv2) for IPv6」、Internet Engineering Task Force、Network Working Group、RFC2710、1999年10月

【非特許文献7】Holbrook他、「Using Internet Group Management Protocol Version 3(IGMPv3) and Multicast Listener Discovery Protocol Version 2(MLDv2) for Source-Specific Multicast」、Internet Engineering Task Force、Network Working Group、RFC4604、2006年8月

【発明の概要】

【課題を解決するための手段】

【0013】

一般に、本開示は、ファイル配信サービスに従ってネットワークを通じてビデオデータをストリーミングするための技法を説明する。ビデオデータは、dynamic adaptive streaming over HTTP(DASH)に従ってフォーマットされ得る。つまり、メディアコンテンツは、メディアコンテンツの1つまたは複数の表現の特性を表すmedia presentation description(MPD)のような、マニフェストファイルを含み得る。しかしながら、メディアコンテンツのデータに対する要求を待機する代わりに、本開示の技法は、データがファイル配信プロトコルを通じて1つまたは複数のクライアントデバイスにブロードキャストされる(またはマルチキャストされる)ことを可能にする。たとえば、データは、File Delivery over Unidirectional Transport(FLUTE)プロトコルを使用してブロードキャスト(またはマルチキャスト)され得る。いくつかの例では、クライアントデバイスは、ブロードキャストされているデータにおいて切替ポイント(つまり、ランダムアクセスポイント)が受信されるまで、ユニキャストプロトコルを使用してメディアデータの一部を検索することができる。DASHとFLUTEのようなファイル配信サービスとの技法をこのように使用することで、ブロードキャストプロトコルまたはマルチキャストプロトコルを通じたビデオデータのリアルタイムストリーミングを改善することができる。

【0014】

一例では、方法は、ユニキャストプロトコルに従ってメディアコンテンツの第1の部分を検索するステップであって、メディアコンテンツがアダプティブビデオストリーミングネットワークプロトコルに準拠する、ステップと、ファイル配信サービスを介してマルチキャストプロトコルに従ってメディアコンテンツの第2の部分を検索するステップであって、第1の部分および第2の部分がメディアコンテンツ中で時間的に連続している、ステップとを含む。

【0015】

別の例では、デバイスは、ユニキャストプロトコルに従って、メディアコンテンツの第1の部分を検索することであって、メディアコンテンツがアダプティブビデオストリーミングネットワークプロトコルに準拠することと、ファイル配信サービスを介してマルチキャストプロトコルに従ってメディアコンテンツの第2の部分を検索することであって、第1の部分および第2の部分がメディアコンテンツ中で時間的に連続していることとを行うように構成される1つまたは複数のプロセッサを含む。

【0016】

別の例では、デバイスは、ユニキャストプロトコルに従ってメディアコンテンツの第1の部分を検索するための手段であって、メディアコンテンツがアダプティブビデオストリーミングネットワークプロトコルに準拠する、手段と、ファイル配信サービスを介してマルチキャストプロトコルに従ってメディアコンテンツの第2の部分を検索するための手段であって、第1の部分および第2の部分がメディアコンテンツ中で時間的に連続している、手段とを含む。

【0017】

別の例では、コンピュータ可読記憶媒体は、実行されると、1つまたは複数のプロセッサに、ユニキャストプロトコルに従ってメディアコンテンツの第1の部分を検索することであって、メディアコンテンツがアダプティブビデオストリーミングネットワークプロトコルに準拠することと、ファイル配信サービスを介してマルチキャストプロトコルに従ってメディアコンテンツの第2の部分を検索することであって、第1の部分および第2の部分がメディアコンテンツ中で時間的に連続していることとを行わせる命令を記憶している。

【0018】

別の例では、方法は、アダプティブビデオストリーミングネットワークプロトコルに準拠するメディアコンテンツを取得するステップと、ユニキャストプロトコルに従ってメディアコンテンツの第1の部分を出力するステップと、ファイル配信サービスに従ってメディアコンテンツの第2の部分を出力するステップとを含み、第1の部分および第2の部分がメディアコンテンツにおいて時間的に連続している。

【0019】

別の例では、デバイスは、アダプティブビデオストリーミングネットワークプロトコルに準拠するメディアコンテンツを取得し、ユニキャストプロトコルに従ってメディアコンテンツの第1の部分を出力し、ファイル配信サービスに従ってメディアコンテンツの第2の部分を出力するように構成される1つまたは複数のプロセッサを含み、第1の部分および第2の部分がメディアコンテンツにおいて時間的に連続している。

【0020】

別の例では、デバイスは、アダプティブビデオストリーミングネットワークプロトコルに準拠するメディアコンテンツを取得するための手段と、ユニキャストプロトコルに従ってメディアコンテンツの第1の部分を出力するための手段と、ファイル配信サービスに従ってメディアコンテンツの第2の部分を出力するための手段とを含み、第1の部分および第2の部分がメディアコンテンツにおいて時間的に連続している。

【0021】

別の例では、コンピュータ可読記憶媒体は、実行されると、1つまたは複数のプロセッサに、アダプティブビデオストリーミングネットワークプロトコルに準拠するメディアコンテンツを取得させ、ユニキャストプロトコルに従ってメディアコンテンツの第1の部分を出力させ、ファイル配信サービスに従ってメディアコンテンツの第2の部分を出力させる命令を記憶しており、第1の部分および第2の部分がメディアコンテンツにおいて時間的に連続している。

【0022】

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

【図面の簡単な説明】

【0023】

【図1】ネットワークを通じてメディアデータをストリーミングするための技法を実施する、ある例示的なシステムを示すブロック図である。

【図2】図1のネットワークの一部を形成するデバイスのある例示的なセットを示すブロック図である。

【図3】2つのサーバデバイスがクライアントデバイスにメディアコンテンツのデータを提供するある例を示すブロック図である。

【図4】例示的なメディアコンテンツの要素を示す概念図である。

【図5】メディアコンテンツの表現のセグメントに対応し得る、ある例示的なビデオファイルの要素を示すブロック図である。

【図6】2つの表現を含む、例示的なメディアコンテンツを示す概念図である。

【図7】ユニキャストおよびマルチキャストのためのネットワークスタックの例を示すブロック図である。

【図8】別の例示的なクライアントデバイスを示すブロック図である。

【図9】本開示の技法による、ユニキャスト、ブロードキャストまたはマルチキャストのいずれかを通じてメディアデータを受信するための例示的な方法を示すフローチャートである。

【図10】ファイル配信サービスを使用してメディアコンテンツを出力するための例示的な方法を示すフローチャートである。

【発明を実施するための形態】

【0024】

一般に、本開示は、ネットワークを通じた、オーディオデータおよびビデオデータのようなマルチメディアデータのストリーミングに関する技法を説明する。本開示の技法は、dynamic adaptive streaming over HTTP(DASH)に関連して使用され得る。以下でより詳しく論じられるように、本開示の技法のある例は、File Delivery over Unidirectional Transport(FLUTE)プロトコルのようなファイル配信サービスを通じて、マルチキャストプロトコルまたはブロードキャストプロトコルを使用して、DASHに従ってカプセル化されたビデオデータをストリーミングするステップを含む。FLUTEは、信頼性のある転送を実現するasynchronous layered coding(ALC)プロトコルを基礎とするので、FLUTEはFLUTE/ALCとも呼ばれ得る。本開示は、ネットワークストリーミングに関連して実行され得る様々な技法を説明して、それらの技法のいずれかまたはすべては、単独で、または任意の様々な組合せで実施され得る。以下でより詳しく説明されるように、ネットワークストリーミングを実行する様々なデバイスは、本開示の技法を実施するように構成され得る。

【0025】

本開示で説明されるようなFLUTEの代わりに使用され得る追加のファイル配信プロトコルには、FCASTおよび生のALC/LCT(たとえば、ファイルタイプ、符号化、および圧縮の属性のようなファイル属性を配信するためにALCおよびLCTヘッダを使用する)がある。FCASTは、Roca、「FCAST: Scalable Object Delivery for the ALC and NORM protocols」、IETF RMT Working Group、2011年10月において説明されている。ALCは、Luby他、「Asynchronous Layered Coding(ALC)Protocol Instantiation」、RFC 5775、2010年4月において説明されている。LCTは、Luby他、「Layered Coding Transport(LCT)Building Block」、RFC 5651、2009年10月において説明されている。大規模なファイルブロードキャストのダウンロードのための他のプロトコルは、MAC層においてファイルをブロードキャストするIEEE 802.1E System Load Protocolを含む。System Load Protocolは、2011年8月9日に出願された、Luby他、「BROADCAST MULTIMEDIA STORAGE AND ACCESS USING PAGE MAPS WHEN ASYMMETRIC MEMORY IS USED」、米国特許出願第13/206,418号において説明されている。

【0026】

IPに基づくモバイルブロードキャストTVシステム(DVB-H、ATSC-M/H、3GPP MBMS(マルチメディアブロードキャストマルチキャストサービス)、3GPP2 BCMCS(ブロードキャストおよびマルチキャストサービス)のような)において、ストリーミングサービスおよびファイル配信サービス(それぞれ、リアルタイム(RT)サービスおよびノンリアルタイム(NRT)サービスとも呼ばれることがある)は、異なる転送プロトコルを使用して配信される。ストリーミングサービスの配信はRTP(RFC3550に従う)を利用する一方、ファイル配信サービス(いくつかのシステムではダウンロード配信サービスとも呼ばれる)はFLUTE/ALC(それぞれ、RFC3926およびRFC5775に従う)を含む。ユニキャストに基づくアダプティブHTTPストリーミングサービスが、現在、インターネットにおけるビデオ配信のための支配的な技術であり、DASH(Dynamic Adaptive Streaming over HTTP)と一般に呼ばれる3GPP[TS 26.247]およびMPEG[ISO/IEC FCD23001-6]において標準化されている。

【0027】

しかしながら、本開示の技法は、LTE技術に基づくenhanced Multimedia Broadcast Multicast Service(eMBMS)のような新興のモバイルブロードキャストシステムに対していくつかの利点を提供することができる。具体的には、本開示の技法によれば、ネットワークを通じたビデオデータのストリーミング配信が、FLUTEのようなファイル配信サービスを通じて実行され得るので、別個のストリーミングおよびファイル配信の機構を展開する必要がない。ストリーミングサービスのブロードキャスト配信からユニキャスト配信へのシームレスなサービスの継続性を維持することは、モバイル事業者にとって重要な能力である。このために、特にHTTPストリーミングおよび関連するエコシステムの使用が広がり伸びている状況では、ユニキャストストリーミングをサポートするためにRTPを利用する必要がないことが非常に望ましい。このエコシステムは、HTTPストリーミング配信をサポートするコンテンツ提供者と、コンテンツ配信ネットワーク(CDN)ならびにエッジサーバおよびキャッシュのような関連するHTTP配信インフラストラクチャと、HTTPストリーミング技術ベンダーとを含む。

【0028】

したがって、いくつかの例では、本開示は、ブロードキャストストリーミング配信のためにFLUTEプロトコルのようなファイル配信サービスを利用することに取って代わる技法を提供する。ファイル配信サービスは、eMBMSのようなブロードキャスト媒体アクセス制御(MAC)プロトコル、またはIPマルチキャストのようなマルチキャストプロトコルを通じて動作することができる。これによって、これらの技法がストリーミングコンテンツとファイルコンテンツの両方を搬送するための単一のアプリケーション転送プロトコル(たとえば、FLUTE)を利用できるという点で、ネットワーク側とユーザデバイス側の両方で簡易性を向上させることができる。さらに、FLUTE/ALCパケットにおいてストリーミングコンテンツを搬送するための連続的なメディア「ファイル」構造としてDASHを利用することによって、ブロードキャスト配信からユニキャスト配信へのサービスの継続性には、単に、FLUTE/ブロードキャストを通じたDASHセグメントの転送からHTTP/ユニキャストを通じたDASHセグメントの転送への切り替えが伴う。その結果、3GPPのPSS(パケット交換ストリーミングサービス)(TS26.234で説明される)のような、RTPに基づくユニキャストストリーミング手法がもはや不要となり、サービス提供者/ネットワーク事業者が、メディアコンテンツのユニキャスト配信のために、HTTPストリーミングの生まれつつある人気を利用することが可能になる。

【0029】

具体的には、FLUTEプロトコルのようなファイル配信サービスを通じてビデオデータをストリーミングするために、クライアントデバイスは、ファイル配信サービスを介して受信されたデータによってキャッシュを事前に満たすことができる。以下でより詳しく説明されるように、クライアントデバイスは、ユニキャストを介してデータを要求する前に、要求されたデータがローカルメモリに存在するかどうかを判定するように構成され得る。ユニキャストを介してデータを受信した後にのみキャッシュを満たすのではなく、本開示の技法は、FLUTEプロトコルのようなファイル配信サービスに従ってブロードキャストまたはマルチキャストを介してデータを受信するステップと、ブロードキャストまたはマルチキャストを介して受信されたデータによってキャッシュを事前に満たすステップとを含む。このようにして、クライアントデバイスは、ユニキャストを介してデータを受信する必要なく、データがキャッシュされたと判定することができる。これによって、適切なキャッシュ管理ソフトウェアを使えば、ブロードキャスト送信とユニキャスト送信との、およびユニキャスト送信とブロードキャスト送信との、シームレスなハンドオーバーが可能になる。この簡略化されたハンドオフ技法は、これまでのいずれの過去のストリーミングプロトコルでも実現されていない。

【0030】

本開示はさらに、いくつかの例では、本来であれば重大な再生の遅延を招き得る、名目的なApplication Level FECプロセスが原因でブロードキャストストリーミングサービスのFLUTE配信を使用した時に、起動およびチャンネル変更の回数を減らすための技法を提供する。さらに、いくつかの例では、クライアントデバイスがFLASHメモリのような適切な量の安価な不揮発性ローカル記憶装置を含むと仮定すると、本開示は、たとえば、同じコンテンツがユニキャスト配信を使用したフェッチを望まれる場合のような、可能性のある今後の使用のために、ダウンロードされたメディアコンテンツをキャッシュするための技法を提供する。

【0031】

本開示は、あらゆる組合せで使用され得る、様々な技法を説明する。一例として、本開示は、ブロードキャストコンテンツ配信を簡略化するための技法を説明する。これらの技法では、FLUTEプロトコルは、ストリーミングメディアコンテンツを配信するために使用され得る。メディアコンテンツは、ISOベースメディアファイルフォーマット(ISO/IEC14496-12に従った)で、特にDASHセグメント(たとえば、TS27.247に従った)の形式で名目上カプセル化され、DASH Media Presentation Description(MPD)によって与えられる関連するマニフェスト情報を伴うと想定される。正確なメディアストリームの再生を確実にするための時間的な動作は、MPDに含まれる実時間インジケータとともに、DASHセグメントフォーマット内に含まれるメタデータによって提供され得る。これらは組み合わされて、RTPの追加のパケットカプセル化処理を必要とすることなく、RTPと同様の機能(RTCP Sender Reportsを介した、シーケンス番号、タイムスタンプ、および実際の実時間)を提供する。ストリーミングメディアコンテンツを搬送するために、RTPの使用をFLUTEによって置き換えることを示す、プロトコルモデル図が図7に示され、これは以下でより詳しく説明される。

【0032】

別の例として、本開示は、ユニキャストHTTPストリーミングの一時的な使用を利用して再生の遅延を低減するための技法を説明する。ユニキャストHTTPストリーミングは、起動(選択されたコンテンツに対する初期の「チャンネル合わせ」)の間、さらにはチャンネルの変更(「ザッピング」としても知られている)の間、エンドユーザが受ける再生の遅延を低減するために、FLUTEブロードキャストの代わりに一時的に使用され得る。これらの技法は、ユーザ体験と全体的なサービス品質との向上のために、サービス提供者およびエンドユーザにとって重要であり得る。たとえば、比較的長い20〜30秒の端末間の遅延(生の事象の実際の開始時間から、それがユーザデバイスの画面に提示されるまでの期間として定義される)は、サービス提供者には許容可能であると想定される。そのような遅延は、Raptor符号(RFC5053に従った)のような、Application Level FEC(AL FEC)の効果的な動作のために所望される時間ダイバーシティを可能にする。

【0033】

名目的なブロードキャスト配信では、いくつかの例は、(SegType10sの)10秒の長さのDASHセグメントがブロードキャスト/FLUTEを通じて配信されると想定する。起動の間、つまり、ユーザが視聴のために所望の生番組を(クライアントデバイスを使用して)選択する(場合によっては、電子サービスガイドに含まれるサービス告知情報を使用して)時、ブロードキャストDASHセグメントを直接配信すると、コンテンツがFEC復号され画面に再生され得るまでに、約10秒強の遅延が発生するであろう。起動遅延を低減するために、クライアントデバイスは、ユニキャストHTTPストリーミングモードで動作でき、これによってDASHセグメントは、本開示の技法のいくつかの例によれば、1〜2秒の長さのオーダーへと、比較的短くなる。

【0034】

1秒の長さのDASHセグメント(これらをSegType1sと呼ぶ)が、プログラム起動の間にユニキャスト/HTTPを通じて配信されると仮定すると、ユーザがプログラムを選択する時、クライアントデバイスはまず、ユニキャストHTTPストリーミングモードで動作し、ユニキャストを介してSegType1sの最初の10セグメントをフェッチし、それらをレンダリングのためにメディアプレーヤに配信する。その間、FLUTEクライアント(クライアントデバイス上でも実行される)は、第2のSegType10s(第1のSegType10sではない、なぜならそれはユニキャスト配信によってサービスされているので)をダウンロードする。クライアントデバイスは次いで、ユニキャスト受信からブロードキャスト受信に切り替えることができ、続いて再生が第10のSegType1sと第2のSegType10sとの間に行われ、その間生の事象の名目的なブロードキャストが継続し、ユニキャストHTTPストリーミングが非アクティブ化され得る。これらの技法の例が、以下の図6に関してより詳しく説明される。

【0035】

チャンネル変更をユーザが実行したことに応答して、同様の動作(安定状態のブロードキャスト動作に対する最初のユニキャスト)が、クライアントデバイスによって実行され得る。言い換えると、チャンネル変更の間に選択されたターゲットチャンネルのユニキャストHTTPストリーミング配信を利用することによって、10秒のオーダーから1秒のオーダーへと、「ザッピング」遅延が低減され得る。以下でより詳しく説明される図10は、本開示の技法による、最初のチャンネル合わせおよび/またはチャンネル変更動作を実行するための例示的な方法を説明する。

【0036】

別の例として、本開示は、クライアントデバイスによって、ブロードキャストされたストリーミングを介して受信されたデータをキャッシュするための技法を説明する。FLUTEブロードキャストコンテンツがクライアントデバイスによって受信されるに従って、クライアントデバイスはコンテンツを継続的に配信し、フラッシュに基づく不揮発性メモリ(NVM)に単一のデータファイルとしてコンテンツを書き込むことができるので、受信されたデータの大きなブロックを、各書き込みの間にデータファイル内の連続する位置に書き込むことができ、フラッシュNVMの各ページが単一のサブブロックと関連付けられるデータを格納するような方式で、データが書き込まれる。さらに、以下でより詳しく説明される図8は、キャッシュされたコンテンツが、HTTPストリーミング配信を使用したエンドユーザによるアクセスのために後で選択されれば、検索され、復号され、HTTPストリーミングクライアントに提供されて、ユニキャストネットワークを介した不必要なコンテンツの取得が回避され得ることを示す。フラッシュメモリからのデータの記憶および検索の詳細は、2011年8月9日に出願された、Luby他、「BROADCAST MULTIMEDIA STORAGE AND ACCESS USING PAGE MAPS WHEN ASYMMETRIC MEMORY IS USED」、米国特許出願第13/206,418号で説明されている。

【0037】

本開示の技法は、いくつかの例では、1つまたは複数の利点を提供することができる。たとえば、これらの技法は、サーバデバイスおよびクライアントデバイスが、より少数の配信方法にしか対応しないことを許可し得る。つまり、サーバデバイスおよびクライアントデバイスは、ファイル配信のためのFLUTEプロトコルとストリーミング配信のためのRTPの両方を実装するのではなく、FLUTEプロトコルのみに従ってビデオデータを配信するように構成され得る。さらに、これらの技法は、ブロードキャスト配信からユニキャスト配信へのサービス継続性またはハンドオフをサポートするための、RTPに基づくユニキャストストリーミング実装の使用をなくすことを可能にし得る。たとえば、3GPP MBMSは、PSSの使用を定義し、ユニキャスト上でMBMSストリーミングサービス配信をサポートする。たとえば、Over-the-Topビデオ配信のためにインターネットにおいて、ユニキャストが望まれる時、RTPは、ユニキャストHTTPストリーミングによって全体が置き換えられ得る。この場合、ハンドオフは、ブラウザがビデオセグメントを要求する時に、ブラウザ自体によって達成され(そして、FLUTEまたはブロードキャストダウンロードプロトコルは、キャッシュをもはや満たすことができない)、これによって「キャッシュ喪失」が発生し、喪失したビデオセグメントをフェッチするためにHTTPが呼び出される。

【0038】

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

【0039】

いくつかの例では、コンテンツ準備デバイスは、表現のセットが共通の特性のセットを有することを示すことができる。コンテンツ準備デバイスは次いで、セット中の表現が適応セットを形成することを示すことができるので、適応セット中の表現は、帯域幅の適応に使用され得る。つまり、セット中の表現は、ビットレートが異なり得るが、それ以外は、実質的に同じ特性を共有し得る。このようにして、クライアントデバイスは、マルチメディアコンテンツの適応セットの共通の特性の様々なセットを決定し、クライアントデバイスの符号化能力およびレンダリング能力に基づいて、適応セットを選択することができる。
次いで、クライアントデバイスは、帯域幅の利用可能性に基づいて、選択された適応セット中の複数の表現を適応的に切り替えることができる。あるいは、本開示の技法に従って、クライアントデバイスは、ユニキャストの間に表現の1つからのデータを要求し、次いでブロードキャストのために異なる表現に切り替えることができる。

【0040】

その上、ブロードキャストを提供するサーバデバイスは、ネットワークにおける帯域幅の利用可能性の変化に応答して複数の表現を切り替えることによって、サーバ側の帯域幅の適応を実行することができる。たとえば、サーバデバイスは、メディアコンテンツのブロードキャストまたはマルチキャストを受信している視聴者の数を示す情報を受信することができる。eMBMSのような一部のブロードキャストシステムは、ブロードキャストの各表現の視聴者の数を数えるためのシグナリングを有する。視聴者の数が増えるに従って、サーバデバイスは、(セクタ中のユーザがより少ないので、セクタ中で他の活動を行う可能性の高い)より多くの帯域幅がそのビデオの専用とされ得るほど多くの視聴者がコンテンツを見ていると、判定することができる。この場合、サービス提供者は、非常に人気のあるメディアブロードキャストの多くの視聴者に対してより多くの満足を与えるために、ビデオ品質を高めることができる。同様に、多くの人々がメディアブロードキャストの視聴を停止したとブロードキャストシステムが判定すると、システムは、そのセクタ中のユニキャストユーザにより多くの満足を与えるために、ビデオ品質およびビットレートを低くすることができる。

【0041】

表現のためのデータは、個々のファイルに分割され得る。ファイルの各々は、特定のuniform resource locator(URL)またはuniform resource identifier(URI)によってアドレス指定可能であり得る。クライアントデバイスは、特定のURLにあるファイルを求めるHTTP GET要求を提出して、ユニキャストを使用してファイルを検索することができる。
あるいは、または加えて、クライアントデバイスは、対応するブロードキャストまたはマルチキャストのデータを検索するために、ブロードキャストネットワークグループまたはマルチキャストネットワークグループに加入することができる。たとえば、クライアントデバイスは、HTTP GET要求を使用して1つの表現からの一連のファイルを要求し、ユニキャストの検索を実行することができるが、同時に、または続いて、ブロードキャストグループまたはマルチキャストグループに加入して、様々な表現からのファイルを検索する。クライアントデバイスは、メディアデータのシームレスな再生を可能にするために、ブロードキャストまたはマルチキャストの一時的な位置と連続しているがそれよりも前の、一時的な位置に対応するファイルを、ユニキャストを使用して検索することができる。つまり、クライアントデバイスは、再生中に、ユニキャストデータからブロードキャストデータまたはマルチキャストデータにシームレスに切り替えることができる。

【0042】

メディアコンテンツの表現のセグメントのようなビデオファイルは、ISOベースメディアファイルフォーマット、Scalable Video Coding(SVC)ファイルフォーマット、Advanced Video Coding(AVC)ファイルフォーマット、Third Generation Partnership Project(3GPP)ファイルフォーマット、および/またはMultiview Video Coding(MVC)ファイルフォーマット、または他の同様のビデオファイルフォーマットのうちのいずれかに従ってカプセル化されたビデオデータに、準拠し得る。説明および例示の目的で、ISOベースメディアファイルフォーマットが以下で説明されるが、他のフォーマットに準拠するファイルも、本開示の技法を実行するために使用され得ることを理解されたい。

【0043】

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

【0044】

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

【0045】

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

【0046】

HTTPストリーミングでは、メディア表現は、クライアントにアクセス可能なデータの構造化された集合体であり得る。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示することができる。HTTPを使用したユニキャストストリーミング配信において、頻繁に使用される動作には、GETおよび部分GETがある。GET動作は、所与のuniform resource locator(URL)と関連付けられるファイル全体を検索する。部分GET動作は、入力パラメータとしてバイト範囲を含み、ファイルのうちの、規定されたバイト範囲に対応する連続した数のバイトを検索する。したがって、部分GET動作は、1つまたは複数の個々の動画フラグメントを検索できるので、動画フラグメントはHTTPストリーミングのために提供され得る。動画フラグメントにおいて、異なるトラックのいくつかのトラックフラグメントが存在し得ることに留意されたい。

【0047】

DASHの例では、マルチメディアコンテンツ(メディアコンテンツとも呼ばれる)のビデオデータおよび/またはオーディオデータの複数の表現が存在し得る。そのような表現のマニフェストは、Media Presentation Description(MPD)データ構造において定義される。メディア提示は、HTTPストリーミングクライアントデバイスにアクセス可能なデータの構造化された集合体に相当し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。MPDデータ構造は、メディアコンテンツの各表現の符号化およびレンダリングの特性を表す。加えて、本開示の技法によれば、サーバデバイスは、ブロードキャストまたはマルチキャストの特性を表すデータを提供して、たとえば、クライアントデバイスがブロードキャストまたはマルチキャストを受信するのに十分な情報を提供することができる。たとえば、データは、クライアントデバイスがマルチキャストに加わるために使用できる、マルチキャストアドレスを含み得る。

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

本開示の技法のいずれかまたはすべてが、種々の状況で使用され得る。たとえば、ユニキャストからマルチキャストまたはブロードキャストへと切り替えるための技法は、たとえば、ビデオストリーミングを最初に開始した時、または、チャンネル変更に応答して、ブロードキャストまたはマルチキャスト中の後続の切替ポイント(またはIDRピクチャ)に「追いつく」ために使用され得る。これらの技法は、種々のチャンネルが利用可能である時にも使用され得る。たとえば、クライアントデバイスは、ユニキャストを介した複数の異なるメディアコンテンツの最初の数秒に対応するデータを検索することができる。次いで、複数のメディアコンテンツの1つをユーザが選択した後、クライアントデバイスは、メディアコンテンツのブロードキャストまたはマルチキャストに加入することができ、一方選択されたメディアコンテンツの表示データは、ユニキャストを介して受信される。
いくつかの例では、クライアントデバイスは、複数のメディアコンテンツの各々の検索されたユニキャストデータに対応する、複数のメディアコンテンツの各々のビデオクリップを有するメニューを提示して、ユーザのためにビデオに基づく選択メニューを提供することができる。

【0053】

別の例として、これらの技法は、ネットワークバックホールの基地局間のハンドオーバーまたはハンドオフの間に適用され得る。いくつかの基地局はマルチキャストまたはブロードキャストを提供できるが、他の基地局はユニキャストしか提供できない。本開示の技法によれば、クライアントデバイスは、基地局の間でハンドオーバーまたはハンドオフが発生した、または発生しそうであると判定することができ、この判定に応答して、ブロードキャストとユニキャストをシームレスに切り替えることができる。たとえば、ブロードキャスト転送またはマルチキャスト転送を提供する基地局から、ユニキャスト転送しか提供しない基地局へと切り替える時、クライアントデバイスは、メディアコンテンツのユニキャストストリーミングを開始することができる。別の例として、ユニキャスト転送しか提供しない基地局からブロードキャスト転送またはマルチキャスト転送を提供する基地局へと切り替える時、クライアントデバイスはそれに従って、ブロードキャストまたはマルチキャストを介したメディアデータの受信を開始することができる。

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

図1の例では、サーバデバイス60は、各々がそれぞれのマニフェストファイル66および1つまたは複数の表現68A〜68N(表現68)を含む様々なマルチメディアコンテンツ64を記憶する、記憶媒体62を含む。本開示の技法によれば、マニフェストファイル66の一部は、別個の位置、たとえば、記憶媒体62または別の記憶媒体の位置、場合によってはプロキシデバイスのようなネットワーク74の別のデバイスの位置に記憶され得る。

【0069】

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

【0070】

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

【0071】

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

【0072】

要求処理ユニット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要求または部分GET要求を受信して、それらの要求に応答してマルチメディアコンテンツ64のデータを提供するように構成され得る。要求は、たとえば、セグメントのURLを使用して、表現68の1つのセグメントを特定することができる。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を特定することができる。いくつかの例では、セグメントのバイト範囲は、部分GET要求を使用して特定され得る。

【0073】

要求処理ユニット70はさらに、表現68の1つのセグメントのヘッダデータを提供するための、HTTP HEAD要求を提供するように構成され得る。いずれの場合でも、要求処理ユニット70は、クライアントデバイス40のような要求デバイスに、要求されたデータを提供するために、要求を処理するように構成され得る。

【0074】

本開示の技法によれば、サーバデバイス60はまた、ブロードキャストサーバまたはマルチキャストサーバとして動作することができる。あるいは、別個のデバイスは、たとえば以下で図3を参照して説明されるように、ブロードキャストサーバまたはマルチキャストサーバとして動作することができる。いずれの場合でも、サーバデバイス60のようなサーバデバイスは、1つまたは複数のブロードキャストプロトコルまたはマルチキャストプロトコルを実装して、1つまたは複数の表現のデータをブロードキャストまたはマルチキャストすることができる。

【0075】

たとえば、クライアントデバイス40は、マルチキャストグループに加わることができ、サーバデバイス60は、表現68の1つのデータをマルチキャストグループに送信することができる。ルータのような、ネットワーク74のネットワークデバイスは、マルチキャストグループに送信されたデータを、マルチキャストグループに加入したデバイスにリダイレクトすることができる。したがって、クライアントデバイス40がマルチキャストグループに加わる時、サーバデバイス60は、表現68の1つのデータをマルチキャストグループに送信し(たとえば、データをマルチキャストグループのIPアドレスに宛てることによって)、ネットワーク74のルータは、最終的にはクライアントデバイス40に達する別個のネットワークルート沿いにあるマルチキャストグループのメンバーのためにデータを複製することができる。

【0076】

サーバデバイス60、クライアントデバイス40、およびネットワーク74のデバイス(ルータのような)は、IPv4ネットワークを通じたマルチキャストを実行するために、Cain他、「Internet Group Management Protocol, Version 3」、Internet Engineering Task Force、Network Working Group、RFC3376、2002年10月で説明されるような、Internet Group Management Protocol(IGMP)を実装することができ、かつ/または、IPv6ネットワークを通じたマルチキャストを実行するために、Vida他、「Multicast Listener Discovery Version 2(MLDv2) for IPv6」、Internet Engineering Task Force、Network Working Group、RFC2710、1999年10月で説明されるような、Multicast Listener Discovery(MLD)を実装することができる。IGMPおよびMLDを使用したマルチキャストの追加の詳細は、Holbrook他、「Using Internet Group Management Protocol Version 3(IGMPv3) and Multicast Listener Discovery Protocol Version 2(MLDv2) for Source-Specific Multicast」、Internet Engineering Task Force、Network Working Group、RFC4604、2006年8月で説明されている。

【0077】

別の例として、ブロードキャストドメインのすべてのメンバー(たとえば、クライアントデバイス40)がブロードキャストデータを受信するように、サーバデバイス60、または別個のサーバデバイスは、表現68の1つのデータをブロードキャストドメインに送信することができる。ネットワーク74内のルータは、ネットワーク74をブロードキャストドメインに分割することができる。いくつかの例では、サーバデバイス60は、仮想ローカルエリアネットワーク(VLAN)を提供することができ、クライアントデバイス40のようなクライアントデバイスは、ネットワークブロードキャストデータを受信するために、VLANに加わることができる。

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

本開示の技法に従って、ウェブアプリケーション52は、サーバデバイス60(または別のサーバデバイス)によって送信されるブロードキャストデータまたはマルチキャストデータを受信することを要求するように構成され得る。たとえば、ウェブアプリケーション52は、マニフェストファイル66のデータを最初に検索するように構成されてよく、このデータは、マルチキャストグループに加わるためのデータ(マルチキャストグループIPアドレスのような)、またはブロードキャストを受信するためのデータ(たとえば、ブロードキャストドメインまたはVLANに加わるためのデータ)を含み得る。その上、ウェブアプリケーション52、またはクライアントデバイス40の別のアプリケーションもしくはシステムソフトウェアは、FLUTEプロトコルのようなファイル配信プロトコルを実装するように構成され得る。このようにして、クライアントデバイス40は、FLUTEプロトコルを介したブロードキャストまたはマルチキャストを使用して、マルチメディアコンテンツ64のデータを検索するように構成され得る。ファイル配信サービスのようなFLUTEを利用するために、サーバデバイス60は、クライアントデバイス40へのメディアコンテンツ62の1つまたは複数のユニキャストuniform resource locator(URL)を示す属性を含む、File Delivery Table(FDT)を提供することができる。

【0083】

本開示の技法によれば、複数の表現68の異なる1つは、切替ポイント(ランダムアクセスポイント(RAP:random access point)とも呼ばれ、瞬時デコーダリフレッシュ(IDR:instantaneous decoder refresh)、オープンデコーダリフレッシュ(ODR:open decoder refresh)、および/またはクリーンランダムアクセス(CRA:clean random access)ピクチャを含み得る)の異なる時間的な周波数を有し得る。たとえば、表現68Aは、再生時間に関して約1秒の間隔で発生する切替ポイントを含んでよく、一方表現68Nは、やはり再生時間に関して約10秒間隔で発生する切替ポイントを含んでよい。サーバデバイス60は、切替ポイントの頻度が比較的低い、たとえばその間隔が再生時間に関して10秒である、表現68の1つからのデータをブロードキャストすることができる。

【0084】

本開示の技法によれば、クライアントデバイス40は、十分な量のデータがバッファリングされるまで、切替ポイントの頻度がより高い表現68の1つからのデータを要求し、次いで、ブロードキャストまたはマルチキャストに切り替えることができる。切替ポイントの頻度がより高い表現のデータは、比較的低品質であり得るが、品質が比較的低くても、少なくとも何らかのビデオデータを見せることによって、クライアントデバイス40がより比較的高品質の表現の切替ポイントに到達するのを待機する間空白の画面を見せるよりも、ユーザ体験を向上させることができる。当然、比較的高品質の表現の切替ポイント(FLUTEプロトコルに従ってブロードキャストまたはマルチキャストを介して受信され得る)を受信した後、クライアントデバイス40はその表現に切り替えることができる。

【0085】

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

【0086】

上で述べられたように、表現68は、様々な符号化およびレンダリングの特性のビデオデータを含み得る。適応セットの表現は、変化するビットレートを有してよく、これは帯域幅の適応を可能にし得る。従来のDASH技法では、これによって、クライアントデバイスが、現在の利用可能な帯域幅の量が対応し得る最良のビットレートを有する表現からデータを検索することによって、変化する帯域幅の利用可能性に適応することが可能になる。本開示の技法によれば、サーバデバイス60は、帯域幅の適応を実行するように構成され得る。たとえば、サーバデバイス60は、ネットワーク帯域幅の現在の量を示す情報を受信し、それに従って表現68の1つを選択することができる。したがって、利用可能な帯域幅が増えると、サーバデバイス60は、ビットレートが比較的高い表現68の1つのデータのブロードキャストまたはマルチキャストを開始することができ、一方利用可能な帯域幅が減ると、サーバデバイス60は、ビットレートが比較的低い表現68の1つのデータのブロードキャストまたはマルチキャストを開始することができる。

【0087】

ネットワークインターフェース54は、ブロードキャストによるものか、マルチキャストによるものか、またはユニキャストによるものかを問わず、サーバデバイス60(または別のサーバデバイス)から送信されたデータを受信することができる。具体的には、ネットワークインターフェース54は、表現68の受信されたセグメントのデータを受信し、それをウェブアプリケーション52に提供することができる。ウェブアプリケーション52は次いで、セグメントをカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化されたデータを検索し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化されたデータがオーディオストリームの一部かビデオストリームの一部かに応じて、符号化されたデータをオーディオデコーダ46とビデオデコーダ48のいずれかに送信することができる。オーディオデコーダ46は、符号化されたオーディオデータを復号し、復号されたオーディオデータをオーディオ出力42に送信し、一方ビデオデコーダ48は、符号化されたビデオデータを復号し、ストリームの複数の表示を含み得る復号されたビデオデータを、ビデオ出力44に送信する。

【0088】

その上、本開示の技法によれば、ウェブアプリケーション52は、たとえば、クライアントデバイス40のフラッシュメモリ(図示せず)に、FLUTEを介してマルチキャストまたはブロードキャストに従って受信されたデータをキャッシュすることができる。クライアントデバイス40は、ある期間にブロードキャストまたはマルチキャストを介して受信されたデータを記憶するための、フラッシュメモリのような1つまたは複数のコンピュータ可読記憶媒体を含み得る。このようにして、ユーザは、サーバデバイス60(または別のサーバデバイス)によってブロードキャストまたはマルチキャストされているデータを見ることを、最初に要求することができる。クライアントデバイス40は次いで、受信されたデータをキャッシュすることができる。したがって、ユーザがデータを見ることを続いて要求する場合、クライアントデバイス40は、データを再び検索するための要求を行うのではなく、クライアントデバイス40の内部にある記憶媒体、たとえばフラッシュメモリからデータを検索することができる。

【0089】

サーバデバイス60は、FLUTEプロトコルを介したビデオデータをブロードキャストまたはマルチキャストする時、キャッシングプリミティブを提供することができる。キャッシングプリミティブは、データを記憶する時間の長さの1つまたは複数を示す値、データが失効するであろうことを示すもの(たとえば、「失効」プリミティブ)、データの作成日、データの送信日、メディアコンテンツの具体的なバージョンを特定するエンティティタグ(ETag)、メディアコンテンツのデータがキャッシュ可能であることを示すキャッシュ制御ヘッダ、または他のそのような情報を含み得る。したがって、クライアントデバイス40は、キャッシングプリミティブを使用して、データをどのようにキャッシュするか、またはどれだけの長さキャッシュするかを決定することができる。同様に、ルータ、プロキシデバイス、キャッシングデバイス、または他のそのようなネットワークデバイスのような、ネットワーク74の中間ネットワークデバイスも、キャッシングプリミティブを使用してデータをキャッシュすることができる。したがって、クライアントデバイスが、たとえばユニキャストを使用してデータを要求するとしたら、データをキャッシュした中間ネットワークデバイスは、その要求をサーバデバイス60に転送するのではなく、データをクライアントデバイスに配信できる。

【0090】

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

【0091】

図2は、図1のネットワーク74の一部を形成するデバイスのある例示的なセットを示すブロック図である。この例では、ネットワーク74は、ルーティングデバイス80A、80B(ルーティングデバイス80)およびプロキシキャッシュデバイス82を含む。ルーティングデバイス80およびプロキシキャッシュデバイス82は、ネットワーク74の一部を形成し得る少数のデバイスを代表することが意図される。スイッチ、ハブ、ゲートウェイ、ファイヤウォール、ブリッジ、および他のそのようなデバイスのような、他のネットワークデバイスも、ネットワーク74内に含まれ得る。その上、追加のネットワークデバイスが、サーバデバイス60とクライアントデバイス40との間のネットワーク経路に沿って設けられ得る。

【0092】

一般に、ルーティングデバイス80は、1つまたは複数のルーティングプロトコルを実装して、ネットワーク74を通じてネットワークデータを交換することができる。いくつかの例では、ルーティングデバイス80は、以下で説明されるようなプロキシキャッシュデバイス82に起因する機能のような、プロキシ動作またはキャッシュ動作を実行するように構成され得る。したがって、いくつかの例では、ルーティングデバイス80は、プロキシデバイスとも呼ばれ得る。一般に、ルーティングデバイス80はルーティングプロトコルを実行して、ネットワーク74を通るルートを発見する。そのようなルーティングプロトコルを実行することによって、ルーティングデバイス80Bは、ルーティングデバイス80Aを介した、ルーティングデバイス80Bからサーバデバイス60へのネットワークルートを発見することができる。

【0093】

したがって、ルーティングデバイス80Bは、サーバデバイス60に宛てられた、TCP-IPカプセル化HTTP GET要求のようなネットワーク通信を、クライアントデバイス40から受信することができる。そのような通信に応答して、ルーティングデバイス80Bは、サーバデバイス60へのルートを決定し、さらに、そのルートがプロキシキャッシュデバイス82を含むと判定することができる。たとえば、プロキシキャッシュデバイス82が、ルート沿いの「ネクストホップ」を含んでよく、または、1つまたは複数の追加のネットワークデバイスが、ルーティングデバイス80Bをプロキシキャッシュデバイス82へ通信可能に結合することができる。プロキシキャッシュデバイス82はまた、通信をルーティングデバイス80Aに向けることができ、ルーティングデバイス80Aは、通信をサーバデバイス60に転送することができる。

【0094】

プロキシキャッシュデバイス82は、プロキシキャッシング機能を実行することができる。HTTPプロキシキャッシングは、インターネットが動作するのに重要である。プロキシキャッシュデバイス82のようなHTTPプロキシキャッシュデバイスは、いずれかのまたはすべてのHTTPプロトコルバージョン(たとえば、HTTP 0.9、HTTP 1.0、および/またはHTTP 1.1)を実装することができる。本開示の技法によれば、プロキシキャッシュデバイス82は、ユニキャスト、ブロードキャスト、またはマルチキャストを介して受信されたメディアコンテンツのデータをキャッシュすることができる。たとえば、プロキシキャッシュデバイス82は、FLUTEプロトコルに従って交換されたデータをキャッシュするように構成され得る。このようにして、プロキシキャッシュデバイス82は、HTTPに従って交換されたユニキャストデータと、FLUTEに従って交換されたマルチキャストデータまたはブロードキャストデータとの両方をキャッシュすることができる。

【0095】

その上、本開示の技法によれば、ルーティングデバイス80Bのようなルーティングデバイスは、マルチキャストデータまたはブロードキャストデータを受信するための、クライアントデバイス40のようなクライアントデバイスによる要求を受け入れるように構成され得る。たとえば、ルーティングデバイス80Bは、クライアントデバイス40のようなクライアントデバイスから、マルチキャストグループに対するIGMP加入要求を受信するように構成され得る。ルーティングデバイス80Bはまた、サーバデバイス60からマルチキャストグループのデータを受信するように構成され得る。そのようなデータを受信したことに応答して、ルーティングデバイス80Bは、受信されたデータをコピーして、マルチキャストグループに加わることを要求した各クライアントデバイスに転送することができる。したがって、追加のクライアントデバイスがルーティングデバイス80Bに通信可能に(直接または間接的に)結合されると仮定すると、ルーティングデバイス80Bは、マルチキャストデータをコピーして、対応するマルチキャストグループに加わったクライアントデバイスの各々に転送する。ルーティングデバイス80Aも、たとえば、マルチキャストのサポートのためにIGMPを実装するために、ルーティングデバイス80Bと同様に構成され得る。さらに、他のクライアントデバイスは、ルーティングデバイス80Aに通信可能に(直接または間接的に)結合されてよい。

【0096】

図3は、2つのサーバデバイスがクライアントデバイス40にメディアコンテンツのデータを提供するある例を示すブロック図である。具体的には、図3の例は、ブロードキャストサーバデバイス90およびユニキャストサーバデバイス92を示す。いくつかの例では、ブロードキャストサーバデバイス90およびユニキャストサーバデバイス92は、同じコンテンツ配信ネットワークの一部を形成する。ブロードキャストサーバデバイス90とユニキャストサーバデバイス92の両方が、図1および図2のサーバデバイス60と同様に構成され得る。あるいは、ブロードキャストサーバデバイス90は、ネットワークブロードキャストまたはマルチキャストの形式のみでメディアデータを出力するように構成されてよく、一方ユニキャストサーバデバイス92は、たとえばクライアントデバイス40からの要求に応答して、ユニキャストの形式のみでメディアデータを出力するように構成されてよい。

【0097】

図3の例では、ブロードキャストサーバデバイス90とユニキャストサーバデバイス92の両方が、コンテンツ準備デバイス20からメディアデータを受信する。ブロードキャストサーバデバイス90およびユニキャストサーバデバイス92は、同じメディアデータ、またはメディアデータの異なる表現を受信することができる。ブロードキャストサーバデバイスと呼ばれるが、ブロードキャストサーバデバイス90は、追加でまたは代替的に、マルチキャストに従ってデータを出力するように構成され得る。さらに、ブロードキャストサーバデバイス90は、FLUTEプロトコルに従ってメディアデータをマルチキャストまたはブロードキャストするように構成され得る。

【0098】

本開示の技法に従って、クライアントデバイス40は、ウェブページまたは他のネットワーク位置にアクセスして、MPDファイル(たとえば、図1のマニフェストファイル66に対応するファイル)を検索することができる。ウェブページは、ユニキャストサーバデバイス92によってホストされ得る。クライアントデバイスは、MPDからの情報を抽出して、ユニキャストサーバデバイス92からメディアコンテンツのデータを検索し、かつ/または、ブロードキャストサーバデバイス90からメディアコンテンツのデータを受信することができる。たとえば、MPDは、ブロードキャストサーバデバイス90によってサービスされるマルチキャストグループの、マルチキャストグループアドレスを含み得る。MPDはまた、ユニキャストに従って、ユニキャストサーバデバイス92によってホストされるメディアコンテンツの表現のデータにアクセスするための、URLを含み得る。その上、MPDは、メディアコンテンツの表現の、符号化およびレンダリングの特性を表すことができる。いくつかの例では、MPDは、ブロードキャストまたはマルチキャストのための適応セットと、ユニキャストのための適応セットとを示す情報を提供することができる。つまり、MPDは、適応セットの表現が、ブロードキャストまたはマルチキャストに利用可能か、ユニキャストに利用可能か、またはこれらの両方に利用可能かを示すことができる。

【0099】

さらに、MPDは、メディアコンテンツの表現のためのタイミング情報を示す情報を提供することができる。いくつかの例では、ブロードキャストサーバデバイス90によって提供されるブロードキャスト表現またはマルチキャスト表現には、ユニキャストサーバデバイス92によって提供される他の表現よりも、切替ポイントが頻繁に現れない。そのような例では、クライアントデバイス40は、(再生時間に関する)複数の切替ポイントの間の期間に対応するデータの量を決定し、ユニキャストサーバデバイス92からその量のデータを検索することを要求することができる。クライアントデバイス40は、ユニキャストサーバデバイス92から受信されたこのデータをバッファリングし、その後、またはそれと同時に、ブロードキャストサーバデバイス90からのブロードキャストまたはマルチキャストのデータを受信することも開始する。このようにして、マルチキャストまたはブロードキャストを介して受信された表現の切替ポイントが受信されるまで、クライアントデバイス40は、ユニキャストを介して受信された十分な量のデータをバッファリングして、メディアコンテンツのデータの復号および再生を開始することができる。クライアントデバイスは、切替ポイントにおいて、マルチキャストまたはブロードキャストを介して受信された表現を復号するのを開始でき、さらに、この表現に切り替えた後、ユニキャストを介してメディアデータのデータを要求するのを停止することができる。

【0100】

やはり、いくつかの例では、同じサーバデバイスが、ユニキャスト(HTTP GET要求または部分GET要求に応答した)とマルチキャストまたはブロードキャストとの両方を使用してデータを出力できることを、理解されたい。図3は、別個のデバイスが、メディアデータのユニキャスト出力と、ブロードキャスト出力またはマルチキャスト出力とを担う、代替的な例を示す。

【0101】

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

【0102】

MPD102は、表現110〜120とは別個のデータ構造を含み得る。MPD102は、図1のマニフェストファイル66に対応し得る。同様に、表現110〜120は、図1の表現68に対応し得る。一般に、MPD102は、符号化およびレンダリングの特性、適応セット、MPD102が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を検索するための情報(たとえば、再生中のメディアコンテンツへの、ターゲットを定めた広告の挿入)のような、表現110〜120の特性を一般に表す、データを含み得る。離れた期間は、外部期間とも呼ばれ得る。以下でより詳しく論じられる図4〜図7は、MPDおよび/または表現のいずれかまたは両方に(たとえば表現のセグメントまたは表現のヘッダデータ内に)含まれる様々な要素を伴う、マルチメディアコンテンツの様々な例を示す。図4〜図7のMPDのいずれかまたはすべてが、図4のMPD102に実質的に対応し得る。

【0103】

本開示の技法によれば、図4のMPD102は、たとえば、マルチキャストグループに加わり、マルチキャストされ得る表現110〜120のいずれかのデータを検索するための、ユニキャストおよびマルチキャストグループアドレス104であり得る、セグメント114および/または124のURLのような情報を規定することができる。あるいは、MPD102は、ネットワークブロードキャストデータを検索するためのデータを含み得る。

【0104】

一例では、表現110のデータはユニキャストを使用して出力されてよいが、表現120のデータはマルチキャストまたはブロードキャストを使用して出力されてよい。当然、マルチメディアコンテンツ100の他の表現のデータ(図示されないが、楕円によって表される)も、マルチキャスト、ブロードキャスト、またはユニキャストのいずれかまたはすべてを使用して出力されてよい。

【0105】

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

【0106】

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

【0107】

セグメント114、124の各々は、固有のuniform resource identifier(URI)、たとえばuniform resource locator(URL)と関連付けられ得る。したがって、セグメント114、124の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立に検索可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント114または124を検索することができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント114または124の特定のバイト範囲を検索することができる。あるいは、本開示の技法によれば、例として、セグメント114は、HTTP GET要求に応答して、ユニキャストを使用して送られてよいが、セグメント124はブロードキャストまたはマルチキャストされてよい。

【0108】

上で述べられたように、MPD102は、特定のMPDプロファイルに準拠し得る。MPD102は、MPD102および/またはマルチメディアコンテンツ100の多目的インターネットメール拡張(MIME)のタイプを示す情報を含み得る。しかしながら、MIMEのタイプは一般に、マルチメディアコンテンツを提示するために何のコーデックが必要かは示さない。一般に、MPD102のような、マルチメディアコンテンツのためのMPDをデバイスが検索できる場合、デバイスは、MPDに対応するマルチメディアコンテンツのデータを再生できると想定される。しかしながら、この想定は常に安全とは限らない。したがって、いくつかの例では、MPD102は、MPD102が対応するプロファイルを示す情報を含み得る。

【0109】

MPDが対応し得るプロファイルは、比較的少数であり得る。プロファイルは、H.264/AVCがビデオ符号化のためのプロファイルおよびレベルを含む方式と同様に、能力を指定するためのレベルによってサポートされ得る。MPDプロファイルは、より上位のプロファイルがすべてのより下位のプロファイルのすべての特徴を含み得るという点で、玉ねぎのような構造であり得る(onion-shelled)。様々なプロファイルを登録するための、登録機関による登録処理があり得る。いくつかの例では、クライアントデバイス40のようなクライアントデバイスは、MPD102のようなMPDのプロファイルを示す情報を、MPD102によってシグナリングされた表現110〜120の特性のようなMPDの他のデータを検索する前に、検索するように構成され得る。このようにして、MPD102のプロファイルは、MPD102に対するアクセスが提供される前にシグナリングされ得る。

【0110】

プロファイル識別子は、プレーンテキストで(たとえば、単純な名前)で、または復元されたドメイン名で与えられてよい。単純な名前は、3GPPまたは別の登録機関のような、登録機関によって用意され得る。プロファイルが、対応するマルチメディアコンテンツがそのプロファイルに準拠すると主張でき、読み取り器(たとえば、クライアントデバイス)に許可を与えるという点で、プロファイルは主張および許可であると考えることができ、読み取り器は、MPDを読み取り、読み取り器が認識するものを解釈し、読み取り器が理解しないものを無視するようにそのプロファイルを実装する。

【0111】

プロファイルは、たとえば、MPD102の特徴、ネットワークの使用量、メディアフォーマット、使用されるコーデック、保護フォーマット、および/またはビットレート、画面サイズなどのような定量的な基準のような、特性を表すことができる。このようにして、MPD102のプロファイルは、MPD102および/またはマルチメディアコンテンツ100のデータを検索するために、何のコーデックがサポートされる必要があるかを示す情報を提供することができる。プロファイルは、「準拠ポイント」とも表され得る。MPDが準拠するプロファイルは、MPDの「プロファイル」属性で示され得る。したがって、クライアントデバイスは、MPD102の追加のデータを検索する前に、「プロファイル」属性に関連する情報を含む、MPD102の一部を検索するように構成され得る。あるいは、プロファイルは、MPDのMIMEのタイプにおいてパラメータとして示され得る。たとえば、プロファイル「X、Y、およびZ」は、video/vnd.mpeg.mpd;profiles="X,Y,Z"という方式でシグナリングされ得る。

【0112】

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

【0113】

ビデオファイル150は一般に、表現110〜120(図4)の1つに含まれ得る、マルチメディアコンテンツのセグメントの例を表す。このようにして、ビデオファイル150は、セグメント114の1つ、セグメント124の1つ、または別の表現のセグメントに対応し得る。本開示の技法によれば、ビデオファイル150と同様の方式でフォーマットされるセグメントは、ユニキャストか、マルチキャストか、ブロードキャストかを問わず、FLUTEを使用して送信され得る。

【0114】

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

【0115】

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

【0116】

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

【0117】

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

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

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

【0123】

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

【0124】

本開示の技法によれば、クライアントデバイス40のようなクライアントデバイスは、MFRAボックス166および/またはSIDXボックス162のデータを使用して、動画フラグメント164の中で切替ポイント(つまり、ランダムアクセスポイント)の位置を決定することができる。このようにして、クライアントデバイスが、ブロードキャストまたはマルチキャストを通じFLUTEを介して、ランダムアクセスポイントまたは切替ポイントを含むビデオファイルを受信すると、クライアントデバイスは、ランダムアクセスポイントからの復号を開始することができる。したがって、クライアントデバイスは、ブロードキャストまたはマルチキャストに従ったビデオファイルの受信元である表現に切り替えてよく、切替ポイントの後、ユニキャストを使用した検索のためのデータをさらに要求しなくてよい。切替ポイントが検索されたことを確実にしようと試みるために、クライアントデバイスは、少なくとも、ブロードキャストまたはマルチキャストを介して受信される(または受信されることになる)表現の複数の切替ポイントの間のビデオデータの時間的なセクションに対応する量の、ユニキャストを介して受信される表現からのデータを、要求しバッファリングすることができる。

【0125】

MFRAボックス166および/またはSIDXボックス162は、たとえば、切替ポイントの時間的な場所(再生に関する)、切替ポイントに達するためのバイトオフセット(たとえば、ビデオファイル150の開始から切替ポイントを含む動画フラグメント164の1つの開始までのバイトオフセット)、または、ビデオファイル150中の切替ポイントの他の特性のような情報を提供することができる。

【0126】

いくつかの例では、ビデオファイル150のデータは、ビデオファイル150のデータがどのようにキャッシュされるべきかを示す、キャッシングプリミティブのようなキャッシング情報を含み得る。このようにして、プロキシキャッシングデバイス(たとえば、図2のプロキシキャッシングデバイス82)またはクライアントデバイス(たとえば、クライアントデバイス40)のような、データをキャッシュするように構成されるデバイスは、要求に応答して、キャッシュされたデータを検索することができる。つまり、メディアコンテンツのデータを求める要求をサーバに転送するのではなく、クライアントデバイスまたはプロキシキャッシュデバイスは、キャッシュされたデータが失効していないと仮定して、キャッシュされたデータを使用して要求を提供することができる。

【0127】

図6は、2つの表現182、186を含む、例示的なメディアコンテンツ180を示す概念図である。この例では、表現182はセグメント184A〜184H(セグメント184)を含み、一方表現186はセグメント188Aおよび188B(セグメント188)を含む。限られた数のセグメントが図6に示されるが、表現の各々は、楕円によって示されるように、追加のセグメントを含み得る。図6の例では、セグメントの時間長は一般に、セグメントの幅によって示される。したがって、表現182のセグメント184は一般に、表現186のセグメント188よりも時間長が短い。例示を目的に、セグメント184、188の各々は、切替ポイント(すなわち、ランダムアクセスポイント)で開始すると仮定する。

【0128】

本開示の技法によれば、クライアントデバイス40は、メディアコンテンツ180にアクセスするための要求を受信することができる。クライアントデバイス40がメディアコンテンツ180のデータをまだキャッシュしていないと仮定すると、クライアントデバイス40は、メディアコンテンツ180のデータを検索することを要求できる。たとえば、ブロードキャストサーバデバイス90がセグメント188Aのほぼ半分までデータをブロードキャストした時に、クライアントデバイス40がメディアコンテンツ180のデータにアクセスするための要求をユーザから受け取ったとする。従来は、クライアントデバイス40は、メディアコンテンツ180のデータを提示する前に、セグメント188Bのデータが受信されるのを待つ必要がある。それは、表現186の次の切替ポイントが、セグメント188Bの開始点で発生するからである。

【0129】

しかしながら、本開示の技法によれば、クライアントデバイス40は、マルチキャストまたはブロードキャストを介して受信されたデータをバッファリングすることができるが、ユニキャストデータを要求することもできる。この例では、クライアントデバイス40は、ユニキャストを介した受信のために、セグメント184の1つまたは複数を要求することができる。たとえば、クライアントデバイス40は、セグメント184A〜184Dの各々を要求して、ユニキャストを介してこれらのセグメントのデータを検索することができる。このようにして、クライアントデバイス40は、表現186の次の切替ポイントに達するのを待機する間、表現182からのセグメント184A〜184Dのデータを復号して表示することができる。したがって、クライアントデバイス40は、セグメント188Bを受信するまで、表現182に対応するデータをユーザに提示することができる。セグメント188Bのデータを受信した後、クライアントデバイス40は、セグメント184を要求するのを停止し、表現186からのセグメント188のデータ、たとえば、セグメント188Bおよびそれ以降のセグメントのデータのみを受信することができる。

【0130】

したがって、一例では、クライアントデバイス40は、ユニキャストを介してセグメント184A〜184Dのいずれかまたはすべてを検索することができ、ブロードキャストまたはマルチキャストを介して、たとえばFLUTEに従って、表現186のセグメント188Bおよび後続のセグメントを検索することができる。さらに、クライアントデバイス40は、ある期間、表現186のセグメント188Bと後続のセグメントとのデータをキャッシュすることができる。このようにして、クライアントデバイス40のユーザは、データを再送信する必要なく、後でメディアコンテンツ180のデータに迅速にアクセスすることができる。その上、セグメント188のデータをキャッシュすることによって、クライアントデバイス40は、ブロードキャストまたはマルチキャストを介して受信されたセグメント188のデータによって、ブラウザのキャッシュを事前に満たすことができる。このようにして、クライアントデバイス40は、データがブラウザのキャッシュ中で利用可能であると判定できるので、クライアントデバイス40は、ユニキャストを使用してデータを検索する必要がない。

【0131】

図7は、ユニキャストおよびマルチキャストのためのネットワークスタックの例を示すブロック図である。図7は、ユニキャストネットワークスタック200Aの例と、マルチキャストネットワークスタック200Bの例とを示す。両方の例示的なネットワークスタックにおいて、アプリケーションデータ202は、たとえばクライアントデバイス上のDASHクライアントのために転送される。一般に、ネットワークスタック200A、200Bの上から下までの様々な層は、開放型システム間相互接続(OSI)ネットワークモデルにおいて定義されるようなネットワーク層に対応する。

【0132】

ネットワークスタック200Aの例は、サービス告知およびメタデータ204、関連配信手順206、ならびにMBMSセキュリティ212を含む。サービス告知およびメタデータ204は、クライアントデバイス40を保有しているユーザのようなワイヤレス顧客に対するMBMSの利用可能性を示す、サービス提供者(たとえば、ワイヤレス事業者)によって提供されるデータを含む。関連配信手順206は、ポイントツーポイント(PTP)ファイル修復208および受信報告210のような、データの配信と関連付けられそれを補足する、手順のためのデータを表す。PTPファイル修復208は、MBMSを通じて配信されたファイルのエラーのない受信を確実にするためのデータを表す。受信報告210は、受信統計のためのデータを表し、このデータは、ブロードキャストサーバまたはマルチキャストサーバのようなブロードキャストサービスセンタ/マルチキャストサービスセンタに提供され得る。

【0133】

ネットワークスタック200Aはまた、MBMSセキュリティ212を含み、MBMSセキュリティ212は、デジタル著作権管理(DRM)により保護されたメディアコンテンツを配信するための保護のレベルを提供する、サービスアクセス保護を提供する。具体的には、MBMS Service Key(MSK)216が送信され、クライアントデバイス40は、MBMS User Keyを使用してMSK216を復号する。MSK216は、Multimedia Internet KEYing(MIKEY)メッセージ222において、ユーザごとに個別に送信される。MSK216は、MBMS Traffic Keys(MTK)234を復号するために使用される。クライアントデバイス40は、MTK234を使用して、クライアントデバイス40によって受信されるメディアコンテンツの表現のセグメントを復号する。クライアントデバイス40はまた、表現214のデータを送信して、クライアントデバイス40がメディアコンテンツを受信するように登録されていることを示す。

【0134】

この例では、MKS216およびMIKEY222は、ユーザデータグラムプロトコル(UDP)226を通じて送信される。この例では、関連配信手順206および登録214のためのデータは、HTTP218に従って送信される。その上、HTTPダイジェスト220が、HTTP218を通じて送信されるデータを保護するために使用される。加えて、HTTP218を通じて送信されるデータは、送信制御プロトコル(224)を通じて送信される。TCP224を介して送信されるデータとUDP226を介して送られるデータの両方が、インターネットプロトコル(IP)228内でカプセル化され、IP228は、ネットワークスタック200Aのためにユニキャストを介して送信される。その上、IP(ユニキャスト)のためのデータ228は、ポイントツーポイント(PTP)ベアラ230を通じて送信される。この例では、ベアラは、MBMSのための無線チャンネルであってよい。

【0135】

ネットワークスタック200Bは、MIKEY222と同様のMTK234およびMIKEY236に対応するという点でMBMSセキュリティ212と同様である、MBMSセキュリティ232を含む。この例では、前方誤り訂正(FEC)238が、たとえば、MBMSセキュリティ232、MTK234、MIKEY236のセキュリティ関連データのために、再送信を伴わないエラーの訂正のためのデータを提供する。

【0136】

ネットワークスタック200Bはまた、ストリーミングコーデック240のためのデータを含み、このデータは、オーディオデータ、ビデオデータ、音声データ、テキストデータなどのような、コーデックのためのデータを含み得る。本開示の技法によれば、このデータは、たとえば図4および図5に関して上で説明されたような、DASHファイルフォーマット242に従ってフォーマットされる。ネットワークスタック200Bはまた、バイナリデータ、静止画像、テキスト、および他のそのようなデータを含み得る、3GPPファイルフォーマット244に従ってフォーマットされたデータを含む。関連配信手順246は、関連配信手順206に実質的に相当し、ポイントツーマルチポイント(PTM)ファイル修復248のためのデータを含む。PTMファイル修復248のデータは、サーバデバイスが、実際のMBMSデータ転送の後に追加のMBMSデータを送信することを可能にする。同様に、サービス告知およびメタデータ250は、サービス告知およびメタデータ204に実質的に相当する。

【0137】

ネットワークスタック200Bの例では、本開示の技法によれば、DASHデータ(ストリーミングコーデック240のDASHファイルフォーマット242でカプセル化されたコーデックデータ)、3GPPファイルフォーマット244のデータ、およびPTMファイル修復248のデータのような関連配信手順246のデータが、FLUTE252を通じて送信され、FLUTE252はALC254を通じて送信される。加えて、layered coding transport(LCT)256、輻輳制御(CC:congestion control)258、およびFEC260のためのデータが提供され得る。ネットワークスタック200Bの例では、このデータは、IPマルチキャストとIPユニキャスト262のいずれかを通じて送信され、IPマルチキャストまたはIPユニキャスト262は、MBMSまたはPTPベアラ264を通じて送信される。

【0138】

このようにして、ネットワークスタック200Bは、本開示の技法に従って、DASHフォーマットのメディアデータがFLUTEプロトコルを通じて送信され得る例を表す。したがって、ネットワークスタック200Bは、FLUTEがストリーミング配信のためのRTPへの代替的な転送としてどのように機能できるかを示す。これによって、DASHを介したブロードキャスト(またはマルチキャスト)とユニキャストの融合を可能にする。加えて、タイミングおよび同期はDASHフォーマットに備わっているので、RTPで提供されるようなタイミングおよび同期は必須ではない。したがって、本開示の技法は、ファイルサービスとストリーミングサービスの両方のための、単一のブロードキャスト転送パラダイムを可能にし得る。また、HTTPストリーミングで十分であるはずなので、MBMSサービスエリアの外に位置するクライアントデバイスに対するMBMSストリーミングサービス配信の継続性を、パケット交換ストリーミング(PSS:packet switched streaming)が提供する必要は、もはやない。

【0139】

図8は、別の例示的なクライアントデバイス280を示すブロック図である。一般に、クライアントデバイス280は、クライアントデバイス40に対応し得る。図8の例は、クライアントデバイスのコンポーネントをより詳しく示す。この例では、クライアントデバイス280は、制御ユニット282に起因する機能を実行するための、ハードウェア、ソフトウェア、および/またはファームウェアを表し得る、制御ユニット282を含む。ソフトウェアまたはファームウェアで実装される場合、制御ユニット282は、1つまたは複数の処理ユニット、および/または、ソフトウェア命令またはファームウェア命令を記憶するための1つまたは複数のハードウェアに基づくコンピュータ可読媒体のような、必須のハードウェアを含むと仮定される。

【0140】

この例では、制御ユニット282は、DASHアプリケーション284、要求ハンドラ286、HTTPアクセスクライアント288、FLUTEクライアント292、メディアキャッシュ290、およびFLUTEキャッシュ294を含む。いくつかの例では、FLUTEキャッシュ294のための別個のキャッシュが必要とならないように、単一のキャッシュのみが提供される(たとえば、メディアキャッシュ290)。DASHアプリケーション284は、DASHの技法を実行するための、ウェブブラウザまたはウェブブラウザのプラグインに相当し得る。いくつかの例では、DASHアプリケーション284はメディアプレーヤを含むが、他の例では、制御ユニット282は別個のメディアプレーヤアプリケーションを含む。図8には示されないが、制御ユニット282は、たとえば図1に示されるような、オーディオ、ビデオ、および他のメディアデータを復号するための、必須のデコーダを含むことも想定される。

【0141】

ユーザは、DASHアプリケーション284と対話して、メディアコンテンツ、たとえばインターネット上で利用可能なある特定の動画を選択することができる。DASHアプリケーション284は、要求ハンドラ286にHTTP要求を出すことができる。要求ハンドラ286は、メディアキャッシュ290から要求されたコンテンツを検索することによって(たとえば、要求されたメディアコンテンツがメディアキャッシュ290中で以前にアクセスされキャッシュされていた場合)、または、たとえばHTTPアクセスクライアント288を介して、ユニキャストネットワークを通じたストリーミング要求を開始することによって、要求にサービスすることができる。このようにして、メディアキャッシュ290およびFLUTEキャッシュ294は、FLUTEのようなファイル配信サービスを介して受信されたメディアデータがキャッシュされ得るローカルメモリの例を表す。その上、要求ハンドラ286は、DASHアプリケーション284からのDASH要求に応答して、ローカルメモリによって実装されるキャッシュにクエリを行うことができる。データがキャッシュの中にある場合、キャッシュ「ヒット」が発生でき、要求ハンドラ286は、キャッシュからのデータを使用して要求にサービスすることができる。一方、データがキャッシュ中にない場合、キャッシュ「喪失」が起こることがあり、これによって要求ハンドラ286は、HTTPアクセスクライアント286を介して、データを求めるユニキャスト要求を送信する。

【0142】

一般に、DASHアプリケーション284は、ある特定のメディアコンテンツの複数の表現から、ある表現を選択するように構成され得る。複数の表現が適応セットに対応する、または、複数の表現がクライアントデバイス280の符号化能力およびレンダリング能力を別様に満たすと仮定すると、DASHアプリケーション284は、ネットワーク帯域幅の量および複数の表現に対するビットレートに基づいて、それらの表現からある表現を選択することができる。たとえば、DASHアプリケーション284は、利用可能な表現の各々の配信遅延を計算する、レート推定アルゴリズムを実装することができる。

【0143】

メディアコンテンツのためのメディアデータがローカルメモリにキャッシュされる場合、レート推定アルゴリズムは、対応する表現の配信遅延が実質的に0であることを示し得る。したがって、メディアコンテンツのある表現のためのメディアデータがローカルメモリ(メディアキャッシュ290またはFLUTEキャッシュ294のような)にキャッシュされる場合、レート推定アルゴリズムは、キャッシュされたデータに対応する表現が最良であると判定することができる。したがって、DASHアプリケーション284が、ユーザのための異なる明示的な要求を受信していない限り、DASHアプリケーション284は、複数の表現のうちの1つを選択する時、ローカルメモリ中のキャッシュされたデータに対応する表現を自然に選択することができる。このようにして、(たとえば、FLUTEクライアント292によって)ブロードキャストまたはマルチキャストを介して受信されたメディアコンテンツによってキャッシュを事前に満たすことによって、DASHアプリケーション284は、計算された配信遅延が実質的に0である表現のキャッシュされたデータに基づいて、サーバデバイスによってブロードキャストまたはマルチキャストされた表現を、自動的に選択することができる。

【0144】

メディアキャッシュ290が、要求されたメディアコンテンツのキャッシュされたデータを含まない場合、制御ユニット282は、FLUTEクライアント292に、ブロードキャストまたはマルチキャストの形式のメディアデータを受信するために、マルチキャストグループへ加入させることができる。FLUTEクライアント292は、MBMSベアラを通じてブロードキャストまたはマルチキャストを受信することができる。さらに、FLUTEクライアント292は、ブロードキャストまたはマルチキャストを受信し、FLUTEクライアント292は、受信されたデータをメディアキャッシュ290に記憶する。このようにして、DASHアプリケーション284が、要求ハンドラ286からの後続のセグメントのデータを続いて要求すると、要求ハンドラ286は、メディアデータがメディアキャッシュ290に記憶されていると判定することができる。したがって、十分な量のデータがブロードキャストまたはマルチキャストを介して受信された後(たとえば、切替ポイントを含むセグメントが受信された後)、要求ハンドラ286は、メディアデータに対する要求を、HTTPアクセスクライアント288にさらに出す必要はないが、代わりに、メディアキャッシュ290からメディアコンテンツを検索することができる。

【0145】

特に、DASHの技法によれば、DASHアプリケーション284は、メディアコンテンツを順次要求するように構成され得る。したがって、メディアコンテンツを求める第1の要求に応答して、メディアコンテンツがメディアキャッシュ290の中に存在しない場合、要求ハンドラ286は、HTTPアクセスクライアント288に、ユニキャストを介してメディアコンテンツのセグメントを検索するための1つまたは複数のGET要求または部分GET要求を出させることができ、また同時に、FLUTEクライアント292に、メディアコンテンツのためのマルチキャストグループへ加わることを要求させる。メディアコンテンツに対するDASHアプリケーション284からの後続の要求(つまり、メディアコンテンツの連続する後の部分)に応答して、要求ハンドラ286は再び、要求されたメディアコンテンツがメディアキャッシュ290において入手可能かどうかを判定することができ、入手可能ではない場合、HTTPアクセスクライアント288に、メディアコンテンツに対する1つまたは複数の後続のGET要求または部分GET要求を出させることができる。要求ハンドラ286は、マルチキャストまたはブロードキャストのデータがメディアキャッシュ290の中で入手可能になるまで(たとえば、表現の切替ポイントがメディアキャッシュ290に記憶された後)、HTTPアクセスクライアント288に、ユニキャストデータを検索させることを続けることができる。さらに、制御ユニット282は、DASHアプリケーション284によって再生された後直ちにまたは間もなくデータを削除するのではなく、ある延長された期間、メディアキャッシュ290に記憶されたデータを保持することができる。

【0146】

このようにして、クライアントデバイス280は、メディアコンテンツの少なくとも一部を検索するための要求をネットワークを介して送信し、その要求に応答して、ネットワークを通じてFile Delivery over Unidirectional Transport(FLUTE)プロトコルに従ってメディアコンテンツの少なくとも一部のストリーミングデータを受信するように構成される、1つまたは複数の処理ユニットを含む、ビデオデータの情報を検索するためのデバイスの例を表し、上記のメディアコンテンツは、HTTP(DASH)を通じた動的な適応ストリーミングに準拠し、上記の要求は、FLUTEプロトコルに従って少なくとも一部が配信されるのを要求することを含む。

【0147】

図9は、本開示の技法による、ユニキャスト、ブロードキャスト、またはマルチキャストのいずれかを通じてメディアデータを受信するための例示的な方法を示すフローチャートである。例示を目的に、図8のクライアントデバイス280の例に関して説明されるが、他のデバイスが同様の技法を実行するように構成されてもよいことを理解されたい。たとえば、図1〜図3のクライアントデバイス40は、図9の方法を実行するように構成され得る。図9の方法は一般に、FLUTEプロトコルのようなファイル配信サービスに従ってブロードキャストまたはマルチキャストを介して受信されたデータを使用して、(メディアキャッシュ290のような)キャッシュを事前に満たし、ブロードキャストまたはマルチキャストを通じたストリーミングを実現するステップを含む。

【0148】

この例では、クライアントデバイス280は最初、メディアデータにアクセスするための要求を受け取る(300)。たとえば、DASHアプリケーション284は、メディアコンテンツにアクセスするための要求を、クライアントデバイス280のユーザから受け取ることができる。図8に関して説明されたように、DASHアプリケーション284は、メディアデータに対する要求を要求ハンドラ286に送信することができる。要求ハンドラ286は次いで、要求されたメディアデータがメディアキャッシュ290内で現在キャッシュされているかどうかを判定することができる(302)。メディアデータがキャッシュ中にない場合(302の「NO」分岐)、要求ハンドラ286は、FLUTEクライアント292に、FLUTEを使用してメディアデータを検索することを要求させることができる(304)。たとえば、FLUTEクライアント292は、マルチキャストグループに加入して、FLUTEに従ったマルチキャストまたはブロードキャストを介したメディアコンテンツのデータの受信を開始することができる。FLUTEクライアント292がFLUTEを介してメディアデータを受信するに従って、FLUTEクライアント292は、FLUTEキャッシュ294および/またはメディアキャッシュ290に、受信されたメディアデータをキャッシュすることができる(306)。

【0149】

加えて、要求ハンドラ286は、HTTPアクセスクライアント288に、HTTPユニキャストを使用してより前のメディアデータを検索することを要求させることができる(308)。HTTPユニキャストを介して要求されたデータは、必ずしも、ブロードキャストまたはマルチキャストの現在の時間的な位置よりも前にある必要はないが、多くの場合、切替ポイントが受信されるブロードキャストまたはマルチキャストのポイントよりも前にあるので、この意味で、HTTPユニキャストを介して要求されたデータはより前にある。クライアントデバイス280は、ユニキャストを介して受信されたメディアデータを、復号して表示することができる(310)。つまり、ブロードキャストまたはマルチキャストを介して切替ポイントの到達を待機している間、クライアントデバイス280は、ユニキャストを介して受信されたデータを復号して表示することができる。具体的には、HTTPアクセスクライアント288が要求されたデータをユニキャストを介して受信した後、HTTPアクセスクライアント288は、そのデータを要求ハンドラ286に送信することができ、要求ハンドラ286は、そのデータをメディアキャッシュ290に記憶し、DASHアプリケーション284に送信することができる。DASHアプリケーション284は次いで、そのデータを復号のために適切なコーデック(図8には示されない)に送信し、復号されたデータを、復号されたビデオのためのディスプレイ(さらには、もしあればテキストの重畳)および復号されたオーディオのためのスピーカのような、ユーザインターフェース(図8には示されない)に向けることができる。そしてこの処理は繰り返すことができ、DASHアプリケーション284はメディアコンテンツの後続のセグメントを要求し、この後続のセグメントはメディアキャッシュ290にキャッシュされていることもありまだキャッシュされていないこともある。

【0150】

メディアコンテンツの表現の切替ポイント(および場合によっては、切替ポイントの後のある最小限の量の追加のデータ)が、ブロードキャストまたはマルチキャストを介して受信され、メディアキャッシュ290に記憶された後、要求ハンドラ286は、DASHアプリケーション284によって要求されるメディアデータがメディアキャッシュ290の中にあると判定することができる(「YES」分岐302)。それに応答して、要求ハンドラ286は、メディアキャッシュ290から要求されたメディアデータを検索し(312)、要求されたメディアデータをDASHアプリケーション284に送信することができる。同様に、DASHアプリケーション284は、メディアキャッシュ290から検索されたメディアデータを、復号して表示することができる(314)。図9の方法には明示的に示されないが、FLUTEクライアント292は、FLUTEを介してメディアコンテンツのデータを受信し続け、メディアキャッシュ290に受信されたデータを記憶し続けると想定される。したがって、要求ハンドラ286は、メディアキャッシュ290のデータを使用して、後続の要求のメディアデータが満たされ得ると判定すべきである。当然、ユーザが異なるメディアコンテンツに変更した場合、または、ブロードキャストまたはマルチキャストのネットワーク割り込みがある場合、クライアントデバイス280は、本開示の技法を実行して、チャンネル変更を達成することができ、または、メディアコンテンツの十分なデータがメディアキャッシュ290でバッファリングされるまで、一時的にユニキャストに戻ることができる。

【0151】

DASHの転送のための、ユニキャストとブロードキャストの両方、またはマルチキャストを許可する、本開示の技法は、種々の状況において利点をもたらし得る。たとえば、上で論じられたように、これらの技法は、クライアントデバイスが、ブロードキャストまたはマルチキャストを介して切替ポイントが受信されるのを単に待機するよりも早く、メディアコンテンツの(特に、ユニキャストを介して受信されるデータの)再生を開始することを可能にし得る。それは、クライアントデバイスは、より頻繁に切替ポイントを有する表現のデータを、ユニキャストを介して検索することができるからである。別の状況として、ブロードキャストまたはマルチキャストされている表現の品質は、ある特定のユーザには十分高くないことがある。そのようなユーザは、ユニキャストを介した、メディアコンテンツのある特定の時間的なセクションのデータの再送信を要求して、データを異なる品質レベルで検索することができる。たとえば、ブロードキャストまたはマルチキャストされている表現の再生において、ぼやけているように見える、または見るのが困難である、詳細部分が存在することがあるので、ユーザは、対応する時間的なセクションの、高品質の表現からのデータを要求することができる。クライアントデバイスは、ブロードキャストまたはマルチキャストのデータをバッファリングし続けることができるが、ユニキャストを使用したより高品質な表現のデータも要求することができる。

【0152】

このようにして、図9の方法は、メディアコンテンツの少なくとも一部を検索するための要求を、ネットワークを介して送信するステップであって、メディアコンテンツがHTTP(DASH)を通じた動的な適応ストリーミングに準拠し、要求が、File Delivery over Unidirectional Transport(FLUTE)プロトコルに従って少なくとも一部が配信されることを要求することを含む、ステップと、要求に応答して、ネットワークを通じてFLUTEプロトコルに従って、メディアコンテンツの少なくとも一部のストリーミングデータを受信するステップとを含む、方法の例を表す。その上、図9の例示的な方法はさらに、ユニキャストプロトコルに従ってメディアコンテンツの第1の部分を検索するステップを含む。また、図9の例示的な方法では、少なくとも一部を検索するための要求を送信するステップは、メディアコンテンツの第2の部分を検索するための要求を送信するステップを含んでよく、第1の部分が、第2の部分よりもメディアコンテンツ内で時間的に早く、第1の部分が、第2の部分の中の複数の切替ポイントの間の時間的な期間と少なくとも同じ長さである、時間長を有する。

【0153】

図10は、FLUTEのようなファイル配信サービスを使用してDASHメディアコンテンツを出力するための例示的な方法を示すフローチャートである。図1および図2のサーバデバイス60の例に関して説明されるが、他のデバイスが、図10の方法を実行するように構成されてもよいことを理解されたい。たとえば、図3のブロードキャストサーバデバイス90は、この方法または同様の方法を実行するように構成され得る。

【0154】

この例では、サーバデバイス60は、たとえばコンテンツ準備デバイス20(図1)から、メディアコンテンツを受信することができる(350)。メディアコンテンツは、DASHに従ってフォーマットされ得る。つまり、メディアコンテンツは、様々な異なる表現を含んでよく、それらの表現は共通の符号化およびレンダリングの特性を有する適応セットへと分類され得る。異なる適応セットの表現は、異なる符号化特性および/またはレンダリング特性を有し得る。サーバデバイス60は、マルチキャストグループのアドレスを決定することができる(352)。サーバデバイス60はまた、メディアコンテンツのためのMPDファイル中のマルチキャストグループのアドレスを通知することができる(354)。サーバデバイス60はまた、MPDファイルを出力することができる(356)。

【0155】

この例では、サーバデバイス60はまた、メディアコンテンツの表現の1つを選択する(358)。たとえば、サーバデバイス60は、管理者のようなユーザから、表現の選択を受け取ることができる。あるいは、サーバデバイス60は、利用可能なネットワーク帯域幅の測定された量および/またはマルチキャストグループに加入しているユーザの数のような、ネットワーク状態に基づいて表現を選択することができる。いずれの場合でも、サーバデバイス60は次いで、マルチキャストグループに選択された表現のデータを出力することができる(360)。つまり、サーバデバイス60は、出力の宛先アドレスとして、マルチキャストグループのインターネットプロトコル(IP)アドレスを設定することができる。その上、サーバデバイス60は、FLUTEプロトコルのようなファイル配信サービスに従って、データを出力することができる。マルチキャストグループのアドレスにデータを送信することで、ネットワーク中のルータに、マルチキャストのデータを複製させ、クライアントデバイス、たとえばクライアントデバイス40のような、マルチキャストグループに加入したデバイスへ、マルチキャストのデータを転送させることができる。

【0156】

サーバデバイス60はまた、ネットワーク状態に変化(たとえば、利用可能なネットワーク帯域幅の変化)があったかどうか、および/または、マルチキャストグループに加入したユーザの数に変化があったかどうかを、判定することができる(362)。そのような変化がなかった場合(362の「NO」分岐)、サーバデバイス60は、マルチキャストグループに選択された表現のデータを出力し続けることができる(360)。あるいは、変化があった場合(362の「YES」分岐)、サーバデバイス60は、異なる表現を選択することができる(364)。たとえば、ユーザの数が増えた場合、サーバデバイス60は、よりビットレートが低い表現を選択することができ、ユーザの数が減った場合、サーバデバイス60は、よりビットレートが高い表現を選択することができる。

【0157】

加えて、図10の例には示されないが、サーバデバイス60または異なるサーバデバイスは、メディアコンテンツのデータを求めるユニキャスト要求を受信することができる。そのような要求は、任意の時間において受信され得る。本開示の技法によれば、要求は、サーバデバイス60によって選択されたものとは異なる表現、たとえば、比較的より頻繁に切替ポイントを有する表現からのデータに対するものであってよい。それに応答して、サーバデバイス60または別のサーバデバイスは、要求デバイスに要求されたデータを送信することができる。

【0158】

このようにして、図10の方法は、HTTP(DASH)を通じた動的な適応ストリーミングに準拠するメディアコンテンツを取得するステップと、ネットワークを通じてファイル配信サービスに従ってメディアコンテンツのデータを出力するステップとを含む、方法のある例を表す。方法はさらに、クライアントデバイスからメディアコンテンツの第1の部分を求める要求を受信するステップであって、要求が、ユニキャストプロトコルに従ったメディアコンテンツの第1の部分に対する要求を含む、ステップと、ユニキャストプロトコルに従って、第1の部分に対する要求を出力するステップとを含み得る。ファイル配信サービスに従ってメディアコンテンツのデータを出力するステップは、ファイル配信サービスに従ってメディアコンテンツの第2の部分を出力するステップを含んでよく、第1の部分は、第2の部分よりもメディアコンテンツ内で時間的に早くてよい。

【0159】

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

【0160】

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

【0161】

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

【0162】

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

【0163】

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

【符号の説明】

【0164】

10 システム
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
42 オーディオ出力
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 ウェブアプリケーション
54 ネットワークインターフェース
60 サーバデバイス
64 マルチメディアコンテンツ
66 マニフェストファイル
68 表現
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
90 ブロードキャストサーバデバイス
92 ユニキャストサーバデバイス
102 MPD
104 マルチキャストグループアドレス
110 表現
112 ヘッダデータ
114 セグメント
150 ビデオファイル
152 ファイルタイプボックス
154 動画ボックス
162 セグメントインデックスボックス
164 動画フラグメント
166 動画フラグメントランダムアクセスボックス
200A ネットワークスタック
202 アプリケーションデータ
280 クライアントデバイス
282 制御ユニット
284 DASHアプリケーション
286 要求ハンドラ
288 HTTPアクセスクライアント
290 メディアキャッシュ
292 FLUTEクライアント
294 FLUTEキャッシュ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】