WO2014148277A1 - コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム - Google Patents

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

Info

Publication number
WO2014148277A1
WO2014148277A1 PCT/JP2014/055928 JP2014055928W WO2014148277A1 WO 2014148277 A1 WO2014148277 A1 WO 2014148277A1 JP 2014055928 W JP2014055928 W JP 2014055928W WO 2014148277 A1 WO2014148277 A1 WO 2014148277A1
Authority
WO
WIPO (PCT)
Prior art keywords
http
rtp
broadcast
multicast
segment file
Prior art date
Application number
PCT/JP2014/055928
Other languages
English (en)
French (fr)
Inventor
山岸　靖明
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to EP14767964.1A priority Critical patent/EP2978229B1/en
Priority to JP2015506701A priority patent/JP6457931B2/ja
Priority to BR112015022727A priority patent/BR112015022727A8/pt
Priority to US14/764,644 priority patent/US10165035B2/en
Priority to CN201480014550.7A priority patent/CN105052159B/zh
Publication of WO2014148277A1 publication Critical patent/WO2014148277A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26616—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for merging a unicast channel into a multicast channel, e.g. in a VOD application, when a client served by unicast channel catches up a multicast channel to save bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1827—Network arrangements for conference optimisation or adaptation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44016—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • the present disclosure relates to a content supply apparatus, a content supply method, a program, and a content supply system, and in particular, an RTP (Real-time RTP) as an alternative path when unicast transmitting content via HTTP via Hyper Text Transfer Protocol (HTTP).
  • RTP Real-time RTP
  • the present invention relates to a content supply device, a content supply method, a program, and a content supply system, capable of performing multicast transmission or broadcast transmission via a broadcast network according to Time Transport Protocol.
  • OTT-V Over The Top Video
  • HTTP in which the supply side and the reception side are connected by point-to-point as in browsing of Web sites etc.
  • MPEG-DASH Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP, hereinafter referred to as DASH
  • Adaptive streaming technology is realized in DASH. That is, the supply side of the content can prepare a plurality of streams having the same content but different in image quality and angle of view size, and the reception side is optimum according to the communication environment of the Internet and the capability and state of the reception side. The stream can be switched and viewed.
  • MPD Media Presentation Description
  • an address that is a supply source of chunked streaming data (media data such as Audio / Video / Subtitle) is described, and the receiving side uses a predetermined server based on the url information. It is possible to access and acquire streaming data to be transmitted by HTTP and reproduce it.
  • FIG. 1 shows an example of the configuration of a content supply system for streaming content based on DASH.
  • the content supply system 20 includes a content management server 21 for supplying content, a DASH segment streamer 22, a DASH MPD server 23, and a DASH client 30 for viewing content. Although not shown, it is assumed that a large number of DASH clients 30 exist.
  • the content management server 21 manages the content to be supplied to the receiving side, generates a plurality of streaming data with different bit rates from the content of the same content, and outputs it to the DASH segment streamer 22.
  • the DASH segment streamer 22 divides the streaming data of the content into segments in time, makes them into files and holds them, and notifies the DASH MPD server 23 of the address. Furthermore, the DASH segment streamer 22 transmits a segmented streaming data file to the DASH client 30 via the Internet 11 as an HTTP server in response to a request from the DASH client 30 on the receiving side.
  • the DASH MPD server 23 generates an MPD in which the address and the like of the supply source of the file of segmented streaming data are described. In addition, the DASH MPD server 23 transmits the MPD as an HTTP server to the DASH client 30 via the Internet 11 in response to a request from the DASH client 30 on the receiving side.
  • the DASH client 30 on the receiving side acquires and reproduces content, accesses the DASH segment streamer 22 based on the MPD acquired from the DASH MPD server 23, and acquires and reproduces a segmented streaming data file .
  • a cache server may be provided on the Internet 11 to cache HTTP transmitted MPD files and segmented streaming data files, etc., and substitute the operations of the DASH segment streamer 22 and the DASH MPD server 23 in some cases.
  • DASH implements an adaptive streaming technology that supplies content by unicast transmission over HTTP.
  • the content receiving side can handle multicast transmission and broadcast transmission, it is desirable to use them as alternative paths in DASH so that the stream can be selected adaptively on the receiving side.
  • the MPD of DASH can not describe the correspondence between the DASH segment unicast transmitted by HTTP and the content section streamed by RTP on the multicast bearer or broadcast bearer corresponding to the segment section. Therefore, it is difficult to realize seamless switching between unicast transmission and multicast transmission or broadcast transmission of content.
  • the present disclosure has been made in view of such a situation, and enables seamless switching between HTTP unicast transmission of content and RTP multicast transmission or broadcast transmission.
  • a content supply apparatus is a content supply apparatus for supplying streaming data of content according to MPEG-DASH, which files the streaming data for each segment, and obtains the resulting segment file by HTTP.
  • An HTTP transmission unit for cast transmission an RTP transmission unit for transmitting the segment file by at least one of multicast or broadcast by RTP, a segment file transmitted by unicast by HTTP, and transmission by multicast or broadcast by RTP
  • a metafile generation unit that generates a metafile describing a temporal correspondence relationship with the segment file to be processed and supplies the metafile to the receiving side.
  • the content supply device may further include an MPD generation unit that generates an MPD describing information for receiving the segment file unicasted by the HTTP, and the meta
  • the file generation unit can generate the metafile by rewriting the MPD.
  • the metafile generation unit associates rtspRange of the segment file transmitted by at least one of multicast and broadcast by RTP in association with the mediaRange attribute of the segment file unicast-transmitted by HTTP described in the MPD.
  • the metafile can be generated by adding an attribute.
  • the RTP transmission unit may perform protocol conversion to change the segment file unicasted by HTTP from the HTTP transmission unit to an RTP packet, and transmit the data by at least one of multicast and broadcast.
  • the RTP transmitter may further transmit an RTP time stamp and an NTP time stamp corresponding to the RTP time stamp by RTCP.
  • a content supply method is a content supply method of a content supply apparatus for supplying streaming data of content according to MPEG-DASH, wherein the streaming data is filed into segments by the content supply apparatus, HTTP transmission step of unicasting the resulting segment file by HTTP, RTP transmission step of transmitting the segment file by at least one of multicast and broadcast by RTP, and the segment file transmitted by unicast by HTTP Generate a metafile that describes the temporal correspondence with the segment file transmitted by multicast and / or broadcast by RTP, and generate the metafile to be supplied to the receiver And a step.
  • a program is an HTTP that files streaming data into segments by a computer that supplies streaming data of content according to MPEG-DASH, and unicasts the resulting segment files by HTTP.
  • a metafile describing the temporal correspondence with the file is generated, and it functions as a metafile generator supplied to the receiving side.
  • streaming data is filed for each segment, the resulting segment file is unicast transmitted by HTTP, and the segment file is transmitted by multicast or broadcast by RTP.
  • a metafile describing the correspondence in time between the segment file unicasted by HTTP and the segment file transmitted by at least one of multicast and broadcast by RTP is generated and supplied to the receiver Ru.
  • a content supply system is a content supply system comprising: a content supply apparatus that supplies streaming data of content according to MPEG-DASH; and a client apparatus that receives the stream data.
  • An HTTP transmission unit that files the streaming data into segments and unicasts the resulting segment file by HTTP, and an RTP transmission unit that transmits the segment file by at least one of multicast and broadcast by RTP;
  • a meta that describes the temporal correspondence between the segment file unicasted by HTTP and the segment file transmitted by multicast and / or broadcast by RTP It generates Airu, and a meta file generating unit supplies to the receiving side.
  • the client device switches between the segment file to be unicast transmitted by HTTP and the segment file transmitted by at least one of multicast or broadcast by RTP based on the acquired metafile, and receives and reproduces the segment file. Do.
  • streaming data is filed for each segment by the content supply device, and a segment file obtained as a result is unicast transmitted by HTTP, and the segment file is at least multicast or broadcast by RTP. It is sent by one side. Furthermore, a metafile describing the correspondence in time between the segment file unicasted by HTTP and the segment file transmitted by at least one of multicast and broadcast by RTP is generated and supplied to the receiver Ru. Also, the client apparatus switches and receives and reproduces the segment file unicasted by HTTP and the segment file transmitted by at least one of multicast and broadcast by RTP based on the acquired metafile. Ru.
  • a content supply system enables seamless switching of each content stream of unicast transmission by HTTP, multicast transmission by RTP, and broadcast transmission when acquiring and reproducing content. is there.
  • the MPD in DASH can be described so that the correspondence between the mediaRange indicating the section of the content stream unicast transmitted by HTTP and the rtspRange indicating the section of the content stream multicast or broadcast transmitted by RTP can be described. Expand.
  • FIG. 2 shows a configuration example of a content supply system according to an embodiment of the present disclosure.
  • the content supply system 50 includes a content supply apparatus 60 for supplying content and a plurality of DASH clients 70 for viewing content.
  • the content supply device 60 and the DASH client 70 are connected via the Internet 11.
  • the DASH client 70 can receive the content to be multicasted and broadcasted from the content supply device 60 via the broadcast network 12.
  • the broadcast network 12 includes a mobile broadcast network such as MBMS (Multimedia Broadcast and Multicast Service) as well as a television broadcast network using terrestrial waves and satellite waves.
  • MBMS Multimedia Broadcast and Multicast Service
  • the content supply device 60 includes a content management server 61, a DASH segment streamer 62, a DASH MPD server 63, an MPD proxy server 64, an MPD configurator 65, a broadcast / multicast (BC / MC) resource manager 66, a DASH client proxy 67, and a broadcast / A multicast (BC / MC) service provider 68 is mutually connected via the Internet 11 and configured.
  • a content management server 61 includes a content management server 61, a DASH segment streamer 62, a DASH MPD server 63, an MPD proxy server 64, an MPD configurator 65, a broadcast / multicast (BC / MC) resource manager 66, a DASH client proxy 67, and a broadcast / A multicast (BC / MC) service provider 68 is mutually connected via the Internet 11 and configured.
  • the content management server 61 manages content (including live broadcast content) to be supplied to the DASH client 70 on the receiving side, and generates a plurality of streaming data with different bit rates from the content of the same content to obtain a DASH segment
  • the streamer 62 is supplied.
  • the DASH segment streamer 62 divides streaming data of content in time.
  • FIG. 3 shows time division of content. That is, as shown in FIG. 3, the DASH segment streamer 62 temporally divides streaming data of content into periods, and further divides into segments, and files each to supply the file. The address indicating the source is notified to the DASH MPD server 63.
  • the DASH segment streamer 62 transmits a segmented streaming data file via HTTP as an HTTP server via the Internet 11 (unicast transmission using HTTP).
  • the DASH MPD server 63 generates an MPD to which the DASH client 70 refers for acquiring the content to be unicast transmitted by HTTP, and transmits the MPD via the Internet 11 in response to a request from the DASH client 70. . Also, the DASH MPD server 63 supplies the generated MPD in response to a request from the MPD proxy server 64.
  • the MPD proxy server 64 acquires the MPD from the DASH MPD server 63 and supplies it to the MPD configurator 65.
  • the MPD configurator 65 rewrites the MPD so that the DASH client 70 can obtain broadcasted and multicast transmitted content identical to the content to be unicasted by HTTP.
  • the broadcast / multicast resource manager 66 notifies the MPD configurator 65 of the status of broadcast bearer and multicast bearer resources.
  • the DASH client proxy 67 transmits the rewritten MPD to the DASH client 70, and also supplies it to the broadcast / multicast service provider 68 for multicast transmission by FLUTE. Also, the DASH client proxy 67 acquires a segment of content from the DASH segment streamer 62, converts the acquired segment into a multicast protocol or a broadcast protocol, supplies it to the broadcast / multicast service provider 68, and transmits it via the broadcast network 12 by RTP. Multicast and broadcast.
  • the broadcast / multicast service provider 68 multicasts the rewritten MPD through the broadcast network 12 by FLUTE. Also, the broadcast / multicast service provider 68 performs multicast transmission and broadcast transmission of stream segments of content via the broadcast network 12 by RTP.
  • FIG. 4 shows the data structure of the MPD.
  • FIG. 5 shows a hierarchical structure below Period in MPD.
  • information on content is divided into Periods, and each Period is provided with a plurality of Representations having the same content and information on streaming data having different stream attributes such as bit rates.
  • Representation stores information on Segment obtained by further subdividing Period into time.
  • FIG. 6 shows the state in which the MPD structure is arranged on the time axis.
  • the communication environment and the self decoding capability can be selected by the DASH client 70 adaptively selecting any of them.
  • the appropriate stream data can be switched and viewed according to the user's request.
  • FIG. 7 shows in detail the structure below the MPD Representation.
  • the address of the DASH segment streamer 62 which is the source of the file in which the segmented stream data is stored is described.
  • the sequence of the address (url information) of each file is described.
  • the range (mediaRange) of each segment in the file A sequence is described. The latter case is shown in FIG.
  • FIG. 8 shows an example in which the structure following Representation shown in FIG. 7 is described in XML format.
  • the DASH client 70 designates "http://example.com/counter-10mn_avc_dash.mp4" as the url of the file and issues an HTTP request specifying mediaRange in its Range header, the target segment You can get
  • MPD / Period / AdaptationSet / Representation / SegmentList / SegmentURL / @ mediaRange "795-83596" is the first segmented stream data in which the byte range from the 795th byte to the 83596th byte in the file is the first. It is shown that.
  • MPD / Period / AdaptationSet / Representation / SegmentList / SegmentURL / @ mediaRange "" 83597-166046 "is a stream in which the second byte range from byte 83597 to byte 166046 in the file is segmented. It indicates that it is data.
  • url "http://example.com/counter-10mn_avc_dash.mp4" of the file is specified in the HTTP request, and mediaRange "795-83596" is specified as the range specification. Should be described.
  • HTTP request may be issued.
  • GET /counter-10mn_avc_dash.mp4 HTTP / 1.1 Host: example.com Range: bytes 83597-166046
  • segmented stream data is supplied to the receiving DASH client 70 by unicast transmission by HTTP, multicast transmission by RTP, and broadcast transmission by RTP. Furthermore, these are seamlessly switched in the DASH client 70.
  • rtspRange representing the section of the stream segment to be multicast-transmitted and broadcast-transmitted by RTP is added corresponding to the byte range of the segment to be unicast-transmitted by HTTP.
  • FIG. 9 shows an example in which the MPD shown in FIG. 8 is rewritten.
  • the rtspRange attribute is disposed in the SegmentURL element as an attribute for specifying a section of a segment stream to be transmitted by multicast and broadcast by RTP as a switching target of a segment to be transmitted by HTTP.
  • the ServiceLocationAttributeUrl attribute in which the url of the ServiceLocationAttribute file storing the ServiceLocation element as the root element is described is placed in the Base URL of the MPD.
  • the rtspRange attribute of the SegmentURL element of the rewritten MPD identifies the RTP stream section defined in RTSP (Real Time Streaming Protocol) used for control of RTP streaming specified in RFC (Request For Comment) 2326
  • RTSP Real Time Streaming Protocol
  • RFC Request For Comment
  • a character string in the format (UTC format) of the range parameter to be stored is stored.
  • the format of the information stored in the rtspRange attribute is not limited to the UTC format.
  • the segment stream 19961108T143720 in the case of FIG. 9, in the first segment formed by the byte range 795th byte to the 83596th byte of the file unicast transmitted by HTTP, the segment stream 19961108T143720. It shows that the sections represented by 25Z to 19961108T143730.25Z correspond.
  • the segment stream 19961108T143730.25Z to 19961108T143740. Transmitted by multicast and broadcasted by RTP. It indicates that the section represented by 25Z corresponds.
  • FIG. 10 shows an example of the XML schema of the ServiceLocationAttribute file specified by the serviceLocationAttributeUrl attribute.
  • FIG. 11 shows the newly introduced ServiceLocation element.
  • the ServiceLocation element consists of a tuning parameter (DeliverySystemAttributes) and an IP multicast address (IPMulticastAddress). Then, the url of the ServiceLocationAttribute file storing the ServiceLocation element as a root element is described in the ServiceLocationAttributeUrl attribute disposed in the BaseURL.
  • a format identifier of a data structure of a tuning parameter employed in multicast transmission or broadcast transmission by MBMS etc. (in the case of MBMS) ID_MBMS) is described.
  • a format identifier of a data structure of a tuning parameter adopted in broadcast transmission of the DVB terrestrial network is described.
  • DeliverySystemDescriptor of DeliverySystemAttributes a data structure (parameter itself) of a tuning parameter specified in broadcast delivery or multicast delivery identified by DeliverySystemIdentifier is described. Note that, in practice, a byte string representing a parameter is converted to a character string by base 64 or the like and described in the Delivery System Descriptor.
  • FIG. 12 is an example of a data structure of User Service Description as a tuning parameter adopted for multicast transmission and broadcast transmission by MBMS.
  • BundleDescription (name space “urn: 3GPP: metadata: 2005: MBMS: userServiceDescription”) is an element for bundling a plurality of userServiceDescription (name space “urn: 3GPP: metadata: 2005: MBMS: userServiceDescription”).
  • userServiceDescription is an element storing information for acquiring (tuning / joining) a stream to be broadcasted or multicasted by MBMS, which is identified by the serviceId attribute.
  • the deliveryMethod (namespace “urn: 3GPP: metadata: 2005: MBMS: userServiceDescription”) is an element that specifies SDP (Session Description Protocol) in which the multicast address of the stream is described. Specifically, the URL of the SDP file is specified by the sessionDescriptionURI attribute.
  • Registration (namespace "urn: 3GPP: metadata: 2008: MBMS: userServiceDescription”) is a process (specified in the registrationURL attribute) required to acquire, for example, the protection key of the stream, which is necessary for registering in the multicast service. It is linked to an authentication session performed by activating a server-side script (when the multicast stream is encrypted and protected).
  • the DeliveryService Descriptor When the UserServiceDescription structure as described above is stored in the DeliveryService Descriptor, it is possible to obtain an MBMS broadcast stream or an MBMS multicast stream by performing usage registration according to the process defined in the definition of the MBMS service. .
  • RTP shall carry the content stream.
  • the protocol hierarchy in this case is configured as shown in A of FIG.
  • DVB_Triplet is an original network identifier ONid stored in the network information table NIT of DVB-SI, and three items of transport stream identifier TSid and service identifier Sid stored in the stream description table SDT of DVB-SI. Point to the information.
  • IP packet streams transferred on the broadcast stream by the DVB terrestrial network obtained by the DVBurl format stored in the ServiceLocation / DeliverySystem element an IP having a multicast address specified by the ServiceLocation / IPMulticastAddress element
  • the packet stream is assumed to carry the content stream by the RTP protocol.
  • the protocol hierarchy in this case is configured as shown in B of FIG.
  • FIG. 14 is a flowchart illustrating the first operation of the content supply system 50.
  • the DASH client 70 voluntarily requests the MPD configurator 65 to rewrite the MPD.
  • the DASH segment streamer 62 acquires, from the content management server 61, a plurality of streaming data having different bit rates of the same content, segmenting and holding each streaming data. It is assumed that the HTTP transmission has been started.
  • the DASH MPD server 63 has generated an MPD based on the file segment address notified of from the DASH segment streamer 62, and has started its HTTP transmission.
  • step S1 the DASH client 70 that is going to receive and reproduce content accesses the DASH MPD server 63 via the Internet 11 and requests HTTP transmission of the MPD. It is assumed that the DASH client 70 knows in advance the address of the DASH MPD server 63.
  • the DASH MPD server 63 transmits the HTTP of the MPD to the DASH client 70 via the Internet 11 in step S11.
  • the DASH client 70 having received the MPD accesses the DASH segment streamer 62 based on the MPD, and receives and reproduces a stream segment to be unicast transmitted by HTTP. Specifically, an HTTP request is issued based on the BaseURL and mediaRange of the MPD to request the DASH segment streamer 62 to transmit HTTP of the file of the DASH stream segment. In response to this request, the DASH segment streamer 62 transmits the corresponding file via HTTP to the DASH client 70 via the Internet 11, and the DASH client 70 receives and reproduces it.
  • the DASH client 70 monitors the bandwidth of the Internet 11 as step S 2, and unicast reception is likely to become unstable from now on, and the DASH client 70 itself has contents via the broadcast network 12.
  • the MPD configurator 65 transmits the acquired MPD to request rewriting of the MPD.
  • the MPD configurator 65 checks the broadcast / multicast resource manager 66 about the resource usage of the broadcast bearer and the multicast bearer. Furthermore, taking into consideration the cost of combining the broadcast bearer and the multicast bearer, the use thereof is determined, and resource reservation is requested to the broadcast / multicast resource manager 66. After receiving notification from the broadcast / multicast resource manager 66 that the resources have been secured, the MPD configurator 65 rewrites the MPD and sends it to the DASH client 70. Note that the transmitted, rewritten MPD is monitored by the DASH client proxy 67 before being received by the DASH client 70.
  • step S31 the DASH client proxy 67 that has monitored the rewritten MPD requests the broadcast / multicast provider 68 to perform periodic multicast transmission of the MPD by FLUTE of the broadcast network 12.
  • the broadcast / multicast provider 68 periodically multicasts the rewritten MPD by the FLUTE of the broadcast network 12 in step S41.
  • the rewritten MPD can be supplied even to the DASH client 70 which has not requested the rewriting of the MPD.
  • step S32 the DASH client proxy 67 requests a stream segment from the DASH segment streamer 62 instead of the DASH client 70 based on the monitored MPD.
  • the DASH segment streamer 62 unicasts the stream segment to the DASH client proxy 67 via the Internet 11 by HTTP in step S51.
  • step S33 the DASH client proxy 67 that has received the stream segment unicasted by HTTP performs protocol conversion to replace the stream segment stored in the HTTP packet with the payload of the RTP packet. Furthermore, it requests the broadcast / multicast provider 68 for multicast transmission and broadcast transmission via the broadcast network 12 by RTP of the stream segment after protocol conversion.
  • step S42 the broadcast / multicast provider 68 starts multicast transmission and broadcast transmission via the broadcast network 12 by RTP of the protocol-converted stream segment.
  • the DASH client 70 that has acquired the rewritten MPD then proceeds to step S3 or step S5.
  • step S4 reception and reproduction of a stream segment to be unicast transmitted via the Internet 11 by HTTP is to be continued, the process proceeds to step S4, and multicast transmission or broadcast transmission is performed via the broadcast network 12 by RTP.
  • the DASH client 70 When continuing reception and reproduction of the unicast transmitted stream segment, the DASH client 70 requests the stream segment from the DASH segment streamer 62 based on the MPD in step S3. Then, in step S4, the unicast transmission (processing of step S52) of the stream segment by the HTTP from the DASH segment streamer 62 according to the request via the Internet 11 (processing of step S52) is received and reproduced.
  • step S5 when switching to a stream segment multicast or broadcast transmitted via the broadcast network 12 by RTP, in step S5, the DASH client 70 is a segment stream unicast transmitted by HTTP based on the rewritten MPD. , Switch to receive and play back to a protocol-converted stream segment transmitted from multicast or broadcast.
  • the timing of this switching is based on the time interval information of rtspRange stored in Segment column corresponding to Representation corresponding to the multicast stream on the rewritten MPD, with the Segment column corresponding to Representation carried by unicast. It is determined based on the correspondence relationship.
  • the method of storing the stream segment in the protocol conversion described above in the payload of the RTP packet is determined for each content encoding method (AVC, AMR, etc.).
  • RTP time stamps and corresponding NTPs are used to determine the time base for synchronous reproduction between streams carried by a plurality of RTP packet streams using RTCP (RTP Control Protocol) simultaneously.
  • Time Protocol Time stamps are transferred.
  • the NTP timestamp is the number of seconds since 1 January 1900, 10:00, 0 seconds (unsigned fixed point with 32 bits of integer part and 32 bits of fraction part), but the UTC timestamp (format is an example: 2004-04-01T12: 00Z (20040401T1200Z). It can be easily converted to UTC representing the midday of April 1, 2004). Therefore, the position (time) on the absolute time (Wall Clock Time) of the RTP timestamp can be calculated from this. That is, the system clock (wall clock) of the content supplier and receiver is synchronized by the NTP timestamp, and on the time axis, based on the correspondence information between the NTP timestamp and the RTP timestamp carried by RTCP. RTP packets to be switched are identified.
  • FIG. 15 is a flowchart for explaining the second operation of the content supply system 50.
  • the MPD proxy server 64 is mainly responsible for requesting the MPD configurator 65 to rewrite the MPD.
  • the DASH segment streamer 62 acquires, from the content management server 61, a plurality of streaming data having different bit rates of the same content, segmenting and holding each streaming data. It is assumed that the HTTP transmission has been started.
  • the DASH MPD server 63 has generated an MPD based on the file segment address notified of from the DASH segment streamer 62, and has started its HTTP transmission.
  • step S71 the DASH client 70 that is going to receive and reproduce content requests the DASH MPD server 63 for HTTP transmission of the MPD via the Internet 11. This request is received by the MPD proxy server 64, and the MPD proxy server 64 requests the DASH MPD server 63 to transmit the MPD in step S81.
  • the DASH MPD server 63 transmits the MPD to the MPD proxy server 64 in step S91.
  • the MPD proxy server 64 that has received the MPD transmits the received MPD to the MPD configurator 65 to request rewriting of the MPD.
  • the MPD configurator 65 checks the broadcast / multicast resource manager 66 for resource utilization of the broadcast bearer and the multicast bearer. Furthermore, taking into consideration the cost of combining the broadcast bearer and the multicast bearer, the use thereof is determined, and resource reservation is requested to the broadcast / multicast resource manager 66. After receiving the notification from the broadcast / multicast resource manager 66 that the resources have been secured, the MPD configurator 65 rewrites the MPD and sends it to the MPD proxy server 64.
  • step S83 the MPD proxy server 64 sends the rewritten MPD to the DASH client 70. Note that the transmitted, rewritten MPD is monitored by the DASH client proxy 67 before being received by the DASH client 70.
  • step S111 the DASH client proxy 67 that has monitored the rewritten MPD requests the broadcast / multicast provider 68 to perform periodic multicast transmission of the MPD by FLUTE of the broadcast network 12.
  • the broadcast / multicast provider 68 periodically multicasts the rewritten MPD by the FLUTE of the broadcast network 12 in step S121.
  • the rewritten MPD can be supplied also to the DASH client 70 which has not requested the transmission of the MPD.
  • step S113 the DASH client proxy 67 requests the stream segment from the DASH segment streamer 62 instead of the DASH client 70 based on the monitored MPD.
  • the DASH segment streamer 62 unicasts the stream segment to the DASH client proxy 67 via the Internet 11 by HTTP in step S131.
  • step S113 the DASH client proxy 67 that has received the stream segment unicasted by HTTP performs protocol conversion to transfer the stream segment stored in the HTTP packet to the payload of the RTP packet. Furthermore, it requests the broadcast / multicast provider 68 for multicast transmission and broadcast transmission via the broadcast network 12 by RTP of the stream segment after protocol conversion.
  • step S122 the broadcast / multicast provider 68 starts multicast transmission and broadcast transmission via the broadcast network 12 by RTP of the protocol-converted stream segment.
  • step S 72 whether the DASH client 70 receives a unicast transmission via the Internet 11 or a multicast transmission or broadcast transmission via the broadcast network 12 based on the band state of the Internet 11, its own reception function, etc. choose
  • step S73 the DASH client 70 requests a stream segment from the DASH segment streamer 62 based on the MPD.
  • step S74 the unicast transmission (processing of step S132) of the stream segment by the HTTP from the DASH segment streamer 62 according to the request via the Internet 11 (processing of step S132) is received and reproduced.
  • step S75 the DASH client 70 receives and reproduces the protocol-converted stream segment multicast-transmitted or broadcast-transmitted by RTP based on the rewritten MPD.
  • a stream segment that is unicast transmitted via the Internet 11 by HTTP and multicast transmission or broadcast transmitted via the broadcast network 12 by RTP Switching can be performed seamlessly with other stream segments. Therefore, the user of the DASH client 70 can adaptively select and view streams having the same content but different paths.
  • the content supply device 60 that executes the series of processes described above and the DASH client 70 can be realized by a computer executing software in addition to hardware configuration.
  • the computer includes, for example, a general-purpose personal computer capable of executing various functions by installing a computer incorporated in dedicated hardware and various programs.
  • FIG. 16 is a block diagram showing an example of the hardware configuration of the computer described above.
  • a central processing unit (CPU) 101 a read only memory (ROM) 102, and a random access memory (RAM) 103 are mutually connected by a bus 104.
  • CPU central processing unit
  • ROM read only memory
  • RAM random access memory
  • an input / output interface 105 is connected to the bus 104.
  • An input unit 106, an output unit 107, a storage unit 108, a communication unit 109, and a drive 110 are connected to the input / output interface 105.
  • the input unit 106 includes a keyboard, a mouse, a microphone and the like.
  • the output unit 107 includes a display, a speaker, and the like.
  • the storage unit 108 includes a hard disk, a non-volatile memory, and the like.
  • the communication unit 109 includes a network interface and the like.
  • the drive 110 drives removable media 111 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.
  • the CPU 101 loads the program stored in the storage unit 108 to the RAM 103 via the input / output interface 105 and the bus 104 and executes the program, for example. A series of processing is performed.
  • the program executed by the computer 100 can be provided by being recorded on, for example, a removable medium 111 as a package medium or the like. Also, the program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.
  • the program can be installed in the storage unit 108 via the input / output interface 105 by attaching the removable media 111 to the drive 110.
  • the program can be received by the communication unit 109 via a wired or wireless transmission medium and installed in the storage unit 108.
  • the program can be installed in advance in the ROM 102 or the storage unit 108.
  • the program executed by the computer 100 may be a program that performs processing in chronological order according to the order described in this specification, or in parallel, or when necessary, such as when a call is made.
  • the program may be a program to be processed in

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

　本開示は、ユニキャスト送信、マルチキャスト送信またはブロードキャスト送信の受信、再生をシームレスにスイッチングできるようにするコンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関する。　本開示のコンテンツ供給装置は、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをユニキャスト送信するHTTP送信部と、前記セグメントファイルをマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、ユニキャスト送信される前記セグメントファイルと、マルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部とを備える。本開示は、コンテンツをストリーミング配信するシステムに適用できる。

Description

コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
　本開示は、コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関し、特に、コンテンツをHTTP(Hyper Text Transfer Protocol)によりインターネットを介してユニキャスト送信する場合の代替パスとして、RTP(Real-time Transport Protocol)により放送網を介してマルチキャスト送信またはブロードキャスト送信できるようにしたコンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関する。
　近年、インターネットを介するストリーミングサービスの主流がOTT-V(Over The Top Video)となっており、その基盤技術として、Webサイトなどの閲覧と同様に供給側と受信側がpoint to pointで接続されるHTTPを用いるMPEG-DASH（Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP、以下、DASHと称する）が知られている（例えば、非特許文献１を参照）。
　DASHでは適応型ストリーミング技術が実現されている。すなわち、コンテンツの供給側は、同一内容のコンテンツであって画質や画角サイズが異なる複数のストリームを準備可能であり、受信側はインターネットの通信環境や受信側の能力や状態に応じて最適なストリームをスイッチングして視聴することができるようにされている。
　DASHにおいては、受信側がストリームを適応的にスイッチングするための情報として、供給側から受信側にMPD(Media Presentation Description)と称されるメタファイルが供給される。MPDには、チャンク化されたストリーミングデータ(Audio/Video/Subtitle等のメディアデータ)の供給元となるアドレス(url情報)が記述されており、受信側は該url情報に基づいて所定のサーバにアクセスし、HTTP送信されるストリーミングデータを取得、再生することができる。
　図１は、DASHに基づいてコンテンツをストリーミング配信するコンテンツ供給システムの構成の一例を示している。
　該コンテンツ供給システム２０は、コンテンツを供給する側のコンテンツマネジメントサーバ２１、DASHセグメントストリーマ２２、およびDASH MPDサーバ２３、並びにコンテンツを視聴する側のDASHクライアント３０から構成される。なお、図示は省略するが、DASHクライアント３０は多数存在するものとする。
　コンテンツマネジメントサーバ２１は、受信側に供給するコンテンツを管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ２２に出力する。
　DASHセグメントストリーマ２２は、コンテンツのストリーミングデータを時間的にセグメントに分割してそれぞれをファイル化して保持し、そのアドレスをDASH MPDサーバ２３に通知する。さらに、DASHセグメントストリーマ２２は、受信側のDASHクライアント３０からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルを、インターネット１１を介してDASHクライアント３０に送信する。
　DASH MPDサーバ２３は、セグメント化されたストリーミングデータのファイルの供給元のアドレスなどを記述したMPDを生成する。また、DASH MPDサーバ２３は、受信側のDASHクライアント３０からの要求に応じ、HTTPサーバとして該MPDをインターネット１１を介してDASHクライアント３０に送信する。
　受信側のDASHクライアント３０は、コンテンツを取得、再生するものであり、DASH MPDサーバ２３から取得するMPDに基づいてDASHセグメントストリーマ２２にアクセスし、セグメント化されたストリーミングデータのファイルを取得、再生する。
　なお、インターネット１１上にキャッシュサーバを設け、HTTP送信されるMPDやセグメント化されたストリーミングデータのファイルなどキャッシングし、DASHセグメントストリーマ２２やDASH MPDサーバ２３の動作を代行させることもある。
「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEI ELECTRONICS 2012.3.19
　上述したように、DASHではHTTPによるユニキャスト送信によりコンテンツを供給する適応的ストリーミング技術が実現されている。
　ただし、数多くのDASHクライアント３０が同時に取得、再生する可能性がある、リアルタイムのスポーツ中継等のコンテンツをDASHにより供給する場合、HTTPを用いているために、CDN(Contents Delivery Network)のサポートが必要となる。しかしながら、CDNのサポートを受けるとしても、そのコスト的な制約から既存の放送配信に匹敵する程のスケーラビリティを求めることはできない。
　ところで、コンテンツを同時に多数の受信側に供給するには、テレビジョン放送網やモバイルネットワークを介したマルチキャストベアラやブロードキャストベアラを利用する方法があり、これには一般的にRTPが用いられる。
　よって、コンテンツの受信側がマルチキャスト送信やブロードキャスト送信に対応可能であれば、DASHにおける代替パスとしてそれらを用い、受信側で適応的にストリームを選択できるようにすることが望ましい。
　しかしながら、現状のDASHの仕様においては、コンテンツのストリーミングデータをHTTP送信することのみを想定しており、マルチキャストベアラやブロードキャストベアラの利用は想定していない。したがって、DASHのMPDには、HTTPによりユニキャスト送信されるDASHセグメントと、そのセグメント区間に対応するマルチキャストベアラまたはブロードキャストベアラ上のRTPによってストリーミングされるコンテンツ区間との対応関係を記述することができない。よって、コンテンツのユニキャスト送信とマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングの実現が困難である。
　本開示はこのような状況に鑑みてなされたものであり、コンテンツのHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングを実現できるようにするものである。
　本開示の第１の側面であるコンテンツ供給装置は、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置において、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部とを備える。
　本開示の第１の側面であるコンテンツ供給装置は、前記HTTPによりユニキャスト送信される前記セグメントファイルを受信するための情報を記述したMPDを生成するMPD生成部をさらに備えることができ、前記メタファイル生成部は、前記MPDを書き換えることにより前記メタファイルを生成することができる。
　前記メタファイル生成部は、前記MPDに記述されている、HTTPによりユニキャスト送信される前記セグメントファイルのmediaRange属性に対応付けて、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルのrtspRange属性を追記することにより前記メタファイルを生成することができる。
　前記RTP送信部は、前記HTTP送信部からHTTPによりユニキャスト送信された前記セグメントファイルをRTPパケットに乗せ変えるプロトコル変換を施して、マルチキャストまたはブロードキャストの少なくとも一方で送信することができる。
　前記RTP送信部は、さらに、RTCPによりRTPタイムスタンプと前記RTPタイムスタンプに対応するNTPタイムスタンプを送信することができる。
　本開示の第１の側面であるコンテンツ供給方法は、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、前記コンテンツ供給装置による、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信ステップと、前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信ステップと、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成ステップとを含む。
　本開示の第１の側面であるプログラムは、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンピュータを、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部として機能させる。
　本開示の第１の側面においては、ストリーミングデータがセグメント毎にファイル化され、その結果得られるセグメントファイルがHTTPによりユニキャスト送信され、前記セグメントファイルがRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される。さらに、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルが生成されて受信側に供給される。
　本開示の第２の側面であるコンテンツ供給システムは、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信するクライアント装置とから成るコンテンツ供給システムにおいて、前記コンテンツ供給装置が、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部とを備える。また、前記クライアント装置が、取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとを切り替えて受信、再生する。
　本開示の第２の側面においては、コンテンツ供給装置により、ストリーミングデータがセグメント毎にファイル化され、その結果得られるセグメントファイルがHTTPによりユニキャスト送信され、前記セグメントファイルがRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される。さらに、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルが生成されて受信側に供給される。また、クライアント装置により、取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとが切り替えて受信、再生される。
　本開示の第１および第２の側面によれば、コンテンツのHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングを実現できる。
DASHを利用する従来のコンテンツ供給システムの構成の一例を示すブロック図である。 本開示を適用したコンテンツ供給システムの構成例を示すブロック図である。 コンテンツの時間的区切りを説明する図である。 MPDの構成を示す図である。 MPDにおけるPeriod以下の階層構造を示す図である。 時間軸上にMPDの構成を並べた図である。 MPDのRepresentation以下の詳細な構造を示す図である。 MPDの一例を示す図である。 書き換えられたMPDの一例を示す図である。 ServiceLocation要素のXML Schemaの一例を示す図である。 ServiceLocation要素のデータ構造を示す図である。 User Searvice Descriptionの一例を示す図である。 プロトコルの階層構造を示す図である。 コンテンツ供給システムの第１の動作を説明するフローチャートである。 コンテンツ供給システムの第２の動作を説明するフローチャートである。 コンピュータの構成例を示すブロック図である。
　以下、本開示を実施するための最良の形態（以下、実施の形態と称する）について、図面を参照しながら詳細に説明する。
［コンテンツ供給システムの構成例］
　本開示の実施の形態であるコンテンツ供給システムは、受信側がコンテンツを取得、再生するに際して、HTTPによるユニキャスト送信、RTPによるマルチキャスト送信およびブロードキャスト送信の各コンテンツストリームをシームレスにスイッチングできるようにするものである。
　具体的には、HTTPによりユニキャスト送信されるコンテンツストリームの区間を示すmediaRangeと、RTPによりマルチキャスト送信またはブロードキャスト送信されるコンテンツストリームの区間を示すrtspRangeとの対応関係を記述できるようにDASHにおけるMPDを拡張する。
　図２は、本開示の実施の形態であるコンテンツ供給システムの構成例を示している。
　該コンテンツ供給システム５０は、コンテンツを供給する側のコンテンツ供給装置６０と、コンテンツを視聴する側の多数のDASHクライアント７０から構成される。コンテンツ供給装置６０とDASHクライアント７０とはインターネット１１を介して接続される。DASHクライアント７０は、コンテンツ供給装置６０から放送網１２を介してマルチキャスト送信およびブロードキャスト送信されるコンテンツを受信できる。放送網１２には、地上波や衛星波などを用いるテレビジョン放送網などの他、MBMS(Multimedia Broadcast and Multicast Service)などのモバイルネットワークも含まれるものとする。
　コンテンツ供給装置６０は、コンテンツマネジメントサーバ６１、DASHセグメントストリーマ６２、DASH MPDサーバ６３、MPDプロキシサーバ６４、MPDコンフィギュレータ６５、ブロードキャスト／マルチキャスト(BC/MC)リソースマネージャ６６、DASHクライアントプロキシ６７、およびブロードキャスト／マルチキャスト(BC/MC)サービスプロバイダ６８がインターネット１１を介して相互に接続されて構成される。
　コンテンツマネジメントサーバ６１は、受信側のDASHクライアント７０に供給するためのコンテンツ（ライブ放送コンテンツを含む）を管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ６２に供給する。
　DASHセグメントストリーマ６２は、コンテンツのストリーミングデータを時間的に分割する。
　図３は、コンテンツの時間的な区切りを示している。すなわち、DASHセグメントストリーマ６２は、図３に示されるように、コンテンツのストリーミングデータを時間的にピリオド(period)に区切り、さらにセグメント(segment)に分割して、それぞれをファイル化し、該ファイルの供給元を示すアドレスをDASH MPDサーバ６３に通知する。
　また、DASHセグメントストリーマ６２は、DASHクライアント７０からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルを、インターネット１１を介してHTTP送信する（HTTPを用いてユニキャスト送信する）。
　DASH MPDサーバ６３は、HTTPによりユニキャスト送信されるコンテンツをDASHクライアント７０が取得するための参照するMPDを生成し、該MPDをDASHクライアント７０からの要求に応じ、インターネット１１を介してHTTP送信する。また、DASH MPDサーバ６３は、MPDプロキシサーバ６４からの要求に応じ、生成したMPDを供給する。
　MPDプロキシサーバ６４は、DASH MPDサーバ６３からMPDを取得してMPDコンフィギュレータ６５に供給する。
　MPDコンフィギュレータ６５は、HTTPによりユニキャスト送信されるコンテンツと同一内容のブロードキャスト送信およびマルチキャスト送信されるコンテンツをDASHクライアント７０が取得できるようにMPDを書き換える。ブロードキャスト／マルチキャストリソースマネージャ６６は、ブロードキャストベアラおよびマルチキャストベアラのリソースの状況をMPDコンフィギュレータ６５に通知する。
　DASHクライアントプロキシ６７は、書き換えられたMPDをDASHクライアント７０に送信するとともに、ブロードキャスト／マルチキャストサービスプロバイダ６８に供給してFLUTEによりマルチキャスト送信させる。また、DASHクライアントプロキシ６７は、DASHセグメントストリーマ６２からコンテンツのセグメントを取得し、取得したセグメントをマルチキャストプロトコルまたはブロードキャストプロトコルに変換してブロードキャスト／マルチキャストサービスプロバイダ６８に供給し、RTPにより放送網１２を介してマルチキャスト送信およびブロードキャスト送信させる。
　ブロードキャスト／マルチキャストサービスプロバイダ６８は、書き換えられたMPDを、FLUTEにより放送網１２を介してマルチキャスト送信する。また、ブロードキャスト／マルチキャストサービスプロバイダ６８は、コンテンツのストリームセグメントをRTPにより放送網１２を介してマルチキャスト送信およびブロードキャスト送信する。
［MPDの概要］
　次に、DASHにおけるMPDの概要について図４および図５を参照して説明する。
　図４はMPDのデータ構成を示している。図５はMPDにおけるPeriod以下の階層構造を示している。
　MPDには、コンテンツ（Media)に関する情報がPeriod毎に区分され、各Periodには同一内容であってビットレートなどのストリーム属性の異なるストリーミングデータに関する情報からなる複数のRepresentationが用意されている。Representationには、Periodをさらに時間的に細分化したSegmentに関する情報が格納されている。
　図６は、時間軸上にMPDの構造を並べた状態を示している。
　同図から明らかなように、同一のSegmentに対して複数のRepresentationが存在しているので、これらのうちのいずれかをDASHクライアント７０が適応的に選択することにより、通信環境や自己のデコード能力などに応じて適切なストリームデータをスイッチングして視聴することができる。
　図７は、MPDのRepresentation以下の構造を詳細に示している。Representationには、セグメント化されたストリームデータが格納されたファイルの供給元となるDASHセグメントストリーマ６２のアドレスが記述される。具体的には、セグメント化された複数のストリームデータがそれぞれ個別にファイル化されている場合には、各ファイルのアドレス（url情報）のシーケンスが記述される。また、セグメント化された複数のストリームデータがまとめて１個のファイルにファイル化されている場合には、該ファイルのアドレス（Base URL）に加えて、該ファイルにおける各セグメントの範囲(mediaRange)のシーケンスが記述される。なお、図７には、後者の場合が示されている。
　図８は、図７に示されたRepresentation以下の構造をXML形式で記述した一例を示している。
　MPD/Period/AdaptationSet/Representation/BaseURLには、セグメント化されたストリームデータが１個のファイルにファイル化されている場合の該ファイルの供給元のアドレスが記述される。同図の場合、”http://example.com/counter-10mn_avc_dash.mp4”がファイルのアドレスを示している。
　MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeには、該ファイルにおける、セグメント化されたストリームデータのバイト範囲のシーケンスが記述される。
　したがって、DASHクライアント７０が、ファイルのurlとして”http://example.com/counter-10mn_avc_dash.mp4”を指定するとともに、そのRangeヘッダにmediaRangeを指定してHTTPリクエストを発行すれば、目的のセグメントを取得することができる。
　例えば、MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange=”795-83596”は、該ファイルにおけるバイト範囲795バイト目から83596バイト目までが１つ目のセグメント化されたストリームデータであることを示している。同様に、次のMPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange=”83597-166046”は、該ファイルにおけるバイト範囲83597バイト目から166046バイト目までが２つ目のセグメント化されたストリームデータであることを示している。
　したがって、１つ目のセグメントを取得するためには、HTTPリクエストにおいて、ファイルのurl”http://example.com/counter-10mn_avc_dash.mp4”を指定するとともに、レンジ指定としてmediaRange”795-83596”を記述すればよい。この際のHTTPリクエストは以下のとおりとなる。
　GET /counter-10mn_avc_dash.mp4 HTTP/1.1
　Host: example.com
　Range: bytes=795-83596
　同様に、２つ目のセグメントを取得するためには、以下のHTTPリクエストを発行すればよい。
　GET /counter-10mn_avc_dash.mp4 HTTP/1.1
　Host: example.com
　Range: bytes=83597-166046
［MPDの書換え］
　本実施の形態においては、セグメント化されたストリームデータがHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信と、RTPによるブロードキャスト送信とにより受信側のDASHクライアント７０に供給される。さらに、DASHクライアント７０にてこれらがシームレスにスイッチングされる。
　これを実現するために、ServiceLocation要素を新たに導入する。また、HTTPによりユニキャスト送信されるセグメントのバイト範囲に対応する、RTPによりマルチキャスト送信およびブロードキャスト送信されるストリームセグメントの区間を表すrtspRangeを追記する。
　図９は、図８に示されたMPDを書き換えた例を示している。具体的には、SegmentURL要素に、HTTP送信されるセグメントのスイッチング対象としての、RTPによるマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの区間を特定する属性としてrtspRange属性が配置される。さらに、ServiceLocation要素をルート要素として格納するServiceLocationAttributeファイルのurlが記述されるServiceLocationAttributeUrl属性がMPDのBaseURLに配置される。
　書き換えられたMPDのSegmentURL要素のrtspRange属性には、RFC(Request For Comment)2326にて規定されるRTPストリーミングの制御に利用されるRTSP（Real Time Streaming Protocol）において定義されているRTPストリーム区間を識別するrangeパラメタのフォーマット（UTCフォーマット）の文字列が格納される。なお、rtspRange属性に格納する情報のフォーマットはUTCフォーマットに限定されるものではない。
　例えば、図９の場合、HTTPによりユニキャスト送信されるファイルのバイト範囲795バイト目から83596バイト目までが成す１つ目のセグメントには、RTPによりマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの19961108T143720.25Zから19961108T143730.25Zの表す区間が対応することを示している。
　同様に、HTTPによりユニキャスト送信されるファイルのバイト範囲83597バイト目から166046バイト目までが成す２つ目のセグメントには、RTPによりマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの19961108T143730.25Zから19961108T143740.25Zの表す区間が対応することを示している。
　図１０は、serviceLocationAttributeUrl属性により指定されるServiceLocationAttributeファイルのXML schemaの一例を示している。
　図１１は、新たに導入したServiceLocation要素を示している。ServiceLocation要素は、チューニングパラメータ(DeliverySystemAttributes)およびIPマルチキャストアドレス(IPMulticastAddress)から成る。そして、該ServiceLocation要素をルート要素として格納するServiceLocationAttributeファイルのurlがBaseURLに配置されたServiceLocationAttributeUrl属性に記述される。
　DeliverySystemAttributesのDeliverySystemIdentifierには、例えばMBMSなどのモバイルネットワークのマルチキャストベアラやブロードキャストベアラを利用する場合、MBMSなどによるマルチキャスト送信やブロードキャスト送信にて採用されているチューニングパラメタのデータ構造のフォーマット識別子（MBMSの場合、ID_MBMS）が記述される。
　また、例えばDVB地上波網などの既存のテレビジョン放送網のブロードキャストベアラを利用する場合、DVB地上波網のブロードキャスト送信にて採用されているチューニングパラメタのデータ構造のフォーマット識別子（DVB地上波網の場合、ID_DVB_T）が記述される。
　DeliverySystemAttributesのDeliverySystemDescriptorには、DeliverySystemIdentifierで識別される放送配信またはマルチキャスト配信にて規定されたチューニングパラメタのデータ構造(パラメタ自体)が記述される。なお、実際には、パラメータを表すバイト列がbase64等により文字列に変換されてDeliverySystemDescriptorに記述される。
　図１２は、MBMSによるマルチキャスト送信やブロードキャスト送信にて採用されているチューニングパラメタとしてのUser Service Descriptionのデータ構造の例である。
　bundleDescription(名前空間"urn:3GPP:metadata:2005:MBMS:userServiceDescription")は、userServiceDescription(名前空間"urn:3GPP:metadata:2005:MBMS:userServiceDescription")を複数束ねるための要素である。userServiceDescriptionは、serviceId属性で識別される、MBMSによるブロードキャスト送信またはマルチキャスト送信されるストリームを取得(チューン/join)するための情報を格納する要素である。
　deliveryMethod(名前空間"urn:3GPP:metadata:2005:MBMS:userServiceDescription")は、ストリームのマルチキャストアドレスが記載されたSDP(Session Description Protocol)を指定する要素である。具体的には、sessionDescriptionURI属性によりSDPファイルのURLが指定される。Registration(名前空間"urn:3GPP:metadata:2008:MBMS:userServiceDescription")は、マルチキャストサービスに登録するために必要な、例えばストリームのプロテクションキー等を取得するためのプロセス(registrationURL属性にて指定されるサーバサイドスクリプトを起動して行われる認証セッション等にリンクされる(マルチキャストストリームが暗号化・保護されているような場合))である。
　DeliveryServiceDescriptorの中に、上述したようなUserServiceDescription構造が格納されている場合には、MBMSサービスの規定に定義されているプロセスに従って利用登録を行えば、MBMSブロードキャストストリームまたはMBMSマルチキャストストリームを取得できるようになる。
　上述したように、ServiceLocation/DeliverySystem要素に格納される情報により取得されるMBMSブロードキャストストリームまたはMBMSマルチキャストストリーム上でIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリームには、RTPによりコンテンツストリームが運ばれるものとする。この場合のプロトコルの階層は図１３のＡに示されるように構成される。
　また、DVB地上波網によるブロードキャストベアラが利用された場合には、チューニングパラメタとして、"ETSI TS 102 851 V1.1.1 (2010-01) Digital Video Broadcasting (DVB); Uniform Resource Identifiers (URI) for DVB Systems"にて規定されているDVB_Tripletを含むDVBurlフォーマットdvb://<ONid>.<TSid>.<Sid>が格納され、該DVBurlフォーマットを参照することによりDVB地上波網によるブロードキャストストリームが取得される。
　ここで、DVB_Tripletは、DVB-SIのネットワーク情報テーブルNITに格納されているオリジナルネットワーク識別子ONid、並びにDVB-SIのストリーム記述テーブルSDTに格納されているトランスポートストリーム識別子TSidおよびサービス識別子Sidの３項目の情報を指す。
　上述したように、ServiceLocation/DeliverySystem要素に格納されるDVBurlフォーマットにより取得されるDVB地上波網によるブロードキャストストリーム上に転送されるIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリームには、RTPプロトコルによりコンテンツストリームが運ばれるものとする。この場合のプロトコルの階層は図１３のＢに示されるように構成される。
［コンテンツ供給システム５０の動作］
　次に、コンテンツ供給システム５０の動作について説明する。
　図１４は、コンテンツ供給システム５０の第１の動作を説明するフローチャートである。該第１の動作では、DASHクライアント７０からMPDコンフィギュレータ６５に対してMPDの書き換えが自発的に依頼される。
　なお、該第１の動作の前提として、DASHセグメントストリーマ６２は、コンテンツマネジメントサーバ６１から、同一内容のコンテンツのビットレートなどが異なる複数のストリーミングデータを取得、各ストリーミングデータをセグメント化して保持しており、そのHTTP送信を開始しているものとする。
　また、DASH MPDサーバ６３は、DASHセグメントストリーマ６２から通知されたストリームセグメントのファイルのアドレスに基づいてMPDを生成しており、そのHTTP送信を開始しているものとする。
　ステップＳ１において、コンテンツを受信、再生しようとするDASHクライアント７０は、インターネット１１を介してDASH MPDサーバ６３にアクセスし、MPDのHTTP送信を要求する。なお、DASHクライアント７０はDASH MPDサーバ６３のアドレスを予め知っているものとする。
　DASHクライアント７０からの要求に応じ、ステップＳ１１において、DASH MPDサーバ６３は、インターネット１１を介してDASHクライアント７０にMPDをHTTP送信する。
　MPDを受信したDASHクライアント７０は、該MPDに基づいてDASHセグメントストリーマ６２にアクセスし、HTTPによりユニキャスト送信されるストリームセグメントを受信、再生する。具体的には、MPDのBaseURLとmediaRangeに基づいてHTTPリクエストを発行して、DASHセグメントストリーマ６２にDASHストリームセグメントのファイルのHTTP送信を要求する。この要求に応じ、DASHセグメントストリーマ６２は、対応するファイルをインターネット１１を介してDASHクライアント７０にHTTP送信し、これをDASHクライアント７０が受信して再生する。
　この受信の間、DASHクライアント７０は、ステップＳ２として、インターネット１１の帯域をモニタリングし、今後、ユニキャスト受信が不安定になりそうであり、かつ、DASHクライアント７０自身が放送網１２を介したコンテンツのマルチキャスト送信やブロードキャスト送信を受信可能である場合、MPDコンフィギュレータ６５に取得済みのMPDを送信して該MPDの書き換えを要求する。
　DASHクライアント７０からのMPDの書き換えの要求に応じ、ステップＳ２１において、MPDコンフィギュレータ６５は、ブロードキャスト／マルチキャストリソースマネージャ６６に対してブロードキャストベアラおよびマルチキャストベアラのリソースの利用状況を確認する。さらに、ブロードキャストベアラおよびマルチキャストベアラを併用することのコストを考慮して、その利用を決定し、ブロードキャスト／マルチキャストリソースマネージャ６６に対してリソースの確保を要求する。ブロードキャスト／マルチキャストリソースマネージャ６６からリソースが確保できた旨の通知を受けた後、MPDコンフィギュレータ６５は、MPDを書き換えて、DASHクライアント７０に送信する。なお、送信された、書き換えられたMPDは、DASHクライアント７０で受信される前に、DASHクライアントプロキシ６７にモニタされる。
　書き換えられたMPDをモニタしたDASHクライアントプロキシ６７は、ステップＳ３１において、ブロードキャスト／マルチキャストプロバイダ６８に対して、放送網１２のFLUTEにより該MPDの周期的なマルチキャスト送信を依頼する。この依頼に応じ、ステップＳ４１において、ブロードキャスト／マルチキャストプロバイダ６８は、書き換えられたMPDを、放送網１２のFLUTEにより周期的にマルチキャスト送信する。このマルチキャスト送信により、MPDの書き換えを要求していないDASHクライアント７０に対しても、書き換えられたMPDを供給することができる。
　ステップＳ３２において、DASHクライアントプロキシ６７は、モニタしたMPDに基づき、DASHクライアント７０の代わりにDASHセグメントストリーマ６２にストリームセグメントを要求する。この要求に応じたDASHセグメントストリーマ６２は、ステップＳ５１において、HTTPによりインターネット１１を介して、DASHクライアントプロキシ６７にストリームセグメントをユニキャスト送信する。
　HTTPによりユニキャスト送信されたストリームセグメント受信したDASHクライアントプロキシ６７は、ステップＳ３３において、HTTPのパケットに格納されている該ストリームセグメントをRTPパケットのペイロードに乗せ換えるプロトコル変換を行う。さらに、ブロードキャスト／マルチキャストプロバイダ６８に対して、プロトコル変換後のストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を依頼する。
　この依頼に応じ、ステップＳ４２において、ブロードキャスト／マルチキャストプロバイダ６８は、プロトコルが変換されたストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を開始する。
　なお、書き換えられたMPDを取得したDASHクライアント７０は、その後、ステップＳ３またはステップＳ５に進む。
　すなわち、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントの受信、再生を継続する場合にはステップＳ４の処理に進むことになり、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントにスイッチングする場合にはステップＳ５に進むことになる。
　ユニキャスト送信されるストリームセグメントの受信、再生を継続する場合、ステップＳ３において、DASHクライアント７０は、該MPDに基づいてDASHセグメントストリーマ６２にストリームセグメントを要求する。そして、ステップＳ４において、この要求に応じたDASHセグメントストリーマ６２からのHTTPによるインターネット１１を介したストリームセグメントのユニキャスト送信（ステップＳ５２の処理）を受信、再生する。
　また、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントにスイッチングする場合、ステップＳ５において、DASHクライアント７０は、書き換えられたMPDに基づき、HTTPによりユニキャスト送信されているセグメントストリームから、マルチキャスト送信またはブロードキャスト送信された、プロトコル変換されたストリームセグメントに受信、再生をスイッチングする。
　このスイッチングのタイミングは、書き換えられたMPD上のマルチキャストストリームに対応するRepresentationに対応するSegment列に格納されているrtspRangeの時間区間情報を頼りに、ユニキャストで運ばれるRepresentationに対応するSegment列との対応関係に基づいて決定される。
　なお、上述したプロトコル変換におけるストリームセグメントをRTPパケットのペイロードに格納する方式は、コンテンツの符号化方式(AVC、AMR等)ごとに定められている。RTPによるストリーミングの際には、RTCP(RTP Control Protocol)も同時に用いて複数のRTPパケットストリームで運ばれるストリーム間の同期再生用の時間軸を決めるための、RTPタイムスタンプとそれに対応するNTP(Network Time Protocol)タイムスタンプが転送される。
　なお、NTPタイムスタンプは、1900年1月1日0時0分0秒からの経過秒数（整数部32bit、小数部32bitの符号なし固定小数点）であるが、UTCタイムスタンプ(フォーマットは例: 2004-04-01T12:00Z (20040401T1200Z). UTCでの2004年4月1日の正午を表す)に容易に変換可能である。よって、これからRTPタイムスタンプの絶対時刻(Wall Clock Time)上の位置(時刻)を計算することができる。すなわち、NTPタイムスタンプによって、コンテンツの供給側と受信側のシステム時刻(wall clock)が同期され、その時間軸上に、RTCPで運ばれるNTPタイムスタンプとRTPタイムスタンプとの対応関係情報に基づいてスイッチング対象のRTPパケットが特定される。
　なお、この後においては、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。
　以上で、コンテンツ供給システム５０の第１の動作の説明を終了する。
　次に、図１５は、コンテンツ供給システム５０の第２の動作を説明するフローチャートである。該第２の動作では、MPDプロキシサーバ６４が主体となってMPDコンフィギュレータ６５に対してMPDの書き換えが依頼される。
　なお、該第２の動作の前提として、DASHセグメントストリーマ６２は、コンテンツマネジメントサーバ６１から、同一内容のコンテンツのビットレートなどが異なる複数のストリーミングデータを取得、各ストリーミングデータをセグメント化して保持しており、そのHTTP送信を開始しているものとする。
　また、DASH MPDサーバ６３は、DASHセグメントストリーマ６２から通知されたストリームセグメントのファイルのアドレスに基づいてMPDを生成しており、そのHTTP送信を開始しているものとする。
　ステップＳ７１において、コンテンツを受信、再生しようとするDASHクライアント７０は、インターネット１１を介してDASH MPDサーバ６３にMPDのHTTP送信を要求する。この要求は、MPDプロキシサーバ６４によって受信され、MPDプロキシサーバ６４は、ステップＳ８１において、DASH MPDサーバ６３にMPDの送信を要求する。
　この要求に応じたDASH MPDサーバ６３は、ステップＳ９１において、MPDをMPDプロキシサーバ６４に送信する。該MPDを受信したMPDプロキシサーバ６４は、ステップＳ８２において、受信したMPDをMPDコンフィギュレータ６５に送信して該MPDの書き換えを要求する。
　MPDの書き換え要求に応じ、ステップＳ１０１において、MPDコンフィギュレータ６５は、ブロードキャスト／マルチキャストリソースマネージャ６６に対してブロードキャストベアラおよびマルチキャストベアラのリソースの利用状況を確認する。さらに、ブロードキャストベアラおよびマルチキャストベアラを併用することのコストを考慮して、その利用を決定し、ブロードキャスト／マルチキャストリソースマネージャ６６に対してリソースの確保を要求する。ブロードキャスト／マルチキャストリソースマネージャ６６からリソースが確保できた旨の通知を受けた後、MPDコンフィギュレータ６５は、MPDを書き換えてMPDプロキシサーバ６４に送信する。
　ステップＳ８３において、MPDプロキシサーバ６４は、書き換えられたMPDをDASHクライアント７０に送信する。なお、送信された、書き換えられたMPDは、DASHクライアント７０で受信される前に、DASHクライアントプロキシ６７にモニタされる。
　書き換えられたMPDをモニタしたDASHクライアントプロキシ６７は、ステップＳ１１１において、ブロードキャスト／マルチキャストプロバイダ６８に対して、放送網１２のFLUTEにより該MPDの周期的なマルチキャスト送信を依頼する。この依頼に応じ、ステップＳ１２１において、ブロードキャスト／マルチキャストプロバイダ６８は、書き換えられたMPDを、放送網１２のFLUTEにより周期的にマルチキャスト送信する。このマルチキャスト送信により、MPDの送信を要求していないDASHクライアント７０に対しても、書き換えられたMPDを供給することができる。
　ステップＳ１１３において、DASHクライアントプロキシ６７は、モニタした、書き換えられたMPDに基づき、DASHクライアント７０の代わりにDASHセグメントストリーマ６２にストリームセグメントを要求する。この要求に応じたDASHセグメントストリーマ６２は、ステップＳ１３１において、HTTPによりインターネット１１を介して、DASHクライアントプロキシ６７にストリームセグメントをユニキャスト送信する。
　HTTPによりユニキャスト送信されたストリームセグメント受信したDASHクライアントプロキシ６７は、ステップＳ１１３において、HTTPのパケットに格納されている該ストリームセグメントをRTPパケットのペイロードに乗せ換えるプロトコル変換を行う。さらに、ブロードキャスト／マルチキャストプロバイダ６８に対して、プロトコル変換後のストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を依頼する。
　この依頼に応じ、ステップＳ１２２において、ブロードキャスト／マルチキャストプロバイダ６８は、プロトコルが変換されたストリームセグメントのRTPによる放送網１２を介したマルチキャスト送信およびブロードキャスト送信を開始する。
　一方、DASHクライアント７０は、既に書き換えられたMPDを取得している。ステップＳ７２において、DASHクライアント７０は、インターネット１１の帯域状態、自身の受信機能などに基づいて、インターネット１１を介するユニキャスト送信を受信するか、放送網１２を介するマルチキャスト送信またはブロードキャスト送信を受信するかを選択する。
　HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントの受信、再生を行うことが選択された場合、処理はステップＳ７３に進められる。ステップＳ７３において、DASHクライアント７０は、該MPDに基づいてDASHセグメントストリーマ６２にストリームセグメントを要求する。そして、ステップＳ７４において、この要求に応じたDASHセグメントストリーマ６２からのHTTPによるインターネット１１を介したストリームセグメントのユニキャスト送信（ステップＳ１３２の処理）を受信、再生する。
　また、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントの受信、再生を行うことが選択された場合、処理はステップＳ７５に進められる。ステップＳ７５において、DASHクライアント７０は、書き換えられたMPDに基づき、RTPによりマルチキャスト送信またはブロードキャスト送信された、プロトコル変換されたストリームセグメントを受信、再生する。
　なお、この後においては、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。
　以上で、コンテンツ供給システム５０の第２の動作の説明を終了する。
　以上説明したように、本実施の形態であるコンテンツ供給システム５０によれば、HTTPによりインターネット１１を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網１２を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。したがって、DASHクライアント７０のユーザは、同一内容のコンテンツであってパスが異なるストリームを適応的に選択し、視聴することができる。
　ところで、上述した一連の処理を実行するコンテンツ供給装置６０、およびDASHクライアント７０は、それぞれをハードウェアにより構成する他、コンピュータがソフトウェアを実行することにより実現することもできる。このコンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
　図１６は、上述したコンピュータのハードウェアの構成例を示すブロック図である。
　このコンピュータ１００において、CPU（Central Processing Unit）１０１，ROM（Read Only Memory）１０２，RAM（Random Access Memory）１０３は、バス１０４により相互に接続されている。
　バス１０４には、さらに、入出力インタフェース１０５が接続されている。入出力インタフェース１０５には、入力部１０６、出力部１０７、記憶部１０８、通信部１０９、およびドライブ１１０が接続されている。
　入力部１０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１０７は、ディスプレイ、スピーカなどよりなる。記憶部１０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１０９は、ネットワークインタフェースなどよりなる。ドライブ１１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１１１を駆動する。
　以上のように構成されるコンピュータ１００では、CPU１０１が、例えば、記憶部１０８に記憶されているプログラムを、入出力インタフェース１０５およびバス１０４を介して、RAM１０３にロードして実行することにより、上述した一連の処理が行われる。
　コンピュータ１００（CPU１０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
　コンピュータ１００では、プログラムは、リムーバブルメディア１１１をドライブ１１０に装着することにより、入出力インタフェース１０５を介して、記憶部１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１０９で受信し、記憶部１０８にインストールすることができる。その他、プログラムは、ROM１０２や記憶部１０８に、あらかじめインストールしておくことができる。
　なお、コンピュータ１００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであってもよい。
　なお、本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
　１１　インターネット，　１２　放送網，　５０　コンテンツ供給システム，　６０　コンテンツ供給装置，　６１　コンテンツマネジメントサーバ，　６２　DASHセグメントストリーマ，　６３　DASH MPDサーバ，　６４　MPDプロキシサーバ，　６５　MPDコンフィギュレータ，　６６　ブロードキャスト／マルチキャストリソースマネージャ，　６７　DASHクライアントプロキシ，　６８　ブロードキャスト／マルチキャストサービスプロバイダ，　７０　DASHクライアント，　１００　コンピュータ，　１０１　CPU

Claims (8)

  1. 　MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置において、
    　前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
    　前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
    　HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
    　を備えるコンテンツ供給装置。
  2. 　前記HTTPによりユニキャスト送信される前記セグメントファイルを受信するための情報を記述したMPDを生成するMPD生成部をさらに備え、
    　前記メタファイル生成部は、前記MPDを書き換えることにより前記メタファイルを生成する
    　請求項１に記載のコンテンツ供給装置。
  3. 　前記メタファイル生成部は、前記MPDに記述されている、HTTPによりユニキャスト送信される前記セグメントファイルのmediaRange属性に対応付けて、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルのrtspRange属性を追記することにより前記メタファイルを生成する
    　請求項２に記載のコンテンツ供給装置。
  4. 　前記RTP送信部は、前記HTTP送信部からHTTPによりユニキャスト送信された前記セグメントファイルをRTPパケットに乗せ変えるプロトコル変換を施して、マルチキャストまたはブロードキャストの少なくとも一方で送信する
    　請求項２に記載のコンテンツ供給装置。
  5. 　前記RTP送信部は、さらに、RTCPによりRTPタイムスタンプと前記RTPタイムスタンプに対応するNTPタイムスタンプを送信する
    　請求項２に記載のコンテンツ供給装置。
  6. 　MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、
    　前記コンテンツ供給装置による、
    　　前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信ステップと、
    　　前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信ステップと、
    　　HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成ステップと
    　を含むコンテンツ供給方法。
  7. 　MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンピュータを、
    　前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
    　前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
    　HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
    　して機能させるプログラム。
  8. 　MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信するクライアント装置とから成るコンテンツ供給システムにおいて、
    　前記コンテンツ供給装置は、
    　　前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
    　　前記セグメントファイルをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
    　　HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部とを備え、
    　前記クライアント装置は、
    　　取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとを切り替えて受信、再生する
    　コンテンツ供給システム。
PCT/JP2014/055928 2013-03-19 2014-03-07 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム WO2014148277A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP14767964.1A EP2978229B1 (en) 2013-03-19 2014-03-07 Content provision device, content provision method, program, and content provision system
JP2015506701A JP6457931B2 (ja) 2013-03-19 2014-03-07 コンテンツ供給装置、コンテンツ供給方法、コンテンツ受信装置、コンテンツ受信方法、プログラム、およびコンテンツ供給システム
BR112015022727A BR112015022727A8 (pt) 2013-03-19 2014-03-07 dispositivo, método e sistema de fornecimento de conteúdo, e, mídia legível por computador
US14/764,644 US10165035B2 (en) 2013-03-19 2014-03-07 Content supplying device, content supplying method, program, and content supplying system
CN201480014550.7A CN105052159B (zh) 2013-03-19 2014-03-07 内容提供设备、内容提供方法、程序、和内容提供系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2013056759 2013-03-19
JP2013-056759 2013-03-19

Publications (1)

Publication Number Publication Date
WO2014148277A1 true WO2014148277A1 (ja) 2014-09-25

Family

ID=51579964

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/055928 WO2014148277A1 (ja) 2013-03-19 2014-03-07 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム

Country Status (6)

Country Link
US (1) US10165035B2 (ja)
EP (1) EP2978229B1 (ja)
JP (1) JP6457931B2 (ja)
CN (1) CN105052159B (ja)
BR (1) BR112015022727A8 (ja)
WO (1) WO2014148277A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016147092A1 (en) * 2015-03-13 2016-09-22 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live adaptive bitrate (abr) media
EP3219030B1 (en) * 2014-11-10 2023-01-25 Bayerische Motoren Werke Aktiengesellschaft Method and device for receiving a broadcast service comprising switching between digital audio broadcasting (dab) transmissions and enhanced multimedia broadcast/multicast transmissions (embms)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9866608B2 (en) * 2014-03-24 2018-01-09 Qualcomm Incorporated Processing continuous multi-period content
JP6340882B2 (ja) * 2014-04-04 2018-06-13 ソニー株式会社 情報処理装置、情報処理方法、及び、プログラム
US10735823B2 (en) 2015-03-13 2020-08-04 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live ABR media
US9854375B2 (en) * 2015-12-01 2017-12-26 Qualcomm Incorporated Selection of coded next generation audio data for transport
WO2020109491A1 (en) * 2018-11-30 2020-06-04 British Telecommunications Public Limited Company Multicast to unicast conversion

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010050022A1 (ja) * 2008-10-29 2010-05-06 富士通株式会社 配信システム、代理サーバおよび配信方法
WO2012096372A1 (ja) * 2011-01-14 2012-07-19 シャープ株式会社 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2648087T3 (es) 2010-10-25 2017-12-28 Alcatel Lucent Procedimiento de difusión en continuo adaptativa
US9026671B2 (en) * 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US9986209B2 (en) * 2013-02-15 2018-05-29 Steven Philip Meyer Method and system for managing data from digital network surveillance cameras

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010050022A1 (ja) * 2008-10-29 2010-05-06 富士通株式会社 配信システム、代理サーバおよび配信方法
WO2012096372A1 (ja) * 2011-01-14 2012-07-19 シャープ株式会社 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"Digital Video Broadcasting (DVB); Uniform Resource Identifiers (URI) for DVB Systems", ETSI TS 102 851 V1.1.1, January 2010 (2010-01-01)
MITSUHIRO HIRABAYASHI: "Realize the video delivery uninterrupted in existing Web servers", NIKKEI ELECTRONICS, 19 March 2012 (2012-03-19)
SCHULZRINNE ET AL., RTP: A TRANSPORT PROTOCOL FOR REAL-TIME APPLICATIONS, July 2003 (2003-07-01), pages 29 - 34, XP055172171 *
See also references of EP2978229A4

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3219030B1 (en) * 2014-11-10 2023-01-25 Bayerische Motoren Werke Aktiengesellschaft Method and device for receiving a broadcast service comprising switching between digital audio broadcasting (dab) transmissions and enhanced multimedia broadcast/multicast transmissions (embms)
WO2016147092A1 (en) * 2015-03-13 2016-09-22 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live adaptive bitrate (abr) media
CN107409135A (zh) * 2015-03-13 2017-11-28 瑞典爱立信有限公司 用于直播自适应比特率(abr)媒体的优化传递的系统和方法
US10826960B2 (en) 2015-03-13 2020-11-03 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live ABR media
CN107409135B (zh) * 2015-03-13 2021-06-29 瑞典爱立信有限公司 用于直播自适应比特率(abr)媒体的优化传递的系统和方法

Also Published As

Publication number Publication date
US20150365458A1 (en) 2015-12-17
CN105052159A (zh) 2015-11-11
EP2978229A4 (en) 2016-10-26
CN105052159B (zh) 2019-03-22
JPWO2014148277A1 (ja) 2017-02-16
JP6457931B2 (ja) 2019-01-23
EP2978229A1 (en) 2016-01-27
BR112015022727A2 (pt) 2017-07-18
EP2978229B1 (en) 2021-02-24
BR112015022727A8 (pt) 2019-11-26
US10165035B2 (en) 2018-12-25

Similar Documents

Publication Publication Date Title
WO2014188886A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JP6457931B2 (ja) コンテンツ供給装置、コンテンツ供給方法、コンテンツ受信装置、コンテンツ受信方法、プログラム、およびコンテンツ供給システム
RU2636123C2 (ru) Устройство предоставления содержания, способ предоставления содержания, программа и система предоставления содержания
JP6258856B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
WO2014208377A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JP6329964B2 (ja) 送信装置、送信方法、受信装置、及び、受信方法
KR20120114016A (ko) 사용자 컨텐츠를 외부 단말기에서 네트워크 적응적으로 스트리밍하는 방법 및 장치
JP6630860B2 (ja) 端末装置および受信方法
WO2014196392A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
WO2016136489A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
KR20190066060A (ko) 모바일 사용자 장치들에 컨텐츠를 전송하는 방법
JP6514505B2 (ja) 情報処理装置、情報処理方法、並びにプログラム
WO2014203745A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JP2015501018A (ja) コンテンツをサーバおよび対応する装置上のファイルに保存する方法
WO2015029800A1 (ja) サーバ装置、情報処理方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015045917A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
Hammershøj et al. Next-generation ott distribution architecture supporting multicast-assisted abr (mabr) and http/3 over quic
WO2017212931A1 (ja) 受信装置および受信方法、再生装置および再生方法、供給装置および供給方法、並びにプログラム
WO2015012140A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015029768A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015064384A1 (ja) 送信装置、送信方法、受信装置、及び、受信方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201480014550.7

Country of ref document: CN

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

Ref document number: 14767964

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
ENP Entry into the national phase

Ref document number: 2015506701

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14764644

Country of ref document: US

Ref document number: 2014767964

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: IDP00201505662

Country of ref document: ID

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112015022727

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112015022727

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20150911