特許 6457931 コンテンツ供給装置、コンテンツ供給方法、コンテンツ受信装置、コンテンツ受信方法、プログラム、およびコンテンツ供給システム

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

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

(11)【特許番号】6457931

(24)【登録日】2018年12月28日

(45)【発行日】2019年1月23日

(54)【発明の名称】コンテンツ供給装置、コンテンツ供給方法、コンテンツ受信装置、コンテンツ受信方法、プログラム、およびコンテンツ供給システム

(51)【国際特許分類】

   H04N 21/238 20110101AFI20190110BHJP

   H04N 21/235 20110101ALI20190110BHJP

   H04N 21/438 20110101ALI20190110BHJP

   H04N 21/435 20110101ALI20190110BHJP

【ＦＩ】

   H04N21/238

   H04N21/235

   H04N21/438

   H04N21/435

【請求項の数】16

【全頁数】25

(21)【出願番号】特願2015-506701(P2015-506701)

(86)(22)【出願日】2014年3月7日

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

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

(87)【国際公開日】20140925

【審査請求日】2017年3月2日

(31)【優先権主張番号】特願2013-56759(P2013-56759)

(32)【優先日】2013年3月19日

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

(73)【特許権者】

【識別番号】316009762

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

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

(74)【代理人】

【識別番号】100121131

【弁理士】

【氏名又は名称】西川 孝

(74)【代理人】

【識別番号】100082131

【弁理士】

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

(72)【発明者】

【氏名】山岸 靖明

【審査官】 後藤 嘉宏

(56)【参考文献】

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

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

【文献】 Guidelines for Progressive Download Using the Adaptive Streaming Profile, [online]，２０１０年 ６月１６日，[retrieved on 2015.03.31], Retrieved from the Internet: <URL: http://www.3gpp.org/ftp/TSG_SA/WG4_CODEC/TSGS4_59/Docs/S4-100452.zip(S4-100452.doc)>

【文献】 Schulzrinne, et al.，RTP: A Transport Protocol for Real-Time Applications，２００３年 ７月，p.29-34，ＵＲＬ，http://tools.ietf.org/pdf/rfc3550.pdf

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

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

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

【請求項1】

MPEG-DASHに従ってコンテンツのストリーミングデータを供給するように構成されたコンテンツ供給装置において、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
を備え、
前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されている
コンテンツ供給装置。

【請求項2】

前記HTTPによりユニキャスト送信される前記セグメントファイルを受信するための情報を記述したMPDを生成するMPD生成部をさらに備え、
前記メタファイル生成部は、前記MPDを書き換えることにより前記メタファイルを生成する
請求項１に記載のコンテンツ供給装置。

【請求項3】

前記メタファイル生成部は、前記MPDに記述されている、HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲を示すmediaRange属性の後に、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間を示すrtspRange属性を追記することにより、前記メタファイルを生成するように構成される
請求項２に記載のコンテンツ供給装置。

【請求項4】

前記RTP送信部は、前記HTTP送信部からHTTPによりユニキャスト送信された前記セグメントファイルをRTPパケットに乗せ変えるプロトコル変換を施して、マルチキャストまたはブロードキャストの少なくとも一方で送信するように構成される
請求項２または３に記載のコンテンツ供給装置。

【請求項5】

前記RTP送信部は、さらに、RTCPによりRTPタイムスタンプと前記RTPタイムスタンプに対応するNTPタイムスタンプを送信するように構成されている
請求項２から４のいずれかに記載のコンテンツ供給装置。

【請求項6】

MPEG-DASHに従ってコンテンツのストリーミングデータを供給するように構成されたコンテンツ供給装置のコンテンツ供給方法において、
前記コンテンツ供給装置による、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信ステップと、
前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信ステップと、
HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルを生成し、受信側に供給するメタファイル生成ステップと
を含み、
前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されている
コンテンツ供給方法。

【請求項7】

MPEG-DASHに従ってコンテンツのストリーミングデータを供給するように構成されたコンピュータを、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルを生成し、受信側に供給するメタファイル生成部として機能させ、
前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されている
して機能させるプログラム。

【請求項8】

MPEG-DASHに従ってコンテンツのストリーミングデータを供給するように構成されたコンテンツ供給装置と、前記ストリーミングデータを受信するように構成されたコンテンツ受信装置とから成るコンテンツ供給システムにおいて、
前記コンテンツ供給装置は、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルを生成し、受信側に供給するメタファイル生成部とを備え、
前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されており、
前記コンテンツ受信装置は、
取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信された前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信された前記セグメントファイルとを切り替えて受信、再生するように構成される
コンテンツ供給システム。

【請求項9】

MPEG-DASHに従って供給されるコンテンツのストリーミングデータを受信するように構成されたコンテンツ受信装置において、
HTTPによりユニキャスト送信されたセグメントファイルを受信するように構成されたHTTP受信部と、
RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されたセグメントファイルを受信するように構成されたRTP受信部と、
HTTPによりユニキャスト送信されるセグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されるセグメントファイルにおけるセグメント毎の配信時間とが対応付けて記述されているメタファイルを取得するように構成されたメタファイル取得部と、
取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信されたセグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されたセグメントファイルとを切り替えて受信、再生させるように構成された切り替え部とを備え、
前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されており、
前記セグメントファイルは、前記コンテンツのストリーミングデータがセグメント毎にファイル化されたものである
コンテンツ受信装置。

【請求項10】

前記メタファイル取得部は、MPDに記述されている、HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲を示すmediaRange属性の後に、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間を示すrtspRange属性が記述されている前記メタファイルを取得するように構成される
請求項９に記載のコンテンツ受信装置。

【請求項11】

前記RTP受信部は、さらに、RTCPにより送信された、RTPタイムスタンプと前記RTPタイムスタンプに対応するNTPタイムスタンプを受信するように構成される
請求項９または１０に記載のコンテンツ受信装置。

【請求項12】

テレビジョン放送網を介して放送されるテレビジョンコンテンツを受信するように構成されたテレビジョンコンテンツ受信部をさらに備える
請求項９から１１のいずれかに記載のコンテンツ受信装置。

【請求項13】

MPEG-DASHに従って供給されるコンテンツのストリーミングデータを受信するように構成されたコンテンツ受信装置のコンテンツ受信方法において、
HTTPによりユニキャスト送信されるセグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されるセグメントファイルにおけるセグメント毎の配信時間とが対応付けて記述されているメタファイルを取得するメタファイル取得ステップと、
取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信された前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信された前記セグメントファイルとを切り替えて受信、再生する切り替えステップと
を含み、
前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されており、
前記セグメントファイルは、前記コンテンツのストリーミングデータがセグメント毎にファイル化されたものである
コンテンツ受信方法。

【請求項14】

前記メタファイル取得ステップは、MPDに記述されている、HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲を示すmediaRange属性の後に、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間を示すrtspRange属性が記述されている前記メタファイルを取得する
請求項１３に記載のコンテンツ受信方法。

【請求項15】

RTCPにより送信された、RTPタイムスタンプと前記RTPタイムスタンプに対応するNTPタイムスタンプを受信する受信ステップを
さらに含む請求項１３または１４に記載のコンテンツ受信方法。

【請求項16】

MPEG-DASHに従って供給されるコンテンツのストリーミングデータを受信するように構成されたコンピュータを、
HTTPによりユニキャスト送信されたセグメントファイルを受信するように構成されたHTTP受信部と、
RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されたセグメントファイルを受信するように構成されたRTP受信部と、
HTTPによりユニキャスト送信されるセグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されるセグメントファイルにおけるセグメント毎の配信時間とが対応付けて記述されているメタファイルを取得するように構成されたメタファイル取得部と、
取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信されたセグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されたセグメントファイルとを切り替えて受信、再生させるように構成された切り替え部として機能させ、
前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されており、
前記セグメントファイルは、前記コンテンツのストリーミングデータがセグメント毎にファイル化されたものである
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、コンテンツ供給装置、コンテンツ供給方法、コンテンツ受信装置、コンテンツ受信方法、プログラム、およびコンテンツ供給システムに関し、特に、コンテンツをHTTP(Hyper Text Transfer Protocol)によりインターネットを介してユニキャスト送信する場合の代替パスとして、RTP(Real-time Transport Protocol)により放送網を介してマルチキャスト送信またはブロードキャスト送信できるようにしたコンテンツ供給装置、コンテンツ供給方法、コンテンツ受信装置、コンテンツ受信方法、プログラム、およびコンテンツ供給システムに関する。

【背景技術】

【0002】

近年、インターネットを介するストリーミングサービスの主流がOTT-V(Over The Top Video)となっており、その基盤技術として、Webサイトなどの閲覧と同様に供給側と受信側がpoint to pointで接続される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 MPDサーバ２３、並びにコンテンツを視聴する側のDASHクライアント３０から構成される。なお、図示は省略するが、DASHクライアント３０は多数存在するものとする。

【0007】

コンテンツマネジメントサーバ２１は、受信側に供給するコンテンツを管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ２２に出力する。

【0008】

DASHセグメントストリーマ２２は、コンテンツのストリーミングデータを時間的にセグメントに分割してそれぞれをファイル化して保持し、そのアドレスをDASH MPDサーバ２３に通知する。さらに、DASHセグメントストリーマ２２は、受信側のDASHクライアント３０からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルを、インターネット１１を介してDASHクライアント３０に送信する。

【0009】

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

【0010】

受信側のDASHクライアント３０は、コンテンツを取得、再生するものであり、DASH MPDサーバ２３から取得するMPDに基づいてDASHセグメントストリーマ２２にアクセスし、セグメント化されたストリーミングデータのファイルを取得、再生する。

【0011】

なお、インターネット１１上にキャッシュサーバを設け、HTTP送信されるMPDやセグメント化されたストリーミングデータのファイルなどキャッシングし、DASHセグメントストリーマ２２やDASH MPDサーバ２３の動作を代行させることもある。

【先行技術文献】

【非特許文献】

【0012】

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

【発明の概要】

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

【0013】

上述したように、DASHではHTTPによるユニキャスト送信によりコンテンツを供給する適応的ストリーミング技術が実現されている。

【0014】

ただし、数多くのDASHクライアント３０が同時に取得、再生する可能性がある、リアルタイムのスポーツ中継等のコンテンツをDASHにより供給する場合、HTTPを用いているために、CDN(Contents Delivery Network)のサポートが必要となる。しかしながら、CDNのサポートを受けるとしても、そのコスト的な制約から既存の放送配信に匹敵する程のスケーラビリティを求めることはできない。

【0015】

ところで、コンテンツを同時に多数の受信側に供給するには、テレビジョン放送網やモバイルネットワークを介したマルチキャストベアラやブロードキャストベアラを利用する方法があり、これには一般的にRTPが用いられる。

【0016】

よって、コンテンツの受信側がマルチキャスト送信やブロードキャスト送信に対応可能であれば、DASHにおける代替パスとしてそれらを用い、受信側で適応的にストリームを選択できるようにすることが望ましい。

【0017】

しかしながら、現状のDASHの仕様においては、コンテンツのストリーミングデータをHTTP送信することのみを想定しており、マルチキャストベアラやブロードキャストベアラの利用は想定していない。したがって、DASHのMPDには、HTTPによりユニキャスト送信されるDASHセグメントと、そのセグメント区間に対応するマルチキャストベアラまたはブロードキャストベアラ上のRTPによってストリーミングされるコンテンツ区間との対応関係を記述することができない。よって、コンテンツのユニキャスト送信とマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングの実現が困難である。

【0018】

本開示はこのような状況に鑑みてなされたものであり、コンテンツのHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングを実現できるようにするものである。

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

【0019】

本開示の第１の側面であるコンテンツ供給装置は、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置において、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルを生成し、受信側に供給するメタファイル生成部とを備え、前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されている。

【0020】

本開示の第１の側面であるコンテンツ供給装置は、前記HTTPによりユニキャスト送信される前記セグメントファイルを受信するための情報を記述したMPDを生成するMPD生成部をさらに備えることができ、前記メタファイル生成部は、前記MPDを書き換えることにより前記メタファイルを生成することができる。

【0021】

前記メタファイル生成部は、前記MPDに記述されている、HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲を示すmediaRange属性の後に、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間を示すrtspRange属性を追記することにより、前記メタファイルを生成することができる。

【0022】

前記RTP送信部は、前記HTTP送信部からHTTPによりユニキャスト送信された前記セグメントファイルをRTPパケットに乗せ変えるプロトコル変換を施して、マルチキャストまたはブロードキャストの少なくとも一方で送信することができる。

【0023】

前記RTP送信部は、さらに、RTCPによりRTPタイムスタンプと前記RTPタイムスタンプに対応するNTPタイムスタンプを送信することができる。

【0024】

本開示の第１の側面であるコンテンツ供給方法は、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、前記コンテンツ供給装置による、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信ステップと、前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信ステップと、HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルを生成し、受信側に供給するメタファイル生成ステップとを含み、前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されている。

【0025】

本開示の第１の側面であるプログラムは、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンピュータを、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルを生成し、受信側に供給するメタファイル生成部として機能させ、前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されている。

【0026】

本開示の第１の側面においては、ストリーミングデータがセグメント毎にファイル化され、その結果得られるセグメントファイルがHTTPによりユニキャスト送信され、前記セグメントファイルがRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される。さらに、HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルが生成されて受信側に供給される。前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されている。

【0027】

本開示の第２の側面であるコンテンツ供給システムは、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信するクライアント装置とから成るコンテンツ供給システムにおいて、前記コンテンツ供給装置が、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルを生成し、受信側に供給するメタファイル生成部とを備え、前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されている。また、前記クライアント装置が、取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信された前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信された前記セグメントファイルとを切り替えて受信、再生する。

【0028】

本開示の第２の側面においては、コンテンツ供給装置により、ストリーミングデータがセグメント毎にファイル化され、その結果得られるセグメントファイルがHTTPによりユニキャスト送信され、前記セグメントファイルがRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される。さらに、HTTPによりユニキャスト送信される前記セグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルが生成されて受信側に供給される。前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されている。また、クライアント装置により、取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとが切り替えて受信、再生される。
本開示の第３の側面であるコンテンツ受信装置は、MPEG-DASHに従って供給されるコンテンツのストリーミングデータを受信するように構成されたコンテンツ受信装置において、HTTPによりユニキャスト送信されたセグメントファイルを受信するように構成されたHTTP受信部と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されたセグメントファイルを受信するように構成されたRTP受信部と、HTTPによりユニキャスト送信されるセグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されるセグメントファイルにおけるセグメント毎の配信時間とが対応付けて記述されているメタファイルを取得するように構成されたメタファイル取得部と、取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信されたセグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されたセグメントファイルとを切り替えて受信、再生させるように構成された切り替え部とを備え、前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されており、前記セグメントファイルは、前記コンテンツのストリーミングデータがセグメント毎にファイル化されたものである。
本開示の第３の側面であるコンテンツ受信方法は、MPEG-DASHに従って供給されるコンテンツのストリーミングデータを受信するように構成されたコンテンツ受信装置のコンテンツ受信方法において、HTTPによりユニキャスト送信されるセグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されるセグメントファイルにおけるセグメント毎の配信時間とが対応付けて記述されているメタファイルを取得するメタファイル取得ステップと、取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信された前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信された前記セグメントファイルとを切り替えて受信、再生する切り替えステップとを含み、前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されており、前記セグメントファイルは、前記コンテンツのストリーミングデータがセグメント毎にファイル化されたものである。
本開示の第３の側面であるプログラムは、MPEG-DASHに従って供給されるコンテンツのストリーミングデータを受信するように構成されたコンピュータを、HTTPによりユニキャスト送信されたセグメントファイルを受信するように構成されたHTTP受信部と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されたセグメントファイルを受信するように構成されたRTP受信部と、HTTPによりユニキャスト送信されるセグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されるセグメントファイルにおけるセグメント毎の配信時間とが対応付けて記述されているメタファイルを取得するように構成されたメタファイル取得部と、取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信されたセグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されたセグメントファイルとを切り替えて受信、再生させるように構成された切り替え部として機能させ、前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されており、前記セグメントファイルは、前記コンテンツのストリーミングデータがセグメント毎にファイル化されたものである。
本開示の第３の側面においては、HTTPによりユニキャスト送信されるセグメントファイルにおけるセグメント毎のデータ範囲と、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルにおけるセグメント毎の配信時間とを対応付けて記述したメタファイルが取得される。取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信されたセグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信されたセグメントファイルとが切り替えられて受信、再生される。前記メタファイルには、１つのセグメントの前記データ範囲と、それに対応する前記配信時間とが、同じセグメント要素に記述されている。

【発明の効果】

【0029】

本開示の第１乃至第３の側面によれば、コンテンツのHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングを実現できる。

【図面の簡単な説明】

【0030】

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

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

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

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

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

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

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

【図8】MPDの一例を示す図である。

【図9】書き換えられたMPDの一例を示す図である。

【図10】ServiceLocation要素のXML Schemaの一例を示す図である。

【図11】ServiceLocation要素のデータ構造を示す図である。

【図12】User Searvice Descriptionの一例を示す図である。

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

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

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

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

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

【0031】

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

【0032】

［コンテンツ供給システムの構成例］
本開示の実施の形態であるコンテンツ供給システムは、受信側がコンテンツを取得、再生するに際して、HTTPによるユニキャスト送信、RTPによるマルチキャスト送信およびブロードキャスト送信の各コンテンツストリームをシームレスにスイッチングできるようにするものである。

【0033】

具体的には、HTTPによりユニキャスト送信されるコンテンツストリームの区間を示すmediaRangeと、RTPによりマルチキャスト送信またはブロードキャスト送信されるコンテンツストリームの区間を示すrtspRangeとの対応関係を記述できるようにDASHにおけるMPDを拡張する。

【0034】

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

【0035】

該コンテンツ供給システム５０は、コンテンツを供給する側のコンテンツ供給装置６０と、コンテンツを視聴する側の多数のDASHクライアント７０から構成される。コンテンツ供給装置６０とDASHクライアント７０とはインターネット１１を介して接続される。DASHクライアント７０は、コンテンツ供給装置６０から放送網１２を介してマルチキャスト送信およびブロードキャスト送信されるコンテンツを受信できる。放送網１２には、地上波や衛星波などを用いるテレビジョン放送網などの他、MBMS(Multimedia Broadcast and Multicast Service)などのモバイルネットワークも含まれるものとする。

【0036】

コンテンツ供給装置６０は、コンテンツマネジメントサーバ６１、DASHセグメントストリーマ６２、DASH MPDサーバ６３、MPDプロキシサーバ６４、MPDコンフィギュレータ６５、ブロードキャスト／マルチキャスト(BC/MC)リソースマネージャ６６、DASHクライアントプロキシ６７、およびブロードキャスト／マルチキャスト(BC/MC)サービスプロバイダ６８がインターネット１１を介して相互に接続されて構成される。

【0037】

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

【0038】

DASHセグメントストリーマ６２は、コンテンツのストリーミングデータを時間的に分割する。

【0039】

図３は、コンテンツの時間的な区切りを示している。すなわち、DASHセグメントストリーマ６２は、図３に示されるように、コンテンツのストリーミングデータを時間的にピリオド(period)に区切り、さらにセグメント(segment)に分割して、それぞれをファイル化し、該ファイルの供給元を示すアドレスをDASH MPDサーバ６３に通知する。

【0040】

また、DASHセグメントストリーマ６２は、DASHクライアント７０からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルを、インターネット１１を介してHTTP送信する（HTTPを用いてユニキャスト送信する）。

【0041】

DASH MPDサーバ６３は、HTTPによりユニキャスト送信されるコンテンツをDASHクライアント７０が取得するための参照するMPDを生成し、該MPDをDASHクライアント７０からの要求に応じ、インターネット１１を介してHTTP送信する。また、DASH MPDサーバ６３は、MPDプロキシサーバ６４からの要求に応じ、生成したMPDを供給する。

【0042】

MPDプロキシサーバ６４は、DASH MPDサーバ６３からMPDを取得してMPDコンフィギュレータ６５に供給する。

【0043】

MPDコンフィギュレータ６５は、HTTPによりユニキャスト送信されるコンテンツと同一内容のブロードキャスト送信およびマルチキャスト送信されるコンテンツをDASHクライアント７０が取得できるようにMPDを書き換える。ブロードキャスト／マルチキャストリソースマネージャ６６は、ブロードキャストベアラおよびマルチキャストベアラのリソースの状況をMPDコンフィギュレータ６５に通知する。

【0044】

DASHクライアントプロキシ６７は、書き換えられたMPDをDASHクライアント７０に送信するとともに、ブロードキャスト／マルチキャストサービスプロバイダ６８に供給してFLUTEによりマルチキャスト送信させる。また、DASHクライアントプロキシ６７は、DASHセグメントストリーマ６２からコンテンツのセグメントを取得し、取得したセグメントをマルチキャストプロトコルまたはブロードキャストプロトコルに変換してブロードキャスト／マルチキャストサービスプロバイダ６８に供給し、RTPにより放送網１２を介してマルチキャスト送信およびブロードキャスト送信させる。

【0045】

ブロードキャスト／マルチキャストサービスプロバイダ６８は、書き換えられたMPDを、FLUTEにより放送網１２を介してマルチキャスト送信する。また、ブロードキャスト／マルチキャストサービスプロバイダ６８は、コンテンツのストリームセグメントをRTPにより放送網１２を介してマルチキャスト送信およびブロードキャスト送信する。

【0046】

［MPDの概要］
次に、DASHにおけるMPDの概要について図４および図５を参照して説明する。

【0047】

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

【0048】

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

【0049】

図６は、時間軸上にMPDの構造を並べた状態を示している。

【0050】

同図から明らかなように、同一のSegmentに対して複数のRepresentationが存在しているので、これらのうちのいずれかをDASHクライアント７０が適応的に選択することにより、通信環境や自己のデコード能力などに応じて適切なストリームデータをスイッチングして視聴することができる。

【0051】

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

【0052】

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

【0053】

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

【0054】

MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeには、該ファイルにおける、セグメント化されたストリームデータのバイト範囲のシーケンスが記述される。

【0055】

したがって、DASHクライアント７０が、ファイルのurlとして”http://example.com/counter-10mn_avc_dash.mp4”を指定するとともに、そのRangeヘッダにmediaRangeを指定してHTTPリクエストを発行すれば、目的のセグメントを取得することができる。

【0056】

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

【0057】

したがって、１つ目のセグメントを取得するためには、HTTPリクエストにおいて、ファイルの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

【0058】

同様に、２つ目のセグメントを取得するためには、以下のHTTPリクエストを発行すればよい。
GET /counter-10mn_avc_dash.mp4 HTTP/1.1
Host: example.com
Range: bytes=83597-166046

【0059】

［MPDの書換え］
本実施の形態においては、セグメント化されたストリームデータがHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信と、RTPによるブロードキャスト送信とにより受信側のDASHクライアント７０に供給される。さらに、DASHクライアント７０にてこれらがシームレスにスイッチングされる。

【0060】

これを実現するために、ServiceLocation要素を新たに導入する。また、HTTPによりユニキャスト送信されるセグメントのバイト範囲に対応する、RTPによりマルチキャスト送信およびブロードキャスト送信されるストリームセグメントの区間を表すrtspRangeを追記する。

【0061】

図９は、図８に示されたMPDを書き換えた例を示している。具体的には、SegmentURL要素に、HTTP送信されるセグメントのスイッチング対象としての、RTPによるマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの区間を特定する属性としてrtspRange属性が配置される。さらに、ServiceLocation要素をルート要素として格納するServiceLocationAttributeファイルのurlが記述されるServiceLocationAttributeUrl属性がMPDのBaseURLに配置される。

【0062】

書き換えられたMPDのSegmentURL要素のrtspRange属性には、RFC(Request For Comment)2326にて規定されるRTPストリーミングの制御に利用されるRTSP（Real Time Streaming Protocol）において定義されているRTPストリーム区間を識別するrangeパラメタのフォーマット（UTCフォーマット）の文字列が格納される。なお、rtspRange属性に格納する情報のフォーマットはUTCフォーマットに限定されるものではない。

【0063】

例えば、図９の場合、HTTPによりユニキャスト送信されるファイルのバイト範囲795バイト目から83596バイト目までが成す１つ目のセグメントには、RTPによりマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの19961108T143720.25Zから19961108T143730.25Zの表す区間が対応することを示している。

【0064】

同様に、HTTPによりユニキャスト送信されるファイルのバイト範囲83597バイト目から166046バイト目までが成す２つ目のセグメントには、RTPによりマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの19961108T143730.25Zから19961108T143740.25Zの表す区間が対応することを示している。

【0065】

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

【0066】

図１１は、新たに導入したServiceLocation要素を示している。ServiceLocation要素は、チューニングパラメータ(DeliverySystemAttributes)およびIPマルチキャストアドレス(IPMulticastAddress)から成る。そして、該ServiceLocation要素をルート要素として格納するServiceLocationAttributeファイルのurlがBaseURLに配置されたServiceLocationAttributeUrl属性に記述される。

【0067】

DeliverySystemAttributesのDeliverySystemIdentifierには、例えばMBMSなどのモバイルネットワークのマルチキャストベアラやブロードキャストベアラを利用する場合、MBMSなどによるマルチキャスト送信やブロードキャスト送信にて採用されているチューニングパラメタのデータ構造のフォーマット識別子（MBMSの場合、ID_MBMS）が記述される。

【0068】

また、例えばDVB地上波網などの既存のテレビジョン放送網のブロードキャストベアラを利用する場合、DVB地上波網のブロードキャスト送信にて採用されているチューニングパラメタのデータ構造のフォーマット識別子（DVB地上波網の場合、ID_DVB_T）が記述される。

【0069】

DeliverySystemAttributesのDeliverySystemDescriptorには、DeliverySystemIdentifierで識別される放送配信またはマルチキャスト配信にて規定されたチューニングパラメタのデータ構造(パラメタ自体)が記述される。なお、実際には、パラメータを表すバイト列がbase64等により文字列に変換されてDeliverySystemDescriptorに記述される。

【0070】

図１２は、MBMSによるマルチキャスト送信やブロードキャスト送信にて採用されているチューニングパラメタとしてのUser Service Descriptionのデータ構造の例である。

【0071】

bundleDescription(名前空間"urn:3GPP:metadata:2005:MBMS:userServiceDescription")は、userServiceDescription(名前空間"urn:3GPP:metadata:2005:MBMS:userServiceDescription")を複数束ねるための要素である。userServiceDescriptionは、serviceId属性で識別される、MBMSによるブロードキャスト送信またはマルチキャスト送信されるストリームを取得(チューン/join)するための情報を格納する要素である。

【0072】

deliveryMethod(名前空間"urn:3GPP:metadata:2005:MBMS:userServiceDescription")は、ストリームのマルチキャストアドレスが記載されたSDP(Session Description Protocol)を指定する要素である。具体的には、sessionDescriptionURI属性によりSDPファイルのURLが指定される。Registration(名前空間"urn:3GPP:metadata:2008:MBMS:userServiceDescription")は、マルチキャストサービスに登録するために必要な、例えばストリームのプロテクションキー等を取得するためのプロセス(registrationURL属性にて指定されるサーバサイドスクリプトを起動して行われる認証セッション等にリンクされる(マルチキャストストリームが暗号化・保護されているような場合))である。

【0073】

DeliveryServiceDescriptorの中に、上述したようなUserServiceDescription構造が格納されている場合には、MBMSサービスの規定に定義されているプロセスに従って利用登録を行えば、MBMSブロードキャストストリームまたはMBMSマルチキャストストリームを取得できるようになる。

【0074】

上述したように、ServiceLocation/DeliverySystem要素に格納される情報により取得されるMBMSブロードキャストストリームまたはMBMSマルチキャストストリーム上でIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリームには、RTPによりコンテンツストリームが運ばれるものとする。この場合のプロトコルの階層は図１３のＡに示されるように構成される。

【0075】

また、DVB地上波網によるブロードキャストベアラが利用された場合には、チューニングパラメタとして、"ETSI TS 102 851 V1.1.1 (2010-01) Digital Video Broadcasting (DVB); Uniform Resource Identifiers (URI) for DVB Systems"にて規定されているDVB_Tripletを含むDVBurlフォーマットdvb://<ONid>.<TSid>.<Sid>が格納され、該DVBurlフォーマットを参照することによりDVB地上波網によるブロードキャストストリームが取得される。

【0076】

ここで、DVB_Tripletは、DVB-SIのネットワーク情報テーブルNITに格納されているオリジナルネットワーク識別子ONid、並びにDVB-SIのストリーム記述テーブルSDTに格納されているトランスポートストリーム識別子TSidおよびサービス識別子Sidの３項目の情報を指す。

【0077】

上述したように、ServiceLocation/DeliverySystem要素に格納されるDVBurlフォーマットにより取得されるDVB地上波網によるブロードキャストストリーム上に転送されるIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリームには、RTPプロトコルによりコンテンツストリームが運ばれるものとする。この場合のプロトコルの階層は図１３のＢに示されるように構成される。

【0078】

［コンテンツ供給システム５０の動作］
次に、コンテンツ供給システム５０の動作について説明する。

【0079】

図１４は、コンテンツ供給システム５０の第１の動作を説明するフローチャートである。該第１の動作では、DASHクライアント７０からMPDコンフィギュレータ６５に対してMPDの書き換えが自発的に依頼される。

【0080】

なお、該第１の動作の前提として、DASHセグメントストリーマ６２は、コンテンツマネジメントサーバ６１から、同一内容のコンテンツのビットレートなどが異なる複数のストリーミングデータを取得、各ストリーミングデータをセグメント化して保持しており、そのHTTP送信を開始しているものとする。

【0081】

また、DASH MPDサーバ６３は、DASHセグメントストリーマ６２から通知されたストリームセグメントのファイルのアドレスに基づいてMPDを生成しており、そのHTTP送信を開始しているものとする。

【0082】

ステップＳ１において、コンテンツを受信、再生しようとするDASHクライアント７０は、インターネット１１を介してDASH MPDサーバ６３にアクセスし、MPDのHTTP送信を要求する。なお、DASHクライアント７０はDASH MPDサーバ６３のアドレスを予め知っているものとする。

【0083】

DASHクライアント７０からの要求に応じ、ステップＳ１１において、DASH MPDサーバ６３は、インターネット１１を介してDASHクライアント７０にMPDをHTTP送信する。

【0084】

MPDを受信したDASHクライアント７０は、該MPDに基づいてDASHセグメントストリーマ６２にアクセスし、HTTPによりユニキャスト送信されるストリームセグメントを受信、再生する。具体的には、MPDのBaseURLとmediaRangeに基づいてHTTPリクエストを発行して、DASHセグメントストリーマ６２にDASHストリームセグメントのファイルのHTTP送信を要求する。この要求に応じ、DASHセグメントストリーマ６２は、対応するファイルをインターネット１１を介してDASHクライアント７０にHTTP送信し、これをDASHクライアント７０が受信して再生する。

【0085】

この受信の間、DASHクライアント７０は、ステップＳ２として、インターネット１１の帯域をモニタリングし、今後、ユニキャスト受信が不安定になりそうであり、かつ、DASHクライアント７０自身が放送網１２を介したコンテンツのマルチキャスト送信やブロードキャスト送信を受信可能である場合、MPDコンフィギュレータ６５に取得済みのMPDを送信して該MPDの書き換えを要求する。

【0086】

DASHクライアント７０からのMPDの書き換えの要求に応じ、ステップＳ２１において、MPDコンフィギュレータ６５は、ブロードキャスト／マルチキャストリソースマネージャ６６に対してブロードキャストベアラおよびマルチキャストベアラのリソースの利用状況を確認する。さらに、ブロードキャストベアラおよびマルチキャストベアラを併用することのコストを考慮して、その利用を決定し、ブロードキャスト／マルチキャストリソースマネージャ６６に対してリソースの確保を要求する。ブロードキャスト／マルチキャストリソースマネージャ６６からリソースが確保できた旨の通知を受けた後、MPDコンフィギュレータ６５は、MPDを書き換えて、DASHクライアント７０に送信する。なお、送信された、書き換えられたMPDは、DASHクライアント７０で受信される前に、DASHクライアントプロキシ６７にモニタされる。

【0087】

書き換えられたMPDをモニタしたDASHクライアントプロキシ６７は、ステップＳ３１において、ブロードキャスト／マルチキャストプロバイダ６８に対して、放送網１２のFLUTEにより該MPDの周期的なマルチキャスト送信を依頼する。この依頼に応じ、ステップＳ４１において、ブロードキャスト／マルチキャストプロバイダ６８は、書き換えられたMPDを、放送網１２のFLUTEにより周期的にマルチキャスト送信する。このマルチキャスト送信により、MPDの書き換えを要求していないDASHクライアント７０に対しても、書き換えられたMPDを供給することができる。

【0088】

ステップＳ３２において、DASHクライアントプロキシ６７は、モニタしたMPDに基づき、DASHクライアント７０の代わりにDASHセグメントストリーマ６２にストリームセグメントを要求する。この要求に応じたDASHセグメントストリーマ６２は、ステップＳ５１において、HTTPによりインターネット１１を介して、DASHクライアントプロキシ６７にストリームセグメントをユニキャスト送信する。

【0089】

HTTPによりユニキャスト送信されたストリームセグメント受信したDASHクライアントプロキシ６７は、ステップＳ３３において、HTTPのパケットに格納されている該ストリームセグメントをRTPパケットのペイロードに乗せ換えるプロトコル変換を行う。さらに、ブロードキャスト／マルチキャストプロバイダ６８に対して、プロトコル変換後のストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を依頼する。

【0090】

この依頼に応じ、ステップＳ４２において、ブロードキャスト／マルチキャストプロバイダ６８は、プロトコルが変換されたストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を開始する。

【0091】

なお、書き換えられたMPDを取得したDASHクライアント７０は、その後、ステップＳ３またはステップＳ５に進む。

【0092】

すなわち、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントの受信、再生を継続する場合にはステップＳ４の処理に進むことになり、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントにスイッチングする場合にはステップＳ５に進むことになる。

【0093】

ユニキャスト送信されるストリームセグメントの受信、再生を継続する場合、ステップＳ３において、DASHクライアント７０は、該MPDに基づいてDASHセグメントストリーマ６２にストリームセグメントを要求する。そして、ステップＳ４において、この要求に応じたDASHセグメントストリーマ６２からのHTTPによるインターネット１１を介したストリームセグメントのユニキャスト送信（ステップＳ５２の処理）を受信、再生する。

【0094】

また、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントにスイッチングする場合、ステップＳ５において、DASHクライアント７０は、書き換えられたMPDに基づき、HTTPによりユニキャスト送信されているセグメントストリームから、マルチキャスト送信またはブロードキャスト送信された、プロトコル変換されたストリームセグメントに受信、再生をスイッチングする。

【0095】

このスイッチングのタイミングは、書き換えられたMPD上のマルチキャストストリームに対応するRepresentationに対応するSegment列に格納されているrtspRangeの時間区間情報を頼りに、ユニキャストで運ばれるRepresentationに対応するSegment列との対応関係に基づいて決定される。

【0096】

なお、上述したプロトコル変換におけるストリームセグメントをRTPパケットのペイロードに格納する方式は、コンテンツの符号化方式(AVC、AMR等)ごとに定められている。RTPによるストリーミングの際には、RTCP(RTP Control Protocol)も同時に用いて複数のRTPパケットストリームで運ばれるストリーム間の同期再生用の時間軸を決めるための、RTPタイムスタンプとそれに対応するNTP(Network Time Protocol)タイムスタンプが転送される。

【0097】

なお、NTPタイムスタンプは、1900年1月1日0時0分0秒からの経過秒数（整数部32bit、小数部32bitの符号なし固定小数点）であるが、UTCタイムスタンプ(フォーマットは例: 2004-04-01T12:00Z (20040401T1200Z). UTCでの2004年4月1日の正午を表す)に容易に変換可能である。よって、これからRTPタイムスタンプの絶対時刻(Wall Clock Time)上の位置(時刻)を計算することができる。すなわち、NTPタイムスタンプによって、コンテンツの供給側と受信側のシステム時刻(wall clock)が同期され、その時間軸上に、RTCPで運ばれるNTPタイムスタンプとRTPタイムスタンプとの対応関係情報に基づいてスイッチング対象のRTPパケットが特定される。

【0098】

なお、この後においては、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。

【0099】

以上で、コンテンツ供給システム５０の第１の動作の説明を終了する。

【0100】

次に、図１５は、コンテンツ供給システム５０の第２の動作を説明するフローチャートである。該第２の動作では、MPDプロキシサーバ６４が主体となってMPDコンフィギュレータ６５に対してMPDの書き換えが依頼される。

【0101】

なお、該第２の動作の前提として、DASHセグメントストリーマ６２は、コンテンツマネジメントサーバ６１から、同一内容のコンテンツのビットレートなどが異なる複数のストリーミングデータを取得、各ストリーミングデータをセグメント化して保持しており、そのHTTP送信を開始しているものとする。

【0102】

また、DASH MPDサーバ６３は、DASHセグメントストリーマ６２から通知されたストリームセグメントのファイルのアドレスに基づいてMPDを生成しており、そのHTTP送信を開始しているものとする。

【0103】

ステップＳ７１において、コンテンツを受信、再生しようとするDASHクライアント７０は、インターネット１１を介してDASH MPDサーバ６３にMPDのHTTP送信を要求する。この要求は、MPDプロキシサーバ６４によって受信され、MPDプロキシサーバ６４は、ステップＳ８１において、DASH MPDサーバ６３にMPDの送信を要求する。

【0104】

この要求に応じたDASH MPDサーバ６３は、ステップＳ９１において、MPDをMPDプロキシサーバ６４に送信する。該MPDを受信したMPDプロキシサーバ６４は、ステップＳ８２において、受信したMPDをMPDコンフィギュレータ６５に送信して該MPDの書き換えを要求する。

【0105】

MPDの書き換え要求に応じ、ステップＳ１０１において、MPDコンフィギュレータ６５は、ブロードキャスト／マルチキャストリソースマネージャ６６に対してブロードキャストベアラおよびマルチキャストベアラのリソースの利用状況を確認する。さらに、ブロードキャストベアラおよびマルチキャストベアラを併用することのコストを考慮して、その利用を決定し、ブロードキャスト／マルチキャストリソースマネージャ６６に対してリソースの確保を要求する。ブロードキャスト／マルチキャストリソースマネージャ６６からリソースが確保できた旨の通知を受けた後、MPDコンフィギュレータ６５は、MPDを書き換えてMPDプロキシサーバ６４に送信する。

【0106】

ステップＳ８３において、MPDプロキシサーバ６４は、書き換えられたMPDをDASHクライアント７０に送信する。なお、送信された、書き換えられたMPDは、DASHクライアント７０で受信される前に、DASHクライアントプロキシ６７にモニタされる。

【0107】

書き換えられたMPDをモニタしたDASHクライアントプロキシ６７は、ステップＳ１１１において、ブロードキャスト／マルチキャストプロバイダ６８に対して、放送網１２のFLUTEにより該MPDの周期的なマルチキャスト送信を依頼する。この依頼に応じ、ステップＳ１２１において、ブロードキャスト／マルチキャストプロバイダ６８は、書き換えられたMPDを、放送網１２のFLUTEにより周期的にマルチキャスト送信する。このマルチキャスト送信により、MPDの送信を要求していないDASHクライアント７０に対しても、書き換えられたMPDを供給することができる。

【0108】

ステップＳ１１３において、DASHクライアントプロキシ６７は、モニタした、書き換えられたMPDに基づき、DASHクライアント７０の代わりにDASHセグメントストリーマ６２にストリームセグメントを要求する。この要求に応じたDASHセグメントストリーマ６２は、ステップＳ１３１において、HTTPによりインターネット１１を介して、DASHクライアントプロキシ６７にストリームセグメントをユニキャスト送信する。

【0109】

HTTPによりユニキャスト送信されたストリームセグメント受信したDASHクライアントプロキシ６７は、ステップＳ１１３において、HTTPのパケットに格納されている該ストリームセグメントをRTPパケットのペイロードに乗せ換えるプロトコル変換を行う。さらに、ブロードキャスト／マルチキャストプロバイダ６８に対して、プロトコル変換後のストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を依頼する。

【0110】

この依頼に応じ、ステップＳ１２２において、ブロードキャスト／マルチキャストプロバイダ６８は、プロトコルが変換されたストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を開始する。

【0111】

一方、DASHクライアント７０は、既に書き換えられたMPDを取得している。ステップＳ７２において、DASHクライアント７０は、インターネット１１の帯域状態、自身の受信機能などに基づいて、インターネット１１を介するユニキャスト送信を受信するか、放送網１２を介するマルチキャスト送信またはブロードキャスト送信を受信するかを選択する。

【0112】

HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントの受信、再生を行うことが選択された場合、処理はステップＳ７３に進められる。ステップＳ７３において、DASHクライアント７０は、該MPDに基づいてDASHセグメントストリーマ６２にストリームセグメントを要求する。そして、ステップＳ７４において、この要求に応じたDASHセグメントストリーマ６２からのHTTPによるインターネット１１を介したストリームセグメントのユニキャスト送信（ステップＳ１３２の処理）を受信、再生する。

【0113】

また、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントの受信、再生を行うことが選択された場合、処理はステップＳ７５に進められる。ステップＳ７５において、DASHクライアント７０は、書き換えられたMPDに基づき、RTPによりマルチキャスト送信またはブロードキャスト送信された、プロトコル変換されたストリームセグメントを受信、再生する。

【0114】

なお、この後においては、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。

【0115】

以上で、コンテンツ供給システム５０の第２の動作の説明を終了する。

【0116】

以上説明したように、本実施の形態であるコンテンツ供給システム５０によれば、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。したがって、DASHクライアント７０のユーザは、同一内容のコンテンツであってパスが異なるストリームを適応的に選択し、視聴することができる。

【0117】

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

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

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

【0123】

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

【0124】

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

【0125】

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

【0126】

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

【符号の説明】

【0127】

１１ インターネット， １２ 放送網， ５０ コンテンツ供給システム， ６０ コンテンツ供給装置， ６１ コンテンツマネジメントサーバ， ６２ DASHセグメントストリーマ， ６３ DASH MPDサーバ， ６４ MPDプロキシサーバ， ６５ MPDコンフィギュレータ， ６６ ブロードキャスト／マルチキャストリソースマネージャ， ６７ DASHクライアントプロキシ， ６８ ブロードキャスト／マルチキャストサービスプロバイダ， ７０ DASHクライアント， １００ コンピュータ， １０１ CPU

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】