Content delivery control including selecting type of upscaling scheme, apparatus, method, program, and system therefor

The present disclosure relates to a content delivery control apparatus, a content delivery control method, a program, and a content delivery system capable of achieving commonality of conditions associated with transcoding at the time of content delivery in different CDNs and supporting a standard upload interface.In a case in which definition information is stored in a metadata file, transcoding of an original segment is controlled on the basis of the definition information. Meanwhile, in a case in which access information for accessing the definition information is stored in the metadata file, then the definition information is requested on the basis of the access information, and the transcoding of the original segment is controlled on the basis of the definition information received in response to the request. The present disclosure is applicable to a content delivery system that delivers a content using MPEG-DASH.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is based on PCT filing PCT/JP2019/005188, filed Feb. 14, 2019, which claims priority to JP 2018-035081, filed Feb. 28, 2018, the entire contents of each are incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates to a content delivery control apparatus, a content delivery control method, a program, and a content delivery system, and particularly relates to a content delivery control apparatus, a content delivery control method, a program, and a content delivery system capable of achieving commonality of conditions associated with transcoding at the time of content delivery in different CDNs (Contents Delivery Networks) and supporting a standard upload interface.

BACKGROUND ART

As a trend of standardization in Internet streaming such as IPTV (Internet Protocol Television), standardization of an approach applied to VOD (Video On Demand) streaming and live streaming based on HTTP (Hypertext Transfer Protocol) streaming has been underway.

Attention has been paid particularly to MPEG-DASH (Dynamic Adaptive Streaming over HTTP) standardized in ISO/IEC/MPEG (refer to, for example, NPL 1).

MPEG-DASH is a technology for acquiring and reproducing streaming data in accordance with a metadata file called MPD (Media Presentation Description) and addresses (URLs: Uniform Resource Locators) of media data of chunked audio, video, subtitles, or the like described in the metadata file.

Furthermore, a study regarding a framework that is FLUS (Framework For Live Uplink Streaming) is currently underway in 3GPP (Third Generation Partnership Project) as an upload interface from stream capture devices to a cloud (refer to, for example, NPL 2 and NPL 3).

CITATION LIST

Patent Literature

[NPL 1]ISO/IEC 23009-1:2012 Information technology Dynamic adaptive streaming over HTTP (DASH)[NPL 2]3GPP TS 26.238 V15.0.0(2017-12) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Uplink Streaming (Release 15)[NPL 3]3GPP TS 26.114 V15.1.0(2017-12) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem(IMS); Multimedia Telephony; Media handling and interaction (Release 15)

SUMMARY

Technical Problem

Meanwhile, there is a probability that a streaming content transitioning into a delivery phase is provided by causing, for example, an edge server (constituent element of the CDN) close to an end user to transcode the streaming content in accordance with stream reproduction environmental conditions of the end user. For example, at the time of transcoding, an original stream is decoded temporarily to a baseband stream and further encoded as a stream suited for a user's reproduction environment. At the time of conversion into this baseband, there is a probability that an edge server having remaining power performs various types of upscaling (upconversion) processing in accordance with the environmental conditions of the end user.

For example, there is a probability that optimal audio and pictures are created while taking into account an aspect ratio or a spatial resolution of a display of a device of the end user, characteristics of a reproducing instrument, and the like, and are encoded as a stream in accordance with a processing capability of a decoder. As creation of the optimal audio and pictures, it is supposed herein that sophisticated images or audios are added using not only upconversion in a simple linear extrapolation way but also, for example, AI (Artificial Intelligence) or the like. It is, however, required that whether or not this upscaling processing, creation of audio and pictures, or the like is permitted is controlled depending on an intention of a content provider (content owner) or a service provider (delivery service provider or the like). In other words, it is necessary to be capable of exercising delivery control as per the intention of the owner, servicer, or the like until the edge server in a delivery platform.

Meanwhile, standard metadata sharable among CDN services provided by various vendors and associated with stream reproducing control is not prepared under present circumstances. It is, therefore, required to achieve commonality of conditions associated with transcoding at the time of content delivery by describing various conditions associated with transcoding described above in a streaming manifest file such as a DASH-MPD (or HLS m3u8).

In other words, CDNs are provided by a plurality of vendors in general, and various types of control, policies, and the like associated with delivery of contents using a common manifest in the different CDNs are not standardized. Owing to this, it is necessary determine destinations and the like to, for example, report (collect logs of) constraints, conditions, and the like associated with transcoding.

Furthermore, with an increase in the number of use cases of delivering streams of, for example, UGC (User Generated Contents) contents, there is a probability of supporting a standard content upload interface (live streaming uplink) even in a delivery platform such as a video ecosystem.

It is, therefore, required to give support in such a manner as to be capable of declaring control over whether or not an edge server can transcode a streaming content transitioning into the delivery phase, and capable of collecting logs such as types and frequencies of transcoding to be executed and utilizing the collected logs for effective operations in accordance with such protocols. Furthermore, it is supposed that transcoding includes a case involving content modifications, and it is necessary to define an upload interface corresponding to such a case.

The present disclosure has been achieved in light of such circumstances, and an object of the present disclosure is to be capable of providing commonality of conditions associated with transcoding at the time of content delivery in different CDNs and supporting a standard upload interface.

Solution to Problem

A content delivery control apparatus according to one aspect of the present disclosure includes a generation section that generates a metadata file storing therein definition information necessary for transcoding a content or first access information for accessing the definition information and second access information for accessing an original segment that is original data generated from the content and that is compliant with MPEG-DASH, a receiving section that receives the metadata file, and a control section that exercises control associated with transcoding of the original segment acquired on the basis of the second access information. The control section controls the transcoding of the original segment on the basis of the definition information in a case in which the definition information is stored in the metadata file. The control section requests the definition information on the basis of the first access information and controls the transcoding of the original segment on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file.

A content delivery control method according to one aspect of the present disclosure includes, by a content delivery control apparatus including a generation section that generates a metadata file storing therein definition information necessary for transcoding a content or first access information for accessing the definition information and second access information for accessing an original segment that is original data generated from the content and that is compliant with MPEG-DASH, a receiving section that receives the metadata file, and a control section that exercises control associated with transcoding of the original segment acquired on the basis of the second access information, causing the control section to control the transcoding of the original segment on the basis of the definition information in a case in which the definition information is stored in the metadata file, and causing the control section to request the definition information on the basis of the first access information and to control the transcoding of the original segment on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file.

A program according to one aspect of the present disclosure causes a computer of a content delivery control apparatus including a generation section that generates a metadata file storing therein definition information necessary for transcoding a content or first access information for accessing the definition information and second access information for accessing an original segment that is original data generated from the content and that is compliant with MPEG-DASH, a receiving section that receives the metadata file, and a control section that exercises control associated with transcoding of the original segment acquired on the basis of the second access information, to execute processing including causing the control section to control the transcoding of the original segment on the basis of the definition information in a case in which the definition information is stored in the metadata file, and causing the control section to request the definition information on the basis of the first access information and to control the transcoding of the original segment on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file.

A content delivery system according to one aspect of the present disclosure includes a first server that has a storage section storing a content therein, a second server that exercises content delivery control, and a client that acquires and reproduces the content delivered in accordance with the content delivery control. The second server includes a generation section that generates a metadata file storing therein definition information necessary for transcoding the content or first access information for accessing the definition information and second access information for accessing an original segment that is original data generated from the content and that is compliant with MPEG-DASH, a receiving section that receives the metadata file, and a control section that exercises control associated with transcoding of the original segment acquired on the basis of the second access information. The control section controls the transcoding of the original segment on the basis of the definition information in a case in which the definition information is stored in the metadata file. The control section requests the definition information on the basis of the first access information and controls the transcoding of the original segment on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file.

In one aspect of the present disclosure, a metadata file in which definition information necessary for transcoding a content is stored or first access information for accessing the definition information and second access information for accessing an original segment that is original data generated from the content and that is compliant with MPEG-DASH are stored is generated, the metadata file is received, and control associated with the transcoding of the original segment acquired on the basis of the second access information is exercised. Furthermore, the transcoding of the original segment is controlled on the basis of the definition information in a case in which the definition information is stored in the metadata file. Meanwhile, the definition information is requested on the basis of the first access information and the transcoding of the original segment is controlled on the basis of the definition information received in response to the request in a case in which the first access information is stored in the metadata file.

Advantageous Effect of Invention

According to one aspect of the present disclosure, it is possible to provide commonality of conditions associated with transcoding at the time of content delivery in different CDNs and support a standard upload interface.

It is noted that advantages are not always limited to those described herein but may be any of the advantages described in the present disclosure.

DESCRIPTION OF EMBODIMENTS

Specific embodiments to which the present technology is applied will be described in detail hereinafter with reference to the drawings.

First and Second Examples of Configuration of Content Delivery System

FIG. 1is a block diagram depicting an example of a configuration of a first embodiment of a content delivery system to which the present technology is applied, andFIG. 2is a block diagram depicting an example of a configuration of a second embodiment of a content delivery system to which the present technology is applied.

A content delivery system11A depicted inFIG. 1is configured, for example, such that a content providing apparatus13A and a DASH player14are connected to cloud computing (hereinafter, referred to as “cloud”)12providing various services via the Internet. In addition, in the content delivery system11A, a content delivered from a stream source server21provided in the content providing apparatus13A is provided to the DASH player14via a CDN23constructed by a plurality of CDN servers on the cloud12by way of a DASH delivery server22on the cloud12.

Similarly to the content delivery system11A, a content delivery system11B depicted inFIG. 2is configured such that a content providing apparatus13B and the DASH player14are connected to the cloud12. In addition, in the content delivery system11B, a content delivered from the stream source server21provided in the content providing system13B by way of the DASH delivery server22is provided to the DASH player14via the CDN23constructed by the plurality of CDN servers on the cloud12.

In other words, the content delivery system11A ofFIG. 1is configured such that the DASH delivery server22is provided on the cloud12separately from the content providing apparatus13A configured with the stream source server21. On the other hand, the content delivery system11B ofFIG. 2is configured such that the content providing apparatus13A configured with the stream source server21is also configured with the DASH delivery server22.

The content providing apparatuses13A and13B are each an input apparatus (stream capture device) which is, for example, a so-called smartphone and a digital camera and to which a content is input.

The DASH player14is an output apparatus which is, for example, a so-called smartphone, a tablet, a personal computer, a television receiver, a game instrument, and a head mounted display and which reproduces and outputs a content.

The stream source server21has a storage section that stores a delivered content in the content delivery system11A or11B and reads a content requested by, for example, the DASH player14to deliver the content from the storage section and delivers the content.

The DASH delivery server22has at least an encoder, a DASH segmenter, and an MPD generator and can encode a content delivered in the content delivery system11A or11B and generate a segment and generate an MPD in accordance with MPEG-DASH.

The CDN23is configured in a multistage fashion by the plurality of CDN servers (such as a CDN origin server41a, a CDN relay server, and a CDN edge server41bto be described later) and constructs an optimized network for content delivery.

It is noted that a framework that is the FLUS (refer to NPL 2 and NPL 3 described above) is used for an upload interface from the content providing apparatus13A or13B to the cloud12. In other words, as depicted inFIG. 1, a FLUS interface is used between the stream source server21and the DASH delivery server22in the content delivery system11A, and the DASH delivery server22, for example, acquires the segment and the MPD via the FLUS interface. In addition, as depicted inFIG. 2, the FLUS interface is used between the DASH delivery server22and the CDN23in the content delivery system11B, and the CDN23, for example, acquires the segment and the MPD via the FLUS interface.

A system configuration of the FLUS interface in the content providing apparatus13A ofFIG. 1will be described with reference toFIG. 3.

In the content providing apparatus13A, the content providing apparatus13A configured with the stream source server21serves as a FLUS source, and a FLUS sink is provided on the cloud12configured with the DASH delivery server22. Description will be given herein on the assumption that the stream source server21and the DASH delivery server22perform processing associated with FLUS media and that FLUS controllers provided by the content providing apparatus13A and the cloud12perform processing associated with FLUS control.

In Step S11, the FLUS controller of the content providing apparatus13A requests Authentication or Authorization, and Authentication or Authorization parameters are transmitted from the content providing apparatus13A to the cloud12.

Upon receiving the Authentication or Authorization parameters transmitted in Step S11, the FLUS controller of the cloud12returns Authentication or Authorization. An AccessToken indicating that a right to access services is given is thereby transmitted from the cloud12to the content providing apparatus13A.

Upon receiving the AccessToken transmitted in Step S12, the FLUS controller of the content providing apparatus13A requests Service establishment in Step S13, and an AccessToken is transmitted from the content providing apparatus13A to the cloud12. It is noted herein that the AccessToken is transmitted in this way for the purpose of proving that the AccessToken is assigned to a message of requesting the Service establishment and that the right to access services is given. It is noted that an AccessToken to be transmitted in each of subsequent steps is used for a similar purpose in each processing.

Upon receiving the AccessToken transmitted in Step S13, the FLUS controller of the cloud12returns Service establishment in Step S14. A ServiceID of a Service established in the cloud12is thereby transmitted from the cloud12to the content providing apparatus13A.

Upon receiving the ServiceID transmitted in Step S14, the FLUS controller of the content providing apparatus13A requests a ServiceResource in Step S15. An AccessToken and the ServiceID are thereby transmitted from the content providing apparatus13A to the cloud12.

Upon receiving the AccessToken and the ServiceID transmitted in Step S15, the FLUS controller of the cloud12returns the ServiceResource in Step S16. The ServiceResource is thereby transmitted from the cloud12to the content providing apparatus13A.

Upon receiving the ServiceResource transmitted in Step S16, the FLUS controller of the content providing apparatus13A updates the ServiceResource to the received ServiceResource in Step S17in the case of subsequent need to change attributes of the Service itself. In addition, an AccessToken, the ServiceID, and the ServiceResource are transmitted from the content providing apparatus13A to the cloud12.

Upon receiving the AccessToken, the ServiceID, and the ServiceResource transmitted in Step S17, the FLUS controller of the cloud12returns an ACK indicating success in receiving the AccessToken, the ServiceID, and the ServiceResource in Step S18.

Upon receiving the ACK in Step S18, the FLUS controller of the content providing apparatus13A requests Session establishment in Step S19. An AccessToken is thereby transmitted from the content providing apparatus13A to the cloud12.

Upon receiving the AccessToken transmitted in Step S19, the FLUS controller of the cloud12returns Session establishment in Step S20. A SessionID of a Session established on the cloud12is thereby transmitted from the cloud12to the content providing apparatus13A.

Upon receiving the SessionID transmitted in Step S20, the FLUS controller of the content providing apparatus13A requests a SessionResource in Step S21. An AccessToken and the ServiceID are thereby transmitted from the content providing apparatus13A to the cloud12.

Upon receiving the AccessToken and the ServiceID transmitted in Step S21, the FLUS controller of the cloud12returns the SessionResource in Step S22. The SessionResource is thereby transmitted from the cloud12to the content providing apparatus13A.

Upon receiving the SessionResource transmitted in Step S22, the FLUS controller of the content providing apparatus13A updates the SessionResource to the received SessionResource in Step S23. In addition, an AccessToken, the ServiceID, and the SessionResource are transmitted from the content providing apparatus13A to the cloud12.

Upon receiving the AccessToken, the ServiceID, and the SessionResource transmitted in Step S23, the FLUS controller of the cloud12returns an ACK indicating success in receiving the AccessToken, the ServiceID, and the SessionResource in Step S24.

The stream source server21then starts transferring a stream and metadata and transmits a Stream and Metadata together with an AccessToken and the SessionID in Step S25. At this time, the stream source server21can also notify the DASH delivery server22of TranscodeDirective of the Stream concerned by storing similar contents to those notified by storing the contents in the SessionResource updated in Step S23in the Metadata.

Upon receiving the Stream and the Metadata together with the AccessToken and the SessionID transmitted in Step S25, the DASH delivery server22returns an ACK indicating success in receiving the Stream, the Metadata, and the like in Step S26.

Subsequently, similar processing to Steps S25and S26is repeatedly performed between the stream source server21and the DASH delivery server22until end of delivery of the stream.

Furthermore, after end of delivery of the stream, the FLUS controller of the content providing apparatus13A requests Session release in Step S27. An AccessToken and the SessionID are thereby transmitted from the content providing apparatus13A to the cloud12.

Upon receiving the AccessToken and the SessionID transmitted in Step S27, the FLUS controller of the cloud12returns an ACK indicating success in receiving the AccessToken and the SessionID in Step S18. The FLUS controller of the cloud12performs processing for releasing the Session in response to this request.

Upon receiving the ACK in Step S28, the FLUS controller of the content providing apparatus13A requests Service release in Step S29. An AccessToken and the ServiceID are thereby transmitted from the content providing apparatus13A to the cloud12.

Upon receiving the AccessToken and the ServiceID transmitted in Step S29, the FLUS controller of the cloud12returns an ACK indicating success in receiving the AccessToken and the ServiceID in Step S30. The FLUS controller of the cloud12performs processing for releasing the Service in response to this request and ends the processing when the FLUS controller of the content providing server13A receives the ACK.

As described so far, either the FLUS controller of the content providing apparatus13A updates contents of the SessionResource transmitted from the FLUS controller of the cloud12and transmits the updated contents to the FLUS controller of the cloud12, or the stream source server21transmits the Metadata to the DASH delivery server22of the cloud12, so that the FLUS source can notify the FLUS sink of the TranscodeDirective of the Stream concerned.

A system configuration of the FLUS interface in the content providing apparatus13B ofFIG. 2will be described with reference toFIG. 4.

In the content providing apparatus13B, the content providing apparatus13B configured with the DASH delivery server22serves as a FLUS source, and a FLUS sink is provided on the CDN23configured with the DASH delivery server22. Description will be given herein on the assumption that the DASH delivery server22and the CDN23perform processing associated with FLUS media, and that FLUS controllers provided by the content providing apparatus13B and the cloud12perform processing associated with FLUS control.

In Steps S51to S64, similar processing to that in Steps S11to S24ofFIG. 3is performed between the FLUS controllers of the content providing apparatus13B and the cloud12.

In Step S65, the DASH delivery server22then starts transferring the DASH segment and the MPD.

Subsequently, the DASH delivery server22starts transferring the DASH segment and the MPD and transmits a DASH-Segment group and the MPD together with an AccessToken and the SessionID in Step S65. At this time, the DASH delivery server22can also notify the CDN23of TranscodeDirective of the DASH-Segment concerned by storing similar contents to those notified by storing the contents in the SessionResource updated in Step S63in the MPD.

Upon receiving the AccessToken, the SessionID, the DASH-Segment group, and the MPD transmitted in Step S65, the CDN23returns an ACK indicating success in receiving the AccessToken and the like in Step S66.

Similar processing to Steps S65and S66is repeatedly performed hereinafter between the DASH delivery server22and the CDN23until end of delivery of the stream.

Furthermore, after end of delivery of the stream, similar processing to that in Steps S27to S30ofFIG. 3is performed between the FLUS controllers of the content providing apparatus13B and the cloud12in Steps S67to S70.

As described so far, either the FLUS controller of the content providing apparatus13B updates contents of the SessionResource transmitted from the FLUS controller of the cloud12and transmits the updated contents to the FLUS controller of the cloud12, or the DASH delivery server22transmits the MPD to the CDN23of the cloud12, so that the FLUS source can notify the FLUS sink of the TranscodeDirective of the DASH-Segment concerned.

Detailed Example of Protocols

Details of protocols used in content delivery processing ofFIGS. 3 and 4will be described with reference toFIGS. 5 to 11. For example, API is implemented by RESTful API (call interface for HTTP of a Web system constructed to comply with a REST principle).

As depicted in (a) ofFIG. 5, in the request of Service establishment (Step S13ofFIG. 3and Step S53ofFIG. 4), the FLUS source transmits an HTTP method, for example, HTTP POST for transmitting data from the FLUS source, to the FLUS sink. At this time, the ServiceResource, for example, is stored in a body part.

In addition, in a response to the request (Step S14ofFIG. 3and Step S54ofFIG. 4), the FLUS sink transmits an HTTP status code, for example, HTTP 201 CREATED for indicating creation of a new resource as a result of success in the request of Service establishment, to the FLUS source. At this time, a url of the ServiceResource updated in the FLUS sink, for example, is stored in a location header. Furthermore, as in the example of the ServiceResource depicted inFIG. 6, in the case of success in Service establishment, a value allocated to a service-id (ServiceID) of the ServiceResource generated in the FLUS sink is stored therein.

As depicted in (b) ofFIG. 5, in a request of the ServiceResource (Step S15ofFIG. 3and Step S55ofFIG. 4), the FLUS source transmits an HTTP method, for example, HTTP GET for requesting information designated by the url, to the FLUS sink. At this time, by the HTTP GET, the url of the ServiceResource returned as a response to Service establishment and updated by the FLUS sink is designated.

In addition, in a response to the request (Step S16ofFIG. 3and Step S56ofFIG. 4), the FLUS sink transmits an HTTP status code, for example, HTTP 200 OK for indicating success in the request of the ServiceResource, to the FLUS source. At this time, the ServiceResource concerned is stored in a body part.

As depicted in (c) ofFIG. 5, in an update of the ServiceResource (Step S17ofFIG. 3and Step S57ofFIG. 4), the FLUS source transmits an HTTP method, for example, HTTP PUT for replacing a file on a server designated by the url, to the FLUS sink. At this time, the ServiceResource updated in the FLUS source is stored in a body part.

In addition, in a response to the update (Step S18ofFIG. 3and Step S58ofFIG. 4), the FLUS sink transmits an HTTP status code, for example, HTTP 200 OK for indicating success in updating the ServiceResource, to the FLUS source. At this time, in the case of success in updating the ServiceResource, the url of the ServiceResource updated in the FLUS sink is stored in a location header.

As depicted in (d) ofFIG. 5, in a request of Session establishment (Step S19ofFIG. 3and Step S59ofFIG. 4), the FLUS source transmits an HTTP method, for example, HTTP POST for transmitting data from the FLUS source, to the FLUS sink. At this time, the SessionResource, for example, is stored in a body part.

In addition, in a response to the request (Step S20ofFIG. 3and Step S60ofFIG. 4), the FLUS sink transmits an HTTP status code, for example, HTTP 201 CREATED for indicating creation of a new resource as a result of success in the request of Service establishment, to the FLUS source. At this time, the url of the ServiceResource updated in the FLUS sink, for example, is stored in the location header. Furthermore, as in the example of the SessionResource depicted inFIG. 7, in the case of success in Session establishment, a value assigned to a Sessione-id (SessionID) of the SessionResource generated in the FLUS sink is stored therein.

As depicted inFIG. 7, herein, ““information for FLUS sink to acquire (by Push/Pull) stream from FLUS source”” is described in the SessionResource, andFIG. 8depicts an example of the information.

As depicted inFIG. 8, as this information, ““URL of MPD of session stream concerned”” is described in the case of Pull acquisition, and ““URL of SDP (Session Description Protocol) of session stream concerned”” is described in the case of Push acquisition.

Moreover,FIG. 9depicts an example of the SDP in ““URL of SDP (Session Description Protocol) of session stream concerned”” depicted inFIG. 8. For example, at the time of delivery of a stream using the SDP, a new session attribute a=transcodeDirective is introduced such that the TranscodeDirective can be disposed in a part of a session attribute description of a video.

Furthermore, in the case of storing a URL of a TranscodeDirective information structure (file) as a variation of “a=transcodeDirective:“contents of TranscodeDirective (base64 encoded character string of TranscodeDirective described in XML)”” depicted inFIG. 9, “a=transcodeDirective:“URL of TranscodeDirective (URL of TranscodeDirective file described in XML)”” is described.

WhileFIG. 9depicts an example of using a SDP file standardized and defined in an IETF (Internet Engineering Task Force) as the metadata file and storing the TranscodeDirective in a media description portion of a media session concerned of the SDP, the TranscodeDirective may be stored in the SessionResource concerned of the FLUS as a variation of this example as depicted inFIG. 10. Furthermore, as a variation thereof, a url of the file is sometimes stored therein.

As depicted in (a) ofFIG. 11, in a request of the SessionResource (Step S21ofFIG. 3and Step S61ofFIG. 4), the FLUS source transmits an HTTP method, for example, HTTP GET for requesting information designated by the url, to the FLUS sink. At this time, by the HTTP GET, the url of the SessionResource returned as a response to Session establishment and updated in the FLUS sink is designated.

In addition, in a response to the request (Step S22ofFIG. 3and Step S62ofFIG. 4), the FLUS sink transmits an HTTP status code, for example, HTTP 200 OK for indicating success in the request of the SessionResource, to the FLUS source. At this time, the SessionResource concerned is stored in a body part.

As depicted in (b) ofFIG. 11, in an update of the SessionResource (Step S23ofFIG. 3and Step S63ofFIG. 4), the FLUS source transmits an HTTP method, for example, HTTP PUT for replacing a file on a server designated by the url, to the FLUS sink. At this time, the SessionResource updated in the FLUS source is stored in a body part.

In addition, in a response to the request (Step S24ofFIG. 3and Step S64ofFIG. 4), the FLUS sink transmits an HTTP status code, for example, HTTP 200 OK for indicating success in updating the SessionResource, to the FLUS source. At this time, in the case of success in updating the Service, the url of the SessionResource updated in the FLUS sink is stored in a location header.

As depicted in (c) ofFIG. 11, in a release of the Session (Step S27ofFIG. 3and Step S67ofFIG. 4), the FLUS source transmits an HTTP method, for example, HTTP DELETE for deleting a file on the server designated by the url, to the FLUS sink. At this time, the url of the SessionResource is designated by HTTP DELETE.

In addition, in a response to the release (Step S28ofFIG. 3and Step S68ofFIG. 4), the FLUS sink transmits an HTTP status code, for example, HTTP 200 OK for indicating success in releasing the Session, to the FLUS source. At this time, in the case of success in releasing the Session, the url of the released SessionResource is stored in a location header.

As depicted in (d) ofFIG. 11, in a release of the Service (Step S29ofFIG. 3and Step S69ofFIG. 4), the FLUS source transmits an HTTP method, for example, HTTP DELETE for deleting a file on the server designated by the url, to the FLUS sink. At this time, the url of the ServiceResource is designated by HTTP DELETE.

In addition, in a response to the release (Step S30ofFIG. 3and Step S70ofFIG. 4), the FLUS sink transmits an HTTP status code, for example, HTTP 200 OK for indicating success in releasing the Service, to the FLUS source. At this time, in the case of success in releasing the Service, the url of the released ServiceResource is stored in a location header.

<Example of Configuration of Each Block in Content Delivery System>

An example of configurations of blocks configuring a content delivery system11will be described with reference toFIGS. 12 to 17. It is noted that the content delivery system11depicted inFIG. 12corresponds to the configuration of any of the content delivery system11A ofFIG. 1and the content delivery system11B ofFIG. 2. In other words, with the configuration of the content delivery system11A, the FLUS interface is used between the stream source server21and the DASH delivery server22, and with the configuration of the content delivery system11B, the FLUS interface is used between the DASH delivery server22and CDNs23-1and23-2.

As depicted inFIG. 12, in the content delivery system11, the DASH delivery server22is connected to the stream source server21, and a streaming delivery manager31is connected to the DASH delivery server22. For example, the DASH delivery server22supplies an original MPD to the streaming delivery manager31, and the streaming delivery manager31returns the MPD to which the TranscodeDirective is added to the DASH delivery server22.

Furthermore, in the content delivery system11depicted inFIG. 12, an example of delivering contents using the CDNs23-1and23-2provided by two vendors is depicted, and each of the CDNs23-1and23-2is configured with multistage CDN servers41. In addition, the DASH delivery server22transmits the MPD and segment to each of a CDN origin server41a-1of the CDN23-1and a CDN origin server41a-2of the CDN23-2.

The CDN23-1is configured with the CDN origin server41a-1, multistage CDN relay servers, not depicted, and a CDN edge server41b-1. The MPD and the segment supplied from the DASH delivery server22to the CDN origin server41a-1arrive at the CDN edge server41b-1via the multistage CDN relay servers, not depicted. Furthermore, the CDN edge server41b-1transmits the MPD and the segment to each of DASH players14-1and14-2, where the content is reproduced.

The CDN23-2is configured with the CDN origin server41a-2, multistage CDN relay servers, not depicted, and a CDN edge server41b-2, and the CDN edge server41b-2has a transcoder42and a transcode manager43. The MPD and the segment supplied from the DASH delivery server22to the CDN origin server41a-2arrive at the CDN edge server41b-2via the multistage CDN relay servers, not depicted.

In the CDN edge server41b-2, the TranscodeDirective-added MPD and an untranscoded segment are input to the transcoder42. Furthermore, in the CDN edge server41b-2, the MPD changed to refer to the transcoded segment and the transcoded segment are output from the transcoder42. Moreover, the CDN edge server41b-2transmits the MPD changed to refer to the transcoded segment and the transcoded segment to the DASH player14-3. Therefore, the DASH player14-3acquires the content delivered in this way and reproduces the content.

FIG. 13is a block diagram depicting an example of a configuration of the stream source server21.

As depicted inFIG. 13, the stream source server21is configured with a video input section51, an audio input section52, a stream generation/storage section53, a stream delivery section54, a metadata generation/storage section55, and a metadata delivery section56.

Video data captured by, for example, an imaging apparatus that is not depicted is input to the video input section51, and audio data collected by, for example, a sound pickup apparatus that is not depicted is input to the audio input section52.

The stream generation/storage section53generates a stream on the basis of the video data supplied from the video input section51and the audio data supplied from the audio input section52, and stores the stream.

The stream delivery section54reads the stream from the stream generation/storage section53and delivers the stream to the DASH delivery server22.

The metadata generation/storage section55generates metadata regarding the stream stored in the stream generation/storage section53and stores the metadata.

The metadata delivery section56reads the metadata from the metadata generation/storage section55and delivers the metadata to the DASH delivery server22.

FIG. 14is a block diagram depicting an example of a configuration of the streaming delivery manager31.

As depicted inFIG. 14, the streaming delivery manager31is configured with a TranscodeDirective generation section61.

The TranscodeDirective generation section61generates TranscodeDirective (definition information) describing control, conditions, and the like at the time of performing transcoding by the transcoder42, for example. In addition, the TranscodeDirective generation section61adds the generated TranscodeDirective to the original MPD supplied from the DASH delivery server22and supplies the TranscodeDirective-added MPD to the DASH delivery server22.

FIG. 15is a block diagram depicting an example of a configuration of the DASH delivery server22.

As depicted inFIG. 15, the DASH delivery server22is configured with a metadata acquisition/storage section71, a stream acquisition/storage section72, a segment generation section73, an MPD generation section74, a segment delivery section75, and an MPD delivery section76.

The metadata acquisition/storage section71acquires the metadata supplied from the metadata delivery section56of the stream source server21and stores the metadata. In addition, the metadata acquisition/storage section71supplies the metadata to the stream acquisition/storage section72and the MPD generation section74.

The stream acquisition/storage section72acquires the stream supplied from the stream delivery section54of the stream source server21and stores the stream. In addition, the stream acquisition/storage section72encodes the stream on the basis of the metadata supplied from the metadata acquisition/storage section71and supplies a content delivered by the stream to the segment generation section73.

The segment generation section73generates a segment compliant with MPEG-DASH from the content supplied from the stream acquisition/storage section72, supplies the segment to the segment delivery section75, and requests the MPD generation section74to generate an MPD of the segment.

The MPD generation section74generates an original MPD for the segment generated by the segment generation section73on the basis of the metadata supplied from the metadata acquisition/storage section71(stores a URL of media data) and supplies the MPD to the streaming delivery manager31. In addition, the MPD generation section74receives the MPD to which the TranscodeDirective is added by the streaming delivery manager31and supplies the TranscodeDirective-added MPD to the MPD delivery section76.

The segment delivery section75delivers the segment supplied from the segment generation section73to the CDN23.

The MPD delivery section76delivers the MPD supplied from the MPD generation section74to the CDN23.

FIG. 16is a block diagram depicting an example of a configuration of the CDN server41configuring the CDN23. It is noted that the CDN origin server41aofFIG. 12, the CDN relay servers that are not depicted, and the CDN edge server41bare similar in configuration to the CDN server41.

As depicted inFIG. 16, the CDN server41is configured with an MPD acquisition section81, a segment acquisition section82, an MPD storage section83, a transcode control section84, a transcode processing section85, a segment storage section86, an MPD delivery section87, and a segment delivery section88.

The MPD acquisition section81acquires the TranscodeDirective-added MPD delivered from the MPD delivery section76of the DASH delivery server22and supplies the TranscodeDirective-added MPD to the segment acquisition section82and the MPD storage section83.

The segment acquisition section82acquires the segment delivered from the segment delivery section75of the DASH delivery server22and supplies the segment to the segment storage section86.

The MPD storage section83stores the TranscodeDirective-added MPD acquired by the MPD acquisition section81and the TranscodeDirective-added MPD updated by the transcode control section84.

The transcode control section84reads the TranscodeDirective-added MPD from the MPD storage section83, analyzes the TranscodeDirective-added MPD, and analyzes the TranscodeDirective. The transcode control section84then updates the MPD in accordance with an analysis result, returns the MPD to the TranscodeDirective-added MPD, and controls transcoding of the segment in the transcode processing section85on the basis of the updated MPD. In a case, for example, in which a TranscodeDirective element is stored in the MPD (refer toFIG. 24to be described later), the transcode control section84controls transcoding on the basis of the TranscodeDirective element. Alternatively, in a case in which a URL of a TranscodeDirective file is stored in the MPD (refer toFIG. 25to be described later), the transcode control section84controls transcoding on the basis of the TranscodeDirective element received in response to a request of the TranscodeDirective on the basis of the URL of the TranscodeDirective file.

The transcode processing section85reads the segment from the segment storage section86, transcodes the segment under control of the transcode control section84, and returns the transcoded segment to the segment storage section86.

The segment storage section86stores the segment acquired by the segment acquisition section82and the transcoded segment by the transcode processing section85.

The MPD delivery section87reads the TranscodeDirective-added MPD updated by the transcode control section84from the MPD storage section83and delivers the updated TranscodeDirective-added MPD to the DASH player14.

The segment delivery section88reads the transcoded segment from the segment storage section86and delivers the transcoded segment to the DASH player14.

FIG. 17is a block diagram depicting an example of a configuration of the DASH player14.

As depicted inFIG. 17, the DASH player14is configured with an MPD acquisition section91, a player control section92, an interaction processing section93, a segment acquisition section94, a segment processing section95, and a rendering processing section96.

The MPD acquisition section91acquires the MPD delivered from the MPD delivery section87of the CDN server41and supplies the MPD to the player control section92.

The player control section92controls the segment acquisition section94, the segment processing section95, and the rendering processing section96in accordance with the MPD supplied from the MPD acquisition section91(TranscodeDirective-added MPD updated by the CDN server41). At this time, the player control section92controls reproducing of the content in response to a user's interaction acquired by the interaction processing section93(for example, direction of a user's face in a case in which the DASH player14is a head mounted display).

The interaction processing section93performs processing on various kinds of information (for example, information indicating the direction in the case in which the DASH player14is a head mounted display) input to an input section that is not depicted, acquires the user's interaction with respect to the DASH player14, and supplies the user's interaction to the player control section92.

The segment acquisition section94acquires the segment delivered from the segment delivery section88of the CDN server41and supplies the segment necessary for the DASH player14to reproduce the content to the segment processing section95under control of the player control section92.

The segment processing section95performs processing on the segment supplied from the segment acquisition section94, reproduces the content, and supplies the content to the rendering processing section96under control of the player control section92.

The rendering processing section96performs rendering on the content supplied from the segment processing section95and outputs the resultant content to an output section that is not depicted to display the content under control of the player control section92.

Content delivery processing in the content delivery system11configured with the stream source server21, the streaming delivery manager31, the DASH delivery server22, the CDN server41, and the DASH player14described above will now be described in detail.

In the case, for example, of delivering a broadcast stream by the content delivery system11, programs, commercials, and the like are accumulated in the stream source server21. Furthermore, as depicted inFIG. 12, the stream delivered from the stream source server21arrives at the CDN edge server41bvia the multistage CDN relay servers from the CDN origin server41aamong a plurality of CDN servers41configuring each of the CDNs23provided by delivery service providers by way of the DASH delivery server22and is finally reproduced by each DASH player14.

At this time, in the DASH delivery server22, the MPD generation section74(FIG. 15) temporarily passes the generated original MPD to the streaming delivery manager31. In the streaming delivery manager31, the TranscodeDirective generation section61(FIG. 14) then modifies the MPD as appropriate on the basis of a delivery policy of the stream and returns the modified MPD to the MPD generation section74.

At this time, the TranscodeDirective generation section61modifies the MPD by adding TranscodeDirective elements describing, for example, control, conditions, and the like for the stream related to transcoding in the CDN23to AdaptationSet elements. A format for simply representing candidates and the like of a transformed profile permitted by a servicer or an author side is used therein. Furthermore, when contents to be constrained in decoding, rendering, or re-encoding processing performed by the CDN server41ofFIG. 16are present, the format needs to accurately represent those contents.

In other words, it is desired that the following declaration can be performed at the time of temporarily returning an encoded original stream to a baseband stream and re-encoding the baseband stream in the course of transcoding processing in the CDN server41.

First, cases of making various image corrections for upscaling are increasing, and it is desired to be capable of declaring whether or not such processing can be performed. Furthermore, secondly, it is desired to be capable of declaring whether or not to permit not only simple integer multiple transform of spatial resolution or temporal resolution but also various upscaling processing patterns (refer toFIGS. 35 to 38to be described later) as upscaling processing methods.

Moreover, thirdly, cases of performing viewport dependent scaling and encoding are considered to increase, and it is desired to be capable of declaring whether or not such partial transcoding processing can be performed. Furthermore, fourthly, it is desired to be capable of declaring a condition description in control as to whether or not to perform transcoding processing such as maximum delay time as an upper limit at the time of performing transcoding and an upper limit of a quality difference (for example, dissociation from original baseband data).

Furthermore, fifthly, it is necessary to provide a function to deliver a feedback report of such processing, if performed, to the author side, and it is desired to be capable of declaring contents such as a structure and a URL of a Notification message at that time. It is supposed, for example, herein to deliver a feedback report as to at what stage of the CDN edge servers41band the like near users what processing is performed within the CDN23or across a plurality of CDNs23.

The MPD modified by adding the TranscodeDirective element describing such contents and the DASH segment are passed to the CDNs23-1and23-2ofFIG. 12and transferred to the CDN edge servers41bvia the multistage CDN servers41. Upon acquiring the desired MPD, each DASH player14then fetches the segment on the CDN edge server41busing HTTP. It is noted that a segmenter sometimes delivers a segment in a protocol and format other than HTTP and the DASH segment to the CDN edge server41bwithin the CDN23. Furthermore, the CDN edge server41bsometimes acquires (PULL acquisition) a desired segment by HTTP from, for example, the upper-stage CDN server41.

In a case herein in which each DASH player14acquires the MPD by way of the CDN edge server41b, a segment encoding scheme is sometimes changed on the basis of a network state between the CDN edge server41band the DASH player14, a viewing liking of an end user of the individual DASH player14, and the like. Such transcoding is executed on the CDN edge server41bwithin each CDN23while a load is distributed in response to a loaded state as appropriate.

For example, in ordinary VoD (Video On Demand) streaming, before the CDN origin server41astarts delivery, streams at a plurality of bit rates of a certain content may be generated and a stream may be delivered in response to a user's request. Alternatively, to improve response performance, before a request from a client, streams may be delivered in advance (prefetched or push delivered) to the CDN edge server41b(or the CDN relay servers that serve as intermediate nodes on a delivery path).

In a case herein in which the CDN edge server41b(hereinafter, expression “CDN edge server41b” including the CDN relay servers as the intermediate nodes on the delivery path will be used) is capable of grasping (supposing) a tendency of the client's request in advance, the CDN edge server41bis capable of improving qualities of streaming (including image and audio qualities and response performance) in advance in consideration of a client's reproducing or viewing liking on the basis of the original stream. For example, the CDN edge server41bimproves the qualities of streaming on the basis of a reproducing capability of the DASH player14, a codec type, and the like predicted from past statistics of requests from a client group accessing the CDN edge server41b.

Furthermore, in a case in which the author provides ROI (Region Of Interest) metadata and the like and a region on an image likely to be requested in advance by a client (while it is also supposed that a plurality of ROIs is present on the same image) can be identified, the CDN edge server41bsometimes performs upscaling with a focus on those ROI regions and then re-encodes the stream. In such a case, a plurality of versions of a transcoded segment is prepared on the assumption that requests from clients scatter for, for example, first few segments (ROI regions differ among the clients). Furthermore, after the requests from the clients are settled into a stationary state, a cache area of the CDN edge server41bcan be greatly saved by transcoding subsequent segments (subsets out of a first variation, that is, mainly subsets out of the plurality of ROIs on the same image).

To control such flexible transcoding, the transcode manager43is mounted in the CDN edge server41b. The transcode manager43instructs the transcoder42mounted in the CDN edge server41bto perform transcoding of segments using the MPD passed to the DASH player14and knowledge regarding the request based on the MPD while grasping a network load status between the CDN23and the DASH player14and considering a load status of the CDN edge server41b.

Furthermore, the transcode manager43parses contents of the TranscodeDirective described in the MPD and instructs the transcoder42to transcode the segment concerned on the basis of various constraints or conditions associated with transcoding processing described in the TranscodeDirective. When the transcoder42performs the transcoding processing, the transcode manager43then transmits a report message to a report back URL described in the TranscodeDirective.

Furthermore, the transcode manager43updates the contents of the MPD and changes the MPD referring to the original segment to an MPD referring to a transcoded segment. In a case herein in which the update does not involve an update of the contents of the MPD such as partial change in segment in consideration of a viewport to be described later, that is, in a case in which an upscaling-caused parameter modification is closed to a file format level (for example, does not influence the MPD), the transcode manager43sometimes changes only contents of the segment with the MPD left to refer to the original segment. In this case, there is no need to urge each client to acquire the updated MPD.

The DASH player14acquires the MPD changed to refer to the transcoded segment in this way and acquires and reproduces the segment on the basis of the MPD.

With reference toFIG. 18, processing performed by the DASH delivery server22, the streaming delivery manager31, the CDN server41(mainly the transcoder42and the transcode manager43on the CDN edge server41b), and the DASH player14in content delivery processing performed in the content delivery system11ofFIG. 12will be described.

In Step S101, in the DASH delivery server22, the stream acquisition/storage section72receives and encodes a stream delivered from the stream source server21, and the segment generation section73generates a segment. The streaming delivery manager31then generates a TranscodeDirective-added MPD. At this time, in a case, for example, in which the contents of the TranscodeDirective are provided as metadata from upstream via the FLUS interface, the streaming delivery manager31inserts the contents of the TranscodeDirective depicted inFIG. 9described above into the MPD. Alternatively, the streaming delivery manager31may insert a URL of a TranscodeDirective file into the MPD as described above as an alternative to the TranscodeDirective.

In Step S102, the CDN server41requests MPD acquisition and segment acquisition to the DASH delivery server22.

Upon acquiring a request from the CDN server41in Step S102, the DASH delivery server22starts transferring the TranscodeDirective-added MPD and the segment in Step S103.

In Step S104, the transcode manager43measures a request processing status.

When the CDN server41receives the TranscodeDirective-added MPD and the segment transferred from the DASH delivery server22in Step S103, the transcode manager43parses the TranscodeDirective-added MPD in Step S105. The transcode manager43then analyzes the TranscodeDirective and instructs the transcoder42to perform transcoding in accordance with an analysis result.

The transcoder42decodes the segment in Step S106, performs upscaling in Step S107, and encodes the segment in Step S108in accordance with the transcoding instruction by the transcode manager43. In Step S109, the transcoder42then generates an MPD referring to the transcoded segment.

In Step S110, the DASH player14requests MPD acquisition to the CDN server41.

Upon receiving a request from the DASH player14in Step S110, the CDN server41transfers the MPD referring to the transcoded segment to the DASH player14in Step S111.

Upon acquiring the MPD referring to the transcoded segment and transferred in Step S111, the DASH player14parses the MPD in Step S112. The DASH player14then requests the CDN server41for the segment.

Upon acquiring a request from the DASH player14in Step S112, the CDN server41transfers the transcoded segment requested by the DASH player14in Step S113.

Upon receiving the transcoded segment transferred in Step S113, the DASH player14reproduces the received transcoded segment in Step S114.

Subsequently, until end of content delivery, transcoded segments are continuously transferred and reproduced.

As described so far, the streaming delivery manager31generates the TranscodeDirective-added MPD, so that the transcode manager43can parse the MPD, analyze the TranscodeDirective, and instruct transcoding.

While an example in which the CDN server41requests the DASH delivery server22to acquire the MPD and the segment is described herein, the DASH delivery server22may transfer the MPD and the segment to the CDN server41in a Push fashion. Alternatively, a flow may be started from bottom up in such a manner that the DASH player14requests the MPD first and the CDN server41transfers the MPD and the segment in accordance with the request.FIGS. 21 to 23to be described later depict examples of processing in the case, inclusive of such a pattern, of a dynamic update of the MPD, which possibly occurs at the time of live streaming.

FIG. 19depicts herein a correspondence relation in a case in which the contents of the TranscodeDirective are passed as the metadata (SDP) via the FLUS interface in Step S101ofFIG. 18. In other words, the correspondence relation depicted inFIG. 19is held between TranscodeDirective described in the SDP and TranscodeDirective inserted into the MPD. Likewise, the correspondence relation depicted inFIG. 19is held between a stream from the stream source server21and a stream on the cloud12in a subsequent stage of the DASH delivery server22.

FIG. 20is a block diagram depicting an example of a configuration of the content delivery system11B as a variation in which the streaming delivery manager31is provided on the cloud12.

As depicted inFIG. 20, the content delivery system11B is configured in such a manner that the streaming delivery manager31adding the contents of the TranscodeDirective to the MPD is disposed between the DASH delivery server22of the content providing apparatus13and the CDN23on the cloud12. In the content delivery system11B, therefore, the FLUS interface is used between the content providing apparatus13B and the streaming delivery manager31and CDN23. The content delivery system11B configured in this way has a pattern in which the TranscodeDirective is not described in the MPD and a pattern in which the TranscodeDirective is already described therein.

Content delivery processing in the content delivery system11B configured as depicted inFIG. 20will be described with reference toFIG. 21.

In Step S131, similarly to Step S101ofFIG. 18, the DASH delivery server22encodes a stream supplied from the stream source server21and generates a segment.

In Step S132, the CDN server41requests the DASH delivery server22to acquire the MPD and the segment.

Upon acquiring a request from the CDN server41in Step S132, the DASH delivery server22starts transferring the MPD and the segment to the streaming delivery manager31.

Upon receiving the MPD and the segment transferred in Step S133, the streaming delivery manager31inserts the TranscodeDirective into the MPD in Step S134. The streaming delivery manager31then starts transferring a TranscodeDirective-added MPD and the segment to the CDN server41.

Subsequently, the content is delivered by similar processing to that in Step S105and the subsequent steps ofFIG. 18.

In this way, with the configuration of providing the streaming delivery manager31on the cloud12, the DASH delivery server22delivers the TranscodeDirective-added MPD and the segment to the CDN server41via the streaming delivery manager31.

Content delivery processing for notifying a client of the MPD referring to the transcoded segment and causing the client to acquire the segment in the content delivery system11ofFIG. 12will be described with reference toFIG. 22.

In Step S151, similarly to Step S101ofFIG. 18, the DASH delivery server22encodes a stream supplied from the stream source server21and generates a segment. Furthermore, the MPD generation section74in the DASH delivery server22generates an original MPD.

In Step S152, the DASH delivery server22transfers the MPD and the segment generated in Step S151, and the CDN server41acquires the MPD and the segment.

In Step S153, the DASH player14requests MPD acquisition to the CDN server41.

Upon receiving a request from the DASH player14in Step S153, the CDN server41transfers the MPD acquired in Step S152to the DASH player14in Step S154.

Upon acquiring the MPD transferred in Step S154, the DASH player14parses the MPD in Step S155. The DASH player14then requests the segment to the CDN server41.

Upon acquiring a request from the DASH player14in Step S155, the CDN server41transfers the segment requested by the DASH player14in Step S156.

Upon receiving the segment transferred in Step S156, the DASH player14reproduces the received segment in Step S157.

In Step S158, the transcode manager43measures a request processing status.

In Step S159, the DASH delivery server22updates and transfers the MPD, that is, transfers a TranscodeDirective-added MPD by the streaming delivery manager31to the CDN server41.

When the CDN server41receives the TranscodeDirective-added MPD and the segment transferred from the DASH delivery server22in Step S159, the transcode manager43parses the TranscodeDirective-added MPD in Step S160. The transcode manager43then analyzes the TranscodeDirective and instructs the transcoder42to perform transcoding in accordance with an analysis result.

The transcoder42decodes the segment in Step S161, performs upscaling in Step S162, and encodes the segment in Step S163in accordance with the transcoding instruction by the transcode manager43. Furthermore, in Step S164, the transcoder42generates an MPD referring to the transcoded segment.

In Step S165, the CDN server41notifies the DASH player14of an update of the MPD.

In Step S166, the DASH player14requests MPD acquisition to the CDN server41in response to a notification from the CDN server41in Step S165.

Upon receiving a request from the DASH player14in Step S166, the CDN server41transfers the MPD referring to the transcoded segment to the DASH player14in Step S167.

Upon acquiring the MPD referring to the transcoded segment and transferred in Step S167, the DASH player14parses the MPD in Step S168. The DASH player14then requests the transcoded segment to the CDN server41as a next segment.

Upon acquiring a request from the DASH player14in Step S168, the CDN server41transfers the transcoded segment requested by the DASH player14in Step S169.

Upon receiving the transcoded segment transferred in Step S169, the DASH player14reproduces the received transcoded segment in Step S170.

Subsequently, until end of content delivery, transcoded segments are continuously transferred and reproduced.

As described so far, the CDN server41can notify the DASH player14of the update of the MPD, and the DASH player14can acquire the MPD referring to the transcoded segment in response to the notification and reproduce the transcoded segment.

Content delivery processing for applying a URL of an untranscoded segment to a URL of a transcoded segment and causing a client to acquire the segment in the content delivery system11ofFIG. 12will be described with reference toFIG. 23.

In Steps S201to S213, similar processing to that in Steps S151to S163ofFIG. 22is performed.

Furthermore, in Step S214, the DASH player14requests a next segment.

At this time, the URL of the untranscoded segment is applied to the URL of the transcoded segment, and the URL of the segment requested by the DASH player14in Step S214is replaced by the URL of the transcoded segment.

Therefore, in Step S215, the CDN server41transfers the transcoded segment in response to a request from the DASH player14.

Upon receiving the transcoded segment transferred in Step S215, the DASH player14reproduces the received transcoded segment in Step S216.

As described so far, applying the URL of the untranscoded segment to the URL of the transcoded segment enables the DASH player14to acquire the transcoded segment without, for example, transferring the MPD changed to refer to the transcoded segment to the DASH player14.

A structure of the TranscodeDirective that is the metadata used by the CDN server41(mainly the CDN edge server41b) in analysis or for-and-against determination will be described with reference toFIGS. 24 to 33.

In the case, for example, of using the DASH-MPD as a manifest of a streaming service, this metadata is added to an AdaptationSet element (or Representation element or SubRepresentation element) to be transcoded. It is noted that the transcode manager43can select optimum elements or values when a plurality of elements or values can be described.

FIG. 24depicts an example of disposing a TranscodeDirective element in the DASH-MPD. For example, the TranscodeDirective element is stored as an independent file, and the TranscodeDirective element can be disposed between <TranscodeDirective . . . > and </TranscodeDirective> in such a manner as to add the TranscodeDirective element to the AdaptationSet element.

Furthermore,FIG. 25depicts an example of a variation of disposing the TranscodeDirective element in the DASH-MPD. As depicted inFIG. 25, a URL of a TranscodeDirective file can be disposed in such a manner as to add the TranscodeDirective file to the AdaptationSet element.

Details of the TranscodeDirective element will be described hereinafter.

As depicted in (a) ofFIG. 26, a transcodable attribute designates true or false as to whether or not transcoding can be performed. For example, a case in which only the transcodable attribute is present in the TranscodeDirective element and the transcodable attribute designates true indicates that transcoding in an arbitrary pattern can be performed. Conversely, a case in which the transcodable attribute designates false indicates that transcoding processing is entirely prohibited.

Further, when the transcodable attribute indicates that transcoding can be performed, the following attributes can be present.

As depicted in (b) ofFIG. 26, an upScalable attribute designates true or false as to whether or not upscaling can be performed at the time of transcoding.

For example, a case in which only the upScalable attribute is present while the transcodable attribute designates true and in which the upScalable attribute designates true indicates that upscaling in an arbitrary pattern can be performed after re-encoding. Conversely, a case in which only the upScalable attribute is present and the upScalable attribute designates false indicates that upscaling is entirely prohibited before re-encoding.

As depicted in (c) ofFIG. 26, a processingLimit attribute designates maximum delay time that is an upper limit value of time required for transcoding processing.

As depicted in (d) ofFIG. 26, an Allowed element designates at least one of (or a plurality of) Parameters/Video or Parameters/Audio as a codec parameter that can be selected at the time of re-encoding. It is noted that designating, for example, “/Parameters/“other media type”” in the Allowed element enables extension to contain making the other media type selectable.

As depicted in (e) ofFIG. 26, a Prohibited element designates at least one of (or a plurality of) Parameters/Video or Parameters/Audio as a codec parameter that is prohibited from being selected at the time of re-encoding. It is noted that designating, for example, “/Parameters/“other media type”” in the Prohibited element enables extension to contain making selection of the other media type impossible.

As depicted in (f) ofFIG. 26, a Condition element designates a URI for identifying a format of a condition description (condition description language) in a schemeldUri attribute. For example, in the case of describing the condition description in ODRL, the Condition element designates urn:ODRL. Furthermore, the condition description is stored in a CDATA section (starting with a character string “<![CDATA[” and ending with a character string “]]>”) that is a content part of the Condition element.

For example, as depicted inFIG. 27, the condition description is stored in the CDATA section of the content part of the Condition element.

Furthermore,FIG. 28depicts an example of the condition description in ODRL. InFIG. 28, an example in which “a.com” that indicates a service owner allows the transcoding concerned to “cdn.com” until 2017/12/31 is described.

As depicted in (a) ofFIG. 29, a TranscodeEventNotification element designates an event notification to which various constraints, policies, and the like described in the TranscodeDirective concerned are applied.

As depicted in (b) ofFIG. 29, a dateTime attribute designates a clock time of occurrence of an event.

As depicted in (c) ofFIG. 29, an MPDUrl attribute designates the URL of the MPD concerned.

As depicted in (d) ofFIG. 29, an AdaptationSetld attribute designates an Id of the AdaptationSet to be transcoded.

As depicted in (e) ofFIG. 29, a notificationUrl attribute designates a URL of a notification destination.

In the case herein, for example, of applying transcoding to a stream (segment) to which the TranscodeDirective concerned is applied, the TranscodeDirective element including the dateTime attribute, the MPDUrl attribute, and the AdaptationSetld attribute described above is notified per se to the URL designated by the notificationUrl attribute by HTTP POST. Contents of actually applied transcoding processing are thereby reported. At this time, it is assumed that elements, attributes, or values are filled as appropriate in accordance with a pattern of the applied transcoding.

Specifically, in the case of upconverting an original video stream into a stream at a4K resolution and a120frame rate and then re-encoding an upconversion result, the TranscodeDirective element such as depicted inFIG. 30is notified to the URL designated by the notificationUrl attribute.

As depicted in (a) ofFIG. 31, a Parameters/Video element designates various attributes of a Video.

As depicted in (b) ofFIG. 31, a profile attribute designates a list of “profile names” demarcated by commas.

As depicted in (c) ofFIG. 31, a resolution attribute designates a list of “vertical×horizontal” pixel counts demarcated by commas. It is noted that as another example of expression of the resolution attribute, the resolution attribute may designate an upper limit or a lower limit of a vertical pixel count and an upper limit or a lower limit of a horizontal pixel count.

As depicted in (d) ofFIG. 31, a frameRate attribute designates a list of “frame rates (in fps)” demarcated by commas. It is noted that as another example of expression of the frameRate attribute, the frameRate attribute may designate an upper limit or a lower limit of frame rates.

As depicted in (e) ofFIG. 31, a bitDepth attribute designates a list of “bit counts (depths)” demarcated by commas. It is noted that as another example of expression of the bitDepth attribute, the bitDepth attribute may designate an upper limit or a lower limit of bit counts.

As depicted in (f) ofFIG. 31, a colorSpace attribute designates a list of “color space names” demarcated by commas.

As depicted in (g) ofFIG. 31, a gamma attribute designates a list of “gamma values” demarcated by commas.

As depicted in (h) ofFIG. 31, an upScalingPatternList attribute designates a list of “upscaling patterns” demarcated by commas.

As depicted in (a) ofFIG. 32, a partialTransformability attribute designates true or false as to whether or not rendering and transcoding involving partial upscaling can be performed.

As depicted in (b) ofFIG. 32, a deviationLimit element designates a difference format identifier and a value expressed by the scheme.

As depicted in (c) ofFIG. 32, a Parameters/Audio element designates various attributes of Audio and lists Audio attributes that are to be designated as true or false.

As depicted in (d) ofFIG. 32, a profileList attribute designates a list of “profile names” demarcated by commas.

As depicted in (e) ofFIG. 32, a samplingRate attribute designates a list of “sampling rates (in Hz)” demarcated by commas. It is noted that as another example of expression of the samplingRate attribute, the samplingRate attribute may designate an upper limit or a lower limit of sampling rates.

As depicted in (f) ofFIG. 32, a bitDepth attribute designates a list of “bit counts (depths)” demarcated by commas. It is noted that as another example of expression of the bitDepth attribute, the bitDepth attribute may designate an upper limit or a lower limit of bit counts.

As depicted in (g) ofFIG. 32, a deviationLimit element designates a difference format identifier and a value expressed by the scheme. As depicted in, for example,FIG. 33, a URI identifying a deviation expression scheme is designated in a schemeIdUri attribute of the deviationLimit element (for example, for PSNR, the URI is designated like urn:PSNR), and a value of the URI (35in the example ofFIG. 33) is stored in a value attribute.

FIG. 34depicts an example of a configuration of the TrasncodeDirective.

As depicted inFIG. 34, in the case of disposing the TranscodeDirective in a Video AdaptationSet, only Video elements are present under a Parameters element. In addition, in the case of disposing the TranscodeDirective in an Audio AdaptationSet, only Audio elements are present under a Parameters element.

Types of upscaling including partial image correction processing will be described with reference toFIGS. 35 to 38.

FIG. 35depicts an example of upscaling (FullHeight) for transforming an SDTV (4:3) into an HDTV (16:9) by adding a black tint to left and right sides of the SDTV. It is noted that upscaling (FullWidth) for transforming the SDTV into the HDTV may be performed by adding a black tint to, for example, top and bottom sides of the SDTV and an angle of view may be transformed, or that a tint other than the black tint may be added.

FIG. 36depicts an example of upscaling (FullWidth-TopBottomCrop-BlowUp) for transforming the SDTV (4:3) into the HDTV (16:9) by adjusting a horizontal width of the SDTV to match with the HDTV (16:9) and cropping the top and bottom sides of the SDTV. It is noted that upscaling (FullHeight-SideCrop-BlowUp) for transforming the SDTV into the HDTV may be performed by adjusting a vertical width of the SDTV to match with the HDTV and cropping left and right sides of the SDTV and the angle of view may be transformed.

FIG. 37depicts an example of upscaling (FullSize-Anamorphic) for transforming the SDTV (4:3) into the HDTV (16:9) by horizontally stretching the SDTV. It is noted that upscaling (FullSize-Anamorphic) for transforming the SDTV into the HDTV may be performed by vertically stretching the SDTV and the angle of view may be transformed.

FIG. 38depicts an example of upscaling (Artificial-FullSize-Anamorphic) for transforming the SDTV (4:3) into the HDTV (16:9) by complementing the left and right sides of the SDTV. At this time, the angle of view can be transformed by, for example, generating an image by analogy using an intelligent image processing technology or the like and complementing the image with an aspect ratio of an object in the image kept unchanged. In other words, as depicted inFIG. 38, an image is added in such a manner as to artificially complement (analogize, extrapolate, or imagine) the image to the left and right sides.

Content delivery processing for delivering a content using PartialTransformability will be described with reference toFIG. 39. For example, setting the partialTransformability attribute depicted in (a) ofFIG. 32described above to true or false makes it possible to optimize transcoding including partial upscaling of an original stream based on information regarding a user's viewport on a client device. In other words, it is possible to transcode the content on the basis of client's environment information (for example, viewport).

In Step S251, the DASH player14requests MPD acquisition to the CDN server41(mainly CDN edge server41b).

Upon receiving a request from the DASH player14in Step S251, the CDN server41transfers an MPD to the DASH player14in Step S252.

Upon acquiring the MPD transferred in Step S252, the DASH player14parses the MPD in Step S253. The DASH player14then requests a segment to the CDN server41.

Upon acquiring a request from the DASH player14in Step S253, the CDN server41transfers a transfer-request-added segment using, for example, DASH metrics or the like belonging to ImmersiveMedia currently under consideration by SAND or the like in Step S254.

In Step S255, the transcode manager43measures a request processing status.

Upon acquiring the SAND-transfer-request-added segment transferred in Step S254, the DASH player14notifies viewport metadata regarding a user of the DASH player14by SAND in Step S256. Furthermore, the DASH player14reproduces the acquired segment in Step S257.

Upon acquiring the viewport notification by SAND transmitted from the DASH player14in Step S256, the transcode manager43parses a TranscodeDirective-added MPD in Step S258. The transcode manager43then analyzes the TranscodeDirective and instructs the transcoder42to perform transcoding in accordance with an analysis result.

At this time, the transcode manager43identifies a stream corresponding to the viewport concerned or part of the stream on the basis of contents of the MPD (for example, version extended to be compliant with OMAF planned to be extended in the future) or an MP4 file (for example, MPF file using the OMAF). The transcoder42can perform upscaling constrained or allowed in the TranscodeDirective on entirety of the stream or part of the stream containing the viewport concerned and then transcoding processing thereon in accordance with this identification.

In other words, the transcoder42performs processing in accordance with the viewport at the time of decoding the segment in Step S259and performing upscaling in Step S260. The transcoder42then encodes the segment in Step S261.

In Step S262, the DASH player14requests a next segment.

Upon acquiring a request from the DASH player14in Step S262, the CDN server41transfers the transcoded segment requested by the DASH player14in Step S263.

Upon receiving the transcoded segment transferred in Step S263, the DASH player14reproduces the received transcoded segment in Step S264.

Subsequently, until end of content delivery, transcoded segments are continuously transferred and reproduced.

As described so far, the DASH player14transmits the viewport notification to the CDN server41, so that the CDN server41can identify the stream corresponding to the viewport and control transcoding in such a manner as to perform upscaling appropriately.

<Viewport Notification of Client Device>

The viewport notification of the DASH player14that is a client device serving as a stream reproducing side will be described with reference toFIGS. 40 and 41.

In a case, for example, in which a viewport on a playback device is identified by an X-axis, a Y-axis, an X-axis, and angles (pitch, yaw, and roll) about these axes as depicted inFIG. 40and a body is immovable, the angles are determined by a motion of a head. It is also set that the respective angles are increased clockwise in positive directions of the X-axis, the Y-axis, and the X-axis. It is further defined that an X-Z plane is in parallel to the ground and that all angles are zero when a person faces the positive direction of the Z-axis.

Furthermore, viewport coordinates are mapped from a coordinate system of this viewport metadata onto a coordinate system of a stream source.

Description will be given on the assumption, for example, that the coordinate system of the source uses a representation method with the use of azimuth angle/elevation angle and that the client side uses the coordinate system by representation of pitch, yaw, and roll. In this case, the viewport is mapped in such a manner that a direction in which the azimuth angle and the elevation angle (centerAzimuth/centerElevation) are both zero in the source coordinate system matches a direction in which the pitch, the yaw, and the roll of the DASH player14are all zero.

Moreover, viewport coordinate values on the transformed coordinate system are stored in a ViewportViews parameter of Immersive Media Metrics currently under consideration as depicted inFIG. 41to comply with a structure SphereRegionStruct specified in the OMAF, and a SANDMessage containing this Metrics is newly defined and used.

<Device Attribute Notification from Client Device>

FIG. 42depicts an example of device attributes notified from the DASH player14that is the client device serving as the stream reproducing side.

For example, capability attributes of the client device are stored in a VRDeviceInfo parameter of the Immersive Media Metrics currently under consideration as depicted inFIG. 42, and a SANDMessage containing this Metrics is newly defined and used.

An architecture of the FLU will be described with reference toFIGS. 43 and 44.

As depicted inFIG. 43, the FLUS source receives a media content from one or a plurality of capture devices. In addition, the FLUS sink decodes the media content and forwards the decoded media content to a rendering function. Alternatively, with a configuration such that the FLUS sink is implemented in a network, the media content is forwarded to a processing sub-function or a distribution sub-function.

Furthermore, the FLUS source is connected to the FLUS source by a reference point, and the FLUS source establishes and controls a single FLUS session and a plurality of media sessions.

A FLUS control plane function (F-C) controls media processing of the FLUS sink associated with uploading and subsequent downstream delivery. A FLUS user plane function (F-U) establishes a media session, performs IMS session setup in, for example, MTSI-based FLUS session establishment, and includes one or a plurality of media stream sessions.

Furthermore, the FLUS control plane function (F-C) is a function to establish and control a FLUS session. By the FLUS control plane function, the FLUS source executes opening of a media session or sessions, provisioning of static metadata regarding the media session or sessions, and selection and configuration of the processing/distribution sub-function.

Furthermore, media session opening is defined as part of the FLUS session. The FLUS user plane function (F-U) contains media session establishment procedures. It is supposed that a plurality of different media sessions is established in one FLUS session.

Moreover, the media session contains one or a plurality of media streams. The media stream contains a single media component (for example, audio only) in some cases, and contains a plurality of different media components (for example, audio and video) in other cases. The media session sometimes contains one or more identical media streams (for example, a plurality of video streams). Moreover, it is supposed that the FLUS sink opens a media session.

FIG. 44depicts an example of the media session and the media stream in the FLUS.

As depicted inFIG. 44, one or a plurality of media streams is transferred in the FLUS session, and the media stream is a time-dependent medium of the FLUS session. For example, when the media stream is active, the FLUS source transfers a media content to the FLUS sink.

Furthermore, the FLUS session includes zero or one or more media sessions each including one or more media streams. In the case of using HTTP in media streaming, the media session is not explicitly established.

<Additional Extension of ViewportViews Message of SAND>

FIG. 45depicts an example of additional extension of a ViewportViews message of SAND.

InFIG. 45, a ViewportViewsType surrounded by a chain double-dashed line is a newly defined part.

<Example of Configuration of Computer>

The series of processing described with reference to the flowcharts described above is not necessarily performed in time series in accordance with the orders described in the flowcharts, and also include processing executed either in parallel or individually (for example, parallel processing or processing by an object). Moreover, a program may be processed by one CPU or may be processed by a plurality of CPUs in a decentralized fashion.

Furthermore, the series of processing (content delivery control method) described above can be either executed by hardware or executed by software. In the case of executing the series of processing by the software, then a program configuring the software is installed in a computer incorporated into dedicated hardware or in, for example, a general-purpose personal computer or the like capable of executing various functions by installing various programs from a program recording medium recording therein the program or programs.

FIG. 46is a block diagram depicting an example of a configuration of the hardware of the computer executing the series of processing described above by the program.

In the computer, a CPU (Central Processing Unit)101, a ROM (Read Only Memory)102, and a RAM (Random Access Memory)103are mutually connected by a bus104.

An input/output interface105is further connected to the bus104. An input section106configured with a keyboard, a mouse, a microphone, and the like, an output section107configured with a display, a speaker, and the like, a storage section108configured with a hard disc, a nonvolatile memory, and the like, a communication section109configured with a network interface and the like, and a drive110that drives a removable medium111such as a magnetic disc, an optical disc, a magneto-optical disc, or a semiconductor memory are connected to the input/output interface105.

In the computer configured as described above, the CPU101loads a program stored in, for example, the storage section108to the RAM103via the input/output interface105and the bus104and executes the program, so that the series of processing described above is performed.

The program executed by the computer (CPU101) is recorded in, for example, the removable medium111that is a package medium configured with the magnetic disc (including a flexible disc), the optical disc (a CD-ROM (Compact Disc-Read Only Memory), a DVD (Digital Versatile Disc), or the like), the magneto-optical disc, or the semiconductor memory, or provided via a wired or wireless transmission medium such as a local area network, the Internet, or a digital satellite service.

Furthermore, the program can be installed in the storage section108via the input/output interface105by attaching the removable medium111to the drive110. Moreover, the program can be received by the communication section109via the wired or wireless transmission medium and installed in the storage section108. Additionally, the program can be installed in advance in the ROM102or the storage section108.

<Example of Combination of Configurations>

It is noted that the present technology can also be configured as follows.

A content delivery control apparatus including:

a generation section that generates a metadata file storing therein definition information necessary for transcoding a content, or first access information for accessing the definition information and second access information for accessing original data generated from the content;

a receiving section that receives the metadata file; and

a control section that exercises control associated with transcoding of the original data acquired on the basis of the second access information, in which

the control section controls the transcoding of the original data on the basis of the definition information in a case in which the definition information is stored in the metadata file, and

the control section requests the definition information on the basis of the first access information and controls the transcoding of the original data on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file.

The content delivery control apparatus according to (1), in which

the metadata file includes an MPD (Media Presentation Description) file standardized and defined by ISO IEC 23009.

The content delivery control apparatus according to (1) or (2), in which

the original data is an original segment that is compliant with MPEG-DASH (Dynamic Adaptive Streaming over HTTP).

The content delivery control apparatus according to (3), in which

the definition information and the access information are stored in an AdaptationSet of the MPD.

The content delivery control apparatus according to (3), in which

the definition information and the access information are stored in a Representation of the MPD.

The content delivery control apparatus according to (3), in which

the definition information and the access information are stored in a SubRepresentation of the MPD.

The content delivery control apparatus according to any one of (1) to (6), in which

the original data includes an original stream delivered using an SDP (Session Description Protocol).

The content delivery control apparatus according to (7), in which

the metadata file includes an SDP file standardized and defined by an IETF (Internet Engineering Task Force), and

the definition information and the access information are stored in a media description portion of the SDP.

The content delivery control apparatus according to any one of (1) to (8), in which

the definition information is stored as an independent file.

The content delivery control apparatus according to any one of (1) to (9), in which

the definition information specifies whether or not the content is transcodable.

The content delivery control apparatus according to any one of (1) to (10), in which

an upscaling scheme including partial image correction processing is defined in the definition information.

The content delivery control apparatus according to any one of (1) to (11), in which

a condition description based on a condition description language used to control whether or not transcoding can be performed is defined in the definition information.

The content delivery control apparatus according to any one of (1) to (12), in which

an information structure used to report contents of actually applied transcoding processing is defined in the definition information.

The content delivery control apparatus according to any one of (1) to (12), in which

the content is transcoded on the basis of environment information associated with a client that acquires and reproduces the content, the environment information being acquired from the client.

The content delivery control apparatus according to (14), in which

transcoding for performing upscaling to contain a viewport is controlled in response to a notification of the viewport from the client.

A content delivery control method including:

by a content delivery control apparatus includinga generation section that generates a metadata file storing therein definition information necessary for transcoding a content, or first access information for accessing the definition information and second access information for accessing original data generated from the content,a receiving section that receives the metadata file, anda control section that exercises control associated with transcoding of the original data acquired on the basis of the second access information,

causing the control section to control the transcoding of the original data on the basis of the definition information in a case in which the definition information is stored in the metadata file; and

causing the control section to request the definition information on the basis of the first access information and to control the transcoding of the original data on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file.

A program for causing a computer of a content delivery control apparatus,

the content delivery control apparatus includinga generation section that generates a metadata file storing therein definition information necessary for transcoding a content, or first access information for accessing the definition information and second access information for accessing original data generated from the content;a receiving section that receives the metadata file; anda control section that exercises control associated with transcoding of the original data acquired on the basis of the second access information,

to execute processing including:

causing the control section to control the transcoding of the original data on the basis of the definition information in a case in which the definition information is stored in the metadata file; and

causing the control section to request the definition information on the basis of the first access information and to control the transcoding of the original data on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file.

A content delivery system including:

a first server that has a storage section storing a content therein;

a second server that exercises content delivery control, the second server includinga generation section that generates a metadata file storing therein definition information necessary for transcoding the content, or first access information for accessing the definition information and second access information for accessing original data generated from the content,a receiving section that receives the metadata file, anda control section that exercises control associated with transcoding of the original data acquired on the basis of the second access information,the control section controlling the transcoding of the original data on the basis of the definition information in a case in which the definition information is stored in the metadata file,the control section requesting the definition information on the basis of the first access information and controlling the transcoding of the original data on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file; and

a client that acquires and reproduces the content delivered in accordance with the content delivery control.

Example of Combination of Configurations

It is noted that the present technology can also be configured as follows.

A content delivery control apparatus including:

a generation section that generates a metadata file storing therein definition information necessary for transcoding a content, or first access information for accessing the definition information and second access information for accessing an original segment that is original data generated from the content and that is compliant with MPEG-DASH (Dynamic Adaptive Streaming over HTTP);

a receiving section that receives the metadata file; and

a control section that exercises control associated with transcoding of the original segment acquired on the basis of the second access information, in which

the control section controls the transcoding of the original segment on the basis of the definition information in a case in which the definition information is stored in the metadata file, and

the control section requests the definition information on the basis of the first access information and controls the transcoding of the original segment on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file.

The content delivery control apparatus according to (1), in which

the metadata file includes an MPD (Media Presentation Description) file standardized and defined by ISO IEC 23009.

The content delivery control apparatus according to (2), in which

the definition information and the access information are stored in an AdaptationSet of the MPD.

The content delivery control apparatus according to (2) or (3), in which

the definition information and the access information are stored in a Representation of the MPD.

The content delivery control apparatus according to any one of (2) to (4), in which

the definition information and the access information are stored in a SubRepresentation of the MPD.

The content delivery control apparatus according to any one of (1) to (5), in which

the definition information is stored as an independent file.

The content delivery control apparatus according to any one of (1) to (6), in which

the definition information specifies whether or not the content is transcodable.

The content delivery control apparatus according to any one of (1) to (7), in which

an upscaling scheme including partial image correction processing is defined in the definition information.

The content delivery control apparatus according to any one of (1) to (8), in which

a condition description based on a condition description language used to control whether or not transcoding can be performed is defined in the definition information.

The content delivery control apparatus according to any one of (1) to (9), in which

an information structure used to report contents of actually applied transcoding processing is defined in the definition information.

The content delivery control apparatus according to any one of (1) to (10), in which

the content is transcoded on the basis of environment information associated with a client that acquires and reproduces the content, the environment information being acquired from the client.

The content delivery control apparatus according to (11), in which

transcoding for performing upscaling to contain a viewport is controlled in response to a notification of the viewport from the client.

A content delivery control method including:

by a content delivery control apparatus includinga generation section that generates a metadata file storing therein definition information necessary for transcoding a content, or first access information for accessing the definition information and second access information for accessing an original segment that is original data generated from the content and that is compliant with MPEG-DASH (Dynamic Adaptive Streaming over HTTP),a receiving section that receives the metadata file, anda control section that exercises control associated with transcoding of the original segment acquired on the basis of the second access information,

causing the control section to control the transcoding of the original segment on the basis of the definition information in a case in which the definition information is stored in the metadata file; and

causing the control section to request the definition information on the basis of the first access information and to control the transcoding of the original segment on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file.

A program for causing a computer of a content delivery control apparatus,

the content delivery control apparatus includinga generation section that generates a metadata file storing therein definition information necessary for transcoding a content, or first access information for accessing the definition information and second access information for accessing an original segment that is original data generated from the content and that is compliant with MPEG-DASH (Dynamic Adaptive Streaming over HTTP),a receiving section that receives the metadata file, anda control section that exercises control associated with transcoding of the original segment acquired on the basis of the second access information,

to execute processing including:

causing the control section to control the transcoding of the original segment on the basis of the definition information in a case in which the definition information is stored in the metadata file; and

causing the control section to request the definition information on the basis of the first access information and to control the transcoding of the original segment on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file.

A content delivery system including:

a first server that has a storage section storing a content therein;

a second server that exercises content delivery control, the second server includinga generation section that generates a metadata file storing therein definition information necessary for transcoding the content, or first access information for accessing the definition information and second access information for accessing an original segment that is original data generated from the content and that is compliant with MPEG-DASH (Dynamic Adaptive Streaming over HTTP),a receiving section that receives the metadata file, anda control section that exercises control associated with transcoding of the original segment acquired on the basis of the second access information,the control section controlling the transcoding of the original segment on the basis of the definition information in a case in which the definition information is stored in the metadata file,the control section requesting the definition information on the basis of the first access information and controlling the transcoding of the original segment on the basis of the definition information received by the receiving section in response to the request in a case in which the first access information is stored in the metadata file; and

a client that acquires and reproduces the content delivered in accordance with the content delivery control.

The embodiments of the present disclosure are not limited to the embodiments described above and various changes can be made without departing from the spirit of the present disclosure. Furthermore, the advantages described in the present specification are given as an example only, and the advantages are not limited to those described in the present specification and may contain other advantages.

REFERENCE SIGNS LIST