JPWO2018173874A1 - コンテンツ提供システムおよびコンテンツ提供方法、並びにプログラム - Google Patents

コンテンツ提供システムおよびコンテンツ提供方法、並びにプログラム Download PDF

Info

Publication number
JPWO2018173874A1
JPWO2018173874A1 JP2019507590A JP2019507590A JPWO2018173874A1 JP WO2018173874 A1 JPWO2018173874 A1 JP WO2018173874A1 JP 2019507590 A JP2019507590 A JP 2019507590A JP 2019507590 A JP2019507590 A JP 2019507590A JP WO2018173874 A1 JPWO2018173874 A1 JP WO2018173874A1
Authority
JP
Japan
Prior art keywords
content
client
mpd
segment
server
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
JP2019507590A
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 JPWO2018173874A1 publication Critical patent/JPWO2018173874A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/26275—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 distributing content or additional data in a staggered manner, e.g. repeating movies on different channels in a time-staggered manner in a near video on demand system
    • 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/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • 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/222—Secondary servers, e.g. proxy server, cable television Head-end
    • 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/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • 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/482—End-user interface for program selection
    • H04N21/4825—End-user interface for program selection using a list of items to be played back in a given order, e.g. playlists
    • 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via 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/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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
    • 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/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
    • 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/84—Generation or processing of descriptive data, e.g. content descriptors
    • 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

Landscapes

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

Abstract

本開示は、複数のトランスポートメディアの割り当てを最適化および効率化することができるようにするコンテンツ提供システムおよびコンテンツ提供方法、並びにプログラムに関する。コンテンツ配信装置は、コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用してコンテンツを配信する。コンテンツ提供装置は、特徴の異なる複数のストリームにより構成されるコンテンツを配信するにあたり、それぞれのストリームの配信を、複数のネットワークで分配する際の判断基準となるポリシーを、コンテンツ配信装置に提供する。本技術は、例えば、MPEG DASHを利用してコンテンツを提供するコンテンツ提供システムに適用できる。

Description

本開示は、コンテンツ提供システムおよびコンテンツ提供方法、並びにプログラムに関し、特に、複数のトランスポートメディアの割り当てを最適化および効率化することができるようにしたコンテンツ提供システムおよびコンテンツ提供方法、並びにプログラムに関する。
IPTV(Internet Protocol Television)等のインターネットストリーミングにおける標準化の流れとして、HTTP(Hypertext Transfer Protocol)ストリーミングによるVOD（Video On Demand）ストリーミングや、ライブストリーミングに適用される方式の標準化が行われている。
特に、ISO/IEC/MPEGで標準化が行われているMPEG-DASH(Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP)が注目されている（例えば、非特許文献１参照）。
また、MPEG DASHでは、SAND（Server and Network Assisted DASH）において、プロキシやCDNエッジサーバがクライアントに対してDASHセグメント（segment）のキャッシュ状況（アベイラビリティ（availability））を知らせるステータス（status）メッセージが定義されている（例えば、非特許文献２参照）。
ISO/IEC 23009-1:2012 Information technology Dynamic adaptive streaming over HTTP (DASH) ISO/IEC JTC 1/SC 29/WG 11, Information Technology - Dynamic adaptive streaming over HTTP (DASH) - Part 5: Server and network assisted DASH (SAND), FDIS ISO/IEC 23009-5, N15991, 2015-02-19
ところで、MPEG DASHでは、DASHストリーミング（例えば、複数のビットレート等、トランスポート特性の異なるストリーム）を複数のトランスポートメディアに割り当てることができる。例えば、MPEG DASHにおいて、ATSCや3GPP-MBMSなどの放送と双方向配信メディアとにDASHストリーミングを割り当てることが想定される。このように、DASHストリーミングを複数のトランスポートメディアの割り当てる際に、より確実に割り当ての最適化および効率化を図ることが求められている。
本開示は、このような状況に鑑みてなされたものであり、複数のトランスポートメディアの割り当てを最適化および効率化することができるようにするものである。
本開示の第１の側面のコンテンツ提供システムは、コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信するコンテンツ配信装置と、特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを、前記コンテンツ配信装置に提供するコンテンツ提供装置とを備える。
本開示の第１の側面のコンテンツ提供方法は、コンテンツ提供システムが、コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信することと特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供することとを含む。
本開示の第１の側面のプログラムは、コンテンツ提供システムのコンピュータに、コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信することと、特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供することとを含む処理を実行させる。
本開示の第１の側面においては、コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用してコンテンツが配信される。そして、特徴の異なる複数のストリームにより構成されるコンテンツを配信するにあたり、それぞれのストリームの配信を、複数のネットワークで分配する際の判断基準となるポリシーが提供される。
本開示の第２の側面のコンテンツ提供システムは、コンテンツ配信ネットワークを構成するサーバと、前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置とを備え、前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得する。
本開示の第２の側面のコンテンツ提供方法は、コンテンツ提供システムは、コンテンツ配信ネットワークを構成するサーバと、前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置とを備え、前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得することを含む。
本開示の第２の側面のプログラムは、コンテンツ配信ネットワークを構成するサーバと、前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置とを備えるコンテンツ提供システムのコンピュータに、前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得することを含む処理を実行させる。
本開示の第２の側面においては、サーバまたはクライアント装置により、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータが参照されて、優先度の高い順に、コンテンツを構成するセグメントが先行取得される。
本開示の第１の側面によれば、複数のトランスポートメディアの割り当てを最適化および効率化することができる。本開示の第２の側面によれば、セグメントのデータ配信における遅延を削減することができる。
インフィニットシーティングの概念を説明する図である。 インフィニットシーティングを提供するサービスのイメージを説明する図である。 MPDを利用して、ユニキャストおよび放送でリソース割り当てを行う概略について説明する図である。 MPDを利用して、放送およびMBMSでリソース割り当てを行う概略について説明する図である。 シートロケーションと、ビューおよびエンコーディングとの関係について説明する図である。 それぞれのシートごとに撮影される全天球ビューと、アングルごとのビューとの関係を示す図である。 優先シートをなるべく放送でプッシュするように放送とネットとを割り当てるポリシーの一例を示す図である。 ROIアングルビューをなるべく放送でプッシュする場合の割り当ての一例を示す図である。 レベルと放送負荷との関係を示す図である。 優先シートをなるべく放送でプッシュする場合の割り当て例を表現したDistributionPolicy要素の内容を示す図である。 ROIアングルビューをなるべく放送でプッシュする場合の割り当て例を表現したDistributionPolicy要素の内容を示す図である。 MPD内に記述する場合のDistributionPolicyのXML表記の一例を示す図である。 オプショナルなDistributionMediaDependantExtension要素について説明する図である。 MPDの記述例を示す図である。 図１４に示すMPDから生成されるべき有効なMPDを示す図である。 MPDの再構成について構造的に示す図である。 MPDの記述例を示す図である。 図１７に示すMPDから生成されるべき有効なMPDを示す図である。 MPDの記述例を示す図である。 図１９に示すMPDから生成されるべき有効なMPDを示す図である。 MPDの再構成について構造的に示す図である。 MPDの再構成について構造的に示す図である。 コンテンツ提供システムの第１の構成例を示す図である。 MPD/DistricutionGroupをヒントとして生成されるMPDについて説明する図である。 コンテンツ提供システムの第２の構成例を示す図である。 コンテンツ配信処理を説明するフローチャートである。 一般的なMPD Eventの一例を示す図である。 In-band Event Signalingの一例を示す図である。 MPDの当該AdaptationSet/Representation要素にInbandEventStream要素を配置する例を示す図である。 DASH Eventによるポリシー／レベル通知の一例を示す図である。 MPDの記述例を示す図である。 emsgボックスの記述例を示す図である。 MPDの記述例を示す図である。 コンテンツ提供システムの第３の構成例を示す図である。 クライアント側で再構成できるようにしたMPDを示す図である。 クライアントで生成されたMPDを示す図である。 クライアントで生成されたMPDを示す図である。 コンテンツ配信処理を説明するフローチャートである。 コンテンツ配信処理を説明するフローチャートである。 クライアントでパースされたMPDの一例を示す図である。 クライアントで検出されたIn-band Event、および、再構成されたMPDの一例を示す図である。 クライアントでパースされたMPDの一例を示す図である。 クライアントで検出されたIn-band Event、および、再構成されたMPDの一例を示す図である。 コンテンツ配信処理を説明するフローチャートである。 コンテンツ配信処理を説明するフローチャートである。 クライアントでパースされたMPDの一例を示す図である。 クライアントで検出されたIn-band Event、および、再構成されたMPDの一例を示す図である。 クライアントでパースされたMPDの一例を示す図である。 クライアントで検出されたIn-band Event、および、再構成されたMPDの一例を示す図である。 MPD拡張のバリエーションを示す図である。 MPD拡張のバリエーションを示す図である。 メッセージングインターフェイスが定義を示す図である。 DANE間でやりとりされるメッセージについて説明する図である。 SANDのメッセージのやり取りについて説明する図である。 DASHクライアントにおける処理の流れを示す図である。 MPDUpdateDirectiveメッセージついて説明する図である。 MPDUpdateDirectiveメッセージの一例を示す図である。 MPDUpdateDirectiveフラグメントのインスタンスの第１の記述例を示す図である。 MPDUpdateDirectiveフラグメントのインスタンスの第２の記述例を示す図である。 MPDUpdateDirectiveフラグメントのインスタンスの第３の記述例を示す図である。 MPDUpdateDirectiveフラグメントのインスタンスの第４の記述例を示す図である。 コンテンツ配信処理を説明するフローチャートである。 コンテンツ配信処理を説明するフローチャートである。 クライアントでパースされたMPDの一例を示す図である。 MPDUpdateDirectiveの一例を示す図である。 クライアントで再構成されたMPDの一例を示す図である。 クライアントでパースされたMPDの一例を示す図である。 MPDUpdateDirectiveの一例を示す図である。 クライアントで再構成されたMPDの一例を示す図である。 放送系のシグナリング拡張について説明する図である。 MPDUpdateDirectiveフラグメントのインスタンスの第１の記述例を示す図である。 MPDUpdateDirectiveフラグメントのインスタンスの第２の記述例を示す図である。 MPDUpdateDirectiveフラグメントのインスタンスの第３の記述例を示す図である。 MPDUpdateDirectiveフラグメントのインスタンスの第４の記述例を示す図である。 コンテンツ配信処理を説明するフローチャートである。 コンテンツ配信処理を説明するフローチャートである。 クライアントでパースされたMPDの一例を示す図である。 クライアントで再構成されたMPDの一例を示す図である。 クライアントで再構成されたMPDの一例を示す図である。 クライアントで再構成されたMPDの一例を示す図である。 遅延制約の低いものをネットで配信する場合の割り当て例を表現したDistributionPolicy要素の内容を示す図である。 MPDの記述例を示す図である。 図８２に示すMPDから生成されるべき有効なMPDを示す図である。 ATSC3.0クライアント実装モデルを示す図である。 Annex.ATSC3.0プロトコルスタックを示す図である。 ROUTE/DASHベースのスタックを示す図である。 優先度を示すメタデータを参照して、セグメントを先行取得するようなコンテンツ提供システムの概要を示す図である。 セグメントポピュラリティータイムラインのエレメントの定義例を示す図である。 セグメントポピュラリティータイムラインのエレメントを使用したMPEG DASHのMPDの例を示す図である。 セグメントポピュラリティータイムラインのエレメントの第１のバリエーションを示す図である。 第１のバリエーションのセグメントポピュラリティータイムラインのエレメントを使用したMPEG DASHのMPDの例を示す図である。 第２のバリエーションのセグメントポピュラリティータイムラインのエレメントを使用したMPEG DASHのMPDの例を示す図である。 セグメントポピュラリティータイムラインのエレメントの第３のバリエーションについて説明する図である。 ディストリビューションポリシーのエレメントにおけるレベルのエレメントを、DPレベルタイムラインのエレメントに置き換えた例を示す図である。 第３のバリエーションディストリビューションポリシーの記述例を示す図である。 セグメントを先行取得する先行取得処理の第１の処理例を説明するフローチャートである。 先行取得処理（アダプテーションセット）について説明するフローチャートである。 先行取得処理について説明する（リプレゼンテーション）について説明するフローチャートである。 セグメントを先行取得する先行取得処理の第２の処理例を説明するフローチャートである。 SANDメッセージの記述例を示す図である。 優先度順に複数列挙したSANDメッセージの記述例を示す図である。 CDNサーバへのセグメントポピュラリティータイムラインの利用時に優先すべきソースの値を通知する処理の概念を説明する図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
＜Infinite seatingについて＞
まず、図１を参照して、本技術を適用したコンテンツ配信方法で実現されるインフィニットシーティング（Infinite seating）の概念について説明する。
昨今のVR（virtual reality）に対する盛り上がりから、VRベースでインフィニットシーティングのサービスを提供可能とするユースケースをサポートする技術が求められている。
例えば、スポーツイベントや、コンサート、ゲームショー、テレビショーなどのブロードキャストまたはマルチキャストにおいて、複数の特定の席（場所）からの360°ビューを提供する値段を、優先シートと、その他のシートとで差を設けることができる。そして、ユーザは、複数の優先シートおよびその他のシートの中から、任意のシートを選んでコンテンツを視聴したり、それらのシートを自由に切り替えたりすることができる。
例えば、図１に示す例において、ハッチングが施された丸印が、優先シート（Reserved）を表しており、ハッチングが施されていない丸印が、その他のシート（Other）を表している。そして、複数のユーザは、それぞれ任意のシートからの360°ビューのコンテンツを視聴することができ、例えば、図１の例では、ユーザＵ１およびユーザＵ２は、同一の優先シートからの360°ビューのコンテンツを視聴している。また、ユーザＵ３およびＵ４は、それ以外の優先シートからの360°ビューのコンテンツを視聴しており、ユーザＵ５およびＵ６は、その他のシートからの360°ビューのコンテンツを視聴している。
図２を参照して、このようなインフィニットシーティングのユースケースを適用したサービスを提供するシステムのイメージについて説明する。
図２に示すコンテンツ提供システム１１は、全天球カメラ１２−１乃至１２−３からクライアント１３−１乃至１３−３へ、それぞれ放送ネットワーク１４および双方向ネットワーク１５を介してコンテンツが配信されるように構成されている。そして、コンテンツ提供システム１１により、例えば、マルチフィールド競技中継等のスタジアム収録ストリームを配信するサービスを提供することができる。
このようなコンテンツ提供システム１１では、快適なVR視聴体験を提供するために、ユーザの視聴アングルの変化が起こる際に、とりあえずユーザが選択しているシートの全天球ビューから必要な領域が切り出される。そして、その切り出した領域を、低遅延かつ表示連続性を担保するためにアングル変化に追随して表示し、ユーザの視聴アングルが定まると、その視聴アングルの高解像度ビューに切り替えて表示する手法が用いられる。
そして、このようなサービスの提供を実現するために、複数のシートに全天球カメラ１２が設置され、それぞれのシートから観ることができる全天球ビューと、各アングルの高解像度ビューがストリーミングされる。また、ユーザは、クライアント１３を利用してコンテンツを視聴することができる。例えば、ユーザによるコンテンツの視聴は、HMD（Head Mount Display）などに実装されるVRクライアントを利用する形態が想定される。
ところで、配信コストの制約がない場合には、すべての全天球ビューストリームとすべてのアングルビューストリームとを、ビットレートや遅延等のQoS（Quality of Service）が保証された放送ネットワーク１４で配信することが考えられる。しかしながら、そのような配信を行うのは、配信コストがかかり過ぎてしまうため、現実的ではない。
そのため、例えば、比較的に多くの視聴者が選択することが想定されるシートの全天球ビューストリームを放送ネットワーク１４でプッシュ型配信し、その他のストリームは双方向ネットワーク１５によりプル型配信することが好ましい。または、配信コストに余裕がある場合には、全天球ビューストリームに加えて、視聴者が見る可能性の高いROI（Region Of Interest）高解像度アングルビューストリームのみを放送ネットワーク１４でプッシュ型配信することが考えられる。また、ユーザが選択するシートの人気度がわからない場合には、すべてのシートの全天球ストリームを放送ネットワーク１４でプッシュ配信することも考えられる。このような様々な組み合わせや、レベル分けなどを行うことが現実的である。
このように、配信コストの異なる複数のネットワーク（トランスポートメディア）を介して配信する場合、配信メディアのコストに応じて、複数のトランスポートメディアの割り当てが行われる。例えば、3GPP-MBMSプラットフォームでは、セル毎に放送および双方向それぞれのネットワークの帯域構成を柔軟に割り当てることができる。ところで、このように複数のトランスポートメディアにストリームを割り当てるとき、それらの組み合わせを最適にかつ効率的に行うためには、優先的に割り当てを行う優先度がヒント情報として用いられる。しかしながら、そのようなヒント情報は、通常、コンテンツプロバイダのみが把握している。
また、今後、コンテンツ提供者から提供されるサービスストリーム群が、複数のトランスポートメディアを保有するサービスプロバイダ（CDN（Content Delivery Network）プロバイダ）を介して配信する形態が一般化する可能性が高いと想定される。そのため、このようなリソース割り当てを最適化かつ効率化するためのヒント情報の必要性が高まることが想定される。
例えば、図３および図4に示すように、リソース割り当てを最適化かつ効率化するためのヒント情報は、MPEG DASHにおいてメタ情報を記述するのに用いられるMPD（Media Presentation Description）を利用して、CDNプロバイダに提供することができる。
図３に示すコンテンツ提供システム１１において、コンテンツプロバイダ２１のMPDには、ユニキャストと放送とでリソースを分配する方針を示す分配ポリシが記述されている。そして、CDNサービスプロバイダ２２は、その分配ポリシを参考にして、ユニキャスト優先およびブロードキャスト優先のどちらかを選択することができる。例えば、双方向ネットワーク１５を利用したコンテンツの配信を優先する場合にはユニキャスト優先が選択され、放送ネットワーク１４を利用したコンテンツの配信を優先する場合にはブロードキャスト優先が選択される。
図３の例では、CDNサービスプロバイダ２２−１は、ユニキャスト優先を選択し、双方向ネットワーク１５を利用したコンテンツの配信が、放送ネットワーク１４を利用したコンテンツの配信よりも優先的に行われる。また、CDNサービスプロバイダ２２−２は、ブロードキャスト優先を選択し、放送ネットワーク１４を利用したコンテンツの配信が、双方向ネットワーク１５を利用したコンテンツの配信よりも優先的に行われる。
また、図４に示すコンテンツ提供システム１１では、放送およびMBMS（Multimedia Broadcast and Multicast Service）によるリソースの分配が行われる。そして、図４に示す例では、CDNサービスプロバイダ２２は、MBMS優先を選択し、MBMSを利用したコンテンツの配信が、双方向ネットワーク１５を利用したコンテンツの配信よりも優先的に行われている。また、放送サービスプロバイダ２３は、ブロードキャスト優先を選択し、放送ネットワーク１４を利用したコンテンツの配信のみが行われる。
また、図５では、フィールド競技やパレード等を視聴するために構成されたシートロケーションと、それぞれのシートごとに撮影されるビューおよびエンコーディングとの関係について説明する。
例えば、シートロケーションとしては、フィールド競技やパレードなどの近くに配置された優先シート（Reserved）と、優先シートよりも遠くに配置されたその他シート（Other）とがある。そして、それぞれのシートごとに、全天球ビュー（ViewScope-ALL）、アングルごとのビューを配信することができる。さらに、アングルごとのビューとして、視聴者が見たいと思う確率の高いアングルビュー（ViewScope-ROI）と、それ以外のアングルビュー（ViewScope-NonROI）とがある。
また、全天球ビュー（ViewScope-ALL）はEncodigタイプ（Base-通常解像度）でエンコードされ、各アングルビュー（ViewScope-ROI/NonROI）はEncodingタイプ(Enhanced-通常解像度に比して高精細な高解像度)でエンコードされるものとする。
図６は、上述のサービスを実現するためのMPDの構成例を示す図である。
図６に示すように、１つのMPD内に、各優先シートから生成される全天球ビューのAdaptationSet（AS-R-B-All）、各優先シートの各アングルビューのAdaptationSet（AS-R-E-ROI/NonROI）、各その他シートから生成される全天球ビューのAdaptationSet（AS-O-B-All）、各その他シートの各アングルビューのAdaptationSet（AS-O-E-ROI/NonROI）を記述することができる。なお、以下の説明では、AdaptationSetは、RepresentationやSubRepresentationに置き換えることもできるものとする。
そして、上述のサービスをコストやトランスポート特性の異なるメディアを利用して配信する場合、ストリーム(AdaptationSet)のメディアへの割り当てが行われる。ここでは、コストやトランスポート特性の異なるメディアとして、例えば、放送およびネットの２種類について説明する。
図７には、優先シートをなるべく放送でプッシュするように放送とネットとを割り当てるポリシーの一例が示されている。
図７に示す例では、レベル１、レベル２、およびレベル３の順に、放送負荷が増大するように放送とネットとが割り当てられている。ここで、優先シートのScope-ALLが通常解像度でエンコードされたコンテンツを第１のストリームとし、その他のシートのViewScope-ALLが通常解像度でエンコードされたコンテンツを第２のストリームとする。また、優先シートのViewScope-ROIが高解像度でエンコードされたコンテンツを第３のストリームとし、その他のシートのViewScope-ROIが高解像度でエンコードされたコンテンツを第４のストリームとする。また、優先シートのViewScope-NonROIが高解像度でエンコードされたコンテンツを第５のストリームとし、その他のシートのViewScope-NonROIが高解像度でエンコードされたコンテンツを第６のストリームとする。
例えば、レベル１では、第１のストリームが放送で配信され、第２乃至第６のストリームがネットで配信される。また、第２のレベルでは、第１および第３のストリームが放送で配信され、第２のストリーム、および第４乃至第６のストリームがネットで配信される。また、第３のレベルでは、第１のストリーム、第３のストリーム、および第５のストリームが放送で配信され、第２のストリーム、第４のストリーム、および第６のストリームがネットで配信される。
また、図８には、ROIアングルビューをなるべく放送でプッシュするように放送とネットとを割り当てるポリシーの一例が示されている。
図８に示す例では、レベル１、レベル２、レベル３、およびレベル４の順に、放送負荷が増大するように放送とネットとが割り当てられている。そして、図７と同様に、第１乃至第６のストリームが、放送またはネットに割り当てられて配信される。
例えば、レベル１では、第１のストリームが放送で配信され、第２乃至第６のストリームがネットで配信される。また、第２のレベルでは、第１および第３のストリームが放送で配信され、第２のストリーム、および第４乃至第６のストリームがネットで配信される。また、第３のレベルでは、第１乃至第３のストリームが放送で配信され、第４乃至第６のストリームが、ネットで配信される。そして、第４のレベルでは、第１乃至第４のストリームが放送で配信され、第５および第６のストリームが、ネットで配信される。
このようなポリシーを参照することで、リソースの割り当てを最適化および効率化することができる。
＜第１のMPD拡張方法＞
上述の配信メディアの割り当てを最適化するためのヒント情報（ポリシー）をMPDに記述できるようにするための、第１のMPD拡張方法について説明する。
例えば、Periodの下に、新たにDistributionPolicy要素（Period下に複数配置可能）を定義する。
DistributionPolicyが持つ要素／属性には、tag、PolicyDistribution、NumLevels、Level[1]AdaptationSetIDs,Level[2]AdaptationSetIDs,…,Level[NumLevels]AdaptationSetIDs、DistributionMediaDependantExtensionがある。
Tagは、DistributionPolicyそのものを識別する文字列（MPD内でユニーク）である。PolicyDistributionは、ポリシーを表現する文字列（ヒント）である。なお、tagおよびPolicyDistributionはオプションである。NumLevelsは、段階を表すレベル数（数値）である。
Level[1]AdaptationSetIDsは、レベル１に属するas-idの列であり、Level[2]AdaptationSetIDsは、レベル２に属するas-idの列であり、以下、同様に、Level[NumLevels]AdaptationSetIDsは、そのレベルに属するas-idの列である。また、オプションとして、レベルごとのビットレート総和（最大MPDをもとに計算して求める）など負荷リソース割り当ての決定に関与しそうなヒントとなりそうな情報を格納できる領域を用意してもよい。
DistributionMediaDependantExtensionは、例えば、どのレベルインデックスのAdaptationSet群まで以下の拡張を適用するかを示すmaxLevelToBeApplied、当該AdaptationSetに追加する要素であるAttributeToBeApplied:"baseURL='/bc'（放送用URLなど）、その他当該DistributionMediaを説明する属性（文字列）などがある。
第１のMPD拡張方法では、このような汎用的なストリームグループ定義スキームが導入される。
そして、DistributionPolicyのレベル（Level[1]、Level[2]…Level[NumLevels]）を選択することで、図９に示すように、放送負荷を軽減または増加させることができる。
例えば、図９では、左側に向かうに従い放送負荷が軽減し、右側に向かうに従い放送負荷が増加するように並べられており、レベル１に属するas-idの列が最も放送負荷が軽く、レベル１およびレベル２に属するas-idの列が次に放送負荷が軽い。このように、レベルが増加するのに伴って、放送負荷が増加する方向となる。
図１０および図１１には、上述の図７および図８を参照して説明した２種類のリソース割り当て例を表現したDistributionPolicy要素の内容が示されている。即ち、図１０には、”Reservedシートをなるべく放送で”の場合におけるDistributionPolicy要素が示されており、図１１には、”ROIアングルをなるべく放送で”の場合におけるDistributionPolicy要素が示されている。
図１０に示すように、Tag：”１”により識別されるDistributionPolicyは、優先シートをなるべく放送（Reserved over Broadcast）で配信するポリシーであり、放送負荷は、レベル１からレベル３の３段階とされる。そして、上述の図７を参照して説明したように、レベル１では、第１のストリームのみが放送で配信され、レベル２では、第１および第３のストリームが放送で配信され、レベル３では、第１のストリーム、第３のストリーム、および第５のストリームが放送で配信される。このように、レベル１では放送負荷が軽く、レベル３では放送負荷が増えるようにリソースが割り当てられる。
図１１に示すように、Tag：”２”により識別されるDistributionPolicyは、ROIアングルをなるべく放送（ROI over Broadcast）で配信するポリシーであり、放送負荷は、レベル１からレベル４の４段階とされる。そして、上述の図８を参照して説明したように、レベル１では、第１のストリームのみが放送で配信され、レベル２では、第１および第３のストリームが放送で配信され、レベル３では、第１乃至第３のストリームが放送で配信され、レベル４では、第１乃至第４のストリームが放送で配信される。このように、このように、レベル１では放送負荷が軽く、レベル４では放送負荷が増えるようにリソースが割り当てられる。
＜DistributionPolicyの具体例とMPD生成例＞
図１２には、MPD内に記述する場合のDistributionPolicyのXML表記の一例が示されている。
また、図１２に示すようなXML表記が基本構造であるが、例えば、各Levelに属性としてオプショナルなResourceSpecificInformation属性を置くことができ、例えば、<Level resourceSpecificInformation='…' … />のように記述することができる。なお、要素として定義することもできる。ここには、Levelごとのビットレート総和等を、負荷リソース割り当ての決定に関与しそうなヒントとなりそうな情報を格納できる領域を用意してもよい。
例えば、ResourceSpecificInformationとして、このLevelに属するAdaptationSet列の最大ビットレートの総和（maxBitRate）を用いる場合には、<Level maxBitRate='そのLevelに属するAdaptationSet列の最大ビットレートの総和値' … />のように記述できるようにする。
また、とあるLevelまでのAdaptationSet要素群に追加すべき要素（Element）、あるいは、属性（Attribute）を定義できるようにする。例えば、放送配信されることになったAdaptationSet要素に対しては、BaseURL='(放送配信であることを示すurlのプリフィクス)'を追加して示すことができる。
従って、このAdaptationSet要素に対する追加分の"BaseURL='(放送配信であることを示すurlのプリフィクス)'"を指示できるようなオプショナルなDistributionMediaDependantExtension要素として、図１３に示すような記述をDistributionPolicyに配置できるようにする。図１３に示す記述は、とあるレベル値までのLevelに含まれるAdaptationSet列に対して、<ElementToBeAppended>要素に格納されている要素が追加されることを意味する。なお、このように簡易な拡張を施すために特別な要素を用意する場合もあれば、XML Query Update等を利用して要素の追加拡張を表現する場合も考えられる。
例えば、図１４に示すように記述されるMPDがある場合、生成されるべき有効なMPDは、図１５に示すように記述される。即ち、図１６に示すように、Level-2までDistributionMediaDependantExtensionであるBaseURL='/bc'を追加することが適用される。
一方、maxLevelToBeApplied属性がないか、あるいは、maxLevelToBeAppliedが0と指定されるとすると、MPDは、図１７に示すように記述される。そして、それが有効となった際に生成されるべきMPDは、図１８に示すように記述される。ここで、このDistributionMediaDependantExtension要素のmaxLevelToBeApplied属性の値は、後述するMPDとは別のデータ構造（イベント、メッセージ、シグナリング等）で有効なMPDを生成する主体に通知することができるようにする。
さらに、別の例として、クライアントが２種類以上の放送ネットワーク（例えば、ATSC放送および3GPP-MBMSネットワーク）と接続されていて、ATSC放送が<BaseURL>/atscBc</BaseURL>で指定され、3GPP-MBMSネットワーが<BaseURL>/3gppBc</BaseURL>で指定されるものとし、それぞれについてリソース割り当てポリシーが異なるような場合、以下のような２種類のDistributionPolicyを持つMPDを定義する。
例えば、MPDが、図１９に示すように記述される場合、ATSC放送のDistributionPolicy@tag='1'についてはmaxLevelToBeAppliedが２までと指定され、かつ、3GPP MBMS放送のDisitributionPolicy@tag='2'についてはmaxLevelToBeAppliedが１までと指定される場合に、生成されるべきMPDは、図２０に示すようになる。
即ち、図２１に示すように、tag=1（ATSC放送の場合に適用）については、Level-2までDistributionMediaDependantExtensionであるBaseURL='/atscBc'を追加することが適用される。同様に、図２２に示すように、tag=2（3GPP放送の場合に適用）についてはLevel-1までDistributionMediaDependantExtensionであるBaseURL='/3gppBc'を追加することが適用される。
＜コンテンツ提供システムの第１の構成例＞
図２３には、コンテンツプロバイダ２１、CDNサービスプロバイダ２２−１および２２−２、並びに、クライアント１３−１および１３−２により構成されるコンテンツ提供システム１１の構成例が示されている。
図２３に示すように、異なるCDNプラットフォームを有するサービスプロバイダ群において配信リソース管理する場合、各CDNの放送または双方向リソースの帯域配分を考慮し、MPD/DistributionPolicyをヒントとして、それぞれのCDNに最適化されたMPDが生成される。
例えば、コンテンツプロバイダ２１のMPDが、図２４の上側に示すように記載されている場合、CDNサービスプロバイダ２２−１は、MPD/DistricutionGroupをヒントとして、図２４の左下側に示すようなMPD’を生成する。同様に、この場合、CDNサービスプロバイダ２２−２は、MPD/DistricutionGroupをヒントとして、図２４の右下側に示すようなMPD’’を生成する。
このとき、CDNサービスプロバイダ２２−１は、MPD’に記述されているように、AS-1を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1の若干のコピーを準備する。同様に、CDNサービスプロバイダ２２−２は、MPD’’に記述されているように、AS-1およびAS-2を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1およびAS-2の若干のコピーを準備する。
＜コンテンツ提供システムの第２の構成例＞
図２５には、コンテンツプロバイダ２１、CDNセグメントマネジャ３１−１および３１−２を備えるサービスプロバイダ２２Ａ、並びに、クライアント１３−１および１３−２により構成されるコンテンツ提供システム１１Ａの構成例が示されている。
図２５に示すように、3GPP-eMBMSをサポートする配信プラットフォームを有する1つのキャリア（サービスプロバイダ）内で、各eNodeB上のCDNセグメントマネジャ（マルチキャスト/ユニキャストのストリーム割り当て配分を管理するモジュール）が各CDNセグメントの放送/双方向リソースの帯域配分を考慮し、MPD/DistributionPolicyをヒントとして、それぞれのCDNセグメントに最適化されたMPDが生成される。
例えば、コンテンツプロバイダ２１のMPDが、上述した図２４の上側に示すように記載されている場合、CDNセグメントマネジャ３１−１は、MPD/DistricutionGroupをヒントとして、上述した図２４の左下側に示すようなMPD’を生成する。同様に、この場合、CDNセグメントマネジャ３１−２は、MPD/DistricutionGroupをヒントとして、上述した図２４の右下側に示すようなMPD’’を生成する。
このとき、CDNセグメントマネジャ３１−１は、MPD’に記述されているように、AS-1を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1の若干のコピーを準備する。同様に、CDNセグメントマネジャ３１−２は、MPD’’に記述されているように、AS-1およびAS-2を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1およびAS-2の若干のコピーを準備する。
＜コンテンツ配信処理＞
図２６を参照して、図２３のコンテンツ提供システム１１においてコンテンツを配信するコンテンツ配信処理の一例について説明する。
ステップＳ１０１において、コンテンツプロバイダ２１は、MPDおよびAS（AdaptationSetおよびDASHセグメントの列）を生成し、CDNサービスプロバイダ２２に転送する。
CDNサービスプロバイダ２２のリソースマネジャは、コンテンツプロバイダ２１によりステップＳ１０１で転送されてくるMPDおよびASを受信する。そして、CDNサービスプロバイダ２２のリソースマネジャは、ステップＳ１１１において、放送または双方向配信のリソースを割り当て、MPDを書き換え、MPDおよびASを双方向サーバおよび放送サーバそれぞれに配置して、それらを転送させる。
CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりステップＳ１１１でMPDおよびASが配置された後、クライアント１３からMPDの要求があると、ステップＳ１２１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からASの要求があると、ステップＳ１２２において、ASをクライアント１３に転送する。
CDNサービスプロバイダ２２の放送サーバは、リソースマネジャによりMPDおよびASが配置された後、ステップＳ１３１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の放送サーバは、ステップＳ１３２において、ASをクライアント１３に転送する。
クライアント１３の（放送チューナ・ミドルウエアが実装された）ローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ１３１で転送されてくるMPDを取得する。また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるMPDの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ１２１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ１４１において、放送サーバから取得したMPD、および、双方向サーバから取得したMPDのどちらか一方のMPDをDASHクライアントに転送する。
その後、クライアント１３のローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ１３２で転送されてくるASを取得する。また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるASの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ１２２で転送されてくるASを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ１４２において、放送サーバから取得したAS、および、双方向サーバから取得したASのどちらか一方のASをDASHクライアントに転送する。
クライアント１３のDASHクライアントは、ステップＳ１５１において、サービスまたはコンテンツの選択が行われると、その選択されたサービスまたはコンテンツのMPDを要求する。その後、クライアント１３のDASHクライアントは、クライアント１３のローカルプロキシサーバによりステップＳ１４１で転送されたMPDを取得する。
続いて、クライアント１３のDASHクライアントは、ステップＳ１５２において、取得したMPDをパースし、ASを特定して、その特定したASを要求する。その後、クライアント１３のDASHクライアントは、クライアント１３のローカルプロキシサーバによりステップＳ１４２で転送されたASを取得する。そして、クライアント１３のDASHクライアントは、ステップＳ１５３において、取得したASを再生する。
以上のように、コンテンツ提供システム１１では、CDNサービスプロバイダ２２が放送または双方向のトランスポートリソースの割り当てを担うことができる。そして、CDNサービスプロバイダ２２のリソースマネジャにおけるMPDの書き換えにより、トランスポートリソースの割り当てをクライアント１３に通知することができる。
なお、図２５のコンテンツ提供システム１１Ａにおいても、コンテンツ提供システム１１と同様のコンテンツ配信処理が行われ、サービスプロバイダ２２ＡのCDNセグメントマネジャ３１により、放送または双方向のトランスポートリソースの割り当てが行われる。
＜DASH EventによるDistributionPolicyとそのレベルの通知＞
MPEG DASHではDASH Eventと呼ばれるイベント通知機構が定義されており、２種類のEventの転送方法が規定されている。第１のEventの転送方法はMPD Eventであり、第２のEventの転送方法はIn-band Event Signalingである。
例えば、MPD Eventは、DASH-MPDのPeriod単位で、EventStream要素を追加することにより、MPD内にPeriod単位でEvent発火のスケジュールと、それぞれのEvent発火のタイミングでクライアントが処理すべき（クライアント上で稼働するアプリケーション等に渡すべき）イベントデータを記述することができる。
図２７には、一般的なMPD Eventの一例が示されている。
例えば、MPD Eventは、EventStream/@schemeIdUri（とオプショナルなEventStream/@value）属性によりイベントの種類を定義し、EventStream/Event要素のコンテンツパートにイベントデータを付加することができる。即ち、MPD/Period/EventStream/Event要素のコンテンツ部に格納されるEvent関連データのフォーマット（何を格納すべきか）については、EventStream/@schemeIdUri属性の値（以下の例では'urn:xxx'）によって特定（定義）される。例えば、MPD Eventは、MPDの送出前に、MPD内に記述されるPeriodの内容が確定できる場合にのみ適用可能である。
図２８には、In-band Event Signalingの一例が示されている。
In-band Event Signalingは、MP4のブランド名"emsg"box typeを有する"DASHEventMessageBox"と呼ばれるmp4 boxをDASH Segmentに挿入して、セグメントストリームの中（in-stream）で転送する。例えば、In-band Event Signalingの場合は、DASHEventMessageBoxのscheme_id_uriフィールド（とオプショナルなvalueフィールド）にイベントの種類を定義し、message_dataフィールドにイベントデータを付加する。ここで、図２８に示されている"presentation_time_delta = 0"は、このemgsボックスが包含されるセグメントのEarliestPresentationStimeからのオフセットを示し、"event_duration = 0xFFFF "の場合、無限を示している。
そして、これらのDASHEventMessageBoxを、DASHセグメントのbox構造の中に配置する。
例えば、図２８に示すemgs boxを格納するDASH segmentがどのストリーム(AdaptationSet/Representation)に含まれて転送されるかを指定するには、図２９のように、MPDの当該AdaptationSet/Representation要素にInbandEventStream要素が配置される。
以上のように説明したDASH Event（MPD Event、ならびに、In-band Event）により、DistributionPolicyのタグ値"tag"とレベル値"level"を指定して、クライアント側でどのDistributionPolicy定義のどのレベル（DistributionPolicy/DistributionMedia DependantExtension/maxLevelToBeApplied）まで、当該DistributionPolicy /DistributionMediaDependantExtension/ElementToBeAppendedが適用されるかを判断できるようにする。これにより、サーバ側でMPDを書き換えることなく、Event送出のタイミングで動的に配信リソースのストリーム割り当てを構成変更することができるため、粒度の細かなリソース割り当て制御が可能となる。
なお、図３０には、DASH Eventによるポリシー／レベル通知の一例が示されている。
また、MPD EventによりDistributionPolicyのtag+levelを通知する場合、MPD/Period/EventStream@schemeIdUriを"urn:mpeg:dash:event:distributionPolicy"とし、図３１に示すように、MPD/Period/EventStream/Event要素のコンテンツパートに"tag値,level値"のように格納する。
一方、In-band EventによりDistributionPolicyのtagとlevelを通知する場合、図３２に示すように、emsgボックスのscheme_id_uriフィールドに" urn:mpeg:dash:event: distributionPolicy"を格納し、message_data[]フィールドに"tag値,level値"の文字列を格納し、このemsgボックスが含まれたDASH segmentが配信される可能性のあるRepresentationを、MPD/Period/AdaptationSet/Representation/InbanedEventStream @schemeIdUri=' urn:mpeg:dash:event:distributionPolicy'と指定することによってクライアント側に周知する。
ここで、emsgボックスは、図３２に示すように記述される。そして、上述したIn-band Eventが抽出される可能性のあるAdaptationSet/Representationを指定するためのMPDは、図３３に示すように記述される。
＜コンテンツ提供システムの第３の構成例＞
図３４には、コンテンツプロバイダ２１、CDNセグメントマネジャ３１−１および３１−２を備えるCDNサービスプロバイダ２２Ｂ、並びに、クライアント１３−１および１３−２により構成されるコンテンツ提供システム１１Ｂの第３の構成例が示されている。
図３４に示すコンテンツ提供システム１１Ｂでは、各CDNセグメントマネジャ３１がDistributionPolicyを含むMDPをクライアント１３に送付して、クライアント１３において、いずれかのAdaptationSet内のDASH Event（in-band event）を検知して、それぞれのCDNセグメントに最適化されたMPDが動的に生成される。このように、DASH Eventによる動的なMDPの生成を実現するためのDASH Eventの拡張について説明する。
例えば、コンテンツプロバイダ２１のMPDは、図３５の上側に示すように記述される。そして、CDNセグメントマネジャ３１のMPDは、図３５の下側に示すように、DistributionPolicyと、別途シグナルされるDistributionPolicy@tag値+Level値により、クライアント１３側において、MPDを再構成できるようにする。そして、CDNセグメントマネジャ３１は、MPDは書き換えずにMPD Eventにて、クライアント１３に動的に周知する。
このとき、CDNセグメントマネジャ３１−１は、MPDに記述されているように、AS-1を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1の若干のコピーを準備する。同様に、CDNセグメントマネジャ３１−２は、MPDに記述されているように、AS-1およびAS-2を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1およびAS-2の若干のコピーを準備する。
そして、図３６に示すように、CDNセグメントマネジャ３１−１の、いずれかのASのDASHセグメント内のIn-band Eventが、MPD Eventにてクライアント１３−１に、動的に周知される。そして、クライアント１３−１が、Level値をもとにMPD’を生成する。
同様に、図３７に示すように、CDNセグメントマネジャ３１−２の、いずれかのASのDASHセグメント内のIn-band Eventが、MPD Eventにてクライアント１３−２に、動的に周知される。そして、クライアント１３−２が、Level値をもとにMPD’’を生成する
＜コンテンツ配信処理＞
図３８乃至図４３を参照して、図３４のコンテンツ提供システム１１Ｂにおいてコンテンツを配信するコンテンツ配信処理の一例について説明する。
図３８のステップＳ２０１において、コンテンツプロバイダ２１は、MPDおよびASを生成し、CDNサービスプロバイダ２２Ｂに転送する。
図３８のステップＳ２１１において、CDNサービスプロバイダ２２Ｂのリソースマネジャは、双方向配信のリソースを割り当て、DistributionPolicy付きのMPDおよびASを双方向サーバに配置して、それらを転送させる。ステップＳ２１２において、CDNサービスプロバイダ２２Ｂのリソースマネジャは、放送または双方向配信のリソースを割り当て、In-band EventをAS（N-1）へ挿入し、AS（N以降）を双方向サーバおよび放送サーバそれぞれに配置転換して、それらを転送させる。
同様に、図３９のステップＳ２１３において、CDNサービスプロバイダ２２Ｂのリソースマネジャは、放送または双方向配信のリソースを割り当て、In-band EventをAS（M-1）へ挿入し、AS（M以降）を双方向サーバおよび放送サーバそれぞれに配置転換して、それらを転送させる。
CDNサービスプロバイダ２２Ｂの双方向サーバは、リソースマネジャによりステップＳ２１１でDistributionPolicy付きのMPDおよびASが配置された後、クライアント１３からMPDの要求があると、図３８のステップＳ２２１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２Ｂの双方向サーバは、クライアント１３からASの要求があると、ステップＳ２２２において、ASをクライアント１３に転送する。また、CDNサービスプロバイダ２２Ｂの双方向サーバは、リソースマネジャによりステップＳ２１２でAS（N以降）が配置転換された後、クライアント１３からASの要求があると、ステップＳ２２３において、AS（N-1）をクライアント１３に転送する。
同様に、CDNサービスプロバイダ２２Ｂの双方向サーバは、クライアント１３からASの要求があると、図３９のステップＳ２２４において、AS（N）をクライアント１３に転送する。その後、CDNサービスプロバイダ２２Ｂの双方向サーバは、リソースマネジャによりAS（M以降）が配置転換された後、クライアント１３からAS（M-1）の要求があると、ステップＳ２２５において、AS（M-1）をクライアント１３に転送する。さらに、CDNサービスプロバイダ２２Ｂの双方向サーバは、クライアント１３からAS（M）の要求があると、ステップＳ２２６において、AS（M）をクライアント１３に転送する。
CDNサービスプロバイダ２２Ｂの放送サーバは、リソースマネジャによりステップＳ２１２でAS（N以降）が配置転換された後、図３９のステップＳ２３１において、AS（N）をクライアント１３に転送する。その後、CDNサービスプロバイダ２２Ｂの放送サーバは、リソースマネジャによりステップＳ２１３でAS（M以降）が配置転換された後、ステップＳ２３２において、AS（M-1）をクライアント１３に転送する。
クライアント１３のローカルプロキシサーバは、DASHクライアントによるMPDの要求をCDNサービスプロバイダ２２Ｂに送信し、その要求に応じて、CDNサービスプロバイダ２２Ｂの双方向サーバによりステップＳ２２１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ２４１において、MPDをDASHクライアントに転送する。また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるASの要求をCDNサービスプロバイダ２２Ｂに送信し、その要求に応じて、CDNサービスプロバイダ２２Ｂの双方向サーバによりステップＳ２２２で転送されてくるASを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ２４２において、ASをDASHクライアントに転送する。
また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるAS後続セグメント（N-1）の要求をCDNサービスプロバイダ２２Ｂに送信し、その要求に応じて、CDNサービスプロバイダ２２Ｂの双方向サーバによりステップＳ２２３で転送されてくるAS（N-1）を取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ２４３において、AS（N-1）をDASHクライアントに転送する。
以下、同様に、クライアント１３のローカルプロキシサーバは、図３９のステップＳ２４４においてAS（N）をDASHクライアントに転送し、ステップＳ２４５においてAS（M-1）をDASHクライアントに転送し、ステップＳ２４６において、AS（M）をDASHクライアントに転送する。
クライアント１３のDASHクライアントは、ステップＳ２５１において、サービスまたはコンテンツの選択が行われると、その選択されたサービスまたはコンテンツのMPDを要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２Ｂの双方向サーバによりステップＳ２２１で転送されたMPD、即ち、クライアント１３のローカルプロキシサーバによりステップＳ２４１で転送されたMPDを取得する。
続いて、クライアント１３のDASHクライアントは、ステップＳ２５２において、取得したMPDをパースし、ASを特定して、その特定したASを要求する。なお、パースされたMPDの一例が、図４０に示されている。
その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ２２２で転送されたAS、即ち、クライアント１３のローカルプロキシサーバによりステップＳ２４２で転送されたASを取得する。そして、クライアント１３のDASHクライアントは、ステップＳ２５３において、取得したASを再生する。
さらに、クライアント１３のDASHクライアントは、ステップＳ２５４において、AS後続セグメント（N-1）を要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ２２３で転送されたAS（N-1）、即ち、クライアント１３のローカルプロキシサーバによりステップＳ２４３で転送されたAS（N-1）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ２５５において、取得したAS（N-1）を再生する。
そして、クライアント１３のDASHクライアントは、ステップＳ２５６において、In-band Eventを検出し、MPDを再構成する。なお、検出されたIn-band Event、および、再構成されたMPDの一例が、図４１に示されている。
以下、同様に、クライアント１３のDASHクライアントは、図３９のステップＳ２５７において、MPDをパースし、セグメント（N）を特定して、その特定したAS（N）を要求し、ステップＳ２５８においてAS（N）を再生する。なお、ステップＳ２５７でパースされたMPDの一例が、図４２に示されている。
また、同様に、クライアント１３のDASHクライアントは、ステップＳ２５９において、AS後続セグメント（M-1）を要求し、ステップＳ２６０においてAS（M-1）を再生する。さらに、同様に、クライアント１３のDASHクライアントは、ステップＳ２６１において、In-band Eventを検出し、MPDを再構成し、ステップＳ２６２において、MPDをパースし、セグメント（M）を特定して、その特定したAS（M）を要求し、ステップＳ２６３において、AS（M）を再生する。なお、検出されたIn-band Event、および、再構成されたMPDの一例が、図４３に示されている。
以上のように、コンテンツ提供システム１１Ｂでは、CDNサービスプロバイダ２２ＢのCDNセグメントマネジャ３１がDistributionPolicyを含むMDPをクライアント１３に送付する。そして、クライアント１３は、いずれかのAdaptationSet内のDASH Event（in-band event）を検知して、それぞれのCDNセグメントに最適化されたMPDを動的に生成することができる。
＜コンテンツ配信処理＞
図４４乃至図４９を参照して、図３４のコンテンツ提供システム１１Ｂにおいてコンテンツを配信するコンテンツ配信処理の他の例について説明する。
上述の図３７および図３８のフローチャートを参照して説明したコンテンツ配信処理においては、DASHクライアントが、放送チューナ・ミドルウエアが実装されたローカルプロキシサーバから、ネットワークの違い（放送か、ネットか）を意識せずに、セグメントを取得することができる。その他、例えば、このようなローカルプロキシサーバを介さずに処理を行ってもよい。
また、CDNサービスプロバイダ２２は、上述したような放送サーバを備えるのではなく、２つの双方向サーバを備える構成とすることができる。例えば、第１の双方向サーバおよび第２の双方向サーバには、それぞれ異なるＩＰアドレスがアサインされており、例えば、第１の双方向サーバ提供されるセグメントのurlはNo.1から始まり、第２の双方向サーバ提供されるセグメントのurlはNo.2から始まるものとする。
図４４のステップＳ３０１において、コンテンツプロバイダ２１は、MPDおよびASを生成し、CDNサービスプロバイダ２２Ｂに転送する。
図４４および図４５のステップＳ３１１乃至Ｓ３１３において、CDNサービスプロバイダ２２Ｂのリソースマネジャは、図３８および図３９のステップＳ２１１乃至Ｓ２１３と同様の処理を行う。
CDNサービスプロバイダ２２Ｂの第１の双方向サーバは、リソースマネジャによりステップＳ３１１でDistributionPolicy付きのMPDおよびASが配置された後、クライアント１３からMPDの要求があると、図４４のステップＳ３２１において、MPDをクライアント１３に転送する。続いて、CDNサービスプロバイダ２２Ｂの第１の双方向サーバは、クライアント１３からASの要求があると、ステップＳ３２２において、ASをクライアント１３に転送する。また、CDNサービスプロバイダ２２Ｂの第１の双方向サーバは、リソースマネジャによりステップＳ３１２でAS（N以降）が配置転換された後、クライアント１３からASの要求があると、ステップＳ３２３において、AS（N-1）をクライアント１３に転送する。
その後、CDNサービスプロバイダ２２Ｂの第１の双方向サーバは、リソースマネジャによりAS（M以降）が配置転換された後、クライアント１３からAS（M）の要求があると、ステップＳ３２４において、AS（M）をクライアント１３に転送する。
CDNサービスプロバイダ２２Ｂの第２の双方向サーバは、リソースマネジャによりステップＳ３１２でAS（N以降）が配置転換された後、クライアント１３からAS（N）の要求があると、ステップＳ３３１において、AS（N）をクライアント１３に転送する。その後、CDNサービスプロバイダ２２Ｂの第２の双方向サーバは、リソースマネジャによりステップＳ３１３でAS（M以降）が配置転換された後、クライアント１３からAS（M-1）の要求があると、ステップＳ３３２において、AS（M-1）をクライアント１３に転送する。
クライアント１３のDASHクライアントは、ステップＳ３５１において、サービスまたはコンテンツの選択が行われると、その選択されたサービスまたはコンテンツのMPDをCDNサービスプロバイダ２２Ｂの第１の双方向サーバに要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２Ｂの第１の双方向サーバによりステップＳ３２１で転送されたMPDを取得する。
続いて、クライアント１３のDASHクライアントは、ステップＳ３５２において、取得したMPDをパースし、ASを特定して、その特定したASを要求する。なお、パースされたMPDの一例が、図４６に示されている。
その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の第１の双方向サーバによりステップＳ３２２で転送されたASを取得する。そして、クライアント１３のDASHクライアントは、ステップＳ３５３において、取得したASを再生する。
さらに、クライアント１３のDASHクライアントは、ステップＳ３５４において、AS後続セグメント（N-1）をCDNサービスプロバイダ２２Ｂの第１の双方向サーバに要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の第１の双方向サーバによりステップＳ３２３で転送されたAS（N-1）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ３５５において、取得したAS（N-1）を再生する。
そして、クライアント１３のDASHクライアントは、ステップＳ３５６において、In-band Eventを検出し、MPDを再構成する。なお、検出されたIn-band Event、および、再構成されたMPDの一例が、図４７に示されている。ここで、図４７に示すように、再構成されたMPDに、/BaseURL='No.2'と記述されていることより、CDNサービスプロバイダ２２Ｂの第２の双方向サーバからの取得も可能となる。
従って、クライアント１３のDASHクライアントは、図４５のステップＳ３５７において、MPDをパースし、セグメント（N）を特定して、その特定したAS（N）をCDNサービスプロバイダ２２Ｂの第２の双方向サーバに要求する。そして、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２Ｂの第２の双方向サーバによりステップＳ３３１で転送されたAS（N）を取得し、ステップＳ３５８においてAS（N）を再生する。なお、ステップＳ３５７でパースされたMPDの一例が、図４８に示されている。
また、クライアント１３のDASHクライアントは、ステップＳ３５９において、AS後続セグメント（M-1）をCDNサービスプロバイダ２２Ｂの第２の双方向サーバに要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の第２の双方向サーバによりステップＳ３３２で転送されたAS（M-1）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ３６０において、取得したAS（N-1）を再生する。
さらに、クライアント１３のDASHクライアントは、ステップＳ３６１において、In-band Eventを検出し、MPDを再構成し、ステップＳ３６２において、MPDをパースし、セグメント（M）を特定して、その特定したAS（M）をCDNサービスプロバイダ２２の第１の双方向サーバに要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の第１の双方向サーバによりステップＳ３２４で転送されたAS（M）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ３６３において、取得したAS（M）を再生する。
なお、検出されたIn-band Event、および、再構成されたMPDの一例が、図４９に示されている。ここで、図４９に示すように、再構成されたMPDに、/BaseURL='No.1のみが記述されていることより、CDNサービスプロバイダ２２Ｂの第１の双方向サーバからしか取得することができないようになっている。
以上のように、コンテンツ提供システム１１Ｂでは、例えば、図３７および図３８のコンテンツ配信処理よりもシンプルに、コンテンツ配信処理を行うことができる。
＜MPD拡張のバリエーション＞
図５０および図５１を参照して、MPD拡張のバリエーションについて説明する。
例えば、図５１に示すように、各AdaptationSet要素の配下に、SupplementalProperty要素を配置できるようにし、SupplementalProperty @schemeIdUri属性値を" urn:mpeg:dash:event:distributionPolicy"とし、value属性値として、"(tag=値),(policyDescription=値),(level=値),(attributeToBeAppended=値), (attributeToBeAppended=値), ..."のように記述できるようにする。
この意味するところは、当該AdaptationSetは、tag値で示されるDistributionPolicyのlevel（level値で示される）に属しており、そのDistributionPolicyのPolicyDescriptionがpolicyDescription値であり、このDistributionPolicy.level （maxLevelToBeApplied）が適用された暁には、複数のattributeToBeAppended値に示される追加が当該AdaptationSet要素に反映されることを示す。各々のattributeToBeAppendedには、例えば、<!CDATA[<BaseURL>/bc</BaseURL>]]>のように適当な記載方法で追加されるべき要素を記載する。
また、図５１には、図５０に示したMPDの記述と等価な表現が示されている。
＜DASH-SANDの拡張＞
図５２乃至図６０を参照して、DASH-SANDの拡張について説明する。
上述の図２７を参照して説明したようにMPD内に定義されたDistributionPolicyに対して、どのレベルを適用してMPDを再構成するかを示すために、DASH Eventを利用することができる。この他、例えば、クライアント側またはサーバ側でMPDを再構成することができるように、DASH-SANDを利用してDistributionPollicyとそのlevelを通知することができる。
例えば、SANDにおいては、図５２および図５３に示すように、DANE（DASH Aware Network Element）と呼ばれるDASHプロトコルを理解してDASHストリーミングを最適化する機能を持つネットワークコンポーネント/サーバと、それらとDASHクライアントがやりとりするメッセージングインターフェイスが定義されている。
また、図５３に示すように、DANE間でやりとりされるメッセージであるPEDについては、現行のDASH-SANDにはインタフェースの界面（PED: Parameter Enhancing Distribution）が存在することのみが定義されていて、具体的なメッセージはまだ定義されていない。
さらに、DASHクライアントが利用するMPDとメディアセグメントはWebサーバによりHTTPを介して提供されるが、図５４に示すように、SANDのメッセージについては、そのHTTPトランザクションとは別のパスでやり取りされる。
例えば、図５５は、DASHクライアントにおける処理の流れを示しているが、MPDとメディアセグメントは、ストリーミングの再生そのものに利用される一方、SANDは、DASHストリーミングの最適化という用途に利用される。
ここで、図５６に示すように、コンテンツプロバイダが提供する（上流側）DANEと、サービスプロバイダが提供する（下流側）DANEを想定する。なお、それぞれのコンテンツプロバイダ内もしくはサービスプロバイダ内におけるDANEは複数で構成される場合もある。
例えば、DANE間のPEDメッセージ、もしくは、DANEからDASHクライアントへのPERメッセージとして、MPDUpdateDirectiveメッセージを導入する。
MPDUpdateDirectiveメッセージは、修正対象のMPDに対してその中身の更新方法を記述する要素を持つメッセージである。MPDUpdateDirectiveメッセージのルート要素であるMPDUpdateDirective要素は、オプショナルな属性としてmpdUriReferenceを持ち、対象のMPDインスタンスのURIを指定できるようにする。その子要素に、複数のDistributionPolicyChange要素を持ち、DistributionPolicyChange要素は、その属性としてオプショナルなPolicyReference属性を持ち、対象のDistributionPolicyのtag値を指定できるようにする。さらに、オプショナルなDistiributionPolicy要素（先に説明したMPD/Period/DistributionPolicy要素そのもの）と、LevelChange要素を持つ。LevelChange要素は、更新するlevel値を属性として格納できるようにする。
そして、SANDのMPDUpdateDirectiveメッセージは、例えば、図５７に示す例のようなHTTP-POSTにて転送される。
図５８には、MPDUpdateDirectiveフラグメントのインスタンスの第１の記述例が示されている。例えば、MPDがDistributionPolicy要素を含まないとき、このMPDを再構成する場合に適用するDistributionPolicyとレベルを、図５８に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
図５９には、MPDUpdateDirectiveフラグメントのインスタンスの第２の記述例が示されている。例えば、MPDがDistributionPolicy要素を含まないとき、このMPDを再構成する場合に適用する２つのDistributionPolicyとそれぞれのレベルを、図５９に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
図６０には、MPDUpdateDirectiveフラグメントのインスタンスの第３の記述例が示されている。例えば、MPDが１つのDistributionPolicy要素を含むとき、このMPDを再構成する場合に適用するDistributionPolicyとレベルを、図６０に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
図６１には、MPDUpdateDirectiveフラグメントのインスタンスの第４の記述例が示されている。例えば、MPDが2つのDistributionPolicy要素を含むとき、このMPDを再構成する場合に適用するそれぞれのDistributionPolicyとレベルを、図６１に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
なお、すべてのSANDメッセージには、SANDメッセージインスタンスを識別するmessageIdが属性として付与されるため、MPDUpdateDirective要素の属性としてmessageIdが追加される。
＜コンテンツ配信処理＞
図６２乃至図６９を参照して、SAND-PEDとして転送されるMPDUpdateDirectiveを用いたコンテンツ配信処理の一例について説明する。
図６２のステップＳ４０１において、コンテンツプロバイダ２１は、MPDおよびASを生成し、CDNサービスプロバイダ２２Ｂに転送する。
図３８のステップＳ４１１において、CDNサービスプロバイダ２２のリソースマネジャ上流側DANEは、放送または双方向配信のリソースを割り当て、DistributionPolicy付きのMPDおよびASを双方向サーバおよび放送サーバに配置して、それらを転送させる。ステップＳ４１２において、CDNサービスプロバイダ２２のリソースマネジャ上流側DANEは、放送または双方向配信のリソースを割り当て、MPDUpdateDirectiveのSAND-PEDを通知し、AS（N以降）を双方向サーバに配置転換して、それらを転送させる。
同様に、図６３のステップＳ４１３において、CDNサービスプロバイダ２２のリソースマネジャ上流側DANEは、放送または双方向配信のリソースを割り当て、MPDUpdateDirectiveのSAND-PEDを通知し、AS（M以降）を双方向サーバに配置転換して、それらを転送させる。
CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりステップＳ４１１でDistributionPolicy付きのMPDおよびASが配置された後、クライアント１３からMPDの要求があると、図６２のステップＳ４２１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からASの要求があると、ステップＳ４２２において、ASをクライアント１３に転送する。また、CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりステップＳ４１２でAS（N以降）が配置転換された後、クライアント１３からMPDUpdateDirective SAND-PEDの要求があると、ステップＳ４２３において、MPDUpdateDirective SAND-PEDをクライアント１３に転送する。なお、MPDUpdateDirectiveの一例が、図６５に示されている。そして、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からASの要求があると、ステップＳ４２４において、AS（N-1）をクライアント１３に転送する。
同様に、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からAS（N）の要求があると、ステップＳ４２５において、AS（N）をクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりAS（M以降）が配置転換された後、クライアント１３からMPDUpdateDirectiveの要求があると、ステップＳ４２６において、MPDUpdateDirectiveをクライアント１３に転送する。なお、転送されるMPDUpdateDirectiveの一例が、図６８に示されている。
さらに、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からAS後続セグメント（M-1）の要求があると、ステップＳ４２７において、AS（M-1）をクライアント１３に転送する。そして、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からAS後続セグメント（M）の要求があると、ステップＳ４２８において、AS（M）をクライアント１３に転送する。
CDNサービスプロバイダ２２の放送サーバは、リソースマネジャによりステップＳ４１１でDistributionPolicy付きのMPDおよびASが配置された後、図６２のステップＳ４３１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、ステップＳ４３２において、AS（N）をクライアント１３に転送し、ステップＳ４４３において、AS（M-1）クライアント１３に転送する。
クライアント１３のローカルプロキシサーバ下流側DANEは、CDNサービスプロバイダ２２の放送サーバからステップＳ４３１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバ下流側DANEは、DASHクライアントによるMPDの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４１において、放送サーバから取得したMPD、および、双方向サーバから取得したMPDのどちらか一方のMPDをDASHクライアントに転送する。
また、クライアント１３のローカルプロキシサーバ下流側DANEは、DASHクライアントによるASの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２２で転送されてくるASを取得する。そして、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４２において、ASをDASHクライアントに転送する。
クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４３において、MPDUpdateDirective SAND-PEDをCDNサービスプロバイダ２２に要求し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２３で転送されてくるMPDUpdateDirective SAND-PEDを取得する。また、クライアント１３のローカルプロキシサーバ下流側DANEは、DASHクライアントによるAS後続セグメント（N-1）の要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２４で転送されてくるAS（N-1）を取得する。
そして、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４４において、MPDを再構成し、MPDUpdateEventをセグメントへ挿入する。なお、再構成されたMPDの一例が、図６６に示されている。クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４５において、AS（N-1）をDASHクライアントに転送する。その後、クライアント１３のローカルプロキシサーバ下流側DANEは、DASHクライアントからMPDが要求されると、ステップＳ４６６において、ステップＳ４４４で再構成した後のMPDをDASHクライアントに転送する。
以下、同様に、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４７において、AS（N）をDASHクライアントに転送し、ステップＳ４４８において、MPDUpdateDirectiveをCDNサービスプロバイダ２２に要求する。さらに、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４９において、MPDを再構成し、MPDUpdateEventをセグメントへ挿入し、ステップＳ４５０において、AS（M-1）をDASHクライアントに転送する。なお、再構成されたMPDの一例が、図６９に示されている。
そして、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４５１において、ステップＳ４４９で再構成した後のMPDをDASHクライアントに転送し、ステップＳ４５２において、AS（M）をDASHクライアントに転送する。
クライアント１３のDASHクライアントは、ステップＳ４６１において、サービスまたはコンテンツの選択が行われると、その選択されたサービスまたはコンテンツのMPDを要求する。その後、クライアント１３のDASHクライアントは、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ４４１で転送されたMPDを取得する。
続いて、クライアント１３のDASHクライアントは、ステップＳ４６２において、取得したMPDをパースし、ASを特定して、その特定したASを要求する。なお、パースされたMPDの一例が、図６４に示されている。
その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２２で転送されたAS、および、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ４４２で転送されたASを取得する。そして、クライアント１３のDASHクライアントは、ステップＳ４６３において、取得したASを再生する。
さらに、クライアント１３のDASHクライアントは、ステップＳ４６４において、AS後続セグメント（N-1）を要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２４で転送されたAS（N-1）、即ち、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ４４５で転送されたAS（N-1）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ４６５において、取得したAS（N-1）を再生する。
そして、クライアント１３のDASHクライアントは、ステップＳ４６６において、In-band Eventを検出し、MPDを要求する。そして、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ４４６で転送されてくるMPDを取得する。
以下、同様に、クライアント１３のDASHクライアントは、図６３のステップＳ４６７において、MPDをパースし、セグメント（N）を特定して、その特定したAS（N）を要求し、ステップＳ４６８においてAS（N）を再生する。なお、ステップＳ４６７でパースされたMPDの一例が、図６７に示されている。
また、同様に、クライアント１３のDASHクライアントは、ステップＳ４６９において、AS後続セグメント（M-1）を要求し、ステップＳ４７０においてAS（M-1）を再生する。さらに、同様に、クライアント１３のDASHクライアントは、ステップＳ４７１において、In-band Eventを検出し、MPDを要求する。そして、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ４５１で転送されてくるMPDを取得する。クライアント１３のDASHクライアントは、ステップＳ４７１において、In-band Eventを検出して、MPDを要求し、ステップＳ４７２において、MPDをパースし、セグメント（M）を特定して、その特定したセグメント（M）を要求し、ステップＳ４７３において、AS（M）を再生する。なお、再構成されたMPDの一例が、図６９に示されている。
以上のように、サービスプロバイダ（もしくは、サービスプロバイダ内のCDNセグメントマネジャ）が放送/双方向トランスポートリソースの割り当てを担う場合で、リソースマネジャにおいてMPDは書き換えずに、SAND-PEDとして転送されるMPDUpdateDirectiveにより、トランスポートリソースの割り当てをクライアント側に通知し、クライアント側でMPDを再構成することができる。
＜放送系のシグナリング拡張＞
図７０乃至図７４を参照して、放送系のシグナリング拡張について説明する。
上述の図２７を参照して説明したように、MPD内に定義されたDistributionPolicyに対して、どのレベルを適用してMPDを再構成するかを示すために、DASH Eventを利用することができる。これに対し、例えば、DASH Eventを利用しないで、クライアント側でのMPDの再構成を促す方法を別途定義することができる。
例えば、ATSCや3GPP-MBMS放送環境において、DASH Eventを利用せずに、上述のような機能を実現するために、それぞれのサービスレイヤーシグナリングプロトコルを拡張して、DistributionPollicyとそのlevelを通知できるようにする。
即ち、図７０に示すように、ATSC3.0では、サービルレイヤーシグナリング(SLS:Service Layer Signaling)のシグナリングフラグメント(XML)により、クライアントに対して、そのシグナリングが配送された時点で有効なMPDを伝えることができる。そして、ここでは、新たなシグナリングフラグメントとしてMPDUpdateDirectiveフラグメントを導入する。
例えば、MPDUpdateDirectiveフラグメントは、その時点で有効なMPDに対してその中身の更新方法を記述する要素である。MPDUpdateDirectiveフラグメントのルート要素であるMPDUpdateDirective要素は、オプショナルな属性としてmpdUriReferenceを持ち、対象のMPDインスタンスのURIを指定できるようにする。その子要素に、複数のDistributionPolicyChange要素を持ち、DistributionPolicyChange要素は、その属性としてオプショナルなPolicyReference属性を持ち、対象のDistributionPolicyのtag値を指定できるようにする。さらに、オプショナルなDistiributionPolicy要素（先に説明したMPD/Period/DistributionPolicy要素そのもの）と、LevelChange要素を持つ。LevelChange要素は、更新するlevel値を属性として格納できるようにする。
図７１には、MPDUpdateDirectiveフラグメントのインスタンスの第１の記述例が示されている。例えば、MPDがDistributionPolicy要素を含まないとき、このMPDを再構成する場合に適用するDistributionPolicyとレベルを、図７１に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
図７２には、MPDUpdateDirectiveフラグメントのインスタンスの第２の記述例が示されている。例えば、MPDがDistributionPolicy要素を含まないとき、このMPDを再構成する場合に適用する２つのDistributionPolicyとそれぞれのレベルを、図７２に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
図７３には、MPDUpdateDirectiveフラグメントのインスタンスの第３の記述例が示されている。例えば、MPDが１つのDistributionPolicy要素を含むとき、このMPDを再構成する場合に適用するDistributionPolicyとレベルを、図７３に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
図７４には、MPDUpdateDirectiveフラグメントのインスタンスの第４の記述例が示されている。例えば、MPDが2つのDistributionPolicy要素を含むとき、このMPDを再構成する場合に適用するそれぞれのDistributionPolicyとレベルを、図７４に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
＜コンテンツ配信処理＞
図７５乃至図８０を参照して、ATSC3.0や3GPP-MBMSのシグナリングフラグメントとして転送されるMPDUpdateDirectiveを用いたコンテンツ配信処理の一例について説明する。
ステップＳ５０１において、コンテンツプロバイダ２１は、MPDおよびASを生成し、CDNサービスプロバイダ２２に転送する。
CDNサービスプロバイダ２２のリソースマネジャは、コンテンツプロバイダ２１によりステップＳ５０１で転送されてくるMPDおよびASを受信する。そして、CDNサービスプロバイダ２２のリソースマネジャは、ステップＳ５１１において、放送または双方向配信のリソースを割り当て、MPDを書き換え、MPDおよびASを双方向サーバおよび放送サーバそれぞれに配置して、それらを転送させる。ステップＳ５１２において、CDNサービスプロバイダ２２のリソースマネジャは、放送または双方向配信のリソースを割り当て、MPDUpdateDirectiveをシグナリング放送し、AS（N以降）を双方向サーバおよび放送サーバそれぞれに配置転換して、それらを転送させる。なお、MPDUpdateDirectiveの一例が、図６５に示されている。
同様に、図７６のステップＳ５１３において、CDNサービスプロバイダ２２のリソースマネジャは、放送または双方向配信のリソースを割り当て、MPDUpdateDirectiveをシグナリング放送し、AS（M以降）を双方向サーバおよび放送サーバそれぞれに配置転換して、それらを転送させる。なお、MPDUpdateDirectiveの一例が、図６８に示されている。
CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりステップＳ５１１でDistributionPolicy付きのMPDおよびASが配置された後、クライアント１３からMPDの要求があると、図７５のステップＳ５２１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からASの要求があると、ステップＳ５２２において、ASをクライアント１３に転送する。また、CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりステップＳ５１２でAS（N以降）が配置転換された後、クライアント１３からASの要求があると、ステップＳ５２３において、AS（N-1）をクライアント１３に転送する。
同様に、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からASの要求があると、図７６のステップＳ５２４において、AS（N）をクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりAS（M以降）が配置転換された後、クライアント１３からAS（M-1）の要求があると、ステップＳ５２５において、AS（M-1）をクライアント１３に転送する。さらに、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からAS（M）の要求があると、ステップＳ５２６において、AS（M）をクライアント１３に転送する。
CDNサービスプロバイダ２２の放送サーバは、リソースマネジャによりステップＳ５１１でDistributionPolicy付きのMPDおよびASが配置された後、図７５のステップＳ５３１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の放送サーバは、リソースマネジャによりステップＳ５１２で生成されたMPDUpdateDirectiveを取得して、ステップＳ５３２においてMPDUpdateDirectiveをクライアント１３に転送する。
その後、CDNサービスプロバイダ２２の放送サーバは、図７６のステップＳ５３３においてAS（N）をDASHクライアントに転送する。また、CDNサービスプロバイダ２２のリソースマネジャによりステップＳ５１３で生成されたMPDUpdateDirectiveを取得し、配置転換されたAS（M以降）を取得して、ステップＳ５３４においてMPDUpdateDirectiveおよびAS（M-1）をクライアント１３に転送する。そして、CDNサービスプロバイダ２２の放送サーバは、ステップＳ５３５においてAS（N）をDASHクライアントに転送する。
クライアント１３のローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ５３１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバは、DASHクライアントによるMPDの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ５４１において、放送サーバから取得したMPD、および、双方向サーバから取得したMPDのどちらか一方のMPDをDASHクライアントに転送する。
また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるASの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２２で転送されてくるASを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ５４２において、ASをDASHクライアントに転送する。
その後、クライアント１３のローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ５３２で転送されてくるMPDUpdateDirectiveを取得する。また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるAS（N-1）の要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２３で転送されてくるASを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ５４３において、MPDを再構成し、MPDUpdateEventをセグメントへ挿入する。なお、再構成されたMPDの一例が、図７８に示されている。
また、クライアント１３のローカルプロキシサーバは、ステップＳ５４４において、AS（N-1）をDASHクライアントに転送する。その後、クライアント１３のローカルプロキシサーバは、DASHクライアントからMPDが要求されると、ステップＳ５４５において、ステップＳ５４３で再構成した後のMPDをDASHクライアントに転送する。
さらに、クライアント１３のローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ５３３で転送されてくるAS（N）を取得する。そして、クライアント１３のローカルプロキシサーバは、DASHクライアントによるセグメント（N）の要求を受け、もし対象のセグメントが放送サーバから届いていなければ、CDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２４で転送されてくるAS（N）を取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ５４６において、AS（N）をDASHクライアントに転送する。
その後、クライアント１３のローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ５３４で転送されてくるMPDUpdateDirectiveおよびAS（M-1）を取得する。そして、クライアント１３のローカルプロキシサーバは、DASHクライアントによるAS後続セグメント（M-1）の要求を受け、もし対象のセグメントが放送サーバから届いていなければ、CDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２５で転送されてくるAS（M-1）を取得する。
そして、クライアント１３のローカルプロキシサーバは、ステップＳ５４７において、MPDを再構成し、MPDUpdateEventをセグメントへ挿入する。なお、再構成されたMPDの一例が、図８０に示されている。クライアント１３のローカルプロキシサーバは、ステップＳ５４８において、AS（N-1）をDASHクライアントに転送する。その後、クライアント１３のローカルプロキシサーバは、DASHクライアントからMPDが要求されると、ステップＳ５４９において、ステップＳ５４７で再構成した後のMPDをDASHクライアントに転送する。
その後、クライアント１３のローカルプロキシサーバは、DASHクライアントによるAS（M）の要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２６で転送されてくるAS（M）を取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ５５０において、AS（M）をDASHクライアントに転送する。
クライアント１３のDASHクライアントは、ステップＳ５６１において、サービスまたはコンテンツの選択が行われると、その選択されたサービスまたはコンテンツのMPDを要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２１で転送されたMPD、CDNサービスプロバイダ２２の放送サーバによりステップＳ５３１で転送されたMPDのうち、クライアント１３のローカルプロキシサーバによりステップＳ５４１で転送されたいずれか一方のMPDを取得する。
続いて、クライアント１３のDASHクライアントは、ステップＳ５６２において、取得したMPDをパースし、ASを特定して、その特定したASを要求する。なお、パースされたMPDの一例が、図７７に示されている。
その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２２で転送されたAS、即ち、クライアント１３のローカルプロキシサーバによりステップＳ５４２で転送されたASを取得する。そして、クライアント１３のDASHクライアントは、ステップＳ５６３において、取得したASを再生する。
さらに、クライアント１３のDASHクライアントは、ステップＳ５６４において、AS後続セグメント（N-1）を要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２３で転送されたAS（N-1）、即ち、クライアント１３のローカルプロキシサーバによりステップＳ５４４で転送されたAS（N-1）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ５６５において、取得したAS（N-1）を再生する。
そして、クライアント１３のDASHクライアントは、ステップＳ５６６において、In-band Event（MPDUpdate）を検出し、MPDを要求する。そして、クライアント１３のローカルプロキシサーバによりステップＳ５４５で転送されてくるMPDを取得する。
以下、同様に、クライアント１３のDASHクライアントは、ステップＳ５６７において、MPDをパースし、セグメント（N）を特定して、その特定したAS（N）を要求し、ステップＳ５６８においてAS（N）を再生する。なお、ステップＳ５６７でパースされたMPDの一例が、図７９に示されている。
また、同様に、クライアント１３のDASHクライアントは、ステップＳ５６９において、AS後続セグメント（M-1）を要求し、ステップＳ５７０においてAS（M-1）を再生する。さらに、同様に、クライアント１３のDASHクライアントは、ステップＳ５７１において、In-band Event（MPDUpdate）を検出して、MPDを要求する。そして、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ５４９で転送されてくるMPDを取得する。クライアント１３のDASHクライアントは、ステップＳ５７１において、In-band Eventを検出し、MPDを要求し、ステップＳ５７２において、MPDをパースし、AS（M）を特定して、その特定したAS（M）を要求し、ステップＳ５７３において、AS（M）を再生する。なお、再構成されたMPDの一例が、図８０に示されている。
以上のように、サービスプロバイダ（もしくは、サービスプロバイダ内のCDNセグメントマネジャ）が放送/双方向トランスポートリソースの割り当てを担う場合で、リソースマネジャにおいてMPDは書き換えずに、ATSC3.0や3GPP-MBMSのシグナリングフラグメントとして転送されるMPDUpdateDirectiveにより、トランスポートリソースの割り当てをクライアント側に通知し、クライアント側でMPDを再構成することができる。
＜ResourceSpecificInformationのその他の例＞
図８１乃至図８３を参照して、ResourceSpecificInformationのその他の例について説明する。
例えば、DistributionPolicyのPolicyDescriptionは、とあるLevelに属するAdaptationSet群に対するさまざまな内容が記述できる。上述の例の他、当該ストリームを転送するのに必要となるトランスポート特性の制約をもとに定義することもできる。トランスポート特性の制約とは、当該ストリーム(放送)を取得する際に要求されるネットワーク要求品質条件を示す。例としては、遅延、遅延揺らぎ、損失(エラー)、スループット等がある。
このうち、遅延を制約記述に用いる場合には、例えば、図８１に示すように、DistributionPolicy.PolicyDescription='遅延制約の高いものを放送へ'のように記載する。さらに、各Levelに対する具体的な制約値を格納できるように、各Level要素のResourceSpecificInformationの部分に、<Level LatencyLimit='100msec' … />のように記述できるようにする。
ここで、Latencyの定義は、例えば、DASHプレイヤがセグメントリクエストを発行してから対象セグメントの先頭バイトを取得するまでの遅延等のように定義しておく。例えば、遅延以外にも、遅延ゆらぎ（ジッタ）、エラーレート等が考えられるが、それぞれのパラメタに対応する記述規則（属性名）とその詳細な意味/定義は別途定義するものとする。
このように、ResourceSpecificInformationを用いるMPDは、図８２に示すように記述される。図８２に示すように、上述したようなDistributionMediaDependant Extension/ElementToBeAppendedに加え、さらにDistributionMediaDependant Extension/ElementToBeRemovedが記述されている。これは、maxLevelToBeAppliedで指定される当該Levelまでに含まれるAdaptationSet要素から削除すべき要素を示す。
そして、生成されるべき有効なMPDは、図８３に示すように記述される。即ち、図８３に示すように、AS@id=１、２のASからBaseURL=/bcが削除されて、BaseURL=/netが追加される。
図８３に示すMPDが配信されるクライアントデバイスが受信することのできる双方向トランスポートが最大遅延50msec以下を提供することできて、そこにはLevel[2]まで(Lavel[1]とLevel[2])のAdaptationSet群が転送されることを示している。一方、そのデバイスが受信することのできる放送トランスポートが最大遅延10msec以下を提供することができて、そこにはLevel[3]のAdaptationSet群が転送される。
＜ATSC3.0クライアント実装モデル＞
図８４には、ATSC3.0のクライアントの実装モデルとして想定される構成例を示すブロック図が示されている。
図８４に示すように、ATSC3.0クライアントアプリケーション("3.0 DASH Client")は、ATSC3.0チューナー(PHY/MAC)を有するATSC3.0放送受信クライアントデバイス("3.0 Client (with ATSC3.0 PHY/MAC)")上に実装されたブラウザ上で実行される(ブラウザアプリケーションとしてだけではなくネイティブアプリケーションとして実行される場合もある)。
また、ATSC3.0クライアントアプリケーションは、クライアント上に実装されたクライアントローカルHTTPプロキシーサーバ("Client Local HTTP Proxy Server")を介して、放送系受信スタックが実装されたクライアントローカルATSCミドルウエア("Client Local ATSC Middleware")が受信した、もしくは、ネット系送受信処理を行う通常のネットワークスタックを介して取得した、DASH-MPDファイルやDASH segmentファイル、ならびに、SLS(Service level Signaling)ファイルにより、ストリームのレンダリングや、アプリケーションの制御を行う。
そして、ATSC3.0 DASHクライアントアプリケーションは、また、LAN等を介してATSC3.0放送受信クライアントデバイスにアクセス可能な他のデバイス上に実装されたブラウザ上(もしくはネイティブアプリケーションとして)でも実行可能であり、そのアプリケーションも、ATSC3.0放送受信クライアントデバイス上のクライアントローカルHTTPプロキシーサーバを介して、クライアントローカルATSCミドルウエアが受信した、もしくは、通常のネットワークスタックを介して取得した、DASH-MPDファイルやDASH segmentファイル、ならびに、SLS(Service level Signaling)ファイルを取得して、ストリームのレンダリングや、アプリケーションの制御を行う。
例えば、このモデルは、アプリケーションからすると、必ずクライアントローカルHTTPプロキシーサーバを介して外の世界にアクセスするため、それらファイル群を放送経由で取得しているのか、ネット経由で取得しているのかの区別を意識することがない(ネットワーク透過性が提供される)ため、アプリケーションの可搬性を高めることが可能となる(放送向けのみに特化して実装する必要がなく、放送もインターネットのどちらを使うかによらない実装にすることができる)。
そして、ATSC3.0 DASHクライアントアプリケーションが上記ファイル群の取得を要求すると(HTTPリクエスト)、それを受けたクライアントローカルHTTPプロキシーサーバが、"Broadcast/Broadband Address Resolover"において放送受信スタックを介して取得するか、ネット経由で取得するかの判断を行う。
ここで、判断の材料となる情報は、"SLS Signaling Parser"から提供される。"SLS Signaling Parser"は、"SLS Signaling Retriever"に、ATSC3.0のシグナリングメタであるUSBD/USDやS-TSID等の取得要求を行う。"SLS Signaling Retriever"は、ATSCチューナー"ATSC3.0 PHY/MAC"を介して放送受信するSLS LCTパケットにより運ばれるシグナリングメタを抽出する。"SLS Signaling Parser"は、また、セグメントの取得要求に含まれるurlから、シグナリングメタを引いて、対象となるファイルを取得するための放送配信アドレス情報を解決する。
そして、放送配信される、または、放送されたことがわかれば、その放送配信アドレス情報をもとにして、所望のファイルが格納されたsegment LCTパケットを放送ストリームから取得し、"Proxy Cache"内に展開する。クライアントローカルHTTPプロキシーサーバは、当該ファイルをアプリケーションに(HTTPのレスポンスとして)返す。
これにより、要求されたセグメントファイルのurlがシグナリングメタになければ、クライアントローカルHTTPプロキシーサーバは、通常のネットスタックを介してセグメントファイルを取得する。
また、図８５には、ATSC3.0プロトコルスタックが示されており、図８６には、ROUTE/DASHベースのスタックが示されている。
＜コンテンツ配信方法における第２の配信方法＞
以下では、本技術を適用したコンテンツ配信方法の第２の配信方法について説明する。
上述したコンテンツ配信方法（第１の配信方法）では、複数のトランスポートメディアを保有するサービスプロバイダを介してコンテンツを配信する際に、分配ポリシーを参考して、ユニキャスト優先およびブロードキャスト優先のどちらかが選択される。これに対し、コンテンツ配信方法の第２の配信方法では、この分配ポリシーと同様に用いられるメタデータに、セグメントを先行取得する際に参照する情報（優先度）を定義することで、より遅延を削減してコンテンツの配信を行うことを想定している。
例えば、コンテンツ配信方法の第２の配信方法は、スポーツなどのイベントの中継、または、全天球（360°VR）コンテンツなどの配信において、複数の視点の映像を提供するときに採用することができる。このような複数の視点の映像を提供する提供方法としては、例えば、完全に異なる複数の位置に配置されたカメラからの映像ストリームを、１つのコンテンツとして提供する方法がある。さらに、全天球コンテンツにおいて、ユーザの視線方向（Viewportと呼ばれる）ごとの個別の映像ストリームを提供する方法や、これらの方法を組み合わせて用いる方法などがある。
また、複数の視点の映像を提供する際に、それらの映像に対して、クライアントが、視聴コンテンツを選択するための各種の（客観的な）メタデータを提供することがある。一方、全天球映像におけるROI（Region of Interest）などのように、制作者の意図（Director's Cut）に基づいて推奨される視点を提供することも想定されている。
これに対し、コンテンツ配信方法の第２の配信方法では、セグメントのデータ配信における遅延を削減することによるユーザ体験の向上を図るために、セグメントを先行取得する際に参照する情報（優先度）が、メタデータにより提供される。例えば、比較的に多くの視聴者が選択することが想定される視点や、視聴者が観る可能性の高いROIのアングルビューなどが、高い優先度となるような割り当てなどが行われる。なお、このメタデータは、従来のクライアントによるユーザ意図や、HMDを装着した視聴者の動きなどを含むインタラクションなどに基づいて視聴ストリームを選択するために用いられるのとは異なるものである。
また、メタデータのソース（メタデータを生成した生成元や、メタデータを提供する提供元、メタデータを付加した主体の種別）としては、コンテンツ提供者、ネットワーク、または、その他が想定される。コンテンツ提供者が提供するメタデータとして、コンテンツを制作した製作者の意図として予測される人気度を用いることが想定される。また、ネットワークにより提供されるメタデータとして、実際に過去にコンテンツを配信したときに測定される、ユーザによる選択の割合を表す実測値（実測された統計に基づく値）を用いることが想定される。また、コンテンツ提供者およびネットワークの他によりメタデータが提供されることも想定される。このように、複数のソースから、メタデータが同時に提供されることが想定されるだけでなく、各々のメタデータが時間的に変化することも考えられる。
そこで、このように、複数のソースから提供され、時間的に変化するようなメタデータを、MPEG DASHのMPDに効率良く記述することが必要とされる。
図８７を参照して、優先度を示すメタデータを参照して、セグメントを先行取得するようなコンテンツ提供システムの概要について説明する。
図８７に示すコンテンツ提供システム１１は、コンテンツプロバイダ２１（オリジン・サーバ）から配信されるコンテンツが、配信サーバ５１によって、放送ネットワーク１４および双方向ネットワーク１５の間で配信リソースの分配が制御される。また、双方向ネットワーク１５は、CDN中間サーバ５２およびCDNエッジサーバ５３により構築され、配信サーバ５１から送信されるコンテンツは、例えば、CDN中間サーバ５２を経由して、CDNエッジサーバ５３により、コンテンツの提供を受けるクライアント１３へ配信される。
また、コンテンツプロバイダ２１から配信されるコンテンツには、セグメントごとに優先度を示すメタデータを付加することができ、例えば、人気度が高い視点のセグメントには高い優先度が設定されている。そして、このメタデータを参照して、CDN中間サーバ５２およびCDNエッジサーバ５３が、優先度が高いセグメントを優先的に先行取得（pre-fetch）したり、クライアント１３が、優先度が高いセグメントを優先的に先行取得したりすることができる。
なお、放送ネットワーク１４を介したブロードキャストまたはマルチキャストと、双方向ネットワーク１５を介したユニキャストとが併用可能である場合、優先度が高いセグメントを、優先的にブロードキャストまたはマルチキャストに割り当てて配信してもよい。
ここで、上述したようにクライアント１３におけるユーザ意図やインタラクションによってストリームを選択する場合には、例えば、ファイルフォーマットレベルの情報を用いることができる。これに対し、配信サーバ５１により配信リソースの配分を最適化するためには、MPEG DASHのMPDレベルでのシグナリングが望ましい。同様に、双方向ネットワーク１５上の配信経路の途中にあるCDN中間サーバ５２およびCDNエッジサーバ５３、並びに、クライアント１３によりセグメントを先行取得するためには、MPDレベルでのシグナリングが望ましい。
ところが、MPEG DASHのMPD記述について既に提案されている方式では、複数のソースからメタデータが提供され、かつ、それらのメタデータが時間的に変化すると、その記述が複雑となってしまう。そこで、このようなメタデータを、MPEG DASHのMPDに効率良く記述することが必要となる。
＜セグメントポピュラリティータイムラインのエレメントの定義例＞
まず、セグメントを先行取得する際に参照する情報として用いられる「人気度」を、MPEG DASHのMPDに記述する方法について説明する。例えば、「人気度」は、そのストリームがクライアントで消費される確率の高さに基づいて求めることができる。
図８８に示すように、MPDのアダプテーションセット（AdaptationSet）またはリプレゼンテーション（Representation）に対する子エレメントとして、セグメントポピュラリティータイムライン（SegmentPopularityTimeline）が定義される。
例えば、セグメントポピュラリティータイムラインは、元のセグメント列に対する人気度（Pupularity rate）を規定する。
ソース（@source）は、条件付きの必須で使用され、「人気度」の提供元または種別を表す値として、content、network、およびotherのいずれかが指定される。contentは、「人気度」が、コンテンツ提供者が提供する予測人気度であることを示す。networkは、「人気度」が、過去のユーザの視聴履歴統計に基づく値などのように、配信を行うネットワークにより提供される人気度であることを示す。otherは、「人気度」が、コンテンツ提供者およびネットワークの他により人気度であることを示す。なお、ソースは、あるエレメント（アダプテーションセットまたはリプレゼンテーショ）が２つ以上のセグメントポピュラリティータイムラインのエレメントを持つ場合に必ず指定される。
SPエレメントは、１〜N個記述することができ、人気度（rate）の値を持つ要素である。SPエレメントで指定されるレート（@rate）は、必須で使用され、「人気度」を１〜１００の整数で指定される。例えば、レートは、レベル１が最も人気度が高く、数字が大きいほど人気度が低くなるように設定されている。SPエレメントで指定されるスタート（@start）は、オプションで使用され、そのSPエレメントのレートの値が適用される一連のセグメントのうちの、最初のセグメントのセグメント番号が指定される。SPエレメントで指定されるセグメント数（@r）は、オプションで使用され、そのSPエレメントで指定されるレートが適用される一連の後続セグメントの数が指定される。なお、セグメント数には、そのレートが指定される最初のセグメントは含まない。
このように、セグメントポピュラリティータイムラインを規定することで、セグメントを先行取得する際に参照する情報を効率良く記述することができる。
なお、図８８において、SPエレメントで指定されるレートの値は、別途、MPEG DASHのMPDに（Periodレベルで）記述されているDistributionPolicy（例えば、上述の図１２参照）のLevel@index（Levelエレメントのindexアトリビュート）の値に対応させることができる。
図８９には、図８８を参照して説明したセグメントポピュラリティータイムラインのエレメントを使用して、２種類の提供元から提供された「人気度」を記述したMPEG DASHのMPDの例が示されている。
図８９に示す例では、セグメントテンプレート（SegmentTemplate）のポピュラリティータイムラインのSPエレメントで記述されているdurationが180180でt=0から始まる６個のセグメントについて、「人気度」が指定されている。例えば、ソースがコンテンツ提供者（source="content"）であるセグメントポピュラリティータイムラインでは、初めの２個（１番目および２番目）のセグメントのレートの値に５０が指定されている。そして、続く２個（３番目および４番目）のセグメントのレートの値に３０が指定され、さらに続く２個（５番目および６番目）のセグメントのレートの値に１０が指定されている。
また、図８９では、１つのアダプテーションセットに対するセグメントポピュラリティータイムラインの記述例のみが示されている。実際には、ピリオドに複数のアダプテーションセットが記述され、それぞれのアダプテーションセットにセグメントポピュラリティータイムラインのエレメントが記述される。そして、各SPエレメントのレートの値で指定される「人気度」は、ピリオド内の特定の区間における、異なるアダプテーションセット間の相対的な「人気度」を示すものである。従って、CDN中間サーバ５２、CDNエッジサーバ５３、またはクライアント１３は、この情報に基づいて、ピリオド内の特定の区間について、特定のアダプテーションセット内のセグメントを選択して、先行取得することができる。
＜セグメントポピュラリティータイムラインのエレメントの第１のバリエーション＞
図９０および図９１を参照して、セグメントポピュラリティータイムラインのエレメントの第１のバリエーションについて説明する。
上述した図８８に示したセグメントポピュラリティータイムラインのエレメントの定義例では、もともとアダプテーションセットのエレメントのセグメントタイムラインで規定されているセグメント単位で「人気度」を指定している。これに対し、例えば、個々のセグメントの時間（duration）とは独立に「人気度」を指定することができる。
図９０に示すセグメントポピュラリティータイムラインが定義では、ソース（@source）、および、SPエレメントで指定されるレート（@rate）は、図８８の定義と同様であり、その説明は省略する。
SPエレメントで指定されるスタートタイム（@start_time）は、オプションで使用され、そのSPエレメントのレートの値が適用される開始時間（media time）を、そのアダプテーションセットに適用されるタイムスケール（timescale）に基づいて記述する。なお、スタートタイムが省略された場合、適用開始時間は、前のSPエレメントに指定されたエンドタイム、または、ピリオドの開始時間となる。
SPエレメントで指定されるエンドタイム（@end_time）は、オプションで使用され、そのSPエレメントのレートの値が適用される終了時間（media time）を、そのアダプテーションセットに適用されるタイムスケール（timescale）に基づいて記述する。なお、エンドタイムが省略された場合、適用終了時間は、ピリオドの終了時間となる。
図９１には、図９０を参照して説明した第１のバリエーションのセグメントポピュラリティータイムラインのエレメントを使用して、２種類の提供元から提供された「人気度」を記述したMPEG DASHのMPDの例が示されている。
図９１に示す例では、セグメントテンプレートのセグメントタイムライン（SegmentTemplate.SegmentTimeline）のSエレメントで記述されているタイムスケールが90000（タイムスケールは、１秒には90000カウントするという意味）となっている。そして、各セグメントの時間（duration）が、180180（=180180/90000秒）でt=0から始まる６個のセグメントについて、「人気度」が指定されている。
例えば、ソースがコンテンツ提供者（source="content"）であるセグメントポピュラリティータイムラインでは、セグメントの境界に関わらずにｔ＝０〜3.003秒までにおいて、レートの値に５０が指定されている。この例では、スタートタイムが省略されているため、ピリオドの開始時間から適用されている。そして、続くｔ＝6.006秒までの区間において、レートの値に３０が指定され、さらに続くｔ＝12.012秒までの区間において、レートの値に１０が指定されている。
また、ソースがネットワーク（source="network"）であるセグメントポピュラリティータイムラインでは、ｔ＝０〜3.5秒までの区間において、レートの値に１０が指定されている。そして、続くｔ＝3.5〜7.0秒までの区間において、レートの値に５０が指定され、さらに続くｔ＝7.0〜12.012秒までの区間において、レートの値に７０が指定されている。この例では、エンドタイムが省略されているため、ピリオドの終了時間まで適用されている。
＜セグメントポピュラリティータイムラインのエレメントの第２のバリエーション＞
図９２を参照して、セグメントポピュラリティータイムラインのエレメントの第２のバリエーションについて説明する。
例えば、セグメントポピュラリティータイムラインのエレメントは、アダプテーションセットのエレメントの子要素としてではなく、リプレゼンテーションのエレメントの子要素とすることができる。特に、ソースがネットワーク（source="network"）である場合、即ち、過去のユーザが取得したストリームの統計情報に基づく「人気度」を記述する場合、リプレゼンテーション単位で記述することによって、CDNエッジサーバ５３がセグメントを先行取得する際に、より有効に参照することができる。つまり、そのCDNエッジサーバ５３からストリームを取得しているクライアント１３との間の利用可能帯域の傾向を表す統計値が提供される可能性がある。
図９２には、このような第２のバリエーションのセグメントポピュラリティータイムラインのエレメントを使用して、セグメント単位で「人気度」を記述したMPEG DASHのMPDの例が示されている。
なお、図９２に示す例では、ソースがネットワーク（source="network"）であるセグメントポピュラリティータイムラインのみ、リプレゼンテーション単位で、レートの値を指定している。なお、これは、ソースがコンテンツ提供者（source="content"）であるセグメントポピュラリティータイムラインにおいて、リプレゼンテーション単位で、レートの値を指定することを排除するものではない。例えば、制作者の意図によって区間ごとの視聴を推奨したい最低限の品質（図９２に示す@bandwidthの値、すなわちストリームのencoding bitrate）を指定する目的で、リプレゼンテーション単位の優先度を指定することなどが想定される。
また、図９２に示す例では、セグメントテンプレートのセグメントタイムライン（SegmentTemplate.SegmentTimeline）のSエレメントで記述されている時間（duration）が180180でｔ＝０から始まる６個のセグメントについて、「人気度」が指定されている。
例えば、ソースがネットワーク（source="network"）であるセグメントポピュラリティータイムラインでは、初めの２個（１番目および２番目）のセグメントでは、bandwidth="500000"のリプレゼンテーションのレートの値が最も高く指定されている。そして、続く２個（３番目および４番目）のセグメントでは、bandwidth="1000000"のリプレゼンテーションのレートの値が最も高く指定されており、さらに続く２個（５番目および６番目）のセグメントでは、bandwidth="500000"のリプレゼンテーションのレートの値が最も高く指定されている。なお、これらのレートの値で示される「人気度」は、アダプテーションセット内のリプレゼンテーション間の相対的な関係を表すだけでなく、上述したように、他のアダプテーションセットで記述されているセグメントとの間の相対的な関係を表している。
＜セグメントポピュラリティータイムラインのエレメントの第３のバリエーション＞
図９３を参照して、セグメントポピュラリティータイムラインのエレメントの第３のバリエーションについて説明する。
例えば、上述したコンテンツ配信方法の第１の配信方法で定義したディストリビューションポリシー（distributionPolicy）のエレメントにおけるレベル（Level）のエレメントを時間に応じて指定可能とすることができる。図９３には、ディストリビューションポリシーのエレメントの記述例が示されている。
そして、このようなディストリビューションポリシーのエレメントにおけるレベルのエレメントを、図９４に示すように定義するDPレベルタイムラインのエレメントに置き換えることができる。
例えば、DPレベルタイムラインは、時間に応じて変化するディストリビューションポリシーのレベルを記述する。レベルは、１〜N個記述することができ、区間ごとのディストリビューションポリシーのレベルを指定する。レベルで指定されるインデックスASIDs（@index_ASIDs）は、必須で使用され、当該レベルのエレメント区間に適用される優先度（または「人気度」）を表すインデックス値、および、それが適用されるアダプテーションセットＩＤをコンマで区切って列挙する。
レベルで指定されるスタートタイム（@start_time）は、オプションで使用され、そのレベルのエレメントのレートの値が適用される開始時間（media time）を秒単位で記述する。なお、スタートタイムが省略された場合、適用開始時間は、前のレベルのエレメントに指定されたエンドタイム、または、ピリオドの開始時間となる。
レベルで指定されるエンドタイム（@end_time）は、オプションで使用され、そのレベルのエレメントの値が適用される終了時間（media time）を秒単位で記述する。なお、エンドタイムが省略された場合、適用終了時間は、ピリオドの終了時間となる。
図９５には、図９４を参照して説明した第３のバリエーションディストリビューションポリシーの記述例が示されている。
図９５に示す例では、ｔ＝０〜3.003秒まで、AS-1にLevel値（index値）１が指定され、AS-2およびAS-3にLevel値（index値）２が指定され、AS-4にLevel値（index値）３が指定されている。この例では、スタートタイムが省略されているため、ピリオドの開始時間から適用されている。そして、続くｔ＝6.006秒までの区間において、AS-1およびAS-2にLevel値（index値）１が指定され、AS-3にLevel値（index値）２が指定され、AS-4にLevel値（index値）３が指定されている。さらに続くｔ＝12.012秒までの区間ではAS-1にLevel値（index値）１が指定され、AS-2およびAS-4にLevel値（index値）２が指定され、AS-3にLevel値（index値）３が指定されている。
＜セグメントを先行取得する先行取得処理の第１の処理例＞
図９６を参照して、セグメントを先行取得する先行取得処理の第１の処理例について説明する。また、CDN中間サーバ５２、CDNエッジサーバ５３、およびクライアント１３それぞれにおいて先行取得処理が行われ、以下では、これらの何れかを処理主体として説明を行う。
例えば、CDN中間サーバ５２、CDNエッジサーバ５３、およびクライアント１３が、それぞれMPDを取得したときに処理が開始される。ステップＳ６０１において、その処理を行う処理主体は、まず、判断基準となるソースを設定するソースパラメータに、コンテンツ提供者を示す値をセット（$SourceParam$="content"）する。これにより、コンテンツ提供者により提供される情報に基づいた判断が優先的に行われる。
ステップＳ６０２において、処理主体は、少なくとも１つ以上のアダプテーションセットに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのエレメントがあるか否かを判定する。
ステップＳ６０２において、処理主体が、少なくとも１つ以上のアダプテーションセットに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがあると判定した場合、処理はステップＳ６０３に進む。ステップＳ６０３では、図９７を参照して後述するように、アダプテーションセット（およびリプレゼンテーション）のセグメントポピュラリティータイムライン情報に基づいてセグメントを先行取得する先行取得処理（アダプテーションセット）が行われ、その後、処理は終了される。
一方、ステップＳ６０２において、処理主体が、少なくとも１つ以上のアダプテーションセットに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがないと判定した場合、処理はステップＳ６０４に進む。
ステップＳ６０４において、処理主体は、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのエレメントがあるか否かを判定する。
ステップＳ６０４において、処理主体が、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがあると判定した場合、処理はステップＳ６０５に進む。ステップＳ６０５では、図９８を参照して後述するように、リプレゼンテーションのセグメントポピュラリティータイムライン情報に基づいたセグメントを先行取得する先行取得処理（リプレゼンテーション）が行われ、その後、処理は終了される。
一方、ステップＳ６０４において、処理主体が、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがないと判定した場合、処理はステップＳ６０６に進む。
ステップＳ６０６において、処理主体は、ソースパラメータに、コンテンツ提供者を示す値がセットされているか否かを判定する。
ステップＳ６０６において、処理主体が、ソースパラメータに、コンテンツ提供者を示す値がセットされていると判定した場合、処理はステップＳ６０７に進む。ステップＳ６０７において、処理主体は、ソースパラメータに、ネットワークを示す値をセット（$SourceParam$="network"）する。これにより、ネットワークにより提供される情報に基づいた判断が行われるようになって、その後、処理はステップＳ６０２に戻り、以下、同様の処理が繰り返される。
一方、ステップＳ６０６において、処理主体が、ソースパラメータに、コンテンツ提供者を示す値がセットされていないと判定した場合、処理はステップＳ６０８に進む。
ステップＳ６０８において、処理主体は、ソースパラメータに、ネットワークを示す値がセットされているか否かを判定する。
ステップＳ６０８において、処理主体が、ソースパラメータに、ネットワークを示す値がセットされていると判定した場合、処理はステップＳ６０９に進む。ステップＳ６０９において、処理主体は、ソースパラメータに、その他を示す値をセット（$SourceParam$="other"）する。これにより、その他により提供される情報に基づいた判断が行われるようになって、その後、処理はステップＳ６０２に戻り、以下、同様の処理が繰り返される。
一方、ステップＳ６０８において、処理主体が、ソースパラメータに、ネットワークを示す値がセットされていないと判定した場合、ソースパラメータに、コンテンツ提供者、ネットワーク、および、その他の全てをセットした処理が行われたことになる。従って、処理は終了される。
以上の例では、CDN中間サーバ５２、CDNエッジサーバ５３、およびクライアント１３は、まず、ソースがコンテンツ提供者（source="content"）であるセグメントポピュラリティータイムラインのレートを最優先し、そのような情報が提供がされていない場合、ソースがネットワーク（source="network"）であるセグメントポピュラリティータイムラインのレートを利用する。さらに、それも記述されていない場合に、ソースがその他（source="other"）であるセグメントポピュラリティータイムラインのレート利用した判断を行う。
図９７に示すフローチャートを参照して、図９６のステップＳ６０３で行われる先行取得処理について説明する。なお、この先行取得処理では、次に取得しようとするセグメント、即ち、セグメントのタイムライン上で、取得済みのセグメントに続く時間のセグメントについて、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのレート（SP@rate）の値が最小であるアダプテーションセット内のセグメントを選択するための判定が行われる。
ステップＳ６１１において、処理主体は、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのレート（SP@rate）の値が最小であるアダプテーションセットを選択する。
ステップＳ６１２において、処理主体は、ステップＳ６１１で選択されたアダプテーションセット内のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインが指定されているか否かを判定する。
ステップＳ６１２において、処理主体が、ステップＳ６１１で選択されたアダプテーションセット内のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインが指定されていると判定した場合、処理はステップＳ６１３に進む。
ステップＳ６１３において、処理主体は、ステップＳ６１１で選択されたアダプテーションセット内のリプレゼンテーションのうちで、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのレートの値が小さいものを選択して、セグメントを先行取得する。このとき、処理主体は、タイムライン上で同一時間区間の１または複数のセグメントを先行取得することができる。
一方、ステップＳ６１２において、処理主体が、ステップＳ６１１で選択されたアダプテーションセット内のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインが指定されていないと判定した場合、処理はステップＳ６１４に進む。
ステップＳ６１４では、以下で説明するような所定の条件に従って、セグメントが先行取得される。
例えば、この先行取得処理を行う処理主体が、CDN中間サーバ５２またはCDNエッジサーバ５３である場合、ステップＳ６１１で選択されたアダプテーションセット内のリプレゼンテーションに付加されている、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するもの以外のリプレゼンテーションのセグメントポピュラリティータイムラインのレートの該当するセグメントを優先する。または、何らかの判断（例えば、過去にリクエストされているbitrate（@bandwidth）の該当するリプレゼンテーションのみ、など）に基づいて選択されたセグメントを先行取得する。
また、この先行取得処理を行う処理主体が、クライアント１３である場合、現在のネットワーク状況に応じて適切なリプレゼンテーションのセグメントを先行取得する。
ステップＳ６１３またはＳ６１４の処理後、処理はステップＳ６１５に進み、処理主体は、ピリオド（Period）で表される区間の終了までセグメントを取得し終えたか否かを判定する。
ステップＳ６１５において、処理主体が、セグメントを取得し終えていないと判定した場合、処理はステップＳ６１１に戻り、取得すべき後続のセグメントを同様に先行取得する処理が繰り返して行われる。
一方、ステップＳ６１５において、処理主体が、セグメントを取得し終えたと判定した場合、この先行取得処理は終了される。
図９８に示すフローチャートを参照して、図９６のステップＳ６０５で行われる先行取得処理について説明する。なお、この先行取得処理は、アダプテーションセットには、該当するセグメントポピュラリティータイムラインのエレメントがなく、かつ、リプレゼンテーションに、該当するセグメントポピュラリティータイムラインのエレメントがある場合に行われる。
ステップＳ６２１において、処理主体は、複数のアダプテーションセットを横断して、次に取得しようとするセグメント、即ち、セグメントのタイムライン上で、取得済みのセグメントに続く時間のセグメントについて、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するリプレゼンテーションのセグメントポピュラリティータイムラインのレート（SP@rate）の値の比較を行って、その値が小さいリプレゼンテーションを選択し、セグメントを取得する。このとき、処理主体は、タイムライン上で同一時間区間の１または複数のセグメントを取得する。
ステップＳ６２２において、処理主体は、ピリオド（Period）で表される区間の終了までセグメントを取得し終えたか否かを判定する。
ステップＳ６２２において、処理主体が、セグメントを取得し終えていないと判定した場合、処理はステップＳ６２１に戻り、取得すべき後続のセグメントを同様に先行取得する処理が繰り返して行われる。
一方、ステップＳ６２２において、処理主体が、セグメントを取得し終えたと判定した場合、この先行取得処理は終了される。
＜セグメントを先行取得する先行取得処理の第２の処理例＞
ところで、図９６乃至図９８のフローチャートを参照して説明した処理では、リプレゼンテーションのセグメントポピュラリティータイムラインよりも、アダプテーションセットのセグメントポピュラリティータイムラインを優先して扱うことが想定されている。これに対し、例えば、MPEG DASHのMPD内の他のエレメントと同様に、下位のエレメントに指定されたプロパティが上位のエレメントに指定された値よりも優先されるという解釈にすることもできる。
そこで、図９９に示すフローチャートを参照して、セグメントを先行取得する先行取得処理の第２の処理例について説明する。なお、図９９に示すフローチャートでは、アダプテーションセットおよびリプレゼンテーションのうちの少なくとも一方に、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source="content"）することが必ず指定されている前提で、それのみに基づいた選択を行う場合について説明する。例えば、ソースの属性を示す値が、ソースパラメータにセットされている値と一致すること以外が指定されている情報を用いる場合には、図９６のフローチャートのＳ６０６およびＳ６０８に対応する処理を経て、同様の処理が繰り返される。
例えば、MPDを取得すると処理が開始され、ステップＳ６３１において、処理主体は、判断基準となるソースを設定するソースパラメータに、コンテンツ提供者を示す値をセット（$SourceParam$="content"）する。これにより、以下では、コンテンツ提供者により提供される情報に基づいた判断が行われることになる。
ステップＳ６３２において、処理主体は、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのエレメントがあるか否かを判定する。
ステップＳ６３２において、処理主体が、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがあると判定した場合、処理はステップＳ６３３に進む。
ステップＳ６３３において、処理主体は、各アダプテーションセットについて選択対象のセグメント（ピリオド内の時間区間）に対する、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するリプレゼンテーションのセグメントポピュラリティータイムラインのレートの最小値を、そのリプレゼンテーションを含むアダプテーションセットのセグメントポピュラリティータイムラインのレートの値と比較して、小さい方を、選択対象の（当該）アダプテーションセットのレートの値とする。
ステップＳ６３３の処理後、処理はステップＳ６３４に進む。また、ステップＳ６３２において、処理主体が、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがないと判定した場合、処理はステップＳ６３４に進む。
ステップＳ６３４において、処理主体は、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのエレメントを持つアダプテーションセットの中で、セグメントポピュラリティータイムラインに最小のレートを持つアダプテーションセットを選択する。ここで、アダプテーションセットには、セグメントポピュラリティータイムラインを持たないが、上述のステップＳ６３３の処理により、レートの値を得たものも、選択の対象となるアダプテーションセットに含まれる。
ステップＳ６３５において、ステップＳ６３４で選択されたアダプテーションセットより、以下で説明するような所定の条件に従って、次に取得しようとするセグメント、即ち、セグメントのタイムライン上で、取得済みのセグメントに続く時間のセグメントについて、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのレート（SP@rate）の値が最小であるアダプテーションセット内のセグメントが先行取得される。
例えば、この先行取得処理を行う処理主体が、CDN中間サーバ５２またはCDNエッジサーバ５３である場合、何らかの判断（例えば、過去にリクエストされているbitrate（@bandwidth）のリプレゼンテーションのみ、など）に基づいて選択されたセグメントを先行取得する。
また、この先行取得処理を行う処理主体が、クライアント１３である場合、現在のネットワーク状況に応じて適切なリプレゼンテーションのセグメントを先行取得する。
ステップＳ６３５の処理後、処理はステップＳ６３６に進み、処理主体は、ピリオド（Period）で表される区間の終了までセグメントを取得し終えたか否かを判定する。
ステップＳ６３６において、処理主体が、セグメントを取得し終えていないと判定した場合、処理はステップＳ６３２に戻り、取得すべき後続のセグメントを同様に先行取得する処理が繰り返して行われる。
一方、ステップＳ６３６において、処理主体が、セグメントを取得し終えたと判定した場合、この先行取得処理は終了される。
ここで、クライアント１３が、CDN中間サーバ５２またはCDNエッジサーバ５３に適用ポリシーを指定する方法について説明する。ここでの適用ポリシーは、上述したように、MPDに記述されているセグメントポピュラリティータイムラインに従ってセグメントを先行取得する際の優先すべき情報元（種別）であるソースのことである。
例えば、クライアント１３が、CDN中間サーバ５２またはCDNエッジサーバ５３に適用ポリシーを指定するのに、MPEG DASHのSANDのメッセージ（図５４参照）を利用することができる。なお、MPEG DASHのSANDのメッセージについては、非特許文献『ISO/IEC 23009-5: 2017 Server and Network Assisted DASH (SAND)』で詳細に説明されている。
例えば、SANDにおいて、クライアント１３からCDNサーバなど（DASH Aware Network Element:DANE）へのメッセージは、SAND Status messageと称され、media segmentの取得リクエスト（HTTP GET request）のヘッダに、以下のような拡張ヘッダを付加することで伝達することができる。
ここで、本実施の形態のコンテンツ提供システム１１では、セグメントポピュラリティータイムラインのレートを用いた先行取得をCDN中間サーバ５２またはCDNエッジサーバ５３に伝達するのに、ヘッダ「SAND-PopularityRateSource:network」をメディアセグメント（Media Segment）のリクエスト時に付加することで、どのソースの値の情報を優先して適用すべきかを伝達することができる。または、複数のソースを優先順次列挙するようなヘッダ「SAND-PopularityRateSource:content,network」を付加してもよい。
また、このメッセージは、CDNエッジサーバ５３が、セグメントを取得または先行取得するときに、CDNエッジサーバ５３から上流のCDN中間サーバ５２へも、そのままフォワードされる。
同様に、コンテンツプロバイダ２１が、CDN中間サーバ５２またはCDNエッジサーバ５３に適用ポリシーを指定するのにも、MPEG DASHのSANDメッセージを利用することができる。ここでの適用ポリシーは、上述したように、先行取得するセグメントの選択に際して適用すべきセグメントポピュラリティータイムラインのソースの値である。
例えば、コンテンツプロバイダ２１とCDN中間サーバ５２またはCDNエッジサーバ５３との間でやり取りされるメッセージは、PED（Parameter Enhancing Delivery）メッセージと称され、先行取得するセグメントの選択に際して適用すべきセグメントポピュラリティータイムラインのソースの値の伝達に、PEDメッセージが用いられる。
なお、現状、MPEG規格ではPEDメッセージはアーキテクチャ上で言及されているのみで、具体的なメッセージは定義されていない。また、PEDメッセージを送受信する配信サーバ５１や、CDN中間サーバ５２およびCDNエッジサーバ５３は、SAND規格において、DASH Aware Network Element（DANE）と称される。
また、DANE間のSANDメッセージのやり取りは、次に説明する２通りの方法がSAND規格に規定されている。
即ち、第１の方法は、上流のDANEに対する下流のDANEからの、例えばMedia Segment取得のためのHTTP GET requestに対するresponseに、SAND Messageを取得するためのURLを記載した拡張HTTP headerを付加する。そして、それを受信した下流のDANEが、当該URLにHTTP GET requestを送信して、SANDメッセージを取得する方法である。
また、第２の方法は、DANE間で予めSANDメッセージ交換のためのWebSocketチャネルを確立しておき、そのチャネルを使ってメッセージを送る方法である。
ここでは、第１の方法および第２の方法のどちらを使用しても目的は達成されるが、第１の方法では、メッセージの伝達先がMedia Segmentの取得リクエストを送付してきた場合に限られるため、第２の方法を使用することが望ましい。もちろん、第１の方法を使用しても、一定の範囲では効果を得ることができる。なお、どちらの方法を使用する場合でも、SANDメッセージ自体は、XML文書で記述されることが想定されており、具体的には、図１００に示すように表現される。
または、PopularityRateSourceのエレメントを、優先度順に複数列挙して、図１０１のように表現することができる。図１０１に示す例では、ソースがコンテンツ提供者（source="content"）であるセグメントポピュラリティータイムラインが、ソースがネットワーク（source="network"）であるセグメントポピュラリティータイムラインのものよりも優先されることが表されている。
なお、図１００および図１０１では、ここで、<CommonEnvelope>にはattributeとして enderID，generationTimeを付加することができる。また、messageIdの値は、SANDメッセージの種別を表すが、図示する例は、規格に未定義の新たなメッセージのため"reserved for future ISO use"とされている値とした。
以上のように、複数のソースから提供されるセグメントの「人気度」、または、クライアント１３で消費される「確からしさ」といった情報を、メタデータとしてMPEG DASHのMPD内に簡潔に表現することができる。従って、これに応じた配信リソース配分の最適化や、CDN中間サーバ５２、CDNエッジサーバ５３、またはクライアント１３により、セグメントの先行（予測）取得を行うことが容易に可能となる。
図１０２には、CDNサーバ（DANE）へのセグメントポピュラリティータイムラインの利用時に優先すべきソース（@source）の値を通知する処理の概念が示されている。
図１０２に示すように、DASH配信サーバ６１は、セグメントを先行取得する際の判断時に優先すべきソースの値の伝達を、SAND PEDメッセージを使用して、複数のCDNサーバ６２それぞれに伝達する。そして、DASH配信サーバ６１からCDNサーバ６２へ、セグメントポピュラリティータイムライン（SPT）を含むMPD、および、メディアセグメントが送信される。
また、MPDクライアント６３は、セグメントを先行取得する際の判断時に優先すべきソースの値の伝達を、SAND Statusメッセージを使用して、複数のCDNサーバ６２それぞれに伝達する。そして、CDNサーバ６２からMPDクライアント６３へ、セグメントポピュラリティータイムライン（SPT）を含むMPD、および、メディアセグメントが送信される。
＜コンピュータの構成例＞
なお、上述のフローチャートを参照して説明した各処理は、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。また、プログラムは、１のCPUにより処理されるものであっても良いし、複数のCPUによって分散処理されるものであっても良い。
また、上述した一連の処理（コンテンツ配信方法）は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラムが記録されたプログラム記録媒体からインストールされる。
図１０３は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
コンピュータにおいて、CPU（Central Processing Unit）１０１，ROM（Read Only Memory）１０２，RAM（Random Access Memory）１０３は、バス１０４により相互に接続されている。
バス１０４には、さらに、入出力インタフェース１０５が接続されている。入出力インタフェース１０５には、キーボード、マウス、マイクロホンなどよりなる入力部１０６、ディスプレイ、スピーカなどよりなる出力部１０７、ハードディスクや不揮発性のメモリなどよりなる記憶部１０８、ネットワークインタフェースなどよりなる通信部１０９、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１を駆動するドライブ１１０が接続されている。
以上のように構成されるコンピュータでは、CPU１０１が、例えば、記憶部１０８に記憶されているプログラムを、入出力インタフェース１０５及びバス１０４を介して、RAM１０３にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ（CPU１０１）が実行するプログラムは、例えば、磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM(Compact Disc-Read Only Memory),DVD(Digital Versatile Disc)等）、光磁気ディスク、もしくは半導体メモリなどよりなるパッケージメディアであるリムーバブルメディア１１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供される。
そして、プログラムは、リムーバブルメディア１１１をドライブ１１０に装着することにより、入出力インタフェース１０５を介して、記憶部１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１０９で受信し、記憶部１０８にインストールすることができる。その他、プログラムは、ROM１０２や記憶部１０８に、あらかじめインストールしておくことができる。
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信するコンテンツ配信装置と、
特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを、前記コンテンツ配信装置に提供するコンテンツ提供装置と
を備えるコンテンツ提供システム。
（２）
前記ポリシーでは、所定のネットワークに対する負荷の大きさを表すレベルごとに、特徴の異なる複数のストリームのうちの、そのネットワークで配信するストリームと、他のネットワークで配信するストリームとが分類される
上記（１）に記載のコンテンツ提供システム。
（３）
前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、MPEG DASHにおいてメタ情報を記述するのに用いられるMPD（Media Presentation Description）に記述し、前記MPDを前記コンテンツ配信装置に転送する
上記（２）に記載のコンテンツ提供システム。
（４）
前記コンテンツ配信装置は、前記コンテンツ提供装置から転送された前記MPDを、前記MPDに記述されている前記ポリシーおよび前記レベルを参照し、前記レベルに応じて書き換える
上記（３）に記載のコンテンツ提供システム。
（５）
前記コンテンツ配信装置は、複数のセグメントマネジャを有しており、それらのセグメントマネジャごとに前記MPDが書き換えられる
上記（３）または（４）に記載のコンテンツ提供システム。
（６）
前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、MPEG DASHにおいてイベントを通知する機能を利用して前記コンテンツを再生するクライアントに提供する
上記（２）に記載のコンテンツ提供システム。
（７）
前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、前記コンテンツ提供装置と前記コンテンツ配信装置、または、前記コンテンツを再生するクライアントとの間でやりとりするメッセージングインターフェイス利用して前記コンテンツ配信装置、または、前記コンテンツを再生するクライアントに提供する
上記（２）に記載のコンテンツ提供システム。
（８）
コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信し、
特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供する
ステップを含むコンテンツ提供方法。
（９）
コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信し、
特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供する
ステップを含む処理をコンピュータに実行させるプログラム。
（１０）
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備え、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得する
コンテンツ提供システム。
（１１）
前記優先度は、前記コンテンツを提供するコンテンツ提供者が提供し、前記コンテンツを作成した作成者の意図に従った値で記述される
上記（１０）に記載のコンテンツ提供システム。
（１２）
前記優先度は、前記コンテンツ配信ネットワークにより提供され、前記コンテンツ配信ネットワークを介して前記コンテンツが過去に配信されたときに実測された統計に基づく値で記述される
上記（１０）または（１１）に記載のコンテンツ提供システム。
（１３）
前記メタデータには、前記優先度が適用されるセグメントを指定する要素が記述される
上記（１０）から（１２）までのいずれかに記載のコンテンツ提供システム。
（１４）
前記優先度が適用される一連のセグメントの最初のセグメントを識別する番号、および、それらの一連のセグメントのセグメント数を用いて、前記優先度が適用されるセグメントが指定される
上記（１３）に記載のコンテンツ提供システム。
（１５）
前記優先度の適用が開始される開始時間、および、前記優先度の適用が終了される終了時間を用いて、前記優先度が適用される期間が指定される
上記（１０）から（１２）までのいずれかに記載のコンテンツ提供システム。
（１６）
前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDに記述されるアダプテーションセットに対する子エレメントとして定義される
上記（１０）から（１５）までのいずれかに記載のコンテンツ提供システム。
（１７）
前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDに記述されるリプレゼンテーションに対する子エレメントとして定義される
上記（１０）から（１５）までのいずれかに記載のコンテンツ提供システム。
（１８）
前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDにおいて複数のネットワークで分配する際の判断基準となるポリシー／レベルの記述で用いられるディストリビューションポリシーのエレメントにおけるレベルを利用して指定される
上記（１０）から（１５）までのいずれかに記載のコンテンツ提供システム。
（１９）
コンテンツ提供システムは、
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備え、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得すること
を含むコンテンツ提供方法。
（２０）
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備えるコンテンツ提供システムのコンピュータに、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得すること
を含む処理を実行させるプログラム。
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
１１ コンテンツ提供システム， １２ 全天球カメラ， １３ クライアント， １４ 放送ネットワーク， １５ 双方向ネットワーク， ２１ コンテンツプロバイダ， ２２ CDNサービスプロバイダ， ２３ 放送サービスプロバイダ， ３１ CDNセグメントマネジャ

Claims (20)

  1. コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信するコンテンツ配信装置と、
    特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを、前記コンテンツ配信装置に提供するコンテンツ提供装置と
    を備えるコンテンツ提供システム。
  2. 前記ポリシーでは、所定のネットワークに対する負荷の大きさを表すレベルごとに、特徴の異なる複数のストリームのうちの、そのネットワークで配信するストリームと、他のネットワークで配信するストリームとが分類される
    請求項１に記載のコンテンツ提供システム。
  3. 前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、MPEG DASHにおいてメタ情報を記述するのに用いられるMPD（Media Presentation Description）に記述し、前記MPDを前記コンテンツ配信装置に転送する
    請求項２に記載のコンテンツ提供システム。
  4. 前記コンテンツ配信装置は、前記コンテンツ提供装置から転送された前記MPDを、前記MPDに記述されている前記ポリシーおよび前記レベルを参照し、前記レベルに応じて書き換える
    請求項３に記載のコンテンツ提供システム。
  5. 前記コンテンツ配信装置は、複数のセグメントマネジャを有しており、それらのセグメントマネジャごとに前記MPDが書き換えられる
    請求項４に記載のコンテンツ提供システム。
  6. 前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、MPEG DASHにおいてイベントを通知する機能を利用して前記コンテンツを再生するクライアントに提供する
    請求項２に記載のコンテンツ提供システム。
  7. 前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、前記コンテンツ提供装置と前記コンテンツ配信装置、または、前記コンテンツを再生するクライアントとの間でやりとりするメッセージングインターフェイス利用して前記コンテンツ配信装置、または、前記コンテンツを再生するクライアントに提供する
    請求項２に記載のコンテンツ提供システム。
  8. コンテンツ提供システムが、
    コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信することと、
    特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供することと
    を含むコンテンツ提供方法。
  9. コンテンツ提供システムのコンピュータに、
    コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信することと、
    特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供することと
    を含む処理を実行させるプログラム。
  10. コンテンツ配信ネットワークを構成するサーバと、
    前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
    を備え、
    前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得する
    コンテンツ提供システム。
  11. 前記優先度は、前記コンテンツを提供するコンテンツ提供者が提供し、前記コンテンツを作成した作成者の意図に従った値で記述される
    請求項１０に記載のコンテンツ提供システム。
  12. 前記優先度は、前記コンテンツ配信ネットワークにより提供され、前記コンテンツ配信ネットワークを介して前記コンテンツが過去に配信されたときに実測された統計に基づく値で記述される
    請求項１０に記載のコンテンツ提供システム。
  13. 前記メタデータには、前記優先度が適用されるセグメントを指定する要素が記述される
    請求項１０に記載のコンテンツ提供システム。
  14. 前記優先度が適用される一連のセグメントの最初のセグメントを識別する番号、および、それらの一連のセグメントのセグメント数を用いて、前記優先度が適用されるセグメントが指定される
    請求項１３に記載のコンテンツ提供システム。
  15. 前記優先度の適用が開始される開始時間、および、前記優先度の適用が終了される終了時間を用いて、前記優先度が適用される期間が指定される
    請求項１０に記載のコンテンツ提供システム。
  16. 前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDに記述されるアダプテーションセットに対する子エレメントとして定義される
    請求項１０に記載のコンテンツ提供システム。
  17. 前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDに記述されるリプレゼンテーションに対する子エレメントとして定義される
    請求項１０に記載のコンテンツ提供システム。
  18. 前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDにおいて複数のネットワークで分配する際の判断基準となるポリシー／レベルの記述で用いられるディストリビューションポリシーのエレメントにおけるレベルを利用して指定される
    請求項１０に記載のコンテンツ提供システム。
  19. コンテンツ提供システムは、
    コンテンツ配信ネットワークを構成するサーバと、
    前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
    を備え、
    前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得すること
    を含むコンテンツ提供方法。
  20. コンテンツ配信ネットワークを構成するサーバと、
    前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
    を備えるコンテンツ提供システムのコンピュータに、
    前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得すること
    を含む処理を実行させるプログラム。
JP2019507590A 2017-03-24 2018-03-14 コンテンツ提供システムおよびコンテンツ提供方法、並びにプログラム Pending JPWO2018173874A1 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2017060220 2017-03-24
JP2017060220 2017-03-24
JP2017201130 2017-10-17
JP2017201130 2017-10-17
PCT/JP2018/009912 WO2018173874A1 (ja) 2017-03-24 2018-03-14 コンテンツ提供システムおよびコンテンツ提供方法、並びにプログラム

Publications (1)

Publication Number Publication Date
JPWO2018173874A1 true JPWO2018173874A1 (ja) 2020-01-30

Family

ID=63586022

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019507590A Pending JPWO2018173874A1 (ja) 2017-03-24 2018-03-14 コンテンツ提供システムおよびコンテンツ提供方法、並びにプログラム

Country Status (6)

Country Link
US (1) US10893315B2 (ja)
EP (1) EP3591978A4 (ja)
JP (1) JPWO2018173874A1 (ja)
KR (1) KR20190128630A (ja)
CN (1) CN110431848B (ja)
WO (1) WO2018173874A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111090691B (zh) * 2019-12-19 2021-02-09 北京百度网讯科技有限公司 一种数据处理方法、装置、电子设备和存储介质
US11546406B2 (en) * 2020-04-13 2023-01-03 Tencent America LLC Media systems and methods including mixed event message tracks
CN112153402A (zh) * 2020-09-22 2020-12-29 北京达佳互联信息技术有限公司 电子资源分配方法、装置、电子设备和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090292819A1 (en) * 2008-05-23 2009-11-26 Porto Technology, Llc System and method for adaptive segment prefetching of streaming media
JP2014511519A (ja) * 2011-02-07 2014-05-15 アルカテル−ルーセント セグメント化されたマルチメディアのためのキャッシュマネージャおよび対応するキャッシュ管理の方法
WO2015004276A2 (en) * 2013-07-12 2015-01-15 Canon Kabushiki Kaisha Adaptive data streaming method with push messages control
JP2019020994A (ja) * 2017-07-14 2019-02-07 国立大学法人電気通信大学 ネットワークシステム、ノード装置、キャッシュ方法及びプログラム

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050044561A1 (en) * 2003-08-20 2005-02-24 Gotuit Audio, Inc. Methods and apparatus for identifying program segments by detecting duplicate signal patterns
JP2005244525A (ja) * 2004-02-25 2005-09-08 Fujitsu Ltd 通信装置
US8782268B2 (en) * 2010-07-20 2014-07-15 Microsoft Corporation Dynamic composition of media
CA2831128C (en) * 2011-03-23 2018-09-18 Invidi Technologies Corporation A priori scheduling of multiple assets within a collection of asset delivery opportunities
US9026671B2 (en) 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US9712891B2 (en) 2011-11-01 2017-07-18 Nokia Technologies Oy Method and apparatus for selecting an access method for delivery of media
US20130182643A1 (en) * 2012-01-16 2013-07-18 Qualcomm Incorporated Method and system for transitions of broadcast dash service receptions between unicast and broadcast
WO2014011848A2 (en) * 2012-07-12 2014-01-16 Huawei Technologies Co., Ltd. Signaling and processing content with variable bitrates for adaptive streaming
JP6348251B2 (ja) 2012-09-13 2018-06-27 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ 端末装置、受信方法、およびプログラム
US10015437B2 (en) 2013-01-15 2018-07-03 Qualcomm Incorporated Supporting transport diversity and time-shifted buffers for media streaming over a network
EP2963939A4 (en) 2013-02-27 2016-10-05 Sony Corp INFORMATION PROCESSING DEVICE, METHOD AND PROGRAM AND CONTENT PROCESSING SYSTEM
JP2014239278A (ja) 2013-06-06 2014-12-18 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
GB2528039A (en) * 2014-07-01 2016-01-13 Canon Kk Method for identifying objects across time periods and corresponding device
KR102460444B1 (ko) 2014-10-28 2022-10-31 소니그룹주식회사 수신 장치, 송신 장치 및 데이터 처리 방법
US9509742B2 (en) * 2014-10-29 2016-11-29 DLVR, Inc. Configuring manifest files referencing infrastructure service providers for adaptive streaming video
US10129308B2 (en) * 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data
WO2016127440A1 (zh) * 2015-02-15 2016-08-18 华为技术有限公司 基于超文本传输协议媒体流的媒体呈现导览方法和相关装置
US11057446B2 (en) * 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
US10412461B2 (en) * 2015-06-12 2019-09-10 Cable Television Laboratories, Inc. Media streaming with latency minimization
EP3318034B1 (en) * 2015-06-30 2023-10-25 British Telecommunications public limited company Low latency media streaming
CN106331898A (zh) * 2016-09-09 2017-01-11 三星电子（中国）研发中心 一种基于dash的多媒体内容插入播放的方法和设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090292819A1 (en) * 2008-05-23 2009-11-26 Porto Technology, Llc System and method for adaptive segment prefetching of streaming media
JP2014511519A (ja) * 2011-02-07 2014-05-15 アルカテル−ルーセント セグメント化されたマルチメディアのためのキャッシュマネージャおよび対応するキャッシュ管理の方法
WO2015004276A2 (en) * 2013-07-12 2015-01-15 Canon Kabushiki Kaisha Adaptive data streaming method with push messages control
JP2016531466A (ja) * 2013-07-12 2016-10-06 キヤノン株式会社 プッシュメッセージ制御による適応型データストリーミング方法
JP2019020994A (ja) * 2017-07-14 2019-02-07 国立大学法人電気通信大学 ネットワークシステム、ノード装置、キャッシュ方法及びプログラム

Also Published As

Publication number Publication date
CN110431848A (zh) 2019-11-08
EP3591978A1 (en) 2020-01-08
US10893315B2 (en) 2021-01-12
EP3591978A4 (en) 2020-04-08
WO2018173874A1 (ja) 2018-09-27
KR20190128630A (ko) 2019-11-18
US20200053411A1 (en) 2020-02-13
CN110431848B (zh) 2021-12-21

Similar Documents

Publication Publication Date Title
US11785268B1 (en) System for managing video playback using a server generated manifest/playlist
US11632578B2 (en) Apparatus and method for configuring control message in broadcasting system
KR101787601B1 (ko) 타깃 미디어 콘텐츠의 전송기법
JP7167194B2 (ja) リアルタイム適応ビットレートトランスコーディングおよびトランスコードされたメディアの伝送のためのシステムおよび方法
JP6348251B2 (ja) 端末装置、受信方法、およびプログラム
US9277252B2 (en) Method and apparatus for adaptive streaming based on plurality of elements for determining quality of content
CA2844648C (en) Method and apparatus for adaptive transcoding of multimedia stream
US11044497B1 (en) Method of unified video switching and advertisement splicing within consumer devices
WO2012033766A1 (en) Method and apparatus for adaptive bit rate switching
CN109792546B (zh) 从服务器向客户端设备传送视频内容的方法
US9866602B2 (en) Adaptive bit rates during broadcast transmission in distributed content delivery networks
US11252478B2 (en) Distribution device, distribution method, reception device, reception method, program, and content distribution system
CN110431848B (zh) 内容提供系统、内容提供方法和程序
US10687106B2 (en) System and method for distributed control of segmented media
US11102536B2 (en) Transmission apparatus, reception apparatus, and data processing method
US10778743B2 (en) Method for identifying objects across time periods and corresponding device
US11277649B2 (en) Chunk-based filtering to optimize video streaming quality and data usage
Haimi-Cohen et al. Flexible and robust video delivery based on self-contained multimedia segments
JP2023004668A (ja) 配信装置、配信方法及び配信プログラム

Legal Events

Date Code Title Description
A524 Written submission of copy of amendment under article 19 pct

Free format text: JAPANESE INTERMEDIATE CODE: A527

Effective date: 20190805

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210202

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220412

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20221018