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

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

Info

Publication number
WO2018043134A1
WO2018043134A1 PCT/JP2017/029488 JP2017029488W WO2018043134A1 WO 2018043134 A1 WO2018043134 A1 WO 2018043134A1 JP 2017029488 W JP2017029488 W JP 2017029488W WO 2018043134 A1 WO2018043134 A1 WO 2018043134A1
Authority
WO
WIPO (PCT)
Prior art keywords
roi
distribution
segment file
unit
segment
Prior art date
Application number
PCT/JP2017/029488
Other languages
English (en)
French (fr)
Inventor
山岸　靖明
高林　和彦
Original Assignee
ソニー株式会社
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 ソニー株式会社 filed Critical ソニー株式会社
Priority to CA3034585A priority Critical patent/CA3034585A1/en
Priority to EP17846142.2A priority patent/EP3509310B1/en
Priority to KR1020197004218A priority patent/KR102376204B1/ko
Priority to MX2019002296A priority patent/MX2019002296A/es
Priority to CN201780051300.4A priority patent/CN109644286B/zh
Priority to US16/328,542 priority patent/US10750243B2/en
Priority to JP2018537114A priority patent/JPWO2018043134A1/ja
Publication of WO2018043134A1 publication Critical patent/WO2018043134A1/ja
Priority to US16/932,110 priority patent/US11252478B2/en

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

Definitions

  • the present technology relates to a distribution device, a distribution method, a reception device, a reception method, a program, and a content distribution system, and in particular, broadcasts a high-priority image area such as a high possibility of being viewed by more users.
  • the present invention relates to a distribution device, a distribution method, a reception device, a reception method, a program, and a content distribution system that are suitable for use in distribution and distribution of other image areas on demand.
  • Non-Patent Document 1 As a standardization flow in Internet streaming such as IPTV, standardization of methods applied to VoD (Video on Demand) streaming by HTTP streaming and live streaming has been carried out, especially standardization in ISO / IEC / MPEG. DASH (Dynamic-Adaptive-Streaming-over-HTTP) is attracting attention (see, for example, Non-Patent Document 1).
  • the imaging space is divided into a plurality of rectangular areas to take an image, and each rectangular area video is assigned to a DASH AdaptationSet to provide a free viewpoint style streaming service.
  • the free-viewpoint streaming service is realized by combining broadcast distribution and on-demand distribution (hereinafter also referred to as “net distribution”), a video that is highly likely to be viewed by many end users (reception device users) in common. If a stream is provided by broadcast distribution and a video stream that is unlikely to be viewed by many users in common is provided by network distribution, distribution resources can be effectively used.
  • a video that is likely to be viewed by many users in common is a video of the entire imaging range or a ROI (Region Of Interest) area (one or a plurality of adjacent rectangles) designated by a broadcasting station or the like. Image).
  • a video that can be viewed by a specific user is unlikely to be viewed in common by many users, and is a video in other rectangular areas.
  • a user can view only a moving image of an area of interest in an imaging space by specifying an arbitrary rectangular area (or a plurality of adjacent rectangular areas). It becomes.
  • DASH when DASH is adopted in the next US digital television standard ATSC3.0 and the above-mentioned free viewpoint style streaming service is realized, it indicates whether the video of each rectangular area is broadcasted or distributed on the Internet. If the distribution mode information and the ROI identifier of the video in each rectangular area (information indicating which ROI belongs to) can be recognized at the level of broadcast signaling, broadcast distribution resources (bandwidth and reception stack) It can be used as an index for assigning priorities.
  • the present technology has been made in view of such a situation, and makes it possible to signal an ROI identifier of a video distributed by at least one of broadcast distribution and net distribution.
  • the distribution device includes a segment file unit configured to segment a video stream for each area obtained by imaging an imaging range divided into a plurality of areas, Corresponds to the area that forms the ROI when a segment unit of the video stream is supplied to the receiving side by at least one of network distribution or broadcast distribution, and when the ROI consisting of one or more of the areas is set in the imaging range And a notification unit for notifying the receiving side of the ROI identifier for specifying the ROI to which the ROI belongs.
  • the notification unit can notify the receiving side of distribution mode information indicating whether the segment file is distributed by net distribution or broadcast distribution as the attribute information regarding the segment file.
  • the notification unit can notify the receiving side of the attribute information related to the segment file described in MPD defined by DASH.
  • the notification unit can notify the attribute information about the segment file to the receiving side in USD.
  • the notification unit can notify the receiving side of the attribute information related to the segment file in EFDT.
  • the notification unit can describe the attribute information related to the segment file in the Entity header and notify the reception side.
  • the one or more ROIs can be set in the imaging range.
  • the distribution unit can distribute the segment file of the video stream corresponding to each of the areas on the Internet and broadcast the segment file corresponding to the area forming the ROI.
  • the distribution method includes a segment file conversion unit configured to segment a video stream for each area obtained by imaging an imaging range divided into a plurality of areas by a distribution device;
  • a segment file conversion unit configured to segment a video stream for each area obtained by imaging an imaging range divided into a plurality of areas by a distribution device;
  • a program includes: a segment filing unit configured to segment a video stream for each area obtained by imaging a computer with an imaging range divided into a plurality of areas; and the area A distribution unit that supplies a segment file of each video stream to the receiving side by at least one of net distribution or broadcast distribution, and an ROI that includes the one or more regions in the imaging range; As the attribute information related to the segment file corresponding to, the ROI identifier for specifying the ROI to which it belongs is made to function as a notification unit that notifies the receiving side.
  • the video stream for each area obtained by imaging the imaging range divided into a plurality of areas is segmented, and the segment file of the video stream for each area is
  • the ROI that is supplied to the receiving side by at least one of distribution or broadcast distribution and an ROI including one or more of the regions is set in the imaging range, the ROI to which the ROI belongs as attribute information regarding the segment file corresponding to the region forming the ROI
  • the receiver is notified of the ROI identifier for identifying.
  • a receiving apparatus when an ROI including one or more areas is set in an imaging range divided into a plurality of areas, includes a segment of a video stream corresponding to the area forming the ROI
  • An attribute unit related to a file and an analysis unit that acquires and analyzes the attribute information that includes at least the ROI identifier for identifying the ROI to which the file belongs, and a predetermined ROI identifier based on the analysis result of the attribute information
  • a request unit for requesting the segment file corresponding to the request an acquisition unit for acquiring the segment file corresponding to the requested predetermined ROI identifier via net distribution or broadcast distribution, and reproducing the acquired segment file And a playback unit.
  • the request unit can request the segment file corresponding to the ROI identifier specified by the operation from the user.
  • the request unit can request the segment file corresponding to the ROI identifier specified by the operation of specifying the subject on the screen.
  • the request unit can request the segment file corresponding to the ROI identifier specified by the operation of selecting subject metadata.
  • the attribute information may further include distribution mode information indicating whether the segment file is distributed by net distribution or broadcast distribution, and the acquisition unit is requested based on the distribution mode information.
  • the segment file corresponding to a predetermined ROI identifier can be acquired via net distribution or broadcast distribution.
  • the analysis result of the attribute information by the analysis unit can be notified to the request unit using a SAND message.
  • the reception method corresponds to a region that forms the ROI when an ROI including one or more regions is set in the imaging range divided into a plurality of regions by the reception device.
  • a requesting step for requesting the segment file corresponding to a predetermined ROI identifier an acquiring step for acquiring the segment file corresponding to the requested predetermined ROI identifier via net distribution or broadcast distribution, and the acquired A playback step of playing back the segment file.
  • the program according to the second aspect of the present technology is directed to a video stream corresponding to a region that forms the ROI when an ROI including one or more regions is set in an imaging range that is divided into a plurality of regions.
  • a request unit that requests the segment file corresponding to the ROI identifier, an acquisition unit that acquires the segment file corresponding to the requested predetermined ROI identifier via net distribution or broadcast distribution, and the acquired segment file To function as a playback unit for playing back.
  • attribute information is analyzed, a segment file corresponding to a predetermined ROI identifier is requested based on the analysis result of the attribute information, and the requested corresponding ROI identifier is A segment file is acquired via net distribution or broadcast distribution, and the acquired segment file is reproduced.
  • a content distribution system in a content distribution system including a distribution device and a reception device, for each area obtained by the distribution device imaging an imaging range divided into a plurality of regions.
  • a segment file conversion unit that converts the video stream into a segment file
  • a distribution unit that supplies the segment file of the video stream for each area to the reception side by at least one of net distribution or broadcast distribution, and one or more in the imaging range
  • the notification unit is configured to notify the receiving side of the ROI identifier for identifying the ROI to which the ROI belongs as attribute information regarding the segment file corresponding to the region constituting the ROI.
  • the receiving device an analysis unit that analyzes the attribute information notified from the distribution device, a request unit that requests the segment file corresponding to a predetermined ROI identifier based on the analysis result of the attribute information, An acquisition unit that acquires the segment file corresponding to the requested predetermined ROI identifier via network distribution or broadcast distribution, and a reproduction unit that reproduces the acquired segment file.
  • the video stream for each area obtained by imaging the imaging range divided into a plurality of areas by the distribution device is segmented into files, and the video stream for each area is
  • a segment file is supplied to the receiving side by at least one of network distribution or broadcast distribution and an ROI composed of one or more of the areas is set in the imaging range, as attribute information regarding the segment file corresponding to the area forming the ROI .
  • the ROI identifier for specifying the ROI to which it belongs is notified to the receiving side.
  • the attribute information notified from the distribution device is analyzed by the receiving device, the segment file corresponding to the predetermined ROI identifier is requested based on the analysis result of the attribute information, and the requested predetermined ROI identifier is supported.
  • the segment file to be acquired is acquired via net distribution or broadcast distribution, and the acquired segment file is reproduced.
  • the ROI identifier of the video distributed at least one of broadcast distribution and net distribution.
  • a segment file belonging to a specific ROI can be acquired and played back.
  • the receiving side acquires a segment file of an area belonging to a specific ROI. Can play.
  • FIG. 10 is a diagram illustrating a configuration of a service signaling transport session and a component file transport session corresponding to an extended Entity header.
  • FIG. 11 is a block diagram illustrating a configuration example of a general-purpose computer.
  • FIG. 1 shows a configuration example of a content distribution system adopting DASH.
  • the Media Presentation on HTTP Server shown on the left side of the figure is the content distribution side
  • the HTTP Streaming Client shown on the right side of the figure is the content receiving side, receives the received content stream, plays it, and presents it to the user can do.
  • the Media-Presentation-on-HTTP Server on the delivery side has the same content, and is a path for terrestrial digital broadcasting, satellite broadcasting, etc., bidirectional communication networks such as the Internet, mobile phone communications such as 3GPP and LTE-eMBMS It is possible to prepare and supply a plurality of streams in which the image quality, the angle of view size, and the like are changed according to the network communication environment and the reception side capability and status.
  • the Media Presentation Server HTTP server can be used to display a video of the entire imaging area of the same content, a video of each rectangular area divided into a plurality of imaging areas, that is, videos belonging to the same content but having different contents, It is possible to prepare and supply a plurality of streams in which the image quality, the angle of view size, and the like are changed according to the capability and state of the receiving side.
  • the HTTP Streaming Client on the receiving side can select and acquire and play the optimum stream according to the communication environment of the path and the capabilities and status of the receiving side among the multiple streams prepared on the delivery side. it can.
  • MPD Media Presentation Description
  • the address (url information) of the chunked stream (media data such as Audio / Video / Subtitle) is described, and the receiving side is based on the url information to determine a predetermined content source. It is possible to access the server and acquire and play streaming data distributed via HTTP.
  • the HTTP Streaming Client on the receiving side which is overwhelmingly larger than the distribution side, requests the same stream from the same server as the content supply source.
  • a so-called proxy server may be provided on the Internet or the like because the communication efficiency is poor if the same stream is transmitted each time it is supplied from each HTTP Streaming Client.
  • FIG. 2 shows the data structure of MPD as metadata supplied from the content distribution side to the reception side.
  • Each Period has an AdaptationSet that groups multiple Representations consisting of information related to synchronized streaming data with the same content and different stream attributes such as bit rate with changed image quality, angle of view size, language, etc. ing. Representation stores information about a segment obtained by further dividing the period.
  • Period is a unit of content time division.
  • the Segment is a unit obtained by subdividing the Period in terms of time, and the content stream is filed in a Segment file in Segment units.
  • Segment file is specified by URL (+ byte range). Segment is a part of Representation, and one Representation is composed of any of the following. (1) One or more SegmentLists (2) One SegmentTemplate (3) One or more BaseURLs and at most one SegmentBase (In this case, SegmentList and SegmentTemplate are not included)
  • FIG. 3 shows an example of representation corresponding to the above (1) to (3).
  • the SegmentBase in (3) above is used when there is only one MediaSegment in one Representation, as shown in FIG.
  • the byte sequence of initialization information and the byte sequence of Random Access Points (RAP) are contained within the first 834 bytes of the file (described in the IndexRange of SegmentBase).
  • the SegmentList in (1) above is composed of a plurality of SegmentURLs arranged in the playback order as shown in FIG. SegmentURL is expressed by the URL of the Segment file (+ the byte range within the file). Initilization arranged at the beginning of the SegmentList indicates a file (InitSegment) in which initialization information is stored.
  • the SegmentTemplate in (2) above is used when a SegmentURL is automatically generated based on the SegmentTemplate (live streaming is a typical use case). That is, on the receiving side, a complete list of SegmentURLs is generated by dynamically replacing predetermined parameters included in the SegmentURL template described in the SegmentTemplate.
  • SegmentTemplate By using SegmentTemplate, the MPD size can be made very small.
  • Fig. 4 shows the hierarchical structure under Period in MPD.
  • the MPD is described in XML format, for example.
  • AdaptationSet which is information for grouping Representation groups to be a stream selection range
  • Representation including information indicating the bit rate, angle of view size, language, etc. of moving images and audio
  • Segmentinfo which is information related to a segment of video or audio
  • an Initialization Segment indicating initialization information such as a data compression method and a Media Segment indicating a source of data in segment units of moving images and audio are described.
  • FIG. 5 shows a state where MPD structures are arranged on the time axis. As is clear from the figure, the segments of Representations with different stream attributes included in the same AdaptationSet are synchronized.
  • the video of the entire imaging area of the same content and the video stream of each rectangular area obtained by dividing the imaging area into a plurality belong to different AdaptationSets, but even in this case, each Representation included in different AdaptationSets The Segments will be in sync with each other.
  • FIG. 6 shows a more detailed configuration example of a content distribution system adopting DASH.
  • the DASH server, Web server, and broadcast server in FIG. 6 correspond to Media Presentation HTTP Server in FIG. Further, the DASH client in FIG. 6 corresponds to HTTP Streaming Client in FIG.
  • DASH client can access DASH server and Web server via CDN (Content Delivery Network) formed on the Internet.
  • CDN Content Delivery Network
  • the CDN is provided with a DASH cache server (proxy server).
  • the DASH server generates an MPD and transfers it to the broadcast server, and also generates a segment file of the stream and transfers it to the Web server. Also, the DASH server distributes the generated MPD via a CDN (Content Delivery Network) in response to an HTTP request from the DASH client. In response to an HTTP request from a DASH client that has selected a stream acquisition destination with reference to the MPD, the Web server distributes a Segment file via the CDN via the Internet.
  • the broadcast server broadcasts MPD. The broadcast server broadcasts and distributes the Segment file.
  • the DASH cache server monitors the CDN and temporarily caches the Segment file distributed via the CDN to the DASH client.
  • the DASH cache server delivers the cached segment file to the requesting MPD client on behalf of the web server. To do.
  • the DASH cache server can temporarily cache not only the segment file of the stream but also the MPD, and can supply the cached MPD to the requesting DASH client instead of the DASH server.
  • the DASH cache server may receive and cache MPD and Segment files that are broadcast and distributed.
  • the content distribution system can improve the efficiency of HTTP streaming distribution to the majority of DASH clients.
  • FIG. 7 shows a configuration example of a client device on the receiving side when DASH is adopted in ATSC 3.0 and a free viewpoint streaming service is realized.
  • the client device 100 can also be applied to a case where a streaming delivery service adopting DASH in a standard other than ATSC 3.0 is realized.
  • the client device (3.0 Client (with ATSC3.0 PHY / MAC)) 100, for example, is installed in a television receiver, video recorder, or set-top box installed in a general house or mounted on a moving body such as an automobile. It is assumed that
  • the client device 100 includes a broadcast receiving unit (Client ATSC Middleware) 110, a communication unit (Ethernet / WiFi etc.) 120, a proxy server unit (Client Local HTTP Proxy Server) 130, and a DASH client unit (3.0 DASH Client) 140. .
  • a broadcast receiving unit (Client ATSC Middleware) 110
  • a communication unit (Ethernet / WiFi etc.) 120
  • a proxy server unit Client Local HTTP Proxy Server
  • DASH client unit (3.0 DASH Client) 140. .
  • the broadcast receiving unit 110 performs a process of receiving, from the Broadcaster 10 (corresponding to the broadcast server in FIG. 6), an MPD, a stream segment file, an SLS file, and the like distributed via the broadcasting network 11 such as digital terrestrial broadcasting or satellite broadcasting. Execute.
  • the broadcast receiving unit 110 receives a broadcast wave, a tuner 111, a Segment Retriever 112 that extracts a segment file from the broadcast wave, an LLS Signaling Retriever 113 that extracts an LLS (Low Level Signaling) file from the broadcast wave, and an LLS that analyzes an LLS file.
  • Signaling Parser 114 is provided.
  • the broadcast receiving unit 110 includes an SLS Signaling Retriever 115 that extracts an SLS (Service Layer Signaling) file from the broadcast wave, and an SLS Signaling Parser 116 that analyzes the SLS file.
  • the communication unit 120 requests an MPD, a stream segment file, and an SLS file from the broadcaster 10 (corresponding to the DASH server and Web server in FIG. 6) via the CDN 12 formed in a bidirectional communication network such as the Internet. (Sends an HTTP request), and executes the process to receive the MPD and Segment files distributed by HTTP accordingly.
  • the proxy server unit 130 responds to requests from the Proxy Cache 131 that caches various files received via the broadcast network 11, the Proxy Cache 132 that caches various files received via the CDN 12, and the DASH client unit 140. Broadcast / Broadband Address Resolver 133 is provided.
  • the Broadcast / Broadband Address Resolver 133 executes a process of supplying MPD and Segment files cached in the Proxy Cache 131 or 132 in response to a request from the DASH client unit 140.
  • the Broadcast / Broadband Address Resolver 133 executes processing for notifying the DASH client unit 140 of supply availability information indicating the reception status of the Segment file by the broadcast receiving unit 110 and the communication unit 120 using the PER message.
  • the Broadcast / Broadband Address Resolver 133 receives broadcast distribution combination information indicating whether each Segment file is broadcast distributed together with the Internet distribution, and, when each Segment file belongs to the ROI, an ROI identifier indicating its belonging.
  • the DASH client unit 140 is notified using the PER message. Details of the PER message will be described later.
  • the DASH client unit 140 requests and obtains an MPD, an MPDeverRetriever 141 that analyzes the MPD, an MPD Parser 142 that analyzes the MPD, requests and obtains a Segment file by referring to the MPD, and an MP4 Parser 144 that extracts and analyzes the MP4 data from the Segment file Is provided. Further, the DASH client unit 140 includes a Decoder 145 that decodes MP4 data, and a Renderer 146 that renders a decoding result.
  • the DASH client unit 140 is realized on a browser installed in the client device 100, for example. However, it may be realized not only as a browser application but also as a native application.
  • the DASH client unit 140 acquires the MPD, Segment file, SLS file, etc. received by the broadcast receiving unit 110 or the communication unit 120 via the proxy server unit 130, and performs stream rendering and application control to thereby generate a stream. A process of outputting the video and audio to a subsequent monitor (not shown) is executed.
  • the DASH client unit 140 can be mounted not only on the client device 100 but also on the client device 200 connected to the client device 100 via the LAN 20.
  • the client device 200 is assumed to be, for example, a smartphone or a tablet.
  • the DASH client unit 140 in the client device 200 is connected to the client device 100 via the LAN 20, and receives the MPD, Segment file, and SLS received by the broadcast receiving unit 110 or the communication unit 120 via the proxy server unit 130 of the client device 100.
  • the DASH client unit 140 in the client device 200 is connected to the client device 100 via the LAN 20, and receives the MPD, Segment file, and SLS received by the broadcast receiving unit 110 or the communication unit 120 via the proxy server unit 130 of the client device 100.
  • a supply apparatus having a configuration in which the DASH client unit 140 is omitted from the client apparatus 100 may be connected to the LAN 20.
  • the client apparatuses 100 and 200 can request the MPD or the Segment file from the supply apparatus.
  • the DASH client unit 140 in the client device 100 and the DASH client unit 140 in the client device 200 always acquire various files via the proxy server unit 130. Therefore, the DASH client unit 140 can realize so-called network transparency that does not need to be aware of whether the various files to be acquired are broadcast distribution via the broadcast network 11 or net distribution via the CDN 12. Therefore, since the DASH client unit 140 is highly portable, the DASH client unit 140 can be mounted even on a device that cannot receive a broadcast.
  • the proxy server unit 130 When the proxy server unit 130 is requested to acquire various files from the DASH client unit 140 (when receiving an HTTP request), the Broadcast / Broadband Address Resolver 133 acquires it via the broadcast network 11 or via the CDN 12. Judge whether to do. Information serving as a material for this determination is provided from the SLS signalling parser 116 of the broadcast receiving unit 110.
  • the SLS Signaling Parser 116 of the broadcast receiving unit 110 makes an acquisition request to the SLS Signaling Retriever 115 for USBD / USD, S-TSID, and the like, which are ATSC 3.0 signaling metadata.
  • the SLS / Signaling / Retriever 115 extracts signaling metadata carried by the SLS / LCT packet from the broadcast signal received by the tuner unit (ATSC 3.0 / PHY / MAC) 111.
  • the SLS Signaling Parser 116 acquires the signaling metadata from the url included in the Segment file acquisition request, and acquires the broadcast distribution address information for acquiring the target Segment file. If the target Segment file is broadcasted in the future, or if it is known that the target segment file has already been broadcasted, the segmentTLCT packet containing the target Segment file is acquired from the broadcast stream based on the broadcast distribution address information. To expand in the Proxy Cache 131 of the proxy server unit 130. Thereafter, the proxy server unit 130 returns the Segment file as a response to the HTTP request to the DASH client unit 140.
  • the proxy server unit 130 acquires the Segment file via the communication unit 120 and expands the acquired Segment file in the Proxy Cache 132. Thereafter, the proxy server unit 130 returns the Segment file as a response to the HTTP request to the DASH client unit 140.
  • FIG. 8 is a diagram for explaining the PER message.
  • the PER message is a message notified from the DANE (DASH-Aware Network Elements) 300 to the DASH Client 400.
  • DANE DASH-Aware Network Elements
  • the DANE 300 corresponds to the proxy server unit 130 of the DASH client device 100 shown in FIG.
  • the DASH client 400 corresponds to the DASH client unit 140 of the DASH client device 100.
  • SAND is a protocol for exchanging and providing various real-time network environment (distribution resource) information that can be provided from a DASH distribution component group managed by a network operator in order to effectively operate DASH.
  • PER is defined as a message protocol of a message (PER message) provided from DANE 300 to DASH Client 400.
  • Status is defined as a message protocol of a message (Status message) provided from DASH Client 400 to DANE 300.
  • the PER message or Status message is also referred to as a SAND message.
  • ResourceStatus a message called ResourceStatus and a message called DaneResourceStatus are defined as similar messages.
  • FIG. 9 is a diagram for explaining each element of ResourceStatus.
  • the Status element of ResourceStatus is expanded so that supply availability information can be stored, and the proxy server unit 130 notifies the DASH client unit 140 of the information.
  • the Reason element of ResourceStatus is expanded so that broadcast distribution combined information and ROI identifiers can be stored, and the DASH client unit 140 is notified from the proxy server unit 130.
  • the Reason element may further describe ROI sequence metadata represented by the ROI identifier (for example, a name of a player to be moved following the ROI sequence). It is assumed that the ROI series metadata represented by the ROI identifier is supplied to the client device 100 by broadcast distribution or net distribution.
  • the DASH client 400 that has received the ResourceStatus can select a DASHSegment file to be requested next based on the ResourceStatus. Since the expiration date is described in ResourceStatus, DASH client 400 can consider that the contents are valid until the expiration date of ResourceStatus.
  • ROUTE Real-Time Object Delivery over Unidirectional Transport
  • IP-based transport stack standardization work is underway, and files based on the MPEG-DASH file format (ISO-BMFF files, MP4 files) that are becoming mainstream in OTT distribution are FLUTE ( Transfer using the ROUTE protocol that extends File Delivery over Unidirectional Transport.
  • DASH fragmented MP4 fragmented MP4 file
  • DASH control metafile MPD DASH control metafile MPD
  • various signaling 3GPP-MBMS -USD (User Service Description) described later
  • the extended ATSC version of USD and the S-TSID that is the control metadata of the ROUTE protocol can be transferred.
  • Fig. 10 shows a ROUTE / DASH-based stack.
  • the ROUTE protocol is a protocol based on FLUTE, and the metadata file describing the transfer control parameters in FLUTE is called FDT (File Delivery Table), but the control metadata in ROUTE corresponding to FDT is S-TSID. (Service-based Transport Session Instance Description) (S-TSID /.../ EFDT is actually the closest).
  • FDT File Delivery Table
  • S-TSID Service-based Transport Session Instance Description
  • S-TSID describes transfer control metadata for all service components (video / audio / data component streams-all realized as file transfer sessions) transferred within a service (corresponding to a broadcast channel) To do.
  • the S-TSID itself is also transferred as a service signaling session in the ROUTE session.
  • the S-TSID is signaling metadata for a component file session transferred within one service, but the service signaling metadata transfer session address (service bootstrap address) for each service to which the S-TSID itself is transferred.
  • Signaling metadata called SLT Service List Table
  • SLT Service List Table
  • FIG. 11 is a diagram for explaining the operation on the client side corresponding to the case where the ROUTE protocol is used.
  • the client device 110 first obtains SLT, then obtains service signaling (Service Level Signaling) of a desired service from the service bootstrap address, and obtains and renders the service component itself constituting the service. Become.
  • service signaling Service Level Signaling
  • FIGS. 12 and 13 are diagrams illustrating an example in which the entire imaging space 510 is divided into a plurality of rectangular areas 511.
  • the entire imaging space 510 is divided into 36 rectangular areas 511. Note that (1, 1) and the like in the figure indicate the arrangement of the rectangular areas 511 in the entire imaging space 510.
  • areas 512A to 512D composed of a plurality of (4 in the case of FIG. 4) rectangular regions 511 are set in the central portion of the entire imaging space 510.
  • the entire stadium venue including the audience seats is the entire imaging space 510, and the stadium fields (grounds) are the areas 512A to 512D.
  • the stadium fields are the areas 512A to 512D.
  • the area following the movement is set to ROI 514 and changes as shown in FIG. 13A to FIG. 13C.
  • each of the images in the areas 512A to 512D is assigned to one AdaptationSet, and each of the images in each rectangular area 511 is assigned to the DASH AdaptationSet. Then, a segment corresponding to each of the images of the areas 512A to 512D, which is likely to be viewed by many users in common, and a segment corresponding to the image of the ROI 514 are broadcast. Then, the Segment corresponding to the video of the other rectangular area 511 is distributed on the net. However, in consideration of users who cannot receive broadcast distribution and missed broadcast distribution (reception mistakes), Segments belonging to all AdaptationSets also perform net distribution.
  • FIG. 14 shows whether segments corresponding to the images in the areas 512A to 512D and segments corresponding to the images in the respective rectangular areas 511 are broadcasted (colored in the drawing) or distributed on the net (FIG. 14). Colorless ones are shown.
  • the upper stage, the middle stage, and the lower stage of the figure correspond to A in FIG. 13, B in FIG. 13, and C in FIG.
  • the ROI 514 in FIG. 13A is composed of four rectangular areas 511 (2, 1, 2, 2, 3, 1, 3, 2), so areas 512A to 512D are shown in the upper part of FIG. Segments corresponding to the respective videos and segments corresponding to the four rectangular areas 511 (2, 1, 2, 2, 3, 1, 3, 2) are broadcast and distributed.
  • the ROI 514 in FIG. 13B is composed of four rectangular areas 511 (3, 2, 3, 3, 4, 2, 4, 3), so as shown in the middle of FIG. Segments respectively corresponding to 512D videos and segments corresponding to the four rectangular areas 511 (3, 2, 3, 3, 4, 2, 4, 3) are broadcast and distributed.
  • only one ROI that follows the ball 513 is set.
  • a plurality of ROIs such as an ROI that follows the movement of a leading player may be set.
  • the free viewpoint style streaming service can also be applied to mapping an equirectangular image often used in VR (Virtual Reality) to SRD (Spatial Relation Description), for example.
  • FIG. 15 shows an example in which the entire screen (or a predetermined area in the imaging range) may be divided into four rectangular areas.
  • the entire screen is divided into four rectangular areas, and the ROI is composed of one rectangular area, so that the entire screen and the four rectangular areas are arranged.
  • An example will be described in which each video is assigned to a DASH AdaptationSet and distributed.
  • AdaptationSet.1.t is a video stream of the entire screen
  • AdaptationSet.1-1.t to 1-4.t are the upper left, upper right, lower left, or lower right rectangles of the entire screen. This is a video stream for each area.
  • t is a parameter representing a time series.
  • roiId1 transitions from AdaptationSet.1-1.1 to AdaptationSet.1-2.2 and further from AdaptationSet.1-3.3.
  • roiId2 transitions from AdaptationSet.1-3.1 to AdaptationSet.1-2.2 and further from AdaptationSet.1-2.3.
  • roiId1 is assumed to have a higher degree of attention than roiId2, all Segments belonging to roiId1 are used together with broadcast distribution, and all Segments belonging to roiId2 are only distributed via the Internet.
  • Segments under AdaptationSet.1 are all broadcast distribution combined with net distribution and broadcast distribution, and a url for net distribution (for example, described by the url prefix "bb") is assigned, and a url for broadcast distribution (for example, url Prefix "bc") is assigned.
  • a url for net distribution for example, described by the url prefix "bb”
  • a url for broadcast distribution for example, url Prefix "bc”
  • Segments under AdaptationSet.1-1 to 1-4 are assigned a url for net distribution and a url for broadcast distribution only when each segment is broadcast. If broadcast distribution is not performed (that is, only net distribution), only the net distribution url is assigned.
  • an ROI identifier for identifying the ROI sequence is appropriately assigned.
  • FIG. 16 shows the broadcasting of Segments under AdaptationSet.1.t (eg, Segment.1.1) and Segments under AdaptationSet.1-1.t through 1-4.t (eg, Segment.1-1.1, etc.) Indicates the presence or absence of combined use and the ROI identifier.
  • Url (bbSeg.1-1.1) described under Segment.1-1.1, etc. means that Segment.1-1.1 is distributed over the Internet.
  • Url (bcSeg.1-1.1) means that Segment.1-1.1 is broadcast and distributed.
  • RoiIdentifier (roiId1) means that Segment.1-1.1 belongs to the ROI system of roiId1.
  • 2.Segment.1-2.2 belongs to roiId1 and roiId2, and is therefore used together with broadcast distribution.
  • the URL of each subordinate Segment is set to What is necessary is just to describe the url prefix added.
  • AdaptationSet / baseURL “http://a.com/bc”
  • AdaptationSet / Representation / SegmentList / SegmentURL @ media "/ segment11.mp4" for a given Segment belonging to it
  • the url of the segment is “http://a.com/bc/segment11.mp4”.
  • a roiId element is added to the SegmentURL attribute so that the ROI identifier for each Segment can be described.
  • the client device 100 can recognize the difference between broadcast distribution and net distribution by acquiring and analyzing the MPD.
  • the file can be acquired.
  • the Segment sequence may be acquired in the order of bcSeg.1.1 to bcSeg.1.2 and bcSeg.1.3 of the SegmentUrl.
  • the Segment sequence may be acquired in the order of bbSeg.1-3.1 to bcSeg.1-2.2 and bbSeg.1-2.3.
  • the broadcast distribution Segment is received or the Whether to receive a segment for distribution may be determined by the client device 100 according to its own reception status or the like.
  • FIG. 18 shows the entire image and the position and resolution of the rectangular area.
  • 19 and 20 show specific positions where the MPD is extended to describe the ROI identifier.
  • the roiId element for describing the ROI identifier is added to the attribute of MPD / Period / AdaptationSet / Representation / SegmentList / SegmentURL.
  • FIG. 21 shows a configuration of a service signaling transport session and a component file transport session corresponding to the extended MPD.
  • the service signaling session shown in FIG. 5A is a transport session for transferring SLS, which is a service layer signaling XML fragment.
  • the component file session shown in FIG. 5B is a transport session for transferring each video / audio / subtitle / application / other various data constituting the service. Detailed stream attributes of each component session are described in the SLS, and an address for acquiring the stream is also described.
  • the session is identified based on the TSI of the LCT packet on UDP / IP, and each file object transferred in the session is identified by the TOI of the LCT packet.
  • UserServiceDescription has an sTSIDUri attribute that stores the url (“stsid-url”) of the S-TSID file.
  • stsid-url the attribute of each component is described in S-TSID / RS / LS / srcFlow.
  • the proxy server unit 130 that receives the request obtains a request via the signaling retriever 113 and the signaling parser 114 of the ATSC 3.0 middleware 110.
  • a desired file is acquired from the acquired and analyzed SLS signaling fragment or EFDT, reconfigured, and the reconfigured file is returned as a response to the DASH client unit 140.
  • FIG. 22 shows an operation sequence when the delivery mode information and the ROI identifier are stored in the MPD.
  • the DASH server On the distribution side, the DASH server generates an MPD that describes the distribution mode information for each segment and appropriately stores the ROI identifier and transfers it to the broadcast server. In addition, the DASH server generates a segment file of the content stream and transfers it to the Web server, and also transfers to the broadcast server those that are used together with broadcast distribution.
  • the broadcast server to which the MPD has been transferred generates an SLS file and broadcasts the generated SLS file and the transferred MPD via a broadcast network.
  • the broadcast server broadcasts and distributes the segment file of the content stream transferred from the DASH server in the ROUTE FileMode.
  • the broadcast receiving unit 110 receives the MPD and SLS file distributed by broadcast. Thereafter, when the DASH client unit 140 requests MPD from the broadcast receiving unit 110, the broadcast receiving unit 110 supplies the MPD to the DASH client unit 140 in response to the request.
  • the communication unit 120 can issue the HTTP request to the DASH server and acquire the MPD distributed on the net.
  • the DASH client unit 140 can select a requested Segment based on the ROI identifier described in the MPD.
  • the communication unit 120 issues an HTTP request for requesting the segment to the web server and supplies it from the web server accordingly (net distribution)
  • the segment is received and supplied to the DASH client unit 140.
  • the DASH client unit 140 reproduces the supplied segment.
  • the broadcast receiving unit 11 receives the segment distributed by broadcast and supplies it to the DASH client unit 140.
  • the DASH client unit 140 reproduces the supplied segment.
  • FIG. 23 is a rewrite of the MPD-SRD representation shown in FIG. 17 using a SegmentTemplate.
  • FIG. 24 is a visualization of the MPD-SRD representation of FIG. However, the SegmentUrl and the ROI identifier in the broken line frame and the one-dot chain line frame in FIG. 24 represent portions that cannot be described in the MPD-SRD representation in FIG.
  • a broadcast distribution url and a net distribution url are specified for a certain segment in a segment sequence following the same period. It is not possible to specify only the net distribution url in the segment. Also, the ROI identifier cannot be specified only for a specific segment.
  • the distribution mode information of each segment can be signaled even with the conventional USD.
  • USD is tied to MPD, and in USD bundleDescriptionROUTE / userServiceDescription / deliveryMethod / deliveryMethod / broadcastAppService / basePattern (url match pattern for broadcast delivery) or ... / unicastAppService / basePattern (url match pattern for net delivery)
  • url match pattern for broadcast delivery or ...
  • unicastAppService / basePattern url match pattern for net delivery
  • segment distributed by broadcast and the segment distributed online are the same by using a set of urls grouped by bundleDescriptionROUTE / userServiceDescription / deliveryMethod / appService / identicalContent.
  • FIG. 25 shows a specific position where USD is extended to store the ROI identifier.
  • the ROI identifier is stored by extending the attribute of the basePattern of each Segment.
  • FIG. 26 shows a configuration of a service signaling transport session and a component file transport session corresponding to the extended USD.
  • “bcSeg.1-1.1” is described in the broadcastAppService / basePattern that describes the matching pattern of the broadcast distribution url under the userServiceDescription / deliveryMethod of USD, and “roiId1” is described as the ROI identifier. Yes.
  • “bbSeg.1-1.1” is described in unicastAppService / basePattern describing the matching pattern of the net distribution url, and “roiId1” is described as its ROI identifier. This means that the same ROI identifier is assigned to a segment in both broadcast distribution and net distribution. And it can show that these Segment groups are the same by grouping by deliveryMethod / appService / identicalContent.
  • the matching pattern described in basePattern is usually a part of baseURL or SegmentURL described in MPD (for example, “http://a.com/bc”, etc.), but is described for each Segment.
  • the entire SegmentURL up to the part where the SegmentURL can be uniquely resolved
  • the URL granularity for each segment is equal to the update granularity of USD.
  • the broadcast receiving unit 110 searches for bbSeg.1-1.1 from the USD, and the corresponding broadcast distribution url “bcSeg.1-1.1” is the url on the component file session. If it is found that the segment file exists, the segment file is acquired from the broadcast stream and supplied to the DASH client unit 140.
  • the DASH client unit 140 when tracking a ROI sequence and obtaining a segment, it is necessary to notify the DASH client unit 140 of information indicating to which ROI sequence the segment obtained by analyzing the USD by the broadcast receiving unit 110 belongs. For this notification, the DASH SAND message described above with reference to FIG. 8 is used.
  • the broadcast distribution combination information and the ROI identifier can be stored in the ResourceStatus / Reason element of the SAND ResourceStatus message.
  • an arbitrary character string may be described as hint information in the reason element.
  • a detailed specification of what information should be described (data structure and semantics) There is no provision).
  • SchemeIdUri a URI that identifies the content of data indicating the reception state is specified, and the content of the value specified by the URI can be described in value.
  • URN “urn: atsc: BroadcastDelivery” indicating that the broadcast distribution is used together is defined as SchemeIdUri
  • “urn: atsc: roiValue” is defined as a scheme for storing the ROI identifier, and the ROI identifier is set to the value attribute. Store.
  • FIG. 27 shows a specific example of a ResourceStatus message storing broadcast distribution combination information and an ROI identifier.
  • the ResourceStatus message includes a baseURL element, a Status element, and a Reason element.
  • the Reason element as shown in Fig. B, the delivery mode information and the ROI identifier are described as a character string in a base64 encoded state.
  • FIG. 28 shows an operation sequence when the delivery mode information and the ROI identifier are stored in the USD.
  • the DASH server On the distribution side, the DASH server generates an MPD using the SegmentTemplate and transfers it to the broadcast server. In addition, the DASH server generates a segment file of the content stream and transfers it to the Web server, and also transfers to the broadcast server those that are used together with broadcast distribution.
  • the broadcast server to which the MPD has been transferred generates an SLS file including the USD storing the distribution mode information and the ROI identifier, and broadcasts the generated SLS file and the transferred MPD via the broadcast network.
  • the broadcast server broadcasts and distributes the segment file of the content stream transferred from the DASH server in the ROUTE FileMode.
  • the broadcast receiving unit 110 receives the MPD and SLS file distributed by broadcast. Thereafter, when the DASH client unit 140 requests MPD from the broadcast receiving unit 110, the broadcast receiving unit 110 supplies the MPD to the DASH client unit 140 in response to the request.
  • the communication unit 120 can issue the HTTP request to the DASH server and acquire the MPD distributed on the net.
  • the DASH client unit 140 to which the MPD is supplied regenerates the MPD by restoring the complete SegmentURL based on the SegmentTemplate.
  • the broadcast receiving unit 110 analyzes the USD, determines the distribution mode information and ROI identifier of each Segment, and notifies the proxy server unit 130 of the determination result.
  • the proxy server unit 130 generates a ResourceStatus message storing the segment distribution mode information and the ROI identifier, and notifies the DASH client unit 140 of it.
  • the DASH client unit 140 can select a requested segment based on the ROI identifier described in the MPD and ResourceStatus message.
  • the communication unit 120 issues an HTTP request for requesting the segment to the web server, and the web server supplied (net distribution) accordingly.
  • the Segment is received and supplied to the DASH client unit 140.
  • the DASH client unit 140 reproduces the supplied segment.
  • the broadcast receiving unit 11 receives the segment distributed by broadcast and supplies it to the DASH client unit 140.
  • the DASH client unit 140 reproduces the supplied segment.
  • Each segment's delivery mode information and ROI identifier are signaled using the S-TSID's EFDT (part of the signaling fragment that can be transferred along with the files it describes on each component file session). be able to.
  • FIG. 29 shows a specific position where the EFDT is extended to store the ROI identifier.
  • RoiId and Identical-Content-Location are added in parallel to the efdtType / routesls: FDTParameters / File / atributes / Content-Location attribute.
  • FIG. 30 shows a configuration of a service signaling transport session and a component file transport session corresponding to the extended EFDT.
  • -1.1 (net distribution url) HTTP request is notified, this notification is passed to the broadcast receiving unit 110.
  • the broadcast receiving unit 110 searches for bbSeg.1-1.1 in the EFDT and is the corresponding broadcast distribution url. If it is found that bcSeg.1-1.1 ”is a url on the component file session, the Segment file is acquired from the broadcast stream and supplied to the DASH client unit 140.
  • the broadcast receiving unit 110 needs to notify the DASH client unit 140 of information indicating which ROI sequence the Segment obtained by analyzing the EFDT belongs to. is there.
  • the DASH SAND message described above is used for this notification.
  • FIG. 31 shows an operation sequence when the delivery mode information and the ROI identifier are stored in the EFDT.
  • the DASH server On the distribution side, the DASH server generates an MPD using the SegmentTemplate and transfers it to the broadcast server. In addition, the DASH server generates a segment file of the content stream and transfers it to the Web server, and also transfers to the broadcast server those that are used together with broadcast distribution.
  • the broadcast server to which the MPD has been transferred generates an SLS file including the EFDT storing the distribution mode information and the ROI identifier, and broadcasts the generated SLS file and the transferred MPD via the broadcast network.
  • the broadcast server broadcasts and distributes the segment file of the content stream transferred from the DASH server in the ROUTE FileMode.
  • the broadcast receiving unit 110 receives the MPD and SLS file distributed by broadcast.
  • the broadcast receiving unit 110 supplies the MPD to the DASH client unit 140 in response to the request.
  • the communication unit 120 can issue the HTTP request to the DASH server and acquire the MPD distributed on the net.
  • the DASH client unit 140 to which the MPD is supplied regenerates the MPD by restoring the complete SegmentURL based on the SegmentTemplate.
  • the broadcast receiving unit 110 analyzes the EFDT, determines the distribution mode information and ROI identifier of each segment, and notifies the proxy server unit 130 of the determination result.
  • the proxy server unit 130 generates a ResourceStatus message storing the segment distribution mode information and the ROI identifier, and notifies the DASH client unit 140 of it.
  • the DASH client unit 140 can select a requested segment based on the ROI identifier described in the MPD and ResourceStatus message.
  • the communication unit 120 issues an HTTP request for requesting the segment to the web server, and the web server supplied (net distribution) accordingly.
  • the Segment is received and supplied to the DASH client unit 140.
  • the DASH client unit 140 reproduces the supplied segment.
  • the broadcast receiving unit 11 receives the segment distributed by broadcast and supplies it to the DASH client unit 140.
  • the DASH client unit 140 reproduces the supplied segment.
  • the delivery mode information and ROI identifier of each Segment can be signaled by transferring the file in EntityMode during the component file session and extending the Entity header.
  • FIG. 32 shows the configuration of a service signaling transport session and a component file transport session corresponding to the extended Entity header.
  • an HTTP request of “bbSeg.1-1.1” (net distribution url) is notified, this notification is passed to the broadcast receiving unit 110, and the broadcast receiving unit 110 acquires the EntityMode acquired from the broadcast stream based on bbSeg.1-1.1.
  • the broadcast distribution url “bcSeg.1-1.1” corresponding to bbSeg.1-1.1 is found on the component file session from the Entity header of the distribution file group, the segment file is broadcast. It is acquired from the stream and supplied to the DASH client unit 140.
  • the broadcast receiving unit 110 needs to notify the DASH client unit 140 of information indicating to which ROI sequence the Segment obtained by analyzing the Entity header belongs. There is.
  • the DASH SAND message described above is used for this notification.
  • FIG. 32 shows an operation sequence when the delivery mode information and the ROI identifier are stored in the Entity header.
  • the DASH server On the distribution side, the DASH server generates an MPD using the SegmentTemplate and transfers it to the broadcast server. In addition, the DASH server generates an Entity header that stores the distribution mode information and the ROI identifier, generates a segment file of the content stream and transfers it to the web server. Forward.
  • the broadcast server to which the MPD has been transferred generates an SLS file and broadcasts the generated SLS file and the transferred MPD via a broadcast network.
  • the broadcast server broadcasts and distributes the segment file of the content stream transferred from the DASH server in the ROUTE EntityMode.
  • the broadcast receiving unit 110 receives the MPD and SLS file distributed by broadcast.
  • the broadcast receiving unit 110 supplies the MPD to the DASH client unit 140 in response to the request.
  • the communication unit 120 can issue the HTTP request to the DASH server and acquire the MPD distributed on the net.
  • the DASH client unit 140 to which the MPD is supplied regenerates the MPD by restoring the complete SegmentURL based on the SegmentTemplate.
  • the broadcast receiving unit 110 analyzes the Entity header to determine the distribution mode information and ROI identifier of each Segment, and notifies the proxy server unit 130 of the determination result.
  • the proxy server unit 130 generates a ResourceStatus message storing the segment distribution mode information and the ROI identifier, and notifies the DASH client unit 140 of it.
  • the DASH client unit 140 can select a requested segment based on the ROI identifier described in the MPD and ResourceStatus message.
  • the communication unit 120 issues an HTTP request for requesting the segment to the web server, and the web server supplied (net distribution) accordingly.
  • the Segment is received and supplied to the DASH client unit 140.
  • the DASH client unit 140 reproduces the supplied segment.
  • the broadcast receiving unit 11 receives the segment distributed by broadcast and supplies it to the DASH client unit 140.
  • the DASH client unit 140 reproduces the supplied segment.
  • FIG. 34 shows an example of using ROI identifiers and metadata corresponding to each ROI sequence.
  • FIG. 7A shows an example of use in which a display area 602 of each metadata (such as a person's name) is moved and displayed together with the person 601 when the person 601 with the ROI set is displayed on the screen 600.
  • a display area 602 of each metadata such as a person's name
  • the image on the screen 600 is enlarged around the person 601X or switched to the ROI image set for the person 601X. Can be.
  • FIG. B shows a usage example in which a display area 602 of metadata (such as a person's name) is collectively displayed at the end of the screen 600 when a person 601 with an ROI is displayed on the screen 600.
  • a display area 602 of metadata such as a person's name
  • the person 601Y on the screen 600 is highlighted (in the display example in FIG. B, around the person 601Y).
  • a blinking frame 605 is displayed), and the person 601Y can be enlarged as a center, or can be switched to the ROI image set for the person 601Y.
  • the above-described series of processing can be executed by hardware or can be executed by software.
  • a program constituting the software is installed in the computer.
  • the computer includes, for example, a general-purpose personal computer capable of executing various functions by installing a computer incorporated in dedicated hardware and various programs.
  • FIG. 35 is a block diagram illustrating a configuration example of hardware of a computer that executes the above-described series of processes by a program.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • An input / output interface 1105 is further connected to the bus 1104.
  • An input unit 1106, an output unit 1107, a storage unit 1108, a communication unit 1109, and a drive 1110 are connected to the input / output interface 1105.
  • the input unit 1106 includes a keyboard, a mouse, a microphone, and the like.
  • the output unit 1107 includes a display, a speaker, and the like.
  • the storage unit 1108 includes a hard disk, a nonvolatile memory, and the like.
  • the communication unit 1109 includes a network interface or the like.
  • the drive 1110 drives a removable medium 1111 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.
  • the CPU 1101 loads the program stored in the storage unit 1108 to the RAM 1103 via the input / output interface 1105 and the bus 1104 and executes the program, for example. A series of processing is performed.
  • the program executed by the computer 1100 can be provided by being recorded in, for example, a removable medium 1111 as a package medium or the like.
  • the program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.
  • the program can be installed in the storage unit 1108 via the input / output interface 1105 by installing the removable medium 1111 in the drive 1110.
  • the program can be received by the communication unit 1109 via a wired or wireless transmission medium and installed in the storage unit 1108.
  • the program can be installed in the ROM 1102 or the storage unit 1108 in advance.
  • the program executed by the computer 1100 may be a program that is processed in time series in the order described in this specification, or a necessary timing such as when a call is performed in parallel. It may be a program in which processing is performed.
  • the present technology can also have the following configurations.
  • a segment file conversion unit for converting a video stream for each area obtained by imaging an imaging range divided into a plurality of areas into a segment file;
  • a distribution unit that supplies a segment file of the video stream for each region to the reception side by at least one of net distribution or broadcast distribution;
  • a notification for notifying the receiving side of the ROI identifier for specifying the ROI to which the ROI belongs as attribute information regarding the segment file corresponding to the region forming the ROI
  • the notification unit further notifies the reception side of distribution mode information indicating whether the segment file is distributed by net distribution or broadcast distribution as the attribute information related to the segment file. Distribution device.
  • the distribution device according to any one of (1) to (6), wherein one or more ROIs are set in the imaging range.
  • the distribution unit distributes the segment file of the video stream corresponding to each of the regions in the network and broadcasts the segment file corresponding to the region forming the ROI. Any one of (1) to (7) The delivery device described.
  • a segment file conversion unit for converting a video stream for each area obtained by imaging an imaging range divided into a plurality of areas into a segment file;
  • a notification for notifying the receiving side of the ROI identifier for specifying the ROI to which the ROI belongs as attribute information regarding the segment file corresponding to the region forming the ROI Delivery method including steps and.
  • a segment file conversion unit for converting a video stream for each area obtained by imaging an imaging range divided into a plurality of areas into a segment file;
  • a distribution unit that supplies a segment file of the video stream for each region to the reception side by at least one of net distribution or broadcast distribution;
  • a notification for notifying the receiving side of the ROI identifier for specifying the ROI to which the ROI belongs as attribute information regarding the segment file corresponding to the region forming the ROI
  • a program that functions as a part.
  • the receiving device (13) The receiving device according to (12), wherein the request unit requests the segment file corresponding to an ROI identifier specified by an operation of designating a subject on a screen. (14) The receiving device according to (12), wherein the request unit requests the segment file corresponding to the ROI identifier specified by an operation of selecting subject metadata. (15) The attribute information further includes distribution mode information indicating whether the segment file is distributed by net distribution or broadcast distribution, The acquisition unit acquires the segment file corresponding to the requested predetermined ROI identifier based on the distribution mode information via the network distribution or the broadcast distribution. (11) to (14) Receiver. (16) The analysis apparatus according to any one of (11) to (15), wherein the analysis result of the attribute information by the analysis unit is notified to the request unit using a SAND message.
  • the receiving device When an ROI composed of one or more areas is set in the imaging range divided into a plurality of areas, the attribute information on the segment file of the video stream corresponding to the area forming the ROI, and at least the ROI to which the ROI belongs An analysis step of acquiring and analyzing the attribute information including an ROI identifier for specifying; Based on the analysis result of the attribute information, a requesting step for requesting the segment file corresponding to a predetermined ROI identifier; An acquisition step of acquiring the segment file corresponding to the requested predetermined ROI identifier via net distribution or broadcast distribution; And a playback step of playing back the obtained segment file.
  • the distribution device includes: A segment file conversion unit for converting a video stream for each area obtained by imaging an imaging range divided into a plurality of areas into a segment file; A distribution unit that supplies a segment file of the video stream for each region to the reception side by at least one of net distribution or broadcast distribution;
  • the department and The receiving device is: An analysis unit that analyzes the attribute information notified from the distribution device; Based on the analysis result of the attribute information, a request unit that requests the segment file corresponding to a predetermined ROI identifier, An acquisition unit for acquiring the segment file corresponding to the requested predetermined ROI identifier via net distribution or broadcast distribution;
  • a content distribution system comprising: a reproduction unit that reproduces the acquired segment file.

Landscapes

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

Abstract

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

Description

配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システム
　本技術は、配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システムに関し、特に、より多くのユーザの視聴される可能性が高い等の優先度が高い画像領域を放送にて配信し、その他の画像領域をオンデマンド配信する場合に用いて好適な配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システムに関する。
　IPTV等のインターネットストリーミングにおける標準化の流れとして、HTTPストリーミングによるVoD(Video on Demand)ストリーミングや、ライブストリーミング等に適用される方式の標準化が行われており、特にISO/IEC/MPEGで標準化が行われているDASH(Dynamic Adaptive Streaming over HTTP)が注目されている（例えば、非特許文献１を参照）。
　該DASHのユースケースとして、撮像空間を複数の矩形領域に分割して撮像し、各矩形領域の映像それぞれをDASHのAdaptationSetに割り当てて自由視点風ストリーミングサービスを提供することを考える。
　該自由視点風ストリーミングサービスを放送配信とオンデマンド配信（以下、ネット配信とも称する）を組合せて実現する場合、数多くのエンドユーザ（受信装置のユーザ）が共通して視聴する可能性が高い映像のストリームを放送配信によって提供し、数多くのユーザが共通して視聴する可能性が低い映像のストリームをネット配信によって提供するようにすれば、配信リソースの有効利用を図ることができる。
　ここで、数多くのユーザが共通して視聴する可能性が高い映像とは、撮像範囲全体の映像や、放送局等によって指定されるROI(Region Of Interest)のエリア（１または隣接する複数の矩形領域から成る）の映像等である。一方、数多くのユーザが共通して視聴する可能性が低く、特定のユーザによって視聴され得る映像とは、その他の矩形領域の映像等である。
　該自由視点風ストリーミングサービスによれば、ユーザは、任意の矩形領域（または隣接する複数の矩形領域）を指定することにより、撮像空間のうちの関心がある領域の動画のみを視聴することが可能となる。
「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEIELECTRONICS 2012.3.19
　ところで、米国次期デジタルテレビ規格であるATSC3.0にてDASHを採用し、上述した自由視点風ストリーミングサービスを実現する場合、各矩形領域の映像が放送配信されるのか、ネット配信されるのかを示す配信モード情報や、各矩形領域の映像のROI識別子（どのROIに属しているかを示す情報）を、放送シグナリングのレベルで認識させることができるようにしておけば、放送配信リソース(帯域や受信スタックでの計算処理等)を割り当てる優先度付けの指標として利用することができる。
　しかしながら、現状においてこれらのROI識別子をシグナリングする方法については確立されていない。
　本技術はこのような状況に鑑みてなされたものであり、放送配信またはネット配信の少なくとも一方で配信される映像のROI識別子をシグナリングできるようにするものである。
　本技術の第１の側面である配信装置は、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部とを備える。
　前記通知部は、前記セグメントファイルに関する前記属性情報として、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を受信側に通知することができる。
　前記通知部は、前記セグメントファイルに関する前記属性情報を、DASHで規定されているMPDに記載して受信側に通知することができる。
　前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、USDに記載して受信側に通知することができる。
　前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、EFDTに記載して受信側に通知することができる。
　前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、Entityヘッダに記載して受信側に通知することができる。
　前記撮像範囲には１以上の前記ROIが設定されているようにすることができる。
　前記配信部は、全て前記領域のそれぞれ対応する前記映像ストリームのセグメントファイルをネット配信するとともに、前記ROIを成す領域に対応するセグメントファイルを放送配信することができる。
　本技術の第１の側面である配信方法は、配信装置による、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信ステップと、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知ステップとを含む。
　本技術の第１の側面であるプログラムは、コンピュータを、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部として機能させる。
　本技術の第１の側面においては、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームがセグメントファイル化され、前記領域毎の前記映像ストリームのセグメントファイルがネット配信または放送配信の少なくとも一方により受信側に供給され、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子が受信側に通知される。
　本技術の第２の側面である受信装置は、複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、取得された前記セグメントファイルを再生する再生部とを備える。
　前記要求部は、ユーザからの操作によって特定されるROI識別子に対応する前記セグメントファイルを要求することができる。
　前記要求部は、画面上の被写体を指定する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求することができる。
　前記要求部は、被写体のメタデータを選択する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求することができる。
　前記属性情報は、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を含むことができ、前記取得部は、前記配信モード情報に基づき、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得することができる。
　前記解析部による前記属性情報の解析結果は、SANDメッセージを用いて前記要求部に通知されるようにすることができる。
　本技術の第２の側面である受信方法は、受信装置による、複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析ステップと、前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求ステップと、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得ステップと、取得された前記セグメントファイルを再生する再生ステップとを含む。
　本技術の第２の側面であるプログラムは、コンピュータを、複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、取得された前記セグメントファイルを再生する再生部として機能させる。
　本技術の第２の側面においては、属性情報が解析され、前記属性情報の解析結果に基づき、所定のROI識別子に対応するセグメントファイルが要求され、要求された前記所定のROI識別子に対応する前記セグメントファイルがネット配信または放送配信を介して取得され、取得された前記セグメントファイルが再生される。
　本技術の第３の側面であるコンテンツ配信システムは、配信装置と受信装置を含むコンテンツ配信システムにおいて、前記配信装置が、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部とを備える。また、前記受信装置が、前記配信装置から通知された前記属性情報を解析する解析部と、前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、取得された前記セグメントファイルを再生する再生部とを備える。
　本技術の第３の側面においては、配信装置による、複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームがセグメントファイル化され、前記領域毎の前記映像ストリームのセグメントファイルがネット配信または放送配信の少なくとも一方により受信側に供給され、前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子が受信側に通知される。また、受信装置により、配信装置から通知された属性情報が解析され、前記属性情報の解析結果に基づき、所定のROI識別子に対応するセグメントファイルが要求され、要求された前記所定のROI識別子に対応する前記セグメントファイルがネット配信または放送配信を介して取得され、取得された前記セグメントファイルが再生される。
　本技術の第１の側面によれば、放送配信またはネット配信の少なくとも一方で配信される映像のROI識別子をシグナリングすることが可能となる。
　本技術の第２の側面によれば、特定のROIに属する領域のセグメントファイルを取得し、再生することができる。
　本技術の第３の側面によれば、放送配信またはネット配信の少なくとも一方で配信される映像のROI識別子をシグナリングすることができ、受信側では、特定のROIに属する領域のセグメントファイルを取得し、再生することができる。
コンテンツ配信システムの構成例を示すブロック図である。 MPDのデータ構造を示す図である。 Representationの例を示す図である。 MPDにおけるPeriod以下の階層構造を示す図である。 時間軸上にMPDの構造を並べた状態を示す図である。 コンテンツ配信システムのより詳細な構成例を示すブロック図である。 本技術を適用したクライアント装置の構成例を示すブロック図である。 PERメッセージについて説明するための図である。 ResourceStatusの各要素を説明する図である。 ROUTE/DASHベースのスタックを示す図である。 ROUTE プロトコルが用いられた場合に対応するクライアント側の動作を説明するための図である。 撮像空間全体と矩形領域とエリアの関係を示す図である。 撮像空間全体と矩形領域とエリアの関係を示す図である。 図１１に示されたROI の移動に対応して放送配信されるSegmentが変化する様子を示す図である。 画像全体を４個の矩形領域に分割した場合を示す図である。 図１４に対応する各Segmentの放送配信併用の有無とROI識別子を示す図である。 図１６に対応するMPD-SRD表現を示す図である。 画像全体とそこにおける矩形領域の位置と解像度を示す図である。 MPDの拡張位置を示す図である。 MPDの拡張位置を示す図である。 拡張したMPDに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示す図である。 MPDに配信モード情報とROI識別子を格納した場合における動作シーケンスを示す図である。 SegmentTemplateを利用して書き換えたMPD-SRD表現を示す図である。 図２３のMPD-SRD表現を説明するための図である。 USDの拡張位置を示す図である。 拡張したUSDに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示す図である。 配信モード情報とROI識別子を格納したResourceStatusメッセージの具体例を示す図である。 USDに配信モード情報とROI識別子を格納した場合における動作シーケンスを示す図である。 EFDTの拡張位置を示す図である。 拡張したEFDTに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示す図である。 EFDTに配信モード情報とROI識別子を格納した場合における動作シーケンスを示す図である。 拡張したEntityヘッダに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示す図である。 Entityヘッダに配信モード情報とROI識別子を格納した場合における動作シーケンスを示す図である。 クライアント装置におけるROI識別子の利用例を示す図である。 汎用のコンピュータの構成例を示すブロック図である。
　以下、本技術を実施するための最良の形態（以下、実施の形態と称する）について、図面を参照しながら詳細に説明する。なお、説明は、以下の順序で行なう。
　１．＜DASHを採用したコンテンツ配信システムの構成例＞
　２．＜本技術を適用したクライアント装置の構成例＞
　３．＜PERメッセージについて＞
　４．＜MPDに配信モード情報とROI識別子を格納する場合＞
　５．＜MPDにSegmentTemplateを利用する場合の対応＞
　６．＜USDに配信モード情報とROI識別子を格納する場合＞
　７．　＜EFDTの拡張＞
　８．　＜Entityヘッダの拡張＞
　９．　＜クライアント装置におけるROI識別子の利用例＞
　＜DASHの概要説明＞
　始めに、DASHの概要について説明する。図１は、DASHを採用したコンテンツ配信システムの構成例を示している。同図左側に示すMedia Presentation on HTTP Serverはコンテンツの配信側であり、同図右側に示すHTTP Streaming Clientがコンテンツの受信側であって、受信したコンテンツのストリームを受信して再生し、ユーザに提示することができる。
　配信側のMedia Presentation on HTTP Serverは、同一内容のコンテンツであって、パスとなる地上デジタル放送や衛星放送等の放送網、インターネット等の双方向通信網、3GPPやLTE-eMBMS等の携帯電話通信網の通信環境や受信側の能力や状態に応じて画質や画角サイズなどが変更されている複数のストリームを用意し、供給することができる。
　また、Media Presentation on HTTP Serverは、同一コンテンツの撮像領域全体の映像や撮像領域を複数に分割した各矩形領域の映像、すなわち、同一のコンテンツに属するが内容が異なる映像を、パスの通信環境や受信側の能力や状態に応じて画質や画角サイズなどが変更されている複数のストリームを用意し、供給することができる。
　一方、受信側のHTTP Streaming Clientは、配信側が用意している複数のストリームのうち、パスの通信環境や受信側の能力や状態などに応じて最適なストリームを選択して取得、再生することができる。
　このように、DASHにおいては、受信側がストリームを適応的に選択して取得できるように、MPD(Media Presentation Description)と称されるメタデータがコンテンツの配信側から受信側に供給される。
　MPDには、チャンク化されたストリーム(Audio/Video/Subtitle等のメディアデータ)のアドレス(url情報)が記述されており、受信側は該url情報に基づいて、コンテンツの供給元となる所定のサーバにアクセスし、HTTP配信されるストリーミングデータを取得、再生することができる。
　なお、配信側に比較して圧倒的に数が多い受信側のHTTP Streaming Clientがコンテンツの供給元となる同一のサーバに対して同一のストリームを要求することが起こり得る。そのような場合、各HTTP Streaming Clientからの供給に応じてその都度、同一のストリームを送信していては通信効率が悪いので、インターネット上などにいわゆるプロキシサーバを設けることがある。
　図２は、コンテンツの配信側から受信側に供給されるメタデータとしてのMPDのデータ構造を示している。
　MPDは、コンテンツに関する情報がPeriod毎に区分されている。各Periodには、同一内容であって画質や画角サイズ、言語等が変更されているビットレートなどのストリーム属性の異なる同期されたストリーミングデータに関する情報からなる複数のRepresentationをグルーピングするAdaptationSetが用意されている。Representationには、Periodをさらに時間的に分割したSegmentに関する情報が格納されている。
　なお、Periodは、コンテンツの時間的な区切りの単位である。Segmentは、Periodを時間的により細分化した単位であり、コンテンツのストリームは、Segmentの単位でSegmentファイルにファイル化されている。
　各SegmentファイルはURL(+バイトレンジ)で特定される。SegmentはRepresentationの一部であり、１つのRepresentationは以下のいずれかで構成される。
（１）１つまたはそれ以上のSegmentList
（２）１つのSegmentTemplate
（３）１つまたはそれ以上のBaseURLと、最大１つSegmentBase(この場合はSegmentListおよびSegmentTemplateは含まない)
　図３は、上記（１）乃至（３）に該当するRepresentationの例を示している。
　上記（３）におけるSegmentBaseは、同図Ａに示されるように、１つのRepresentationに１つのMediaSegmentしかない場合に利用される。この場合、初期化情報のバイト列とRandom Access Points (RAP)のバイト列がファイルの最初の834バイト(SegmentBaseのindexRangeで記述する)以内に収められている。
　上記（１）におけるSegmentListは、同図Ｂに示されるように、再生順に配置される複数のSegmentURLで構成される。SegmentURLはSegmentファイルのURL(+そのファイル内のバイトレンジ)により表現される。SegmentListの最初に配置されているInitilizationは、初期化情報が格納されているファイル(InitSegment)を指示する。
　上記（２）におけるSegmentTemplateは、SegmentTemplateに基づいてSegmentURLを自動的に生成するとき(ライブストリーミングが典型的なユースケース)に利用される。すなわち、受信側において、SegmentTemplateに記載されるSegmentURLのひな形に含まれる所定のパラメータを動的に置き換えていくことにより、完全なSegmentURLのリストを生成する。SegmentTemplateを利用することによりMPDのサイズを非常に小さくすること可能となる。
　例えば、同図Ｃに示されるようなSegmentTemplateが利用された場合、ReplacementParameterである$Number$を、StartNumberで示される値を初期値として１ずつインクリメントした値に置き換えることにより、同図Ｄに示されるようなSegmentURLを生成する。
　図４は、MPDにおけるPeriod以下の階層構造を示している。なお、MPDは、例えばXML形式で記述される。Periodの下層には、ストリームの選択範囲となるRepresentation群をグルーピングする情報であるAdaptationSetが記述される。AdaptationSetの下層には、動画や音声のビットレート、画角サイズ、言語などを表す情報を含むRepresentationが記述される。Representationの下層には、動画や音声のSegment関連の情報であるSegmentinfoが記述される。Segmentinfoの下層には、データ圧縮方式などの初期化情報を表すInitialization Segment、および、動画や音声のSegment単位のデータの供給元を表すMedia Segmentが記述される。
　受信側では、MPDのPeriodに含まれるRepresentationの属性に基づいて受信、再生に最適なRepresentationを選択し、選択したRepresentationの先頭のSegmentからInitialization Segmentを取得してデータ圧縮方式などを判断した後、後続のsegmentを要求、取得し、再生を行うことができる。
　図５は、時間軸上にMPDの構造を並べた状態を示している。同図から明らかなように、同一のAdaptationSetに含まれるストリーム属性が異なる各RepresentationのSegmentどうしは同期したものとなる。
　上述したように、同一コンテンツの撮像領域全体の映像や撮像領域を複数に分割した各矩形領域の映像のストリームは、それぞれ異なるAdaptationSetに属しているが、その場合でも、異なるAdaptationSetに含まれる各RepresentationのSegmentどうしも同期したものとなる。
　次に、図６は、DASHを採用したコンテンツ配信システムのより詳細な構成例を示している。
　図６におけるDASHサーバ、Webサーバ、および放送サーバは、図１におけるMedia Presentation on HTTP Serverに相当する。また、図６におけるDASHクライアントは、図１におけるHTTP Streaming Clientに相当する。
　DASHサーバおよびWebサーバに対し、DASHクライアントは、インターネット上に形成されたCDN(Content Delivery Network)を介してアクセスできる。CDNにはDASHキャッシュサーバ（プロキシサーバ）が設けられている。
　DASHサーバは、MPDを生成して放送サーバに転送するとともに、ストリームのSegmentファイルを生成してWebサーバに転送する。また、DASHサーバは、DASHクライアントからのHTTPリクエストに応じ、生成したMPDをCDN(Content Delivery Network)を介してネット配信する。Webサーバは、MPDを参照してストリームの取得先を選択したDASHクライアントからのHTTPリクエストに応じ、CDNを介してSegmentファイルをネット配信する。放送サーバは、MPDを放送配信する。また、放送サーバは、Segmentファイルを放送配信する。
　DASHキャッシュサーバは、CDNを監視し、DASHクライアントに対してCDNを介して配信されるSegmentファイルを一時的にキャッシュする。そして、DASHキャッシュサーバは、DASHクライアントからキャッシュしているSegmentファイルを要求するHTTPリクエストがWebサーバに送信された場合、Webサーバに代わって、キャッシュしているSegmentファイルを要求元のMPDクライアントに配信する。
　なお、DASHキャッシュサーバは、ストリームのSegmentファイルだけでなく、MPDも一時的にキャッシュすることができ、DASHサーバの代わりに、キャッシュしているMPDを要求元のDASHクライアントに供給することができる。また、DASHキャッシュサーバが放送配信されるMPDやSegmentファイルを受信、キャッシュできるようにしてもよい。
　CDN上にDASHキャッシュサーバを設けたことにより、該コンテンツ配信システムでは、大多数のDASHクライアントに対するHTTPストリーミングの配信効率を向上させることができる。
　＜本技術を適用したクライアント装置の構成例＞
　次に、図７は、ATSC3.0においてDASHを採用し、自由視点風ストリーミングサービスを実現する場合における受信側のクライアント装置の構成例を示している。
　該クライアント装置１００は、ATSC3.0以外の規格においてDASHを採用したストリーミング配信サービスを実現する場合にも適用することが可能である。
　クライアント装置(3.0 Client(with ATSC3.0 PHY/MAC))１００は、例えば、一般家屋に設置されたり、自動車等の移動体に搭載されたりするテレビジョン受像機やビデオレコーダ、セットトップボックスに内蔵されることを想定したものである。
　クライアント装置１００は、放送受信部（Client ATSC Middleware）１１０、通信部(Ethernet/WiFi etc.)１２０、プロキシサーバ部（Client Local HTTP Proxy Server）１３０、およびDASHクライアント部(3.0 DASH Client)１４０を備える。
　放送受信部１１０は、Broadcaster１０（図６の放送サーバに相当）から、地上デジタル放送または衛星放送などの放送網１１を介して配信されるMPD、ストリームのSegmentファイル、SLSファイル等を受信する処理を実行する。
　放送受信部１１０は、放送波を受信するチューナ部１１１、放送波からSegmentファイルを抽出するSegment Retriever１１２、放送波からLLS(Low Level Signaling)ファイルを抽出するLLS Signaling Retriever１１３、およびLLSファイルを解析するLLS Signaling Parser１１４を備える。さらに、放送受信部１１０は、放送波からSLS(Service Layer Signaling)ファイルを抽出するSLS Signaling Retriever１１５、およびSLSファイルを解析するSLS Signaling Parser１１６を備える。
　通信部１２０は、インターネットなどの双方向通信網に形成されているCDN１２を介し、Broadcaster１０（（図６のDASHサーバおよびWebサーバに相当））に対してMPD、ストリームのSegmentファイル、SLSファイルを要求し（HTTPリクエストを送信し）、それに応じてHTTP配信されるMPDやSegmentファイルを受信する処理を実行する。
　プロキシサーバ部１３０は、放送網１１を介して受信された各種ファイルをキャッシュするProxy Cache１３１、CDN１２を介して受信された各種ファイルをキャッシュするProxy Cache１３２、および、DASHクライアント部１４０からの要求に対応するBroadcast/Broadband Address Resolver１３３を備える。
　Broadcast/Broadband Address Resolver１３３は、Proxy Cache１３１または１３２にキャッシュされているMPDやSegmentファイルを、DASHクライアント部１４０からの要求に応じてそれらを供給する処理を実行する。
　さらに、Broadcast/Broadband Address Resolver１３３は、放送受信部１１０や通信部１２０によるSegmentファイルの受信状態などを表す供給可否情報を、PERメッセージを用いてDASHクライアント部１４０に通知する処理を実行する。
　またさらに、Broadcast/Broadband Address Resolver１３３は、各Segmentファイルがネット配信とともに放送配信されるか否かを示す放送配信併用情報と、各SegmentファイルがROIに属している場合にその所属を表すROI識別子を、PERメッセージを用いてDASHクライアント部１４０に通知する処理を実行する。PERメッセージの詳細については後述する。
　DASHクライアント部１４０は、MPDを要求、取得するMPD Retriever１４１、MPDを解析するMPD Parser１４２、MPDを参照してSegmentファイルを要求、取得するSegment Retriever１４３、およびSegmentファイルからMP4データを抽出、解析するMP4 Parser１４４を備える。さらに、DASHクライアント部１４０は、MP4データをデコードするDecoder１４５、およびデコード結果をレンダリングするRenderer１４６を備える。
　DASHクライアント部１４０は、例えば、クライアント装置１００に実装されたブラウザ上で実現される。ただし、ブラウザアプリケーションとしてだけではなくネイティブアプリケーションとして実現するようにしてもよい。DASHクライアント部１４０は、プロキシサーバ部１３０を介して、放送受信部１１０または通信部１２０が受信したMPD、Segmentファイル、SLSファイル等を取得し、ストリームのレンダリングやアプリケーションの制御を行うことにより、ストリームの映像および音声を後段のモニタ（不図示）に出力する処理を実行する。
　なお、DASHクライアント部１４０は、クライアント装置１００のみならず、クライアント装置１００に対してLAN２０を介して接続されているクライアント装置２００に実装することができる。クライアント装置２００は、例えば、スマートフォン、タブレットなどを想定したものである。
　クライアント装置２００におけるDASHクライアント部１４０は、LAN２０を介してクライアント装置１００に接続し、クライアント装置１００のプロキシサーバ部１３０を介して、放送受信部１１０または通信部１２０が受信したMPD、Segmentファイル、SLSファイル等を取得し、ストリームのレンダリングやアプリケーションの制御を行うことにより、ストリームの映像および音声を後段のモニタ（不図示）に出力する処理を実行することができる。
　なお、図示は省略するが、クライアント装置１００からDASHクライアント部１４０を省略した構成を有する供給装置を、LAN２０に接続してもよい。その場合、クライアント装置１００および２００は、該供給装置に対してもMPDやSegmentファイル等を要求することができる。
　上述したように、クライアント装置１００におけるDASHクライアント部１４０、およびクライアント装置２００におけるDASHクライアント部１４０は、必ずプロキシサーバ部１３０を介して各種ファイルを取得している。したがって、DASHクライアント部１４０は、取得する各種ファイルが放送網１１を介する放送配信か、CDN１２を介するネット配信かの区別を意識する必要が無い、いわゆるネットワーク透過性を実現できる。したがって、DASHクライアント部１４０は、その可搬性が高まるので、放送を受信できない装置に対してもDASHクライアント部１４０を搭載することが可能となる。
　次に、プロキシサーバ部１３０について詳述する。プロキシサーバ部１３０は、DASHクライアント部１４０から各種ファイルの取得を要求されると（HTTPリクエストを受信すると）、Broadcast/Broadband Address Resolver１３３が、それを放送網１１経由で取得するか、CDN１２経由で取得するかを判断する。この判断の材料となる情報は、放送受信部１１０のSLS Signaling Parser１１６から提供される。
　放送受信部１１０のSLS Signaling Parser１１６は、SLS Signaling Retriever１１５に対して、ATSC3.0のシグナリングメタデータであるUSBD/USDやS-TSID等の取得要求を行う。SLS Signaling Retriever１１５は、チューナ部(ATSC3.0 PHY/MAC)１１１が受信する放送信号からSLS LCTパケットにより運ばれるシグナリングメタデータを抽出する。
　また、SLS Signaling Parser１１６は、Segmentファイルの取得要求に含まれるurlからシグナリングメタデータを取得して、対象となるSegmentファイルを取得するための放送配信アドレス情報を取得する。対象となるSegmentファイルが今後放送配信される、または既に放送配信されたことがわかれば、その放送配信アドレス情報に基づき、対象となるSegmentファイルが格納されているsegment LCTパケットを放送ストリームから取得してプロキシサーバ部１３０のProxy Cache１３１内に展開する。この後、プロキシサーバ部１３０は、DASHクライアント部１４０に対してHTTPリクエストのレスポンスとして当該Segmentファイルを返すことになる。
　要求されたSegmentファイルのurlがシグナリングメタデータになければ、プロキシサーバ部１３０は、通信部１２０を介してSegmentファイルを取得し、取得したSegmentファイルをProxy Cache１３２内に展開する。この後、プロキシサーバ部１３０は、DASHクライアント部１４０に対してHTTPリクエストのレスポンスとして当該Segmentファイルを返すことになる。
　＜PERメッセージについて＞
　次に、PERメッセージについて説明する。供給可否情報、放送配信併用情報、およびROI識別子は、以下に説明するPERメッセージを拡張して格納する。
　図８は、PERメッセージについて説明するための図である。PERメッセージは、DANE(DASH-Aware Network Elements)３００からDASH Client４００に対して通知されるメッセージである。
　ここで、DANE３００は、図７に示されたDASHクライアント装置１００のプロキシサーバ部１３０に相当する。DASH Client４００は、DASHクライアント装置１００のDASHクライアント部１４０に相当する。
　DASHにおいては、SANDと称されるプロトコルの規定が検討されている。SANDは、DASHを効果的に運用するために、ネットワークオペレータが管理するDASH配信コンポーネント群から提供され得る種々のリアルタイムネットワーク環境(配信リソース)情報を交換、提供するためのプロトコルである。
　SANDには、DANE３００からDASH Client４００に提供されるメッセージ（PERメッセージ）のメッセージプロトコルとしてPERが規定されている。また、DASH Client４００からDANE３００に提供されるメッセージ（Statusメッセージ）のメッセージプロトコルとしてStatusが規定されている。なお、以下、PERメッセージまたはStatusメッセージをSANDメッセージとも称する。
　PERでは、ResourceStatusと称するメッセージと、この同類のメッセージとしてDaneResourceStatusと称するメッセージが定義されている。
　図９は、ResourceStatusの各要素を説明する図である。本実施の形態では、ResourceStatusのStatus要素を拡張して供給可否情報を格納できるようにし、プロキシサーバ部１３０からDASHクライアント部１４０に通知する。
　さらに、ResourceStatusのReason要素を拡張して放送配信併用情報とROI識別子を格納できるようにし、プロキシサーバ部１３０からDASHクライアント部１４０に通知する。該Reason要素には、さらに、ROI識別子が表わすROI系列のメタデータ（例えば、該ROI系列が追従して移動される選手の名前等）を記述するようにしてもよい。なお、ROI識別子が表わすROI系列のメタデータは、放送配信またはネット配信によってクライアント装置１００に供給されているものとする。
　ResourceStatusを受け取ったDASH client４００は、ResourceStatusに基づいて次に要求するDASHSegmentファイルを選択することができる。なお、ResourceStatusには、有効期限が記述されているので、DASH client４００はResourceStatusの有効期限まではその内容が有効であるとみなすことができる。
　＜ROUTE(Real-Time Object Delivery over Unidirectional Transport)プロトコル＞
　次に、ROUTEプロトコルについて説明する。ATSC3.0においては、IPベースのトランスポートスタックの標準化作業が行われており、OTT配信で主流となりつつあるMPEG-DASHのファイルフォーマット(ISO-BMFFファイル、MP4ファイル)に基づくファイルを、FLUTE(File Delivery over Unidirectional Transport)を拡張したROUTEプロトコルを用いて転送する。
　ROUTEプロトコルを用いることにより、DASHのfragmented MP4（フラグメント化されたMP4ファイル）ファイルシーケンスと、DASHの制御メタファイルであるMPDや、後述する各種のシグナリング(3GPP-MBMS -USD(User Service Description)を拡張したATSCバージョンのUSDやROUTEプロトコルの制御メタデータであるS-TSID等)を転送することができる。
　図１０は、ROUTE/DASHベースのスタックを示している。ROUTEプロトコルはFLUTEをベースとするプロトコルであり、FLUTEにおける転送制御パラメータを記述したメタデータファイルはFDT(File Delivery Table)と称されているが、FDTに相当するROUTEにおける制御メタデータはS-TSID(Service-based Transport Session Instance Description)と称される(実際にはS-TSID/.../EFDTが一番近い)。
　S-TSIDは、あるサービス(放送のチャンネルに相当する)内で転送される全てのサービスコンポーネント(ビデオ/オーディオ/データコンポーネントストリーム-全てファイル転送セッションとして実現される)についての転送制御メタデータを記述する。S-TSID自身も、ROUTEセッションの中でサービスシグナリングセッションとして転送される。
　また、S-TSIDは１つのサービス内で転送されるコンポーネントファイルセッションについてのシグナリングメタデータであるが、S-TSID自身が転送されるサービス毎のサービスシグナリングメタデータ転送セッションのアドレス(サービスブートストラップアドレス)を解決するためのブートストラップメタデータとしてSLT(Service List Table)と称するシグナリングメタデータを用意しており、UDP/IP上でそれぞれのサービスとは異なる特別なDestination IP Address/Destination Portで転送するようにしている。
　図１１は、ROUTEプロトコルが用いられた場合に対応するクライアント側の動作を説明するための図である。
　クライアント装置１１０は、初めにSLTを取得した後、サービスブートストラップアドレスにより所望のサービスのサービスシグナリング(Service Level Signaling)を取得し、当該サービスを構成するサービスコンポーネントそのものを取得してレンダリングを行うことになる。
　＜自由視点風ストリーミングサービスについて＞
　次に、本実施の形態であるコンテンツ配信システムが実現可能な自由視点風ストリーミングサービスについて改めて説明する。
　図１２および図１３は、撮像空間全体５１０を複数の矩形領域５１１に分割した場合の例示している図である。
　同図の場合、撮像空間全体５１０が３６個の矩形領域５１１に分割されている。なお、図中の（１，１）等は撮像空間全体５１０における矩形領域５１１の配置を示している。ここで、撮像空間全体５１０の中央部分に複数（同図の場合、４）の矩形領域５１１から成るエリア５１２Ａ乃至５１２Ｄを設定する。
　例えば、配信されるコンテンツがサッカーの試合である場合、観客席を含むスタジアム会場全体が撮像空間全体５１０とされ、スタジアムのフィールド（グランド）が、エリア５１２Ａ乃至５１２Ｄとされる。さらに、試合中にボール５１３が移動すると、その動きに追従するエリアがROI５１４とされ、図１３のＡ乃至図１３のＣに示されるように推移する。
　同図のような場合、エリア５１２Ａ乃至５１２Ｄの映像がそれぞれ１個のAdaptationSetに割り当てられるとともに、各矩形領域５１１の映像がそれぞれをDASHのAdaptationSetに割り当てられる。そして、数多くのユーザが共通して視聴する可能性が高いエリア５１２Ａ乃至５１２Ｄそれぞれの映像に対応するSegmentと、ROI５１４の映像に対応するSegmentが放送配信される。そして、その他の矩形領域５１１の映像に対応するSegmentはネット配信される。ただし、放送配信を受信できないユーザや放送配信の取りこぼし（受信ミス）を配慮して、全てのAdaptationSetに属するSegmentはネット配信も行うようにする。
　図１４は、エリア５１２Ａ乃至５１２Ｄの映像にそれぞれ対応するSegmentと、各矩形領域５１１の映像にそれぞれ対応するSegmentが放送配信されるか（図中で色付きのもの）、ネット配信されるか（図中で無色のもの）を示している。なお、同図上段、中段、下段がそれぞれ図１３のＡ、図１３のＢ、図１３のＣに対応する。
　例えば、図１３のＡにおけるROI５１４は、４個の矩形領域５１１（2,1、2,2、3,1、3,2）から成るので、図１４上段に示されるように、エリア５１２Ａ乃至５１２Ｄの映像にそれぞれ対応するSegmentと、４個の矩形領域５１１（2,1、2,2、3,1、3,2）の映像にそれぞれ対応するSegmentが放送配信される。
　同様に、図１３のＢにおけるROI５１４は、４個の矩形領域５１１（3,2、3,3、4,2、4,3）から成るので、図１４中段に示されるように、エリア５１２Ａ乃至５１２Ｄの映像にそれぞれ対応するSegmentと、４個の矩形領域５１１（3,2、3,3、4,2、4,3）の映像にそれぞれ対応するSegmentが放送配信される。
　なお、図１３に示された例では、ボール５１３に追従するROIが１つだけ設定されているが、例えば、有力選手の動きに追従するROI等、複数のROIを設定してもよい。ただし、全てのROIを放送配信する必要はなく、ユーザに視聴される可能性に応じ、ネット配信のみを行うROIがあってもよい。
　なお、図示は省略するが、自由視点風ストリーミングサービスは、例えば、VR(Virtual Reality)でよく使われる正距円筒画像 をSRD(Spatial Relation Description)にマッピングする場合にも適用できる。
　次に、図１５は、画面全体（または撮像範囲のうちの所定の領域でもよい）を４個の矩形領域に分割した例を示している。以下、説明を簡単にするため、図１５に示すように、画面全体を４個の矩形領域に分割するとともに、ROIを１個の矩形領域から構成するようにし、画面全体と４個の矩形領域のそれぞれの映像をDASHのAdaptationSetに割り当てて配信する場合を例に説明する。
　図１５の例では、AdaptationSet.1.tが画面全体の映像のストリームであり、AdaptationSet.1-1.t乃至1-4.tが、画面全体の左上、右上、左下、または右下の矩形領域それぞれの映像のストリームである。なお、tは時系列を表すパラメータである。
　また、図１５の例では、ROIとしてroiId1とroiId2の２系統が設定されている。roiId1は、AdaptationSet.1-1.1からAdaptationSet.1-2.2へ、さらにAdaptationSet.1-3.3へと遷移する。roiId2は、AdaptationSet.1-3.1からAdaptationSet.1-2.2へ、さらにAdaptationSet.1-2.3へと遷移する。
　２系統のROIのうち、roiId1がroiId2よりも注目度が高いと仮定されており、roiId1に属するSegmentは全て放送配信併用とされ、roiId2に属するSegmentは全てネット配信のみとされている。
　AdaptationSet.1配下のSegmentは全てネット配信と放送配信が行われる放送配信併用であり、ネット配信用のurl(例えばurlプリフィクス"bb"で記載)が割り当てられるとともに、放送配信用のurl(例えばurlプリフィクス"bc"で記載)が割り当てられる。
　AdaptationSet.1-1乃至1-4配下のSegmentは、それぞれが放送配信される場合のみ、ネット配信用のurlが割り当てられるとともに、放送配信用のurlが割り当てられる。放送配信されない場合（すなわち、ネット配信だけの場合）、ネット配信用のurlだけが割り当てられる。
　また、それぞれのSegmentがROIに属している場合には、ROI系列を識別するためのROI識別子が適宜割り当てられる。
　図１６は、AdaptationSet.1.t配下のSegment（例えば、Segment.1.1等）と、AdaptationSet.1-1.t乃至1-4.t配下のSegment（例えば、Segment.1-1.1等）の放送配信併用の有無およびROI識別子を示している。
　例えば、Segment.1-1.1等の下に記載されているUrl(bbSeg.1-1.1)は、Segment.1-1.1がネット配信されることを意味する。また、Url(bcSeg.1-1.1)は、Segment.1-1.1が放送配信されることを意味する。さらに、RoiIdentifier(roiId1)は、Segment.1-1.1がroiId1のROI系統に属していることを意味する。
　例えば、画面全体の左上の矩形領域に対応するAdaptationSet.1-1.tでは、ｔ＝１のSegment.1-1.1はroiId1に属するので、放送配信併用とされる（放送配信とネット配信が行われる）が、ｔ＝２，３のSegment.1-1.2とSegment.1-1.3はROI系列に属していないので、ネット配信のみが行われる。
　また、例えば、画面全体の右上の矩形領域に対応するAdaptationSet.1-2.tでは、ｔ＝１のSegment.1-2.1はROI系列に属していないので、ネット配信のみが行われるが、ｔ＝２のSegment.1-2.2はroiId1とroiId2に属するので、放送配信併用とされる。
　さらに、例えば、画面全体の左下の矩形領域に対応するAdaptationSet.1-3.tでは、ｔ＝１のSegment.1-3.1はroiId2に属するが、注目度が低いと想定されている場合、ネット配信のみが行われる。
　上述したように、各Segmentが放送配信されるのかネット配信されるのかを示す配信モード情報をMPDに記載するためには、AdaptationSet要素の子要素であるbaseURL要素に、配下の各Segmentのurlに付加されるurlプリフィクスを記載すればよい。
　例えば、AdaptationSet/baseURL=”http://a.com/bc”であれば、その配下に属する所定のSegmentに対してAdaptationSet/Representation/SegmentList/SegmentURL@media="/segment11.mp4"と記載される場合、当該segmentのurlは、”http://a.com/bc/segment11.mp4”となる。
　一方、ROI識別子については、現状のMPDにSegment単位で記載することはできないので、MPDを拡張する必要がある。具体的には、SegmentURLの属性にroiId要素を追加してSegment毎のROI識別子を記載できるようにする。例えば、<SegmentURL roiId=”roiId1”>は、当該SegmentのROI識別子が”roiId1”であることを示す。
　上述したように、MPDにSegment単位の配信モード情報とROI識別子を記載できるようにすれば、クライアント装置１００は、MPDを取得、解析することにより、放送配信、ネット配信の違いを意識してSegmentファイルを取得することが可能となる。
　これにより、例えば、画面全体を視聴したいユーザのデバイスでは、SegmentUrlのbcSeg.1.1からbcSeg.1.2、bcSeg.1.3の順にSegmentシーケンスを取得すればよい。また、例えば、roiId=”roiId1”を視聴したいユーザのデバイスでは、bcSeg.1-1.1からbcSeg.1-2.2、cSeg.1-3.3の順にSegmentシーケンスを取得すればよい。同様に、roiIId=”roiId2”を視聴したいユーザのデバイスでは、bbSeg.1-3.1からbcSeg.1-2.2、bbSeg.1-2.3の順にSegmentシーケンスを取得すればよい。
　なお、MPDにおいて、同一のSegmentに対して放送配信用urlとネット配信用urlが記載されている場合（すなわち、該Segmentが放送配信併用である場合）、放送配信のSegmentを受信するか、ネット配信のSegmentを受信するかについては、クライアント装置１００が自身の受信状況等に応じて決定すればよい。
　＜MPDに配信モード情報とROI識別子を格納する場合＞
　図１７は、図１５および図１６に示された例のt=1のタイミングに対応するMPD-SRD表現を示している。図１８は、画像全体とそこにおける矩形領域の位置と解像度を示している。
　MPD-SRDにおける〈AdaptationSet id="1"…>からそれに対応する〈/AdaptationSet>までの記載は、図１８のＡに斜線で示される画面全体に対応する。〈AdaptationSet id="1-1"…>からそれに対応する〈/AdaptationSet>までの記載は、図１８のＢに斜線で示される画面全体の左上の矩形領域に対応する。ここに記載されているroiId="roiId1"等がMPDの拡張部分である。
　〈AdaptationSet id="1-3"…>からそれに対応する〈/AdaptationSet>までの記載は、図１８のＣに斜線で示される画面全体の左下の矩形領域に対応する。〈AdaptationSet id="1-4"…>からそれに対応する〈/AdaptationSet>までの記載は、図１８のＤに斜線で示される画面全体の右下の矩形領域に対応する。
　図１９および図２０は、ROI識別子を記載するためにMPDを拡張した具体的な位置に示している。
　同図に示されるように、ROI識別子を記載するためのroiId要素は、MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURLの属性に追加される。
　次に、図２１は、拡張したMPDに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示している。
　同図Ａに示されるサービスシグナリングセッションは、サービスレイヤのシグナリングXMLフラグメントであるSLSを転送するトランスポートセッションである。同図Ｂに示されるコンポーネントファイルセッションは、サービスを構成する各動画/音声/サブタイトル/アプリケーション/他各種データを転送するトランスポートセッションである。各コンポーネントセッションの詳細なストリーム属性はSLSに記載され、ストリームを取得するためのアドレスも記載される。
　ROUTEのファイル転送においては、UDP/IP上のLCTパケットのTSIに基づいてそのセッションが識別され、LCTパケットのTOIによりそのセッションの中で転送される各ファイルオブジェクトが識別される。
　同図Ａの例では、TSI=”sls-tsi”で識別されるサービスシグナリングセッションで、USDおよびS-TSIDを含むsls-bundleファイルが転送される。sls-bundelファイル自身はファイルURL=”slsid-url”、TOI=”0”により識別され、そこに格納されるUSDファイルとS-TSIDファイルは、それぞれ、ファイルURL=”usd-url”、”stsid-url”により識別される。(LCTのレイヤでファイルを再構成する際に必要となるのがTSIとTOIの組であり、sls-bundleファイル自身がTOI=”0”により再構成されるため、sls-bundleファイルの中に格納されたUSDやS-TSIDファイルはTOIが必要ない(ROUTEではこれをPackageModeのファイル転送と称している)。USD(USBD/USD)のuserServiceDescripionには各サービス属性が記載される。
　userServiceDescriptionは、S-TSIDファイルのurl（”stsid-url”）を格納するsTSIDUri属性を持つ。S-TSIDには、そのS-TSID/RS/LS/srcFlowに各コンポーネントの属性を記述する。
　同図Ａの例では、S-TSIDには１つのコンポーネントがあり、そのコンポーネントを構成するファイル群はTSI=”av-tsi”で識別されるセッションで転送され、そのセッションのファイル群の各々の属性を記述するEFDTがそれらファイル群と同じセッションで転送され、EFDTがファイルURL=”efdt-url”で識別されることを示す。TSI=”av-tsi”で識別されるセッションで転送されるEFDTには同一セッションで転送される１つファイルについて記述されており、そのファイルはファイルURL=”bcSeg.1-1.1”で識別され、TOI=”segmentFile-toi”のLCTパケットを集めると再構成できることを示している。再構成されたファイルURL=”bcSeg.1-1.1”で識別されるファイルにはSegmentの中身が格納されている。
　したがって、クライアント装置１００においてDASHクライアント部１４０が所定のsegmentURLによりsegment取得リクエストを発行すると、それを受けたプロキシサーバ部１３０が、ATSC3.0ミドルウエア１１０のシグナリングリトリーバ１１３とシグナリングパーサ１１４を介して取得、分析されたSLSシグナリングフラグメントやEFDTから所望のファイルを取得して再構成し、DASHクライアント部１４０へのレスポンスとして再構成したファイルを返すことになる。
　一方、同一のファイルをネット配信から取得する場合には、同図Ｃに示されるSegmentFile（ファイルURL”bbSeg.1-1.1”）にHTTPリクエストを発行し、それに応じて供給されるファイルを取得することになる。
　次に、図２２は、MPDに配信モード情報とROI識別子を格納した場合における動作シーケンスを示している。
　配信側においては、DASHサーバが、Segment毎に配信モード情報を記述するとともにROI識別子を適宜格納したMPDを生成して放送サーバに転送する。また、DASHサーバがコンテンツストリームのSegmentファイルを生成してWebサーバに転送するとともに、そのうちの放送配信併用のものについては放送サーバにも転送する。
　MPDが転送された放送サーバは、SLSファイルを生成し、生成したSLSファイルと転送されたMPDを、放送網を介して放送配信する。また、放送サーバは、DASHサーバから転送されたコンテンツストリームのSegmentファイルをROUTEのFileModeで放送配信する。
　受信側のクライアント装置１００においては、放送受信部１１０が、放送配信されたMPDとSLSファイルを受信する。この後、DASHクライアント部１４０が、放送受信部１１０に対してMPDを要求すると、その要求に応じて放送受信部１１０がDASHクライアント部１４０にMPDを供給する。なお、放送受信部１１０が放送配信されたMPDを受信していない場合、通信部１２０がDASHサーバにHTTPリクエストを発行してネット配信されるMPDを取得することができる。
　DASHクライアント部１４０では、MPDに記載されているROI識別子等に基づき、要求するSegmentを選択することができる。DASHクライアント部１４０がMPDに基づき、ネット配信されるSegmentを要求した場合、通信部１２０が該Segmentを要求するHTTPリクエストをWebサーバに対して発行し、それ応じてWebサーバから供給（ネット配信）された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
　また、DASHクライアント部１４０がMPDに基づき、放送配信されるSegmentを要求した場合、放送受信部１１が放送配信された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
　以上で、MPDに配信モード情報とROI識別子を格納した場合における動作シーケンスの説明を終了する。
　＜MPDにSegmentTemplateを利用する場合の対応＞
　ところで、ライブ放送等の配信にDASHを利用する場合、SegmentListにSegmentUrlを列記するとMPDのデータサイズが極端に大きくなってしまう(ATSC3.0等の場合にはSegment単体の時間が0.5秒くらいを想定している)。そこで通常の場合、MPDにはSegmentTemplateが利用される。
　図２３は、図１７に示されたMPD-SRD表現を、SegmentTemplateを利用して書き換えたものである。図２４は、図２３のMPD-SRD表現を可視化したものである。ただし、図２４における破線枠や１点鎖線枠内のSegmentUrlやROI識別子は、図２３のMPD-SRD表現では記述できない部分を表している。
　MPDにSegmentTemplateを利用することにより、MPDのデータサイズを大幅に削減することができる。ただし、SegmentTemplateはPeriod単位で同一の生成規則が適用されるので、個々のSegmentに対して異なる属性（いまの場合、配信モード情報やROI識別子）を記述することができない。
　図２４と図１６を比較して明らかなように、SegmentTemplateを利用した場合、同一Periodの配下にある時系列にならぶSegmentシーケンスにおいて、あるSegmentには放送配信urlとネット配信urlを指定し、他のSegmentにはネット配信urlのみを指定するようなことができない。また、特定のSegmentに対してのみROI識別子を指定することができない。
　したがって、MPDにSegmentTemplateを利用する場合には、個々のSegmentに対して指定できない配信モード情報やROI識別子を、MPD以外に格納して受信側にシグナリングする必要がある。
　＜USDに配信モード情報とROI識別子を格納する場合＞
　次に、SLSシグナリングのUSDを拡張して、各Segmentの配信モード情報とROI識別子をシグナリングする方法について説明する。
　各Segmentの配信モード情報については、従来のUSDでもシグナリングすることができる。
　USDはMPDに紐づけられており、USDのbundleDescriptionROUTE/userServiceDescription/deliveryMethod/broadcastAppService/basePattern(放送配信向けのurl一致パターン)、または、.../unicastAppService/basePattern (ネット配信向けのurl一致パターン)に列挙されているurlの一部(全部でもよい)が当該Segmentのurlに一致するとき、当該Segmentは放送網のROUTEを介する放送配置、または、CDNを介するネット配信されることを示すことになる。
　また、放送配信されるSegmentとネット配信されるSegmentが同一のものであることは、bundleDescriptionROUTE/userServiceDescription/deliveryMethod/appService/identicalContentによりグルーピングされているurlの組を用いて示すことができる。
　図２５は、ROI識別子を格納するためにUSDを拡張した具体的な位置に示している。同図に示されるように、ROI識別子(roiId)については、各SegmentのbasePatternの属性を拡張してROI識別子を格納する。
　図２６は、拡張したUSDに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示している。
　同図の例では、USDのuserServiceDescription/deliveryMethodの下の、放送配信urlのマッチングパターンを記載するbroadcastAppService/basePatternに”bcSeg.1-1.1”が記載され、そのROI識別子として”roiId1”が記載されている。一方、ネット配信urlのマッチングパターンを記載するunicastAppService/basePatternには”bbSeg.1-1.1”が記載され、そのROI識別子として”roiId1”が記載されている。これは、あるSegmentに対して放送配信とネット配信の両方で同じROI識別子が割り当てられていることを意味する。そして、これらのSegment群が同一のものであることは、deliveryMethod/appService/identicalContentによりグルーピングすることにより示すことができる。
　ここで、basePatternに記載するマッチングパターンは、通常、MPDに記載されるbaseURLやSegmentURLの一部(例えば、“http://a.com/bc”等)が記載されるが、各Segmentについて記載する場合はSegmentURLの全体(SegmentURLがユニークに解決できる部分まで)を記載することになる。よって、各SegmentのROIが変化するような場合は、Segment毎のURL粒度とUSDの更新粒度が等しくなる。
　クライアント装置１００において、ROI系列を追尾しないでSegmentを取得する場合、DASHクライアント部１４０はプロキシサーバ部１３０に対してSegmentURL=”bbSeg.1-1.1”(ネット配信url)のHTTPリクエストを通知すると、この通知が放送受信部１１０に渡り、放送受信部１１０ではbbSeg.1-1.1をUSDの中から探し、対応する放送配信urlである”bcSeg.1-1.1”が、コンポーネントファイルセッション上のurlであることがわかると、当該Segmentファイルを放送ストリームから取得してDASHクライアント部１４０に供給することとなる。
　一方、ROI系列を追尾してSegmentを取得する場合、放送受信部１１０がUSDを解析して得たSegmentがどのROI系列に属しているのか示す情報をDASHクライアント部１４０に通知する必要がある。この通知には、図８を参照して上述したDASHのSANDメッセージ等が利用される。
　具体的には、上述したように、SANDのResourceStatusメッセージのResourceStatus/Reason要素に放送配信併用情報とROI識別子を格納できるようにする。ただし、現在の規定では、reason要素にはヒント情報として任意の文字列を記載してもよいことになっているが、どういった情報が記載されるべきかの細かな規定(データ構造とセマンティクスの規定)がない。
　そこで、データ構造として、任意の受信状態メタデータを格納できるようSchemeIdUri(必須)とValue(オプショナル)の組を格納できるようにすることを提案する。SchemeIdUriには、受信状態を示すデータの内容を識別するURIを指定して、そのURIで規定される値の内容をvalueに記載できるようにする。
　例えば、SchemeIdUriとして放送配信併用であるを示す”urn:atsc:BroadcastDelivery”というURNを規定し、さらに、ROI識別子を格納するスキームとして”urn:atsc:roiValue”を規定してROI識別子をvalue属性に格納する。
　図２７は、放送配信併用情報とROI識別子を格納したResourceStatusメッセージの具体例を示している。同図Ａに示されるように、ResourceStatusメッセージは、baseURL要素とStatus要素とReason要素が記載される。なお、Reason要素には、同図Ｂに示されるように、配信モード情報とROI識別子がbase64エンコードされた状態の文字列として記載される。
　次に、図２８は、USDに配信モード情報とROI識別子を格納した場合における動作シーケンスを示している。
　配信側においては、DASHサーバが、SegmentTemplateを利用したMPDを生成して放送サーバに転送する。また、DASHサーバがコンテンツストリームのSegmentファイルを生成してWebサーバに転送するとともに、そのうちの放送配信併用のものについては放送サーバにも転送する。
　MPDが転送された放送サーバは、配信モード情報とROI識別子を格納したUSDを含むSLSファイルを生成し、生成したSLSファイルと転送されたMPDを、放送網を介して放送配信する。また、放送サーバは、DASHサーバから転送されたコンテンツストリームのSegmentファイルをROUTEのFileModeで放送配信する。
　受信側のクライアント装置１００においては、放送受信部１１０が、放送配信されたMPDとSLSファイルを受信する。この後、DASHクライアント部１４０が、放送受信部１１０に対してMPDを要求すると、その要求に応じて放送受信部１１０がDASHクライアント部１４０にMPDを供給する。なお、放送受信部１１０が放送配信されたMPDを受信していない場合、通信部１２０がDASHサーバにHTTPリクエストを発行してネット配信されるMPDを取得することができる。
　MPDが供給されたDASHクライアント部１４０では、SegmentTemplateに基づいて完全なSegmentURLを復元することによってMPDを再生成する。
　さらに、放送受信部１１０は、USDを解析して各Segmentの配信モード情報とROI識別子を判断し、その判断結果をプロキシサーバ部１３０に通知する。プロキシサーバ部１３０は、Segmentの配信モード情報とROI識別子を格納したResourceStatusメッセージを生成してDASHクライアント部１４０に通知する。
　DASHクライアント部１４０では、MPDとResourceStatusメッセージに記載されているROI識別子等に基づき、要求するSegmentを選択することができる。DASHクライアント部１４０がネット配信されるSegmentを要求した場合、通信部１２０が、該Segmentを要求するHTTPリクエストをWebサーバに対して発行し、それ応じてWebサーバから供給（ネット配信）された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
　また、DASHクライアント部１４０が放送配信されるSegmentを要求した場合、放送受信部１１が、放送配信された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
　以上で、USDに配信モード情報とROI識別子を格納した場合における動作シーケンスの説明を終了する。
　ところで、上述したようにUSDを用いて各Segmentの配信モード情報とROI識別子をシグナルした場合、Segment粒度(Segment単位毎)で放送配信併用であるか否かが変化するようなときには、その変化のたびにUSDを更新しなければならない。しかしながら、USDは、本来、サービス(チャネル)全体に亘って変化がない属性をシグナリングするために導入されており、頻繁に更新が必要となる運用は想定されていない(禁止されているわけではない）。そこで、USDを用いずに、同様のシグナリングを行う２種類の方法について以下の（１）および（２）の方法を提案する。
（１）ROUTEの転送モードがFileModeの場合、EFDTを拡張してROI識別子を格納する。
（２）ROUTEの転送モードがEFDTを利用しないEntityModeの場合、Entityヘッダを拡張して同一コンテンツを識別するurlや、ROI識別子を格納する。
　＜EFDTの拡張＞
　各Segmentの配信モード情報とROI識別子は、S-TSIDのEFDT(各コンポーネントファイルセッション上にそれが記述するファイル群とともに転送することができるシグナリングフラグメントの一部(断片))を用いてシグナルリングすることができる。
　図２９は、ROI識別子を格納するためにEFDTを拡張した具体的な位置に示している。同図に示されるように、efdtType/routesls:FDTParameters/File/atributes/Content-Location属性にRoiIdとIdentical-Content-Locationを並列に追加する。
　図３０は、拡張したEFDTに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示している。
　同図に示されるように、当該Segmentが生成された元となるMPDに紐づけられているUSDのbundleDescriptionROUTE/userServiceDescription@sTSIDUriから参照されるS-TSIDフラグメントのS-TSID/RS/LS/srcFlow/EFDTから参照されるコンポーネントファイルセッション中のEFDTに、当該SegmentファイルのファイルURLを記載するためのContent-Location属性に追加されたIdentical-Content-Locationにネット配信url(同図の場合、bbSeg.1-1.1)を記載し、RoiIdにROI記述子（同図の場合”roiid1）を記載する。
　この場合、拡張したUSDを用いるときと同様に、クライアント装置１００において、ROI系列を追尾しないでSegmentを取得する際には、DASHクライアント部１４０はプロキシサーバ部１３０に対してSegmentURL=”bbSeg.1-1.1”(ネット配信url)のHTTPリクエストを通知すると、この通知が放送受信部１１０に渡り、放送受信部１１０ではbbSeg.1-1.1をEFDTの中から探し、対応する放送配信urlである”bcSeg.1-1.1”が、コンポーネントファイルセッション上のurlであることがわかると、当該Segmentファイルを放送ストリームから取得してDASHクライアント部１４０に供給することとなる。
　一方、ROI系列を追尾してSegmentを取得する際には、放送受信部１１０がEFDTを解析して得たSegmentがどのROI系列に属しているのか示す情報をDASHクライアント部１４０に通知する必要がある。この通知には、上述したDASHのSANDメッセージ等が利用される。
　次に、図３１は、EFDTに配信モード情報とROI識別子を格納した場合における動作シーケンスを示している。
　配信側においては、DASHサーバが、SegmentTemplateを利用したMPDを生成して放送サーバに転送する。また、DASHサーバがコンテンツストリームのSegmentファイルを生成してWebサーバに転送するとともに、そのうちの放送配信併用のものについては放送サーバにも転送する。
　MPDが転送された放送サーバは、配信モード情報とROI識別子を格納したEFDTを含むSLSファイルを生成し、生成したSLSファイルと転送されたMPDを、放送網を介して放送配信する。また、放送サーバは、DASHサーバから転送されたコンテンツストリームのSegmentファイルをROUTEのFileModeで放送配信する。
　受信側のクライアント装置１００においては、放送受信部１１０が、放送配信されたMPDとSLSファイルを受信する。DASHクライアント部１４０が、放送受信部１１０に対してMPDを要求すると、その要求に応じて放送受信部１１０がDASHクライアント部１４０にMPDを供給する。なお、放送受信部１１０が放送配信されたMPDを受信していない場合、通信部１２０がDASHサーバにHTTPリクエストを発行してネット配信されるMPDを取得することができる。
　MPDが供給されたDASHクライアント部１４０では、SegmentTemplateに基づいて完全なSegmentURLを復元することによってMPDを再生成する。
　さらに、放送受信部１１０は、EFDTを解析して各Segmentの配信モード情報とROI識別子を判断し、その判断結果をプロキシサーバ部１３０に通知する。プロキシサーバ部１３０は、Segmentの配信モード情報とROI識別子を格納したResourceStatusメッセージを生成してDASHクライアント部１４０に通知する。
　DASHクライアント部１４０では、MPDとResourceStatusメッセージに記載されているROI識別子等に基づき、要求するSegmentを選択することができる。DASHクライアント部１４０がネット配信されるSegmentを要求した場合、通信部１２０が、該Segmentを要求するHTTPリクエストをWebサーバに対して発行し、それ応じてWebサーバから供給（ネット配信）された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
　また、DASHクライアント部１４０が放送配信されるSegmentを要求した場合、放送受信部１１が、放送配信された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
　以上で、EFDTに配信モード情報とROI識別子を格納した場合における動作シーケンスの説明を終了する。
　＜Entityヘッダの拡張＞
　各Segmentの配信モード情報とROI識別子は、コンポーネントファイルセッション中に当該ファイルをEntityModeで転送し、Entityヘッダを拡張することによりシグナルリングすることができる。
　図３２は、拡張したEntityヘッダに対応するサービスシグナリングトランスポートセッションとコンポーネントファイルトランスポートセッションの構成を示している。
　同図に示されるように、当該Segmentが生成された元となるMPDに紐づけられているUSDのbundleDescriptionROUTE/userServiceDescription@sTSIDUriから参照されるS-TSIDフラグメントのS-TSID/RS/LS＠tsiから参照されるコンポーネントファイルセッションで流れる当該SegmentファイルのEntityヘッダ中にIdentical-Content-Location要素とROI-id要素を設け、Identical-Content-Locationにはネット配信url(同図の場合、bbSeg.1-1.1)を記載し、ROI-idにはROI識別子（同図の場合、roiId1）を記載するようにする。
　この場合、拡張したUSDや拡張したEFDTを用いるときと同様に、クライアント装置１００において、ROI系列を追尾しないでSegmentを取得する際には、DASHクライアント部１４０はプロキシサーバ部１３０に対してSegmentURL=”bbSeg.1-1.1”(ネット配信url)のHTTPリクエストを通知すると、この通知が放送受信部１１０に渡り、放送受信部１１０ではbbSeg.1-1.1をもとに、放送ストリームから取得したEntityMode配信のファイル群のEntityヘッダの中からbbSeg.1-1.1に対応する放送配信urlである”bcSeg.1-1.1”が、コンポーネントファイルセッション上のurlであることがわかると、当該Segmentファイルを放送ストリームから取得してDASHクライアント部１４０に供給することとなる。
　一方、ROI系列を追尾してSegmentを取得する際には、放送受信部１１０がEntityヘッダを解析して得たSegmentがどのROI系列に属しているのか示す情報をDASHクライアント部１４０に通知する必要がある。この通知には、上述したDASHのSANDメッセージ等が利用される。
　次に、図３２は、Entityヘッダに配信モード情報とROI識別子を格納した場合における動作シーケンスを示している。
　配信側においては、DASHサーバが、SegmentTemplateを利用したMPDを生成して放送サーバに転送する。また、DASHサーバが、配信モード情報とROI識別子を格納したEntityヘッダを生成するとともに、コンテンツストリームのSegmentファイルを生成してWebサーバに転送し、そのうちの放送配信併用のものについては放送サーバにも転送する。
　MPDが転送された放送サーバは、SLSファイルを生成し、生成したSLSファイルと転送されたMPDを、放送網を介して放送配信する。また、放送サーバは、DASHサーバから転送されたコンテンツストリームのSegmentファイルをROUTEのEntityModeで放送配信する。
　受信側のクライアント装置１００においては、放送受信部１１０が、放送配信されたMPDとSLSファイルを受信する。DASHクライアント部１４０が、放送受信部１１０に対してMPDを要求すると、その要求に応じて放送受信部１１０がDASHクライアント部１４０にMPDを供給する。なお、放送受信部１１０が放送配信されたMPDを受信していない場合、通信部１２０がDASHサーバにHTTPリクエストを発行してネット配信されるMPDを取得することができる。
　MPDが供給されたDASHクライアント部１４０では、SegmentTemplateに基づいて完全なSegmentURLを復元することによってMPDを再生成する。
　さらに、放送受信部１１０は、Entityヘッダを解析して各Segmentの配信モード情報とROI識別子を判断し、その判断結果をプロキシサーバ部１３０に通知する。プロキシサーバ部１３０は、Segmentの配信モード情報とROI識別子を格納したResourceStatusメッセージを生成してDASHクライアント部１４０に通知する。
　DASHクライアント部１４０では、MPDとResourceStatusメッセージに記載されているROI識別子等に基づき、要求するSegmentを選択することができる。DASHクライアント部１４０がネット配信されるSegmentを要求した場合、通信部１２０が、該Segmentを要求するHTTPリクエストをWebサーバに対して発行し、それ応じてWebサーバから供給（ネット配信）された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
　また、DASHクライアント部１４０が放送配信されるSegmentを要求した場合、放送受信部１１が、放送配信された該Segmentを受信してDASHクライアント部１４０に供給する。DASHクライアント部１４０は、供給されたSegmentを再生する。
　以上で、Entityヘッダに配信モード情報とROI識別子を格納した場合における動作シーケンスの説明を終了する。
　＜クライアント装置１００におけるROI識別子の利用例＞
　上述したように、各ROI系列に対応するメタデータも供給される場合、クライアント装置１００ではこれらをU/Iに利用することができる。図３４は、各ROI系列に対応するROI識別子とメタデータの利用例を示している。
　同図Ａは、ROIが設定されている人物６０１が画面６００上に表示される際、それぞれのメタデータ（人物の名前など）の表示領域６０２を人物６０１とともに移動させて表示する利用例である。この利用例では、例えば、人物６０１Ｘを含む領域６０３Ｘがユーザによって指定された場合、画面６００の映像を、人物６０１Ｘを中心として拡大したり、人物６０１Ｘに対して設定されているROIの映像に切り替えたりすることができる。
　同図Ｂは、ROIが設定されている人物６０１が画面６００上に表示される際、そのメタデータ（人物の名前など）の表示領域６０２を画面６００の端にまとめて表示する利用例である。この利用例では、例えば、人物６０１Ｙに対応するメタデータの表示領域６０２Ｙがユーザによって選択された場合、画面６００の人物６０１Ｙが強調表示されたり（同図Ｂの表示例では、人物６０１Ｙの周囲に点滅表示する枠６０５が表示される）、人物６０１Ｙを中心として拡大したり、人物６０１Ｙに対して設定されているROIの映像に切り替えたりすることができる。
　＜他の実施形態＞
　ところで、上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
　図３５は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
　該コンピュータ１１００において、CPU（Central Processing Unit）１１０１，ROM（Read Only Memory）１１２，RAM（Random Access Memory）１１０３は、バス１１０４により相互に接続されている。
　バス１１０４には、さらに、入出力インタフェース１１０５が接続されている。入出力インタフェース１１０５には、入力部１１０６、出力部１１０７、記憶部１１０８、通信部１１０９、およびドライブ１１１０が接続されている。
　入力部１１０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１１０７は、ディスプレイ、スピーカなどよりなる。記憶部１１０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１１０９は、ネットワークインタフェースなどよりなる。ドライブ１１１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１１１１を駆動する。
　以上のように構成されるコンピュータ１１００では、CPU１１０１が、例えば、記憶部１１０８に記憶されているプログラムを、入出力インタフェース１１０５およびバス１１０４を介して、RAM１１０３にロードして実行することにより、上述した一連の処理が行われる。
　コンピュータ１１００（CPU１１０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１１１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
　コンピュータ１１００では、プログラムは、リムーバブルメディア１１１１をドライブ１１１０に装着することにより、入出力インタフェース１１０５を介して、記憶部１１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１１０９で受信し、記憶部１１０８にインストールすることができる。その他、プログラムは、ROM１１０２や記憶部１１０８に、あらかじめインストールしておくことができる。
　なお、コンピュータ１１００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであってもよい。
　なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　本技術は以下のような構成も取ることができる。
（１）
　複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
　前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
　前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
　を備える配信装置。
（２）
　前記通知部は、前記セグメントファイルに関する前記属性情報として、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を受信側に通知する
　前記（１）に記載の配信装置。
（３）
　前記通知部は、前記セグメントファイルに関する前記属性情報を、DASHで規定されているMPDに記載して受信側に通知する
　前記（１）または（２）に記載の配信装置。
（４）
　前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、USDに記載して受信側に通知する
　前記（１）または（２）に記載の配信装置。
（５）
　前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、EFDTに記載して受信側に通知する
　前記（１）または（２）に記載の配信装置。
（６）
　前記通知部は、DASHで規定されているMPDにSegmentTemplateが利用される場合、前記セグメントファイルに関する前記属性情報を、Entityヘッダに記載して受信側に通知する
　前記（１）または（２）に記載の配信装置。
（７）
　前記撮像範囲には１以上の前記ROIが設定される
　前記（１）から（６）のいずれかに記載の配信装置。
（８）
　前記配信部は、全て前記領域のそれぞれ対応する前記映像ストリームのセグメントファイルをネット配信するとともに、前記ROIを成す領域に対応するセグメントファイルを放送配信する
　前記（１）から（７）のいずれかに記載の配信装置。
（９）
　配信装置の配信方法において、
　前記配信装置による、
　　複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
　　前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信ステップと、
　　前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知ステップと
　を含む配信方法。
（１０）
　コンピュータを、
　複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
　前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
　前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
　して機能させるプログラム。
（１１）
　複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、
　前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
　要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
　取得された前記セグメントファイルを再生する再生部と
　を備える受信装置。
（１２）
　前記要求部は、ユーザからの操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
　前記（１１）に記載の受信装置。
（１３）
　前記要求部は、画面上の被写体を指定する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
　前記（１２）に記載の受信装置。
（１４）
　前記要求部は、被写体のメタデータを選択する操作によって特定されるROI識別子に対応する前記セグメントファイルを要求する
　前記（１２）に記載の受信装置。
（１５）
　前記属性情報は、さらに、前記セグメントファイルがネット配信または放送配信のどちらで配信されるのかを示す配信モード情報を含み、
　前記取得部は、前記配信モード情報に基づき、要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する
　前記（１１）から（１４）のいずれかに記載の受信装置。
（１６）
　前記解析部による前記属性情報の解析結果は、SANDメッセージを用いて前記要求部に通知される
　前記（１１）から（１５）のいずれかに記載の受信装置。
（１７）
　受信装置の受信方法において、
　前記受信装置による、
　　複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析ステップと、
　　前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求ステップと、
　　要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得ステップと、
　　取得された前記セグメントファイルを再生する再生ステップと
　を含む受信方法。
（１８）
　コンピュータを、
　複数の領域に分割されている撮像範囲に１以上の領域から成るROIが設定されている場合、前記ROIを成す領域に対応する映像ストリームのセグメントファイルに関する属性情報であって、少なくとも属する前記ROIを特定するためのROI識別子が含まれている前記属性情報を取得して解析する解析部と、
　前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
　要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
　取得された前記セグメントファイルを再生する再生部と
　して機能させるプログラム。
（１９）
　配信装置と受信装置を含むコンテンツ配信システムにおいて、
　前記配信装置は、
　　複数の領域に分割されている撮像範囲を撮像して得られる前記領域毎の映像ストリームをセグメントファイル化するセグメントファイル化部と、
　　前記領域毎の前記映像ストリームのセグメントファイルをネット配信または放送配信の少なくとも一方により受信側に供給する配信部と、
　　前記撮像範囲に１以上の前記領域から成るROIが設定された場合、前記ROIを成す領域に対応するセグメントファイルに関する属性情報として、属する前記ROIを特定するためのROI識別子を受信側に通知する通知部と
　を備え、
　前記受信装置は、
　　前記配信装置から通知された前記属性情報を解析する解析部と、
　　前記属性情報の解析結果に基づき、所定のROI識別子に対応する前記セグメントファイルを要求する要求部と、
　　要求された前記所定のROI識別子に対応する前記セグメントファイルをネット配信または放送配信を介して取得する取得部と、
　　取得された前記セグメントファイルを再生する再生部と
　を備える
　コンテンツ配信システム。
　１０　Broadcaster，　１１　放送網，　１２　CDN，　２０　LAN，　１００　クライアント装置，　１１０　放送受信部，　１２０　通信部，　１３０　プロキシサーバ部，　１４０　DASHクライアント部，　３００　DANE，　４００　DASH client，　５１４　ROI，　１１００　コンピュータ，　１１０１　CPU

Claims (19)

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

Priority Applications (8)

Application Number Priority Date Filing Date Title
CA3034585A CA3034585A1 (en) 2016-08-30 2017-08-17 Distribution device, distribution method, reception device, reception method, program, and content distribution system
EP17846142.2A EP3509310B1 (en) 2016-08-30 2017-08-17 Delivery device, delivery method, receiver, receiving method, program, and content delivery system
KR1020197004218A KR102376204B1 (ko) 2016-08-30 2017-08-17 분배 장치, 분배 방법, 수신 장치, 수신 방법, 프로그램 및 콘텐츠 분배 시스템
MX2019002296A MX2019002296A (es) 2016-08-30 2017-08-17 Dispositivo de distribucion, metodo de distribucion, dispositivo de recepcion, metodo de recepcion, programa y sistema de distribucion de contenidos.
CN201780051300.4A CN109644286B (zh) 2016-08-30 2017-08-17 分发装置和方法、接收装置和方法、介质和内容分发系统
US16/328,542 US10750243B2 (en) 2016-08-30 2017-08-17 Distribution device, distribution method, reception device, reception method, program, and content distribution system
JP2018537114A JPWO2018043134A1 (ja) 2016-08-30 2017-08-17 配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システム
US16/932,110 US11252478B2 (en) 2016-08-30 2020-07-17 Distribution device, distribution method, reception device, reception method, program, and content distribution system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016167607 2016-08-30
JP2016-167607 2016-08-30

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US16/328,542 A-371-Of-International US10750243B2 (en) 2016-08-30 2017-08-17 Distribution device, distribution method, reception device, reception method, program, and content distribution system
US16/932,110 Continuation US11252478B2 (en) 2016-08-30 2020-07-17 Distribution device, distribution method, reception device, reception method, program, and content distribution system

Publications (1)

Publication Number Publication Date
WO2018043134A1 true WO2018043134A1 (ja) 2018-03-08

Family

ID=61300582

Family Applications (1)

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

Country Status (8)

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

Families Citing this family (4)

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

Citations (4)

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

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110139130B (zh) * 2012-10-12 2022-09-20 佳能株式会社 流传输数据的方法、发送和接收视频数据的方法和设备
ITTO20130437A1 (it) * 2013-05-29 2014-11-30 Sisvel Technology Srl Metodo di elaborazione di un contenuto video ricevibile da una pluralità di piattaforme di distribuzione e relativo apparato di ricezione video
CN111954029B (zh) * 2015-01-29 2022-08-16 Lg 电子株式会社 广播信号发送和接收设备及广播信号发送和接收方法
CA3013111C (en) * 2016-02-02 2022-08-30 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Scene section and region of interest handling in video streaming

Patent Citations (4)

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

Also Published As

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

Similar Documents

Publication Publication Date Title
JP6348251B2 (ja) 端末装置、受信方法、およびプログラム
US11252478B2 (en) Distribution device, distribution method, reception device, reception method, program, and content distribution system
JP6329964B2 (ja) 送信装置、送信方法、受信装置、及び、受信方法
KR102499231B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
WO2014208377A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JPWO2018079295A1 (ja) 情報処理装置、及び、情報処理方法
JP2014239278A (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JP6492006B2 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、および、コンテンツ供給システム
WO2015146647A1 (ja) 送信装置、送信方法、受信装置、受信方法、及び、プログラム
US10893315B2 (en) Content presentation system and content presentation method, and program
JP2015002513A (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JP6597604B2 (ja) 受信装置、送信装置、データ通信方法、およびデータ処理方法
WO2015041071A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
KR102533674B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
KR102123208B1 (ko) 콘텐츠 공급 장치, 콘텐츠 공급 방법, 프로그램, 단말 장치, 및 콘텐츠 공급 시스템
JP7160030B2 (ja) 情報処理装置、受信装置、及び情報処理方法
WO2017212931A1 (ja) 受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17846142

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018537114

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20197004218

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 3034585

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017846142

Country of ref document: EP

Effective date: 20190401