(57)【要約】  本開示は、異なるCDNでコンテンツを配信する際のトランスコードに関わる条件を共通化し、標準的なアップロードインターフェイスをサポートすることができるようにするコンテンツ配信制御装置、コンテンツ配信制御方法、プログラム、およびコンテンツ配信システムに関する。メタデータファイルに定義情報が格納されている場合、定義情報に基づいて、オリジナルセグメントのトランスコードが制御される。一方、メタデータファイルに定義情報にアクセスするためのアクセス情報が格納されている場合、そのアクセス情報に基づいて定義情報をリクエストし、リクエストに応じて受信された定義情報に基づいて、オリジナルセグメントのトランスコードが制御される。MPEG-DASHを利用してコンテンツを配信するコンテンツ配信システムに適用できる。
2019167633.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASH(Dynamic Adaptive Streaming over HTTP)に従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部と
を備え、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御し、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御する
コンテンツ配信制御装置。
【請求項２】
前記メタデータファイルは、ISO IEC 23009で規格定義されるMPD（Media Presentation Description）ファイルである
請求項１に記載のコンテンツ配信制御装置。
【請求項３】
前記定義情報および前記アクセス情報は、前記MPDのAdaptationSetに格納される
請求項２に記載のコンテンツ配信制御装置。
【請求項４】
前記定義情報および前記アクセス情報は、前記MPDのRepresentationに格納される
請求項２に記載のコンテンツ配信制御装置。
【請求項５】
前記定義情報および前記アクセス情報は、前記MPDのSubRepresentationに格納される
請求項２に記載のコンテンツ配信制御装置。
【請求項６】
前記定義情報は、単独のファイルとして記憶されている
請求項１に記載のコンテンツ配信制御装置。
【請求項７】
前記定義情報により、前記コンテンツがトランスコード可能であるか否かが指定される
請求項１に記載のコンテンツ配信制御装置。
【請求項８】
前記定義情報には、部分的な画像修正処理を含むアップスケーリング方式が定義されている
請求項１に記載のコンテンツ配信制御装置。
【請求項９】
前記定義情報には、トランスコードの可否制御に利用する条件記述言語に基づく条件記述が定義されている
請求項１に記載のコンテンツ配信制御装置。
【請求項１０】
前記定義情報には、実際に適用されたトランスコード処理の内容報告に利用する情報構造が定義されている
請求項１に記載のコンテンツ配信制御装置。
【請求項１１】
前記コンテンツのトランスコードは、前記コンテンツを取得して再生するクライアントから取得される前記クライアントの環境情報に基づいて行われる
請求項１に記載のコンテンツ配信制御装置。
【請求項１２】
前記クライアントからviewport通知が行われるのに応じ、そのviewportを含むようにアップスケーリングするトランスコードを制御する
請求項１１に記載のコンテンツ配信制御装置。
【請求項１３】
コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASH(Dynamic Adaptive Streaming over HTTP)に従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部と
を備えるコンテンツ配信制御装置が、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することと、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することと
を含むコンテンツ配信制御方法。
【請求項１４】
コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASH(Dynamic Adaptive Streaming over HTTP)に従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部と
を備えるコンテンツ配信制御装置のコンピュータに、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することと、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することと
を含む処理を実行させるためのプログラム。
【請求項１５】
コンテンツを記憶する記憶部を有する第１のサーバと、
前記コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASH(Dynamic Adaptive Streaming over HTTP)に従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部と
を有し、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御し、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御する
コンテンツ配信制御を行う第２のサーバと、
前記コンテンツ配信制御に従って配信される前記コンテンツを取得して、再生するクライアントと
を備えるコンテンツ配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンテンツ配信制御装置、コンテンツ配信制御方法、プログラム、およびコンテンツ配信システムに関し、特に、異なるCDN（Contents Delivery Network）でコンテンツを配信する際のトランスコードに関わる条件を共通化し、標準的なアップロードインターフェイスをサポートすることができるようにしたコンテンツ配信制御装置、コンテンツ配信制御方法、プログラム、およびコンテンツ配信システムに関する。
【背景技術】
【０００２】
IPTV(Internet Protocol Television)等のインターネットストリーミングにおける標準化の流れとして、HTTP(Hypertext Transfer Protocol)ストリーミングによるVOD（Video On Demand）ストリーミングや、ライブストリーミングに適用される方式の標準化が行われている。【０００３】
特に、ISO/IEC/MPEGで標準化が行われているMPEG-DASH(Dynamic Adaptive Streaming over HTTP)が注目されている（例えば、非特許文献１参照）。【０００４】
MPEG-DASHは、MPD（Media Presentation Description）と呼ばれるメタファイルと、そこに記述されるチャンク化されたオーディオ、ビデオ、又は字幕等のメディアデータのアドレス（URL：Uniform Resource Locator）に従い、ストリームデータを取得して再生するものである。【０００５】
また、現在、ストリームキャプチャデバイスからクラウドへのアップロードインターフェイスとして、3GPP（Third Generation Partnership Project）において、FLUS（Framework For Live Uplink Streaming）のフレームワークが検討されている（例えば、非特許文献２および３参照）。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】ISO/IEC 23009-1:2012 Information technology Dynamic adaptive streaming over HTTP (DASH)
【非特許文献２】3GPP TS 26.238 V15.0.0(2017-12)  3rd Generation Partnership Project ; Technical Specification Group Services and System Aspects ; Uplink Streaming (Release 15)
【非特許文献３】3GPP TS 26.114 V15.1.0(2017-12)  3rd Generation Partnership Project ; Technical Specification Group Services and System Aspects ; IP Multimedia Subsystem(IMS) ; Multimedia Telephony ; Media handling and interaction (Release 15)
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、配信フェーズに移行したストリーミングコンテンツが、例えば、エンドユーザの近傍のエッジサーバ（CDNの構成要素）において、エンドユーザのストリーム再生環境条件に応じて、トランスコードされて提供される可能性がある。例えば、トランスコードの際には、オリジナルのストリームを一旦デコードしてベースバンドストリームに落とし、さらにユーザの再生環境にふさわしいストリームとしてエンコードすることが行われる。このベースバンドに落とす際に、今後、余力のあるエッジサーバが、エンドユーザの環境条件に応じて様々なアップスケール（アップコンバート）処理を施す可能性がある。【０００８】
例えば、エンドユーザのデバイスのディスプレイのアスペクト比または空間解像度や、再生機器の特性などを加味して最適な絵音作りが行われてから、デコーダの処理能力に応じたストリームとしてエンコードし直す可能性がある。ここで、最適な絵音作りとしては、単なる線形外挿補間的なアップコンバート以外にも、例えば、AI（Artificial Intelligence）等を利用した高度な画像または音声を追加することが想定される。但し、このアップスケール処理や絵音作り等は、コンテンツプロバイダ（コンテンツのオーナ）、または、サービスプロバイダ（配信サービスプロバイダ等）の意向により可否制御されるべきという要件がある。即ち、配信プラットフォームのエッジサーバまでは、オーナやサービサー等の意向通りの配信制御を行うことができるようにする必要がある。【０００９】
ところで、現状では、様々なベンダで提供されるCDNサービスにおいて共有可能な、ストリームの再生制御に関わる標準的なメタデータは用意されていない。従って、DASH-MPD（または、HLSのm3u8）等のストリーミングマニフェストファイルに、上述したようなトランスコードに係る様々な条件を記述することで、コンテンツを配信する際のトランスコードに関わる条件を共通化することが求められている。【００１０】
即ち、CDNは、複数のベンダで提供されるのが一般的であり、それぞれ異なるCDNにおいてコンテンツを共通のマニフェストで配信するのに関わる様々な制御やポリシーなどの標準化が行われていない。そのため、マニフェスト（MPD）に、例えば、トランスコードに関わる制限や条件などをレポーティング（ログ収集）するための宛先などを定めることが必要となる。【００１１】
さらに、例えば、UGC（User Generated Contents）コンテンツ等のストリームを配信するユースケースの増加に伴い、ビデオエコシステム等の配信プラットフォームにおいても、標準的なコンテンツアップロードインタフェイス（ライブストリームアップリンク）をサポートすることになる可能性がある。【００１２】
従って、こういったプロトコルにおいても配信フェーズに移行したストリーミングコンテンツのエッジサーバでのトランスコード可否制御を宣言したり、実行されるトランスコードの種類や頻度等のログを収集して効果的な運用に利用したりすることができるようにサポートすることが求められている。また、トランスコードには、コンテンツ改変を伴うケースも含まれることが想定され、そのようなケースに対応するアップロードインターフェイスの定義が必要となる。【００１３】
本開示は、このような状況に鑑みてなされたものであり、異なるCDNでコンテンツを配信する際のトランスコードに関わる条件を共通化し、標準的なアップロードインターフェイスをサポートすることができるようにするものである。
【課題を解決するための手段】
【００１４】
本開示の一側面のコンテンツ配信制御装置は、コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASHに従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、前記メタデータファイルを受信する受信部と、前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部とを備え、前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御し、前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御する。【００１５】
本開示の一側面のコンテンツ配信制御方法は、コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASHに従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、前記メタデータファイルを受信する受信部と、前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部とを備えるコンテンツ配信制御装置が、前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することと、前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することとを含む。【００１６】
本開示の一側面のプログラムは、コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASHに従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、前記メタデータファイルを受信する受信部と、前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部とを備えるコンテンツ配信制御装置のコンピュータに、前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することと、前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することとを含む処理を実行させる。【００１７】
本開示の一側面のコンテンツ配信システムは、コンテンツを記憶する記憶部を有する第１のサーバと、前記コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASHに従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、前記メタデータファイルを受信する受信部と、前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部とを有し、前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御し、前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御するコンテンツ配信制御を行う第２のサーバと、前記コンテンツ配信制御に従って配信されるコンテンツを取得して、再生するクライアントとを備える。【００１８】
本開示の一側面においては、コンテンツをトランスコードするために必要な定義情報、または、定義情報にアクセスするための第１のアクセス情報と、コンテンツから生成されたオリジナルのデータであるMPEG-DASHに従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルが生成され、メタデータファイルが受信され、第２のアクセス情報に基づいて取得されたオリジナルセグメントのトランスコードに関する制御が行われる。そして、メタデータファイルに定義情報が格納されている場合、定義情報に基づいて、オリジナルセグメントのトランスコードが制御される。一方、メタデータファイルに第１のアクセス情報が格納されている場合、第１のアクセス情報に基づいて定義情報がリクエストされ、そのリクエストに応じて受信された定義情報に基づいて、オリジナルセグメントのトランスコードが制御される。
【発明の効果】
【００１９】
本開示の一側面によれば、異なるCDNでコンテンツを配信する際のトランスコードに関わる条件を共通化し、標準的なアップロードインターフェイスをサポートすることができる。【００２０】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００２１】
【図１】本技術を適用したコンテンツ配信システムの第１の実施の形態の構成例を示すブロック図である。
【図２】本技術を適用したコンテンツ配信システムの第２の実施の形態の構成例を示すブロック図である。
【図３】図１の構成例におけるFLUSインターフェイス界面のシステム構成について説明する図である。
【図４】図２の構成例におけるFLUSインターフェイス界面のシステム構成について説明する図である。
【図５】コンテンツ配信処理で用いられるプロトコルの詳細について説明する図である。
【図６】ServiceResourceの一例を示す図である。
【図７】SessionResourceの一例を示す図である。
【図８】『"FLUSシンクがFLUSソースからストリームを(Push/Pull)取得するための情報"』の一例を示す図である。
【図９】『"当該セッションストリームのSDPのURL"』におけるSDPの一例を示す図である。
【図１０】『"当該セッションストリームのSDPのURL"』におけるSDPの他の例を示す図である。
【図１１】コンテンツ配信処理で用いられるプロトコルの詳細について説明する図である。
【図１２】コンテンツ配信システムの詳細な構成例を示すブロック図である。
【図１３】ストリームソースサーバの構成例を示すブロック図である。
【図１４】ストリーミング配信マネジャの構成例を示すブロック図である。
【図１５】DASH配信サーバの構成例を示すブロック図である。
【図１６】CDNサーバの構成例を示すブロック図である。
【図１７】DASHプレイヤの構成例を示すブロック図である。
【図１８】図１２のコンテンツ配信システムにおけるコンテンツ配信処理を説明する図である。
【図１９】TranscodeDirectiveの内容がFLUSインターフェイスを介したメタデータ（SDP）として渡される場合の対応関係を示す図である。
【図２０】ストリーミング配信マネジャがクラウド上に設けられるバリエーションのコンテンツ配信システムの構成例を示すブロック図である。
【図２１】図２０のコンテンツ配信システムにおけるコンテンツ配信処理を説明する図である。
【図２２】トランスコード済みセグメントを参照するMPDをクライアントに通知してセグメントを取得させるコンテンツ配信処理を説明する図である。
【図２３】トランスコード前のセグメントのURLをトランスコード済みセグメントのURLに流用してクライアントにセグメントを取得させるコンテンツ配信処理を説明する図である。
【図２４】DASH-MPDへのTranscodeDirective要素の配置例を示す図である。
【図２５】DASH-MPDへのTranscodeDirective要素の配置例のバリエーションを示す図である。
【図２６】transcodable属性、upScalable属性、processingLimit属性、Allowed要素、Prohibited要素、およびCondition要素について説明する図である。
【図２７】Condition要素のコンテンツパートのCDATAセクションに条件記述が格納される一例を示す図である。
【図２８】ODRL記述の一例を示す図である。
【図２９】TranscodeEventNotification要素、dateTime属性、MPDUrl属性、AdaptationSetId属性、およびnotificationUrl属性について説明する図である。
【図３０】TranscodeDirective要素の一例を示す図である。
【図３１】Parameters/Video要素、profile属性、resolution属性、frameRate属性、bitDepth属性、colorSpace属性、gamma属性、およびupScalingPatternList属性について説明する図である。
【図３２】partialTransformability属性、deviationLimit要素、Parameters/Audio要素、profileList属性、samplingRate属性、bitDepth属性、およびdeviationLimit要素について説明する図である。
【図３３】value属性に値が格納される例を示す図である。
【図３４】TrasncodeDirectiveの構成例を示す図である。
【図３５】アップスケーリング（FullHeight）の例を示す図である。
【図３６】アップスケーリング（FullWidth-TopBottomCrop-BlowUp）例を示す図である。
【図３７】アップスケーリング（FullSize-Anamorphic）の例を示す図である。
【図３８】アップスケーリング（Artificial-FullSize-Anamorphic）の例を示す図である。
【図３９】PartialTransformabilityを利用してコンテンツを配信するコンテンツ配信処理を説明する図である。
【図４０】viewport通知について説明する図である。
【図４１】viewport通知の一例を示す図である。
【図４２】デバイス属性の一例を示す図である。
【図４３】FLUSの機能ブロックを示す図である。
【図４４】FLUS Sessionの一例を示す図である。
【図４５】SANDのViewportViewsメッセージの追加拡張の一例を示す図である。
【図４６】本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
【発明を実施するための形態】
【００２２】
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
【００２３】
＜コンテンツ配信システムの第１および第２の構成例＞
図１は、本技術を適用したコンテンツ配信システムの第１の実施の形態の構成例を示すブロック図であり、図２は、本技術を適用したコンテンツ配信システムの第２の実施の形態の構成例を示すブロック図である。
【００２４】
図１に示すコンテンツ配信システム１１Ａは、例えば、インターネットを経由して様々なサービスを提供するクラウドコンピューティング（以下、クラウドと称する）１２に、コンテンツ提供装置１３ＡおよびDASHプレイヤ１４が接続されて構成される。そして、コンテンツ配信システム１１Ａでは、コンテンツ提供装置１３Ａが備えるストリームソースサーバ２１から配信されるコンテンツは、クラウド１２上にあるDASH配信サーバ２２を経由して、クラウド１２上の複数のCDNサーバにより構築されるCDN２３を介して、DASHプレイヤ１４に提供される。
【００２５】
図２に示すコンテンツ配信システム１１Ｂは、コンテンツ配信システム１１Ａと同様に、クラウド１２に、コンテンツ提供装置１３ＢおよびDASHプレイヤ１４が接続されて構成される。そして、コンテンツ配信システム１１Ｂでは、コンテンツ提供装置１３Ｂが備えるストリームソースサーバ２１からDASH配信サーバ２２を経由して配信されるコンテンツは、クラウド１２上の複数のCDNサーバにより構築されるCDN２３を介して、DASHプレイヤ１４に提供される。
【００２６】
即ち、図１のコンテンツ配信システム１１Ａは、ストリームソースサーバ２１を備えたコンテンツ提供装置１３Ａとは別に、クラウド１２上にDASH配信サーバ２２が設けられた構成となっている。一方、図２のコンテンツ配信システム１１Ｂは、ストリームソースサーバ２１を備えたコンテンツ提供装置１３Ａが、DASH配信サーバ２２も備えた構成となっている。
【００２７】
コンテンツ提供装置１３Ａおよび１３Ｂは、例えば、いわゆるスマートフォンやディジタルカメラなどのように、コンテンツの入力を行う入力装置（ストリームキャプチャデバイス）である。
【００２８】
DASHプレイヤ１４は、例えば、いわゆるスマートフォンやタブレット、パーソナルコンピュータ、テレビジョン受像機、ゲーム機器、ヘッドマウントディスプレイなどのように、コンテンツを再生して出力する出力装置である。
【００２９】
ストリームソースサーバ２１は、コンテンツ配信システム１１Ａまたは１１Ｂにおいて配信されるコンテンツを記憶する記憶部を有しており、例えば、DASHプレイヤ１４から配信が要求されたコンテンツを記憶部から読み出して配信する。
【００３０】
DASH配信サーバ２２は、エンコーダ、DASHセグメンタ、およびMPDジェネレータを少なくとも有しており、コンテンツ配信システム１１Ａまたは１１Ｂにおいて配信されるコンテンツのエンコード、MPEG-DASHに従ったセグメントの生成、および、MPDの生成を行うことができる。
【００３１】
CDN２３は、複数のCDNサーバ（後述するCDNオリジンサーバ４１ａや、CDN中継サーバ、CDNエッジサーバ４１ｂなど）により多段に構成され、コンテンツを配信するために最適化されたネットワークを構築する。
【００３２】
なお、コンテンツ提供装置１３Ａまたは１３Ｂからクラウド１２へのアップロードインターフェイスについては、FLUS（上述の非特許文献２および３参照）のフレームワークが利用される。即ち、図１に示すように、コンテンツ配信システム１１Ａでは、ストリームソースサーバ２１およびDASH配信サーバ２２の間で、FLUSインターフェイスが利用され、例えば、DASH配信サーバ２２はFLUSインターフェイスを介してセグメントおよびMPDを取得する。また、図２に示すように、コンテンツ配信システム１１Ｂでは、DASH配信サーバ２２およびCDN２３の間で、FLUSインターフェイスが利用され、例えば、CDN２３はFLUSインターフェイスを介してセグメントおよびMPDを取得する。
【００３３】
＜FLUSインターフェイスを介したコンテンツ配信処理＞
図３を参照して、図１のコンテンツ提供装置１３ＡにおけるFLUSインターフェイス界面のシステム構成について説明する。
【００３４】
コンテンツ提供装置１３Ａでは、ストリームソースサーバ２１を備えるコンテンツ提供装置１３ＡがFLUSソースとなり、DASH配信サーバ２２を備えるクラウド１２上にFLUSシンクが設けられる。ここでは、FLUSメディアに関する処理を、ストリームソースサーバ２１およびDASH配信サーバ２２が行い、FLUSコントロールに関する処理を、コンテンツ提供装置１３Ａおよびクラウド１２により提供されるFLUSコントローラが行うものとして説明する。
【００３５】
ステップＳ１１において、コンテンツ提供装置１３ＡのFLUSコントローラは、AuthenticationまたはAuthorizationの要求を行い、コンテンツ提供装置１３Ａからクラウド１２にAuthenticationまたはAuthorizationのパラメタが送信される。
【００３６】
クラウド１２のFLUSコントローラは、ステップＳ１１で送信されてくるAuthenticationまたはAuthorizationのパラメタを受信すると、ステップＳ１２において、AuthenticationまたはAuthorizationの返答を行う。これにより、クラウド１２からコンテンツ提供装置１３Ａに、サービスにアクセスする権利が与えられたことを示すAccessTokenが送信される。
【００３７】
コンテンツ提供装置１３ＡのFLUSコントローラは、ステップＳ１２で送信されてくるAccessTokenを受信すると、ステップＳ１３において、Service確立の要求を行い、コンテンツ提供装置１３Ａからクラウド１２にAccessTokenが送信される。ここで、このようにAccessTokenが送信されるのは、Service確立を要求するメッセージにAccessTokenが付与されていて、サービスにアクセスする権利が与えられていることの証明を目的として使用される。なお、以下のステップで送信されるAccessTokenも、それぞれの処理において同様の目的で使用される。
【００３８】
クラウド１２のFLUSコントローラは、ステップＳ１３で送信されてくるAccessTokenを受信すると、ステップＳ１４において、Service確立の返答を行う。これにより、クラウド１２からコンテンツ提供装置１３Ａに、クラウド１２で確立したServiceのServiceIDが送信される。
【００３９】
コンテンツ提供装置１３ＡのFLUSコントローラは、ステップＳ１４で送信されてくるServiceIDを受信すると、ステップＳ１５において、ServiceResourceの要求を行う。これにより、コンテンツ提供装置１３Ａからクラウド１２にAccessTokenおよびServiceIDが送信される。
【００４０】
クラウド１２のFLUSコントローラは、ステップＳ１５で送信されてくるAccessTokenおよびServiceIDを受信すると、ステップＳ１６において、ServiceResourceの返答を行う。これにより、クラウド１２からコンテンツ提供装置１３Ａに、ServiceResourceが送信される。
【００４１】
コンテンツ提供装置１３ＡのFLUSコントローラは、ステップＳ１６で送信されてくるServiceResourceを受信すると、以降、Serviceそのものの属性に変更が必要となった場合には、ステップＳ１７において、受信したServiceResourceで更新を行う。そして、コンテンツ提供装置１３Ａからクラウド１２にAccessToken、ServiceID、およびServiceResourceが送信される。
【００４２】
クラウド１２のFLUSコントローラは、ステップＳ１７で送信されてくるAccessToken、ServiceID、およびServiceResourceを受信すると、ステップＳ１８において、それらの受信が成功したことを示すACK返答を行う。
【００４３】
コンテンツ提供装置１３ＡのFLUSコントローラは、ステップＳ１８におけるACK返答を受信すると、ステップＳ１９において、Session確立の要求を行う。これにより、コンテンツ提供装置１３Ａからクラウド１２にAccessTokenが送信される。
【００４４】
クラウド１２のFLUSコントローラは、ステップＳ１９で送信されてくるAccessTokenを受信すると、ステップＳ２０において、Session確立の返答を行う。これにより、クラウド１２からコンテンツ提供装置１３Ａに、クラウド１２で確立したSessionのSessionIDが送信される。
【００４５】
コンテンツ提供装置１３ＡのFLUSコントローラは、ステップＳ２０で送信されてくるSessionIDを受信すると、ステップＳ２１において、SessionResourceの要求を行う。これにより、コンテンツ提供装置１３Ａからクラウド１２にAccessTokenおよびServiceIDが送信される。
【００４６】
クラウド１２のFLUSコントローラは、ステップＳ２１で送信されてくるAccessTokenおよびServiceIDを受信すると、ステップＳ２２において、SessionResourceの返答を行う。これにより、クラウド１２からコンテンツ提供装置１３Ａに、SessionResourceが送信される。
【００４７】
コンテンツ提供装置１３ＡのFLUSコントローラは、ステップＳ２２で送信されてくるSessionResourceを受信すると、ステップＳ２３において、受信したSessionResourceで更新を行う。そして、コンテンツ提供装置１３Ａからクラウド１２に、AccessToken、ServiceID、およびSessionResourceが送信される。
【００４８】
クラウド１２のFLUSコントローラは、ステップＳ２３で送信されてくるAccessToken、ServiceID、およびSessionResourceを受信すると、ステップＳ２４において、それらの受信が成功したことを示すACK返答を行う。
【００４９】
その後、ストリームソースサーバ２１は、ストリームおよびメタデータの転送を開始し、ステップＳ２５において、AccessTokenおよびSessionIDとともに、StreamおよびMetadataを送信する。このとき、ステップＳ２３で更新されたSessionResourceに格納することにより通知した内容と同様な内容をMetadataに格納することによっても、当該StreamのTranscodeDirectiveを通知することができる。
【００５０】
DASH配信サーバ２２は、ステップＳ２５で送信されてくるAccessTokenおよびSessionIDとともに、StreamおよびMetadataを受信すると、ステップＳ２６において、それらの受信が成功したことを示すACK返答を行う。
【００５１】
以下、ストリームの配信が終了するまで、ストリームソースサーバ２１とDASH配信サーバ２２との間で、ステップＳ２５およびＳ２６と同様の処理が繰り返して行われる。
【００５２】
そして、ストリームの配信が終了すると、ステップＳ２７において、コンテンツ提供装置１３ＡのFLUSコントローラは、Session解放の要求を行う。これにより、コンテンツ提供装置１３Ａからクラウド１２にAccessTokenおよびSessionIDが送信される。
【００５３】
クラウド１２のFLUSコントローラは、ステップＳ２７で送信されてくるAccessTokenおよびSessionIDを受信すると、ステップＳ１８において、それらの受信が成功したことを示すACK返答を行う。これに応じて、クラウド１２のFLUSコントローラは、Sessionを解放する処理を行う。
【００５４】
コンテンツ提供装置１３ＡのFLUSコントローラは、ステップＳ２８におけるACK返答を受信すると、ステップＳ２９において、Service解放の要求を行う。これにより、コンテンツ提供装置１３Ａからクラウド１２にAccessTokenおよびServiceIDが送信される。
【００５５】
クラウド１２のFLUSコントローラは、ステップＳ２９で送信されてくるAccessTokenおよびServiceIDを受信すると、ステップＳ３０において、それらの受信が成功したことを示すACK返答を行う。これに応じて、クラウド１２のFLUSコントローラは、Serviceを解放する処理を行い、そのACK返答が受信されると処理は終了される。
【００５６】
以上のように、コンテンツ提供装置１３ＡのFLUSコントローラが、クラウド１２のFLUSコントローラから送信されてくるSessionResourceの内容を更新してクラウド１２のFLUSコントローラに送信するか、または、ストリームソースサーバ２１が、Metadataをクラウド１２のDASH配信サーバ２２に送信するかの、いずれかにより、FLUSソース側が、当該StreamのTranscodeDirectiveを、FLUSシンク側に通知することができる。
【００５７】
図４を参照して、図２のコンテンツ提供装置１３ＢにおけるFLUSインターフェイス界面のシステム構成について説明する。
【００５８】
コンテンツ提供装置１３Ｂでは、DASH配信サーバ２２を備えるコンテンツ提供装置１３ＢがFLUSソースとなり、DASH配信サーバ２２を備えるCDN２３上にFLUSシンクが設けられる。ここでは、FLUSメディアに関する処理を、DASH配信サーバ２２CDN２３が行い、FLUSコントロールに関する処理を、コンテンツ提供装置１３Ｂおよびクラウド１２により提供されるFLUSコントローラが行うものとして説明する。
【００５９】
ステップＳ５１からステップＳ６４までは、図３のステップＳ１１からステップＳ２４までと同様の処理が、コンテンツ提供装置１３Ｂおよびクラウド１２のFLUSコントローラの間で行われる。
【００６０】
そして、ステップＳ６５において、DASH配信サーバ２２は、DASHセグメントおよびMPDの転送を開始する。
【００６１】
その後、DASH配信サーバ２２は、DASHセグメントおよびMPDの転送を開始し、ステップＳ６５において、AccessTokenおよびSessionIDとともに、DASH-Segment群およびMPDを送信する。このとき、ステップＳ６３で更新されたSessionResourceに格納することにより通知した内容と同様な内容をMPDに格納することによっても、当該DASH-SegmentのTranscodeDirectiveを通知することができる。
【００６２】
CDN２３は、ステップＳ６５で送信されてくるAccessTokenおよびSessionID、並びに、DASH-Segment群およびMPDを受信すると、ステップＳ６６において、それらの受信が成功したことを示すACK返答を行う。
【００６３】
以下、ストリームの配信が終了するまで、DASH配信サーバ２２とCDN２３との間で、ステップＳ６５およびＳ６６と同様の処理が繰り返して行われる。
【００６４】
そして、ストリームの配信が終了すると、ステップＳ６７からステップＳ７０まで、図３のステップＳ２７からステップＳ３０までと同様の処理が、コンテンツ提供装置１３Ｂおよびクラウド１２のFLUSコントローラの間で行われる。
【００６５】
以上のように、コンテンツ提供装置１３ＢのFLUSコントローラが、クラウド１２のFLUSコントローラから送信されてくるSessionResourceの内容を更新してクラウド１２のFLUSコントローラに送信するか、または、DASH配信サーバ２２が、クラウド１２上のCDN２３にMPDを送付するかの、いずれかにより、FLUSソース側が、当該DASH-SegmentのTranscodeDirectiveを、FLUSシンク側に通知することができる。
【００６６】
＜プロトコルの詳細例＞
図５乃至図１１を参照して、図３および図４のコンテンツ配信処理で用いられるプロトコルの詳細について説明する。例えば、APIはRESTful API（RESTの原則に則って構築されたWebシステムのHTTPでの呼び出しインターフェイス）により実装される。
【００６７】
図５の（ａ）に示すように、Service確立の要求（図３のステップＳ１３および図４のステップＳ５３）では、FLUSソースからFLUSシンクへHTTPメソッドが送信され、例えば、FLUSソース側からデータを送るためのHTTP POSTが送信される。このとき、ボディパートには、例えば、ServiceResourceが格納される。
【００６８】
そして、その要求に対する応答（図３のステップＳ１４および図４のステップＳ５４）では、FLUSシンクからFLUSソースへHTTPステータスコードが送信され、例えば、Service確立の要求が成功した結果新たなリソースが作成されたことを示すHTTP 201 CREATEDが送信される。このとき、locationヘッダには、例えば、FLUSシンクで更新されたServiceResourceのurlが格納される。また、図６に示すServiceResourceの一例のように、Service確立に成功した場合には、FLUSシンク側で生成されたServiceResourceのservice-idに割り当てられた値（ServiceID）が格納される。
【００６９】
図５の（ｂ）に示すように、ServiceResourceの要求（図３のステップＳ１５および図４のステップＳ５５）では、FLUSソースからFLUSシンクへHTTPメソッドが送信され、例えば、urlで指定した情報を要求するHTTP GETが送信される。このとき、HTTP GETでは、Service確立の応答で返されたFLUSシンクで更新されたServiceResourceのurlが指定される。
【００７０】
そして、その要求に対する応答（図３のステップＳ１６および図４のステップＳ５６）では、FLUSシンクからFLUSソースへHTTPステータスコードが送信され、例えば、ServiceResourceの要求が成功したことを示すHTTP 200 OKが送信される。このとき、ボディパートには、当該ServiceResourceが格納される。
【００７１】
図５の（ｃ）に示すように、ServiceResourceの更新（図３のステップＳ１７および図４のステップＳ５７）では、FLUSソースからFLUSシンクへHTTPメソッドが送信され、例えば、urlで指定したサーバ上のファイルを置き換えるHTTP PUTが送信される。このとき、ボディパートには、FLUSソースで更新したServiceResourceが格納される。
【００７２】
そして、その更新に対する応答（図３のステップＳ１８および図４のステップＳ５８）では、FLUSシンクからFLUSソースへHTTPステータスコードが送信され、例えば、ServiceResourceの更新が成功したことを示すHTTP 200 OKが送信される。このとき、ServiceResourceの更新に成功した場合、locationヘッダには、FLUSシンクで更新したServiceResourceのurlが格納される。
【００７３】
図５の（ｄ）に示すように、Session確立の要求（図３のステップＳ１９および図４のステップＳ５９）では、FLUSソースからFLUSシンクへHTTPメソッドが送信され、例えば、FLUSソース側からデータを送るためのHTTP POSTが送信される。このとき、ボディパートには、例えば、SessionResourceが格納される。
【００７４】
そして、その要求に対する応答（図３のステップＳ２０および図４のステップＳ６０）では、FLUSシンクからFLUSソースへHTTPステータスコードが送信され、例えば、Session確立の要求が成功した結果新たなリソースが作成されたことを示すHTTP 201 CREATEDが送信される。このとき、locationヘッダには、例えば、FLUSシンクで更新されたSessionResourceのurlが格納される。また、図７に示すSessionResourceの一例のように、Session確立に成功した場合には、FLUSシンク側で生成されたSessionResourceのSessione-idに割り当てられた値（SessionID）が格納される。
【００７５】
ここで、図７に示すように、SessionResourceには、『"FLUSシンクがFLUSソースからストリームを(Push/Pull)取得するための情報"』が記述され、図８に、その一例が示されている。
【００７６】
図８に示すように、この情報には、Pull取得の場合には、『"当該セッションストリームのMPDのURL"』が記述され、Push取得の場合には『"当該セッションストリームのSDP(Session Description Protocol)のURL"』が記述される。
【００７７】
さらに、図９には、図８に示す『"当該セッションストリームのSDP（Session Description Protocol）のURL"』におけるSDPの一例が示されている。例えば、SDPを利用してストリームを配信するとき、図９に示すように、SDPには、ビデオのセッション属性記述のパートにTranscodeDirectiveを配置できるように、新たなセッション属性a=transcodeDirectiveが導入される。
【００７８】
また、図９に示す『a=transcodeDirective: "TranscodeDirectiveの内容(XMLで記述されたTranscodeDirectiveの文字列をbase64エンコードしたもの)"』のバリエーションとして、TranscodeDirective情報構造(ファイル)のURLを格納する場合には、『a=transcodeDirective: "TranscodeDirectiveのURL(XMLで記述されたTranscodeDirectiveファイルのURL)"』が記載される。
【００７９】
なお、図９では、IETF（Internet Engineering Task Force）で規格定義されるSDPファイルをメタデータファイルとして用い、TranscodeDirectiveを、SDPの当該メディアセッションのメディア記述部に格納する一例を示したが、このバリエーションとして、図１０に示すように、FLUSの当該SessionResourceの中に格納してもよい。さらに、そのバリエーションとして、ファイルのurlの場合もある。
【００８０】
図１１の（ａ）に示すように、SessionResourceの要求（図３のステップＳ２１および図４のステップＳ６１）では、FLUSソースからFLUSシンクへHTTPメソッドが送信され、例えば、urlで指定した情報を要求するHTTP GETが送信される。このとき、HTTP GETにより、Session確立の応答で返されたFLUSシンクで更新されたSessionResourceのurlが指定される。
【００８１】
そして、その要求に対する応答（図３のステップＳ２２および図４のステップＳ６２）では、FLUSシンクからFLUSソースへHTTPステータスコードが送信され、例えば、SessionResourceの要求が成功したことを示すHTTP 200 OKが送信される。このとき、ボディパートには、当該SessionResourceが格納される。
【００８２】
図１１の（ｂ）に示すように、SessionResourceの更新（図３のステップＳ２３および図４のステップＳ６３）では、FLUSソースからFLUSシンクへHTTPメソッドが送信され、例えば、urlで指定したサーバ上のファイルを置き換えるHTTP PUTが送信される。このとき、ボディパートには、FLUSソースで更新したSessionResourceが格納される。
【００８３】
そして、その要求に対する応答（図３のステップＳ２４および図４のステップＳ６４）では、FLUSシンクからFLUSソースへHTTPステータスコードが送信され、例えば、SessionResourceの更新が成功したことを示すHTTP 200 OKが送信される。このとき、Service更新に成功した場合、locationヘッダには、FLUSシンクで更新したSessionResourceのurlが格納される。
【００８４】
図１１の（ｃ）に示すように、Sessionの解放（図３のステップＳ２７および図４のステップＳ６７）では、FLUSソースからFLUSシンクへHTTPメソッドが送信され、例えば、urlで指定したサーバ上のファイルを削除するHTTP DELETEが送信される。このとき、HTTP DELETEでは、SessionResourceのurlが指定される。
【００８５】
そして、その解放に対する応答（図３のステップＳ２８および図４のステップＳ６８）では、FLUSシンクからFLUSソースへHTTPステータスコードが送信され、例えば、Sessionの解放が成功したことを示すHTTP 200 OKが送信される。このとき、Sessionの解放に成功した場合、locationヘッダには、解放されたSessionResourceのurlが格納される。
【００８６】
図１１の（ｄ）に示すように、Serviceの解放（図３のステップＳ２９および図４のステップＳ６９）では、FLUSソースからFLUSシンクへHTTPメソッドが送信され、例えば、urlで指定したサーバ上のファイルを削除するHTTP DELETEが送信される。このとき、HTTP DELETEでは、ServiceResourceのurlが指定される。
【００８７】
そして、その解放に対する応答（図３のステップＳ３０および図４のステップＳ７０）では、FLUSシンクからFLUSソースへHTTPステータスコードが送信され、例えば、Serviceの解放が成功したことを示すHTTP 200 OKが送信される。このとき、Serviceの解放に成功した場合、locationヘッダには、解放されたServiceResourceのurlが格納される。
【００８８】
＜コンテンツ配信システムの各ブロックの構成例＞
図１２乃至図１７を参照して、コンテンツ配信システム１１を構成する各ブロックの構成例について説明する。なお、図１２に示すコンテンツ配信システム１１は、図１のコンテンツ配信システム１１Ａおよび図２のコンテンツ配信システム１１Ｂのどちらの構成にも対応する。即ち、コンテンツ配信システム１１Ａの構成では、ストリームソースサーバ２１とDASH配信サーバ２２との間でFLUSインターフェイスが利用され、コンテンツ配信システム１１Ｂの構成では、DASH配信サーバ２２とCDN２３−１およびCDN２３−２との間でFLUSインターフェイスが利用される。
【００８９】
図１２に示すように、コンテンツ配信システム１１では、ストリームソースサーバ２１にDASH配信サーバ２２が接続され、DASH配信サーバ２２にストリーミング配信マネジャ３１が接続されている。例えば、DASH配信サーバ２２からストリーミング配信マネジャ３１へ、オリジナルのMPDが供給され、ストリーミング配信マネジャ３１からDASH配信サーバ２２へ、TranscodeDirectiveが追記されたMPDが戻される。
【００９０】
また、図１２に示すコンテンツ配信システム１１では、２つのベンダにより提供されるCDN２３−１およびCDN２３−２を利用してコンテンツを配信する例が示されており、CDN２３−１およびCDN２３−２は、多段のCDNサーバ４１により構成されている。そして、DASH配信サーバ２２から、CDN２３−１のCDNオリジンサーバ４１ａ−１およびCDN２３−２のCDNオリジンサーバ４１ａ−２それぞれへ、MPDおよびセグメントが送信される。
【００９１】
CDN２３−１は、CDNオリジンサーバ４１ａ−１、図示しない多段のCDN中継サーバ、およびCDNエッジサーバ４１ｂ−１により構成される。DASH配信サーバ２２からCDNオリジンサーバ４１ａ−１へ供給されたMPDおよびセグメントは、図示しない多段のCDN中継サーバを介して、CDNエッジサーバ４１ｂ−１へ至る。そして、CDNエッジサーバ４１ｂ−１からDASHプレイヤ１４−１および１４−２それぞれへ、MPDおよびセグメントが送信され、コンテンツが再生される。
【００９２】
CDN２３−２は、CDNオリジンサーバ４１ａ−２、図示しない多段のCDN中継サーバ、およびCDNエッジサーバ４１ｂ−２により構成され、CDNエッジサーバ４１ｂ−２は、トランスコーダ４２およびトランスコードマネジャ４３を有している。DASH配信サーバ２２からCDNオリジンサーバ４１ａ−２へ供給されたMPDおよびセグメントは、図示しない多段のCDN中継サーバを介して、CDNエッジサーバ４１ｂ−２へ至る。
【００９３】
CDNエッジサーバ４１ｂ−２では、TranscodeDirectiveが追記されたMPDと、トランスコード前のセグメントとが、トランスコーダ４２に入力される。そして、CDNエッジサーバ４１ｂ−２では、トランスコード後のセグメントを参照するように変更されたMPDと、トランスコード済みのセグメントとが、トランスコーダ４２から出力される。そして、CDNエッジサーバ４１ｂ−２からDASHプレイヤ１４−３へ、トランスコード後のセグメントを参照するように変更されたMPDと、トランスコード済みのセグメントとが送信される。従って、DASHプレイヤ１４−３は、このように配信されるコンテンツを取得して、再生する。
【００９４】
図１３は、ストリームソースサーバ２１の構成例を示すブロック図である。
【００９５】
図１３に示すように、ストリームソースサーバ２１は、ビデオ入力部５１、オーディオ入力部５２、ストリーム生成／記憶部５３、ストリーム配信部５４、メタデータ生成／記憶部５５、およびメタデータ配信部５６を備えて構成される。
【００９６】
ビデオ入力部５１には、例えば、図示しない撮像装置により撮像されたビデオデータが入力され、オーディオ入力部５２には、例えば、図示しない収音装置により集音されたオーディオデータが入力される。
【００９７】
ストリーム生成／記憶部５３は、ビデオ入力部５１から供給されるビデオデータと、オーディオ入力部５２から供給されるオーディオデータとに基づいてストリームを生成し、記憶する。
【００９８】
ストリーム配信部５４は、ストリーム生成／記憶部５３からストリームを読み出して、DASH配信サーバ２２へ配信する。
【００９９】
メタデータ生成／記憶部５５は、ストリーム生成／記憶部５３に記憶されているストリームのメタデータを生成し、記憶する。
【０１００】
メタデータ配信部５６は、メタデータ生成／記憶部５５からメタデータを読み出して、DASH配信サーバ２２へ配信する。
【０１０１】
図１４は、ストリーミング配信マネジャ３１の構成例を示すブロック図である。
【０１０２】
図１４に示すように、ストリーミング配信マネジャ３１は、TranscodeDirective生成部６１を備えて構成される。
【０１０３】
TranscodeDirective生成部６１は、例えば、トランスコーダ４２においてトランスコードを行う際の制御や条件等を記述するTranscodeDirective（定義情報）を生成する。そして、TranscodeDirective生成部６１は、生成したTranscodeDirectiveを、DASH配信サーバ２２から供給されるオリジナルのMPDに追記して、DASH配信サーバ２２へ供給する。
【０１０４】
図１５は、DASH配信サーバ２２の構成例を示すブロック図である。
【０１０５】
図１５に示すように、DASH配信サーバ２２は、メタデータ取得／記憶部７１、ストリーム取得／記憶部７２、セグメント生成部７３、MPD生成部７４、セグメント配信部７５、およびMPD配信部７６を備えて構成される。
【０１０６】
メタデータ取得／記憶部７１は、ストリームソースサーバ２１のメタデータ配信部５６から供給されるメタデータを取得し、そのメタデータを記憶する。そして、メタデータ取得／記憶部７１は、メタデータをストリーム取得／記憶部７２およびMPD生成部７４に供給する。
【０１０７】
ストリーム取得／記憶部７２は、ストリームソースサーバ２１のストリーム配信部５４から供給されるストリームを取得し、そのストリームを記憶する。また、ストリーム取得／記憶部７２は、メタデータ取得／記憶部７１から供給されるメタデータに基づいてストリームをエンコードして、そのストリームで配信されるコンテンツをセグメント生成部７３に供給する。
【０１０８】
セグメント生成部７３は、ストリーム取得／記憶部７２から供給されるコンテンツから、MPEG-DASHに従ったセグメントを生成してセグメント配信部７５に供給するとともに、そのセグメントのMPDの生成をMPD生成部７４に要求する。
【０１０９】
MPD生成部７４は、メタデータ取得／記憶部７１から供給されるメタデータに基づいて、セグメント生成部７３において生成されたセグメントについてのオリジナルのMPDを生成（メディアデータのURLを格納）し、そのMPDをストリーミング配信マネジャ３１に供給する。そして、MPD生成部７４は、ストリーミング配信マネジャ３１においてTranscodeDirectiveが追記されたMPDを受け取って、MPD配信部７６へ供給する。
【０１１０】
セグメント配信部７５は、セグメント生成部７３から供給されるセグメントを、CDN２３へ配信する。
【０１１１】
MPD配信部７６は、MPD生成部７４から供給されるMPDを、CDN２３へ配信する。
【０１１２】
図１６は、CDN２３を構成するCDNサーバ４１の構成例を示すブロック図である。なお、図１２のCDNオリジンサーバ４１ａ、図示しないCDN中継サーバ、およびCDNエッジサーバ４１ｂは、それぞれCDNサーバ４１と同様の構成となっている。
【０１１３】
図１６に示すように、CDNサーバ４１は、MPD取得部８１、セグメント取得部８２、MPD記憶部８３、トランスコード制御部８４、トランスコード処理部８５、セグメント記憶部８６、MPD配信部８７、およびセグメント配信部８８を備えて構成される。
【０１１４】
MPD取得部８１は、DASH配信サーバ２２のMPD配信部７６から配信されるTranscodeDirectiveが追記されたMPDを取得し、セグメント取得部８２およびMPD記憶部８３に供給する。
【０１１５】
セグメント取得部８２は、DASH配信サーバ２２のセグメント配信部７５から配信されるセグメントを取得し、セグメント記憶部８６に供給する。
【０１１６】
MPD記憶部８３は、MPD取得部８１により取得されたTranscodeDirectiveが追記されたMPD、および、トランスコード制御部８４により更新済みのTranscodeDirectiveが追記されたMPDを記憶する。
【０１１７】
トランスコード制御部８４は、MPD記憶部８３からTranscodeDirectiveが追記されたMPDを読み出して、そのMPDを解析し、TranscodeDirectiveの解析を行う。そして、トランスコード制御部８４は、解析の結果に従ってMPDを更新し、TranscodeDirectiveが追記されたMPDに戻すとともに、更新されたMPDに基づいて、トランスコード処理部８５によるセグメントのトランスコードを制御する。例えば、トランスコード制御部８４は、MPDにTranscodeDirective要素が格納されている場合（後述する図２４参照）には、そのTranscodeDirective要素に基づいてトランスコードを制御する。または、トランスコード制御部８４は、MPDにTranscodeDirectiveファイルのURLが格納されている場合（後述する図２５参照）には、そのTranscodeDirectiveファイルのURLに基づいてTranscodeDirectiveをリクエストするのに応じて受信されたTranscodeDirective要素に基づいてトランスコードを制御する。
【０１１８】
トランスコード処理部８５は、セグメント記憶部８６からセグメントを読み出し、トランスコード制御部８４による制御に従ってトランスコードし、トランスコード済みのセグメントをセグメント記憶部８６に戻す。
【０１１９】
セグメント記憶部８６は、セグメント取得部８２により取得されたセグメント、および、トランスコード処理部８５によりトランスコード済みのセグメントを記憶する。
【０１２０】
MPD配信部８７は、トランスコード制御部８４により更新済みのTranscodeDirectiveが追記されたMPDをMPD記憶部８３から読み出して、DASHプレイヤ１４へ配信する。
【０１２１】
セグメント配信部８８は、トランスコード済みのセグメントをセグメント記憶部８６から読み出して、DASHプレイヤ１４へ配信する。
【０１２２】
図１７は、DASHプレイヤ１４の構成例を示すブロック図である。
【０１２３】
図１７に示すように、DASHプレイヤ１４は、MPD取得部９１、プレイヤ制御部９２、インタラクション処理部９３、セグメント取得部９４、セグメント処理部９５、およびレンダリング処理部９６を備えて構成される。
【０１２４】
MPD取得部９１は、CDNサーバ４１のMPD配信部８７から配信されるMPDを取得して、プレイヤ制御部９２へ供給する。
【０１２５】
プレイヤ制御部９２は、MPD取得部９１から供給されるMPD（CDNサーバ４１で更新済みのTranscodeDirectiveが追記されたMPD）に従って、セグメント取得部９４、セグメント処理部９５、およびレンダリング処理部９６に対する制御を行う。このとき、プレイヤ制御部９２は、インタラクション処理部９３により取得されるユーザのインタラクション（例えば、DASHプレイヤ１４がヘッドマウントディスプレイの場合にはユーザの顔の向きなど）に応じてコンテンツの再生を制御する。
【０１２６】
インタラクション処理部９３は、図示しない入力部に入力される各種の情報（例えば、DASHプレイヤ１４がヘッドマウントディスプレイの場合には向きを示す情報など）に対する処理を行って、DASHプレイヤ１４に対するユーザのインタラクションを取得し、プレイヤ制御部９２に供給する。
【０１２７】
セグメント取得部９４は、CDNサーバ４１のセグメント配信部８８から配信されるセグメントを取得し、プレイヤ制御部９２による制御に従って、DASHプレイヤ１４でコンテンツを再生するのに必要なセグメントをセグメント処理部９５に供給する。
【０１２８】
セグメント処理部９５は、プレイヤ制御部９２による制御に従って、セグメント取得部９４から供給されるセグメントに対する処理を行って、コンテンツを再生してレンダリング処理部９６に供給する。
【０１２９】
レンダリング処理部９６は、プレイヤ制御部９２による制御に従って、セグメント処理部９５から供給されるコンテンツに対するレンダリングを行って、図示しない出力部に出力して、コンテンツを表示させる。
【０１３０】
ここで、上述したようなストリームソースサーバ２１、ストリーミング配信マネジャ３１、DASH配信サーバ２２、CDNサーバ４１、およびDASHプレイヤ１４により構成されるコンテンツ配信システム１１におけるコンテンツ配信処理について詳細に説明する。
【０１３１】
例えば、コンテンツ配信システム１１で放送ストリームを配信する場合、ストリームソースサーバ２１には、番組やコマーシャルなどが蓄積されている。そして、図１２に示したように、ストリームソースサーバ２１から配信されるストリームは、DASH配信サーバ２２を経由し、配信サービスプロバイダが提供するCDN２３を構成する複数のCDNサーバ４１のうちの、CDNオリジンサーバ４１ａから多段のCDN中継サーバを介してCDNエッジサーバ４１ｂに至り、最終的にDASHプレイヤ１４で再生される。
【０１３２】
このとき、DASH配信サーバ２２では、MPD生成部７４（図１５）が、生成したオリジナルのMPDをいったんストリーミング配信マネジャ３１に渡す。そして、ストリーミング配信マネジャ３１では、TranscodeDirective生成部６１（図１４）が、そのストリームの配信ポリシーに基づいて、適宜MPDを改変してMPD生成部７４に戻す。
【０１３３】
このとき、TranscodeDirective生成部６１は、例えば、ストリームのCDN２３におけるトランスコードに係る制御や条件等を記述するTranscodeDirective要素を、AdaptationSet要素に追加することによりMPDを改変する。そこには、サービサーやオーサー側が認めた変換後プロファイルの候補などをシンプルに表現する形式が用いられる。さらには、図１６のCDNサーバ４１で行われるデコード、レンダリング、または再エンコード処理において制限したい内容があれば、それらを的確に表現する形式であることが必要となる。
【０１３４】
即ち、CDNサーバ４１におけるトランスコード処理の過程で、エンコードされたオリジナルのストリームをいったんベースバンドストリームに戻してから再エンコードする際に、以下に示すような宣言を行えるようにすることが望まれる。
【０１３５】
まず、第１に、様々な画像補正をかけてアップスケーリングするケースが増えてくるが、そのような処理を可能とするか否かを宣言できることが望まれる。また、第２に、アップスケーリングの処理方法として、単純な空間解像度または時間解像度の整数倍変換のみならず、様々なアップスケーリングの処理パターン（後述する図３５乃至図３８参照）を認めるか否かを宣言できることが望まれる。
【０１３６】
さらに、第３に、viewport dependentなスケーリングやエンコーディングを行うケースも増えてくると思われるが、そのようなpartialなトランスコード処理を可能とするか否かを宣言できることが望まれる。また、第４に、トランスコードが行われる際に上限とする最大遅延時間や、品質差分の上限（例えば、オリジナルのベースバンドデータとの乖離）等のトランスコード処理の可否制御における条件記述を宣言できることが望まれる。
【０１３７】
そして、第５に、そういった処理がなされた場合に、オーサー側にフィードバックレポートする機能が必要となるが、その際のNotificationメッセージの構造、URL等といった内容を宣言できることが望まれる。ここでは、例えば、CDN２３の内部や、複数のCDN２３をまたぐとき、ユーザ近傍のCDNエッジサーバ４１ｂ等のどの段階で、どういった処理が行われたかをフィードバックレポートすることが想定される。
【０１３８】
このような内容が記述されたTranscodeDirective要素が追記されて改変されたMPDとDASHセグメントとが、図１２のCDN２３−１およびCDN２３−２に渡され、多段のCDNサーバ４１を介してCDNエッジサーバ４１ｂに転送される。そして、DASHプレイヤ１４は、所望のMPDを取得するとHTTPを利用してCDNエッジサーバ４１ｂ上のセグメントをフェッチする。なお、CDN２３の内部では、HTTPや、DASHセグメント以外の、プロトコルやフォーマットにより、セグメンタからCDNエッジサーバ４１ｂに配信されることもある。また、CDNエッジサーバ４１ｂは、例えば、より上段のCDNサーバ４１からHTTPにより所望のセグメントをPULL取得することもある。
【０１３９】
ここで、CDNエッジサーバ４１ｂを経由して、DASHプレイヤ１４がMPDを取得する場合、CDNエッジサーバ４１ｂとDASHプレイヤ１４との間のネットワークの状態や、個々のDASHプレイヤ１４のエンドユーザの視聴嗜好等に基づいてセグメントのエンコード方式を変更することがある。こういったトランスコードは、CDN２３の内部のCDNエッジサーバ４１ｂ上で、負荷状態に応じて適宜負荷分散しながら実行される。
【０１４０】
例えば、一般のVoD（Video On Demand）ストリーミングにおいては、CDNオリジンサーバ４１ａにおいて、配信が開始される前に、とあるコンテンツの複数ビットレートストリームを生成してから、ユーザリクエストに応じて配信してもよい。または、レスポンスのパフォーマンスを向上させるため、クライアントからのリクエストがなされる前に、CDNエッジサーバ４１ｂ（または、配信経路上の中間ノードとなるCDN中継サーバ）に事前配信（プリフェッチまたはプッシュ配信）しておいてもよい。
【０１４１】
ここで、CDNエッジサーバ４１ｂ（以降、配信経路上の中間ノード（CDN中継サーバ）を含めて、CDNエッジサーバ４１ｂとの表現を用いる）が、クライアントからのリクエストの傾向を事前に把握（想定）できる場合には、あらかじめ、オリジナルのストリームをもとに、クライアントの再生または視聴の嗜好を考慮にいれて、ストリーミングの品質（画音質からレスポンスパフォーマンスを含む）に対する改善を施すことが可能となる。例えば、CDNエッジサーバ４１ｂにアクセスするクライアント群からのリクエストの過去の統計から予測されるDASHプレイヤ１４の再生能力やコーデックの種類等に基づいて、CDNエッジサーバ４１ｂにおけるストリーミングの品質改善が施される。
【０１４２】
また、オーサー側からROI（Region Of Interest）メタデータ等が提供され、あらかじめクライアントが要求しそうな画像上の領域（ROIが同一画像上に複数あることも想定）を特定することが可能な場合には、CDNエッジサーバ４１ｂにて、それらのROI領域を中心にアップスケーリングを施してからエンコードし直すこともある。このような場合には、例えば、最初の数セグメントについてはクライアントからのリクエストがばらつく（ROI領域がそれぞれのクライアント毎に異なる）ことを想定して、トランスコード済みセグメントの複数のバージョンを準備する。そして、クライアントからのリクエストが定常状態に落ち着いた後に、後続のセグメント（最初のバリエーションのうちのサブセット、即ち、同一画像上の複数ROIのうちのサブセットを中心に）をトランスコードすることにより、CDNエッジサーバ４１ｂのキャッシュ領域を大幅にセーブすることも可能となる。
【０１４３】
このようなフレキシブルなトランスコードを制御するため、CDNエッジサーバ４１ｂにトランスコードマネジャ４３を実装する。トランスコードマネジャ４３は、DASHプレイヤ１４との間のネットワークの負荷状況を把握したり、CDNエッジサーバ４１ｂの負荷状況を考慮に入れながら、DASHプレイヤ１４に渡したMPDとそれに基づくリクエストについての知識を利用して、CDNエッジサーバ４１ｂに実装されるトランスコーダ４２に対してセグメントのトランスコードを指示する。
【０１４４】
また、トランスコードマネジャ４３は、MPDに記述されるTranscodeDirectiveの内容をパースし、そこに記述されるトランスコード処理に関わる様々な制約または条件に基づいて、トランスコーダ４２に対して当該セグメントについてのトランスコードを指示する。そして、トランスコードマネジャ４３は、トランスコーダ４２においてトランスコード処理が行われると、TranscodeDirectiveに記載されたレポートバックURLに、レポートメッセージを送付する。
【０１４５】
さらに、トランスコードマネジャ４３は、MPDの内容を更新し、オリジナルのセグメント参照から、トランスコードがなされたセグメント参照へと変更する。ここで、後述する、viewportを考慮にいれたセグメントの部分的な変更のように、MPDの内容の更新を伴わない場合、即ち、アップスケーリングによるパラメタ改変がファイルフォーマットレベルにクローズしている（例えば、MPDに染み出していない）場合、オリジナルのセグメント参照のままで、セグメントの内容のみが変更されることがある。この場合は、クライアントにはMPDの更新取得を促す必要はない。
【０１４６】
DASHプレイヤ１４は、このようなトランスコードがなされたセグメントを参照するように変更されたMPDを取得し、そのMPDに基づいてセグメントを取得して再生する。
【０１４７】
図１８を参照して、図１２のコンテンツ配信システム１１で行われるコンテンツ配信処理において、DASH配信サーバ２２およびストリーミング配信マネジャ３１、CDNサーバ４１（主にCDNエッジサーバ４１ｂのトランスコーダ４２およびトランスコードマネジャ４３）、並びに、DASHプレイヤ１４で行われる処理について説明する。
【０１４８】
ステップＳ１０１において、DASH配信サーバ２２では、ストリームソースサーバ２１から配信されるストリームをストリーム取得／記憶部７２が受信してエンコードし、セグメント生成部７３がセグメントを生成する。そして、ストリーミング配信マネジャ３１は、TranscodeDirectiveが追記されたMPDを生成する。このとき、ストリーミング配信マネジャ３１は、例えば、TranscodeDirectiveの内容がFLUSインターフェイスを介したメタデータとして上流側から提供される場合、上述の図９に示したようなTranscodeDirectiveの内容をMPDに挿入する。または、ストリーミング配信マネジャ３１は、TranscodeDirectiveに替えて、上述したように、TranscodeDirectiveファイルのURLをMPDに挿入してもよい。
【０１４９】
ステップＳ１０２において、CDNサーバ４１は、DASH配信サーバ２２に対してMPDおよびセグメントの取得を要求する。
【０１５０】
DASH配信サーバ２２は、ステップＳ１０２におけるCDNサーバ４１からの要求を取得すると、ステップＳ１０３において、TranscodeDirectiveが追記されたMPDとセグメントとの転送を開始する。
【０１５１】
ステップＳ１０４において、トランスコードマネジャ４３は、リクエスト処理状況の計測を行う。
【０１５２】
CDNサーバ４１が、ステップＳ１０３でDASH配信サーバ２２から転送されてくるTranscodeDirectiveが追記されたMPDとセグメントとを受信すると、ステップＳ１０５において、トランスコードマネジャ４３は、TranscodeDirectiveが追記されたMPDをパースする。そして、トランスコードマネジャ４３は、TranscodeDirectiveの解析を行い、その解析結果に従って、トランスコーダ４２に対するトランスコードを指示する。
【０１５３】
トランスコーダ４２は、トランスコードマネジャ４３によるトランスコード指示に従って、ステップＳ１０６においてセグメントをデコードし、ステップＳ１０７においてアップスケーリングを行い、ステップＳ１０８においてセグメントをエンコードする。そして、ステップＳ１０９において、トランスコーダ４２は、トランスコード済みのセグメントを参照するMPDを生成する。
【０１５４】
ステップＳ１１０において、DASHプレイヤ１４は、CDNサーバ４１に対してMPDの取得を要求する。
【０１５５】
CDNサーバ４１は、ステップＳ１１０におけるDASHプレイヤ１４からの要求を受信すると、ステップＳ１１１において、トランスコード済みのセグメントを参照するMPDをDASHプレイヤ１４に転送する。
【０１５６】
DASHプレイヤ１４は、ステップＳ１１１で転送されてくるトランスコード済みのセグメントを参照するMPDを取得すると、ステップＳ１１２において、そのMPDをパースする。そして、DASHプレイヤ１４は、CDNサーバ４１に対してセグメントを要求する。
【０１５７】
CDNサーバ４１は、ステップＳ１１２におけるDASHプレイヤ１４からの要求を取得すると、ステップＳ１１３において、DASHプレイヤ１４により要求されたトランスコード済みのセグメントの転送を行う。
【０１５８】
DASHプレイヤ１４は、ステップＳ１１３で転送されてくるトランスコード済みのセグメントを受信すると、ステップＳ１１４において、その受信したトランスコード済みのセグメントの再生を行う。
【０１５９】
その後、コンテンツの配信が終了するまで、トランスコード済みのセグメントの転送と、その再生が継続して行われる。
【０１６０】
以上のように、ストリーミング配信マネジャ３１が、TranscodeDirectiveが追記されたMPDを生成することで、トランスコードマネジャ４３は、そのMPDをパースして、TranscodeDirectiveを解析し、トランスコードを指示することができる。
【０１６１】
なお、ここでは、CDNサーバ４１側からDASH配信サーバ２２に対してMPDやセグメントの取得を要求する例を示したが、例えば、DASH配信サーバ２２側からプッシュ風にCDNサーバ４１に対してMPDやセグメントを転送してもよい。または、DASHプレイヤ１４が最初にMPDの要求を行って、その要求に従ってCDNサーバ４１からMPDやセグメントを転送するようにボトムアップでフローが開始されてもよい。このようなパターンも含めて、後述する図２１乃至図２３には、ライブストリーミングの際に起こりうる可能性のあるMPDが動的に更新される場合における処理の例を示す。
【０１６２】
ここで、図１９には、図１８のステップＳ１０１において、TranscodeDirectiveの内容がFLUSインターフェイスを介したメタデータ（SDP）として渡される場合の対応関係が示されている。即ち、SDPに記載されるTranscodeDirectiveと、MPDに挿入されるTranscodeDirectiveとの間には、図１９に示すような対応関係がある。同様に、ストリームソースサーバ２１からのストリームと、DASH配信サーバ２２より後段のクラウド１２上のストリームとの間には、図１９に示すような対応関係がある。
【０１６３】
図２０は、ストリーミング配信マネジャ３１がクラウド１２上に設けられるバリエーションのコンテンツ配信システム１１Ｂの構成例を示すブロック図である。
【０１６４】
図２０に示すように、コンテンツ配信システム１１Ｂは、TranscodeDirectiveの内容をMPDに追加するストリーミング配信マネジャ３１が、コンテンツ提供装置１３のDASH配信サーバ２２と、クラウド１２上のCDN２３との間に配置されて構成される。従って、コンテンツ配信システム１１Ｂでは、コンテンツ提供装置１３Ｂと、ストリーミング配信マネジャ３１およびCDN２３と間で、FLUSインターフェイスが利用される。なお、このように構成されるコンテンツ配信システム１１Ｂでは、MPDには、TranscodeDirectiveが記載されていないパターンと、すでに記載されているパターンとがある。
【０１６５】
図２１を参照して、図２０に示すように構成されるコンテンツ配信システム１１Ｂにおけるコンテンツ配信処理について説明する。
【０１６６】
ステップＳ１３１において、図１８のステップＳ１０１と同様に、DASH配信サーバ２２では、ストリームソースサーバ２１から供給されるストリームがエンコードされて、セグメントが生成される。
【０１６７】
ステップＳ１３２において、CDNサーバ４１は、DASH配信サーバ２２に対してMPDおよびセグメントの取得を要求する。
【０１６８】
DASH配信サーバ２２は、ステップＳ１３２におけるCDNサーバ４１からの要求を取得すると、ステップＳ１３３において、ストリーミング配信マネジャ３１に対するMPDとセグメントとの転送を開始する。
【０１６９】
ストリーミング配信マネジャ３１は、ステップＳ１３３で転送されてくるMPDとセグメントとを受信すると、ステップＳ１３４において、TranscodeDirectiveのMPDへの挿入を行う。そして、ストリーミング配信マネジャ３１は、CDNサーバ４１に対して、TranscodeDirectiveが追記されたMPDとセグメントとの転送を開始する。
【０１７０】
その後、図１８のステップＳ１０５以降と同様の処理により、コンテンツの配信が行われる。
【０１７１】
このように、ストリーミング配信マネジャ３１がクラウド１２上に設けられる構成では、DASH配信サーバ２２からストリーミング配信マネジャ３１を介してCDNサーバ４１へ、TranscodeDirectiveが追記されたMPDおよびセグメントが配信される。
【０１７２】
図２２を参照して、図１２のコンテンツ配信システム１１において、トランスコード済みセグメントを参照するMPDをクライアントに通知してセグメントを取得させるコンテンツ配信処理について説明する。
【０１７３】
ステップＳ１５１において、図１８のステップＳ１０１と同様に、DASH配信サーバ２２では、ストリームソースサーバ２１から供給されるストリームがエンコードされて、セグメントが生成される。さらに、DASH配信サーバ２２では、MPD生成部７４が、オリジナルのMPDを生成する。
【０１７４】
ステップＳ１５２において、DASH配信サーバ２２は、ステップＳ１５１で生成したMPDおよびセグメントを転送し、CDNサーバ４１において取得される。
【０１７５】
ステップＳ１５３において、DASHプレイヤ１４は、CDNサーバ４１に対してMPDの取得を要求する。
【０１７６】
CDNサーバ４１は、ステップＳ１５３におけるDASHプレイヤ１４からの要求を受信すると、ステップＳ１５４において、ステップＳ１５２で取得していたMPDをDASHプレイヤ１４に転送する。
【０１７７】
DASHプレイヤ１４は、ステップＳ１５４で転送されてくるMPDを取得すると、ステップＳ１５５において、そのMPDをパースする。そして、DASHプレイヤ１４は、CDNサーバ４１に対してセグメントを要求する。
【０１７８】
CDNサーバ４１は、ステップＳ１５５におけるDASHプレイヤ１４からの要求を取得すると、ステップＳ１５６において、DASHプレイヤ１４により要求されたセグメントの転送を行う。
【０１７９】
DASHプレイヤ１４は、ステップＳ１５６で転送されてくるセグメントを受信すると、ステップＳ１５７において、その受信したセグメントの再生を行う。
【０１８０】
ステップＳ１５８において、トランスコードマネジャ４３は、リクエスト処理状況の計測を行う。
【０１８１】
ステップＳ１５９において、DASH配信サーバ２２は、MPDを更新して転送、即ち、ストリーミング配信マネジャ３１によりTranscodeDirectiveが追記されたMPDをCDNサーバ４１へ転送する。
【０１８２】
CDNサーバ４１が、ステップＳ１５９でDASH配信サーバ２２から転送されてくるTranscodeDirectiveが追記されたMPDとセグメントとを受信すると、処理はステップＳ１６０において、トランスコードマネジャ４３は、TranscodeDirectiveが追記されたMPDをパースする。そして、トランスコードマネジャ４３は、TranscodeDirectiveの解析を行い、その解析結果に従って、トランスコーダ４２に対するトランスコードを指示する。
【０１８３】
トランスコーダ４２は、トランスコードマネジャ４３によるトランスコード指示に従って、ステップＳ１６１においてセグメントをデコードし、ステップＳ１６２においてアップスケーリングを行い、ステップＳ１６３においてセグメントをエンコードする。そして、ステップＳ１６４において、トランスコーダ４２は、トランスコード済みのセグメントを参照するMPDを生成する。
【０１８４】
ステップＳ１６５において、CDNサーバ４１は、MPDが更新されたことをDASHプレイヤ１４に対して通知する。
【０１８５】
ステップＳ１６６において、DASHプレイヤ１４は、ステップＳ１６５でのCDNサーバ４１からの通知に応じて、CDNサーバ４１に対してMPDの取得を要求する。
【０１８６】
CDNサーバ４１は、ステップＳ１６６におけるDASHプレイヤ１４からの要求を受信すると、ステップＳ１６７において、トランスコード済みのセグメントを参照するMPDをDASHプレイヤ１４に転送する。
【０１８７】
DASHプレイヤ１４は、ステップＳ１６７で転送されてくるトランスコード済みのセグメントを参照するMPDを取得すると、ステップＳ１６８において、そのMPDをパースする。そして、DASHプレイヤ１４は、次のセグメントとして、CDNサーバ４１に対してトランスコード済みのセグメントを要求する。
【０１８８】
CDNサーバ４１は、ステップＳ１６８におけるDASHプレイヤ１４からの要求を取得すると、ステップＳ１６９において、DASHプレイヤ１４により要求されたトランスコード済みのセグメントの転送を行う。
【０１８９】
DASHプレイヤ１４は、ステップＳ１６９で転送されてくるトランスコード済みのセグメントを受信すると、ステップＳ１７０において、その受信したトランスコード済みのセグメントの再生を行う。
【０１９０】
その後、コンテンツの配信が終了するまで、トランスコード済みのセグメントの転送と、その再生が継続して行われる。
【０１９１】
以上のように、CDNサーバ４１からDASHプレイヤ１４へ、MPDが更新されたことを通知し、その通知に応じて、DASHプレイヤ１４が、トランスコード済みのセグメントを参照するMPDを取得し、トランスコード済みのセグメントを再生することができる。
【０１９２】
図２３を参照して、図１２のコンテンツ配信システム１１において、トランスコード前のセグメントのURLをトランスコード済みセグメントのURLに流用してクライアントにセグメントを取得させるコンテンツ配信処理について説明する。
【０１９３】
ステップＳ２０１からステップＳ２１３までは、図２２のステップＳ１５１からステップＳ１６３までと同様の処理が行われる。
【０１９４】
そして、ステップＳ２１４において、DASHプレイヤ１４は、次のセグメントを要求する。
【０１９５】
このとき、トランスコード前のセグメントのURLがトランスコード済みセグメントのURLに流用されており、ステップＳ２１４でDASHプレイヤ１４が要求したURLのセグメントは、トランスコード済みセグメントにより置き換えられている。
【０１９６】
従って、ステップＳ２１５において、CDNサーバ４１は、DASHプレイヤ１４の要求に応じて、トランスコード済みのセグメントの転送を行う。
【０１９７】
DASHプレイヤ１４は、ステップＳ２１５で転送されてくるトランスコード済みのセグメントを受信すると、ステップＳ２１６において、その受信したトランスコード済みのセグメントの再生を行う。
【０１９８】
以上のように、トランスコード前のセグメントのURLをトランスコード済みセグメントのURLに流用することで、例えば、トランスコード後のセグメントを参照するように変更されたMPDをDASHプレイヤ１４に転送しなくても、DASHプレイヤ１４は、トランスコード済みセグメントを取得することができる。
【０１９９】
＜TranscodeDirectiveの構造＞
図２４乃至図３３を参照して、CDNサーバ４１（主にCDNエッジサーバ４１ｂ）において、解析または可否の判定に用いられるメタデータであるTranscodeDirectiveの構造について説明する。
【０２００】
例えば、ストリーミングサービスのマニフェストとしてDASH-MPDを利用する場合には、このメタデータがトランスコードの対象となるAdaptationSet要素（または、Representation要素、SubRepresentation要素）に追記される。なお、トランスコードマネジャ４３は、要素や値が複数記載できるものに関して、最適なものを選択することができる。
【０２０１】
図２４には、DASH-MPDへのTranscodeDirective要素の配置例が示されている。例えば、TranscodeDirective要素は、単独のファイルとして記憶され、図２４に示すように、AdaptationSet要素に追記するように、<TranscodeDirective...>から</TranscodeDirective>の間に、TranscodeDirective要素を配置することができる。
【０２０２】
また、図２５には、DASH-MPDへのTranscodeDirective要素の配置のバリエーションの一例が示されている。図２５に示すように、AdaptationSet要素に追記するように、TranscodeDirectiveファイルのURLを配置することができる。
【０２０３】
以下では、TranscodeDirective要素の詳細について説明する。
【０２０４】
図２６の（ａ）に示すように、transcodable属性により、トランスコード可能か否かがtrueまたはfalseにより指定される。例えば、TranscodeDirective要素にtranscodable属性のみが存在し、かつ、transcodable属性によりtrueと指定された場合には、任意のパターンのトランスコードが可能であることを示す。逆に、transcodable属性によりfalseと指定された場合には、一切のトランスコード処理が禁止であることを示す。
【０２０５】
そして、transcodable属性において、トランスコードが可能であることが示されているとき、以下の属性が存在できる。
【０２０６】
図２６の（ｂ）に示すように、upScalable属性により、トランスコードの際にアップスケール可能か否かがtrueまたはfalseにより指定される。例えば、transcodable属性においてtrueが指定されているときにupScalable属性のみが存在し、かつ、upScalable属性によりtrueと指定された場合には、再エンコードした後に、任意のパターンのアップスケーリングが可能であることを示す。逆に、upScalable属性のみが存在し、かつ、upScalable属性によりfalseと指定された場合には、再エンコードの前に一切のアップスケーリングが禁止であることを示す。
【０２０７】
図２６の（ｃ）に示すように、processingLimit属性により、トランスコードの処理にかかる時間の上限値である遅延最大時間が指定される。
【０２０８】
図２６の（ｄ）に示すように、Allowed要素により、再エンコードの際に選択可能なコーデックパラメタとして、Parameters/VideoおよびParameters/Audioのうちの少なくとも一方が指定（複数可）される。なお、Allowed要素において『/Parameters/"他のメディアタイプ"』のように指定することで、他のメディアタイプを選択可能とすることも包含するように拡張することができる。
【０２０９】
図２６の（ｅ）に示すように、Prohibited要素により、再エンコードの際に選択不可能なコーデックパラメタとして、Parameters/VideoおよびParameters/Audioのうちの少なくとも一方が指定（複数可）される。なお、Prohibited要素において『/Parameters/"他のメディアタイプ"』のように指定することで、他のメディアタイプを選択不可能とすることも包含するように拡張することができる。
【０２１０】
図２６の（ｆ）に示すように、Condition要素により、schemeIdUri属性に条件記述のフォーマット（条件記述言語）を識別するURIが指定される。例えば、条件記述をODRLにて記述する場合には、urn:ODRLのように指定される。また、Condition要素のコンテンツパートのCDATAセクション（"<![CDATA["という文字列で始まり、"]]>"という文字列で終わる）には、条件記述が格納される。
【０２１１】
例えば、図２７に示すように、Condition要素のコンテンツパートのCDATAセクションに条件記述が格納される。
【０２１２】
また、図２８に、ODRLによる条件記述の一例を示す。図２８では、サービスオーナーである"a.com"は、2017/12/31までであれば、"cdn.com"に対して、当該トランスコードを許可するという例が記述されている。
【０２１３】
図２９の（ａ）に示すように、TranscodeEventNotification要素により、当該TranscodeDirectiveに記載される各種制限や方針等が適用されたイベント通知が指定される。
【０２１４】
図２９の（ｂ）に示すように、dateTime属性により、イベントが発生した時刻が指定される。
【０２１５】
図２９の（ｃ）に示すように、MPDUrl属性により、当該MPDのURLが指定される。
【０２１６】
図２９の（ｄ）に示すように、AdaptationSetId属性により、トランスコード対象のAdaptationSetのIdが指定される。
【０２１７】
図２９の（ｅ）に示すように、notificationUrl属性により、notification送付先URLが指定される。
【０２１８】
ここで、例えば、当該TranscodeDirectiveの適用対象となるストリーム（セグメント）に対してトランスコードが適用された場合には、上述したdateTime属性、MPDUrl属性、およびAdaptationSetId属性のTranscodeDirective要素そのものを、notificationUrl属性で指定されるURLにHTTP POSTで通知する。これにより、実際に適用されたトランスコード処理の内容報告が行われる。このとき、適用されたトランスコードのパターンに応じて適宜要素、属性、または値が埋められるものとする。
【０２１９】
具体的には、オリジナルビデオストリームを、4K解像度および120フレームレートにアップコンバートしてから再エンコードした場合には、図３０に示されるようなTranscodeDirective要素が、notificationUrl属性で指定されるURLに通知される。
【０２２０】
図３１の（ａ）に示すように、Parameters/Video要素により、Videoの各種属性が指定される。
【０２２１】
図３１の（ｂ）に示すように、profile属性により、カンマにより区切られた”profile名”のリストが指定される。
【０２２２】
図３１の（ｃ）に示すように、resolution属性により、カンマにより区切られた”縦×横”の画素数のリストが指定される。なお、resolution属性の他の表現例として、縦画素数の上限または下限と、横画素数の上限または下限により指定してもよい。
【０２２３】
図３１の（ｄ）に示すように、frameRate属性により、カンマにより区切られた”フレームレート（fps単位）”のリストが指定される。なお、frameRate属性の他の表現例として、フレームレートの上限または下限により指定してもよい。
【０２２４】
図３１の（ｅ）に示すように、bitDepth属性により、カンマにより区切られた”ビット数（深度）”のリストが指定される。なお、bitDepth属性の他の表現例として、ビット数の上限または下限により指定してもよい。
【０２２５】
図３１の（ｆ）に示すように、colorSpace属性により、カンマにより区切られた”色空間名”のリストが指定される。
【０２２６】
図３１の（ｇ）に示すように、gamma属性により、カンマにより区切られた”ガンマ値”のリストが指定される。
【０２２７】
図３１の（ｈ）に示すように、upScalingPatternList属性により、カンマにより区切られた”アップスケーリングパターン”のリストが指定される。
【０２２８】
図３２の（ａ）に示すように、partialTransformability属性により、部分的アップスケーリングを伴うレンダリングおよびトランスコードが可能であるか否かがtrueまたはfalseにより指定される。
【０２２９】
図３２の（ｂ）に示すように、deviationLimit要素により、差分フォーマット識別子と、その方式で表現される値が指定される。
【０２３０】
図３２の（ｃ）に示すように、Parameters/Audio要素により、Audioの各種属性が指定され、可否指定対象のAudio属性が列挙される。
【０２３１】
図３２の（ｄ）に示すように、profileList属性により、カンマにより区切られた”プロファイル名”のリストが指定される。
【０２３２】
図３２の（ｅ）に示すように、samplingRate属性により、カンマにより区切られた”サンプリングレート（Hz単位）”のリストが指定される。なお、samplingRate属性の他の表現例として、サンプリングレートの上限または下限により指定してもよい。
【０２３３】
図３２の（ｆ）に示すように、bitDepth属性により、カンマにより区切られた”ビット数（深度）”のリストが指定される。なお、bitDepth属性の他の表現例として、ビット数の上限または下限により指定してもよい。
【０２３４】
図３２の（ｇ）に示すように、deviationLimit要素により、差分フォーマット識別子と、その方式で表現される値が指定される。例えば、図３３に示すように、deviationLimit要素のschemeIdUri属性にdeviationの表現方式を識別するURIが指定（例えば、PSNRであれば、urn:PSNRのように指定）され、value属性に、その値（図３３の例では３５）が格納される。
【０２３５】
図３４は、TrasncodeDirectiveの構成の一例が示されている。
【０２３６】
図３４に示すように、VideoのAdaptationSetに配置される場合は、Parameters要素の下はVideo要素のみとなる。また、AudioのAdaptationSetに配置される場合は、Parameters要素の下はAudio要素のみとなる。
【０２３７】
＜アップスケーリングの種類＞
図３５乃至図３８を参照して、部分的な画像修正処理を含むアップスケーリングの種類について説明する。
【０２３８】
図３５には、SDTV（4:3）の左右に、黒味を追加することで、HDTV（16:9）に変換するアップスケーリング（FullHeight）の例が示されている。なお、例えば、SDTVの上下に、黒味を追加することで、HDTVに変換するアップスケーリング（FullWidth）を行って画角を変換してもよく、黒味以外を追加してもよい。
【０２３９】
図３６には、SDTV（4:3）からHDTV（16:9）へ横幅を合わせて、上下をカットすることで、HDTV（16:9）に変換するアップスケーリング（FullWidth-TopBottomCrop-BlowUp）の例が示されている。なお、例えば、SDTVからHDTVへ縦幅を合わせて、左右をカットすることで、HDTVに変換するアップスケーリング（FullHeight- SideCrop-BlowUp）を行って画角を変換してもよい。
【０２４０】
図３７には、SDTV（4:3）から左右に引き伸ばすことで、HDTV（16:9）に変換するアップスケーリング（FullSize-Anamorphic）の例が示されている。なお、SDTVから上下に引き伸ばすことで、HDTVに変換するアップスケーリング（FullSize-Anamorphic）を行って画角を変換してもよい。
【０２４１】
図３８には、SDTV（4:3）から左右を補完することで、HDTV（16:9）に変換するアップスケーリング（Artificial-FullSize-Anamorphic）の例が示されている。このとき、例えば、知的画像処理技術等を利用して画像を類推生成して画像の中のオブジェクトの縦横比を維持しながら画像を補完することによって画角を変換することができる。即ち、図３８に示すように、左右に人工的に補完（その他、類推、外挿、または想像）するように画像が追加される。
【０２４２】
＜PartialTransformabilityを利用した処理＞
図３９を参照して、PartialTransformabilityを利用してコンテンツを配信するコンテンツ配信処理について説明する。例えば、上述の図３２の（ａ）に示したpartialTransformability属性をtrueまたはfalseに設定することにより、クライアントデバイスにおけるユーザのviewportの情報に基づいたオリジナルストリームの部分的なアップスケーリングを含むトランスコーディングの最適化を図ることができる。つまり、クライアントの環境情報（例えば、viewport）に基づいて、コンテンツのトランスコードを行うことができる。
【０２４３】
ステップＳ２５１において、DASHプレイヤ１４は、CDNサーバ４１（主にCDNエッジサーバ４１ｂ）に対して、MPDの取得を要求する。
【０２４４】
CDNサーバ４１は、ステップＳ２５１におけるDASHプレイヤ１４からの要求を受信すると、ステップＳ２５２において、MPDをDASHプレイヤ１４に転送する。
【０２４５】
DASHプレイヤ１４は、ステップＳ２５２で転送されてくるMPDを取得すると、ステップＳ２５３において、そのMPDをパースする。そして、DASHプレイヤ１４は、CDNサーバ４１に対してセグメントを要求する。
【０２４６】
CDNサーバ４１は、ステップＳ２５３におけるDASHプレイヤ１４からの要求を取得すると、ステップＳ２５４において、例えば、SAND等により現在検討途上のImmersiveMedia系のDASH metrics等を利用した転送要求付きのセグメントを転送する。
【０２４７】
ステップＳ２５５において、トランスコードマネジャ４３は、リクエスト処理状況の計測を行う。
【０２４８】
DASHプレイヤ１４は、ステップＳ２５４で転送されてくるSAND転送要求付きのセグメントを取得すると、ステップＳ２５６において、SANDにより、DASHプレイヤ１４におけるユーザのviewportメタデータを通知する。そして、DASHプレイヤ１４は、ステップＳ２５７において、取得したセグメントの再生を行う。
【０２４９】
トランスコードマネジャ４３は、ステップＳ２５６でDASHプレイヤ１４から送信されてくるSANDによるviewport通知を取得すると、ステップＳ２５８において、TranscodeDirectiveが追記されたMPDをパースする。そして、トランスコードマネジャ４３は、TranscodeDirectiveの解析を行い、その解析結果に従って、トランスコーダ４２に対するトランスコードを指示する。
【０２５０】
このとき、トランスコードマネジャ４３は、MPD（例えば、今後拡張される予定のOMAF対応拡張が施されたバージョン）、または、MP4ファイル（例えば、それがOMAFを利用している場合）の内容に基づいて、当該viewportに対応するストリームまたは、ストリームの一部分を特定する。これに従い、トランスコーダ４２は、そのストリームの全体、または、当該viewportを含むストリームの一部分に対して、トランスコードディレクティブにて制限または許可されるアップスケーリングを行った後に、トランスコード処理を行うことができる。
【０２５１】
即ち、トランスコーダ４２は、ステップＳ２５９においてセグメントをデコードし、ステップＳ２６０においてアップスケーリングを行う際に、viewportに従った処理を行う。そして、トランスコーダ４２は、ステップＳ２６１においてセグメントをエンコードする。
【０２５２】
ステップＳ２６２において、DASHプレイヤ１４は、次のセグメントを要求する。
【０２５３】
CDNサーバ４１は、ステップＳ２６２におけるDASHプレイヤ１４からの要求を取得すると、ステップＳ２６３において、DASHプレイヤ１４により要求されたトランスコード済みのセグメントの転送を行う。
【０２５４】
DASHプレイヤ１４は、ステップＳ２６３で転送されてくるトランスコード済みのセグメントを受信すると、ステップＳ２６４において、その受信したトランスコード済みのセグメントの再生を行う。
【０２５５】
その後、コンテンツの配信が終了するまで、トランスコード済みのセグメントの転送と、その再生が継続して行われる。
【０２５６】
以上のように、DASHプレイヤ１４からCDNサーバ４１へviewport通知を行うことで、CDNサーバ４１は、そのviewportに対応するストリームを特定して、適切にアップスケーリングされるようにトランスコードを制御することができる。
【０２５７】
＜クライアントデバイスでのviewport通知＞
図４０および図４１を参照して、ストリーム再生側となるクライアントデバイスであるDASHプレイヤ１４でのviewport通知について説明する。
【０２５８】
例えば、プレイバックデバイスにおけるviewportが、図４０に示すようなＸ軸、Ｙ軸、およびＸ軸と、これらの軸を中心にしたアングル（pitch，yaw，roll）とにより特定される場合、胴体が固定されていると、アングルは頭の動きで決定されることになる。また、Ｘ軸、Ｙ軸、およびＸ軸の正方向を向いて、各々のアングルは時計方向に増加するものと設定される。さらに、Ｘ−Ｚプレーンは、地上に平行であり、Ｚ軸の正方向を見ているときには、すべてのアングルが０であると定義する。
【０２５９】
そして、このviewportメタデータの座標系からストリームソースにおける座標系にマッピングする。
【０２６０】
例えば、ソースにおける座標系が方位角／高度角を利用した表現方法を利用していて、クライアント側がpitch，yaw，roll表現による座標系を利用しているとして説明を行う。この場合、ソース座標系の方位角／高度角（centerAzimuth／centerElevation）いずれも０の方向が、DASHプレイヤ１４におけるpitch，yaw，rollがすべて0の方向に一致するようにマッピングする。
【０２６１】
そして、変換された座標系でのviewport座標値は、OMAFで規定される構造SphereRegionStructに沿って、図４１に示すような現在検討途上のImmersive Media MetricsのViewportViewsパラメタに格納され、このMetricsを包内するSANDMessageを新たに定義して利用する。
【０２６２】
＜クライアントデバイスからのデバイス属性通知＞
図４２には、ストリーム再生側となるクライアントデバイスであるDASHプレイヤ１４から通知されるデバイス属性の一例が示されている。
【０２６３】
例えば、クライアントデバイスの能力属性については、図４２に示すような現在検討途上のImmersive Media MetricsのVRDeviceInfoパラメタに格納され、このMetricsを包内するSANDMessageを新たに定義して利用する。
【０２６４】
＜FLUSのアーキテクチャ＞
図４３および図４４を参照して、FLUのアーキテクチャについて説明する。
【０２６５】
図４３に示すように、FLUSソースは、１つまたは複数のキャプチャデバイスからメディアコンテンツを受信する。また、FLUSシンクは、メディアコンテンツをデコードし、レンダリング機能にフォワードする。または、FLUSシンクがネットワークに実装される構成では、メディアコンテンツは、メディアコンテンツをプロセシングサブファンクションまたはディストリビューションサブファンクションにフォワードされる。
【０２６６】
そして、リファレンスポイントにより、FLUSソースとFLUSシンクとが接続され、FLUSソースが単体のFLUSセッションと複数のメディアセッションとを確立し制御する。
【０２６７】
FLUSコントロールプレーン機能（F-C）は、アップロードとそれに続くダウンストリーム配信に関するFLUSシンクのメディア処理を制御する。FLUSユーザプレーン機能（F-U）は、メディアセッションを確立し、例えば、MTSI-based FLUSセッション確立におけるIMSセッションセットアップを行い、１または複数のメディアストリームセッションからなる。
【０２６８】
また、FLUSコントロールプレーン機能（F-C）は、FLUSセッションを確立して制御する機能である。FLUSソースは、FLUSコントロールプレーン機能により、メディアセッション開設、メディアセッションの静的メタデータのプロビジョニング、および、プロセシング／ディストリビューションサブファンクションの選択とコンフィギュレーションを実行する。
【０２６９】
また、メディアセッション開設は、FLUSセッションの一部として定義される。FLUSユーザプレーン機能（F-U）には、メディアセッション確立プロシジャが含まれる。１つのFLUSセッションに、複数の異なるメディアセッションが確立されることが想定される。
【０２７０】
また、メディアセッションは、１つあるは複数のメディアストリームを含む。メディアストリームは、単一メディアコンポーネント（例えば、音声のみ）を含む場合もあれば、複数の異なるメディアコンポーネント（例えば、音声と動画）を含む場合もある。メディアセッションは、１つ以上の同一メディアストリーム（例えば、複数の動画ストリーム）を含む場合もある。また、FLUSシンクがメディアセッションを開設することが想定される。
【０２７１】
図４４には、FLUSにおけるメディアセッションおよびメディアストリームの一例が示されている。
【０２７２】
図４４に示すように、FLUSセッションは、１または複数のメディアストリームを転送し、メディアストリームは、FLUSセッションの時間依存メディアである。例えば、メディアストリームがアクティブになると、FLUSソースはメディアコンテンツをFLUSシンクに転送する。
【０２７３】
また、FLUSセッションは、１つ以上のメディアストリームからなる、０または１以上のメディアセッションから構成される。なお、HTTPをメディアストリーミングに使用する場合には、メディアセッションは明示的には確立されない。
【０２７４】
＜SANDのViewportViewsメッセージの追加拡張＞
図４５には、SANDのViewportViewsメッセージの追加拡張の一例が示されている。
【０２７５】
図４５において、二点鎖線で囲われているViewportViewsTypeが新たに定義される部分である。
【０２７６】
＜コンピュータの構成例＞
なお、上述のフローチャートを参照して説明した各処理は、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。また、プログラムは、１の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１０２や記憶部１０８に、あらかじめインストールしておくことができる。
【０２８４】
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルのデータのトランスコードに関する制御を行う制御部と
を備え、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルのデータのトランスコードを制御し、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルのデータのトランスコードを制御する
コンテンツ配信制御装置。
（２）
前記メタデータファイルは、ISO IEC 23009で規格定義されるMPD（Media Presentation Description）ファイルである
上記（１）に記載のコンテンツ配信制御装置。
（３）
前記オリジナルのデータは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に従ったオリジナルセグメントである
上記（１）または（２）に記載のコンテンツ配信制御装置。
（４）
前記定義情報および前記アクセス情報は、前記MPDのAdaptationSetに格納される
上記（３）に記載のコンテンツ配信制御装置。
（５）
前記定義情報および前記アクセス情報は、前記MPDのRepresentationに格納される
上記（３）に記載のコンテンツ配信制御装置。
（６）
前記定義情報および前記アクセス情報は、前記MPDのSubRepresentationに格納される
上記（３）に記載のコンテンツ配信制御装置。
（７）
前記オリジナルのデータは、SDP（Session Description Protocol）を利用して配信されるオリジナルストリームである
上記（１）から（６）までのいずれかに記載のコンテンツ配信制御装置。
（８）
前記メタデータファイルは、IETF（Internet Engineering Task Force）で規格定義されるSDPファイルであって、
前記定義情報および前記アクセス情報は、前記SDPのメディア記述部に格納される
上記（７）に記載のコンテンツ配信制御装置。
（９）
前記定義情報は、単独のファイルとして記憶されている
上記（１）から（８）までのいずれかに記載のコンテンツ配信制御装置。
（１０）
前記定義情報により、前記コンテンツがトランスコード可能であるか否かが指定される
上記（１）から（９）までのいずれかに記載のコンテンツ配信制御装置。
（１１）
前記定義情報には、部分的な画像修正処理を含むアップスケーリング方式が定義されている
上記（１）から（１０）までのいずれかに記載のコンテンツ配信制御装置。
（１２）
前記定義情報には、トランスコードの可否制御に利用する条件記述言語に基づく条件記述が定義されている
上記（１）から（１１）までのいずれかに記載のコンテンツ配信制御装置。
（１３）
前記定義情報には、実際に適用されたトランスコード処理の内容報告に利用する情報構造が定義されている
上記（１）から（１２）までのいずれかに記載のコンテンツ配信制御装置。
（１４）
前記コンテンツのトランスコードは、前記コンテンツを取得して再生するクライアントから取得される前記クライアントの環境情報に基づいて行われる
上記（１）から（１２）までのいずれかに記載のコンテンツ配信制御装置。
（１５）
前記クライアントからviewport通知が行われるのに応じ、そのviewportを含むようにアップスケーリングするトランスコードを制御する
上記（１４）に記載のコンテンツ配信制御装置。
（１６）
コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルのデータのトランスコードに関する制御を行う制御部と
を備えるコンテンツ配信制御装置が、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルのデータのトランスコードを制御することと、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルのデータのトランスコードを制御することと
を含むコンテンツ配信制御方法。
（１７）
コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルのデータのトランスコードに関する制御を行う制御部と
を備えるコンテンツ配信制御装置のコンピュータに、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルのデータのトランスコードを制御することと、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルのデータのトランスコードを制御することと
を含む処理を実行させるためのプログラム。
（１８）
コンテンツを記憶する記憶部を有する第１のサーバと、
前記コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルのデータのトランスコードに関する制御を行う制御部と
を有し、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルのデータのトランスコードを制御し、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルのデータのトランスコードを制御する
コンテンツ配信制御を行う第２のサーバと、
前記コンテンツ配信制御に従って配信されるコンテンツを取得して、再生するクライアントと
を備えるコンテンツ配信システム。
【０２８５】
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASH(Dynamic Adaptive Streaming over HTTP)に従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部と
を備え、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御し、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御する
コンテンツ配信制御装置。
（２）
前記メタデータファイルは、ISO IEC 23009で規格定義されるMPD（Media Presentation Description）ファイルである
上記（１）に記載のコンテンツ配信制御装置。
（３）
前記定義情報および前記アクセス情報は、前記MPDのAdaptationSetに格納される
上記（２）に記載のコンテンツ配信制御装置。
（４）
前記定義情報および前記アクセス情報は、前記MPDのRepresentationに格納される
上記（２）または（３）に記載のコンテンツ配信制御装置。
（５）
前記定義情報および前記アクセス情報は、前記MPDのSubRepresentationに格納される
上記（２）から（４）までのいずれかに記載のコンテンツ配信制御装置。
（６）
前記定義情報は、単独のファイルとして記憶されている
上記（１）から（５）までのいずれかに記載のコンテンツ配信制御装置。
（７）
前記定義情報により、前記コンテンツがトランスコード可能であるか否かが指定される
上記（１）から（６）までのいずれかに記載のコンテンツ配信制御装置。
（８）
前記定義情報には、部分的な画像修正処理を含むアップスケーリング方式が定義されている
上記（１）から（７）までのいずれかに記載のコンテンツ配信制御装置。
（９）
前記定義情報には、トランスコードの可否制御に利用する条件記述言語に基づく条件記述が定義されている
上記（１）から（８）までのいずれかに記載のコンテンツ配信制御装置。
（１０）
前記定義情報には、実際に適用されたトランスコード処理の内容報告に利用する情報構造が定義されている
上記（１）から（９）までのいずれかに記載のコンテンツ配信制御装置。
（１１）
前記コンテンツのトランスコードは、前記コンテンツを取得して再生するクライアントから取得される前記クライアントの環境情報に基づいて行われる
上記（１）から（１０）までのいずれかに記載のコンテンツ配信制御装置。
（１２）
前記クライアントからviewport通知が行われるのに応じ、そのviewportを含むようにアップスケーリングするトランスコードを制御する
上記（１１）に記載のコンテンツ配信制御装置。
（１３）
コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASH(Dynamic Adaptive Streaming over HTTP)に従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部と
を備えるコンテンツ配信制御装置が、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することと、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することと
を含むコンテンツ配信制御方法。
（１４）
コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASH(Dynamic Adaptive Streaming over HTTP)に従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部と
を備えるコンテンツ配信制御装置のコンピュータに、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することと、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御することと
を含む処理を実行させるためのプログラム。
（１５）
コンテンツを記憶する記憶部を有する第１のサーバと、
前記コンテンツをトランスコードするために必要な定義情報、または、前記定義情報にアクセスするための第１のアクセス情報と、前記コンテンツから生成されたオリジナルのデータであるMPEG-DASH(Dynamic Adaptive Streaming over HTTP)に従ったオリジナルセグメントにアクセスするための第２のアクセス情報とが格納されたメタデータファイルを生成する生成部と、
前記メタデータファイルを受信する受信部と、
前記第２のアクセス情報に基づいて取得された前記オリジナルセグメントのトランスコードに関する制御を行う制御部と
を有し、
前記メタデータファイルに前記定義情報が格納されている場合、前記制御部は、前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御し、
前記メタデータファイルに前記第１のアクセス情報が格納されている場合、前記制御部は、前記第１のアクセス情報に基づいて前記定義情報をリクエストし、そのリクエストに応じて前記受信部において受信された前記定義情報に基づいて、前記オリジナルセグメントのトランスコードを制御する
コンテンツ配信制御を行う第２のサーバと、
前記コンテンツ配信制御に従って配信される前記コンテンツを取得して、再生するクライアントと
を備えるコンテンツ配信システム。
【０２８６】
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
【符号の説明】
【０２８７】
１１  コンテンツ配信システム，  １２  クラウド，  １３  コンテンツ提供装置，  １４  DASHプレイヤ，  ２１  ストリームソースサーバ，  ２２  DASH配信サーバ，  ２３  CDN，  ３１  ストリーミング配信マネジャ，  ４１  CDNサーバ，  ４１ａ  CDNオリジンサーバ，  ４１ｂ  CDNエッジサーバ，  ４２  トランスコーダ，  ４３  トランスコードマネジャ
【図１】
2019167633.tif 000003
【図２】
2019167633.tif 000004
【図３】
2019167633.tif 000005
【図４】
2019167633.tif 000006
【図５】
2019167633.tif 000007
【図６】
2019167633.tif 000008
【図７】
2019167633.tif 000009
【図８】
2019167633.tif 000010
【図９】
2019167633.tif 000011
【図１０】
2019167633.tif 000012
【図１１】
2019167633.tif 000013
【図１２】
2019167633.tif 000014
【図１３】
2019167633.tif 000015
【図１４】
2019167633.tif 000016
【図１５】
2019167633.tif 000017
【図１６】
2019167633.tif 000018
【図１７】
2019167633.tif 000019
【図１８】
2019167633.tif 000020
【図１９】
2019167633.tif 000021
【図２０】
2019167633.tif 000022
【図２１】
2019167633.tif 000023
【図２２】
2019167633.tif 000024
【図２３】
2019167633.tif 000025
【図２４】
2019167633.tif 000026
【図２５】
2019167633.tif 000027
【図２６】
2019167633.tif 000028
【図２７】
2019167633.tif 000029
【図２８】
2019167633.tif 000030
【図２９】
2019167633.tif 000031
【図３０】
2019167633.tif 000032
【図３１】
2019167633.tif 000033
【図３２】
2019167633.tif 000034
【図３３】
2019167633.tif 000035
【図３４】
2019167633.tif 000036
【図３５】
2019167633.tif 000037
【図３６】
2019167633.tif 000038
【図３７】
2019167633.tif 000039
【図３８】
2019167633.tif 000040
【図３９】
2019167633.tif 000041
【図４０】
2019167633.tif 000042
【図４１】
2019167633.tif 000043
【図４２】
2019167633.tif 000044
【図４３】
2019167633.tif 000045
【図４４】
2019167633.tif 000046
【図４５】
2019167633.tif 000047
【図４６】
2019167633.tif 000048
【国際調査報告】
2019167633.tif 000049
2019167633.tif 000050
2019167633.tif 000051
2019167633.tif 000052