(57)【要約】  本技術は、放送配信またはネット配信の少なくとも一方で配信される映像のROI識別子をシグナリングすることができるようにする配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システムに関する。本技術の第１の側面である配信装置は、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部とを備える。本技術は、DASHを用いたストリーミング配信に適用できる。
2018043134.tif 000002
【特許請求の範囲】
【請求項１】
複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
を備える配信装置。
【請求項２】
前記通知部は、前記セグメントファイルに関する前記属性情報として、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を受信側に通知する
請求項１に記載の配信装置。
【請求項３】
前記通知部は、前記セグメントファイルに関する前記属性情報を、DASHで規定されているMPDに記載して受信側に通知する
請求項２に記載の配信装置。
【請求項４】
前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、USDに記載して受信側に通知する
請求項２に記載の配信装置。
【請求項５】
前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、EFDTに記載して受信側に通知する
請求項２に記載の配信装置。
【請求項６】
前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、Entityヘッダに記載して受信側に通知する
請求項２に記載の配信装置。
【請求項７】
前記撮像範囲には１以上の前記ROIが設定される
請求項２に記載の配信装置。
【請求項８】
前記配信部は、全て前記領域のそれぞれ対応する前記映像ストリームのセグメントファイルをネット配信するとともに、前記ROIを成す領域に対応するセグメントファイルを放送配信する
請求項２に記載の配信装置。
【請求項９】
配信装置の配信方法において、
前記配信装置による、
複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信ステップと、
前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知ステップと
を含む配信方法。
【請求項１０】
コンピュータを、
複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
して機能させるプログラム。
【請求項１１】
複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、
前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
取得された前記セグメントファイルを再生する再生部と
を備える受信装置。
【請求項１２】
前記要求部は、ユーザからの操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
請求項１１に記載の受信装置。
【請求項１３】
前記要求部は、画面上の被写体を指定する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
請求項１２に記載の受信装置。
【請求項１４】
前記要求部は、被写体のメタデータを選択する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
請求項１３に記載の受信装置。
【請求項１５】
前記属性情報は、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を含み、
前記取得部は、前記配信モード情報に基づき、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する
請求項１２に記載の受信装置。
【請求項１６】
前記解析部による前記属性情報の解析結果は、SANDメッセージを用いて前記要求部に通知される
請求項１２に記載の受信装置。
【請求項１７】
受信装置の受信方法において、
前記受信装置による、
複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析ステップと、
前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求ステップと、
要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得ステップと、
取得された前記セグメントファイルを再生する再生ステップと
を含む受信方法。
【請求項１８】
コンピュータを、
複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、
前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
取得された前記セグメントファイルを再生する再生部と
して機能させるプログラム。
【請求項１９】
配信装置と受信装置を含むコンテンツ配信システムにおいて、
前記配信装置は、
複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
を備え、
前記受信装置は、
前記配信装置から通知された前記属性情報を解析する解析部と、
前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
取得された前記セグメントファイルを再生する再生部と
を備える
コンテンツ配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システムに関し、特に、より多くのユーザの視聴される可能性が高い等の優先度が高い画像領域を放送にて配信し、その他の画像領域をオンデマンド配信する場合に用いて好適な配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システムに関する。
【背景技術】
【０００２】
IPTV等のインターネットストリーミングにおける標準化の流れとして、HTTPストリーミングによるVoD(Video on Demand)ストリーミングや、ライブストリーミング等に適用される方式の標準化が行われており、特にISO/IEC/MPEGで標準化が行われているDASH(Dynamic Adaptive Streaming over HTTP)が注目されている（例えば、非特許文献１を参照）。【０００３】
該DASHのユースケースとして、撮像空間を複数の矩形領域に分割して撮像し、各矩形領域の映像それぞれをDASHのAdaptationSetに割り当てて自由視点風ストリーミングサービスを提供することを考える。【０００４】
該自由視点風ストリーミングサービスを放送配信とオンデマンド配信（以下、ネット配信とも称する）を組合せて実現する場合、数多くのエンドユーザ（受信装置のユーザ）が共通して視聴する可能性が高い映像のストリームを放送配信によって提供し、数多くのユーザが共通して視聴する可能性が低い映像のストリームをネット配信によって提供するようにすれば、配信リソースの有効利用を図ることができる。【０００５】
ここで、数多くのユーザが共通して視聴する可能性が高い映像とは、撮像範囲全体の映像や、放送局等によって指定されるROI(Region Of Interest)のエリア（１または隣接する複数の矩形領域から成る）の映像等である。一方、数多くのユーザが共通して視聴する可能性が低く、特定のユーザによって視聴され得る映像とは、その他の矩形領域の映像等である。【０００６】
該自由視点風ストリーミングサービスによれば、ユーザは、任意の矩形領域（または隣接する複数の矩形領域）を指定することにより、撮像空間のうちの関心がある領域の動画のみを視聴することが可能となる。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEIELECTRONICS 2012.3.19
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、米国次期デジタルテレビ規格であるATSC3.0にてDASHを採用し、上述した自由視点風ストリーミングサービスを実現する場合、各矩形領域の映像が放送配信されるのか、ネット配信されるのかを示す配信モード情報や、各矩形領域の映像のROI識別子（どのROIに属しているかを示す情報）を、放送シグナリングのレベルで認識させることができるようにしておけば、放送配信リソース(帯域や受信スタックでの計算処理等)を割り当てる優先度付けの指標として利用することができる。【０００９】
しかしながら、現状においてこれらのROI識別子をシグナリングする方法については確立されていない。【００１０】
本技術はこのような状況に鑑みてなされたものであり、放送配信またはネット配信の少なくとも一方で配信される映像のROI識別子をシグナリングできるようにするものである。
【課題を解決するための手段】
【００１１】
本技術の第１の側面である配信装置は、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部とを備える。【００１２】
前記通知部は、前記セグメントファイルに関する前記属性情報として、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を受信側に通知することができる。【００１３】
前記通知部は、前記セグメントファイルに関する前記属性情報を、DASHで規定されているMPDに記載して受信側に通知することができる。【００１４】
前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、USDに記載して受信側に通知することができる。【００１５】
前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、EFDTに記載して受信側に通知することができる。【００１６】
前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、Entityヘッダに記載して受信側に通知することができる。【００１７】
前記撮像範囲には１以上の前記ROIが設定されているようにすることができる。【００１８】
前記配信部は、全て前記領域のそれぞれ対応する前記映像ストリームのセグメントファイルをネット配信するとともに、前記ROIを成す領域に対応するセグメントファイルを放送配信することができる。【００１９】
本技術の第１の側面である配信方法は、配信装置による、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信ステップと、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知ステップとを含む。【００２０】
本技術の第１の側面であるプログラムは、コンピュータを、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部として機能させる。【００２１】
本技術の第１の側面においては、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームがセグメントファイル化され、前記領域毎の前記映像ストリームのセグメントファイルがネット配信または放送配信の少なくとも一方により受信側に供給され、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子が受信側に通知される。【００２２】
本技術の第２の側面である受信装置は、複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、取得された前記セグメントファイルを再生する再生部とを備える。【００２３】
前記要求部は、ユーザからの操作によって特定されるROI識別子に対応する前記セグメントファイルを要求することができる。【００２４】
前記要求部は、画面上の被写体を指定する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求することができる。【００２５】
前記要求部は、被写体のメタデータを選択する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求することができる。【００２６】
前記属性情報は、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を含むことができ、前記取得部は、前記配信モード情報に基づき、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得することができる。【００２７】
前記解析部による前記属性情報の解析結果は、SANDメッセージを用いて前記要求部に通知されるようにすることができる。【００２８】
本技術の第２の側面である受信方法は、受信装置による、複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析ステップと、前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求ステップと、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得ステップと、取得された前記セグメントファイルを再生する再生ステップとを含む。【００２９】
本技術の第２の側面であるプログラムは、コンピュータを、複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、取得された前記セグメントファイルを再生する再生部として機能させる。【００３０】
本技術の第２の側面においては、属性情報が解析され、前記属性情報の解析結果に基づき、所定のROI識別子に対応するセグメントファイルが要求され、要求された前記所定のROI識別子に対応する前記セグメントファイルがネット配信または放送配信を介して取得され、取得された前記セグメントファイルが再生される。【００３１】
本技術の第３の側面であるコンテンツ配信システムは、配信装置と受信装置を含むコンテンツ配信システムにおいて、前記配信装置が、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部とを備える。また、前記受信装置が、前記配信装置から通知された前記属性情報を解析する解析部と、前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、取得された前記セグメントファイルを再生する再生部とを備える。【００３２】
本技術の第３の側面においては、配信装置による、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームがセグメントファイル化され、前記領域毎の前記映像ストリームのセグメントファイルがネット配信または放送配信の少なくとも一方により受信側に供給され、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子が受信側に通知される。また、受信装置により、配信装置から通知された属性情報が解析され、前記属性情報の解析結果に基づき、所定のROI識別子に対応するセグメントファイルが要求され、要求された前記所定のROI識別子に対応する前記セグメントファイルがネット配信または放送配信を介して取得され、取得された前記セグメントファイルが再生される。
【発明の効果】
【００３３】
本技術の第１の側面によれば、放送配信またはネット配信の少なくとも一方で配信される映像のROI識別子をシグナリングすることが可能となる。【００３４】
本技術の第２の側面によれば、特定のROIに属する領域のセグメントファイルを取得し、再生することができる。【００３５】
本技術の第３の側面によれば、放送配信またはネット配信の少なくとも一方で配信される映像のROI識別子をシグナリングすることができ、受信側では、特定のROIに属する領域のセグメントファイルを取得し、再生することができる。
【図面の簡単な説明】
【００３６】
【図１】コンテンツ配信システムの構成例を示すブロック図である。
【図２】MPDのデータ構造を示す図である。
【図３】Representationの例を示す図である。
【図４】MPDにおけるPeriod以下の階層構造を示す図である。
【図５】時間軸上にMPDの構造を並べた状態を示す図である。
【図６】コンテンツ配信システムのより詳細な構成例を示すブロック図である。
【図７】本技術を適用したクライアント装置の構成例を示すブロック図である。
【図８】PERメッセージについて説明するための図である。
【図９】ResourceStatusの各要素を説明する図である。
【図１０】ROUTE/DASHベースのスタックを示す図である。
【図１１】ROUTE プロトコルが用いられた場合に対応するクライアント側の動作を説明するための図である。
【図１２】撮像空間全体と矩形領域とエリアの関係を示す図である。
【図１３】撮像空間全体と矩形領域とエリアの関係を示す図である。
【図１４】図１１に示されたROI の移動に対応して放送配信されるSegmentが変化する様子を示す図である。
【図１５】画像全体を４個の矩形領域に分割した場合を示す図である。
【図１６】図１４に対応する各Segmentの放送配信併用の有無とROI識別子を示す図である。
【図１７】図１６に対応するMPD-SRD表現を示す図である。
【図１８】画像全体とそこにおける矩形領域の位置と解像度を示す図である。
【図１９】MPDの拡張位置を示す図である。
【図２０】MPDの拡張位置を示す図である。
【図２１】拡張したMPDに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示す図である。
【図２２】MPDに配信モード情報とROI識別子を格納した場合における動作シーケンスを示す図である。
【図２３】SegmentTemplateを利用して書き換えたMPD-SRD表現を示す図である。
【図２４】図２３のMPD-SRD表現を説明するための図である。
【図２５】USDの拡張位置を示す図である。
【図２６】拡張したUSDに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示す図である。
【図２７】配信モード情報とROI識別子を格納したResourceStatusメッセージの具体例を示す図である。
【図２８】USDに配信モード情報とROI識別子を格納した場合における動作シーケンスを示す図である。
【図２９】EFDTの拡張位置を示す図である。
【図３０】拡張したEFDTに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示す図である。
【図３１】EFDTに配信モード情報とROI識別子を格納した場合における動作シーケンスを示す図である。
【図３２】拡張したEntityヘッダに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示す図である。
【図３３】Entityヘッダに配信モード情報とROI識別子を格納した場合における動作シーケンスを示す図である。
【図３４】クライアント装置におけるROI識別子の利用例を示す図である。
【図３５】汎用のコンピュータの構成例を示すブロック図である。
【発明を実施するための形態】
【００３７】
以下、本技術を実施するための最良の形態（以下、実施の形態と称する）について、図面を参照しながら詳細に説明する。なお、説明は、以下の順序で行なう。
１．＜DASHを採用したコンテンツ配信システムの構成例＞
２．＜本技術を適用したクライアント装置の構成例＞
３．＜PERメッセージについて＞
４．＜MPDに配信モード情報とROI識別子を格納する場合＞
５．＜MPDにSegmentTemplateを利用する場合の対応＞
６．＜USDに配信モード情報とROI識別子を格納する場合＞
７．  ＜EFDTの拡張＞
８．  ＜Entityヘッダの拡張＞
９．  ＜クライアント装置におけるROI識別子の利用例＞
【００３８】
＜DASHの概要説明＞
始めに、DASHの概要について説明する。図１は、DASHを採用したコンテンツ配信システムの構成例を示している。同図左側に示すMedia Presentation on HTTP Serverはコンテンツの配信側であり、同図右側に示すHTTP Streaming Clientがコンテンツの受信側であって、受信したコンテンツのストリームを受信して再生し、ユーザに提示することができる。
【００３９】
配信側のMedia Presentation on HTTP Serverは、同一内容のコンテンツであって、パスとなる地上デジタル放送や衛星放送等の放送網、インターネット等の双方向通信網、3GPPやLTE-eMBMS等の携帯電話通信網の通信環境や受信側の能力や状態に応じて画質や画角サイズなどが変更されている複数のストリームを用意し、供給することができる。
【００４０】
また、Media Presentation on HTTP Serverは、同一コンテンツの撮像領域全体の映像や撮像領域を複数に分割した各矩形領域の映像、すなわち、同一のコンテンツに属するが内容が異なる映像を、パスの通信環境や受信側の能力や状態に応じて画質や画角サイズなどが変更されている複数のストリームを用意し、供給することができる。
【００４１】
一方、受信側のHTTP Streaming Clientは、配信側が用意している複数のストリームのうち、パスの通信環境や受信側の能力や状態などに応じて最適なストリームを選択して取得、再生することができる。
【００４２】
このように、DASHにおいては、受信側がストリームを適応的に選択して取得できるように、MPD(Media Presentation Description)と称されるメタデータがコンテンツの配信側から受信側に供給される。
【００４３】
MPDには、チャンク化されたストリーム(Audio/Video/Subtitle等のメディアデータ)のアドレス(url情報)が記述されており、受信側は該url情報に基づいて、コンテンツの供給元となる所定のサーバにアクセスし、HTTP配信されるストリーミングデータを取得、再生することができる。
【００４４】
なお、配信側に比較して圧倒的に数が多い受信側のHTTP Streaming Clientがコンテンツの供給元となる同一のサーバに対して同一のストリームを要求することが起こり得る。そのような場合、各HTTP Streaming Clientからの供給に応じてその都度、同一のストリームを送信していては通信効率が悪いので、インターネット上などにいわゆるプロキシサーバを設けることがある。
【００４５】
図２は、コンテンツの配信側から受信側に供給されるメタデータとしてのMPDのデータ構造を示している。
【００４６】
MPDは、コンテンツに関する情報がPeriod毎に区分されている。各Periodには、同一内容であって画質や画角サイズ、言語等が変更されているビットレートなどのストリーム属性の異なる同期されたストリーミングデータに関する情報からなる複数のRepresentationをグルーピングするAdaptationSetが用意されている。Representationには、Periodをさらに時間的に分割したSegmentに関する情報が格納されている。
【００４７】
なお、Periodは、コンテンツの時間的な区切りの単位である。Segmentは、Periodを時間的により細分化した単位であり、コンテンツのストリームは、Segmentの単位でSegmentファイルにファイル化されている。
【００４８】
各SegmentファイルはURL(+バイトレンジ)で特定される。SegmentはRepresentationの一部であり、１つのRepresentationは以下のいずれかで構成される。
（１）１つまたはそれ以上のSegmentList
（２）１つのSegmentTemplate
（３）１つまたはそれ以上のBaseURLと、最大１つSegmentBase(この場合はSegmentListおよびSegmentTemplateは含まない)
【００４９】
図３は、上記（１）乃至（３）に該当するRepresentationの例を示している。
【００５０】
上記（３）におけるSegmentBaseは、同図Ａに示されるように、１つのRepresentationに１つのMediaSegmentしかない場合に利用される。この場合、初期化情報のバイト列とRandom Access Points (RAP)のバイト列がファイルの最初の834バイト(SegmentBaseのindexRangeで記述する)以内に収められている。
【００５１】
上記（１）におけるSegmentListは、同図Ｂに示されるように、再生順に配置される複数のSegmentURLで構成される。SegmentURLはSegmentファイルのURL(+そのファイル内のバイトレンジ)により表現される。SegmentListの最初に配置されているInitilizationは、初期化情報が格納されているファイル(InitSegment)を指示する。
【００５２】
上記（２）におけるSegmentTemplateは、SegmentTemplateに基づいてSegmentURLを自動的に生成するとき(ライブストリーミングが典型的なユースケース)に利用される。すなわち、受信側において、SegmentTemplateに記載されるSegmentURLのひな形に含まれる所定のパラメータを動的に置き換えていくことにより、完全なSegmentURLのリストを生成する。SegmentTemplateを利用することによりMPDのサイズを非常に小さくすること可能となる。
【００５３】
例えば、同図Ｃに示されるようなSegmentTemplateが利用された場合、ReplacementParameterである$Number$を、StartNumberで示される値を初期値として１ずつインクリメントした値に置き換えることにより、同図Ｄに示されるようなSegmentURLを生成する。
【００５４】
図４は、MPDにおけるPeriod以下の階層構造を示している。なお、MPDは、例えばXML形式で記述される。Periodの下層には、ストリームの選択範囲となるRepresentation群をグルーピングする情報であるAdaptationSetが記述される。AdaptationSetの下層には、動画や音声のビットレート、画角サイズ、言語などを表す情報を含むRepresentationが記述される。Representationの下層には、動画や音声のSegment関連の情報であるSegmentinfoが記述される。Segmentinfoの下層には、データ圧縮方式などの初期化情報を表すInitialization Segment、および、動画や音声のSegment単位のデータの供給元を表すMedia Segmentが記述される。
【００５５】
受信側では、MPDのPeriodに含まれるRepresentationの属性に基づいて受信、再生に最適なRepresentationを選択し、選択したRepresentationの先頭のSegmentからInitialization Segmentを取得してデータ圧縮方式などを判断した後、後続のsegmentを要求、取得し、再生を行うことができる。
【００５６】
図５は、時間軸上にMPDの構造を並べた状態を示している。同図から明らかなように、同一のAdaptationSetに含まれるストリーム属性が異なる各RepresentationのSegmentどうしは同期したものとなる。
【００５７】
上述したように、同一コンテンツの撮像領域全体の映像や撮像領域を複数に分割した各矩形領域の映像のストリームは、それぞれ異なるAdaptationSetに属しているが、その場合でも、異なるAdaptationSetに含まれる各RepresentationのSegmentどうしも同期したものとなる。
【００５８】
次に、図６は、DASHを採用したコンテンツ配信システムのより詳細な構成例を示している。
【００５９】
図６におけるDASHサーバ、Webサーバ、および放送サーバは、図１におけるMedia Presentation on HTTP Serverに相当する。また、図６におけるDASHクライアントは、図１におけるHTTP Streaming Clientに相当する。
【００６０】
DASHサーバおよびWebサーバに対し、DASHクライアントは、インターネット上に形成されたCDN(Content Delivery Network)を介してアクセスできる。CDNにはDASHキャッシュサーバ（プロキシサーバ）が設けられている。
【００６１】
DASHサーバは、MPDを生成して放送サーバに転送するとともに、ストリームのSegmentファイルを生成してWebサーバに転送する。また、DASHサーバは、DASHクライアントからのHTTPリクエストに応じ、生成したMPDをCDN(Content Delivery Network)を介してネット配信する。Webサーバは、MPDを参照してストリームの取得先を選択したDASHクライアントからのHTTPリクエストに応じ、CDNを介してSegmentファイルをネット配信する。放送サーバは、MPDを放送配信する。また、放送サーバは、Segmentファイルを放送配信する。
【００６２】
DASHキャッシュサーバは、CDNを監視し、DASHクライアントに対してCDNを介して配信されるSegmentファイルを一時的にキャッシュする。そして、DASHキャッシュサーバは、DASHクライアントからキャッシュしているSegmentファイルを要求するHTTPリクエストがWebサーバに送信された場合、Webサーバに代わって、キャッシュしているSegmentファイルを要求元のMPDクライアントに配信する。
【００６３】
なお、DASHキャッシュサーバは、ストリームのSegmentファイルだけでなく、MPDも一時的にキャッシュすることができ、DASHサーバの代わりに、キャッシュしているMPDを要求元のDASHクライアントに供給することができる。また、DASHキャッシュサーバが放送配信されるMPDやSegmentファイルを受信、キャッシュできるようにしてもよい。
【００６４】
CDN上にDASHキャッシュサーバを設けたことにより、該コンテンツ配信システムでは、大多数のDASHクライアントに対するHTTPストリーミングの配信効率を向上させることができる。
【００６５】
＜本技術を適用したクライアント装置の構成例＞
次に、図７は、ATSC3.0においてDASHを採用し、自由視点風ストリーミングサービスを実現する場合における受信側のクライアント装置の構成例を示している。
【００６６】
該クライアント装置１００は、ATSC3.0以外の規格においてDASHを採用したストリーミング配信サービスを実現する場合にも適用することが可能である。
【００６７】
クライアント装置(3.0 Client(with ATSC3.0 PHY/MAC))１００は、例えば、一般家屋に設置されたり、自動車等の移動体に搭載されたりするテレビジョン受像機やビデオレコーダ、セットトップボックスに内蔵されることを想定したものである。
【００６８】
クライアント装置１００は、放送受信部（Client ATSC Middleware）１１０、通信部(Ethernet/WiFi etc.)１２０、プロキシサーバ部（Client Local HTTP Proxy Server）１３０、およびDASHクライアント部(3.0 DASH Client)１４０を備える。
【００６９】
放送受信部１１０は、Broadcaster１０（図６の放送サーバに相当）から、地上デジタル放送または衛星放送などの放送網１１を介して配信されるMPD、ストリームのSegmentファイル、SLSファイル等を受信する処理を実行する。
【００７０】
放送受信部１１０は、放送波を受信するチューナ部１１１、放送波からSegmentファイルを抽出するSegment Retriever１１２、放送波からLLS(Low Level Signaling)ファイルを抽出するLLS Signaling Retriever１１３、およびLLSファイルを解析するLLS Signaling Parser１１４を備える。さらに、放送受信部１１０は、放送波からSLS(Service Layer Signaling)ファイルを抽出するSLS Signaling Retriever１１５、およびSLSファイルを解析するSLS Signaling Parser１１６を備える。
【００７１】
通信部１２０は、インターネットなどの双方向通信網に形成されているCDN１２を介し、Broadcaster１０（（図６のDASHサーバおよびWebサーバに相当））に対してMPD、ストリームのSegmentファイル、SLSファイルを要求し（HTTPリクエストを送信し）、それに応じてHTTP配信されるMPDやSegmentファイルを受信する処理を実行する。
【００７２】
プロキシサーバ部１３０は、放送網１１を介して受信された各種ファイルをキャッシュするProxy Cache１３１、CDN１２を介して受信された各種ファイルをキャッシュするProxy Cache１３２、および、DASHクライアント部１４０からの要求に対応するBroadcast/Broadband Address Resolver１３３を備える。
【００７３】
Broadcast/Broadband Address Resolver１３３は、Proxy Cache１３１または１３２にキャッシュされているMPDやSegmentファイルを、DASHクライアント部１４０からの要求に応じてそれらを供給する処理を実行する。
【００７４】
さらに、Broadcast/Broadband Address Resolver１３３は、放送受信部１１０や通信部１２０によるSegmentファイルの受信状態などを表す供給可否情報を、PERメッセージを用いてDASHクライアント部１４０に通知する処理を実行する。
【００７５】
またさらに、Broadcast/Broadband Address Resolver１３３は、各Segmentファイルがネット配信とともに放送配信されるか否かを示す放送配信併用情報と、各SegmentファイルがROIに属している場合にその所属を表すROI識別子を、PERメッセージを用いてDASHクライアント部１４０に通知する処理を実行する。PERメッセージの詳細については後述する。
【００７６】
DASHクライアント部１４０は、MPDを要求、取得するMPD Retriever１４１、MPDを解析するMPD Parser１４２、MPDを参照してSegmentファイルを要求、取得するSegment Retriever１４３、およびSegmentファイルからMP4データを抽出、解析するMP4 Parser１４４を備える。さらに、DASHクライアント部１４０は、MP4データをデコードするDecoder１４５、およびデコード結果をレンダリングするRenderer１４６を備える。
【００７７】
DASHクライアント部１４０は、例えば、クライアント装置１００に実装されたブラウザ上で実現される。ただし、ブラウザアプリケーションとしてだけではなくネイティブアプリケーションとして実現するようにしてもよい。DASHクライアント部１４０は、プロキシサーバ部１３０を介して、放送受信部１１０または通信部１２０が受信したMPD、Segmentファイル、SLSファイル等を取得し、ストリームのレンダリングやアプリケーションの制御を行うことにより、ストリームの映像および音声を後段のモニタ（不図示）に出力する処理を実行する。
【００７８】
なお、DASHクライアント部１４０は、クライアント装置１００のみならず、クライアント装置１００に対してLAN２０を介して接続されているクライアント装置２００に実装することができる。クライアント装置２００は、例えば、スマートフォン、タブレットなどを想定したものである。
【００７９】
クライアント装置２００におけるDASHクライアント部１４０は、LAN２０を介してクライアント装置１００に接続し、クライアント装置１００のプロキシサーバ部１３０を介して、放送受信部１１０または通信部１２０が受信したMPD、Segmentファイル、SLSファイル等を取得し、ストリームのレンダリングやアプリケーションの制御を行うことにより、ストリームの映像および音声を後段のモニタ（不図示）に出力する処理を実行することができる。
【００８０】
なお、図示は省略するが、クライアント装置１００からDASHクライアント部１４０を省略した構成を有する供給装置を、LAN２０に接続してもよい。その場合、クライアント装置１００および２００は、該供給装置に対してもMPDやSegmentファイル等を要求することができる。
【００８１】
上述したように、クライアント装置１００におけるDASHクライアント部１４０、およびクライアント装置２００におけるDASHクライアント部１４０は、必ずプロキシサーバ部１３０を介して各種ファイルを取得している。したがって、DASHクライアント部１４０は、取得する各種ファイルが放送網１１を介する放送配信か、CDN１２を介するネット配信かの区別を意識する必要が無い、いわゆるネットワーク透過性を実現できる。したがって、DASHクライアント部１４０は、その可搬性が高まるので、放送を受信できない装置に対してもDASHクライアント部１４０を搭載することが可能となる。
【００８２】
次に、プロキシサーバ部１３０について詳述する。プロキシサーバ部１３０は、DASHクライアント部１４０から各種ファイルの取得を要求されると（HTTPリクエストを受信すると）、Broadcast/Broadband Address Resolver１３３が、それを放送網１１経由で取得するか、CDN１２経由で取得するかを判断する。この判断の材料となる情報は、放送受信部１１０のSLS Signaling Parser１１６から提供される。
【００８３】
放送受信部１１０のSLS Signaling Parser１１６は、SLS Signaling Retriever１１５に対して、ATSC3.0のシグナリングメタデータであるUSBD/USDやS-TSID等の取得要求を行う。SLS Signaling Retriever１１５は、チューナ部(ATSC3.0 PHY/MAC)１１１が受信する放送信号からSLS LCTパケットにより運ばれるシグナリングメタデータを抽出する。
【００８４】
また、SLS Signaling Parser１１６は、Segmentファイルの取得要求に含まれるurlからシグナリングメタデータを取得して、対象となるSegmentファイルを取得するための放送配信アドレス情報を取得する。対象となるSegmentファイルが今後放送配信される、または既に放送配信されたことがわかれば、その放送配信アドレス情報に基づき、対象となるSegmentファイルが格納されているsegment LCTパケットを放送ストリームから取得してプロキシサーバ部１３０のProxy Cache１３１内に展開する。この後、プロキシサーバ部１３０は、DASHクライアント部１４０に対してHTTPリクエストのレスポンスとして当該Segmentファイルを返すことになる。
【００８５】
要求されたSegmentファイルのurlがシグナリングメタデータになければ、プロキシサーバ部１３０は、通信部１２０を介してSegmentファイルを取得し、取得したSegmentファイルをProxy Cache１３２内に展開する。この後、プロキシサーバ部１３０は、DASHクライアント部１４０に対してHTTPリクエストのレスポンスとして当該Segmentファイルを返すことになる。
【００８６】
＜PERメッセージについて＞
次に、PERメッセージについて説明する。供給可否情報、放送配信併用情報、およびROI識別子は、以下に説明するPERメッセージを拡張して格納する。
【００８７】
図８は、PERメッセージについて説明するための図である。PERメッセージは、DANE(DASH-Aware Network Elements)３００からDASH Client４００に対して通知されるメッセージである。
【００８８】
ここで、DANE３００は、図７に示されたDASHクライアント装置１００のプロキシサーバ部１３０に相当する。DASH Client４００は、DASHクライアント装置１００のDASHクライアント部１４０に相当する。
【００８９】
DASHにおいては、SANDと称されるプロトコルの規定が検討されている。SANDは、DASHを効果的に運用するために、ネットワークオペレータが管理するDASH配信コンポーネント群から提供され得る種々のリアルタイムネットワーク環境(配信リソース)情報を交換、提供するためのプロトコルである。
【００９０】
SANDには、DANE３００からDASH Client４００に提供されるメッセージ（PERメッセージ）のメッセージプロトコルとしてPERが規定されている。また、DASH Client４００からDANE３００に提供されるメッセージ（Statusメッセージ）のメッセージプロトコルとしてStatusが規定されている。なお、以下、PERメッセージまたはStatusメッセージをSANDメッセージとも称する。
【００９１】
PERでは、ResourceStatusと称するメッセージと、この同類のメッセージとしてDaneResourceStatusと称するメッセージが定義されている。
【００９２】
図９は、ResourceStatusの各要素を説明する図である。本実施の形態では、ResourceStatusのStatus要素を拡張して供給可否情報を格納できるようにし、プロキシサーバ部１３０からDASHクライアント部１４０に通知する。
【００９３】
さらに、ResourceStatusのReason要素を拡張して放送配信併用情報とROI識別子を格納できるようにし、プロキシサーバ部１３０からDASHクライアント部１４０に通知する。該Reason要素には、さらに、ROI識別子が表わすROI系列のメタデータ（例えば、該ROI系列が追従して移動される選手の名前等）を記述するようにしてもよい。なお、ROI識別子が表わすROI系列のメタデータは、放送配信またはネット配信によってクライアント装置１００に供給されているものとする。
【００９４】
ResourceStatusを受け取ったDASH client４００は、ResourceStatusに基づいて次に要求するDASHSegmentファイルを選択することができる。なお、ResourceStatusには、有効期限が記述されているので、DASH client４００はResourceStatusの有効期限まではその内容が有効であるとみなすことができる。
【００９５】
＜ROUTE(Real-Time Object Delivery over Unidirectional Transport)プロトコル＞
次に、ROUTEプロトコルについて説明する。ATSC3.0においては、IPベースのトランスポートスタックの標準化作業が行われており、OTT配信で主流となりつつあるMPEG-DASHのファイルフォーマット(ISO-BMFFファイル、MP4ファイル)に基づくファイルを、FLUTE(File Delivery over Unidirectional Transport)を拡張したROUTEプロトコルを用いて転送する。
【００９６】
ROUTEプロトコルを用いることにより、DASHのfragmented MP4（フラグメント化されたMP4ファイル）ファイルシーケンスと、DASHの制御メタファイルであるMPDや、後述する各種のシグナリング(3GPP-MBMS -USD(User Service Description)を拡張したATSCバージョンのUSDやROUTEプロトコルの制御メタデータであるS-TSID等)を転送することができる。
【００９７】
図１０は、ROUTE/DASHベースのスタックを示している。ROUTEプロトコルはFLUTEをベースとするプロトコルであり、FLUTEにおける転送制御パラメータを記述したメタデータファイルはFDT(File Delivery Table)と称されているが、FDTに相当するROUTEにおける制御メタデータはS-TSID(Service-based Transport Session Instance Description)と称される(実際にはS-TSID/.../EFDTが一番近い)。
【００９８】
S-TSIDは、あるサービス(放送のチャンネルに相当する)内で転送される全てのサービスコンポーネント(ビデオ/オーディオ/データコンポーネントストリーム-全てファイル転送セッションとして実現される)についての転送制御メタデータを記述する。S-TSID自身も、ROUTEセッションの中でサービスシグナリングセッションとして転送される。
【００９９】
また、S-TSIDは１つのサービス内で転送されるコンポーネントファイルセッションについてのシグナリングメタデータであるが、S-TSID自身が転送されるサービス毎のサービスシグナリングメタデータ転送セッションのアドレス(サービスブートストラップアドレス)を解決するためのブートストラップメタデータとしてSLT(Service List Table)と称するシグナリングメタデータを用意しており、UDP/IP上でそれぞれのサービスとは異なる特別なDestination IP Address/Destination Portで転送するようにしている。
【０１００】
図１１は、ROUTEプロトコルが用いられた場合に対応するクライアント側の動作を説明するための図である。
【０１０１】
クライアント装置１１０は、初めにSLTを取得した後、サービスブートストラップアドレスにより所望のサービスのサービスシグナリング(Service Level Signaling)を取得し、当該サービスを構成するサービスコンポーネントそのものを取得してレンダリングを行うことになる。
【０１０２】
＜自由視点風ストリーミングサービスについて＞
次に、本実施の形態であるコンテンツ配信システムが実現可能な自由視点風ストリーミングサービスについて改めて説明する。
【０１０３】
図１２および図１３は、撮像空間全体５１０を複数の矩形領域５１１に分割した場合の例示している図である。
【０１０４】
同図の場合、撮像空間全体５１０が３６個の矩形領域５１１に分割されている。なお、図中の（１，１）等は撮像空間全体５１０における矩形領域５１１の配置を示している。ここで、撮像空間全体５１０の中央部分に複数（同図の場合、４）の矩形領域５１１から成るエリア５１２Ａ乃至５１２Ｄを設定する。
【０１０５】
例えば、配信されるコンテンツがサッカーの試合である場合、観客席を含むスタジアム会場全体が撮像空間全体５１０とされ、スタジアムのフィールド（グランド）が、エリア５１２Ａ乃至５１２Ｄとされる。さらに、試合中にボール５１３が移動すると、その動きに追従するエリアがROI５１４とされ、図１３のＡ乃至図１３のＣに示されるように推移する。
【０１０６】
同図のような場合、エリア５１２Ａ乃至５１２Ｄの映像がそれぞれ１個のAdaptationSetに割り当てられるとともに、各矩形領域５１１の映像がそれぞれをDASHのAdaptationSetに割り当てられる。そして、数多くのユーザが共通して視聴する可能性が高いエリア５１２Ａ乃至５１２Ｄそれぞれの映像に対応するSegmentと、ROI５１４の映像に対応するSegmentが放送配信される。そして、その他の矩形領域５１１の映像に対応するSegmentはネット配信される。ただし、放送配信を受信できないユーザや放送配信の取りこぼし（受信ミス）を配慮して、全てのAdaptationSetに属するSegmentはネット配信も行うようにする。
【０１０７】
図１４は、エリア５１２Ａ乃至５１２Ｄの映像にそれぞれ対応するSegmentと、各矩形領域５１１の映像にそれぞれ対応するSegmentが放送配信されるか（図中で色付きのもの）、ネット配信されるか（図中で無色のもの）を示している。なお、同図上段、中段、下段がそれぞれ図１３のＡ、図１３のＢ、図１３のＣに対応する。
【０１０８】
例えば、図１３のＡにおけるROI５１４は、４個の矩形領域５１１（2,1、2,2、3,1、3,2）から成るので、図１４上段に示されるように、エリア５１２Ａ乃至５１２Ｄの映像にそれぞれ対応するSegmentと、４個の矩形領域５１１（2,1、2,2、3,1、3,2）の映像にそれぞれ対応するSegmentが放送配信される。
【０１０９】
同様に、図１３のＢにおけるROI５１４は、４個の矩形領域５１１（3,2、3,3、4,2、4,3）から成るので、図１４中段に示されるように、エリア５１２Ａ乃至５１２Ｄの映像にそれぞれ対応するSegmentと、４個の矩形領域５１１（3,2、3,3、4,2、4,3）の映像にそれぞれ対応するSegmentが放送配信される。
【０１１０】
なお、図１３に示された例では、ボール５１３に追従するROIが１つだけ設定されているが、例えば、有力選手の動きに追従するROI等、複数のROIを設定してもよい。ただし、全てのROIを放送配信する必要はなく、ユーザに視聴される可能性に応じ、ネット配信のみを行うROIがあってもよい。
【０１１１】
なお、図示は省略するが、自由視点風ストリーミングサービスは、例えば、VR(Virtual Reality)でよく使われる正距円筒画像 をSRD(Spatial Relation Description)にマッピングする場合にも適用できる。
【０１１２】
次に、図１５は、画面全体（または撮像範囲のうちの所定の領域でもよい）を４個の矩形領域に分割した例を示している。以下、説明を簡単にするため、図１５に示すように、画面全体を４個の矩形領域に分割するとともに、ROIを１個の矩形領域から構成するようにし、画面全体と４個の矩形領域のそれぞれの映像をDASHのAdaptationSetに割り当てて配信する場合を例に説明する。
【０１１３】
図１５の例では、AdaptationSet.1.tが画面全体の映像のストリームであり、AdaptationSet.1-1.t乃至1-4.tが、画面全体の左上、右上、左下、または右下の矩形領域それぞれの映像のストリームである。なお、tは時系列を表すパラメータである。
【０１１４】
また、図１５の例では、ROIとしてroiId1とroiId2の２系統が設定されている。roiId1は、AdaptationSet.1-1.1からAdaptationSet.1-2.2へ、さらにAdaptationSet.1-3.3へと遷移する。roiId2は、AdaptationSet.1-3.1からAdaptationSet.1-2.2へ、さらにAdaptationSet.1-2.3へと遷移する。
【０１１５】
２系統のROIのうち、roiId1がroiId2よりも注目度が高いと仮定されており、roiId1に属するSegmentは全て放送配信併用とされ、roiId2に属するSegmentは全てネット配信のみとされている。
【０１１６】
AdaptationSet.1配下のSegmentは全てネット配信と放送配信が行われる放送配信併用であり、ネット配信用のurl(例えばurlプリフィクス"bb"で記載)が割り当てられるとともに、放送配信用のurl(例えばurlプリフィクス"bc"で記載)が割り当てられる。
【０１１７】
AdaptationSet.1-1乃至1-4配下のSegmentは、それぞれが放送配信される場合のみ、ネット配信用のurlが割り当てられるとともに、放送配信用のurlが割り当てられる。放送配信されない場合（すなわち、ネット配信だけの場合）、ネット配信用のurlだけが割り当てられる。
【０１１８】
また、それぞれのSegmentがROIに属している場合には、ROI系列を識別するためのROI識別子が適宜割り当てられる。
【０１１９】
図１６は、AdaptationSet.1.t配下のSegment（例えば、Segment.1.1等）と、AdaptationSet.1-1.t乃至1-4.t配下のSegment（例えば、Segment.1-1.1等）の放送配信併用の有無およびROI識別子を示している。
【０１２０】
例えば、Segment.1-1.1等の下に記載されているUrl(bbSeg.1-1.1)は、Segment.1-1.1がネット配信されることを意味する。また、Url(bcSeg.1-1.1)は、Segment.1-1.1が放送配信されることを意味する。さらに、RoiIdentifier(roiId1)は、Segment.1-1.1がroiId1のROI系統に属していることを意味する。
【０１２１】
例えば、画面全体の左上の矩形領域に対応するAdaptationSet.1-1.tでは、ｔ＝１のSegment.1-1.1はroiId1に属するので、放送配信併用とされる（放送配信とネット配信が行われる）が、ｔ＝２，３のSegment.1-1.2とSegment.1-1.3はROI系列に属していないので、ネット配信のみが行われる。
【０１２２】
また、例えば、画面全体の右上の矩形領域に対応するAdaptationSet.1-2.tでは、ｔ＝１のSegment.1-2.1はROI系列に属していないので、ネット配信のみが行われるが、ｔ＝２のSegment.1-2.2はroiId1とroiId2に属するので、放送配信併用とされる。
【０１２３】
さらに、例えば、画面全体の左下の矩形領域に対応するAdaptationSet.1-3.tでは、ｔ＝１のSegment.1-3.1はroiId2に属するが、注目度が低いと想定されている場合、ネット配信のみが行われる。
【０１２４】
上述したように、各Segmentが放送配信されるのかネット配信されるのかを示す配信モード情報をMPDに記載するためには、AdaptationSet要素の子要素であるbaseURL要素に、配下の各Segmentのurlに付加されるurlプリフィクスを記載すればよい。
【０１２５】
例えば、AdaptationSet/baseURL=”http://a.com/bc”であれば、その配下に属する所定のSegmentに対してAdaptationSet/Representation/SegmentList/SegmentURL@media="/segment11.mp4"と記載される場合、当該segmentのurlは、”http://a.com/bc/segment11.mp4”となる。
【０１２６】
一方、ROI識別子については、現状のMPDにSegment単位で記載することはできないので、MPDを拡張する必要がある。具体的には、SegmentURLの属性にroiId要素を追加してSegment毎のROI識別子を記載できるようにする。例えば、<SegmentURL roiId=”roiId1”>は、当該SegmentのROI識別子が”roiId1”であることを示す。
【０１２７】
上述したように、MPDにSegment単位の配信モード情報とROI識別子を記載できるようにすれば、クライアント装置１００は、MPDを取得、解析することにより、放送配信、ネット配信の違いを意識してSegmentファイルを取得することが可能となる。
【０１２８】
これにより、例えば、画面全体を視聴したいユーザのデバイスでは、SegmentUrlのbcSeg.1.1からbcSeg.1.2、bcSeg.1.3の順にSegmentシーケンスを取得すればよい。また、例えば、roiId=”roiId1”を視聴したいユーザのデバイスでは、bcSeg.1-1.1からbcSeg.1-2.2、cSeg.1-3.3の順にSegmentシーケンスを取得すればよい。同様に、roiIId=”roiId2”を視聴したいユーザのデバイスでは、bbSeg.1-3.1からbcSeg.1-2.2、bbSeg.1-2.3の順にSegmentシーケンスを取得すればよい。
【０１２９】
なお、MPDにおいて、同一のSegmentに対して放送配信用urlとネット配信用urlが記載されている場合（すなわち、該Segmentが放送配信併用である場合）、放送配信のSegmentを受信するか、ネット配信のSegmentを受信するかについては、クライアント装置１００が自身の受信状況等に応じて決定すればよい。
【０１３０】
＜MPDに配信モード情報とROI識別子を格納する場合＞
図１７は、図１５および図１６に示された例のt=1のタイミングに対応するMPD-SRD表現を示している。図１８は、画像全体とそこにおける矩形領域の位置と解像度を示している。
【０１３１】
MPD-SRDにおける〈AdaptationSet id="1"…>からそれに対応する〈/AdaptationSet>までの記載は、図１８のＡに斜線で示される画面全体に対応する。〈AdaptationSet id="1-1"…>からそれに対応する〈/AdaptationSet>までの記載は、図１８のＢに斜線で示される画面全体の左上の矩形領域に対応する。ここに記載されているroiId="roiId1"等がMPDの拡張部分である。
【０１３２】
〈AdaptationSet id="1-3"…>からそれに対応する〈/AdaptationSet>までの記載は、図１８のＣに斜線で示される画面全体の左下の矩形領域に対応する。〈AdaptationSet id="1-4"…>からそれに対応する〈/AdaptationSet>までの記載は、図１８のＤに斜線で示される画面全体の右下の矩形領域に対応する。
【０１３３】
図１９および図２０は、ROI識別子を記載するためにMPDを拡張した具体的な位置に示している。
【０１３４】
同図に示されるように、ROI識別子を記載するためのroiId要素は、MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURLの属性に追加される。
【０１３５】
次に、図２１は、拡張したMPDに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示している。
【０１３６】
同図Ａに示されるサービスシグナリングセッションは、サービスレイヤのシグナリングXMLフラグメントであるSLSを転送するトランスポートセッションである。同図Ｂに示されるコンポーネントファイルセッションは、サービスを構成する各動画/音声/サブタイトル/アプリケーション/他各種データを転送するトランスポートセッションである。各コンポーネントセッションの詳細なストリーム属性はSLSに記載され、ストリームを取得するためのアドレスも記載される。
【０１３７】
ROUTEのファイル転送においては、UDP/IP上のLCTパケットのTSIに基づいてそのセッションが識別され、LCTパケットのTOIによりそのセッションの中で転送される各ファイルオブジェクトが識別される。
【０１３８】
同図Ａの例では、TSI=”sls-tsi”で識別されるサービスシグナリングセッションで、USDおよびS-TSIDを含むsls-bundleファイルが転送される。sls-bundelファイル自身はファイルURL=”slsid-url”、TOI=”0”により識別され、そこに格納されるUSDファイルとS-TSIDファイルは、それぞれ、ファイルURL=”usd-url”、”stsid-url”により識別される。(LCTのレイヤでファイルを再構成する際に必要となるのがTSIとTOIの組であり、sls-bundleファイル自身がTOI=”0”により再構成されるため、sls-bundleファイルの中に格納されたUSDやS-TSIDファイルはTOIが必要ない(ROUTEではこれをPackageModeのファイル転送と称している)。USD(USBD/USD)のuserServiceDescripionには各サービス属性が記載される。
【０１３９】
userServiceDescriptionは、S-TSIDファイルのurl（”stsid-url”）を格納するsTSIDUri属性を持つ。S-TSIDには、そのS-TSID/RS/LS/srcFlowに各コンポーネントの属性を記述する。
【０１４０】
同図Ａの例では、S-TSIDには１つのコンポーネントがあり、そのコンポーネントを構成するファイル群はTSI=”av-tsi”で識別されるセッションで転送され、そのセッションのファイル群の各々の属性を記述するEFDTがそれらファイル群と同じセッションで転送され、EFDTがファイルURL=”efdt-url”で識別されることを示す。TSI=”av-tsi”で識別されるセッションで転送されるEFDTには同一セッションで転送される１つファイルについて記述されており、そのファイルはファイルURL=”bcSeg.1-1.1”で識別され、TOI=”segmentFile-toi”のLCTパケットを集めると再構成できることを示している。再構成されたファイルURL=”bcSeg.1-1.1”で識別されるファイルにはSegmentの中身が格納されている。
【０１４１】
したがって、クライアント装置１００においてDASHクライアント部１４０が所定のsegmentURLによりsegment取得リクエストを発行すると、それを受けたプロキシサーバ部１３０が、ATSC3.0ミドルウエア１１０のシグナリングリトリーバ１１３とシグナリングパーサ１１４を介して取得、分析されたSLSシグナリングフラグメントやEFDTから所望のファイルを取得して再構成し、DASHクライアント部１４０へのレスポンスとして再構成したファイルを返すことになる。
【０１４２】
一方、同一のファイルをネット配信から取得する場合には、同図Ｃに示されるSegmentFile（ファイルURL”bbSeg.1-1.1”）にHTTPリクエストを発行し、それに応じて供給されるファイルを取得することになる。
【０１４３】
次に、図２２は、MPDに配信モード情報とROI識別子を格納した場合における動作シーケンスを示している。
【０１４４】
配信側においては、DASHサーバが、Segment毎に配信モード情報を記述するとともにROI識別子を適宜格納したMPDを生成して放送サーバに転送する。また、DASHサーバがコンテンツストリームのSegmentファイルを生成してWebサーバに転送するとともに、そのうちの放送配信併用のものについては放送サーバにも転送する。
【０１４５】
MPDが転送された放送サーバは、SLSファイルを生成し、生成したSLSファイルと転送されたMPDを、放送網を介して放送配信する。また、放送サーバは、DASHサーバから転送されたコンテンツストリームのSegmentファイルをROUTEのFileModeで放送配信する。
【０１４６】
受信側のクライアント装置１００においては、放送受信部１１０が、放送配信されたMPDとSLSファイルを受信する。この後、DASHクライアント部１４０が、放送受信部１１０に対してMPDを要求すると、その要求に応じて放送受信部１１０がDASHクライアント部１４０にMPDを供給する。なお、放送受信部１１０が放送配信されたMPDを受信していない場合、通信部１２０がDASHサーバにHTTPリクエストを発行してネット配信されるMPDを取得することができる。
【０１４７】
DASHクライアント部１４０では、MPDに記載されているROI識別子等に基づき、要求するSegmentを選択することができる。DASHクライアント部１４０がMPDに基づき、ネット配信されるSegmentを要求した場合、通信部１２０が該Segmentを要求するHTTPリクエストをWebサーバに対して発行し、それ応じてWebサーバから供給（ネット配信）された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
【０１４８】
また、DASHクライアント部１４０がMPDに基づき、放送配信されるSegmentを要求した場合、放送受信部１１が放送配信された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
【０１４９】
以上で、MPDに配信モード情報とROI識別子を格納した場合における動作シーケンスの説明を終了する。
【０１５０】
＜MPDにSegmentTemplateを利用する場合の対応＞
ところで、ライブ放送等の配信にDASHを利用する場合、SegmentListにSegmentUrlを列記するとMPDのデータサイズが極端に大きくなってしまう(ATSC3.0等の場合にはSegment単体の時間が0.5秒くらいを想定している)。そこで通常の場合、MPDにはSegmentTemplateが利用される。
【０１５１】
図２３は、図１７に示されたMPD-SRD表現を、SegmentTemplateを利用して書き換えたものである。図２４は、図２３のMPD-SRD表現を可視化したものである。ただし、図２４における破線枠や１点鎖線枠内のSegmentUrlやROI識別子は、図２３のMPD-SRD表現では記述できない部分を表している。
【０１５２】
MPDにSegmentTemplateを利用することにより、MPDのデータサイズを大幅に削減することができる。ただし、SegmentTemplateはPeriod単位で同一の生成規則が適用されるので、個々のSegmentに対して異なる属性（いまの場合、配信モード情報やROI識別子）を記述することができない。
【０１５３】
図２４と図１６を比較して明らかなように、SegmentTemplateを利用した場合、同一Periodの配下にある時系列にならぶSegmentシーケンスにおいて、あるSegmentには放送配信urlとネット配信urlを指定し、他のSegmentにはネット配信urlのみを指定するようなことができない。また、特定のSegmentに対してのみROI識別子を指定することができない。
【０１５４】
したがって、MPDにSegmentTemplateを利用する場合には、個々のSegmentに対して指定できない配信モード情報やROI識別子を、MPD以外に格納して受信側にシグナリングする必要がある。
【０１５５】
＜USDに配信モード情報とROI識別子を格納する場合＞
次に、SLSシグナリングのUSDを拡張して、各Segmentの配信モード情報とROI識別子をシグナリングする方法について説明する。
【０１５６】
各Segmentの配信モード情報については、従来のUSDでもシグナリングすることができる。
【０１５７】
USDはMPDに紐づけられており、USDのbundleDescriptionROUTE/userServiceDescription/deliveryMethod/broadcastAppService/basePattern(放送配信向けのurl一致パターン)、または、.../unicastAppService/basePattern (ネット配信向けのurl一致パターン)に列挙されているurlの一部(全部でもよい)が当該Segmentのurlに一致するとき、当該Segmentは放送網のROUTEを介する放送配置、または、CDNを介するネット配信されることを示すことになる。
【０１５８】
また、放送配信されるSegmentとネット配信されるSegmentが同一のものであることは、bundleDescriptionROUTE/userServiceDescription/deliveryMethod/appService/identicalContentによりグルーピングされているurlの組を用いて示すことができる。
【０１５９】
図２５は、ROI識別子を格納するためにUSDを拡張した具体的な位置に示している。同図に示されるように、ROI識別子(roiId)については、各SegmentのbasePatternの属性を拡張してROI識別子を格納する。
【０１６０】
図２６は、拡張したUSDに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示している。
【０１６１】
同図の例では、USDのuserServiceDescription/deliveryMethodの下の、放送配信urlのマッチングパターンを記載するbroadcastAppService/basePatternに”bcSeg.1-1.1”が記載され、そのROI識別子として”roiId1”が記載されている。一方、ネット配信urlのマッチングパターンを記載するunicastAppService/basePatternには”bbSeg.1-1.1”が記載され、そのROI識別子として”roiId1”が記載されている。これは、あるSegmentに対して放送配信とネット配信の両方で同じROI識別子が割り当てられていることを意味する。そして、これらのSegment群が同一のものであることは、deliveryMethod/appService/identicalContentによりグルーピングすることにより示すことができる。
【０１６２】
ここで、basePatternに記載するマッチングパターンは、通常、MPDに記載されるbaseURLやSegmentURLの一部(例えば、“http://a.com/bc”等)が記載されるが、各Segmentについて記載する場合はSegmentURLの全体(SegmentURLがユニークに解決できる部分まで)を記載することになる。よって、各SegmentのROIが変化するような場合は、Segment毎のURL粒度とUSDの更新粒度が等しくなる。
【０１６３】
クライアント装置１００において、ROI系列を追尾しないでSegmentを取得する場合、DASHクライアント部１４０はプロキシサーバ部１３０に対してSegmentURL=”bbSeg.1-1.1”(ネット配信url)のHTTPリクエストを通知すると、この通知が放送受信部１１０に渡り、放送受信部１１０ではbbSeg.1-1.1をUSDの中から探し、対応する放送配信urlである”bcSeg.1-1.1”が、コンポーネントファイルセッション上のurlであることがわかると、当該Segmentファイルを放送ストリームから取得してDASHクライアント部１４０に供給することとなる。
【０１６４】
一方、ROI系列を追尾してSegmentを取得する場合、放送受信部１１０がUSDを解析して得たSegmentがどのROI系列に属しているのか示す情報をDASHクライアント部１４０に通知する必要がある。この通知には、図８を参照して上述したDASHのSANDメッセージ等が利用される。
【０１６５】
具体的には、上述したように、SANDのResourceStatusメッセージのResourceStatus/Reason要素に放送配信併用情報とROI識別子を格納できるようにする。ただし、現在の規定では、reason要素にはヒント情報として任意の文字列を記載してもよいことになっているが、どういった情報が記載されるべきかの細かな規定(データ構造とセマンティクスの規定)がない。
【０１６６】
そこで、データ構造として、任意の受信状態メタデータを格納できるようSchemeIdUri(必須)とValue(オプショナル)の組を格納できるようにすることを提案する。SchemeIdUriには、受信状態を示すデータの内容を識別するURIを指定して、そのURIで規定される値の内容をvalueに記載できるようにする。
【０１６７】
例えば、SchemeIdUriとして放送配信併用であるを示す”urn:atsc:BroadcastDelivery”というURNを規定し、さらに、ROI識別子を格納するスキームとして”urn:atsc:roiValue”を規定してROI識別子をvalue属性に格納する。
【０１６８】
図２７は、放送配信併用情報とROI識別子を格納したResourceStatusメッセージの具体例を示している。同図Ａに示されるように、ResourceStatusメッセージは、baseURL要素とStatus要素とReason要素が記載される。なお、Reason要素には、同図Ｂに示されるように、配信モード情報とROI識別子がbase64エンコードされた状態の文字列として記載される。
【０１６９】
次に、図２８は、USDに配信モード情報とROI識別子を格納した場合における動作シーケンスを示している。
【０１７０】
配信側においては、DASHサーバが、SegmentTemplateを利用したMPDを生成して放送サーバに転送する。また、DASHサーバがコンテンツストリームのSegmentファイルを生成してWebサーバに転送するとともに、そのうちの放送配信併用のものについては放送サーバにも転送する。
【０１７１】
MPDが転送された放送サーバは、配信モード情報とROI識別子を格納したUSDを含むSLSファイルを生成し、生成したSLSファイルと転送されたMPDを、放送網を介して放送配信する。また、放送サーバは、DASHサーバから転送されたコンテンツストリームのSegmentファイルをROUTEのFileModeで放送配信する。
【０１７２】
受信側のクライアント装置１００においては、放送受信部１１０が、放送配信されたMPDとSLSファイルを受信する。この後、DASHクライアント部１４０が、放送受信部１１０に対してMPDを要求すると、その要求に応じて放送受信部１１０がDASHクライアント部１４０にMPDを供給する。なお、放送受信部１１０が放送配信されたMPDを受信していない場合、通信部１２０がDASHサーバにHTTPリクエストを発行してネット配信されるMPDを取得することができる。
【０１７３】
MPDが供給されたDASHクライアント部１４０では、SegmentTemplateに基づいて完全なSegmentURLを復元することによってMPDを再生成する。
【０１７４】
さらに、放送受信部１１０は、USDを解析して各Segmentの配信モード情報とROI識別子を判断し、その判断結果をプロキシサーバ部１３０に通知する。プロキシサーバ部１３０は、Segmentの配信モード情報とROI識別子を格納したResourceStatusメッセージを生成してDASHクライアント部１４０に通知する。
【０１７５】
DASHクライアント部１４０では、MPDとResourceStatusメッセージに記載されているROI識別子等に基づき、要求するSegmentを選択することができる。DASHクライアント部１４０がネット配信されるSegmentを要求した場合、通信部１２０が、該Segmentを要求するHTTPリクエストをWebサーバに対して発行し、それ応じてWebサーバから供給（ネット配信）された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
【０１７６】
また、DASHクライアント部１４０が放送配信されるSegmentを要求した場合、放送受信部１１が、放送配信された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
【０１７７】
以上で、USDに配信モード情報とROI識別子を格納した場合における動作シーケンスの説明を終了する。
【０１７８】
ところで、上述したようにUSDを用いて各Segmentの配信モード情報とROI識別子をシグナルした場合、Segment粒度(Segment単位毎)で放送配信併用であるか否かが変化するようなときには、その変化のたびにUSDを更新しなければならない。しかしながら、USDは、本来、サービス(チャネル)全体に亘って変化がない属性をシグナリングするために導入されており、頻繁に更新が必要となる運用は想定されていない(禁止されているわけではない）。そこで、USDを用いずに、同様のシグナリングを行う２種類の方法について以下の（１）および（２）の方法を提案する。
（１）ROUTEの転送モードがFileModeの場合、EFDTを拡張してROI識別子を格納する。
（２）ROUTEの転送モードがEFDTを利用しないEntityModeの場合、Entityヘッダを拡張して同一コンテンツを識別するurlや、ROI識別子を格納する。
【０１７９】
＜EFDTの拡張＞
各Segmentの配信モード情報とROI識別子は、S-TSIDのEFDT(各コンポーネントファイルセッション上にそれが記述するファイル群とともに転送することができるシグナリングフラグメントの一部(断片))を用いてシグナルリングすることができる。
【０１８０】
図２９は、ROI識別子を格納するためにEFDTを拡張した具体的な位置に示している。同図に示されるように、efdtType/routesls:FDTParameters/File/atributes/Content-Location属性にRoiIdとIdentical-Content-Locationを並列に追加する。
【０１８１】
図３０は、拡張したEFDTに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示している。
【０１８２】
同図に示されるように、当該Segmentが生成された元となるMPDに紐づけられているUSDのbundleDescriptionROUTE/userServiceDescription@sTSIDUriから参照されるS-TSIDフラグメントのS-TSID/RS/LS/srcFlow/EFDTから参照されるコンポーネントファイルセッション中のEFDTに、当該SegmentファイルのファイルURLを記載するためのContent-Location属性に追加されたIdentical-Content-Locationにネット配信url(同図の場合、bbSeg.1-1.1)を記載し、RoiIdにROI記述子（同図の場合”roiid1）を記載する。
【０１８３】
この場合、拡張したUSDを用いるときと同様に、クライアント装置１００において、ROI系列を追尾しないでSegmentを取得する際には、DASHクライアント部１４０はプロキシサーバ部１３０に対してSegmentURL=”bbSeg.1-1.1”(ネット配信url)のHTTPリクエストを通知すると、この通知が放送受信部１１０に渡り、放送受信部１１０ではbbSeg.1-1.1をEFDTの中から探し、対応する放送配信urlである”bcSeg.1-1.1”が、コンポーネントファイルセッション上のurlであることがわかると、当該Segmentファイルを放送ストリームから取得してDASHクライアント部１４０に供給することとなる。
【０１８４】
一方、ROI系列を追尾してSegmentを取得する際には、放送受信部１１０がEFDTを解析して得たSegmentがどのROI系列に属しているのか示す情報をDASHクライアント部１４０に通知する必要がある。この通知には、上述したDASHのSANDメッセージ等が利用される。
【０１８５】
次に、図３１は、EFDTに配信モード情報とROI識別子を格納した場合における動作シーケンスを示している。
【０１８６】
配信側においては、DASHサーバが、SegmentTemplateを利用したMPDを生成して放送サーバに転送する。また、DASHサーバがコンテンツストリームのSegmentファイルを生成してWebサーバに転送するとともに、そのうちの放送配信併用のものについては放送サーバにも転送する。
【０１８７】
MPDが転送された放送サーバは、配信モード情報とROI識別子を格納したEFDTを含むSLSファイルを生成し、生成したSLSファイルと転送されたMPDを、放送網を介して放送配信する。また、放送サーバは、DASHサーバから転送されたコンテンツストリームのSegmentファイルをROUTEのFileModeで放送配信する。
【０１８８】
受信側のクライアント装置１００においては、放送受信部１１０が、放送配信されたMPDとSLSファイルを受信する。DASHクライアント部１４０が、放送受信部１１０に対してMPDを要求すると、その要求に応じて放送受信部１１０がDASHクライアント部１４０にMPDを供給する。なお、放送受信部１１０が放送配信されたMPDを受信していない場合、通信部１２０がDASHサーバにHTTPリクエストを発行してネット配信されるMPDを取得することができる。
【０１８９】
MPDが供給されたDASHクライアント部１４０では、SegmentTemplateに基づいて完全なSegmentURLを復元することによってMPDを再生成する。
【０１９０】
さらに、放送受信部１１０は、EFDTを解析して各Segmentの配信モード情報とROI識別子を判断し、その判断結果をプロキシサーバ部１３０に通知する。プロキシサーバ部１３０は、Segmentの配信モード情報とROI識別子を格納したResourceStatusメッセージを生成してDASHクライアント部１４０に通知する。
【０１９１】
DASHクライアント部１４０では、MPDとResourceStatusメッセージに記載されているROI識別子等に基づき、要求するSegmentを選択することができる。DASHクライアント部１４０がネット配信されるSegmentを要求した場合、通信部１２０が、該Segmentを要求するHTTPリクエストをWebサーバに対して発行し、それ応じてWebサーバから供給（ネット配信）された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
【０１９２】
また、DASHクライアント部１４０が放送配信されるSegmentを要求した場合、放送受信部１１が、放送配信された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
【０１９３】
以上で、EFDTに配信モード情報とROI識別子を格納した場合における動作シーケンスの説明を終了する。
【０１９４】
＜Entityヘッダの拡張＞
各Segmentの配信モード情報とROI識別子は、コンポーネントファイルセッション中に当該ファイルをEntityModeで転送し、Entityヘッダを拡張することによりシグナルリングすることができる。
【０１９５】
図３２は、拡張したEntityヘッダに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示している。
【０１９６】
同図に示されるように、当該Segmentが生成された元となるMPDに紐づけられているUSDのbundleDescriptionROUTE/userServiceDescription@sTSIDUriから参照されるS-TSIDフラグメントのS-TSID/RS/LS＠tsiから参照されるコンポーネントファイルセッションで流れる当該SegmentファイルのEntityヘッダ中にIdentical-Content-Location要素とROI-id要素を設け、Identical-Content-Locationにはネット配信url(同図の場合、bbSeg.1-1.1)を記載し、ROI-idにはROI識別子（同図の場合、roiId1）を記載するようにする。
【０１９７】
この場合、拡張したUSDや拡張したEFDTを用いるときと同様に、クライアント装置１００において、ROI系列を追尾しないでSegmentを取得する際には、DASHクライアント部１４０はプロキシサーバ部１３０に対してSegmentURL=”bbSeg.1-1.1”(ネット配信url)のHTTPリクエストを通知すると、この通知が放送受信部１１０に渡り、放送受信部１１０ではbbSeg.1-1.1をもとに、放送ストリームから取得したEntityMode配信のファイル群のEntityヘッダの中からbbSeg.1-1.1に対応する放送配信urlである”bcSeg.1-1.1”が、コンポーネントファイルセッション上のurlであることがわかると、当該Segmentファイルを放送ストリームから取得してDASHクライアント部１４０に供給することとなる。
【０１９８】
一方、ROI系列を追尾してSegmentを取得する際には、放送受信部１１０がEntityヘッダを解析して得たSegmentがどのROI系列に属しているのか示す情報をDASHクライアント部１４０に通知する必要がある。この通知には、上述したDASHのSANDメッセージ等が利用される。
【０１９９】
次に、図３２は、Entityヘッダに配信モード情報とROI識別子を格納した場合における動作シーケンスを示している。
【０２００】
配信側においては、DASHサーバが、SegmentTemplateを利用したMPDを生成して放送サーバに転送する。また、DASHサーバが、配信モード情報とROI識別子を格納したEntityヘッダを生成するとともに、コンテンツストリームのSegmentファイルを生成してWebサーバに転送し、そのうちの放送配信併用のものについては放送サーバにも転送する。
【０２０１】
MPDが転送された放送サーバは、SLSファイルを生成し、生成したSLSファイルと転送されたMPDを、放送網を介して放送配信する。また、放送サーバは、DASHサーバから転送されたコンテンツストリームのSegmentファイルをROUTEのEntityModeで放送配信する。
【０２０２】
受信側のクライアント装置１００においては、放送受信部１１０が、放送配信されたMPDとSLSファイルを受信する。DASHクライアント部１４０が、放送受信部１１０に対してMPDを要求すると、その要求に応じて放送受信部１１０がDASHクライアント部１４０にMPDを供給する。なお、放送受信部１１０が放送配信されたMPDを受信していない場合、通信部１２０がDASHサーバにHTTPリクエストを発行してネット配信されるMPDを取得することができる。
【０２０３】
MPDが供給されたDASHクライアント部１４０では、SegmentTemplateに基づいて完全なSegmentURLを復元することによってMPDを再生成する。
【０２０４】
さらに、放送受信部１１０は、Entityヘッダを解析して各Segmentの配信モード情報とROI識別子を判断し、その判断結果をプロキシサーバ部１３０に通知する。プロキシサーバ部１３０は、Segmentの配信モード情報とROI識別子を格納したResourceStatusメッセージを生成してDASHクライアント部１４０に通知する。
【０２０５】
DASHクライアント部１４０では、MPDとResourceStatusメッセージに記載されているROI識別子等に基づき、要求するSegmentを選択することができる。DASHクライアント部１４０がネット配信されるSegmentを要求した場合、通信部１２０が、該Segmentを要求するHTTPリクエストをWebサーバに対して発行し、それ応じてWebサーバから供給（ネット配信）された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
【０２０６】
また、DASHクライアント部１４０が放送配信されるSegmentを要求した場合、放送受信部１１が、放送配信された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
【０２０７】
以上で、Entityヘッダに配信モード情報とROI識別子を格納した場合における動作シーケンスの説明を終了する。
【０２０８】
＜クライアント装置１００におけるROI識別子の利用例＞
上述したように、各ROI系列に対応するメタデータも供給される場合、クライアント装置１００ではこれらをU/Iに利用することができる。図３４は、各ROI系列に対応するROI識別子とメタデータの利用例を示している。
【０２０９】
同図Ａは、ROIが設定されている人物６０１が画面６００上に表示される際、それぞれのメタデータ（人物の名前など）の表示領域６０２を人物６０１とともに移動させて表示する利用例である。この利用例では、例えば、人物６０１Ｘを含む領域６０３Ｘがユーザによって指定された場合、画面６００の映像を、人物６０１Ｘを中心として拡大したり、人物６０１Ｘに対して設定されているROIの映像に切り替えたりすることができる。
【０２１０】
同図Ｂは、ROIが設定されている人物６０１が画面６００上に表示される際、そのメタデータ（人物の名前など）の表示領域６０２を画面６００の端にまとめて表示する利用例である。この利用例では、例えば、人物６０１Ｙに対応するメタデータの表示領域６０２Ｙがユーザによって選択された場合、画面６００の人物６０１Ｙが強調表示されたり（同図Ｂの表示例では、人物６０１Ｙの周囲に点滅表示する枠６０５が表示される）、人物６０１Ｙを中心として拡大したり、人物６０１Ｙに対して設定されているROIの映像に切り替えたりすることができる。
【０２１１】
＜他の実施形態＞
ところで、上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
【０２１２】
図３５は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
【０２１３】
該コンピュータ１１００において、CPU（Central Processing Unit）１１０１，ROM（Read Only Memory）１１２，RAM（Random Access Memory）１１０３は、バス１１０４により相互に接続されている。
【０２１４】
バス１１０４には、さらに、入出力インタフェース１１０５が接続されている。入出力インタフェース１１０５には、入力部１１０６、出力部１１０７、記憶部１１０８、通信部１１０９、およびドライブ１１１０が接続されている。
【０２１５】
入力部１１０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１１０７は、ディスプレイ、スピーカなどよりなる。記憶部１１０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１１０９は、ネットワークインタフェースなどよりなる。ドライブ１１１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１１１１を駆動する。
【０２１６】
以上のように構成されるコンピュータ１１００では、CPU１１０１が、例えば、記憶部１１０８に記憶されているプログラムを、入出力インタフェース１１０５およびバス１１０４を介して、RAM１１０３にロードして実行することにより、上述した一連の処理が行われる。
【０２１７】
コンピュータ１１００（CPU１１０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１１１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
【０２１８】
コンピュータ１１００では、プログラムは、リムーバブルメディア１１１１をドライブ１１１０に装着することにより、入出力インタフェース１１０５を介して、記憶部１１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１１０９で受信し、記憶部１１０８にインストールすることができる。その他、プログラムは、ROM１１０２や記憶部１１０８に、あらかじめインストールしておくことができる。
【０２１９】
なお、コンピュータ１１００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであってもよい。
【０２２０】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０２２１】
本技術は以下のような構成も取ることができる。
（１）
複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
を備える配信装置。
（２）
前記通知部は、前記セグメントファイルに関する前記属性情報として、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を受信側に通知する
前記（１）に記載の配信装置。
（３）
前記通知部は、前記セグメントファイルに関する前記属性情報を、DASHで規定されているMPDに記載して受信側に通知する
前記（１）または（２）に記載の配信装置。
（４）
前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、USDに記載して受信側に通知する
前記（１）または（２）に記載の配信装置。
（５）
前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、EFDTに記載して受信側に通知する
前記（１）または（２）に記載の配信装置。
（６）
前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、Entityヘッダに記載して受信側に通知する
前記（１）または（２）に記載の配信装置。
（７）
前記撮像範囲には１以上の前記ROIが設定される
前記（１）から（６）のいずれかに記載の配信装置。
（８）
前記配信部は、全て前記領域のそれぞれ対応する前記映像ストリームのセグメントファイルをネット配信するとともに、前記ROIを成す領域に対応するセグメントファイルを放送配信する
前記（１）から（７）のいずれかに記載の配信装置。
（９）
配信装置の配信方法において、
前記配信装置による、
複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信ステップと、
前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知ステップと
を含む配信方法。
（１０）
コンピュータを、
複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
して機能させるプログラム。
（１１）
複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、
前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
取得された前記セグメントファイルを再生する再生部と
を備える受信装置。
（１２）
前記要求部は、ユーザからの操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
前記（１１）に記載の受信装置。
（１３）
前記要求部は、画面上の被写体を指定する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
前記（１２）に記載の受信装置。
（１４）
前記要求部は、被写体のメタデータを選択する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
前記（１２）に記載の受信装置。
（１５）
前記属性情報は、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を含み、
前記取得部は、前記配信モード情報に基づき、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する
前記（１１）から（１４）のいずれかに記載の受信装置。
（１６）
前記解析部による前記属性情報の解析結果は、SANDメッセージを用いて前記要求部に通知される
前記（１１）から（１５）のいずれかに記載の受信装置。
（１７）
受信装置の受信方法において、
前記受信装置による、
複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析ステップと、
前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求ステップと、
要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得ステップと、
取得された前記セグメントファイルを再生する再生ステップと
を含む受信方法。
（１８）
コンピュータを、
複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、
前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
取得された前記セグメントファイルを再生する再生部と
して機能させるプログラム。
（１９）
配信装置と受信装置を含むコンテンツ配信システムにおいて、
前記配信装置は、
複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
を備え、
前記受信装置は、
前記配信装置から通知された前記属性情報を解析する解析部と、
前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
取得された前記セグメントファイルを再生する再生部と
を備える
コンテンツ配信システム。
【符号の説明】
【０２２２】
１０  Broadcaster，  １１  放送網，  １２  CDN，  ２０  LAN，  １００  クライアント装置，  １１０  放送受信部，  １２０  通信部，  １３０  プロキシサーバ部，  １４０  DASHクライアント部，  ３００  DANE，  ４００  DASH client，  ５１４  ROI，  １１００  コンピュータ，  １１０１  CPU
【図１】
2018043134.tif 000003
【図２】
2018043134.tif 000004
【図３】
2018043134.tif 000005
【図４】
2018043134.tif 000006
【図５】
2018043134.tif 000007
【図６】
2018043134.tif 000008
【図７】
2018043134.tif 000009
【図８】
2018043134.tif 000010
【図９】
2018043134.tif 000011
【図１０】
2018043134.tif 000012
【図１１】
2018043134.tif 000013
【図１２】
2018043134.tif 000014
【図１３】
2018043134.tif 000015
【図１４】
2018043134.tif 000016
【図１５】
2018043134.tif 000017
【図１６】
2018043134.tif 000018
【図１７】
2018043134.tif 000019
【図１８】
2018043134.tif 000020
【図１９】
2018043134.tif 000021
【図２０】
2018043134.tif 000022
【図２１】
2018043134.tif 000023
【図２２】
2018043134.tif 000024
【図２３】
2018043134.tif 000025
【図２４】
2018043134.tif 000026
【図２５】
2018043134.tif 000027
【図２６】
2018043134.tif 000028
【図２７】
2018043134.tif 000029
【図２８】
2018043134.tif 000030
【図２９】
2018043134.tif 000031
【図３０】
2018043134.tif 000032
【図３１】
2018043134.tif 000033
【図３２】
2018043134.tif 000034
【図３３】
2018043134.tif 000035
【図３４】
2018043134.tif 000036
【図３５】
2018043134.tif 000037
【国際調査報告】
2018043134.tif 000038
2018043134.tif 000039
2018043134.tif 000040
2018043134.tif 000041