特許 6348251 端末装置、受信方法、およびプログラム

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

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

(11)【特許番号】6348251

(24)【登録日】2018年6月8日

(45)【発行日】2018年6月27日

(54)【発明の名称】端末装置、受信方法、およびプログラム

(51)【国際特許分類】

   H04N 21/438 20110101AFI20180618BHJP

   H04N 21/435 20110101ALI20180618BHJP

   H04N 21/6332 20110101ALI20180618BHJP

【ＦＩ】

   H04N21/438

   H04N21/435

   H04N21/6332

【請求項の数】7

【全頁数】18

(21)【出願番号】特願2012-201059(P2012-201059)

(22)【出願日】2012年9月13日

(65)【公開番号】特開2014-57227(P2014-57227A)

(43)【公開日】2014年3月27日

【審査請求日】2015年8月4日

(73)【特許権者】

【識別番号】316009762

【氏名又は名称】サターン ライセンシング エルエルシー

【氏名又は名称原語表記】Ｓａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ

(74)【代理人】

【識別番号】100121131

【弁理士】

【氏名又は名称】西川 孝

(74)【代理人】

【識別番号】100082131

【弁理士】

【氏名又は名称】稲本 義雄

(72)【発明者】

【氏名】山岸 靖明

【審査官】 後藤 嘉宏

(56)【参考文献】

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

【文献】 Digital Video Broadcasting (DVB); Uniform Resource Identifiers (URI) for DVB Systems，ETSI TS 102 851 V1.3.1 (2012-01)，ＵＲＬ，http://www.etsi.org/deliver/etsi_ts/102800_102899/102851/01.03.01_60/ts_102851v010301p.pdf

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

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

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

【請求項1】

適応的ストリーミング技術に従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置から前記ストリーミングデータを受信する端末装置において、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルとして供給されたコンテンツのストリーミングデータを、HTTP配信またはマルチキャスト配信の少なくとも一方を介して受信し、
前記マルチキャスト配信されるセグメントファイルを受信するための情報が記述されたメタファイルとして、マルチキャストアドレスを記述できるように拡張されたMPDを取得し、
前記メタファイルとして前記拡張されたMPDは、
前記マルチキャストアドレス、
チューニングパラメータのデータ形式識別子、
および前記チューニングパラメータ
を含むサービスロケーション属性ファイルの取得先アドレスを含み、
取得した前記メタファイルに基づいて、HTTP配信により供給されたセグメントファイルを受信し、
取得した前記メタファイルに基づいて、前記サービスロケーション属性ファイルを取得し、
前記サービスロケーション属性ファイルに基づいて、セグメントファイルの属性情報を含む、マルチキャスト配信されるFDTを受信し、
受信した前記FDTに基づいてセグメントファイルを含む一方向ファイル転送プロトコルパケットを受信するように構成された
端末装置。

【請求項2】

前記FDTは、レンジ属性を含む
請求項１に記載の端末装置。

【請求項3】

前記レンジ属性は、適応的ストリーミング技術のMPDにおけるメディアレンジ属性が流用される
請求項２に記載の端末装置。

【請求項4】

適応的ストリーミング技術に従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置から前記ストリーミングデータを受信する端末装置であって、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルとして供給されたコンテンツのストリーミングデータを、HTTP配信またはマルチキャスト配信の少なくとも一方を介して受信する受信部と、
前記マルチキャスト配信されるセグメントファイルを受信するための情報が記述されたメタファイルとして、マルチキャストアドレスを記述できるように拡張されたMPDを取得する取得部とを含む端末装置の受信方法であって、
前記メタファイルとして前記拡張されたMPDは、
前記マルチキャストアドレス、
チューニングパラメータのデータ形式識別子、
および前記チューニングパラメータ
を含むサービスロケーション属性ファイルの取得先アドレスを含み、
前記受信部が、取得した前記メタファイルに基づいて、HTTP配信により供給されたセグメントファイルを受信し、
前記取得部が、取得した前記メタファイルに基づいて、前記サービスロケーション属性ファイルを取得し、
前記受信部が、
前記サービスロケーション属性ファイルに基づいて、セグメントファイルの属性情報を含む、マルチキャスト配信されるFDTを受信し、
受信した前記FDTに基づいてセグメントファイルを含む一方向ファイル転送プロトコルパケットを受信する
ステップを含む受信方法。

【請求項5】

前記FDTは、レンジ属性を含む
請求項４に記載の受信方法。

【請求項6】

前記レンジ属性は、適応的ストリーミング技術のMPDにおけるメディアレンジ属性が流用される
請求項５に記載の受信方法。

【請求項7】

適応的ストリーミング技術に従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置から前記ストリーミングデータを受信する端末装置を制御するコンピュータを、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルとして供給されたコンテンツのストリーミングデータを、HTTP配信またはマルチキャスト配信の少なくとも一方を介して受信する受信部と、
前記マルチキャスト配信されるセグメントファイルを受信するための情報が記述されたメタファイルとして、マルチキャストアドレスを記述できるように拡張されたMPDを取得する取得部として機能させ、
前記メタファイルとして前記拡張されたMPDは、
前記マルチキャストアドレス、
チューニングパラメータのデータ形式識別子、
および前記チューニングパラメータ
を含むサービスロケーション属性ファイルの取得先アドレスを含み、
前記受信部が、取得した前記メタファイルに基づいて、HTTP配信により供給されたセグメントファイルを受信し、
前記取得部が、取得した前記メタファイルに基づいて、前記サービスロケーション属性ファイルを取得し、
前記受信部が、
前記サービスロケーション属性ファイルに基づいて、セグメントファイルの属性情報を含む、マルチキャスト配信されるFDTを受信し、
受信した前記FDTに基づいてセグメントファイルを含む一方向ファイル転送プロトコルパケットを受信する
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、端末装置、受信方法、およびプログラムに関し、特に、コンテンツをインタネットを介してHTTP配信する場合の代替パスとして放送網を介した放送配信やインタネットを介したマルチキャスト配信を利用できるようにした端末装置、受信方法、およびプログラムに関する。

【背景技術】

【0002】

インタネットを介する動画配信に利用可能な国際標準化された動画配信プロトコルとして、Webサイトなどの閲覧と同様のHTTPを用いるMPEG-DASH（Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP、以下、DASHと称する）が知られている（例えば、非特許文献１を参照）。

【0003】

DASHでは適応型ストリーミング技術が実現されている。すなわち、コンテンツの供給側は、インタネットの通信環境や受信側の能力や状態に応じた、同一内容のコンテンツであって画質や画角サイズが異なる複数のストリームを準備可能であり、受信側はインタネットの通信環境や受信側の能力や状態に応じて最適なストリームを選択して取得、再生することが可能である。

【0004】

DASHにおいては、受信側がストリームを適応的に取得するために、供給側から受信側にMPD(Media Presentation Description)と称されるメタファイルが供給される。MPDには、チャンク化されたストリーミングデータ(Audio/Video/Subtitle等のメディアデータ)のアドレス(url情報)が記述されており、受信側は該url情報に基づいて所定のサーバにアクセスし、HTTP配信されるストリーミングデータを取得、再生することができる。

【0005】

図１は、DASHに基づいてコンテンツをストリーミング配信するコンテンツ供給システムの構成の一例を示している。

【0006】

供給側のコンテンツマネジメントサーバ１１は、受信側に供給するコンテンツを管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ１２に出力する。DASHセグメントストリーマ１２は、コンテンツのストリーミングデータを時間的にセグメントに分割して、それぞれをファイル化し、該ファイルのアドレスをDASH MPDサーバ１３に通知する。さらに、DASHセグメントストリーマ１２は、受信側のDASHクライアント１７からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルをHTTP配信する。

【0007】

DASH MPDサーバ１３は、セグメント化されたストリーミングデータのファイルのアドレスなどを記述したMPDを生成し、HTTPサーバとして、受信側のDASHクライアント１７からの要求に応じ、該MPDをHTTP配信する。

【0008】

インタネット上に存在するキャッシュサーバ１５は、DASHクライアント１７−１からの要求によりHTTP配信されたMPDやセグメント化されたストリーミングデータのファイルなどをキャッシングする。そして、キャッシングしているMPDやセグメント化されたストリーミングデータのファイルがDASHクライアント１７−２からDASH MPDサーバ１３またはDASHセグメントストリーマ１２に要求された場合、それらに代わってキャッシングしているMPDやセグメント化されたストリーミングデータをDASHクライアント１７−２にHTTP配信する。

【先行技術文献】

【非特許文献】

【0009】

【非特許文献1】「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEI ELECTRONICS 2012.3.19

【発明の概要】

【発明が解決しようとする課題】

【0010】

上述したように、DASHではHTTP配信を用いた適応的ストリーミング技術が実現されている。

【0011】

ところで、受信側が地上放送や衛星放送などで放送配信されるストリームや、インタネットによるマルチキャスト配信されたストリームも取得、再生できるのであれば、それらの配信パスも用いてストリームを配信するようにし、受信側で適応的にストリームを選択できるようにすることが望ましい。

【0012】

放送配信やインタネットによるマルチキャスト配信はQoS(保証帯域/遅延等)が保証されているので、HTTP配信よりも高品質のストリームを受信側で取得、再生できる場合がある。また、コスト的にも放送配信を利用した方がリーズナブルとなることがある。さらに、HTTP配信だけの場合、インタネットの通信環境(トラフィック)の急激な変化により所望の帯域を確保できない状況になったときにはストリーム再生が停止してしまうことになるが、そのようなときに、放送配信またはマルチキャスト配信のストリームに切り替えることができれば、その画質がHTTP配信のそれよりも低いものであったとしても、コンテンツの視聴を停止することなく継続したいというユーザの要求をかなえることができる。

【0013】

しかしながら、DASHにおいてはコンテンツのストリーミングデータをHTTP配信することのみを想定しており、放送配信やマルチキャスト配信は想定されていない。したがって、DASHにて規定されたMPDにも、放送配信やマルチキャスト配信されるストリームについて記述する術がない。

【0014】

本開示はこのような状況に鑑みてなされたものであり、DASHを用いた適応的ストリーミング技術を拡張し、放送配信とマルチキャスト配信も利用できるようにするものである。

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

【0015】

本開示の一側面である端末装置は、適応的ストリーミング技術に従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置から前記ストリーミングデータを受信する端末装置において、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルとして供給されたコンテンツのストリーミングデータを、HTTP配信またはマルチキャスト配信の少なくとも一方を介して受信し、前記マルチキャスト配信されるセグメントファイルを受信するための情報が記述されたメタファイルとして、マルチキャストアドレスを記述できるように拡張されたMPDを取得し、前記メタファイルとして前記拡張されたMPDは、前記マルチキャストアドレス、チューニングパラメータのデータ形式識別子、および前記チューニングパラメータを含むサービスロケーション属性ファイルの取得先アドレスを含み、取得した前記メタファイルに基づいて、HTTP配信により供給されたセグメントファイルを受信し、取得した前記メタファイルに基づいて、前記サービスロケーション属性ファイルを取得し、前記サービスロケーション属性ファイルに基づいて、セグメントファイルの属性情報を含む、マルチキャスト配信されるFDTを受信し、受信した前記FDTに基づいてセグメントファイルを含む一方向ファイル転送プロトコルパケットを受信するように構成される。

【0016】

本開示の一側面である受信方法は、適応的ストリーミング技術に従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置から前記ストリーミングデータを受信する端末装置であって、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルとして供給されたコンテンツのストリーミングデータを、HTTP配信またはマルチキャスト配信の少なくとも一方を介して受信する受信部と、前記マルチキャスト配信されるセグメントファイルを受信するための情報が記述されたメタファイルとして、マルチキャストアドレスを記述できるように拡張されたMPDを取得する取得部とを含む端末装置の受信方法であって、前記メタファイルとして前記拡張されたMPDは、前記マルチキャストアドレス、チューニングパラメータのデータ形式識別子、および前記チューニングパラメータを含むサービスロケーション属性ファイルの取得先アドレスを含み、前記受信部が、取得した前記メタファイルに基づいて、HTTP配信により供給されたセグメントファイルを受信し、前記取得部が、取得した前記メタファイルに基づいて、前記サービスロケーション属性ファイルを取得し、前記受信部が、前記サービスロケーション属性ファイルに基づいて、セグメントファイルの属性情報を含む、マルチキャスト配信されるFDTを受信し、受信した前記FDTに基づいてセグメントファイルを含む一方向ファイル転送プロトコルパケットを受信するステップを含む。

【0017】

本開示の一側面であるプログラムは、適応的ストリーミング技術に従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置から前記ストリーミングデータを受信する端末装置を制御するコンピュータを、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルとして供給されたコンテンツのストリーミングデータを、HTTP配信またはマルチキャスト配信の少なくとも一方を介して受信する受信部と、前記マルチキャスト配信されるセグメントファイルを受信するための情報が記述されたメタファイルとして、マルチキャストアドレスを記述できるように拡張されたMPDを取得する取得部として機能させ、前記メタファイルとして前記拡張されたMPDは、前記マルチキャストアドレス、チューニングパラメータのデータ形式識別子、および前記チューニングパラメータを含むサービスロケーション属性ファイルの取得先アドレスを含み、前記受信部が、取得した前記メタファイルに基づいて、HTTP配信により供給されたセグメントファイルを受信し、前記取得部が、取得した前記メタファイルに基づいて、前記サービスロケーション属性ファイルを取得し、前記受信部が、前記サービスロケーション属性ファイルに基づいて、セグメントファイルの属性情報を含む、マルチキャスト配信されるFDTを受信し、受信した前記FDTに基づいてセグメントファイルを含む一方向ファイル転送プロトコルパケットを受信するように機能させる。

【0018】

本開示の一側面においては、適応的ストリーミング技術に従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置から前記ストリーミングデータを受信する端末装置であって、前記ストリーミングデータがセグメント毎にファイル化され、その結果得られるセグメントファイルとして供給されたコンテンツのストリーミングデータが、HTTP配信またはマルチキャスト配信の少なくとも一方を介して受信され、前記マルチキャスト配信されるセグメントファイルを受信するための情報が記述されたメタファイルとして、マルチキャストアドレスを記述できるように拡張されたMPDが取得され、前記メタファイルとして前記拡張されたMPDには、前記マルチキャストアドレス、チューニングパラメータのデータ形式識別子、および前記チューニングパラメータを含むサービスロケーション属性ファイルの取得先アドレスが含まれ、取得した前記メタファイルに基づいて、HTTP配信により供給されたセグメントファイルが受信され、取得された前記メタファイルに基づいて、前記サービスロケーション属性ファイルが取得され、前記サービスロケーション属性ファイルに基づいて、セグメントファイルの属性情報を含む、マルチキャスト配信されるFDTが受信され、受信された前記FDTに基づいてセグメントファイルを含む一方向ファイル転送プロトコルパケットが受信される。

【発明の効果】

【0035】

本開示の一側面によれば、DASHを用いた適応的ストリーミング技術を拡張し、放送配信とマルチキャスト配信も利用することができる。

【図面の簡単な説明】

【0036】

【図1】DASHを利用する従来のコンテンツ供給システムの構成の一例を示すブロック図である。

【図2】本開示を適用したコンテンツ供給システムの構成例を示すブロック図である。

【図3】コンテンツの時間的区切りを説明する図である。

【図4】MPDの構成を示す図である。

【図5】MPDにおけるPeriod以下の階層構造を示す図である。

【図6】時間軸上にMPDの構成を並べた図である。

【図7】MPDのRepresentation以下の詳細な構造を示す図である。

【図8】Representation以下の構造をXML形式で記述した一例を示す図である。

【図9】serviceLocationAttributeUrl属性により指定されるServiceLocation要素のデータ構造を示す図である。

【図10】チューニングパラメータの一例を示す図である。

【図11】serviceLocationAttributeUrl属性により指定されるServiceLocation要素のXML Schemaの一例を示す図である。

【図12】拡張したMPDの構造を示す図である。

【図13】FLUTEプロトコルの階層構造を示す図である。

【図14】FDTのデータ構造を示す図である。

【図15】拡張したFDTのデータ構造を示す図である。

【図16】コンテンツ供給装置の動作を説明するフローチャートである。

【図17】コンテンツ供給システムの動作を説明するフローチャートである。

【図18】コンピュータの構成例を示すブロック図である。

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

【0037】

以下、本開示を実施するための最良の形態（以下、実施の形態と称する）について、図面を参照しながら詳細に説明する。

【0038】

［コンテンツ供給システムの構成例］
本開示の実施の形態であるコンテンツ供給システムは、HTTP配信、放送配信、およびマルチキャスト配信を利用したコンテンツの適応的ストリーミングを実現するものである。

【0039】

具体的には、DASHにおけるMPDを拡張して、放送配信とマルチキャスト配信のチューニング用のパラメータを記述できるようにするとともに、放送配信およびマルチキャスト配信で適用される一方向ファイル転送プロトコルであるFLUTE(File Delivery over Unidirectional Transport)におけるファイル属性が記述されるFDT(File Delivery Table)を拡張する。

【0040】

図２は、本開示の実施の形態であるコンテンツ供給システムの構成例を示している。

【0041】

このコンテンツ供給システム２０は、コンテンツ供給装置３０および端末装置４０から構成される。

【0042】

コンテンツ供給装置３０は、コンテンツマネジメントサーバ３１、DASHセグメントストリーマ３２、DASH MPDサーバ３３、FLUTEサーバ３４、および放送配信サーバ３５を有する。

【0043】

コンテンツマネジメントサーバ３１は、受信側の端末装置４０に供給するコンテンツ（ライブ放送コンテンツを含む）を管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ３２に出力する。

【0044】

DASHセグメントストリーマ３２は、図３に示されるように、コンテンツのストリーミングデータを時間的にピリオド(period)に区切り、さらにセグメント(segment)に分割して、それぞれをファイル化し、該ファイルのアドレスをDASH MPDサーバ３３およびFLUTEサーバ３４に通知する。また、DASHセグメントストリーマ３２は、セグメント化されたストリーミングデータのファイルをFLUTEサーバ３４に供給する。さらに、DASHセグメントストリーマ３２は、端末装置４０からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルを、インタネット１を介してHTTP配信する。

【0045】

DASH MPDサーバ３３は、セグメント化されたストリーミングデータのファイルがHTTP配信、放送配信、またはマルチキャスト配信される際のアドレスなどを記述したMPDを生成し、HTTPサーバとして、端末装置４０からの要求に応じ、該MPDを、インタネット１を介してHTTP配信する。また、DASH MPDサーバ３３は、生成したMPDをFLUTEサーバ３４に供給する。なお、生成されたMPDは、DASH MPDサーバ３３からHTTP配信する他、FLUTEサーバ３４からマルチキャスト配信したり、放送配信サーバ３５から放送配信したりするようにしてもよい。

【0046】

FLUTEサーバ３４は、セグメント化されたストリーミングデータのファイルを格納したFLUTEパケット（ALC(Asynchronous Layered Coding)パケットなど）を生成するとともに、MPDに基づいてFDTを生成し、FLUTEパケットおよびFDTをFLUTEプロトコルに従い、インタネット１を介してマルチキャスト配信する。また、FLUTEサーバ３４は、FLUTEパケットおよびFDTを放送配信サーバ３５に供給する。

【0047】

放送配信サーバ３５は、FLUTEサーバ３４から供給されるFLUTEパケットおよびFDTを、放送網２を介して放送配信する。なお、放送網２には、地上放送、衛星放送、CATV網、携帯通信網などが含まれるものとする。以下、本明細書においては、マルチキャスト配信の用語は、放送網２を介する放送配信を含むものとする。

【0048】

インタネット１上に設けられたキャッシュサーバ３６は、インタネット１を介してHTTP配信またマルチキャスト配信されたMPD、セグメント化されたストリーミングデータのファイル、FDT、およびFLUTEパケットなどをキャッシングする。そして、キャッシングしているMPD等がDASH MPDサーバ３３に要求された場合、それらに代わってキャッシングしているMPDなどを要求元にHTTP配信する。

【0049】

［MPDの概要］
次に、MPDの概要について説明する。

【0050】

図４はMPDのデータ構成を示し、図５はMPDにおけるPeriod以下の階層構造を示している。

【0051】

MPDには、コンテンツ（Media)に関する情報がPeriod毎に区分され、各Periodには同一内容であってビットレートなどのストリーム属性の異なるストリーミングデータに関する情報からなる複数のRepresentationが用意されている。Representationには、Periodをさらに時間的に分割したSegmentに関する情報が格納されている。

【0052】

図６は、時間軸上にMPDの構造を並べた状態を示している。同図から明らかなように、同一のSegmentに対して複数のRepresentationが存在しているので、これらのうちのいずれかを端末装置４０は適応的に選択することにより、通信環境や自己のデコード能力などに応じて適切なストリームデータを取得、再生することができる。

【0053】

図７は、MPDのRepresentation以下の構造を詳細に示している。Representationには、セグメント化されたストリームデータが格納されたファイルのアドレスが記述される。具体的には、セグメント化された複数のストリームデータがそれぞれ個別にファイル化されている場合には、各ファイルのアドレス（url情報）のシーケンスが記述される。また、セグメント化された複数のストリームデータがまとめてファイル化されている場合には、該ファイルのアドレス（Base URL）と、該ファイルにおける各セグメントの範囲(mediaRange)のシーケンスが記述される。なお、図７には、後者の場合が示されている。

【0054】

図８は、図７に示されたRepresentation以下の構造をXML形式で記述した一例を示している。

【0055】

同図においては、MPD/Period/AdaptationSet/Representation/BaseURLに記述されている”http://example.com/counter-10mn_avc_dash.mp4”が、セグメント化されたストリームデータがまとめてファイル化されたファイルのアドレスを示している。

【0056】

また、MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeが該ファイルにおける、セグメント化されたストリームデータのバイト範囲を示している。

【0057】

例えば、MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange=”795-83596”は、該ファイルにおけるバイト範囲795バイト目から83596バイト目までが１つ目のセグメント化されたストリームデータであることを示している。

【0058】

したがって、端末装置４０がセグメント化されたストリームデータを取得する際には、ファイルのurlを”http://example.com/counter-10mn_avc_dash.mp4”とともに、そのRangeヘッダにmediaRangeを指定してHTTPリクエストを発行すればよい。

【0059】

例えば１つ目のセグメント化されたストリームデータを取得するためには、ファイルのurl”http://example.com/counter-10mn_avc_dash.mp4”とともに、mediaRange”795-83596”を指定すればよい。この際のHTTPリクエストは以下のとおりとなる。
GET /counter-10mn_avc_dash.mp4 HTTP/1.1
Host: example.com
Range: bytes=795-83596

【0060】

また例えば２つ目のセグメント化されたストリームデータを取得するためには、ファイルのurl”http://example.com/server/counter-10mn_aacdash.mp4”とともに、mediaRange”83597-166046”を指定すればよい。この際のHTTPリクエストは以下のとおりとなる。
GET /counter-10mn_avc_dash.mp4 HTTP/1.1
Host: example.com
Range: bytes=83597-166046

【0061】

［MPDの拡張］
本実施の形態においては、セグメント化されたストリームデータを放送配信とマルチキャスト配信のIPマルチキャストストリーム上のFLUTEで転送されるファイルに格納するので、IPマルチキャストストリームのアドレスを記述できるようにMPDを拡張する。

【0062】

具体的には、図９に示されるような、セグメントファイル群が転送されるIPマルチキャストストリームを受信するための新たな要素としてチューニングパラメータ(DeliverySystemAttributes)およびIPマルチキャストアドレス(IPMulticastAddress)が記述されたServiceLocation要素を導入する。

【0063】

DeliverySystemAttributesのDeliverySystemIdentifierには、放送配信またはマルチキャスト配信にて採用されているチューニングパラメータのデータ構造のフォーマット識別子が記述される。例えば、欧州にて採用されている地上放送による放送配信の場合には、”ID_DVB_T”が記述され、衛星放送に放送配信の場合には、”ID_DVB_S”が記述される。

【0064】

DeliverySystemAttributesのDeliverySystemDescriptorには、DeliverySystemIdentifierで識別される放送配信またはマルチキャスト配信にて規定されたチューニングパラメータのデータ構造(パラメタ自体)が記述される。図１０は、欧州にて採用されている地上放送による放送配信に対応するチューニングパラメータのデータ構造の例である。なお、実際には、上記フォーマットに則ったバイト列をbase64等により文字列に変換してDeliverySystemDescriptorに記述する。

【0065】

図１１は、serviceLocationAttributeUrl属性により指定されるServiceLocationファイルのXML schemaの一例を示している。

【0066】

図１２は、拡張したMPDの構造を示している。すなわち、拡張したMPDのRepresentationのBaseURLは、ServiceLocation要素をルート要素として格納するserviceLocationAttributeファイルのurlを含むserviceLocationAttribute Url属性が記述できるよう拡張されている。

【0067】

［FDTの拡張］
次に、FDTの拡張について説明する。上述したServiceLocation/DeliverySystem要素に格納される情報によりチューニングされたMPEG2-TSストリーム上に転送されるIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリーム上には、FLUTEプロトコルによりファイル群が運ばれる。

【0068】

図１３はFLUTEプロトコルの階層を示している。なお同図では、上述したDeliverySystemAttributesで指定する対象がMPEG2-TSパケットであり、これがULE(Unidirectional Light-weight Encapsulation)またはMPE(Multi Protocol Encapsulation)によりカプセル化されているIPパケット上にFLUTEパケットが運ばれる場合を示している。

【0069】

FLUTEプロトコルでは、FLUTEパケットにより運ばれるファイルのそれぞれに対してファイル属性が記述できる。ファイル属性はFDT(FDT-Instance要素)に記述される。

【0070】

図１４は、現在規定されているFDTのデータ構造を示している。FDTに必須のファイル属性は以下の３種である。
FDT-Instance/Expires(FDTの有効期限)
FDT-Instance/File/Content-Location(転送するファイルのURL)
FDT-Instance/File/TOI(Transport Object Identifier、FLUTE転送する上で必須の構成チャンク群の識別子)

【0071】

FLUTEプロトコルでは、同一のTOIを有する全てのファイルが受信された段階で初めて、Content-LocationのURLにより指定されるファイルとしてそれらに対してアクセスが可能となる。したがって、映画などのVoDコンテンツのように再生時間が長く１つのファイルのサイズが非常に大きい場合には、そのファイル全体が受信側で再構成されてアクセスできるようになるまでに、ある程度の時間が必要となる。

【0072】

これに対して、DASHを利用したストリーミングにおいては、対象のVoDコンテンツのファイルのサイズが大きくても、個々のHTTPリクエストのmediaRange指定によりファイルの一部をセグメント単位で取得、再生することができる。したがって、放送配信またはマルチキャスト配信のIPマルチキャストストリームによりFLUTE転送されるファイルについても同様にセグメントの単位で取得、再生できるようにすることが望ましい。

【0073】

ただし、現在規定されているFDTのContent-Location要素では、MPDのBaseURL＋SegmentURL mediaRangeのシーケンスのように、ファイルの一部を表現することができない。そこで、FDTについてもファイルの一部を表現できるように拡張する。

【0074】

図１５は、拡張したFDTのデータ構造を示している。すなわち、FDTに対して、Content-Locationと、さらにそのContent-Locationのurlで指定されるファイルの中のバイトレンジが指定できるように新たにrange属性を導入する。range属性のシンタクスには、range-specifier(RFC2616.section.14.35.1)の定義を適用する。range属性には、MPDのPeriod/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeをそのまま流用することができる。

【0075】

このようにFDTを拡張すれば、端末装置４０が取得、再生するストリーミングデータを、HTTP配信、放送配信、またはマルチキャスト配信の間で適応的、かつ、アドホックに切り替えることが可能となる。また、コンテンツのストリーミングサービスを運用する上での柔軟性を確保することが可能となる。

【0076】

［コンテンツ供給システム２０の動作］
次に、コンテンツ供給システム２０の動作について説明する。図１６は、コンテンツ供給システム２０のコンテンツ供給装置３０の動作を説明するフローチャートである。

【0077】

コンテンツマネジメントサーバ３１は、ステップＳ１として、受信側の端末装置４０に供給する、同一内容のコンテンツのビットレートなどが異なる複数のストリーミングデータをDASHセグメントストリーマ３２に出力する。また、ステップＳ２として、コンテンツのメタデータをDASH MPDサーバ３３に通知する。

【0078】

ステップＳ１１において、DASHセグメントストリーマ３２は、コンテンツのストリーミングデータを時間的にピリオドに区切り、さらにセグメントに分割して、DASHストリームセグメントを生成し、それぞれをファイル化する。また、DASHセグメントストリーマ３２は、DASHストリームセグメントのファイルをFLUTEサーバ３４に供給する。

【0079】

ステップＳ１２において、DASHセグメントストリーマ３２は、DASHストリームセグメントのファイルのアドレス（url情報）をDASH MPDサーバ３３およびFLUTEサーバ３４に通知する。この後、ステップＳ１３において、DASHセグメントストリーマ３２は、DASHストリームセグメントのファイルのインタネット１を介するHTTP配信を開始する。

【0080】

DASHストリームセグメントのファイルのアドレスの通知を受けたDASH MPDサーバ３３は、ステップＳ２１において、MPDを生成し、ステップＳ２２において、該MPDをFLUTEサーバ３４に供給し、そのマルチキャスト配信を依頼する。この後、ステップＳ２３において、DASH MPDサーバ３３は、生成したMPDのインタネット１を介するHTTP配信を開始する。

【0081】

MPDの供給を受けたFLUTEサーバ３４は、ステップＳ３１において、MPDに基づいてFDTを生成するとともに、DASHセグメントストリーマ３２からDASHストリームセグメントのファイルを格納したFLUTEパケットを生成する。ステップＳ３２において、FLUTEサーバ３４は、生成したFDTとFLUTEパケットを放送配信サーバ３５に供給し、それらの放送配信を依頼する。この後、所定のタイミングにおいて、ステップＳ３３として、FLUTEサーバ３４は、FDTとFLUTEパケットのインタネット１を介するマルチキャスト配信を開始する。

【0082】

FDTとFLUTEパケットの供給を受けた放送配信サーバ３５は、所定のタイミングにおいてステップＳ４１として、FLUTEパケットおよびFDTを、放送網２を介して放送配信する。以上で、コンテンツ供給システム２０のコンテンツ供給装置３０の動作説明を終了する。

【0083】

次に、図１７は、端末装置４０がコンテンツを受信、再生するまで動作を説明するフローチャートである。

【0084】

コンテンツを受信、再生しようとする端末装置４０は、ステップＳ５１において、インタネット１を介してDASH MPDサーバ３３にアクセスし、MPDのHTTP配信を要求する。この要求に応じ、ステップＳ６１において、DASH MPDサーバ３３は、インタネット１を介して端末装置４０にMPDをHTTP配信する。

【0085】

なお、インタネット１上のキャッシュサーバ３６が該MPDを保持している場合には、DASH MPDサーバ３３に代わってキャッシュサーバ３６が端末装置４０に該MPDをHTTP配信することになる。

【0086】

また、MPDがインタネット１を介してマルチキャスト配信されたり、放送網２を介して放送配信されたりする場合もあり、それを受信、取得するときにはステップＳ５１の処理は不要となる。

【0087】

MPDを取得した端末装置４０は、ステップＳ５２において、MPDのBaseURLとmediaRangeにもとづいてHTTPリクエストを発行して、DASHセグメントストリーマ３２にDASHストリームセグメントのファイルのHTTP配信を要求する。この要求に応じ、ステップＳ７１において、DASHセグメントストリーマ３２は、対応するファイルをインタネット１を介して端末装置４０にHTTP配信する。なお、インタネット１上のキャッシュサーバ３６が該ファイルを保持している場合には、DASHセグメントストリーマ３２に代わってキャッシュサーバ３６が端末装置４０に該ファイルをHTTP配信することになる。

【0088】

ステップＳ５３において、端末装置４０は、HTTP配信された該ファイルを受信、再生する。この後、例えばインタネット１の通信環境が悪化したりした場合、端末装置４０は、受信するストリームを適応的に切り替えることができる。具体的には、ステップＳ５４として、例えば、放送配信サーバ３５がステップＳ８１として放送配信しているDASHストリームセグメントのファイルを受信、再生することができる。また、この後、HTTP配信されるファイルの受信、再生に戻ることもできる。

【0089】

なお、DASHセグメントストリーマ３２からHTTP配信される、よりビットのレートが低いストリームを受信、再生するように切替えたり、FLUTEサーバ３４がインタネット１を介してマルチキャスト配信するストリームに切替えたりすることも可能である。

【0090】

以上で、端末装置４０の動作説明を終了する。

【0091】

ところで、上述した一連の処理を実行するコンテンツ供給装置３０、および端末装置４０は、それぞれをハードウェアにより構成する他、コンピュータがソフトウェアを実行することにより実現することもできる。このコンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

【0092】

図１８は、上述したコンピュータのハードウェアの構成例を示すブロック図である。

【0093】

このコンピュータ１００において、CPU（Central Processing Unit）１０１，ROM（Read Only Memory）１０２，RAM（Random Access Memory）１０３は、バス１０４により相互に接続されている。

【0094】

バス１０４には、さらに、入出力インタフェース１０５が接続されている。入出力インタフェース１０５には、入力部１０６、出力部１０７、記憶部１０８、通信部１０９、およびドライブ１１０が接続されている。

【0095】

入力部１０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１０７は、ディスプレイ、スピーカなどよりなる。記憶部１０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１０９は、ネットワークインタフェースなどよりなる。ドライブ１１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１１１を駆動する。

【0096】

以上のように構成されるコンピュータ１００では、CPU１０１が、例えば、記憶部１０８に記憶されているプログラムを、入出力インタフェース１０５およびバス１０４を介して、RAM１０３にロードして実行することにより、上述した一連の処理が行われる。

【0097】

コンピュータ１００（CPU１０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インタネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

【0098】

コンピュータ１００では、プログラムは、リムーバブルメディア１１１をドライブ１１０に装着することにより、入出力インタフェース１０５を介して、記憶部１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１０９で受信し、記憶部１０８にインストールすることができる。その他、プログラムは、ROM１０２や記憶部１０８に、あらかじめインストールしておくことができる。

【0099】

なお、コンピュータ１００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであってもよい。

【0100】

なお、本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。

【符号の説明】

【0101】

２０ コンテンツ供給システム， ３０ コンテンツ供給装置， ３１ コンテンツマネジメントサーバ， ３２ DASHセグメントストリーマ， ３３ DASH MPDサーバ， ３４ FLUTEサーバ， ３５ 放送配信サーバ， 端末装置４０， １００ コンピュータ， １０１ CPU

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】