(57)【要約】【課題】  DASHを拡張し、ユニキャスト送信、マルチキャスト送信またはブロードキャスト送信の受信、再生をシームレスにスイッチングする。【解決手段】  本開示の第１の側面であるコンテンツ供給装置は、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部とを備える。本開示は、コンテンツをストリーミング配信するシステムに適用できる。【選択図】  図２
2014230055.tif 000002
【特許請求の範囲】
【請求項１】
MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置において、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
を備えるコンテンツ供給装置。
【請求項２】
前記コンテンツのストリーミングデータはfragmented MP4であり、
前記RTP送信部は、前記セグメントファイルを前記fragmented MP4のbox構造を維持したまま前記RTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信する
請求項１に記載のコンテンツ供給装置。
【請求項３】
前記RTP送信部は、前記RTPパケットのRTPヘッダのタイムスタンプフィールドに、前記RTPパケットの送信時の先頭のビットの送信時刻を記述する
請求項２に記載のコンテンツ供給装置。
【請求項４】
前記RTP送信部は、前記RTPパケットのRTPペイロードに、前記RTPペイロードのモードを表す情報と、セグメントの境界を表す情報とを記述し、ペイロードデータにNALユニットを配置する
請求項２に記載のコンテンツ供給装置。
【請求項５】
前記RTP送信部は、さらに、前記RTPパケットのRTPペイロードに、前記MPEG-DASH で規定されているInitialization SegmentとMedia Segmentのメタデータの両方を配置するか、前記Media Segmentのメタデータを配置するか、または前記Initialization Segmentと前記Media Segmentのメタデータの両方を配置しない
請求項２に記載のコンテンツ供給装置。
【請求項６】
MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、
前記コンテンツ供給装置による、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信ステップと、
前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信ステップと、
HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成ステップと
を含むコンテンツ供給方法。
【請求項７】
MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンピュータを、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
して機能させるプログラム。
【請求項８】
MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信するクライアント装置とから成るコンテンツ供給システムにおいて、
前記コンテンツ供給装置は、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
を備え、
前記クライアント装置は、
取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとを切り替えて受信、再生する
コンテンツ供給システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関し、特に、コンテンツをHTTP(Hyper Text Transfer Protocol)によりインターネットを介してユニキャスト送信する場合の代替パスとして、RTP(Real-time Transport Protocol)により放送網を介してマルチキャスト送信またはブロードキャスト送信できるようにしたコンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関する。
【背景技術】
【０００２】
近年、インターネットを介するストリーミングサービスの主流がOTT-V(Over The Top Video)となっており、その基盤技術として、Webサイトなどの閲覧と同様に供給側と受信側がpoint to pointで接続されるHTTPを用いたMPEG-DASH（Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP、以下、DASHと称する）が知られている（例えば、非特許文献１を参照）。
【０００３】
DASHでは適応型ストリーミング技術が実現されている。すなわち、コンテンツの供給側は、同一内容のコンテンツであって画質や画角サイズが異なる複数のストリームを供給できる体制を整えており、受信側はインターネットの通信環境や受信側の能力や状態に応じて最適なストリームをスイッチングして視聴することができるようにされている。
【０００４】
DASHにおいては、受信側がストリームを適応的にスイッチングするための情報として、供給側から受信側にMPD(Media Presentation Description)と称されるメタファイルが供給される。MPDには、チャンク化されたストリーミングデータ(Audio/Video/Subtitle等のメディアデータ)の供給元のサーバを表すアドレス(url情報)が記述されている。
【０００５】
受信側は、該url情報に基づいて該サーバにアクセスし、HTTP送信されるストリーミングデータを取得、再生することができる。
【０００６】
図１は、DASHに基づいてコンテンツをストリーミング配信するコンテンツ供給システムの構成の一例を示している。
【０００７】
該コンテンツ供給システム２０は、コンテンツを供給する側のコンテンツマネジメントサーバ２１、DASHセグメントストリーマ２２、およびDASH MPDサーバ２３、並びにコンテンツを受信、視聴する側のDASHクライアント３０から構成される。なお、図示は省略するが、DASHクライアント３０は多数存在するものとする。
【０００８】
コンテンツマネジメントサーバ２１は、受信側に供給するコンテンツを管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ２２に出力する。
【０００９】
DASHセグメントストリーマ２２は、コンテンツのストリーミングデータを時間的にセグメントに分割してそれぞれをファイル化して保持し、そのアドレスをDASH MPDサーバ２３に通知する。さらに、DASHセグメントストリーマ２２は、受信側のDASHクライアント３０からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルを、インターネット１１を介してDASHクライアント３０にユニキャスト送信する。
【００１０】
DASH MPDサーバ２３は、セグメント化されたストリーミングデータのファイルの供給元となるDASHセグメントストリーマ２２のアドレスなどを記述したMPDを生成する。また、DASH MPDサーバ２３は、受信側のDASHクライアント３０からの要求に応じ、HTTPサーバとして該MPDをインターネット１１を介してDASHクライアント３０にユニキャスト送信する。
【００１１】
受信側のDASHクライアント３０は、コンテンツを受信、再生するものであり、DASH MPDサーバ２３から取得するMPDに基づいてHTTPサーバとしてのDASHセグメントストリーマ２２にアクセスし、セグメント化されたストリーミングデータのファイルを受信、再生する。
【００１２】
なお、インターネット１１上にキャッシュサーバを設け、ユニキャスト送信されるMPDやセグメント化されたストリーミングデータのファイルなどキャッシングし、DASHセグメントストリーマ２２やDASH MPDサーバ２３の動作を代行させることもある。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEI ELECTRONICS 2012.3.19
【発明の概要】
【発明が解決しようとする課題】
【００１４】
上述したように、DASHではHTTPによるユニキャスト送信によりコンテンツを供給する適応的ストリーミング技術が実現されている。
【００１５】
ただし、例えば、リアルタイムのスポーツ中継のコンテンツなどのように、数多くのDASHクライアント３０が同時に取得、再生する可能性があるコンテンツを、DASHにより同時に多数に供給する場合、HTTPを用いているために、CDN(Contents Delivery Network)のサポートが必要となる。しかしながら、CDNのサポートを受けるとしても、そのコスト的な制約から既存の放送配信に匹敵する程のスケーラビリティを求めることはできない。
【００１６】
ところで、コンテンツを同時に多数の受信側に供給するには、テレビジョン放送網やモバイルネットワークを介したマルチキャストベアラやブロードキャストベアラを利用する方法があり、これには一般的にRTPが用いられる。
【００１７】
よって、受信側がマルチキャスト送信またはブロードキャスト送信されるコンテンツを受信、再生可能であれば、DASHにおける代替パスとしてそれらを用い、受信側で適応的にストリームを選択できるようにすることが望ましい。
【００１８】
しかしながら、現状のDASHの仕様においては、コンテンツのストリーミングデータをHTTPによりユニキャスト送信することのみを想定しており、マルチキャストベアラやブロードキャストベアラの利用は想定していない。
【００１９】
したがって、DASHのMPDには、HTTPによりユニキャスト送信されるDASHセグメントと、そのセグメント区間に対応するマルチキャストベアラまたはブロードキャストベアラ上のRTPによってストリーミングされるコンテンツ区間との対応関係を記述することができない。
【００２０】
また、現状においては、DASHの制御対象となるコンテンツストリームチャンクであるfragmented MP4のbox構造を壊すことなくそのままRTPパケットに格納できるようなペイロードフォーマットが規定されていない。
【００２１】
よって、現状のDASHの規格では、コンテンツのユニキャスト送信とマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングの実現が困難である。
【００２２】
本開示はこのような状況に鑑みてなされたものであり、コンテンツのHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングを実現できるようにするものである。
【課題を解決するための手段】
【００２３】
本開示の第１の側面であるコンテンツ供給装置は、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置において、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部とを備える。
【００２４】
前記コンテンツのストリーミングデータはfragmented MP4とすることができ、前記RTP送信部は、前記セグメントファイルを前記fragmented MP4のbox構造を維持したまま前記RTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信することができる。
【００２５】
前記RTP送信部は、前記RTPパケットのRTPヘッダのタイムスタンプフィールドに、前記RTPパケットの送信時の先頭のビットの送信時刻を記述することができる。
【００２６】
前記RTP送信部は、前記RTPパケットのRTPペイロードに、前記RTPペイロードのモードを表す情報と、セグメントの境界を表す情報とを記述し、ペイロードデータにNALユニットを配置することができる。
【００２７】
前記RTP送信部は、さらに、前記RTPパケットのRTPペイロードに、前記MPEG-DASH で規定されているInitialization SegmentとMedia Segmentのメタデータの両方を配置するか、前記Media Segmentのメタデータを配置するか、または前記Initialization Segmentと前記Media Segmentのメタデータの両方を配置しないようにすることができる。
【００２８】
本開示の第１の側面であるコンテンツ供給方法は、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、前記コンテンツ供給装置による、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信ステップと、前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信ステップと、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成ステップとを含む。
【００２９】
本開示の第１の側面であるプログラムは、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンピュータを、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部として機能させる。
【００３０】
本開示の第１の側面においては、ストリーミングデータがセグメント毎にファイル化され、その結果得られるセグメントファイルがHTTPによりユニキャスト送信され、前記セグメントファイルがそのままRTPパケットに格納され、前記RTPパケットがRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される。また、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルが生成されて受信側に供給される。
【００３１】
本開示の第２の側面であるコンテンツ供給システムは、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信するクライアント装置とから成るコンテンツ供給システムにおいて、前記コンテンツ供給装置が、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と備える。また、前記クライアント装置が、取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとを切り替えて受信、再生する。
【発明の効果】
【００３２】
本開示の第１および第２の側面によれば、コンテンツのHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングを実現できる。
【図面の簡単な説明】
【００３３】
【図１】DASHを利用する従来のコンテンツ供給システムの構成の一例を示すブロック図である。
【図２】本開示を適用したコンテンツ供給システムの構成例を示すブロック図である。
【図３】コンテンツの時間的区切りを説明する図である。
【図４】MPDの構成を示す図である。
【図５】MPDにおけるPeriod以下の階層構造を示す図である。
【図６】時間軸上にMPDの構成を並べた図である。
【図７】MPDのRepresentation以下の詳細な構造を示す図である。
【図８】MPDの一例を示す図である。
【図９】書き換えられたMPDの一例を示す図である。
【図１０】ServiceLocation要素のXML Schemaの一例を示す図である。
【図１１】ServiceLocation要素のデータ構造を示す図である。
【図１２】User Searvice Descriptionの一例を示す図である。
【図１３】プロトコルの階層構造を示す図である。
【図１４】RTPパケットのデータ構造を表す図である。
【図１５】RTPパケットにAVC fragmented MP4を格納する場合の図である。
【図１６】RTPパケットにHEVC Segmented MP4を格納する場合の図である。
【図１７】RTPペイロードのフォーマットの組み合わせパターンの例を示す図である。
【図１８】コンテンツ供給システムの第１の動作を説明するフローチャートである。
【図１９】コンテンツ供給システムの第２の動作を説明するフローチャートである。
【図２０】コンピュータの構成例を示すブロック図である。
【発明を実施するための形態】
【００３４】
以下、本開示を実施するための最良の形態（以下、実施の形態と称する）について、図面を参照しながら詳細に説明する。
【００３５】
［コンテンツ供給システムの構成例］
本開示の実施の形態であるコンテンツ供給システムは、コンテンツを受信、再生する側がコンテンツを受信するに際し、HTTPによるユニキャスト送信、RTPによるマルチキャスト送信、またはRTPによるブロードキャスト送信の各コンテンツストリームをシームレスにスイッチングできるようにするものである。
【００３６】
具体的には、HTTPによりユニキャスト送信されるコンテンツストリームの区間を示すmediaRangeと、RTPによりマルチキャスト送信またはブロードキャスト送信されるコンテンツストリームの区間を示すrtspRangeとの対応関係を記述できるようにDASHにおけるMPDを拡張する。
【００３７】
また、より容易に、すなわち、DASHの制御対象となるコンテンツストリームチャンクであるfragmented MP4のbox構造を壊すことなく、そのままRTPパケットに格納できるようペイロードフォーマットを規定する。
【００３８】
図２は、本開示の実施の形態であるコンテンツ供給システムの構成例を示している。
【００３９】
該コンテンツ供給システム５０は、コンテンツを供給する側のコンテンツ供給装置６０と、コンテンツを受信、視聴する側の多数のDASHクライアント７０から構成される。
【００４０】
DASHクライアント７０は、インターネット１１を介してコンテンツ供給装置６０に接続することができ、HTTPによるユニキャスト送信されるコンテンツを受信できる。また、DASHクライアント７０は、コンテンツ供給装置６０から放送網１２を介してマルチキャスト送信およびブロードキャスト送信されるコンテンツを受信できる。
【００４１】
ここで、放送網１２には地上波や衛星波などを用いるテレビジョン放送網などの他、MBMS(Multimedia Broadcast and Multicast Service)などのモバイルネットワークも含まれるものとする。
【００４２】
コンテンツ供給装置６０は、コンテンツマネジメントサーバ６１、DASHセグメントストリーマ６２、DASH MPDサーバ６３、MPDプロキシサーバ６４、MPDコンフィギュレータ６５、ブロードキャスト／マルチキャスト(BC/MC)リソースマネージャ６６、DASHクライアントプロキシ６７、およびブロードキャスト／マルチキャスト(BC/MC)サービスプロバイダ６８を有し、これらがインターネット１１を介して相互に接続されて構成される。
【００４３】
コンテンツマネジメントサーバ６１は、DASHクライアント７０に供給するためのコンテンツ（ライブ放送コンテンツを含む）を管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ６２に供給する。
【００４４】
DASHセグメントストリーマ６２は、コンテンツのストリーミングデータを時間的に分割する。
【００４５】
図３は、コンテンツの時間的な区切りを示している。すなわち、DASHセグメントストリーマ６２は、図３に示されるように、コンテンツのストリーミングデータを時間的にピリオド(period)に区切り、さらにセグメント(segment)に分割して、コンテンツをセグメント単位でファイル化して保持し、該ファイルの供給元を示すアドレスをDASH MPDサーバ６３に通知する。
【００４６】
また、DASHセグメントストリーマ６２は、DASHクライアント７０からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルを、インターネット１１を介してHTTP送信する（HTTPを用いてユニキャスト送信する）。
【００４７】
DASH MPDサーバ６３は、HTTPによりユニキャスト送信されるコンテンツをDASHクライアント７０が取得するに際して参照するMPDを生成し、該MPDをDASHクライアント７０からの要求に応じ、インターネット１１を介してHTTP送信する。また、DASH MPDサーバ６３は、DASHプロクシサーバ６４からの要求にも応じて、生成したMPDを供給する。
【００４８】
MPDプロキシサーバ６４は、DASH MPDサーバ６３からMPDを取得してMPDコンフィギュレータ６５に供給する。
【００４９】
MPDコンフィギュレータ６５は、HTTPによりユニキャスト送信されるコンテンツと同一内容の、ブロードキャスト送信およびマルチキャスト送信されるコンテンツをDASHクライアント７０が取得できるようにMPDを書き換える。
【００５０】
ブロードキャスト／マルチキャストリソースマネージャ６６は、ブロードキャストベアラおよびマルチキャストベアラのリソースの状況をMPDコンフィギュレータ６５に通知する。
【００５１】
DASHクライアントプロキシ６７は、書き換えられたMPDをDASHクライアント７０に送信する。また、DASHクライアントプロキシ６７は、書き換えられたMPDをブロードキャスト／マルチキャストサービスプロバイダ６８に供給してFLUTEによりマルチキャスト送信させる。
【００５２】
さらに、DASHクライアントプロキシ６７は、DASHセグメントストリーマ６２からユニキャスト送信されるコンテンツのセグメントを取得し、取得したセグメントを、そのままbox構造を壊すことなくRTPパケットのペイロードに格納してブロードキャスト／マルチキャストサービスプロバイダ６８に供給し、RTPにより放送網１２を介してマルチキャスト送信およびブロードキャスト送信させる。
【００５３】
ブロードキャスト／マルチキャストサービスプロバイダ６８は、書き換えられたMPDを、FLUTEにより放送網１２を介してマルチキャスト送信する。また、ブロードキャスト／マルチキャストサービスプロバイダ６８は、コンテンツのセグメントがそのまま格納されたRTPパケットを、放送網１２を介してマルチキャスト送信およびブロードキャスト送信する。
【００５４】
［MPDの概要］
次に、DASHにおけるMPDの概要について図４および図５を参照して説明する。
【００５５】
図４はMPDのデータ構成を示している。図５はMPDにおけるPeriod以下の階層構造を示している。
【００５６】
MPDには、コンテンツ（Media)に関する情報がPeriod毎に区分され、各Periodには同一内容であってビットレートなどのストリーム属性が異なるストリーミングデータに関する情報からなる複数のRepresentationが用意されている。Representationには、Periodをさらに時間的に細分化したSegmentに関する情報が格納されている。
【００５７】
図６は、時間軸上にMPDの構造を並べた状態を示している。
【００５８】
同図から明らかなように、MPDにおいては、コンテンツの同一のSegmentに対して複数のRepresentationが存在している。よって、これらのうちのいずれかをDASHクライアント７０が適応的に選択することにより、通信環境や自己のデコード能力などに応じて適切なストリームデータをスイッチングして受信、再生することができる。
【００５９】
図７は、MPDのRepresentation以下の構造を詳細に示している。
【００６０】
Representationには、コンテンツのセグメントが格納されているファイルの供給元となるDASHセグメントストリーマ６２のアドレスが記述される。具体的には、複数のセグメントがそれぞれ個別にファイル化されている場合には、各ファイルのアドレス（url情報）のシーケンスが記述される。また、複数のセグメントがまとめて１個のファイルに格納されている場合には、該ファイルのアドレス（Base URL）に加えて、該ファイルにおける各セグメントの範囲(mediaRange)のシーケンスが記述される。なお、図７には、後者の例が示されている。
【００６１】
図８は、図７に示されたRepresentation以下の構造をXML形式で記述した一例を示している。
【００６２】
MPD/Period/AdaptationSet/Representation/BaseURLには、コンテンツの複数のセグメントが１個のファイルに格納されている場合の該ファイルの供給元のアドレスが記述される。同図の場合、”http://example.com/counter-10mn_avc_dash.mp4”が該ファイルのアドレスを示している。
【００６３】
MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeには、該ファイルにおける、各セグメントのバイト範囲のシーケンスが記述される。
【００６４】
したがって、DASHクライアント７０が、ファイルのurlとして”http://example.com/counter-10mn_avc_dash.mp4”を指定するとともに、そのRangeヘッダにmediaRangeを指定してHTTPリクエストを発行すれば、目的のセグメントを取得することができる。
【００６５】
例えば、MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange=”795-83596”は、該ファイルにおけるバイト範囲795バイト目から83596バイト目までが１つ目のセグメントであることを示している。同様に、次のMPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange=”83597-166046”は、該ファイルにおけるバイト範囲83597バイト目から166046バイト目までが２つ目のセグメントであることを示している。
【００６６】
したがって、１つ目のセグメントを取得するためには、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
【００６７】
同様に、２つ目のセグメントを取得するためには、以下のHTTPリクエストを発行すればよい。
GET /counter-10mn_avc_dash.mp4 HTTP/1.1
Host: example.com
Range: bytes=83597-166046
【００６８】
［MPDの書換え］
本実施の形態においては、セグメント化されたコンテンツのストリームデータがHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信と、RTPによるブロードキャスト送信とにより受信側のDASHクライアント７０に供給される。さらに、DASHクライアント７０にてこれらがシームレスにスイッチングして受信、再生される。
【００６９】
これを実現するために、MPDにServiceLocation要素を新たに導入する。また、HTTPによりユニキャスト送信されるセグメントのバイト範囲に対応する、RTPによりマルチキャスト送信およびブロードキャスト送信されるストリームセグメントの区間を表すrtspRangeを追記する。
【００７０】
図９は、図８に示されたMPDを書き換えた例を示している。
【００７１】
具体的には、SegmentURL要素に、HTTPによりユニキャスト送信されるセグメントのスイッチング対象としての、RTPによりマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの区間を特定する属性としてrtspRange属性が配置される。さらに、ServiceLocation要素をルート要素として格納するServiceLocationAttributeファイルのurlが記述されるServiceLocationAttributeUrl属性がMPDのBaseURLに配置される。
【００７２】
書き換えられたMPDのSegmentURL要素のrtspRange属性には、RFC(Request For Comment)2326にて規定されるRTPストリーミングの制御に利用されるRTSP（Real Time Streaming Protocol）において定義されているRTPストリーム区間を識別するrangeパラメタのフォーマット（UTCフォーマット）の文字列が格納される。なお、rtspRange属性に格納する情報のフォーマットはUTCフォーマットに限定されるものではない。
【００７３】
例えば、図９の場合、HTTPによりユニキャスト送信されるファイルのバイト範囲795バイト目から83596バイト目までのデータから成る１つ目のセグメントには、RTPによりマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの19961108T143720.25Zから19961108T143730.25Zの表す区間が対応することを示している。
【００７４】
同様に、HTTPによりユニキャスト送信されるファイルのバイト範囲83597バイト目から166046バイト目までのデータから成る２つ目のセグメントには、RTPによりマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの19961108T143730.25Zから19961108T143740.25Zの表す区間が対応することを示している。
【００７５】
図１０は、serviceLocationAttributeUrl属性により指定されるServiceLocationAttributeファイルのXML schemaの一例を示している。
【００７６】
図１１は、MPDに新たに導入したServiceLocation要素を示している。
【００７７】
ServiceLocation要素は、チューニングパラメータ(DeliverySystemAttributes)およびIPマルチキャストアドレス(IPMulticastAddress)から成る。そして、該ServiceLocation要素をルート要素として格納するServiceLocationAttributeファイルのurlがBaseURLに配置されたServiceLocationAttributeUrl属性に記述される。
【００７８】
DeliverySystemAttributesのDeliverySystemIdentifierには、例えばMBMSなどのモバイルネットワークのマルチキャストベアラやブロードキャストベアラを利用する場合、MBMSなどによるマルチキャスト送信やブロードキャスト送信にて採用されているチューニングパラメタのデータ構造のフォーマット識別子（MBMSの場合、ID_MBMS）が記述される。
【００７９】
また、例えばDVB地上波網などの既存のテレビジョン放送網のブロードキャストベアラを利用する場合、DVB地上波網のブロードキャスト送信にて採用されているチューニングパラメタのデータ構造のフォーマット識別子（DVB地上波網の場合、ID_DVB_T）が記述される。
【００８０】
DeliverySystemAttributesのDeliverySystemDescriptorには、DeliverySystemIdentifierで識別される放送配信またはマルチキャスト配信にて規定されたチューニングパラメタのデータ構造(パラメタ自体)が記述される。なお、実際には、パラメータを表すバイト列がbase64等により文字列に変換されてDeliverySystemDescriptorに記述される。
【００８１】
図１２は、MBMSによるマルチキャスト送信やブロードキャスト送信にて採用されているチューニングパラメタとしてのUser Service Descriptionのデータ構造の例である。
【００８２】
bundleDescription(名前空間"urn:3GPP:metadata:2005:MBMS:userServiceDescription")は、userServiceDescription(名前空間"urn:3GPP:metadata:2005:MBMS:userServiceDescription")を複数束ねるための要素である。userServiceDescriptionは、serviceId属性で識別される、MBMSによるブロードキャスト送信またはマルチキャスト送信されるストリームを取得(チューン/join)するための情報を格納する要素である。
【００８３】
deliveryMethod(名前空間"urn:3GPP:metadata:2005:MBMS:userServiceDescription")は、ストリームのマルチキャストアドレスが記載されたSDP(Session Description Protocol)を指定する要素である。具体的には、sessionDescriptionURI属性によりSDPファイルのURLが指定される。Registration(名前空間"urn:3GPP:metadata:2008:MBMS:userServiceDescription")は、マルチキャストサービスに登録するために必要な、例えばストリームのプロテクションキー等を取得するためのプロセス(registrationURL属性にて指定されるサーバサイドスクリプトを起動して行われる認証セッション等にリンクされる(マルチキャストストリームが暗号化・保護されているような場合))である。
【００８４】
DeliveryServiceDescriptorの中に、上述したようなUserServiceDescription構造が格納されている場合には、MBMSサービスの規定に定義されているプロセスに従って利用登録を行えば、MBMSブロードキャストストリームまたはMBMSマルチキャストストリームを取得できるようになる。
【００８５】
上述したように、ServiceLocation/DeliverySystem要素に格納される情報により取得されるMBMSブロードキャストストリームまたはMBMSマルチキャストストリーム上でIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリームには、RTPによりコンテンツストリームが運ばれるものとする。図１３Ａは、この場合におけるプロトコルの階層構造を示している。
【００８６】
また、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地上波網によるブロードキャストストリームが取得される。
【００８７】
ここで、DVB_Tripletは、DVB-SIのネットワーク情報テーブルNITに格納されているオリジナルネットワーク識別子ONid、並びにDVB-SIのストリーム記述テーブルSDTに格納されているトランスポートストリーム識別子TSidおよびサービス識別子Sidの３項目の情報を指す。
【００８８】
上述したように、ServiceLocation/DeliverySystem要素に格納されるDVBurlフォーマットにより取得されるDVB地上波網によるブロードキャストストリーム上に転送されるIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリームには、RTPプロトコルによりコンテンツストリームが運ばれるものとする。図１３Ｂは、この場合におけるプロトコルの階層構造を示している。
【００８９】
［RTPパケットのデータ構造について］
ここで、コンテンツストリームをマルチキャスト送信する場合、およびブロードキャスト送信する場合に用いるRTPパケットについて説明する。
【００９０】
図１４は、RTPパケットのデータ構造を示している。同図に示されるように、RTPパケットは、RTPヘッダ８１とRTPペイロード８２で構成される。RTPヘッダ８１には、ペイロードタイプ（ＰＴ）８３、シーケンスナンバ（ＳＮ）８４、およびタイムスタンプ（ＴＳ）８５の各フィールドが設けられている。
【００９１】
ペイロードタイプ８３には、RTPペイロード８２に格納されるコンテンツの種類を示すための情報が記述される。本実施の形態の場合、RTPペイロード８２に格納されるコンテンツのコーデックの種類を示すための情報が記述される。具体的には、RTPペイロード８２にAVC fragmented MP4が格納される場合、"AVC fragmented MP4 over RTP"が記述され、RTPペイロード８２にHEVC fragmented MP4が格納される場合、"HEVC fragmented MP4 over RTP"が記述される。
【００９２】
シーケンスナンバ８４には、連続して送信されるRTPパケットのシーケンス番号が記述される。該シーケンス番号によりパケットロスの有無が検出される。
【００９３】
タイムスタンプ８５は、RTPパケットにおけるタイムスタンプの従来の運用とは異なり、該RTPパケットの送信時の最初のビットの送信時刻が、３２ビットのショートフォーマット（clause 6 of IETF RFC5905, NTP version 4 にて既定）のNTPタイムスタンプ値が記述される。ここで、RTPパケットにおけるタイムスタンプの従来の運用とは、RTPペイロード８２のペイロードデータの先頭バイトのサンプリング時刻のタイムスタンプを記述することを指す。
【００９４】
タイムスタンプ８５に記述されたNTPタイムスタンプ値は、主に転送上のジッタ除去に利用され、タイムスタンプの従来の運用のような提示時刻制御には利用されない。なお、本実施の形態の場合、提示時刻制御にはfragmented MP4のbox構造（図１５のmoof９７または図１６のmoof１０７）から導出されるタイムスタンプ値が利用される。
【００９５】
［RTPペイロード８２のデータ構造について］
図１５は、ペイロードタイプ８３が"AVC fragmented MP4 over RTP"である場合、すなわち、RTPペイロード８２にAVC fragmented MP4が格納される場合のRTPペイロード８２のフォーマットを示している。
【００９６】
同図Ａは、第１のモードのRTPペイロード８２のフォーマットを示している。第１のモードのRTPペイロード８２は、PayloadMode９１、SegmentBoundary９２、dash(ftyp)９３、moov９４、msix(styp)９５、sidx９６、moof９７、mdatのヘッダ（mdat-h）９８およびAVC over RTP payload９９で構成される。
【００９７】
PayloadMode９１は、モードを表すための１バイトの値である。いまの場合、第１のモードであることを表す値１が記述される。
【００９８】
SegmentBoundary９２には、該RTPパケットに格納されているコンテンツのセグメントの境界を表すための１バイトの識別子が記述される。該RTPパケットにコンテンツのセグメントの先頭のNAL(Network Abstraction Layer)ユニットが格納されている場合には１が、セグメントの最後のNALユニットが格納されている場合には３が、それ以外の場合には２が記述される。
【００９９】
dash(ftyp)９３およびmoov９４には、DASHにおけるデコーダ等の初期化情報が格納されているInitialization Segmentのftyp（ブラインド名dash）boxとmoov boxが配置される。
【０１００】
msix(styp)９５、sidx９６、moof９７、およびmdatのヘッダ９８には、DASHにおけるメディアデータのチャンク(fragment)が格納されているMedia Segmentのメタデータであるstyp（ブランド名misx）boxとsidx boxとmoof boxとmdat boxのメディアデータを含まないヘッダ情報のみが配置される。moof９７にはただ１つのtrackに関する情報が格納される。なお、DASHクライアント７０では、moof９７に格納されている情報に基づき、Payload dataの先頭バイトのサンプリング時刻を表すCompositionTimeがRTP Timestampとして導出される。
【０１０１】
AVC over RTP payload９９には、rfc(request for comment)3984にて規定されたRTPペイロードフォーマット仕様(RTP Payload Format for H.264 Video)に従った、分割された先頭のNALユニット、１つのNALユニット、または複数のNALユニットが格納される。
【０１０２】
同図Ｂは、第２のモードのRTPペイロード８２のフォーマットを示している。第２のモードのRTPペイロード８２は、PayloadMode９１、SegmentBoundary９２、msix(styp)９５、sidx９６、moof９７、およびAVC over RTP payload９９で構成される。
【０１０３】
第２のモードの場合、PayloadMode９１には、第２のモードであることを表す値２が記述される。また、AVC over RTP payload９９には、rfc3984にて規定されたRTPペイロードフォーマット仕様に従った、分割された先頭のNALユニット、１つのNALユニット、または複数のNALユニットが格納される。
【０１０４】
同図Ｃは、第３のモードのRTPペイロード８２のフォーマットを示している。第３のモードのRTPペイロード８２は、PayloadMode９１、SegmentBoundary９２、およびAVC over RTP payload９９で構成される。
【０１０５】
第３のモードの場合、PayloadMode９１には、第３のモードであることを表す値３が記述される。また、AVC over RTP payload９９には、rfc3984にて規定されたRTPペイロードフォーマット仕様に従った、分割されたNALユニット（先頭のものは除く）、１つのNALユニット、または複数のNALユニットが格納される。
【０１０６】
次に、図１６は、ペイロードタイプ８３が"HEVC fragmented MP4 over RTP"である場合、すなわち、RTPペイロード８２にHEVC fragmented MP4が格納される場合のRTPペイロード８２のフォーマットを示している。
【０１０７】
なお、RTPペイロード８２にHEVC fragmented MP4が格納される場合も、図１５に示された場合と同様、第１乃至第３のモードがあり、図１６Ａ乃至図１６Ｃに示されるとおりである。
【０１０８】
同図Ａは、第１のモードのRTPペイロード８２のフォーマットを示している。第１のモードのRTPペイロード８２は、PayloadMode１０１、SegmentBoundary１０２、dash(ftyp)１０３、moov１０４、msix(styp)１０５、sidx１０６、moof１０７、mdatのヘッダ（mdat-h）１０８およびHEVC over RTP payload１０９で構成される。
【０１０９】
PayloadMode１０１は、モードを表すための１バイトの値である。いまの場合、第１のモードであることを表す値１が記述される。
【０１１０】
SegmentBoundary１０２には、該RTPパケットに格納されているコンテンツのセグメントの境界を表すための１バイトの識別子が記述される。該RTPパケットにコンテンツのセグメントの先頭のNALユニットが格納されている場合には１が、セグメントの最後のNALユニットが格納されている場合には３が、それ以外の場合には２が記述される。
【０１１１】
dash(ftyp)１０３およびmoov１０４には、DASHにおけるデコーダ等の初期化情報が格納されているInitialization Segmentであるftyp（ブランド名dash）boxとmoov boxが配置される。
【０１１２】
msix(styp)１０５、sidx１０６、moof１０７およびmdatのヘッダ９８には、DASHにおけるメディアデータのチャンク(fragment)が格納されているMedia Segmentのメタデータであるstyp（ブランド名msix）boxとsidx boxとmoof boxとmdat boxのメディアデータを含まないヘッダ情報のみが配置される。moof１０７にはただ１つのtrackに関する情報が格納される。なお、DASHクライアント７０では、moof１０７に格納されている情報に基づき、Payload dataの先頭バイトのサンプリング時刻を表すCompositionTimeがRTP Timestampとして導出される。
【０１１３】
HEVC over RTP payload１０８には、draft-schierl-payload-rtp-h265-01にて規定されているRTPペイロードフォーマット仕様(RTP Payload Format for High Efficiency Video Coding)に従った、分割された先頭のNALユニット、１つのNALユニット、または複数のNALユニットが格納される。
【０１１４】
同図Ｂは、第２のモードのRTPペイロード８２のフォーマットを示している。第２のモードのRTPペイロード８２は、PayloadMode１０１、SegmentBoundary１０２、msix(styp)１０５、sidx１０６、moof１０７、およびHEVC over RTP payload１０９で構成される。
【０１１５】
第２のモードの場合、PayloadMode１０１には、第２のモードであることを表す値２が記述される。また、HEVC over RTP payload１０９には、draft-schierl-payload-rtp-h265-01にて規定されているRTPペイロードフォーマット仕様に従った、分割された先頭のNALユニット、１つのNALユニット、または複数のNALユニットが格納される。
【０１１６】
同図Ｃは、第３のモードのRTPペイロード８２のフォーマットを示している。第３のモードのRTPペイロード８２は、PayloadMode１０１、SegmentBoundary１０２、およびHEVC over RTP payload１０９で構成される。
【０１１７】
第３のモードの場合、PayloadMode１０１には、第３のモードであることを表す値３が記述される。また、HEVC over RTP payload１０９には、draft-schierl-payload-rtp-h265-01にて規定されているRTPペイロードフォーマット仕様に従った、分割されたNALユニット（先頭のものは除く）、１つのNALユニット、または複数のNALユニットが格納される。
【０１１８】
［RTPパケットの送信パターンについて］
図１７は、連続して送信されるRTPパケットのRTPペイロード８２に採用し得るフォーマット（第１乃至第３のモード）の組み合わせパターンの４つの例を示している。
【０１１９】
同図Ａに示される第１の組み合わせパターンは、連続して送信される全てのRTPパケットのRTPペイロード８２に第１のモードが採用されている。なお、第１の組み合わせパターンの場合、１つ目のRTPパケットから３つ目のRTPパケットまでが１つのセグメントであり、４つ目のRTPパケットと５つ目のRTPパケットが１つのセグメントである。
【０１２０】
同図Ｂに示される第２の組み合わせパターンは、連続して送信される１つ目から５つ目のRTPパケットのRTPペイロード８２に順に、第１のモード、第２のモード、第２のモード、第１のモード、第２のモードが採用されている。なお、第２の組み合わせパターンの場合、１つ目のRTPパケットから３つ目のRTPパケットまでが１つのセグメントであり、４つ目のRTPパケットと５つ目のRTPパケットが１つのセグメントである。
【０１２１】
同図Ｃに示される第３の組み合わせパターンは、連続して送信される１つ目から５つ目のRTPパケットのRTPペイロード８２に順に、第１のモード、第２のモード、第３のモード、第１のモード、第３のモードが採用されている。なお、第３の組み合わせパターンの場合、１つ目のRTPパケットから３つ目のRTPパケットまでが１つのセグメントであり、４つ目のRTPパケットと５つ目のRTPパケットが１つのセグメントである。
【０１２２】
同図Ｄに示される第４の組み合わせパターンは、連続して送信される１つ目から５つ目のRTPパケットのRTPペイロード８２に順に、第１のモード、第３のモード、第３のモード、第３のモード、第３のモードが採用されている。なお、第４の組み合わせパターンの場合、１つ目のRTPパケットから５つ目のRTPパケットまでが１つのセグメントである。
【０１２３】
なお、組み合わせパターンについては、図示したものに限るものではなく任意であるが、１つのセグメントが格納された１以上のRTPパケットのうちの１以上のもののRTPペイロード８２に第１のモードを採用する必要がある。
【０１２４】
［コンテンツ供給システム５０の動作］
次に、コンテンツ供給システム５０の動作について説明する。
【０１２５】
図１８は、コンテンツ供給システム５０の第１の動作を説明するフローチャートである。該第１の動作では、DASHクライアント７０からMPDコンフィギュレータ６５に対してMPDの書き換えが自発的に依頼される。
【０１２６】
なお、該第１の動作の前提として、DASHセグメントストリーマ６２は、コンテンツマネジメントサーバ６１から、同一内容のコンテンツのビットレートなどが異なる複数のストリーミングデータを取得、各ストリーミングデータをセグメント化して保持しており、それのHTTPによるユニキャスト送信を開始しているものとする。
【０１２７】
また、DASH MPDサーバ６３は、DASHセグメントストリーマ６２から通知されたストリームセグメントのファイルのアドレスに基づいてMPDを生成しており、それのHTTPによるユニキャスト送信を開始しているものとする。
【０１２８】
ステップＳ１において、コンテンツを受信、再生しようとするDASHクライアント７０は、インターネット１１を介してDASH MPDサーバ６３にアクセスしてMPDの送信を要求する。なお、DASHクライアント７０はDASH MPDサーバ６３のアドレスを予め知っているものとする。
【０１２９】
DASHクライアント７０からの要求に応じ、ステップＳ１１において、DASH MPDサーバ６３は、インターネット１１を介してDASHクライアント７０にMPDをHTTPによりユニキャスト送信する。
【０１３０】
MPDを受信したDASHクライアント７０は、該MPDに基づいてDASHセグメントストリーマ６２にアクセスし、HTTPによりユニキャスト送信されるストリームセグメントを受信、再生する。
【０１３１】
具体的には、MPDのBaseURLとmediaRangeに基づいてHTTPリクエストを発行して、DASHセグメントストリーマ６２にDASHストリームセグメントのファイルを要求する。この要求に応じ、DASHセグメントストリーマ６２は、対応するファイルをインターネット１１を介してDASHクライアント７０にHTTPによってユニキャスト送信し、これをDASHクライアント７０が受信して再生する。
【０１３２】
この受信の間、DASHクライアント７０は、ステップＳ２として、インターネット１１の通信帯域をモニタリングし、今後、インターネット１１を介したユニキャスト受信が不安定になりそうであり、かつ、DASHクライアント７０自身が放送網１２を介したコンテンツのマルチキャスト送信やブロードキャスト送信を受信可能である場合、MPDコンフィギュレータ６５に対して取得済みのMPDを送信し、該MPDの書き換えを要求する。
【０１３３】
DASHクライアント７０からのMPDの書き換え要求に応じ、ステップＳ２１において、MPDコンフィギュレータ６５は、ブロードキャスト／マルチキャストリソースマネージャ６６に対してブロードキャストベアラおよびマルチキャストベアラのリソースの利用状況を確認する。さらに、ブロードキャストベアラおよびマルチキャストベアラを併用することについてのコストを考慮してその利用を決定し、ブロードキャスト／マルチキャストリソースマネージャ６６に対して該リソースの確保を要求する。ブロードキャスト／マルチキャストリソースマネージャ６６から該リソースが確保できた旨の通知を受けた後、MPDコンフィギュレータ６５は、MPDを書き換えてDASHクライアント７０に送信する。なお、送信された、書き換えられたMPDは、DASHクライアント７０で受信される前に、DASHクライアントプロキシ６７にモニタリングされる。
【０１３４】
書き換えられたMPDをモニタリングしたDASHクライアントプロキシ６７は、ステップＳ３１において、ブロードキャスト／マルチキャストプロバイダ６８に対して、放送網１２のFLUTEにより該MPDの周期的なマルチキャスト送信を依頼する。この依頼に応じ、ステップＳ４１において、ブロードキャスト／マルチキャストプロバイダ６８は、書き換えられたMPDを、放送網１２のFLUTEにより周期的にマルチキャスト送信する。このマルチキャスト送信により、MPDの書き換えを要求していないDASHクライアント７０に対しても、書き換えられたMPDを供給することができる。
【０１３５】
ステップＳ３２において、DASHクライアントプロキシ６７は、モニタリングしたMPDに基づき、DASHクライアント７０の代わりにDASHセグメントストリーマ６２にストリームセグメントを要求する。この要求に応じたDASHセグメントストリーマ６２は、ステップＳ５１において、HTTPによりインターネット１１を介して、DASHクライアントプロキシ６７にストリームセグメントをユニキャスト送信する。
【０１３６】
DASHセグメントストリーマ６２からHTTPによりユニキャスト送信されたストリームセグメントを受信したDASHクライアントプロキシ６７は、ステップＳ３３において、HTTPのパケットに格納されている該ストリームセグメントをbox構造を外すことなくそのままRTPパケットのRTPペイロード８２に乗せ換えるプロトコル変換を行う。なお、このプロトコル変換は、図１５または図１６を参照して上述したように行なわれる。
【０１３７】
さらに、DASHクライアントプロキシ６７は、ブロードキャスト／マルチキャストプロバイダ６８に対して、プロトコル変換後のストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を依頼する。
【０１３８】
この依頼に応じ、ステップＳ４２において、ブロードキャスト／マルチキャストプロバイダ６８は、プロトコルが変換されたストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を開始する。
【０１３９】
なお、書き換えられたMPDを取得したDASHクライアント７０は、その後、ステップＳ３またはステップＳ５に進む。
【０１４０】
すなわち、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントの受信、再生を継続する場合、処理はステップＳ３に進むことになる。また、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントにスイッチングする場合、処理はステップＳ５に進むことになる。
【０１４１】
ユニキャスト送信されるストリームセグメントの受信、再生を継続する場合には、ステップＳ３において、DASHクライアント７０は、該MPDに基づいてDASHセグメントストリーマ６２にストリームセグメントを要求する。そして、ステップＳ４において、この要求に応じたDASHセグメントストリーマ６２からのHTTPによるインターネット１１を介したストリームセグメントのユニキャスト送信（ステップＳ５２の処理）を受信、再生する。
【０１４２】
RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントにスイッチングする場合には、ステップＳ５において、DASHクライアント７０は、書き換えられたMPDに基づき、HTTPによりユニキャスト送信されているセグメントストリームから、RTPによりマルチキャスト送信またはブロードキャスト送信されている、プロトコル変換されたストリームセグメントに受信、再生をスイッチングする。
【０１４３】
このスイッチングのタイミングは、書き換えられたMPD上のマルチキャストストリームに対応するRepresentationに対応するSegment列に格納されているrtspRangeの時間区間情報を頼りに、ユニキャストで運ばれるRepresentationに対応するSegment列との対応関係に基づいて決定される。
【０１４４】
なお、DASHクライアント７０における提示時刻制御には、RTPペイロード８２のmoof９７（またはmoof１０７）から導出されるタイムスタンプ値が利用される。
【０１４５】
この後においては、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。
【０１４６】
以上で、コンテンツ供給システム５０の第１の動作の説明を終了する。
【０１４７】
次に、図１９は、コンテンツ供給システム５０の第２の動作を説明するフローチャートである。該第２の動作では、MPDプロキシサーバ６４が主体となってMPDコンフィギュレータ６５に対してMPDの書き換えが依頼される。
【０１４８】
なお、該第２の動作の前提として、DASHセグメントストリーマ６２は、コンテンツマネジメントサーバ６１から、同一内容のコンテンツのビットレートなどが異なる複数のストリーミングデータを取得、各ストリーミングデータをセグメント化して保持しており、それらのHTTPによるユニキャスト送信を開始しているものとする。
【０１４９】
また、DASH MPDサーバ６３は、DASHセグメントストリーマ６２から通知されたストリームセグメントのファイルのアドレスに基づいてMPDを生成しており、それのHTTPによるユニキャスト送信を開始しているものとする。
【０１５０】
ステップＳ７１において、コンテンツを受信、再生しようとするDASHクライアント７０は、インターネット１１を介してDASH MPDサーバ６３にMPDを要求する。この要求は、MPDプロキシサーバ６４によって受信され、MPDプロキシサーバ６４は、ステップＳ８１において、DASH MPDサーバ６３にMPDを要求する。
【０１５１】
MPDプロキシサーバ６４からの要求に応じたDASH MPDサーバ６３は、ステップＳ９１において、MPDをMPDプロキシサーバ６４に対してHTTPによりユニキャスト送信する。該MPDを受信したMPDプロキシサーバ６４は、ステップＳ８２において、受信したMPDをMPDコンフィギュレータ６５に送信して該MPDの書き換えを要求する。
【０１５２】
MPDの書き換え要求に応じ、ステップＳ１０１において、MPDコンフィギュレータ６５は、ブロードキャスト／マルチキャストリソースマネージャ６６に対してブロードキャストベアラおよびマルチキャストベアラのリソースの利用状況を確認する。さらに、ブロードキャストベアラおよびマルチキャストベアラを併用することのコストを考慮して、その利用を決定し、ブロードキャスト／マルチキャストリソースマネージャ６６に対して該リソースの確保を要求する。ブロードキャスト／マルチキャストリソースマネージャ６６から該リソースが確保できた旨の通知を受けた後、MPDコンフィギュレータ６５は、MPDを書き換えてMPDプロキシサーバ６４に送信する。
【０１５３】
ステップＳ８３において、MPDプロキシサーバ６４は、書き換えられたMPDをDASHクライアント７０に送信する。なお、送信された、書き換えられたMPDは、DASHクライアント７０で受信される前に、DASHクライアントプロキシ６７にモニタリングされる。
【０１５４】
書き換えられたMPDをモニタリングしたDASHクライアントプロキシ６７は、ステップＳ１１１において、ブロードキャスト／マルチキャストプロバイダ６８に対して、放送網１２のFLUTEにより該MPDの周期的なマルチキャスト送信を依頼する。この依頼に応じ、ステップＳ１２１において、ブロードキャスト／マルチキャストプロバイダ６８は、書き換えられたMPDを、放送網１２のFLUTEにより周期的にマルチキャスト送信する。このマルチキャスト送信により、MPDの送信を要求していないDASHクライアント７０に対しても、書き換えられたMPDを供給することができる。
【０１５５】
ステップＳ１１２において、DASHクライアントプロキシ６７は、モニタリングした、書き換えられたMPDに基づき、DASHクライアント７０の代わりにDASHセグメントストリーマ６２にストリームセグメントを要求する。この要求に応じたDASHセグメントストリーマ６２は、ステップＳ１３１において、HTTPによりインターネット１１を介して、DASHクライアントプロキシ６７にストリームセグメントをユニキャスト送信する。
【０１５６】
DASHセグメントストリーマ６２からHTTPによりユニキャスト送信されたストリームセグメントを受信したDASHクライアントプロキシ６７は、ステップＳ１１３において、HTTPのパケットに格納されている該ストリームセグメントをbox構造を外すことなくそのままRTPパケットのRTPペイロード８２に乗せ換えるプロトコル変換を行う。なお、このプロトコル変換は、図１５または図１６を参照して上述したように行なわれる。
【０１５７】
さらに、DASHクライアントプロキシ６７は、ブロードキャスト／マルチキャストプロバイダ６８に対して、プロトコル変換後のストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を依頼する。
【０１５８】
この依頼に応じ、ステップＳ１２２において、ブロードキャスト／マルチキャストプロバイダ６８は、プロトコルが変換されたストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を開始する。
【０１５９】
一方、DASHクライアント７０は、書き換えられたMPDを既に取得している。ステップＳ７２において、DASHクライアント７０は、インターネット１１の通信帯域の状態、自身の受信機能、デコード機能などに基づいて、インターネット１１を介するユニキャスト送信を受信するか、放送網１２を介するマルチキャスト送信またはブロードキャスト送信を受信するかを選択する。
【０１６０】
HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントの受信、再生を行うことが選択された場合、処理はステップＳ７３に進められる。ステップＳ７３において、DASHクライアント７０は、該MPDに基づいてDASHセグメントストリーマ６２にストリームセグメントを要求する。そして、ステップＳ７４において、この要求に応じたDASHセグメントストリーマ６２からのHTTPによるインターネット１１を介したストリームセグメントのユニキャスト送信（ステップＳ１３２の処理）を受信、再生する。
【０１６１】
また、ステップＳ７２において、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントの受信、再生を行うことが選択された場合、処理はステップＳ７５に進められる。ステップＳ７５において、DASHクライアント７０は、書き換えられたMPDに基づき、RTPによりマルチキャスト送信またはブロードキャスト送信された、プロトコル変換されたストリームセグメントを受信、再生する。
【０１６２】
なお、DASHクライアント７０における提示時刻制御には、RTPペイロード８２のmoof９７（またはmoof１０７）から導出されるタイムスタンプ値が利用される。
【０１６３】
この後においては、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。
【０１６４】
以上で、コンテンツ供給システム５０の第２の動作の説明を終了する。
【０１６５】
以上説明したように、本実施の形態であるコンテンツ供給システム５０によれば、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。したがって、DASHクライアント７０のユーザは、同一内容のコンテンツであってパスが異なるストリームを適応的に選択し、視聴することができる。
【０１６６】
また、本実施の形態であるコンテンツ供給システム５０によれば、HTTPによりユニキャスト送信されるストリームセグメントをbox構造を壊すことなくそのままRTPパケットに格納してマルチキャスト送信したりブロードキャスト送信したりすることができる。したがって、コンテンツの供給側は、容易にDASHにおける代替パスを用意することができる。
【０１６７】
ところで、上述した一連の処理を実行するコンテンツ供給装置６０、およびDASHクライアント７０は、それぞれをハードウェアにより構成する他、コンピュータがソフトウェアを実行することにより実現することもできる。このコンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
【０１６８】
図２０６は、上述したコンピュータのハードウェアの構成例を示すブロック図である。
【０１６９】
このコンピュータ２００において、CPU（Central Processing Unit）２０１，ROM（Read Only Memory）２０２，RAM（Random Access Memory）２０３は、バス２０４により相互に接続されている。
【０１７０】
バス２０４には、さらに、入出力インタフェース２０５が接続されている。入出力インタフェース２０５には、入力部２０６、出力部２０７、記憶部２０８、通信部２０９、およびドライブ２２０が接続されている。
【０１７１】
入力部２０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部２０７は、ディスプレイ、スピーカなどよりなる。記憶部２０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部２０９は、ネットワークインタフェースなどよりなる。ドライブ２２０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア２１１を駆動する。
【０１７２】
以上のように構成されるコンピュータ２００では、CPU２０１が、例えば、記憶部２０８に記憶されているプログラムを、入出力インタフェース２０５およびバス２０４を介して、RAM２０３にロードして実行することにより、上述した一連の処理が行われる。
【０１７３】
コンピュータ２００（CPU２０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア２１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
【０１７４】
コンピュータ２００では、プログラムは、リムーバブルメディア２１１をドライブ２２０に装着することにより、入出力インタフェース２０５を介して、記憶部２０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部２０９で受信し、記憶部２０８にインストールすることができる。その他、プログラムは、ROM２０２や記憶部２０８に、あらかじめインストールしておくことができる。
【０１７５】
なお、コンピュータ２００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであってもよい。
【０１７６】
なお、本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
【０１７７】
なお、本開示は以下のような構成も取ることができる。
（１）
MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置において、
前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
を備えるコンテンツ供給装置。
（２）
前記コンテンツのストリーミングデータはfragmented MP4であり、
前記RTP送信部は、前記セグメントファイルを前記fragmented MP4のbox構造を維持したまま前記RTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信する
前記（１）に記載のコンテンツ供給装置。
（３）
前記RTP送信部は、前記RTPパケットのRTPヘッダのタイムスタンプフィールドに、前記RTPパケットの送信時の先頭のビットの送信時刻を記述する
前記（１）または（２）に記載のコンテンツ供給装置。
（４）
前記RTP送信部は、前記RTPパケットのRTPペイロードに、前記RTPペイロードのモードを表す情報と、セグメントの境界を表す情報とを記述し、ペイロードデータにNALユニットを配置する
前記（１）から（２）のいずれかに記載のコンテンツ供給装置。
（５）
前記RTP送信部は、さらに、前記RTPパケットのRTPペイロードに、前記MPEG-DASH で規定されているInitialization SegmentとMedia Segmentのメタデータの両方を配置するか、前記Media Segmentのメタデータを配置するか、または前記Initialization Segmentと前記Media Segmentのメタデータの両方を配置しない
前記（４）に記載のコンテンツ供給装置。
【符号の説明】
【０１７８】
１１  インターネット，  １２  放送網，  ５０  コンテンツ供給システム，  ６０  コンテンツ供給装置，  ６１  コンテンツマネジメントサーバ，  ６２  DASHセグメントストリーマ，  ６３  DASH MPDサーバ，  ６４  MPDプロキシサーバ，  ６５  MPDコンフィギュレータ，  ６６  ブロードキャスト／マルチキャストリソースマネージャ，  ６７  DASHクライアントプロキシ，  ６８  ブロードキャスト／マルチキャストサービスプロバイダ，  ７０  DASHクライアント，  ２００  コンピュータ，  ２０１  CPU
【図１】
2014230055.tif 000003
【図２】
2014230055.tif 000004
【図３】
2014230055.tif 000005
【図４】
2014230055.tif 000006
【図５】
2014230055.tif 000007
【図６】
2014230055.tif 000008
【図７】
2014230055.tif 000009
【図８】
2014230055.tif 000010
【図９】
2014230055.tif 000011
【図１０】
2014230055.tif 000012
【図１１】
2014230055.tif 000013
【図１２】
2014230055.tif 000014
【図１３】
2014230055.tif 000015
【図１４】
2014230055.tif 000016
【図１５】
2014230055.tif 000017
【図１６】
2014230055.tif 000018
【図１７】
2014230055.tif 000019
【図１８】
2014230055.tif 000020
【図１９】
2014230055.tif 000021
【図２０】
2014230055.tif 000022