JPWO2017212931A1 - 受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラム - Google Patents

受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラム Download PDF

Info

Publication number
JPWO2017212931A1
JPWO2017212931A1 JP2018522412A JP2018522412A JPWO2017212931A1 JP WO2017212931 A1 JPWO2017212931 A1 JP WO2017212931A1 JP 2018522412 A JP2018522412 A JP 2018522412A JP 2018522412 A JP2018522412 A JP 2018522412A JP WO2017212931 A1 JPWO2017212931 A1 JP WO2017212931A1
Authority
JP
Japan
Prior art keywords
unit
segment file
supply
playback
proxy server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2018522412A
Other languages
English (en)
Inventor
山岸　靖明
靖明 山岸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Publication of JPWO2017212931A1 publication Critical patent/JPWO2017212931A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2183—Cache memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]

Landscapes

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

Abstract

本開示は、プロキシサーバ等からストリームの受信状態等を表す受信可否情報を取得することができるようにする受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラムに関する。
本開示の受信装置は、コンテンツのストリームを構成するセグメントファイルを受信する受信部と、受信した前記セグメントファイルを取得して再生する再生部と、セグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備え、前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給し、前記再生部は、生成された前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する。本開示は、ストリーム配信システムに適用できる。

Description

本開示は、受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラムに関し、特に、放送または配信されるコンテンツをキャッシングして他に供給するプロキシのコンテンツの受信状態を通知できるようにした受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラムに関する。
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， １６０ モバイル通信部

Claims (16)

  1. コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
    前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、
    前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備え、
    前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給し、
    前記再生部は、生成された前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する
    受信装置。
  2. 前記受信部は、放送網、双方向通信網、または携帯電話通信網を介して、前記セグメントファイルを受信する
    請求項１に記載の受信装置。
  3. 前記プロキシサーバ部は、前記受信部が受信した前記セグメントファイルをキャッシュするキャッシュ部を有し、前記再生部から要求された前記セグメントを前記キャッシュ部がキャッシュしている場合、前記キャッシュ部がキャッシュしている前記セグメントファイルを前記再生部に供給する
    請求項２に記載の受信装置。
  4. 前記プロキシサーバ部は、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを受信する際のデータパスに対する受信メトリクスおよび前記受信メトリクスの値をさらに含む前記供給可否情報を生成する
    請求項２に記載の受信装置。
  5. 前記プロキシサーバ部は、SANDプロトコルによるResourceStatusメッセージを拡張した前記供給可否情報を生成する
    請求項２に記載の受信装置。
  6. 前記プロキシサーバ部は、SANDプロトコルによるDaneResourceStatusメッセージを拡張した前記供給可否情報を生成する
    請求項２に記載の受信装置。
  7. 前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じたレスポンスのヘッダに前記供給可否情報の取得先情報を格納するとともに、前記レスポンスのボディに前記セグメントファイルのバイナリデータを格納する
    請求項２に記載の受信装置。
  8. コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
    前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、
    前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部と
    を備える受信装置の受信方法において、
    前記再生部による、前記プロキシサーバ部に対して前記セグメントファイルを要求する第１の要求ステップと、
    前記プロキシサーバ部による、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給する供給ステップと、
    前記再生部による、前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する第２の要求ステップと
    を含む受信方法。
  9. コンピュータを、
    コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
    前記受信部が受信した前記セグメントファイルを取得して再生する再生部と、
    前記受信部による前記セグメントファイルの受信状態に基づき、前記再生部が要求し得るセグメントファイルを前記再生部に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部として機能させ、
    前記プロキシサーバ部は、前記再生部からの前記セグメントファイルの要求に応じて、前記供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生部に供給し、
    前記再生部は、生成された前記供給可否情報に基づき、次に再生する前記セグメントファイルを前記プロキシサーバ部に要求する
    プログラム。
  10. 所定のネットワークを介してコンテンツを供給する供給装置に接続された再生装置において、
    前記供給装置が生成した供給可否情報に基づき、前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する要求部と、
    前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生部とを備え、
    前記供給装置は、
    前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、
    前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える
    再生装置。
  11. 前記所定のネットワークは、LANである
    請求項１０に記載の再生装置。
  12. 所定のネットワークを介してコンテンツを供給する供給装置に接続された再生装置の再生方法において、
    前記再生装置による、
    前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する第１の要求ステップと、
    前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生ステップと、
    前記供給装置が生成した供給可否情報に基づき、次に再生する前記セグメントファイルを前記供給装置に対して要求する第２の要求ステップとを含み、
    前記供給装置は、
    前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、
    前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える
    再生方法。
  13. 所定のネットワークを介してコンテンツを供給する供給装置に接続されたコンピュータを、
    前記供給装置が生成した供給可否情報に基づき、前記供給装置に対して前記コンテンツを構成するセグメントファイルを要求する要求部と、
    前記要求に応じて前記供給装置から供給された前記セグメントファイルを再生する再生部として機能させ、
    前記供給装置は、
    前記コンテンツのストリームを構成する前記セグメントファイルを受信する受信部と、
    前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するプロキシサーバ部とを備える
    プログラム。
  14. 所定のネットワークを介して再生装置にコンテンツを供給する供給装置において、
    前記コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
    前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生装置に供給するプロキシサーバ部と
    を備える供給装置。
  15. コンテンツのストリームを構成するセグメントファイルを受信する受信部を備え、
    所定のネットワークを介して再生装置に前記セグメントファイルを供給する供給装置の供給方法において、
    前記供給装置による、
    前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成する生成ステップと、
    前記受信部が受信した前記セグメントファイルを前記再生装置に供給する供給ステップと
    を含む供給方法。
  16. 所定のネットワークを介して再生装置にコンテンツを供給するコンピュータを、
    前記コンテンツのストリームを構成するセグメントファイルを受信する受信部と、
    前記再生装置からの前記セグメントファイルの要求に応じ、前記受信部による前記セグメントファイルの受信状態に基づき、前記再生装置が要求し得るセグメントファイルを前記再生装置に対して供給できる確率を含む供給可否情報を生成するとともに、前記受信部が受信した前記セグメントファイルを前記再生装置に供給するプロキシサーバ部と
    して機能させるプログラム。
JP2018522412A 2016-06-08 2017-05-25 受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラム Pending JPWO2017212931A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016114359 2016-06-08
JP2016114359 2016-06-08
PCT/JP2017/019494 WO2017212931A1 (ja) 2016-06-08 2017-05-25 受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラム

Publications (1)

Publication Number Publication Date
JPWO2017212931A1 true JPWO2017212931A1 (ja) 2019-04-04

Family

ID=60577810

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018522412A Pending JPWO2017212931A1 (ja) 2016-06-08 2017-05-25 受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラム

Country Status (7)

Country Link
US (1) US11159860B2 (ja)
JP (1) JPWO2017212931A1 (ja)
KR (1) KR102319932B1 (ja)
CN (1) CN109219962B (ja)
CA (1) CA3026233C (ja)
MX (1) MX2018014748A (ja)
WO (1) WO2017212931A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110945873B (zh) * 2017-06-02 2022-11-04 Vid拓展公司 下一代网络上的360度视频递送

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8599822B2 (en) 2005-03-23 2013-12-03 Cisco Technology, Inc. Slot-based transmission synchronization mechanism in wireless mesh networks
JP5405501B2 (ja) * 2010-02-25 2014-02-05 パナソニック株式会社 通信装置及び通信方法
JP5837621B2 (ja) * 2011-02-11 2015-12-24 インターデイジタル パテント ホールディングス インコーポレイテッド コンテンツの配信および受信の方法および装置
US9160779B2 (en) * 2011-06-30 2015-10-13 Qualcomm Incorporated Dynamic adaptive streaming proxy for unicast or broadcast/multicast services
US9357275B2 (en) 2011-09-06 2016-05-31 Qualcomm Incorporated Network streaming of coded video data
CN110087262B (zh) * 2011-10-21 2023-12-01 弗劳恩霍夫应用研究促进协会 无线资源管理设备及方法
US9712874B2 (en) * 2011-12-12 2017-07-18 Lg Electronics Inc. Device and method for receiving media content
US20150006621A1 (en) 2013-07-01 2015-01-01 Futurewei Technologies, Inc. Adaptive Video Streaming for Information Centric Networks
US10033824B2 (en) 2014-06-30 2018-07-24 Samsung Electronics Co., Ltd. Cache manifest for efficient peer assisted streaming
CN107637045B (zh) * 2015-06-16 2020-11-27 苹果公司 使用动态无线接入网信息的自适应视频流送
US10193994B2 (en) * 2015-06-18 2019-01-29 Qualcomm Incorporated Signaling cached segments for broadcast

Also Published As

Publication number Publication date
KR102319932B1 (ko) 2021-11-02
CN109219962A (zh) 2019-01-15
MX2018014748A (es) 2019-04-29
CA3026233A1 (en) 2017-12-14
CN109219962B (zh) 2021-07-20
US20190174205A1 (en) 2019-06-06
CA3026233C (en) 2023-10-17
US11159860B2 (en) 2021-10-26
WO2017212931A1 (ja) 2017-12-14
KR20190016020A (ko) 2019-02-15

Similar Documents

Publication Publication Date Title
JP6348251B2 (ja) 端末装置、受信方法、およびプログラム
WO2014196392A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JP6457931B2 (ja) コンテンツ供給装置、コンテンツ供給方法、コンテンツ受信装置、コンテンツ受信方法、プログラム、およびコンテンツ供給システム
WO2018079295A1 (ja) 情報処理装置、及び、情報処理方法
JPWO2016174960A1 (ja) 受信装置、送信装置、およびデータ処理方法
JPWO2016136489A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
KR102376204B1 (ko) 분배 장치, 분배 방법, 수신 장치, 수신 방법, 프로그램 및 콘텐츠 분배 시스템
CN105284118B (zh) 内容供应装置、内容供应方法、程序存储介质、终端装置和内容供应系统
JP6466850B2 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2017212931A1 (ja) 受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラム
WO2015029800A1 (ja) サーバ装置、情報処理方法、プログラム、端末装置、およびコンテンツ供給システム
KR102123208B1 (ko) 콘텐츠 공급 장치, 콘텐츠 공급 방법, 프로그램, 단말 장치, 및 콘텐츠 공급 시스템
WO2015041071A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2018012315A1 (ja) 情報処理装置、及び、情報処理方法
JP2015043484A (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015178221A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法