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

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

Info

Publication number
WO2014196392A1
WO2014196392A1 PCT/JP2014/063794 JP2014063794W WO2014196392A1 WO 2014196392 A1 WO2014196392 A1 WO 2014196392A1 JP 2014063794 W JP2014063794 W JP 2014063794W WO 2014196392 A1 WO2014196392 A1 WO 2014196392A1
Authority
WO
WIPO (PCT)
Prior art keywords
metafile
content
streaming data
content supply
supplies
Prior art date
Application number
PCT/JP2014/063794
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 US14/893,475 priority Critical patent/US10212208B2/en
Priority to EP14808290.2A priority patent/EP3007458A4/en
Priority to CN201480030652.8A priority patent/CN105247882A/zh
Publication of WO2014196392A1 publication Critical patent/WO2014196392A1/ja

Links

Images

Classifications

    • 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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/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/643—Communication protocols
    • H04N21/64322—IP
    • 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, a content supply apparatus suitable for use in the case of supplying content of the same content via a plurality of distribution paths, It relates to a program and a content supply system.
  • MPEG-DASH Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP, hereinafter referred to as DASH
  • DASH Dynamic Adaptive Streaming over HTTP
  • Adaptive streaming technology is realized in DASH. That is, the content supply side prepares a plurality of streams having the same content, and in which the image quality, the angle of view size, etc. are changed according to the Internet communication environment serving as the path and the capability and state of the reception side. It is done like that.
  • the receiving side can select, acquire, and reproduce an optimal stream according to the communication environment of the Internet, the capability and the state of the receiving side, and the like among the plurality of streams prepared by the supplying side.
  • MPD Media Presentation Description
  • the MPD describes the address (url information) of chunked streaming data (media data such as Audio / Video / Subtitle), and the receiving side is a predetermined content source based on the url information.
  • the server can be accessed to obtain streaming data to be delivered via HTTP and played back.
  • FIG. 1 shows an example of the configuration of a content supply system for streaming content based on DASH.
  • the content supply system 10 includes a content management server 11, a DASH segment streamer 12, a DASH MPD server 13, a cache server 15, and a DASH client 17.
  • the content management server 11 manages content to be supplied to the DASH client 17, generates a plurality of streaming data having different bit rates from the content of the same content, and outputs the streaming data to the DASH segment streamer 12.
  • the DASH segment streamer 12 temporally divides streaming data of content into segments, makes each of the files into a file, holds the file, and notifies the DASH MPD server 13 of the address of the supply source of the file. Further, the DASH segment streamer 12 HTTP-distributes segmented streaming data files as an HTTP server in response to a request from the DASH client 17 on the receiving side.
  • the DASH MPD server 13 generates an MPD in which an address or the like representing the source of a plurality of segmented streaming data files is described, and delivers the MPD in response to a request from the DASH client 17 on the receiving side.
  • the cache server 15 existing on the Internet caches HTTP distributed MPD, segmented streaming data file, and the like. Then, when the caching MPD or segmented streaming data file is requested from the DASH client 17-2 to the DASH MPD server 13 or the DASH segment streamer 12, the caching MPD or segmentation is performed instead of them.
  • the distributed streaming data is delivered to the DASH client 17-2 via HTTP.
  • the DASH client 17 acquires the MPD from the DASH MPD server 13 and selects a stream suitable for the current situation from among the plurality of streams prepared by the DASH segment streamer 12 based on the acquired MPD, and selects the DASH segment streamer 12 Request, and receive and reproduce the file delivered by HTTP according to the request.
  • DASH implements adaptive streaming technology using HTTP delivery via the Internet.
  • the receiving side can acquire and reproduce a stream distributed by broadcasting over various broadcasting networks (terrestrial broadcasting, satellite broadcasting, mobile communication network, wireless LAN such as Wi-Fi, etc.) or a stream distributed by multicasting via the Internet It is desirable to supply streams using these delivery paths so that the stream can be adaptively selected on the receiving side.
  • broadcasting networks terrestrial broadcasting, satellite broadcasting, mobile communication network, wireless LAN such as Wi-Fi, etc.
  • wireless LAN such as Wi-Fi, etc.
  • the present disclosure has been made in view of such circumstances, and extends adaptive streaming technology using DASH so that content can be supplied by different distribution paths.
  • a content supply device for supplying a plurality of streaming data having the same content and different attributes according to an adaptive streaming technique, wherein the plurality of streaming data are different
  • a metafile is generated that includes a supply unit that supplies to the receiver via multiple networks, a QoS parameter for the receiver to select the multiple streaming data to be supplied, and a manifest file acquisition destination that describes the condition value And a meta file generation unit to be supplied to the receiving side.
  • the metafile generator may generate an expanded MPD as the metafile.
  • the plurality of different networks may include at least one of the Internet, a terrestrial broadcast network, a satellite broadcast network, a cable television broadcast network, a mobile broadcast network, or a wireless LAN.
  • the meta file may be supplied to the receiving side by HTTP distribution, FLUTE distribution, or broadcast distribution via the network.
  • a content supply method of a content supply apparatus is a content supply method of a content supply apparatus that supplies a plurality of streaming data having the same content and different attributes according to an adaptive streaming technique.
  • a program in accordance with adaptive streaming technology, provides a computer for providing a plurality of streaming data having the same content and different attributes according to adaptive streaming technology, the plurality of streaming data, and a plurality of different networks.
  • a metafile including a supply unit to be supplied to the receiving side via the receiving side, a QoS parameter for the receiving side to select the plurality of streaming data to be supplied, and a manifest file acquisition destination in which the condition value is described; Function as a metafile generator supplied to
  • a plurality of streaming data are supplied to the receiving side via different networks, and the QoS parameter and its condition value for the receiving side to select the plurality of streaming data supplied are provided.
  • a metafile containing the described manifest file acquisition destination is generated and supplied to the receiver.
  • a content supply system is a content supply apparatus that supplies a plurality of streaming data having the same content and different attributes according to adaptive streaming technology, and a terminal apparatus that receives the stream data
  • a content supply apparatus that supplies the plurality of streaming data to the terminal apparatus via a plurality of different networks; and the terminal apparatus that supplies the plurality of streaming data to be supplied
  • a metafile generation unit that generates a metafile including a QoS parameter for selecting and a manifest file acquisition destination in which the condition value is described, and supplies the metafile to the receiving side, and the terminal apparatus acquires the metafile acquired Based on the manifest file Tokushi, the QoS parameters described in the manifest file and on the basis of the condition values, selects the streaming data to be received.
  • a QoS parameter for a receiver to select a plurality of streaming data supplied by a content supply device to a receiver via a plurality of different networks and supplied.
  • a metafile including the source of the manifest file describing the condition value and the condition value is generated and supplied to the receiving side.
  • the manifest file is acquired by the terminal device based on the acquired metafile, and the streaming data to be received is selected based on the QoS parameter described in the manifest file and its condition value.
  • content can be provided by a plurality of different distribution paths.
  • adaptive streaming techniques using DASH can be extended to provide content with different delivery paths.
  • FIG. 8 is a diagram illustrating an example in which the following structure is described in an XML format. It is a figure which shows the structure of expanded MPD.
  • FIG. 7 is a diagram showing an example of QoS parameters of DVB satellite broadcasting / cable television.
  • FIG. 7 is a diagram showing an example of QoS parameters of DVB cable television.
  • QoS parameter of DVB satellite broadcasting It is a figure which shows the example of the QoS parameter of DVB satellite broadcasting.
  • QoS parameter of terrestrial broadcasting DVD-T.
  • FIG. 5 illustrates an example of QoS parameters for a 3G mobile phone (UTRA FDD) terminal.
  • FIG. 7 illustrates an example of QoS parameters for 3G mobile phone (UTRA TDD) terminals.
  • FIG. 7 is a diagram illustrating an example of QoS parameters for an LTE (E-UTRA) terminal.
  • FIG. 2 shows a stack of streaming protocols. It is a flowchart explaining operation
  • a content supply system which is an embodiment of the present disclosure, implements adaptive streaming that supplies content via different distribution paths.
  • the receiving side can receive and reproduce the optimal content stream according to the reception environment of the user, the decoding capability, and the like.
  • FIG. 2 shows a configuration example of a content supply system according to an embodiment of the present disclosure.
  • the content supply system 20 includes a content supply device 30 and a terminal device 40.
  • the content supply device 30 has a content management server 31, a DASH segment streamer 32, a DASH MPD server 33, an RTP / RTP / FLUTE server 34, and a broadcast distribution server 35.
  • the content management server 31 manages content (including live broadcast content) to be supplied to the terminal device 40 on the receiving side, generates a plurality of streaming data having different bit rates from the content of the same content, and transmits the DASH segment streamer 32. Output to
  • the DASH segment streamer 32 temporally divides streaming data of content into periods, and further divides the data into segments, and stores the respective files into files. Further, the DASH segment streamer 32 notifies the DASH MPD server 33 and the RTP / FLUTE server 34 of the address from which the file to be held is supplied. Also, the DASH segment streamer 32 provides the RTP / FLUTE server 34 with a file of segmented streaming data. Furthermore, in response to a request from the terminal device 40, the DASH segment streamer 32 unicasts the segmented streaming data file via the Internet 1 by HTTP.
  • the DASH MPD server 33 generates an MPD necessary to receive streaming data of content supplied via a plurality of different distribution paths, and in response to a request from the terminal device 40, the MPD is transmitted over the Internet 1 by HTTP. Distribute via unicast. Also, the DASH MPD server 33 supplies the generated MPD to the RTP / FLUTE server 34. In addition to HTTP distribution from the DASH MPD server 33, the generated MPD may be distributed by multicast from the RTP / FLUTE server 34 or distributed by broadcast from the broadcast distribution server 35.
  • the RTP / FLUTE server 34 generates FLUTE packets (such as ALC (Asynchronous Layered Coding) packets storing files of segmented streaming data), and generates FDTs based on the MPD, and FLUTE packets and FDTs are FLUTEd. Multicast distribution via the Internet 1 in accordance with the protocol. Further, the RTP / FLUTE server 34 supplies the FLUTE packet and the FDT to the broadcast distribution server 35.
  • FLUTE packets such as ALC (Asynchronous Layered Coding) packets storing files of segmented streaming data
  • the broadcast distribution server 35 broadcasts and distributes FLUTE packets and FDT supplied from the RTP / FLUTE server 34 via the broadcast network 2.
  • the broadcast network 2 includes terrestrial broadcast, satellite broadcast, CATV network, mobile communication network, and the like.
  • multicast delivery includes broadcast delivery via the broadcast network 2.
  • the cache server 36 provided on the Internet 1 caches MPDs which have been HTTP-distributed or multicast-distributed via the Internet 1, files of segmented streaming data, FDTs, FLUTE packets and the like.
  • the MPD or the like caching is requested from the terminal device 40 to the DASH MPD server 33 or the like, the MPD or the like caching the information is HTTP distributed to the terminal device 40 of the request source instead.
  • FIG. 4 shows the data structure of the MPD.
  • FIG. 5 shows a hierarchical structure below Period in MPD.
  • each Period is provided with a plurality of Representations which are information having the same content and information on streaming data having different stream attributes such as the image quality and the bit rate at which the angle of view size is changed.
  • Representation information on Segments obtained by further dividing the Period into time is stored.
  • FIG. 6 shows the state in which the MPD structure is arranged on the time axis.
  • the terminal device 40 can use any of these in Segment units according to the communication environment, its own decoding capability, etc. By adaptively selecting, appropriate stream data can be obtained and reproduced.
  • FIG. 7 shows in detail the structure below the MPD Representation.
  • Representation the address of the supply source of the file in which the segmented stream data is stored is described. Specifically, when a plurality of segmented stream data are individually filed, a sequence of the address (url information) of the supply source of each file is described. In addition, when a plurality of segmented stream data are grouped together into one file, the address (Base URL) of the source of the file and 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.
  • MPD / Period / AdaptationSet / Representation / SegmentList / SegmentURL / @ mediaRange indicates the byte range of segmented stream data in the file.
  • 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.
  • the mediaRange "795" is included in the Range header together with the file url "http://example.com/counter-10mn_avc_dash.mp4".
  • MPD extension In the present embodiment, not only the Internet but also various broadcast networks can be described as the distribution path of the content stream, and further, the reference value of the QoS parameter required when selecting each distribution path and receiving is described. Extend MPD to be able to
  • a ServiceLocation element in which tuning parameters (DeliverySystemAttributes) and an IP multicast address (IPMulticastAddress) are described as new elements for receiving an IP multicast stream to which a segment file group is transferred is introduced. Then, the serviceLocationAttribute Url attribute for describing the url of the serviceLocationAttribute file storing the ServiceLocation element as a root element is introduced into the MPD.
  • FIG. 10 shows an example of the XML schema of the ServiceLocation element stored in the ServiceLocation file specified by the serviceLocationAttributeUrl attribute.
  • FIG. 11 illustrates the hierarchical structure of XML schema below DeliverySystemAttributes shown in FIG.
  • L3L4L5Address stores FLUTE session stream, IP address "ipAddress” to which RTP multicast stream is transferred, port number "port”, and FLUTE session ID "transportSessionId” when SDP is not used for multicast stream resolution It is an element.
  • the DeliverySystemIdentifier is an element in which the format identifier of the data structure of the tuning parameter adopted in broadcast distribution or multicast distribution is stored. For example, in the case of broadcast distribution by terrestrial broadcast adopted in Europe, "ID_DVB_T” is stored, and in the case of broadcast distribution to satellite broadcast, "ID_DVB_S" is stored.
  • the DeliverySystem Descriptor is an element in which the data structure (parameter itself) of the tuning parameter specified in broadcast distribution or multicast distribution identified by DeliverySystemIdentifier is stored.
  • FIG. 12 is an example of a data structure of tuning parameters corresponding to broadcast distribution by terrestrial broadcast adopted in Europe. Note that, in practice, a byte string conforming to the above format is converted to a character string by base 64 or the like and described in the Delivery System Descriptor.
  • RequiredQoSParameter is the identification name of the QoS parameter required for tuning, "parameterURI”, and its upper limit value as the request value "requestdValue”, “lowerLimit”, or "just (specified value)". It is an element to store.
  • a parameter representing the physical layer signal quality of a broadcast or mobile phone terminal is representative of radio waves.
  • Level 1 (specified by "urn: CNclass1"): 10-3 or more (defect)
  • Level 2 (specified by "urn: CNclass2”): 10-5 or more, 10-3 (good)
  • Level 3 (specified by "urn: CNclass3”): less than 10-5 (best)
  • RequiredQoSParameter / @ parameterURI urn: CarrierToNoiseRatio (unique identifier indicating C / N)
  • RequiredQoSParameter / requiredClass / @ class "urn: CNclass2”
  • RequiredQoSParameter / requiredClass / @ class "urn: CNclass3” (Meaning that the CN ratio and class 1 or class 2 are required) And write.
  • parameters listed in FIG. 13 to FIG. 21 can be described as the QoS parameter.
  • FIG. 13 is an example of QoS parameters of DVB satellite / cable television.
  • FIG. 14 is an example of QoS parameters of DVB cable television.
  • FIG. 15 is an example of QoS parameters of DVB satellite broadcasting.
  • FIG. 16 is an example of a terrestrial broadcast (DVB-T) QoS parameter. Examples of the QoS parameters shown in FIGS. 13 to 16 are all defined in ETSI TR 101 290 V1.2.1 (2001-05), "Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems". It is a thing.
  • FIG. 17 is an example of a terrestrial broadcast (DVB-T2) QoS parameter. These are defined in DVB BlueBook A14-2 (07/12), "Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems; Amendment for DVB-T2 System.
  • FIG. 18 is an example of QoS parameters of cable television (DVB-C2). These are defined in DVB BlueBook A14-3 (03/13), “Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems; Amendment for DVB-C2 System”.
  • FIG. 19 is an example of other terrestrial broadcast QoS parameters. These are those defined in NorDig Unified version 2.4.
  • FIG. 20 is an example of QoS parameters for a 3G mobile phone (UTRA FDD) terminal. These are defined in ETSI TS 125 215 V11.0.0 (2012-11); “Universal Mobile Telecommunications System (UMTS); Physical layer; Measurements (FDD) (3GPP TS 25.215 version 11.0.0 Release 11)" It is a thing.
  • UTRA FDD 3G mobile phone
  • FIG. 21 is an example of QoS parameters for 3G mobile phone (UTRA TDD) terminal. These are defined in ETSI TS 125 225 V11.0.0 (2012-09); "Universal Mobile Telecommunications System (UMTS); Physical layer; Measurements (TDD) (3GPP TS 25.225 version 11.0.0 Release 11)" It is a thing.
  • ETSI TS 125 225 V11.0.0 2012-09
  • UMTS Universal Mobile Telecommunications System
  • TDD Measurements
  • FIG. 22 is a diagram illustrating an example of QoS parameters for an LTE (E-UTRA) terminal. These are defined in ETSI TS 136 214 V11.1.0 (2013-02); "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; Measurements (3GPP TS 36.214 version 11.1.0 Release 11)". It is also defined in ETSI TS 136 214 V11.1.0 (2013-02); "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; Measurements (3GPP TS 36.214 version 11.1.0 Release 11)". It is defined in ETSI TS 136 214 V11.1.0 (2013-02); “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; Measurements (3GPP TS 36.214 version 11.1.0 Release 11)". It is also defined in ETSI TS 136 214 V11.1.0 (2013-02); “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA);
  • RTP or IP packet streams having a multicast address specified in the ServiceLocation / IPMulticastAddress element are RTP or Files are transported by the FLUTE protocol.
  • FIG. 23 shows a streaming protocol stack of files carried on an IP packet stream.
  • RTP is a protocol that transfers real-time (synchronous) streams over IP packets.
  • the FLUTE protocol is a protocol for transferring a file on an IP packet, and is hierarchically configured as shown in FIG.
  • MAC is a generic term for link layer protocols, and in the broadcasting system, GSE, TLV, etc. correspond.
  • the Content-Location element of the currently defined FDT can not represent a part of the file as in the sequence of MPD's BaseURL + SegmentURL mediaRange. Therefore, FDT is also extended to express a part of the file.
  • a range attribute is newly introduced so that the content-location and the byte range in the file specified by the url of the content-location can be specified.
  • the definition of range-specifier (RFC2616.section.14.35.1) applies to the syntax of the range attribute.
  • MPD Period / AdaptationSet / Representation / SegmentList / SegmentURL / @ mediaRange can be used as it is.
  • FIG. 24 is a flow chart for explaining the operation of the content supply apparatus 30 of the content supply system 20.
  • step S1 the content management server 31 supplies the DASH segment streamer 32 with a plurality of streaming data having the same content but different bit rates, for example, to be supplied to the terminal device 40 on the receiving side.
  • the content management server 31 notifies the DASH MPD server 33 of metadata of the content in step S2.
  • step S11 the DASH segment streamer 32 which has received the streaming data divides the streaming data of the content into periods in time and further into segments to generate DASH stream segments and file each of them. Also, the DASH segment streamer 32 supplies the file of the DASH stream segment to the RTP / FLUTE server 34 for multicast delivery.
  • step S12 the DASH segment streamer 32 notifies the DASH MPD server 33 and the RTP / FLUTE server 34 of the address (url information) of the supply source of the file of the DASH stream segment. Thereafter, in step S13, the DASH segment streamer 32 starts HTTP distribution of the file of the DASH stream segment via the Internet 1 in response to the request from the terminal device 40.
  • the DASH MPD server 33 notified of the address of the supply source of the file of the DASH stream segment generates an MPD in step S21, supplies the MPD to the RTP / FLUTE server 34 in step S22, and distributes the distribution according to the FLUTE I request it. Thereafter, in step S23, the DASH MPD server 33 starts HTTP distribution of the generated MPD via the Internet 1 in response to the request from the terminal device 40.
  • the RTP / FLUTE server 34 receiving the MPD from the DASH MPD server 33 generates the expanded FDT based on the MPD in step S31, and the file of the DASH stream segment supplied from the DASH segment streamer 32. To generate a FLUTE packet (or RTP packet) that stores
  • step S32 the RTP / FLUTE server 34 supplies the generated FDT and FLUTE packet (or RTP packet) to the broadcast distribution server 35, and requests their broadcast distribution. Thereafter, at a predetermined timing, the RTP / FLUTE server 34 starts multicast distribution of FDT and FLUTE packets (or RTP packets) via the Internet 1 in step S33.
  • the broadcast distribution server 35 receiving the supply of the FDT and the FLUTE packet (or RTP packet) broadcasts the FLUTE packet (or RTP packet) and the FDT via the broadcast network 2 at step S41 at a predetermined timing. This is the end of the description of the operation of the content supply device 30 of the content supply system 20.
  • FIG. 25 is a flowchart illustrating an operation until the terminal device 40 receives and reproduces content.
  • step S51 the terminal device 40 that is to receive and reproduce content accesses the DASH MPD server 33 via the Internet 1 and requests the MPD.
  • the DASH MPD server 33 delivers the HTTP of the MPD to the terminal device 40 via the Internet 1 in step S61.
  • the cache server 36 on the Internet 1 may HTTP-distribute the MPD to the terminal device 40 instead of the DASH MPD server 33.
  • MPD may be FLUTE distributed or broadcast distributed via the broadcast network 2, and the process of step S51 becomes unnecessary when receiving and acquiring it.
  • step S52 the terminal device 40 that has acquired the MPD acquires the ServiceLocationAttribute file based on the serviceLocationAttributeUrl attribute of the MPD, refers to the RequiredQoSParameter element described in the ServiceLocationAttribute file, and monitors its own current communication status. Choose the best stream to get.
  • step S53 the terminal device 40 issues an HTTP request based on the BaseURL and mediaRange corresponding to the selected stream of the MPD, and requests the DASH segment streamer 32 for a DASH stream segment file.
  • the DASH segment streamer 32 distributes the corresponding file to the terminal device 40 via the Internet 1 in step S71.
  • the cache server 36 on the Internet 1 holds the file, the cache server 36 may deliver the file to the terminal device 40 by HTTP instead of the DASH segment streamer 32.
  • step S54 the terminal device 40 receives and reproduces the HTTP-distributed file. After that, for example, when the communication environment of the Internet 1 is deteriorated, the terminal device 40 can adaptively switch the stream to be received. Specifically, as the step S55, for example, the file of the DASH stream segment which is being distributed by the broadcast distribution server 35 as the step S81 can be received and reproduced. Also, after that, it is possible to return to reception and reproduction of the file to be delivered by HTTP.
  • the RequiredQoSParameter element is provided in the ServiceLocationAttribute file that can be referred to based on the serviceLocationAttributeUrl attribute of the MPD, it is possible for the terminal device 40 to switch to the optimal stream in the current situation. It became.
  • the content supply device 30 and the terminal device 40 that execute the series of processes described above can be realized by a computer executing software, in addition to hardware being configured.
  • 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. 26 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.
  • the program can also 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
  • the present disclosure can also be configured as follows.
  • a supply unit that supplies the plurality of streaming data to the receiving side via different networks;
  • a metafile generation unit that generates a metafile including a QoS parameter for the receiver to select the plurality of streaming data to be supplied and an acquisition destination of a manifest file describing the condition value thereof, and supplies the metafile to the receiver; Supply device.
  • the plurality of different networks include at least one of the Internet, a terrestrial broadcast network, a satellite broadcast network, a cable television broadcast network, a mobile broadcast network, or a wireless LAN.
  • Reference Signs List 20 content supply system 30 content supply device, 31 content management server, 32 DASH segment streamer, 33 DASH MPD server, 34 FLUTE server, 35 broadcast distribution server, terminal device 40, 100 computer, 101 CPU

Landscapes

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

Abstract

　本開示は、DASHを用いた適応的ストリーミング技術を拡張し、異なる複数の配信パスによりコンテンツを供給することができるようにするコンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関する。　本開示の第１の側面であるコンテンツ供給装置は、適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置において、前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部とを備える。本開示は、コンテンツをストリーミング配信するシステムに適用できる。

Description

コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
　本開示は、コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関し、特に、同一内容のコンテンツを複数の配信パスを介して供給する場合に用いて好適なコンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関する。
　インタネットを介する動画配信に利用可能な国際標準化された動画配信プロトコルとして、Webサイトなどの閲覧と同様の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サーバとして、セグメント化されたストリーミングデータのファイルをHTTP配信する。
　DASH MPDサーバ１３は、セグメント化された複数のストリーミングデータのファイルの供給元を表すアドレスなどを記述したMPDを生成し、受信側のDASHクライアント１７からの要求に応じ、該MPDをHTTP配信する。
　インタネット上に存在するキャッシュサーバ１５は、HTTP配信されたMPDやセグメント化されたストリーミングデータのファイルなどをキャッシングする。そして、キャッシングしているMPDやセグメント化されたストリーミングデータのファイルがDASHクライアント１７-２からDASH MPDサーバ１３またはDASHセグメントストリーマ１２に要求された場合、それらに代わってキャッシングしているMPDやセグメント化されたストリーミングデータをDASHクライアント１７-２にHTTP配信する。
　DASHクライアント１７は、DASH MPDサーバ１３からMPDを取得し、取得したMPDに基づいて、DASHセグメントストリーマ１２が用意している複数のストリームのうち、現況に適したものを選択してDASHセグメントストリーマ１２に要求し、該要求に応じてHTTP配信されるファイルを受信、再生する。
「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEI ELECTRONICS 2012.3.19
　上述したように、DASHでは、インタネットを介するHTTP配信を用いた適応的ストリーミング技術が実現されている。
　ところで、受信側が各種放送網（地上放送、衛星放送、モバイル通信網、Wi-Fi等の無線LANなど）で放送配信されるストリームや、インタネットによるマルチキャスト配信されたストリームも取得、再生できるのであれば、それらの配信パスも用いてストリームを供給するようにし、受信側で適応的にストリームを選択できるようにすることが望ましい。
　しかしながら、DASHにおいてはコンテンツのストリーミングデータをHTTP配信することのみを想定しており、放送配信やマルチキャスト配信は想定されていない。
　したがって、DASHにて規定されたMPDにも、放送配信やマルチキャスト配信されるストリームについて記述する術がないので、上記を実現するためにはMPDを拡張する必要がある。
　さらに、MPDを拡張する場合、コンテンツを配信する様々なパスのそれぞれのQoS(Quality Of Service)に関するパラメータが記述できれば、受信側がストリームを選択する際の助けとなる。
　本開示はこのような状況に鑑みてなされたものであり、DASHを用いた適応的ストリーミング技術を拡張し、異なる複数の配信パスによりコンテンツを供給できるようにするものである。
　本開示の第１の側面であるコンテンツ供給装置は、適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置において、前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部とを備える。
　前記メタファイル生成部は、前記メタファイルとして拡張されたMPDを生成することができる。
　前記異なる複数のネットワークは、インタネット、地上放送網、衛星放送網、ケーブルテレビ放送網、モバイル放送網、または無線LANのうちの少なくとも一つを含むことができる。
　前記メタファイルは、前記ネットワークを介したHTTP配信、FLUTE配信、または放送配信により、前記受信側に供給されるようにすることができる。
　本開示の第１の側面であるコンテンツ供給装置のコンテンツ供給方法は、適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、前記コンテンツ供給装置による、前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給ステップと、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成ステップとを含む。
　本開示の第１の側面であるプログラムは、適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンピュータを、前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部として機能させる。
　本開示の第１の側面においては、複数のストリーミングデータが異なる複数のネットワークを介して受信側に供給され、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルが生成されて受信側に供給される。
　本開示の第２の側面であるコンテンツ供給システムは、適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信する端末装置とから成るコンテンツ供給システムにおいて、前記コンテンツ供給装置が、前記複数のストリーミングデータを、異なる複数のネットワークを介して前記端末装置に供給する供給部と、供給される前記複数のストリーミングデータを前記端末装置が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部とを備え、前記端末装置が、取得した前記メタファイルに基づいて前記マニフェストファイルを取得し、前記マニフェストファイルに記述されている前記QoSパラメータとその条件値に基づいて、受信するストリーミングデータを選択する。
　本開示の第２の側面においては、コンテンツ供給装置により、複数のストリーミングデータが異なる複数のネットワークを介して受信側に供給され、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルが生成されて受信側に供給される。また、端末装置により、取得した前記メタファイルに基づいて前記マニフェストファイルが取得され、前記マニフェストファイルに記述されている前記QoSパラメータとその条件値に基づいて、受信するストリーミングデータが選択される。
　本開示の第１の側面によれば、異なる複数の配信パスによりコンテンツを供給することができる。
　本開示の第２の側面によれば、DASHを用いた適応的ストリーミング技術を拡張し、異なる複数の配信パスによりコンテンツを供給することができる。
従来のコンテンツ供給システムの構成の一例を示すブロック図である。 本開示を適用したコンテンツ供給システムの構成例を示すブロック図である。 コンテンツの時間的区切りを説明する図である。 MPDの構成を示す図である。 MPDにおけるPeriod以下の階層構造を示す図である。 時間軸上にMPDの構成を並べた図である。 MPDのRepresentation以下の詳細な構造を示す図である。 Representation以下の構造をXML形式で記述した一例を示す図である。 拡張したMPDの構造を示す図である。 serviceLocationAttributeUrl属性により指定されるServiceLocation要素のXML Schemaの一例を示す図である。 serviceLocationAttributeUrl属性により指定されるServiceLocation要素のデータ構造を示す図である。 チューニングパラメータの一例を示す図である。 DVB衛星放送／ケーブルテレビのQoSパラメータの例を示す図である。 DVBケーブルテレビのQoSパラメータの例を示す図である。 DVB衛星放送のQoSパラメータの例を示す図である。 地上放送(DVB-T)のQoSパラメータの例を示す図である。 地上放送(DVB-T2)のQoSパラメータの例を示す図である。 ケーブルテレビ(DVB-C2)のQoSパラメータの例を示す図である。 その他の地上放送のQoSパラメータの例を示す図である。 ３Ｇ携帯電話機(UTRA FDD)端末用のQoSパラメータの例を示す図である。 ３Ｇ携帯電話機(UTRA TDD)端末用のQoSパラメータの例を示す図である。 LTE (E-UTRA)端末用のQoSパラメータの例を示す図である。 ストリーミングプロトコルのスタックを示す図である。 コンテンツ供給装置の動作を説明するフローチャートである。 コンテンツ供給システムの動作を説明するフローチャートである。 コンピュータの構成例を示すブロック図である。
　以下、本開示を実施するための最良の形態（以下、実施の形態と称する）について、図面を参照しながら詳細に説明する。
［コンテンツ供給システムの構成例］
　本開示の実施の形態であるコンテンツ供給システムは、コンテンツを異なる複数の配信パスを介して供給する適応的ストリーミングを実現するものである。
　具体的には、DASHにおけるMPDを拡張して、コンテンツストリームの配信パスとして、インタネットのみならず各種の放送網を記述できるようにするとともに、各配信パスを選択して受信する場合に必要となるQoS（サービス品質）パラメータの基準値を記述できるようにする。これにより、受信側では、自己の受信環境、デコード能力などに応じて、最適なコンテンツストリームを受信、再生することができる。
　図２は、本開示の実施の形態であるコンテンツ供給システムの構成例を示している。
　このコンテンツ供給システム２０は、コンテンツ供給装置３０および端末装置４０から構成される。
　コンテンツ供給装置３０は、コンテンツマネジメントサーバ３１、DASHセグメントストリーマ３２、DASH MPDサーバ３３、RTP/RTP/FLUTEサーバ３４、および放送配信サーバ３５を有する。
　コンテンツマネジメントサーバ３１は、受信側の端末装置４０に供給するコンテンツ（ライブ放送コンテンツを含む）を管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ３２に出力する。
　DASHセグメントストリーマ３２は、図３に示されるように、コンテンツのストリーミングデータを時間的にピリオド(period)に区切り、さらにセグメント(segment)に分割して、それぞれをファイル化して保持する。さらに、DASHセグメントストリーマ３２は、保持するファイルの供給元となるアドレスをDASH MPDサーバ３３およびRTP/FLUTEサーバ３４に通知する。また、DASHセグメントストリーマ３２は、セグメント化されたストリーミングデータのファイルをRTP/FLUTEサーバ３４に供給する。さらに、DASHセグメントストリーマ３２は、端末装置４０からの要求に応じ、セグメント化されたストリーミングデータのファイルを、HTTPによりインタネット１を介してユニキャスト配信する。
　DASH MPDサーバ３３は、異なる複数の配信パスを介して供給されるコンテンツのストリーミングデータを受信するために必要なMPDを生成し、端末装置４０からの要求に応じ、該MPDを、HTTPによりインタネット１を介してユニキャスト配信する。また、DASH MPDサーバ３３は、生成したMPDをRTP/FLUTEサーバ３４に供給する。なお、生成されたMPDは、DASH MPDサーバ３３からHTTP配信する他、RTP/FLUTEサーバ３４からマルチキャスト配信したり、放送配信サーバ３５から放送配信したりするようにしてもよい。
　RTP/FLUTEサーバ３４は、セグメント化されたストリーミングデータのファイルを格納したFLUTEパケット（ALC(Asynchronous Layered Coding)パケットなど）を生成するとともに、MPDに基づいてFDTを生成し、FLUTEパケットおよびFDTをFLUTEプロトコルに従い、インタネット１を介してマルチキャスト配信する。また、RTP/FLUTEサーバ３４は、FLUTEパケットおよびFDTを放送配信サーバ３５に供給する。
　放送配信サーバ３５は、RTP/FLUTEサーバ３４から供給されるFLUTEパケットおよびFDTを、放送網２を介して放送配信する。なお、放送網２には、地上放送、衛星放送、CATV網、携帯通信網などが含まれるものとする。以下、本明細書においては、マルチキャスト配信の用語は、放送網２を介する放送配信を含むものとする。
　インタネット１上に設けられたキャッシュサーバ３６は、インタネット１を介してHTTP配信またマルチキャスト配信されたMPD、セグメント化されたストリーミングデータのファイル、FDT、およびFLUTEパケットなどをキャッシングする。そして、キャッシングしているMPD等が、端末装置４０からDASH MPDサーバ３３などに対して要求された場合、それらに代わってキャッシングしているMPDなどを要求元の端末装置４０にHTTP配信する。
［MPDの概要］
　次に、MPDの概要について、図４および図５を参照して説明する。
　図４はMPDのデータ構成を示している。図５はMPDにおけるPeriod以下の階層構造を示している。
　MPDは、コンテンツ（Media)に関する情報がPeriod毎に区分されている。各Periodには、同一内容であって画質や画角サイズが変更されているビットレートなどのストリーム属性の異なるストリーミングデータに関する情報からなる複数のRepresentationが用意されている。Representationには、Periodをさらに時間的に分割したSegmentに関する情報が格納されている。
　図６は、時間軸上にMPDの構造を並べた状態を示している。同図から明らかなように、同一のSegmentに対して複数のRepresentationが存在しているので、端末装置４０ではこれらのうちのいずれかを、通信環境や自己のデコード能力などに応じてSegment単位で適応的に選択することにより、適切なストリームデータを取得、再生することができる。
　図７は、MPDのRepresentation以下の構造を詳細に示している。Representationには、セグメント化されたストリームデータが格納されたファイルの供給元のアドレスが記述される。具体的には、セグメント化された複数のストリームデータがそれぞれ個別にファイル化されている場合には、各ファイルそれぞれの供給元のアドレス（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が該ファイルにおける、セグメント化されたストリームデータのバイト範囲を示している。
　例えば、MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange="795-83596"は、該ファイルにおけるバイト範囲795バイト目から83596バイト目までが１つ目のセグメント化されたストリームデータであることを示している。
　したがって、端末装置４０が１つ目のセグメント化されたストリームデータを取得する際には、ファイルのurl"http://example.com/counter-10mn_avc_dash.mp4"とともに、そのRangeヘッダにmediaRange"795-83596"を指定してHTTPリクエストを発行すればよい。この際のHTTPリクエストは以下のとおりとなる。
　GET /counter-10mn_avc_dash.mp4 HTTP/1.1
　Host: example.com
　Range: bytes=795-83596
　また例えば２つ目のセグメント化されたストリームデータを取得するためには、ファイルのurl"http://example.com/Servicer/counter-10mn_avc_dash.mp4"とともに、mediaRange"83597-166046"を指定してHTTPリクエストを発行すればよい。この際のHTTPリクエストは以下のとおりとなる。
　GET /counter-10mn_avc_dash.mp4 HTTP/1.1
　Host: example.com
　Range: bytes=83597-166046
［MPDの拡張］
　本実施の形態においては、コンテンツストリームの配信パスとして、インタネットのみならず各種の放送網を記述できるようにし、さらに各配信パスを選択して受信する場合に必要となるQoSパラメータの基準値を記述できるようMPDを拡張する。
　具体的には、セグメントファイル群が転送されるIPマルチキャストストリームを受信するための新たな要素としてチューニングパラメータ(DeliverySystemAttributes)およびIPマルチキャストアドレス(IPMulticastAddress)が記述されたServiceLocation要素を導入する。そして、該ServiceLocation要素をルート要素として格納するserviceLocationAttributeファイルのurlを記述するためのserviceLocationAttribute Url属性をMPDに導入する。
　図１０は、serviceLocationAttributeUrl属性により指定されるServiceLocationファイルに格納されるServiceLocation要素のXML schemaの一例を示している。
　図１１は、図１０に示されたDeliverySystemAttributes以下のXML schemaの階層構造を図示したものである。
　L3L4L5Addressは、マルチキャストストリームの解決にSDPを利用しない場合の、FLUTEセッションストリーム、RTPマルチキャストストリームが転送されるIPアドレス"ipAddress"、ポート番号"port"、およびFLUTEのセッションID"transportSessionId"が格納される要素である。
　DeliverySystemIdentifierは、放送配信またはマルチキャスト配信にて採用されているチューニングパラメータのデータ構造のフォーマット識別子が格納される要素である。例えば、欧州にて採用されている地上放送による放送配信の場合には、"ID_DVB_T"が格納され、衛星放送に放送配信の場合には、"ID_DVB_S"が格納される。
　DeliverySystemDescriptorは、DeliverySystemIdentifierで識別される放送配信またはマルチキャスト配信にて規定されたチューニングパラメータのデータ構造(パラメタ自体)が格納される要素である。図１２は、欧州にて採用されている地上放送による放送配信に対応するチューニングパラメータのデータ構造の例である。なお、実際には、上記フォーマットに則ったバイト列をbase64等により文字列に変換してDeliverySystemDescriptorに記述する。
　RequiredQoSParameterは、チューニングに必要なQoSパラメータの識別名"parameterURI"、およびその条件値"requestdValue"としての"upperLimit(上限値)"、"lowerLimit(下限値)"、または"just(指定値)"を格納する要素である。
　RequiredQoSParameterの記述例について具体的に説明する。
　例えば、ストリーミングサービス一般に適用されるQoEパラメータとして、遅延、遅延揺らぎ、損失(エラー)、スループット等が存在する。このうち、スループットについて記述する場合には、
RequiredQoSParameter/@parameterURI=urn:DownLinkThroughput(下りスループットを示すユニークな識別子)と記述し、条件値としてその下限値を指定するときは、
RequiredQoSParameter/requiredValue/@lowerLimit="3Mbps"（下りスループットの下限値3Mbpsとの意味）と記述する。
　また例えば、放送を受信する場合や、Wi-Fi等無線LANを介してストリームを受信する場合の放送や携帯電話の端末の物理層信号品質を表すパラメータには、代表的なものとして、電波の強さに関するものと、ビット誤り率(BER)に関するものが存在する。より具体的には、前者の例としては、搬送波対雑音比(CN比)、受信信号強度(RSSI)等がある。後者の例としては、リード・ソロモン(RS)等の誤り訂正処理(放送/通信方式によって異なる)前/後のビット誤り率(BER before/after RS)や、トランスポート・ブロックの誤り率(BLER)等がある。
　このうち、CN比について記述する場合には、
RequiredQoSParameter/@parameterURI=urn:CarrierToNoiseRatio(CN比を示すユニークな識別子)と記述し、条件値としてその下限値を指定するときには、
RequiredQoSParameter/requiredValue/@lowerLimit="10dB"（CN比の下限値10dBとの意味）
と記述する。
　また、条件値としてCN比をいくつかのクラス（例えば３クラス）に分類して評価するときには、
　レベル１("urn:CNclass1"で指定):１０-3以上（不良）
　レベル２("urn:CNclass2"で指定): １０-5以上、１０-3未満（良）
　レベル３("urn:CNclass3"で指定): １０-５未満（最良）
と定義した上で、
RequiredQoSParameter/@parameterURI=urn:CarrierToNoiseRatio(C/Nを示すユニークな識別子)と記述し、条件値として、
RequiredQoSParameter/requiredClass/＠class="urn:CNclass2"
RequiredQoSParameter/requiredClass/＠class="urn:CNclass3"
（CN比とクラス１またはクラス２が必要との意味）
と記述する。
　なお、QoSパラメータとしては、上述した例の他にも、図１３乃至図２１に挙げるパラメータを記述することができる。
　図１３は、DVB衛星放送／ケーブルテレビのQoSパラメータの例である。図１４は、DVBケーブルテレビのQoSパラメータの例である。図１５は、DVB衛星放送のQoSパラメータの例である。図１６は、地上放送(DVB-T)のQoSパラメータの例である。図１３乃至図１６に示されたQoSパラメータの例は、いずれもETSI TR 101 290 V1.2.1 (2001-05), "Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems"にて定義されているものである。
　図１７は、地上放送(DVB-T2)のQoSパラメータの例である。これらは、DVB BlueBook A14-2 (07/12), "Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems; Amendment for DVB-T2 Systemにて定義されているものである。
　図１８は、ケーブルテレビ(DVB-C2)のQoSパラメータの例である。これらは、DVB BlueBook A14-3 (03/13), "Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems; Amendment for DVB-C2 System"にて定義されているものである。
　図１９は、その他の地上放送のQoSパラメータの例である。これらは、NorDig Unified ver2.4にて定義されているものである。
　図２０は、３Ｇ携帯電話機(UTRA FDD)端末用のQoSパラメータの例である。これらは、ETSI TS 125 215 V11.0.0 (2012-11); "Universal Mobile Telecommunications System (UMTS); Physical layer; Measurements (FDD) (3GPP TS 25.215 version 11.0.0 Release 11)"にて定義されているものである。
　図２１は、３Ｇ携帯電話機(UTRA TDD)端末用のQoSパラメータの例である。これらは、ETSI TS 125 225 V11.0.0 (2012-09); "Universal Mobile Telecommunications System (UMTS); Physical layer; Measurements (TDD) (3GPP TS 25.225 version 11.0.0 Release 11)"にて定義されているものである。
　図２２は、LTE (E-UTRA)端末用のQoSパラメータの例を示す図である。これらは、ETSI TS 136 214 V11.1.0 (2013-02); "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; Measurements (3GPP TS 36.214 version 11.1.0 Release 11)"にて定義されているものである。
［ストリーミングプロトコルスタックについて］
　上述したServiceLocation/DeliverySystem要素に格納される情報によりチューンされたMPEG2-TSストリーム上に転送されるIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリーム上では、RTPまたはFLUTEプロトコルによりファイル群が運ばれる。
　図２３は、IPパケットストリーム上で運ばれるファイル群のストリーミングプロトコルスタックを示している。
　RTPは、IPパケット上にリアルタイム(同期型)ストリームを転送するプロトコルである。FLUTEプロトコルは、IPパケット上にファイルを転送するプロトコルであり、それぞれ同図Ａまたは同図Ｂに示されるように階層的構成される。ここで、MACはリンク層プロトコルの総称であり、放送系ではGSE、TLV等が相当する。
［FDTの拡張］
　FLUTEプロトコルでは、同一のTOIを有する全てのファイルが受信された段階で初めて、Content-LocationのURLにより指定されるファイルとしてそれらに対してアクセスが可能となる。したがって、映画などのVoDコンテンツのように再生時間が長く１つのファイルのサイズが非常に大きい場合には、そのファイル全体が受信側で再構成されてアクセスできるようになるまでに、ある程度の時間が必要となる。
　これに対して、DASHを利用したストリーミングにおいては、対象のVoDコンテンツのファイルのサイズが大きくても、個々のHTTPリクエストのmediaRange指定によりファイルの一部をセグメント単位で取得、再生することができる。したがって、放送配信またはマルチキャスト配信のIPマルチキャストストリームによりFLUTE転送されるファイルについても同様にセグメントの単位で取得、再生できるようにすることが望ましい。
　ただし、現在規定されているFDTのContent-Location要素では、MPDのBaseURL＋SegmentURL mediaRangeのシーケンスのように、ファイルの一部を表現することができない。そこで、FDTについてもファイルの一部を表現できるように拡張する。
　すなわち、FDTに対して、Content-Locationと、さらにそのContent-Locationのurlで指定されるファイルの中のバイトレンジが指定できるように新たにrange属性を導入する。range属性のシンタクスには、range-specifier(RFC2616.section.14.35.1)の定義を適用する。range属性には、MPDのPeriod/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeをそのまま流用することができる。
　このようにFDTを拡張すれば、端末装置４０が取得、再生するストリーミングデータを、HTTP配信、放送配信、またはマルチキャスト配信の間で適応的、かつ、アドホックに切り替えることが可能となる。また、コンテンツのストリーミングサービスを運用する上での柔軟性を確保することが可能となる。
［コンテンツ供給システム２０の動作］
　次に、コンテンツ供給システム２０の動作について説明する。
　図２４は、コンテンツ供給システム２０のコンテンツ供給装置３０の動作を説明するフローチャートである。
　ステップＳ１において、コンテンツマネジメントサーバ３１は、受信側の端末装置４０に供給するための、同一内容のコンテンツであってビットレートなどが異なる複数のストリーミングデータをDASHセグメントストリーマ３２に供給する。また、コンテンツマネジメントサーバ３１は、ステップＳ２において、コンテンツのメタデータをDASH MPDサーバ３３に通知する。
　ストリーミングデータの供給を受けたDASHセグメントストリーマ３２は、ステップＳ１１において、コンテンツのストリーミングデータを時間的にピリオドに区切り、さらにセグメントに分割して、DASHストリームセグメントを生成し、それぞれをファイル化する。また、DASHセグメントストリーマ３２は、DASHストリームセグメントのファイルを、マルチキャスト配信のためにRTP/FLUTEサーバ３４に供給する。
　ステップＳ１２において、DASHセグメントストリーマ３２は、DASHストリームセグメントのファイルの供給元のアドレス（url情報）を、DASH MPDサーバ３３およびRTP/FLUTEサーバ３４に通知する。これ以降、DASHセグメントストリーマ３２は、ステップＳ１３において、端末装置４０からの要求に応じた、DASHストリームセグメントのファイルのインタネット１を介するHTTP配信を開始する。
　DASHストリームセグメントのファイルの供給元のアドレスの通知を受けたDASH MPDサーバ３３は、ステップＳ２１においてMPDを生成し、ステップＳ２２において、該MPDをRTP/FLUTEサーバ３４に供給し、そのFLUTEによる配信を依頼する。これ以降、ステップＳ２３において、DASH MPDサーバ３３は、端末装置４０からの要求に応じた、生成したMPDのインタネット１を介するHTTP配信を開始する。
　DASH MPDサーバ３３からMPDの供給を受けたRTP/FLUTEサーバ３４は、ステップＳ３１において、MPDに基づいて、拡張されたFDTを生成するとともに、DASHセグメントストリーマ３２から供給されているDASHストリームセグメントのファイルを格納したFLUTEパケット（またはRTPパケット）を生成する。
　ステップＳ３２において、RTP/FLUTEサーバ３４は、生成したFDTとFLUTEパケット（またはRTPパケット）を放送配信サーバ３５に供給し、それらの放送配信を依頼する。これ以降、所定のタイミングにおいて、ステップＳ３３として、RTP/FLUTEサーバ３４は、FDTとFLUTEパケット（またはRTPパケット）のインタネット１を介するマルチキャスト配信を開始する。
　FDTとFLUTEパケット（またはRTPパケット）の供給を受けた放送配信サーバ３５は、所定のタイミングにおいて、ステップＳ４１として、FLUTEパケット（またはRTPパケット）およびFDTを、放送網２を介して放送配信する。以上で、コンテンツ供給システム２０のコンテンツ供給装置３０の動作説明を終了する。
　次に、図２５は、端末装置４０がコンテンツを受信、再生するまで動作を説明するフローチャートである。
　コンテンツを受信、再生しようとする端末装置４０は、ステップＳ５１において、インタネット１を介してDASH MPDサーバ３３にアクセスし、MPDを要求する。この要求に応じ、ステップＳ６１において、DASH MPDサーバ３３は、インタネット１を介して端末装置４０にMPDをHTTP配信する。
　なお、インタネット１上のキャッシュサーバ３６が該MPDを保持している場合には、DASH MPDサーバ３３に代わってキャッシュサーバ３６が端末装置４０に該MPDをHTTP配信することもある。
　また、MPDがFLUTE配信されたり、放送網２を介して放送配信されたりする場合もあり、それを受信、取得するときにはステップＳ５１の処理は不要となる。
　MPDを取得した端末装置４０は、ステップＳ５２において、MPDのserviceLocationAttributeUrl属性に基づいてServiceLocationAttributeファイルを取得し、ServiceLocationAttributeファイルに記述されているRequiredQoSParameter要素を参照するとともに、自己の現在の通信状況をモニタリングして、取得する最適なストリームを選択する。
　ステップＳ５３において、端末装置４０は、MPDの、選択したストリームに対応するBaseURLとmediaRangeにもとづいてHTTPリクエストを発行して、DASHセグメントストリーマ３２にDASHストリームセグメントのファイルを要求する。この要求に応じ、ステップＳ７１において、DASHセグメントストリーマ３２は、対応するファイルをインタネット１を介して端末装置４０にHTTP配信する。なお、インタネット１上のキャッシュサーバ３６が該ファイルを保持している場合には、DASHセグメントストリーマ３２に代わってキャッシュサーバ３６が端末装置４０に該ファイルをHTTP配信することもある。
　ステップＳ５４において、端末装置４０は、HTTP配信された該ファイルを受信、再生する。この後、例えばインタネット１の通信環境が悪化したりした場合、端末装置４０は、受信するストリームを適応的に切り替えることができる。具体的には、ステップＳ５５として、例えば、放送配信サーバ３５がステップＳ８１として放送配信しているDASHストリームセグメントのファイルを受信、再生することができる。また、この後、HTTP配信されるファイルの受信、再生に戻ることもできる。
　なお、DASHセグメントストリーマ３２からHTTP配信される、よりビットのレートが低いストリームを受信、再生するように切替えたり、RTP/FLUTEサーバ３４がインタネット１を介してマルチキャスト配信するストリームに切替えたりすることも可能である。以上で、端末装置４０の動作説明を終了する。
　以上説明したように、本実施の形態においては、MPDのserviceLocationAttributeUrl属性に基づいて参照可能なServiceLocationAttributeファイルに、RequiredQoSParameter要素を設けたので、端末装置４０にて現況において最適なストリームにスイッチングすることが可能となった。
　ところで、上述した一連の処理を実行するコンテンツ供給装置３０、および端末装置４０は、それぞれをハードウェアにより構成する他、コンピュータがソフトウェアを実行することにより実現することもできる。このコンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
　図２６は、上述したコンピュータのハードウェアの構成例を示すブロック図である。
　このコンピュータ１００において、CPU（Central Processing Unit）１０１，ROM（Read Only Memory）１０２，RAM（Random Access Memory）１０３は、バス１０４により相互に接続されている。
　バス１０４には、さらに、入出力インタフェース１０５が接続されている。入出力インタフェース１０５には、入力部１０６、出力部１０７、記憶部１０８、通信部１０９、およびドライブ１１０が接続されている。
　入力部１０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１０７は、ディスプレイ、スピーカなどよりなる。記憶部１０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１０９は、ネットワークインタフェースなどよりなる。ドライブ１１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１１１を駆動する。
　以上のように構成されるコンピュータ１００では、CPU１０１が、例えば、記憶部１０８に記憶されているプログラムを、入出力インタフェース１０５およびバス１０４を介して、RAM１０３にロードして実行することにより、上述した一連の処理が行われる。
　コンピュータ１００（CPU１０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インタネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
　コンピュータ１００では、プログラムは、リムーバブルメディア１１１をドライブ１１０に装着することにより、入出力インタフェース１０５を介して、記憶部１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１０９で受信し、記憶部１０８にインストールすることができる。その他、プログラムは、ROM１０２や記憶部１０８に、あらかじめインストールしておくことができる。
　なお、コンピュータ１００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであってもよい。
　本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
　本開示は以下のような構成もとることができる。
（１）
　適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置において、
　前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、
　供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部と
　を備えるコンテンツ供給装置。
（２）
　前記メタファイル生成部は、前記メタファイルとして拡張されたMPDを生成する
　前記（１）に記載のコンテンツ供給装置。
（３）
　前記異なる複数のネットワークは、インタネット、地上放送網、衛星放送網、ケーブルテレビ放送網、モバイル放送網、または無線LANのうちの少なくとも一つを含む
　前記（１）または（２）に記載のコンテンツ供給装置。
（４）
　前記メタファイルは、前記ネットワークを介したHTTP配信、FLUTE配信、または放送配信により、前記受信側に供給される
　前記（１）から（３）のいずれかに記載のコンテンツ供給装置。
　２０　コンテンツ供給システム，　３０　コンテンツ供給装置，　３１　コンテンツマネジメントサーバ，　３２　DASHセグメントストリーマ，　３３　DASH MPDサーバ，　３４　FLUTEサーバ，　３５　放送配信サーバ，　端末装置４０，　１００　コンピュータ，　１０１　CPU

Claims (7)

  1. 　適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置において、
    　前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、
    　供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部と
    　を備えるコンテンツ供給装置。
  2. 　前記メタファイル生成部は、前記メタファイルとして拡張されたMPDを生成する
    　請求項１に記載のコンテンツ供給装置。
  3. 　前記異なる複数のネットワークは、インタネット、地上放送網、衛星放送網、ケーブルテレビ放送網、モバイル放送網、または無線LANのうちの少なくとも一つを含む
    　請求項２に記載のコンテンツ供給装置。
  4. 　前記メタファイルは、前記ネットワークを介したHTTP配信、FLUTE配信、または放送配信により、前記受信側に供給される
    　請求項２に記載のコンテンツ供給装置。
  5. 　適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、
    　前記コンテンツ供給装置による、
    　　前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給ステップと、
    　　供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成ステップと
    　を含むコンテンツ供給方法。
  6. 　適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンピュータを、
    　前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、
    　供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部と
    　して機能させるプログラム。
  7. 　適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信する端末装置とから成るコンテンツ供給システムにおいて、
    　前記コンテンツ供給装置は、
    　　前記複数のストリーミングデータを、異なる複数のネットワークを介して前記端末装置に供給する供給部と、
    　　供給される前記複数のストリーミングデータを前記端末装置が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部とを備え、
    　前記端末装置は、
    　　取得した前記メタファイルに基づいて前記マニフェストファイルを取得し、前記マニフェストファイルに記述されている前記QoSパラメータとその条件値に基づいて、受信するストリーミングデータを選択する
    　コンテンツ供給システム。
PCT/JP2014/063794 2013-06-06 2014-05-26 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム WO2014196392A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US14/893,475 US10212208B2 (en) 2013-06-06 2014-05-26 Content supply device, content supply method, program, and content supply system
EP14808290.2A EP3007458A4 (en) 2013-06-06 2014-05-26 CONTENT PROVIDING DEVICE, CONTENT PROVIDING METHOD, PROGRAM, AND CONTENT PROVIDING SYSTEM
CN201480030652.8A CN105247882A (zh) 2013-06-06 2014-05-26 内容提供设备、内容提供方法、程序和内容提供系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2013119511A JP2014239278A (ja) 2013-06-06 2013-06-06 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JP2013-119511 2013-06-06

Publications (1)

Publication Number Publication Date
WO2014196392A1 true WO2014196392A1 (ja) 2014-12-11

Family

ID=52008042

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/063794 WO2014196392A1 (ja) 2013-06-06 2014-05-26 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム

Country Status (5)

Country Link
US (1) US10212208B2 (ja)
EP (1) EP3007458A4 (ja)
JP (1) JP2014239278A (ja)
CN (1) CN105247882A (ja)
WO (1) WO2014196392A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10637948B2 (en) * 2013-10-28 2020-04-28 Saturn Licensing Llc Content supply apparatus, content supply method, program, terminal apparatus, and content supply system
US10129308B2 (en) * 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data
WO2017058437A1 (en) * 2015-09-30 2017-04-06 Apple Inc. Synchronization of media rendering in heterogeneous networking environments
US9788033B1 (en) * 2016-06-29 2017-10-10 Cisco Technology, Inc. Secure differential insertion of secondary content
WO2018173874A1 (ja) * 2017-03-24 2018-09-27 ソニー株式会社 コンテンツ提供システムおよびコンテンツ提供方法、並びにプログラム
CN113329244B (zh) * 2017-09-30 2022-07-22 华为技术有限公司 业务传输方法和装置
US11438282B2 (en) * 2020-11-06 2022-09-06 Khoros, Llc Synchronicity of electronic messages via a transferred secure messaging channel among a system of various networked computing devices

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012096372A1 (ja) * 2011-01-14 2012-07-19 シャープ株式会社 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造
WO2012096353A1 (ja) * 2011-01-12 2012-07-19 シャープ株式会社 再生装置、再生装置の制御方法、生成装置、生成装置の制御方法、記録媒体、データ構造、制御プログラム、及び該プログラムを記録した記録媒体
JP2013038766A (ja) * 2011-07-12 2013-02-21 Sharp Corp 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9160779B2 (en) * 2011-06-30 2015-10-13 Qualcomm Incorporated Dynamic adaptive streaming proxy for unicast or broadcast/multicast services
KR20130005873A (ko) 2011-07-07 2013-01-16 삼성전자주식회사 방송 시스템에서 컨텐츠 수신 방법 및 장치
US20140219088A1 (en) * 2011-09-30 2014-08-07 Ozgur Oyman Quality of experience enhancements over wireless networks
KR101874629B1 (ko) * 2011-10-21 2018-07-05 프라운호퍼 게젤샤프트 쭈르 푀르데룽 데어 안겐반텐 포르슝 에. 베. 서버로부터 클라이언트로 미디어 콘텐츠를 전달하기 위한 라디오 리소스 관리 개념
US9088583B2 (en) * 2011-10-31 2015-07-21 Interdigital Patent Holdings, Inc. Method and apparatus for enabling multimedia synchronization
US9712891B2 (en) * 2011-11-01 2017-07-18 Nokia Technologies Oy Method and apparatus for selecting an access method for delivery of media
WO2013100968A1 (en) * 2011-12-28 2013-07-04 Intel Corporation Video adaptation for content-aware wireless streaming
US9125073B2 (en) * 2012-08-03 2015-09-01 Intel Corporation Quality-aware adaptive streaming over hypertext transfer protocol using quality attributes in manifest file
US9332051B2 (en) * 2012-10-11 2016-05-03 Verizon Patent And Licensing Inc. Media manifest file generation for adaptive streaming cost management
JP6239629B2 (ja) * 2012-10-26 2017-11-29 インテル コーポレイション ビデオ方位に基づくマルチメディア適応

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012096353A1 (ja) * 2011-01-12 2012-07-19 シャープ株式会社 再生装置、再生装置の制御方法、生成装置、生成装置の制御方法、記録媒体、データ構造、制御プログラム、及び該プログラムを記録した記録媒体
WO2012096372A1 (ja) * 2011-01-14 2012-07-19 シャープ株式会社 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造
JP2013038766A (ja) * 2011-07-12 2013-02-21 Sharp Corp 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems", ETSI TR 101 290 V1.2.1, May 2001 (2001-05-01)
"DVB BlueBook A14-3 (03/13", article "Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems; Amendment for DVB-C2 System"
"LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; Measurements (3GPPTS 36.214 version 11.1.0 Release 11", ETSI TS 136 214 V11.1.0, February 2013 (2013-02-01)
"Universal Mobile Telecommunications System (UMTS); Physical layer; Measurements (FDD) (3GPP TS 25.215 version 11.0.0 Release 11", ETSI TS 125 215 VII.0.0, November 2012 (2012-11-01)
"Universal Mobile Telecommunications System (UMTS); Physical layer; Measurements (TDD) (3GPP TS 25.225 version 11.0.0 Release 11", ETSI TS 125 225 V11.0.0, September 2012 (2012-09-01)
See also references of EP3007458A4

Also Published As

Publication number Publication date
US20160134680A1 (en) 2016-05-12
EP3007458A1 (en) 2016-04-13
JP2014239278A (ja) 2014-12-18
US10212208B2 (en) 2019-02-19
CN105247882A (zh) 2016-01-13
EP3007458A4 (en) 2016-12-07

Similar Documents

Publication Publication Date Title
JP6348251B2 (ja) 端末装置、受信方法、およびプログラム
US9942619B2 (en) Content supply device, content supply method, program, and content supply system
WO2014196392A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
US10749919B2 (en) Reception device, reception method, transmission device, and transmission method for distributing signaling information
US10165035B2 (en) Content supplying device, content supplying method, program, and content supplying system
WO2016136489A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
WO2014208377A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JP6466850B2 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015041071A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
CN109219962B (zh) 接收装置、接收方法、再现装置、再现方法、供应装置、供应方法以及程序
WO2015045917A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015029768A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム

Legal Events

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

Ref document number: 14808290

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14893475

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2014808290

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE