(57)【要約】  本開示は、プロキシサーバ等からストリームの受信状態等を表す受信可否情報を取得することができるようにする受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラムに関する。本開示の受信装置は、コンテンツのストリームを構成するセグメントファイルを受信する受信部と、受信した前記セグメントファイルを取得して再生する再生部と、セグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備え、前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給し、前記再生部は、生成された前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する。本開示は、ストリーム配信システムに適用できる。
2017212931.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備え、
前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給し、
前記再生部は、生成された前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する
受信装置。
【請求項２】
前記受信部は、放送網、双方向通信網、または携帯電話通信網を介して、前記セグメントファイルを受信する
請求項１に記載の受信装置。
【請求項３】
前記プロキシサーバ部は、前記受信部が受信した前記セグメントファイルをキャッシュするキャッシュ部を有し、前記再生部から要求された前記セグメントを前記キャッシュ部がキャッシュしている場合、前記キャッシュ部がキャッシュしている前記セグメントファイルを前記再生部に供給する
請求項２に記載の受信装置。
【請求項４】
前記プロキシサーバ部は、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを受信する際のデータパスに対する受信メトリクスおよび前記受信メトリクスの値をさらに含む前記供給可否情報を生成する
請求項２に記載の受信装置。
【請求項５】
前記プロキシサーバ部は、SANDプロトコルによるResourceStatusメッセージを拡張した前記供給可否情報を生成する
請求項２に記載の受信装置。
【請求項６】
前記プロキシサーバ部は、SANDプロトコルによるDaneResourceStatusメッセージを拡張した前記供給可否情報を生成する
請求項２に記載の受信装置。
【請求項７】
前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じたレスポンスのヘッダに前記供給可否情報の取得先情報を格納するとともに、前記レスポンスのボディに前記セグメントファイルのバイナリデータを格納する
請求項２に記載の受信装置。
【請求項８】
コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部と
を備える受信装置の受信方法において、
前記再生部による、前記プロキシサーバ部に対して前記セグメントファイルを要求する第１の要求ステップと、
前記プロキシサーバ部による、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給する供給ステップと、
前記再生部による、前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する第２の要求ステップと
を含む受信方法。
【請求項９】
コンピュータを、
コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部として機能させ、
前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給し、
前記再生部は、生成された前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する
プログラム。
【請求項１０】
所定のネットワークを介してコンテンツを供給する供給装置に接続された再生装置において、
前記供給装置が生成した供給可否情報に基づき、前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する要求部と、
前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生部とを備え、
前記供給装置は、
前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える
再生装置。
【請求項１１】
前記所定のネットワークは、LANである
請求項１０に記載の再生装置。
【請求項１２】
所定のネットワークを介してコンテンツを供給する供給装置に接続された再生装置の再生方法において、
前記再生装置による、
前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する第１の要求ステップと、
前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生ステップと、
前記供給装置が生成した供給可否情報に基づき、次に再生する前記セグメントファイルを前記供給装置に対して要求する第２の要求ステップとを含み、
前記供給装置は、
前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える
再生方法。
【請求項１３】
所定のネットワークを介してコンテンツを供給する供給装置に接続されたコンピュータを、
前記供給装置が生成した供給可否情報に基づき、前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する要求部と、
前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生部として機能させ、
前記供給装置は、
前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える
プログラム。
【請求項１４】
所定のネットワークを介して再生装置にコンテンツを供給する供給装置において、
前記コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生装置に供給するプロキシサーバ部と
を備える供給装置。
【請求項１５】
コンテンツのストリームを構成するセグメントファイルを受信する受信部を備え、
所定のネットワークを介して再生装置に前記セグメントファイルを供給する供給装置の供給方法において、
前記供給装置による、
前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成する生成ステップと、
前記受信部が受信した前記セグメントファイルを前記再生装置に供給する供給ステップと
を含む供給方法。
【請求項１６】
所定のネットワークを介して再生装置にコンテンツを供給するコンピュータを、
前記コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生装置に供給するプロキシサーバ部と
して機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラムに関し、特に、放送または配信されるコンテンツをキャッシングして他に供給するプロキシのコンテンツの受信状態を通知できるようにした受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラムに関する。
【背景技術】
【０００２】
IPTV等のインターネットストリーミングにおける標準化の流れとして、HTTPストリーミングによるVoD(Video on Demand)ストリーミングや、ライブストリーミング等に適用される方式の標準化が行われている。【０００３】
特にISO/IEC/MPEGで標準化が行われているDASH(Dynamic Adaptive Streaming over HTTP)が注目されている（例えば、非特許文献１を参照）。【０００４】
ここで、DASHの概要について説明する。図１は、DASHを採用したストリーム配信システムの構成の一例を示している。同図左側に示すMedia Presentation on HTTP Serverはコンテンツの供給側であり、同図右側に示すHTTP Streaming Clientがコンテンツの受信側であって、受信したコンテンツを受信して再生するユーザに提示することができる。【０００５】
供給側のMedia Presentation on HTTP Serverは、同一内容のコンテンツであって、パスとなる地上デジタル放送や衛星放送等の放送網、インターネット等の双方向通信網、3GPPやLTE-eMBMS等の携帯電話通信網の通信環境や受信側の能力や状態に応じて画質や画角サイズなどが変更されている複数のストリームを用意し、供給することができる。一方、受信側のHTTP Streaming Clientは、供給側が用意している複数のストリームのうち、パスの通信環境や受信側の能力や状態などに応じて最適なストリームを選択して取得、再生することができる。【０００６】
このように、DASHにおいては、受信側がストリームを適応的に選択して取得できるように、MPD(Media Presentation Description)と称されるメタデータがコンテンツの供給側から受信側に供給される。【０００７】
MPDには、チャンク化されたストリーム(Audio/Video/Subtitle等のメディアデータ)のアドレス(url情報)が記述されており、受信側は該url情報に基づいて、コンテンツの供給元となる所定のサーバにアクセスし、HTTP配信されるストリーミングデータを取得、再生することができる。【０００８】
ところで、供給側に比較して圧倒的に数が多い受信側のHTTP Streaming Clientがコンテンツの供給元となる同一のサーバに対して同一のストリームを要求することが起こり得る。そのような場合、各HTTP Streaming Clientからの供給に応じてその都度、同一のストリームを送信していては通信効率が悪いので、インターネット上などにいわゆるプロキシサーバを設けることも提案されている。【０００９】
さらに、上述したプロキシサーバと同等の機能を受信側のHTTP Streaming Client内に設けることも提案されている。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEIELECTRONICS 2012.3.19
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上述したように、インターネット上などにプロキシサーバを設けたり、受信側にプロキシサーバと同等の機能を持たせ、受信側がプロキシサーバ等におけるストリームの受信状態等を取得することができれば、コンテンツの取得先としてプロキシサーバを効率的に選択できたり、プロキシサーバ等を介さずにコンテンツの供給元のサーバから直接的にコンテンツを取得できたりすることになる。【００１２】
しかしながら、現状において受信側は、プロキシサーバ等に所望するストリームが既にキャッシングされているか否かを表す情報を取得できるに過ぎず、プロキシサーバ等におけるストリームの受信状態などを取得する方法は確立されていない。【００１３】
本開示はこのような状況に鑑みてなされたものであり、プロキシサーバ等からストリームの受信状態を取得できるようにするものである。
【課題を解決するための手段】
【００１４】
本開示の第１の側面である受信装置は、コンテンツのストリームを構成するセグメントファイルを受信する受信部と、前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備え、前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給し、前記再生部は、生成された前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する。【００１５】
前記受信部は、放送網、双方向通信網、または携帯電話通信網を介して、前記セグメントファイルを受信することができる。【００１６】
前記プロキシサーバ部は、前記受信部が受信した前記セグメントファイルをキャッシュするキャッシュ部を有することができ、前記再生部から要求された前記セグメントを前記キャッシュ部がキャッシュしている場合、前記キャッシュ部がキャッシュしている前記セグメントファイルを前記再生部に供給することができる。【００１７】
前記プロキシサーバ部は、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを受信する際のデータパスに対する受信メトリクスおよび前記受信メトリクスの値をさらに含む前記供給可否情報を生成することができる。【００１８】
前記プロキシサーバ部は、SANDプロトコルによるResourceStatusメッセージを拡張した前記供給可否情報を生成することができる。【００１９】
前記プロキシサーバ部は、SANDプロトコルによるDaneResourceStatusメッセージを拡張した前記供給可否情報を生成することができる。【００２０】
前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じたレスポンスのヘッダに前記供給可否情報の取得先情報を格納するとともに、前記レスポンスのボディに前記セグメントファイルのバイナリデータを格納することができる。【００２１】
本開示の第１の側面である受信方法は、コンテンツのストリームを構成するセグメントファイルを受信する受信部と、前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える受信装置の受信方法において、前記再生部による、前記プロキシサーバ部に対して前記セグメントファイルを要求する第１の要求ステップと、前記プロキシサーバ部による、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給する供給ステップと、前記再生部による、前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する第２の要求ステップとを含む。【００２２】
本開示の第１の側面であるプログラムは、コンピュータを、コンテンツのストリームを構成するセグメントファイルを受信する受信部と、前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部として機能させ、前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給し、前記再生部は、生成された前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する。【００２３】
本開示の第１の側面においては、プロキシサーバ部に対してセグメントファイルが要求され、前記要求に応じて、供給可否情報が生成されるとともに、受信されたセグメントファイルが再生部に供給すされる。さらに、供給可否情報に基づき、次に再生するセグメントファイルが要求される。【００２４】
本開示の第２の側面である再生装置は、所定のネットワークを介してコンテンツを供給する供給装置に接続された再生装置において、前記供給装置が生成した供給可否情報に基づき、前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する要求部と、前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生部とを備え、前記供給装置は、前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える。【００２５】
前記所定のネットワークは、LANとすることができる。【００２６】
本開示の第２の側面である再生方法は、所定のネットワークを介してコンテンツを供給する供給装置に接続された再生装置の再生方法において、前記再生装置による、前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する第１の要求ステップと、前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生ステップと、前記供給装置が生成した供給可否情報に基づき、次に再生する前記セグメントファイルを前記供給装置に対して要求する第２の要求ステップとを含み、前記供給装置は、前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える。【００２７】
本開示の第２の側面であるプログラムは、所定のネットワークを介してコンテンツを供給する供給装置に接続されたコンピュータを、前記供給装置が生成した供給可否情報に基づき、前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する要求部と、前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生部として機能させ、前記供給装置は、前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える。【００２８】
本開示の第２の側面においては、供給装置に対してコンテンツを構成するセグメントファイルが要求され、要求に応じて供給装置から供給されたセグメントファイルが再生され、供給装置が生成した供給可否情報に基づき、次に再生するセグメントファイルが供給装置に対して要求される。【００２９】
本開示の第３の側面である供給装置は、所定のネットワークを介して再生装置にコンテンツを供給する供給装置において、前記コンテンツのストリームを構成するセグメントファイルを受信する受信部と、前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生装置に供給するプロキシサーバ部とを備える。【００３０】
本開示の第３の側面である供給方法は、コンテンツのストリームを構成するセグメントファイルを受信する受信部を備え、所定のネットワークを介して再生装置に前記セグメントファイルを供給する供給装置の供給方法において、前記供給装置による、前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成する生成ステップと、前記受信部が受信した前記セグメントファイルを前記再生装置に供給する供給ステップとを含む。【００３１】
本開示の第３の側面であるプログラムは、所定のネットワークを介して再生装置にコンテンツを供給するコンピュータを、前記コンテンツのストリームを構成するセグメントファイルを受信する受信部と、前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生装置に供給するプロキシサーバ部として機能させる。【００３２】
本開示の第３の側面においては、再生装置からのセグメントファイルの要求に応じ、受信部によるセグメントファイルの受信状態に基づき、再生装置が要求し得るセグメントファイルを再生装置に対して供給できる確率を含む供給可否情報が生成され、受信部が受信したセグメントファイルが再生装置に供給される。
【発明の効果】
【００３３】
本開示の第１の側面によれば、再生部はプロキシサーバ部から供給可否情報を取得できる。【００３４】
本開示の第２の側面によれば、供給装置から供給可否情報を取得でき、供給可否情報に基づいて次に再生するセグメントファイルを要求できる。【００３５】
本開示の第３の側面によれば、再生装置に対して供給するための供給可否情報を生成できる。
【図面の簡単な説明】
【００３６】
【図１】DASHを採用したストリーム配信システムの構成の一例を示すブロック図である。
【図２】コンテンツのストリームを表すPeriod，Representation，Segmentの関係を示す図である。
【図３】MPDのデータ構造を示す図である。
【図４】MPDにおけるPeriod以下の階層構造を示す図である。
【図５】時間軸上にMPDの構造を並べた状態を示す図である。
【図６】DASHを採用したストリーム配信システムの構成の一例を示すブロック図である。
【図７】ROUTE/DASHベースのスタックを示す図である。
【図８】ROUTE/DASHベースのスタックを示す図である。
【図９】本開示の実施の形態であるDASHクライアント装置の構成例を示すブロック図である。
【図１０】PERメッセージについて説明するための図である。
【図１１】供給可否情報として利用するために拡張したResourceStatusの第１のデータ構造を示す図である。
【図１２】ResourceStatusのstatusに格納する情報を示す図である。
【図１３】供給可否情報として利用するために拡張したResourceStatusの第２のデータ構造を示す図である。
【図１４】供給可否情報として利用するために拡張したDaneResourceStatusのデータ構造を示す図である。
【図１５】DaneResourceStatusのstatusに格納する情報を示す図である。
【図１６】供給可否情報が供給されるときの動作を説明するフローチャートである。
【図１７】オプションのreason要素が記述されている供給可否情報の例を示す図である。
【図１８】DANEに接続されるPHY/MAC層の第１の構成例を示す図である。
【図１９】DANEに接続されるPHY/MAC層の第２の構成例を示す図である。
【図２０】１つのネットワークモジュールが２種類のデータパイプを有する場合のSANDメッセージを生成する処理を説明するフローチャートである。
【図２１】ネットワークモジュールが２種類ある場合のSANDメッセージを生成する処理を説明するフローチャートである。
【図２２】通常は非アクティブなネットワークモジュールがある場合のSANDメッセージを生成する処理を説明するフローチャートである。
【図２３】通常は非アクティブなネットワークモジュールがある場合のSANDメッセージを生成する処理を説明するフローチャートである。
【図２４】汎用のコンピュータの構成例を示すブロック図である。
【発明を実施するための形態】
【００３７】
以下、本開示を実施するための最良の形態（以下、実施の形態と称する）について、図面を参照しながら詳細に説明する。
【００３８】
＜DASHの概要説明＞
始めに、DASHの概要についてより詳細に説明する。
【００３９】
図２は、DASHを採用したコンテンツ配信システムにおいて配信されるコンテンツのストリームに関するデータ単位を表すPeriod，Representation，Segmentの関係を示している。
【００４０】
Periodは、コンテンツの時間的な区切りの単位である。Segmentは、Periodを時間的により細分化した単位であり、コンテンツのストリームは、Segmentの単位でファイル化されている。
【００４１】
Representationは、同一内容であって画質や画角サイズが変更されることによりビットレートなどの属性が異なるストリームを表す用語であり、同一内容のコンテンツに対して複数のRepresentationが用意されている。
【００４２】
図３は、コンテンツの供給側から受信側に供給されるメタデータとしてのMPDのデータ構造を示している。
【００４３】
MPDは、コンテンツに関する情報がPeriod毎に区分されている。各Periodには、同一内容であって画質や画角サイズ、言語等が変更されているビットレートなどのストリーム属性の異なる同期されたストリーミングデータに関する情報からなる複数のRepresentationが用意されている。Representationには、Periodをさらに時間的に分割したSegmentに関する情報が格納されている。
【００４４】
図４は、MPDにおけるPeriod以下の階層構造を示している。なお、MPDは、例えばXML形式で記述される。Periodの下層には、ストリームの選択範囲となるRepresentation群をグルーピングする情報であるAdaptationSetが記述される。AdaptationSetの下層には、動画や音声のビットレート、画角サイズ、言語などを表す情報を含むRepresentationが記述される。Representationの下層には、動画や音声のセグメント関連の情報であるSegmentinfoが記述される。Segmentinfoの下層には、データ圧縮方式などの初期化情報を表すInitialization Segment、および、動画や音声のSegment単位のデータの供給元を表すMedia Segmentが記述される。
【００４５】
図５は、時間軸上にMPDの構造を並べた状態を示している。同図から明らかなように、同一のAdaptationSetに含まれるストリーム属性が異なる各RepresentationのSegmentどうしは同期したものとなる。
【００４６】
受信側では、MPDのPeriodに含まれるRepresentationの属性に基づいて受信、再生に最適なRepresentationを選択し、選択したRepresentationの先頭のSegmentからInitialization Segmentを取得してデータ圧縮方式などを判断した後、後続のsegmentを取得、再生を行うことができる。
【００４７】
図６は、DASHを採用したストリーム配信システムの構成の一例を示している。
【００４８】
図６のDASH MPDサーバおよびDASHセグメントストリーマは、図１のMedia Presentation on HTTP Serverに相当する。また、図６のDASHクライアントは、図１のHTTP Streaming Clientに相当する。
【００４９】
DASH MPDサーバおよびDASHセグメントストリーマとDASHクライアントとは、インターネット上に形成されたCDN(Content Delivery Network)を介して接続される。CDNにはDASHキャッシュサーバ（プロキシサーバ）が設けられている。
【００５０】
DASH MPDサーバは、DASHクライアントからのHTTPリクエストに応じ、CDN(Content Delivery Network)を介してMPDを配信する。DASHセグメントストリーマは、MPDを参照してストリームの取得先を選択したDASHクライアントからのHTTPリクエストに応じ、CDNを介してセグメントファイル配信する。
【００５１】
DASHキャッシュサーバは、CDNを監視し、DASHクライアントに対してCDNを介して配信されるセグメントファイルを一時的にキャッシュする。そして、DASHキャッシュサーバは、DASHクライアントからキャッシュしているセグメントファイルを要求するHTTPリクエストがDASHセグメントストリーマに送信された場合、DASHセグメントストリーマに代わって、キャッシュしているセグメントファイルを要求元のMPDクライアントに配信する。
【００５２】
なお、DASHキャッシュサーバは、ストリームのセグメントファイルだけでなく、MPDも一時的にキャッシュすることができ、DASH MPDサーバの代わりに、キャッシュしているMPDを要求元のDASHクライアントに供給することができる。
【００５３】
CDN上にDASHキャッシュサーバを設けたことにより、該ストリーム配信システムでは、大多数のDASHクライアントに対するHTTPストリーミングの配信効率を向上させることができる。
【００５４】
なお、本開示は、受信側にDASHキャッシュサーバとしての機能を持たせることを前提としたものである（詳細は図９を参照して後述する）。
【００５５】
ところで、MPDとコンテンツのストリームのセグメントファイルは、HTTPによるユニキャスト配信だけでなく、同時に多数のDASHクライアントに対して同時に配信できるマルチキャスト配信することも想定される。
【００５６】
具体的には、例えば米国における次世代の地上デジタルテレビジョン放送規格であるATSC3.0のIPベースのトランスポートスタックに格納してマルチキャスト配信することが想定されている。
【００５７】
図７および図８は、ATSC3.0におけるIPベースのトランスポートスタックの標準化において標準候補方式として確立しているROUTE(Real-Time Object Delivery over Unidirectional Transport)/DASHベースのスタックを示している。
【００５８】
DASHにおけるMPDやセグメント、放送配信のためのシグナリング(拡張されたUSBD/USD、S-TSID等）は、ROUTEプロトコルにより転送することができる。
【００５９】
ROUTEプロトコルは、FLUTE(File Delivery over Unidirectional Transport)プロトコルを拡張したものである。FLUTEプロトコルにおける転送制御パラメタを記述したメタデータファイルはFDT(File Delivery Table)と称されていたが、ROUTEにおける転送制御パラメタを記述したメタデータファイルはS-TSID(Service based Transport Session Description)と称される。なお、S-TSIDはFDTのスーパセットでありFDTを含む。
【００６０】
＜本開示を適用したクライアント装置の構成例＞
次に、図９は、ATSC3.0においてDASHを採用したストリーミング配信サービスを実現する場合における受信側のクライアント装置の構成例を示している。
【００６１】
該クライアント装置１００は、本開示第１の一側面である受信装置の実施の形態である。
【００６２】
クライアント装置１００は、ATSC3.0以外のテレビジョン放送規格においてDASHを採用したストリーミング配信サービスを実現する場合にも適用することが可能である。
【００６３】
クライアント装置(3.0 Client(with ATSC3.0 PHY/MAC))１００は、例えば、一般家屋に設置されたり、自動車等の移動体に搭載されたりするテレビジョン受像機等を想定したものである。
【００６４】
クライアント装置１００は、放送受信部（Client ATSC Middleware）１１０、通信部(Ethernet/WiFi etc.)１２０、プロキシサーバ部（Client Local HTTP Proxy Server）１３０、およびDASHクライアント部(3.0 DASH Client)１４０を備える。
【００６５】
放送受信部１１０は、放送信号を受信するチューナ部１１１、放送信号からセグメントファイルを抽出するSegment Retriever１１２、放送信号からLLS(Low Level Signaling)ファイルを抽出するLLS Signaling Retriever１１３、およびLLSファイルを解析するLLS Signaling Parser１１４を備える。さらに、放送受信部１１０は、放送信号からSLS(Service Layer Signaling)ファイルを抽出するSLS Signaling Retriever１１５、およびSLSファイルを解析するSLS Signaling Parser１１６を備える。
【００６６】
放送受信部１１０は、Broadcaster１０（図６のDASH MPDサーバおよびDASHセグメントストリーマに相当）から、地上デジタル放送または衛星放送などの放送網１１を介して配信されるMPD、ストリームのセグメントファイル、SLSファイル等を受信する処理を実行する。
【００６７】
通信部１２０は、Broadcaster１０から、インターネットなどの双方向通信網に形成されているCDN１２を介してMPD、ストリームのセグメントファイル、SLSファイルを要求し（HTTPリクエストを送信し）、それに応じてHTTP配信されるMPDやセグメントファイルを受信する処理を実行する。
【００６８】
プロキシサーバ部１３０は、放送網１１を介して受信された各種ファイルをキャッシュするProxy Cache１３１、CDN１２を介して受信された各種ファイルをキャッシュするProxy Cache１３２、および、DASHクライアント部１４０からの要求に対応するBroadcast/Broadband Address Resolver１３３を備える。
【００６９】
Broadcast/Broadband Address Resolver１３３は、Proxy Cache１３１または１３２にキャッシュされているMPDやセグメントファイルをキ、DASHクライアント部１４０からの要求に応じてそれらを供給する処理を実行する。
【００７０】
さらに、Broadcast/Broadband Address Resolver１３３は、放送受信部１１０や通信部１２０によるセグメントファイルの受信状態などを表す供給可否情報をDASHクライアント部１４０に通知する処理を実行する。なお、供給可否情報の詳細については後述する。
【００７１】
DASHクライアント部１４０は、MPDを要求、取得するMPD Retriever１４１、MPDを解析するMPD Parser１４２、MPDを参照してセグメントファイルを要求、取得するSegment Retriever１４３、およびセグメントファイルからMP4データを抽出、解析するMP4 Parser１４４を備える。さらに、DASHクライアント部１４０は、MP4データをデコードするDecoder１４５、およびデコード結果をレンダリングするRenderer１４６を備える。
【００７２】
DASHクライアント部１４０は、例えば、クライアント装置１００に実装されたブラウザ上で実現される。ただし、ブラウザアプリケーションとしてだけではなくネイティブアプリケーションとして実現するようにしてもよい。DASHクライアント部１４０は、プロキシサーバ部１３０を介して、放送受信部１１０または通信部１２０が受信したMPD、セグメントファイル、SLSファイル等を取得し、ストリームのレンダリングやアプリケーションの制御を行うことにより、ストリームの映像および音声を後段のモニタ（不図示）に出力する処理を実行する。
【００７３】
なお、DASHクライアント部１４０は、クライアント装置１００のみならず、クライアント装置１００に対してLAN２０を介して接続されているクライアント装置２００に実装することができる。クライアント装置２００は、例えば、スマートフォン、タブレットなどを想定したものである。
【００７４】
該クライアント装置２００は、本開示の第２の側面である再生装置の実施の形態である。
【００７５】
クライアント装置２００におけるDASHクライアント部１４０は、LAN２０を介してクライアント装置２００に接続し、クライアント装置２００のプロキシサーバ部１３０を介して、放送受信部１１０または通信部１２０が受信したMPD、セグメントファイル、SLSファイル等を取得し、ストリームのレンダリングやアプリケーションの制御を行うことにより、ストリームの映像および音声を後段のモニタ（不図示）に出力する処理を実行することができる。
【００７６】
なお、図示は省略するが、本開示の第３の側面である供給装置の実施の形態となるクライアント装置１００からDASHクライアント部１４０を省略した構成を有する供給装置を、LAN２０に接続してもよい。その場合、クライアント装置１００および２００は、該供給装置に対してもMPDやセグメントファイル等を要求することができる。
【００７７】
上述したように、クライアント装置１００におけるDASHクライアント部１４０、およびクライアント装置２００におけるDASHクライアント部１４０は、必ずプロキシサーバ部１３０を介して各種ファイルを取得している。したがって、DASHクライアント部１４０は、取得する各種ファイルが放送網１１を介するか、CDN１２を介するかの区別を意識する必要が無い、いわゆるネットワーク透過性を実現できる。したがって、DASHクライアント部１４０は、その可搬性が高まるので、放送を受信できない装置に対してもDASHクライアント部１４０を搭載することが可能となる。
【００７８】
次に、プロキシサーバ部１３０について詳述する。プロキシサーバ部１３０は、DASHクライアント部１４０から各種ファイルの取得を要求されると（HTTPリクエストを受信すると）、Broadcast/Broadband Address Resolver１３３が、それを放送網１１経由で取得するか、CDN１２経由で取得するかを判断する。この判断の材料となる情報は、放送受信部１１０のSLS Signaling Parser１１６から提供される。
【００７９】
放送受信部１１０のSLS Signaling Parser１１６は、SLS Signaling Retriever１１５に対して、ATSC3.0のシグナリングメタデータであるUSBD/USDやS-TSID等の取得要求を行う。SLS Signaling Retriever１１５は、チューナ部(ATSC3.0 PHY/MAC)１１１が受信する放送信号からSLS LCTパケットにより運ばれるシグナリングメタデータを抽出する。
【００８０】
また、SLS Signaling Parser１１６は、また、セグメントファイルの取得要求に含まれるurlからシグナリングメタデータを取得して、対象となるセグメントファイルを取得するための放送配信アドレス情報を取得する。対象となるセグメントファイルが放送配信される、または放送配信されたことがわかれば、その放送配信アドレス情報に基づき、対象となるセグメントファイルが格納されているsegment LCTパケットを放送ストリームから取得してプロキシサーバ部１３０のProxy Cache１３１内に展開する。この後、プロキシサーバ部１３０は、DASHクライアント部１４０に対してHTTPリクエストのレスポンスとして当該セグメントファイルを返すことになる。
【００８１】
要求されたセグメントファイルのurlがシグナリングメタデータになければ、プロキシサーバ部１３０は、通信部１２０を介してセグメントファイルを取得し、取得したセグメントファイルをProxy Cache１３２内に展開する。この後、プロキシサーバ部１３０は、DASHクライアント部１４０に対してHTTPリクエストのレスポンスとして当該セグメントファイルを返すことになる。
【００８２】
＜供給可否情報について＞
次に、供給可否情報について説明する。供給可否情報は、以下に説明するPERメッセージを拡張したものである。
【００８３】
図１０は、供給可否情報のベースとなるPERメッセージについて説明するための図である。PERメッセージは、DANE(DASH-Aware Network Elements)３００からDASH Client４００に対して通知されるメッセージである。ここで、DANE３００は、図９に示されたDASHクライアント装置１００のプロキシサーバ部１３０に相当する。DASH Client４００は、DASHクライアント装置１００のDASHクライアント部１４０に相当する。
【００８４】
DASHにおいては、検討途上ではあるがSANDと称されるプロトコルが規定されている。SANDは、DASHを効果的に運用するために、ネットワークオペレータが管理するDASH配信コンポーネント群から提供され得る種々のリアルタイムネットワーク環境(配信リソース)情報を交換・提供するためのプロトコルである。
【００８５】
SANDには、DANE３００からDASH Client４００に提供されるメッセージ（PERメッセージ）のメッセージプロトコルとしてPERが規定されている。また、DASH Client４００からDANE３００に提供されるメッセージ（Statusメッセージ）のメッセージプロトコルとしてStatusが規定されている。なお、以下、PERメッセージまたはStatusメッセージをSANDメッセージとも称する。
【００８６】
PERでは、ResourceStatusと称するメッセージと、この同類のメッセージとしてDaneResourceStatusと称するメッセージが定義されている。本実施の形態では、ResourceStatusまたはDaneResourceStatusを拡張して供給可否情報として、プロキシサーバ部１３０からDASHクライアント部１４０に通知する。
【００８７】
ResourceStatusを受け取ったDASH client４００は、ResourceStatusに基づいて次に要求するDASHセグメントファイルを選択することができる。なお、ResourceStatusには、有効期限が記述されているので、DASH client４００はResourceStatusの有効期限まではその内容が有効であるとみなすことができる。
【００８８】
図１１は、供給可否情報として利用するための拡張したResourceStatusの第１のデータ構造を示している。該第１のデータ構造は、DASHにおけるストリームをBaseURL要素によって指定するものである。
【００８９】
BaseURL要素には、DASHにおけるストリームを指定するためのパラメタ（識別子）としてBaseURLを格納する。status要素には、該ストリームのセグメントファイルのキャッシングの状態を表す情報（図１２）を格納する。供給可否情報のstatus要素により、これを受け取ったDASHクライアント部１４０では、該ストリームのセグメントファイルのavailability(利用可能可否)を知ることができる。
【００９０】
図１２は、status要素に格納される情報の具体例を示している。availableは、該ストリームのセグメントファイルに対するリクエストを受け付ける用意があり、期待どおりのレスポンスを得られる可能性があることを表す。unavailableは、該ストリームのセグメントファイルに対するクエストを受け付ける用意ができておらず期待どおりのレスポンスを得られる可能性がないことを表す。cachedは、該ストリームのセグメントファイルは既にキャッシュ済みであり必ずレスポンスできることを表す。
【００９１】
図１１に戻る。拡張部分であるprobability要素は、供給可否情報に必須のものであり、status要素がavailableである場合に、status要素がavailableであるその他のリソースに対する相対的な受信確率を格納する。この比較対象範囲は、運用上の都合で決定できるものとする。
【００９２】
さらに、任意の文字列を格納できるreason要素は、供給可否情報にオプションとして追加することができ、チューナ部１１１による受信状態情報（例えば、C/N値等）を格納する。
【００９３】
次に、図１３は、供給可否情報として利用するために拡張したResourceStatusの第２のデータ構造を示している。該第２のデータ構造は、DASHにおけるストリームをRepresentationIDによって指定するものである。
【００９４】
repID要素には、DASHにおけるストリームを指定するためのパラメタ（識別子）としてRepresentationIDを格納する。status要素、probability要素およびreason要素については、第１のデータ構造と同様なので、その説明は省略する。
【００９５】
図１４は、供給可否情報として利用するために拡張したDaneResourceStatusのデータ構造を示している。
【００９６】
status要素には、次に説明するresource要素に格納されたURIよって指定されるストリームのセグメントファイルのキャッシングの状態を表す情報（図１５）を格納する。供給可否情報のstatus要素により、これを受け取ったDASHクライアント部１４０では、該ストリームのセグメントファイルのavailability(利用可能可否)を知ることができる。
【００９７】
図１５は、status要素に格納される情報の具体例を示している。cachedは、該ストリームのセグメントファイルは既にキャッシュされており、必ずレスポンスできることを表す。unavailableは、該ストリームのセグメントファイルリクエストを受け付ける用意ができておらず期待どおりのレスポンスを得られる可能性がないことを表す。unknownは、該ストリームのセグメントファイルリクエストを受け付ける用意があるが、そのリクエストはオリジンサーバ(オリジナルのDASHサーバ)に中継され、その結果、期待どおりのレスポンスを得られるか否かについては保証できないことを表す。promisedは、該ストリームのセグメントファイルリクエストを受け付ける用意があり、かつ、MPDに記載どおりの時間にレスポンスが得られる可能性があることを表す。
【００９８】
図１４に戻る。resource要素には、status要素に格納されている状態に対応するストリームを表すURIを格納する。byte要素には、resourceが表わすストリームのうち、status要素に格納されている状態に対応する範囲を表す値を格納する。resourceGroup要素には、status要素に格納されている状態に対応するリソースのグループを表す情報を格納する。
【００９９】
拡張部分であるprobability要素は、供給可否情報に必須のものであり、status要素がpromisedである場合に、status要素がpromisedであるその他のリソースに対する相対的な受信確率を格納する。この比較対象範囲は、運用上の都合で決定できるものとする。
【０１００】
さらに、任意の文字列を格納できるreason要素は、供給可否情報にオプションとして追加できるものであり、チューナ部１１１による受信状態情報（例えば、C/N値等）を格納する。
【０１０１】
＜供給可否情報におけるProbability表現の例について＞
次に、供給可否情報におけるProbability表現の例を、プロキシサーバ部１３０からDASHクライアント部１４０に供給可否情報としてのSANDメッセージが供給されるときの動作とともに説明する。
【０１０２】
図１６は、プロキシサーバ部１３０からDASHクライアント部１４０に供給可否情報としてのSANDメッセージが供給されるときの動作を説明するフローチャートである。
【０１０３】
ステップＳ１において、DASHクライアント部１４０がMPDを取得、解析し、プロキシサーバ部１３０に対してMPDに記述されていたセグメントを供給するセグメントリクエストを送信する。
【０１０４】
ステップＳ２において、プロキシサーバ部１３０は、DASHクライアント部１４０からのセグメントリクエストに応じて、DASHクライアント部１４０に提供するための供給可否情報としてのSANDメッセージ（PERメッセージ）を生成する。
【０１０５】
具体的には、以前に行われた該DASHクライアント部１４０とのセグメントファイルのリクエストとそのレスポンスのやりとり(セグメントファイルトランザクションと称する）、または、他のDASHクライアント装置(例えば、LAN２０を介して接続されているDASHクライアント装置２００)のDASHクライアント部１４０とのセグメントファイルトランザクションにより、既にプロキシサーバ部１３０にキャッシュされているセグメントファイルの記録や、放送受信部１１０の受信状況から推測される受信可能性に基づき、該DASHクライアント部１４０から要求されたセグメントファイル以降のファイルについて、リクエストされる可能性が高い(比較対象とする)複数のストリームのそれぞれについての供給可否情報としてのSANDメッセージを生成する。
【０１０６】
このとき、プロキシサーバ部１３０が過去にDASHクライアント部１４０に対して提供したMPDを知っていれば、要求されたセグメントファイルと、そのMPDに列挙されているBaseURLを比較して、これ以降に要求される可能性があるセグメントシーケンスを絞って、それらについてのみの相対的に受信確率をSANDメッセージに記載する。
【０１０７】
さらに、プロキシサーバ部１３０は、生成したSANDメッセージを格納したurlを、セグメントリクエストに対するレスポンスのヘッダに格納して返答する。このレスポンスのボディには、要求されたセグメントファイルのバイナリデータ（mp4ファイル）が格納される。
【０１０８】
ステップＳ３において、DASHクライアント部１４０は、受信したレスポンスのボディに格納されているmp4ファイルをデコードし、レンダリングすることにより、要求したストリームの再生を実行する。次に、ステップＳ４において、DASHクライアント部１４０は、受信したレスポンスのヘッダに格納されているurlに基づき、プロキシサーバ部１３０に対して供給可否情報としてのSANDメッセージを要求する。
【０１０９】
ステップＳ５において、プロキシサーバ部１３０は、この要求に応じ、ステップＳ２で生成した供給可否情報としてのSANDメッセージを返答する。
【０１１０】
ステップＳ６において、DASHクライアント部１４０は、受信した供給可否情報としてのSANDメッセージのprobabilityなどを参照し、そこに格納されている相対的な受信確率に基づき、これ以降に要求するストリームを選択し、選択に対応したセグメントリクエストをプロキシサーバ部１３０に送信する。
【０１１１】
ステップＳ７において、プロキシサーバ部１３０は、DASHクライアント部１４０からのセグメントリクエストに応じ、要求されたセグメントファイルのバイナリデータ（mp4ファイル）をボディに格納したレスポンスを、要求元のDASHクライアント部１４０に供給する。ステップＳ８において、DASHクライアント部１４０は、受信したレスポンスのボディに格納されているmp4ファイルをデコードし、レンダリングすることにより、要求したストリームの再生を実行する。
【０１１２】
なお、プロキシサーバ部１３０は、DASHクライアント部１４０からのセグメントリクエストを受信する毎に供給可否情報としてのSANDメッセージを生成してもよいし、セグメントリクエストを所定の回数だけ受信する毎に生成するようにしてもよい。
【０１１３】
なお、図１６の動作例では、DASHクライアント部１４０は、初めに低解像度のi-Videoのストリームを要求しており、供給可否情報としてのSANDメッセージにおける比較対象としては、３種類のストリーム（r-Video（中解像度）、n-Video（高解像度）、i-Video（低解像度））が選択されている。このうち、r-Videoとn-Videoのstatusがavailableであり、その相対的な受信確率はそれぞれ８０％，２０％とされている。また、i-Videoのstatusはcachedである。
【０１１４】
ここで、例えば、DASHクライアント部１４０が、解像度とロバスト性の両方を重視するように設定されている場合、供給可否情報を取得したDASHクライアント部１４０は、受信対象を低画質のi-Videoから、まだキャッシュされていないが相対的な受信確率が高い中画質のr-Videoのストリームにセグメントリクエストを変更して送信することができる。
【０１１５】
＜供給可否情報のreason要素について＞
次に、図１７は、供給可否情報としてのSANDメッセージの他の例であり、オプションとして記述可能なreason要素にチューナ部１１１の受信状態情報が格納されている場合を示している。
【０１１６】
reason要素には、データ構造として、SchemeIdUri(必須)とValue(オプショナル)の組を格納するようにする。SchemeIdUriには、受信状態を示すメトリクスを識別するURIを指定して、そのURIで規定される値の内容をvalueに記載できるようにする。
【０１１７】
例えば、放送や携帯電話の端末の物理層信号品質を表すメトリクスには、代表的なものとして、電波強度に関するものと、ビット誤り率(BER)に関するものがある。
【０１１８】
電波強度の例としては、搬送波対雑音比(C/N比)、受信信号強度等がある。ビット誤り率の例としては、リード・ソロモン(RS)等の誤り訂正処理(放送/通信方式によって異なる)前/後のビット誤り率(BER before/after RS)や、トランスポート・ブロックの誤り率(BLER)等がある。
【０１１９】
このうち、C/N比を状態情報指標に用いる場合には、
schemeIdUri=’urn:CarrierToNoiseRatio’(C/Nを示す識別子。各種標準仕様(後述)で規定するメトリクスも一意に指定できるようにする)として、
その値を以下のように記述する。
value=’10db’（C/N比の値10dB）
【０１２０】
そして、reason要素には、以下のようにReceptionQualityという要素から始まる構造を持った文字列をbase64方式でエンコードした文字列を格納する。ReceptionQuality要素の中にschemeIdUri属性と対応するvalue属性を格納できるように拡張する。
Reason=’(base64方式でエンコードされた
<ReceptionQuality schemeIdUri=’ urn:CarrierToNoiseRatio’ value=’10db’/>
)の列‘
【０１２１】
具体的には、以下のように記述する。
reason=’PFJlY2VwdGlvblF1YWxpdHkgc2NoZW1lSWRVcmk94oCZIHVybjpDYXJyaWVyVG9Ob2lzZVJhdGlv4oCZIHZhbHVlPeKAmTEwZGLigJkvPg==’
【０１２２】
このように、品質を具体的なメトリクスの名前と値として記述できるようにすることにより、reason要素の中身を解釈できるDASHクライアント部１４０は、複数のパスの中から自身の判断基準で(probability要素に格納された相対的な受信確率のみならず、例えば、時系列に並べた供給可否情報のreason要素に格納されているメトリクスの値の遷移から推測される近い将来の受信状態情報により)、後続の当該セグメントファイルシーケンスの取得を指示することができるようになる。
【０１２３】
以下、物理層信号品質を表すメトリクスの具体例を挙げる。
【０１２４】
DVB 衛星放送/ケーブル・テレビ共通メトリクス
ETSI TR 101 290 V1.2.1 (2001-05), “Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems”
【０１２５】
DVB 衛星放送用メトリクス
ETSI TR 101 290 V1.2.1 (2001-05), “Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems”
【０１２６】
地上放送(DVB-T2)用メトリクス
DVB BlueBook A14-2 (07/12), “Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems; Amendment for DVB-T2 System”
【０１２７】
ケーブル・テレビ(DVB-C2)用メトリクス
DVB BlueBook A14-3 (03/13), “Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems; Amendment for DVB-C2 System”
【０１２８】
LTE(E-UTRA)端末用メトリクス
ETSI TS 136 214 V11.1.0 (2013-02); “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; Measurements (3GPP TS 36.214 version 11.1.0 Release 11)”
【０１２９】
メトリクスの名前を特定するには、例えば、DVB 衛星放送/ケーブル・テレビ共通メトリクス(ETSI TR 101 290 V1.2.1 (2001-05), “Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems”)の6.3 BER before RS decoder に規定されるメトリクスの場合には、schemeIdUri=”urn:ETSI-TR-101-290-V1-2-1-Measurement-guidelines-for-DVB-systems:BER-before-RS-decoderとして、値をvalueに格納する。
【０１３０】
＜DANEに実装されるPHY/MAC層の構成例＞
図１８は、図１７に示されたSANDメッセージを生成、供給するDANE（プロキシサーバ部１３０）に接続されるネットワークモジュールとしてのPHY/MAC層の第１の構成例を示している。
【０１３１】
該第１の構成例は、DANEに対し、PHY/MAC層として放送受信部１１０、および通信部１２０が接続されている。
【０１３２】
該第１の構成例における放送受信部１１０は、ATSC3.0の放送波の所定の周波数帯域により提供されるデータパイプの中に２種類の異なる転送信頼性を持つデータパイプ(高ロバストなデータパイプ、および低ロバストなデータパイプ)からセグメントファイルを受信できる。
【０１３３】
通信部１２０は、EthernetまたはWiFi等により接続されるインターネット上に形成されたCDN１２上に確立される中ロバストなデータパイプからセグメントファイルを受信できる。
【０１３４】
図１９は、図１７に示されたSANDメッセージを生成、供給するDANE（プロキシサーバ部１３０）に接続されるネットワークモジュールとしてのPHY/MAC層の第２の構成例を示している。
【０１３５】
該第２の構成例は、DANEに対して、PHY/MAC層として放送受信部１１０、通信部１２０、および、モバイル通信部（3GPP-LTE RFモジュール）１６０が接続されている。
【０１３６】
該第２の構成例における放送受信部１１０は、ATSC3.0の放送波の所定の周波数帯域により提供されるデータパイプの中にある高ロバストなデータパイプからセグメントファイルを受信できる。
【０１３７】
モバイル通信部１６０は、携帯電話通信網の3GPP-LTEの基地局と接続されるチャネル上に3GPP-MBMS(Multimedia Broadcast/Multicast Service) のプロトコルで提供される放送トランスポートセッションにある低ロバストなデータパイプからセグメントファイルを受信できる。
【０１３８】
通信部１２０は、EthernetまたはWiFi等により接続されるインターネット上に形成されたCDN１２上に確立される中ロバストなデータパイプからセグメントファイルを受信できる。
【０１３９】
＜reason要素を含む供給可否情報としてのSANDメッセージを生成する処理＞
次に、プロキシサーバ部１３０(DANE)が、ネットワークモジュールからの情報に基づいて、reason要素を含む供給可否情報としてのSANDメッセージを生成する処理について説明する。
【０１４０】
図２０は、ネットワークモジュールが図１８に示された２種類の異なる転送信頼性を持つデータパイプ(高ロバストなデータパイプ、および低ロバストなデータパイプ)を有する放送受信部１１０である場合の、供給可否情報としてのreason要素を含むSANDメッセージを生成する処理を説明するフローチャートである。
【０１４１】
ステップＳ１１において、DASHクライアント部１４０が、既に取得しているMPDを解析し、プロキシサーバ部１３０に対してセグメントリクエストを送信すると、ステップＳ１２において、プロキシサーバ部１３０は、放送受信部１１０に対して受信状態の計測を要請する。この要請に応じ、ステップＳ１３において、放送受信部１１０は、それぞれのデータパイプにおける受信状態を計測して、その計測結果をプロキシサーバ部１３０に通知する。
【０１４２】
この通知を受けたプロキシサーバ部１３０は、ステップＳ１４において、reason要素に各データパイプの受信状態を記述した供給可否情報としてのSANDメッセージを生成する。ステップＳ１５において、プロキシサーバ部１３０は、生成したSANDメッセージを格納したurlを、セグメントリクエストに対するレスポンスのヘッダに、要求されたセグメントファイルのバイナリデータ（mp4ファイル）をボディに格納したレスポンスをDASHクライアント部１４０に送信する。
【０１４３】
ステップＳ１６において、DASHクライアント部１４０は、受信したレスポンスのボディに格納されているmp4ファイルをデコードし、レンダリングすることにより、要求したストリームの再生を実行する。また、DASHクライアント部１４０は、受信したレスポンスのヘッダに格納されているurlに基づき、プロキシサーバ部１３０に対して供給可否情報としてのSANDメッセージを要求する。
【０１４４】
この要求に応じ、ステップＳ１７において、プロキシサーバ部１３０は、ステップＳ１４で生成した供給可否情報としてのSANDメッセージを返答する。
【０１４５】
ステップＳ１８において、DASHクライアント部１４０は、受信した供給可否情報としてのSANDメッセージを参照し、これ以降に要求するストリームを選択し、選択に対応したセグメントリクエストをプロキシサーバ部１３０に送信する。この後、上述したステップＳ１２以降の処理が繰り返される。
【０１４６】
なお、時系列の供給可否情報を受信したDASHクライアント部１４０では、同じデータパイプの受信状態の遷移等にも基づいて、それ以降に要求するストリームを選択することができる。
【０１４７】
次に図２１は、ネットワークモジュールが図１９に示された、それぞれが１種類のデータパイプを有する放送受信部１１０と通信部１２０である場合の、供給可否情報としてのreason要素を含むSANDメッセージを生成する処理を説明するフローチャートである。
【０１４８】
ステップＳ２１において、DASHクライアント部１４０が、既に取得しているMPDを解析し、プロキシサーバ部１３０に対してセグメントリクエストを送信すると、ステップＳ２２において、プロキシサーバ部１３０は、放送受信部１１０および通信部１２０に対して受信状態の計測を要請する。この要請に応じ、ステップＳ２３において、通信部１２０は、自身のデータパイプにおける受信状態を計測して、その計測結果をプロキシサーバ部１３０に通知する。同様に、放送受信部１１０は、自身のデータパイプにおける受信状態を計測して、その計測結果をプロキシサーバ部１３０に通知する。
【０１４９】
この通知を受けたプロキシサーバ部１３０は、ステップＳ２４において、reason要素に各データパイプの受信状態を記述した供給可否情報としてのSANDメッセージを生成する。ステップＳ２５において、プロキシサーバ部１３０は、生成したSANDメッセージを格納したurlを、セグメントリクエストに対するレスポンスのヘッダに、要求されたセグメントファイルのバイナリデータ（mp4ファイル）をボディに格納したレスポンスをDASHクライアント部１４０に送信する。
【０１５０】
ステップＳ２６において、DASHクライアント部１４０は、受信したレスポンスのボディに格納されているmp4ファイルをデコードし、レンダリングすることにより、要求したストリームの再生を実行する。また、DASHクライアント部１４０は、受信したレスポンスのヘッダに格納されているurlに基づき、プロキシサーバ部１３０に対して供給可否情報としてのSANDメッセージを要求する。
【０１５１】
この要求に応じ、ステップＳ２７において、プロキシサーバ部１３０は、ステップＳ２４で生成した供給可否情報としてのSANDメッセージを返答する。
【０１５２】
ステップＳ２８において、DASHクライアント部１４０は、受信した供給可否情報としてのSANDメッセージを参照し、これ以降に要求するストリームを選択し、選択に対応したセグメントリクエストをプロキシサーバ部１３０に送信する。この後、上述したステップＳ２２以降の処理が繰り返される。
【０１５３】
なお、時系列の供給可否情報を受信したDASHクライアント部１４０では、同じデータパイプの受信状態の遷移等にも基づいて、それ以降に要求するストリームを選択することができる。
【０１５４】
次に、図２２および図２３は、ネットワークモジュールが、常時アクティブな２種類の異なる転送信頼性を持つデータパイプを有する放送受信部１１０と、例えば従量課金されるなどの理由によって通常は非アクティブなデータパイプを有するモバイル通信部１６０である場合の、供給可否情報としてのreason要素を含むSANDメッセージを生成する処理を説明するフローチャートである。
【０１５５】
DASHクライアント部１４０が、既に取得しているMPDを解析し、プロキシサーバ部１３０に対してセグメントリクエストを送信すると、プロキシサーバ部１３０は、放送受信部１１０に対して受信状態の計測を要請する。この要請に応じ、ステップＳ３１において、通信部１２０は、２種類のデータパイプそれぞれにおける受信状態を計測して、その計測結果をプロキシサーバ部１３０に通知する。
【０１５６】
この通知を受けたプロキシサーバ部１３０は、ステップＳ３２において、reason要素に各データパイプの受信状態を記述した供給可否情報としてのSANDメッセージを生成し、生成したSANDメッセージを格納したurlを、セグメントリクエストに対するレスポンスのヘッダに、要求されたセグメントファイルのバイナリデータ（mp4ファイル）をボディに格納したレスポンスをDASHクライアント部１４０に送信する。
【０１５７】
このｎ回目のレスポンスを受信したDASHクライアント部１４０は、そのボディに格納されているmp4ファイルをデコードし、レンダリングすることにより、要求したストリームの再生を実行するとともに、そのヘッダに格納されているurlに基づき供給可否情報としてのSANDメッセージを要求する。この要求に応じ、プロキシサーバ部１３０は、ステップＳ３２で生成した供給可否情報としてのSANDメッセージを返答する。
【０１５８】
SANDメッセージを受信したDASHクライアント部１４０は、供給可否情報としてのSANDメッセージを参照し、これ以降に要求するストリームを選択し、選択に対応したセグメントリクエストをプロキシサーバ部１３０に送信すると、上述したステップＳ３１およびＳ３２の処理と同様のステップＳ３３とＳ３４の処理が行われる。
【０１５９】
ｎ＋１回目のレスポンスを受信したDASHクライアント部１４０は、そのボディに格納されているmp4ファイルをデコードし、レンダリングすることにより、要求したストリームの再生を実行するとともに、そのヘッダに格納されているurlに基づき供給可否情報としてのSANDメッセージを要求する。この要求に応じ、プロキシサーバ部１３０は、２回目に生成した供給可否情報としてのSANDメッセージを返答する。
【０１６０】
ｎ＋１回目のSANDメッセージを受信したDASHクライアント部１４０は、供給可否情報としてのSANDメッセージを参照し、これ以降に要求するストリームを選択し、選択に対応したセグメントリクエストをプロキシサーバ部１３０に送信する。
【０１６１】
ただし、ｎ＋１回目に送信された供給可否情報とｎ回目に受信した供給可否情報を比較すると、放送受信部１１０の２種類のデータパイプはともにC/Nが80dbから30dbに低下しているので、今後、放送受信部１１０の受信状況が一層劣化してしまう可能性が有る。
【０１６２】
そこで、DASHクライアント部１４０では、他のネットワークモジュール（いまの場合、モバイル通信部１６０）の受信状態も確認するために、ステップＳ３５において、通常は非アクティブなモバイル通信部１６０をアクティベートする。
【０１６３】
アクティベートされたモバイル通信部１６０は、ステップＳ３６において、自身のデータパイプにおける受信状態を計測して、その計測結果をプロキシサーバ部１３０に通知する。
【０１６４】
なお、プロキシサーバ部１３０には、ステップＳ３７の処理として、通信部１２０から、２種類のデータパイプそれぞれにおける受信状態の計測結果が通知されている。そこで、この通知を受けたプロキシサーバ部１３０は、ステップＳ３８において、reason要素に各データパイプの受信状態を記述した供給可否情報としてのSANDメッセージを生成し、生成したSANDメッセージを格納したurlを、セグメントリクエストに対するレスポンスのヘッダに、要求されたセグメントファイルのバイナリデータ（mp4ファイル）をボディに格納したレスポンスをDASHクライアント部１４０に送信する。
【０１６５】
このｎ＋２回目のレスポンスを受信したDASHクライアント部１４０は、そのボディに格納されているmp4ファイルをデコードし、レンダリングすることにより、要求したストリームの再生を実行するとともに、そのヘッダに格納されているurlに基づき供給可否情報としてのSANDメッセージを要求する。この要求に応じ、プロキシサーバ部１３０は、ステップＳ３８で生成した供給可否情報としてのSANDメッセージを返答する。
【０１６６】
SANDメッセージを受信したDASHクライアント部１４０は、供給可否情報としてのSANDメッセージを参照し、これ以降に要求するストリームを選択し、選択に対応したセグメントリクエストをプロキシサーバ部１３０に送信することになる。
【０１６７】
なお、ｎ＋２回目に送信された供給可否情報では、ｎ＋１回目に受信した供給可否情報に比較して、放送受信部１１０の２種類のデータパイプのC/Nがさらに低下しているので、DASHクライアント部１４０は、この後に受信するストリームとしてモバイル通信部１６０が受信するi-Videoを選択することができる。
【０１６８】
以上に説明したように、クライアント装置１００のDASHクライアント部１４０は、同一のクライアント装置１００に内蔵されているプロキシサーバ部１３０から供給可否情報を取得できる。よって、供給可否情報を取得した後、設定されている条件（例えば、ロバスト性優先、画質優先等）に適したセグメントを要求することができる。
【０１６９】
また、クライアント装置１００に対してLAN２０を介して接続されているクライアント装置２００のDASHクライアント部１４０は、クライアント装置１１０に内蔵されているプロキシサーバ部１３０から供給可否情報を取得できる。よって、供給可否情報を取得した後、設定されている条件（例えば、ロバスト性優先、画質優先等）に適したセグメントを要求することができる。
【０１７０】
ところで、上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
【０１７１】
図２４は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
【０１７２】
該コンピュータ１１００において、CPU（Central Processing Unit）１１０１，ROM（Read Only Memory）１１０２，RAM（Random Access Memory）１１０３は、バス１１０４により相互に接続されている。
【０１７３】
バス１１０４には、さらに、入出力インタフェース１１０５が接続されている。入出力インタフェース１１０５には、入力部１１０６、出力部１１０７、記憶部１１０８、通信部１１０９、およびドライブ１１１０が接続されている。
【０１７４】
入力部１１０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１１０７は、ディスプレイ、スピーカなどよりなる。記憶部１１０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１１０９は、ネットワークインタフェースなどよりなる。ドライブ１１１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１１１１を駆動する。
【０１７５】
以上のように構成されるコンピュータ１１００では、CPU１１０１が、例えば、記憶部１１０８に記憶されているプログラムを、入出力インタフェース１１０５およびバス１１０４を介して、RAM１１０３にロードして実行することにより、上述した一連の処理が行われる。
【０１７６】
コンピュータ１１００（CPU１１０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１１１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
【０１７７】
コンピュータ１１００では、プログラムは、リムーバブルメディア１１１１をドライブ１１１０に装着することにより、入出力インタフェース１１０５を介して、記憶部１１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１１０９で受信し、記憶部１１０８にインストールすることができる。その他、プログラムは、ROM１１０２や記憶部１１０８に、あらかじめインストールしておくことができる。
【０１７８】
なお、コンピュータ１１００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであってもよい。
【０１７９】
なお、本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
【０１８０】
本開示は以下のような構成も取ることができる。
（１）
コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備え、
前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給し、
前記再生部は、生成された前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する
受信装置。
（２）
前記受信部は、放送網、双方向通信網、または携帯電話通信網を介して、前記セグメントファイルを受信する
前記（１）に記載の受信装置。
（３）
前記プロキシサーバ部は、前記受信部が受信した前記セグメントファイルをキャッシュするキャッシュ部を有し、前記再生部から要求された前記セグメントを前記キャッシュ部がキャッシュしている場合、前記キャッシュ部がキャッシュしている前記セグメントファイルを前記再生部に供給する
前記（１）または（２）に記載の受信装置。
（４）
前記プロキシサーバ部は、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを受信する際のデータパスに対する受信メトリクスおよび前記受信メトリクスの値をさらに含む前記供給可否情報を生成する
前記（１）から（３）のいずれかに記載の受信装置。
（５）
前記プロキシサーバ部は、SANDプロトコルによるResourceStatusメッセージを拡張した前記供給可否情報を生成する
前記（１）から（４）のいずれかに記載の受信装置。
（６）
前記プロキシサーバ部は、SANDプロトコルによるDaneResourceStatusメッセージを拡張した前記供給可否情報を生成する
前記（１）から（４）のいずれかに記載の受信装置。
（７）
前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じたレスポンスのヘッダに前記供給可否情報の取得先情報を格納するとともに、前記レスポンスのボディに前記セグメントファイルのバイナリデータを格納する
前記（１）から（６）のいずれかに記載の受信装置。
（８）
コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部と
を備える受信装置の受信方法において、
前記再生部による、前記プロキシサーバ部に対して前記セグメントファイルを要求する第１の要求ステップと、
前記プロキシサーバ部による、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給する供給ステップと、
前記再生部による、前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する第２の要求ステップと
を含む受信方法。
（９）
コンピュータを、
コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部として機能させ、
前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給し、
前記再生部は、生成された前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する
プログラム。
（１０）
所定のネットワークを介してコンテンツを供給する供給装置に接続された再生装置において、
前記供給装置が生成した供給可否情報に基づき、前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する要求部と、
前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生部とを備え、
前記供給装置は、
前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える
再生装置。
（１１）
前記所定のネットワークは、LANである
前記（１０）に記載の再生装置。
（１２）
所定のネットワークを介してコンテンツを供給する供給装置に接続された再生装置の再生方法において、
前記再生装置による、
前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する第１の要求ステップと、
前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生ステップと、
前記供給装置が生成した供給可否情報に基づき、次に再生する前記セグメントファイルを前記供給装置に対して要求する第２の要求ステップとを含み、
前記供給装置は、
前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える
再生方法。
（１３）
所定のネットワークを介してコンテンツを供給する供給装置に接続されたコンピュータを、
前記供給装置が生成した供給可否情報に基づき、前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する要求部と、
前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生部として機能させ、
前記供給装置は、
前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、
前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える
プログラム。
（１４）
所定のネットワークを介して再生装置にコンテンツを供給する供給装置において、
前記コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生装置に供給するプロキシサーバ部と
を備える供給装置。
（１５）
コンテンツのストリームを構成するセグメントファイルを受信する受信部を備え、
所定のネットワークを介して再生装置に前記セグメントファイルを供給する供給装置の供給方法において、
前記供給装置による、
前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成する生成ステップと、
前記受信部が受信した前記セグメントファイルを前記再生装置に供給する供給ステップと
を含む供給方法。
（１６）
所定のネットワークを介して再生装置にコンテンツを供給するコンピュータを、
前記コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生装置に供給するプロキシサーバ部と
して機能させるプログラム。
【符号の説明】
【０１８１】
１０  Broadcaster，  １１  放送網，  １２  CDN，  ２０  LAN，  １００  クライアント装置，  １１０  放送受信部，  １２０  通信部，  １３０  プロキシサーバ部，  １４０  DASHクライアント部，  ２００  クライアント装置，  ３００  DANE，  ４００  DASH client，  １６０  モバイル通信部
【図１】
2017212931.tif 000003
【図２】
2017212931.tif 000004
【図３】
2017212931.tif 000005
【図４】
2017212931.tif 000006
【図５】
2017212931.tif 000007
【図６】
2017212931.tif 000008
【図７】
2017212931.tif 000009
【図８】
2017212931.tif 000010
【図９】
2017212931.tif 000011
【図１０】
2017212931.tif 000012
【図１１】
2017212931.tif 000013
【図１２】
2017212931.tif 000014
【図１３】
2017212931.tif 000015
【図１４】
2017212931.tif 000016
【図１５】
2017212931.tif 000017
【図１６】
2017212931.tif 000018
【図１７】
2017212931.tif 000019
【図１８】
2017212931.tif 000020
【図１９】
2017212931.tif 000021
【図２０】
2017212931.tif 000022
【図２１】
2017212931.tif 000023
【図２２】
2017212931.tif 000024
【図２３】
2017212931.tif 000025
【図２４】
2017212931.tif 000026
【国際調査報告】
2017212931.tif 000027
2017212931.tif 000028