JPWO2018043134A1 - 配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システム - Google Patents

配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システム Download PDF

Info

Publication number
JPWO2018043134A1
JPWO2018043134A1 JP2018537114A JP2018537114A JPWO2018043134A1 JP WO2018043134 A1 JPWO2018043134 A1 JP WO2018043134A1 JP 2018537114 A JP2018537114 A JP 2018537114A JP 2018537114 A JP2018537114 A JP 2018537114A JP WO2018043134 A1 JPWO2018043134 A1 JP WO2018043134A1
Authority
JP
Japan
Prior art keywords
roi
distribution
segment
unit
segment file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2018537114A
Other languages
English (en)
Inventor
山岸　靖明
靖明 山岸
高林　和彦
和彦 高林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Publication of JPWO2018043134A1 publication Critical patent/JPWO2018043134A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/20—Arrangements for broadcast or distribution of identical information via plural systems
    • H04H20/24—Arrangements for distribution of identical information via broadcast system and non-broadcast system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/28—Arrangements for simultaneous broadcast of plural pieces of information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/93—Arrangements characterised by the broadcast information itself which locates resources of other pieces of information, e.g. URL [Uniform Resource Locator]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/21805—Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234345—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements the reformatting operation being performed only on part of the stream, e.g. a region of the image or a time segment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4728—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for selecting a Region Of Interest [ROI], e.g. for requesting a higher resolution version of a selected region
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/42—Arrangements for resource management

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本技術は、放送配信またはネット配信の少なくとも一方で配信される映像のROI識別子をシグナリングすることができるようにする配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システムに関する。本技術の第１の側面である配信装置は、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部とを備える。本技術は、DASHを用いたストリーミング配信に適用できる。

Description

本技術は、配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システムに関し、特に、より多くのユーザの視聴される可能性が高い等の優先度が高い画像領域を放送にて配信し、その他の画像領域をオンデマンド配信する場合に用いて好適な配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システムに関する。
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

Claims (19)

  1. 複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
    前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
    前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
    を備える配信装置。
  2. 前記通知部は、前記セグメントファイルに関する前記属性情報として、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を受信側に通知する
    請求項１に記載の配信装置。
  3. 前記通知部は、前記セグメントファイルに関する前記属性情報を、DASHで規定されているMPDに記載して受信側に通知する
    請求項２に記載の配信装置。
  4. 前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、USDに記載して受信側に通知する
    請求項２に記載の配信装置。
  5. 前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、EFDTに記載して受信側に通知する
    請求項２に記載の配信装置。
  6. 前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、Entityヘッダに記載して受信側に通知する
    請求項２に記載の配信装置。
  7. 前記撮像範囲には１以上の前記ROIが設定される
    請求項２に記載の配信装置。
  8. 前記配信部は、全て前記領域のそれぞれ対応する前記映像ストリームのセグメントファイルをネット配信するとともに、前記ROIを成す領域に対応するセグメントファイルを放送配信する
    請求項２に記載の配信装置。
  9. 配信装置の配信方法において、
    前記配信装置による、
    複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
    前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信ステップと、
    前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知ステップと
    を含む配信方法。
  10. コンピュータを、
    複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
    前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
    前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
    して機能させるプログラム。
  11. 複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、
    前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
    要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
    取得された前記セグメントファイルを再生する再生部と
    を備える受信装置。
  12. 前記要求部は、ユーザからの操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
    請求項１１に記載の受信装置。
  13. 前記要求部は、画面上の被写体を指定する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
    請求項１２に記載の受信装置。
  14. 前記要求部は、被写体のメタデータを選択する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
    請求項１３に記載の受信装置。
  15. 前記属性情報は、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を含み、
    前記取得部は、前記配信モード情報に基づき、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する
    請求項１２に記載の受信装置。
  16. 前記解析部による前記属性情報の解析結果は、SANDメッセージを用いて前記要求部に通知される
    請求項１２に記載の受信装置。
  17. 受信装置の受信方法において、
    前記受信装置による、
    複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析ステップと、
    前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求ステップと、
    要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得ステップと、
    取得された前記セグメントファイルを再生する再生ステップと
    を含む受信方法。
  18. コンピュータを、
    複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、
    前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
    要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
    取得された前記セグメントファイルを再生する再生部と
    して機能させるプログラム。
  19. 配信装置と受信装置を含むコンテンツ配信システムにおいて、
    前記配信装置は、
    複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
    前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
    前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
    を備え、
    前記受信装置は、
    前記配信装置から通知された前記属性情報を解析する解析部と、
    前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
    要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
    取得された前記セグメントファイルを再生する再生部と
    を備える
    コンテンツ配信システム。
JP2018537114A 2016-08-30 2017-08-17 配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システム Pending JPWO2018043134A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016167607 2016-08-30
JP2016167607 2016-08-30
PCT/JP2017/029488 WO2018043134A1 (ja) 2016-08-30 2017-08-17 配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システム

Publications (1)

Publication Number Publication Date
JPWO2018043134A1 true JPWO2018043134A1 (ja) 2019-06-24

Family

ID=61300582

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018537114A Pending JPWO2018043134A1 (ja) 2016-08-30 2017-08-17 配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システム

Country Status (8)

Country Link
US (2) US10750243B2 (ja)
EP (1) EP3509310B1 (ja)
JP (1) JPWO2018043134A1 (ja)
KR (1) KR102376204B1 (ja)
CN (1) CN109644286B (ja)
CA (1) CA3034585A1 (ja)
MX (1) MX2019002296A (ja)
WO (1) WO2018043134A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111131515B (zh) * 2019-12-31 2022-07-15 武汉市烽视威科技有限公司 一种cdn边缘注入分发方法及***
US11765428B2 (en) * 2021-04-07 2023-09-19 Idomoo Ltd System and method to adapting video size
EP4138401A1 (en) * 2021-08-17 2023-02-22 Nokia Technologies Oy A method, an apparatus and a computer program product for video encoding and video decoding
CN114500846B (zh) * 2022-02-12 2024-04-02 北京蜂巢世纪科技有限公司 现场活动观看视角切换方法、装置、设备及可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015050769A (ja) * 2013-08-29 2015-03-16 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法および受信方法
WO2015060349A1 (ja) * 2013-10-22 2015-04-30 シャープ株式会社 表示制御装置、配信装置、表示制御方法、および表示制御システム
WO2015197815A1 (en) * 2014-06-27 2015-12-30 Koninklijke Kpn N.V. Determining a region of interest on the basis of a hevc-tiled video stream
JP2016009925A (ja) * 2014-06-23 2016-01-18 キヤノン株式会社 データ処理装置、データ処理方法、及びプログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101968070B1 (ko) * 2012-10-12 2019-04-10 캐논 가부시끼가이샤 데이터를 스트리밍하기 위한 방법, 데이터를 제공하기 위한 방법, 데이터를 획득하기 위한 방법, 컴퓨터 판독 가능 저장 매체, 서버 장치, 및 클라이언트 장치
ITTO20130437A1 (it) * 2013-05-29 2014-11-30 Sisvel Technology Srl Metodo di elaborazione di un contenuto video ricevibile da una pluralità di piattaforme di distribuzione e relativo apparato di ricezione video
WO2016122269A1 (ko) * 2015-01-29 2016-08-04 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CN113316024B (zh) * 2016-02-02 2024-05-31 弗劳恩霍夫应用研究促进协会 视频流传输中的场景部分和感兴趣区域处理

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015050769A (ja) * 2013-08-29 2015-03-16 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法および受信方法
WO2015060349A1 (ja) * 2013-10-22 2015-04-30 シャープ株式会社 表示制御装置、配信装置、表示制御方法、および表示制御システム
JP2016009925A (ja) * 2014-06-23 2016-01-18 キヤノン株式会社 データ処理装置、データ処理方法、及びプログラム
WO2015197815A1 (en) * 2014-06-27 2015-12-30 Koninklijke Kpn N.V. Determining a region of interest on the basis of a hevc-tiled video stream

Also Published As

Publication number Publication date
US20190182550A1 (en) 2019-06-13
KR20190042568A (ko) 2019-04-24
EP3509310A4 (en) 2019-08-21
US11252478B2 (en) 2022-02-15
CN109644286A (zh) 2019-04-16
MX2019002296A (es) 2019-07-04
US10750243B2 (en) 2020-08-18
EP3509310B1 (en) 2020-09-30
KR102376204B1 (ko) 2022-03-21
CA3034585A1 (en) 2018-03-08
CN109644286B (zh) 2021-08-17
US20200351559A1 (en) 2020-11-05
EP3509310A1 (en) 2019-07-10
WO2018043134A1 (ja) 2018-03-08

Similar Documents

Publication Publication Date Title
JP6348251B2 (ja) 端末装置、受信方法、およびプログラム
JP6612249B2 (ja) メディアデータをストリーミングするためのターゲット広告挿入
US11252478B2 (en) Distribution device, distribution method, reception device, reception method, program, and content distribution system
KR102499231B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
WO2014208377A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2014196392A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JPWO2018079295A1 (ja) 情報処理装置、及び、情報処理方法
US10893315B2 (en) Content presentation system and content presentation method, and program
WO2014203745A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JP6597604B2 (ja) 受信装置、送信装置、データ通信方法、およびデータ処理方法
WO2015041071A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
KR102123208B1 (ko) 콘텐츠 공급 장치, 콘텐츠 공급 방법, 프로그램, 단말 장치, 및 콘텐츠 공급 시스템
KR102319932B1 (ko) 수신 장치 및 수신 방법, 재생 장치 및 재생 방법, 공급 장치 및 공급 방법, 그리고 프로그램
WO2015029768A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200817

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200817

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210907

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211027

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20220222