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

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

Info

Publication number
WO2014188886A1
WO2014188886A1 PCT/JP2014/062488 JP2014062488W WO2014188886A1 WO 2014188886 A1 WO2014188886 A1 WO 2014188886A1 JP 2014062488 W JP2014062488 W JP 2014062488W WO 2014188886 A1 WO2014188886 A1 WO 2014188886A1
Authority
WO
WIPO (PCT)
Prior art keywords
rtp
http
segment
broadcast
multicast
Prior art date
Application number
PCT/JP2014/062488
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 EP14800786.7A priority Critical patent/EP3001690A4/en
Priority to CN201480028025.0A priority patent/CN105210372B/zh
Priority to US14/891,023 priority patent/US9942619B2/en
Publication of WO2014188886A1 publication Critical patent/WO2014188886A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/643Communication protocols
    • H04N21/6437Real-time Transport Protocol [RTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/633Control signals issued by server directed to the network components or client
    • H04N21/6332Control signals issued by server directed to the network components or client directed to client
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/64Addressing
    • H04N21/6405Multicasting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/64Addressing
    • H04N21/6408Unicasting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/643Communication protocols
    • H04N21/64322IP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84Generation or processing of descriptive data, e.g. content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85Assembly of content; Generation of multimedia applications
    • H04N21/854Content authoring
    • H04N21/85406Content authoring involving a specific file format, e.g. MP4 format

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 has prepared a system capable of supplying a plurality of streams having the same content but different in image quality and angle of view size, and the reception side depends on the communication environment of the Internet and the capability and state of the reception side. The best stream can be switched and viewed.
  • MPD Media Presentation Description
  • an address representing a server of a supply source of chunked streaming data (media data such as Audio / Video / Subtitle) is described.
  • the receiving side can access the server based on the url information and can acquire and reproduce streaming data to be transmitted by HTTP.
  • FIG. 1 shows an example of the configuration of a content supply system for streaming content based on DASH.
  • the content supply system 20 comprises a content management server 21 for supplying content, a DASH segment streamer 22 and a DASH MPD server 23, and a DASH client 30 for receiving and 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, in response to a request from the receiving DASH client 30, the DASH segment streamer 22 unicasts a segmented streaming data file to the DASH client 30 via the Internet 11 as an HTTP server.
  • the DASH MPD server 23 generates an MPD in which an address or the like of the DASH segment streamer 22 which is a supply source of the segmented streaming data file is described. Also, in response to a request from the receiving DASH client 30, the DASH MPD server 23 unicasts the MPD to the DASH client 30 via the Internet 11 as an HTTP server.
  • the DASH client 30 on the receiving side receives and reproduces content, accesses the DASH segment streamer 22 as an HTTP server based on the MPD acquired from the DASH MPD server 23, and divides the segmented streaming data file Receive, play.
  • a cache server may be provided on the Internet 11 to cache MPDs transmitted in unicast, segmented streaming data files, etc., and substitute the operation of the DASH segment streamer 22 or the DASH MPD server 23 in some cases.
  • DASH implements an adaptive streaming technology that supplies content by unicast transmission over HTTP.
  • 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.
  • a payload format that can be stored as it is in an RTP packet without breaking the box structure of fragmented MP4, which is a content stream chunk to be controlled by DASH, is not defined.
  • 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 storing the segment file as it is in an RTP packet, and transmitting the RTP packet by at least one of multicast and broadcast by RTP, and the segment file transmitted by unicast by HTTP
  • a metafile generation unit which generates a metafile describing a temporal correspondence with the segment file transmitted by at least one of multicast and broadcast by RTP, and supplies the metafile to the receiving side.
  • the streaming data of the content may be fragmented MP4, and the RTP transmission unit stores the segment file in the RTP packet while maintaining the box structure of the fragmented MP4, and multicasts or broadcasts the RTP packet by RTP. And at least one of them can be sent.
  • the RTP transmission unit may describe, at a time stamp field of an RTP header of the RTP packet, a transmission time of a leading bit at the time of transmission of the RTP packet.
  • the RTP transmission unit may describe, in an RTP payload of the RTP packet, information indicating a mode of the RTP payload and information indicating a boundary of a segment, and may arrange an NAL unit in payload data.
  • the RTP transmission unit may further arrange, in the RTP payload of the RTP packet, both the Initialization Segment and Media Segment metadata specified by the MPEG-DASH or the Media Segment metadata. Or, both of the Initialization Segment and the metadata of the Media Segment may not be arranged.
  • 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 storing the segment file as it is in RTP packet, and transmitting the RTP packet by at least one of multicast and broadcast by RTP, and HTTP Metafile that describes the temporal correspondence between the segment file unicast transmitted by the device and the segment file transmitted by at least one of multicast and broadcast by RTP It generates, and a meta file generating step of supplying to the receiving side.
  • 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 transmitting unit an RTP transmitting unit which stores the segment file as it is in an RTP packet and transmits the RTP packet by at least one of multicast and broadcast by RTP, the segment file which is unicast transmitted by HTTP, and multicast by RTP Or, it generates a metafile describing the correspondence in time with the segment file transmitted by at least one of broadcast and functions as a metafile generator to be supplied to the receiver.
  • streaming data is filed for each segment, and a segment file obtained as a result is unicast transmitted by HTTP, the segment file is stored as it is in an RTP packet, and the RTP packet is RTP Transmitted by multicast and / or broadcast. Also, a metafile describing a temporal correspondence 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, stores the segment file as it is in an RTP packet, and multicasts or broadcasts the RTP packet by RTP And the segment file transmitted by unicast by HTTP, and the segment transmitted by multicast or broadcast by RTP. It generates a meta file describing the temporal correspondence between the file includes 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.
  • a content supply system seamlessly switches each content stream of unicast transmission by HTTP, multicast transmission by RTP, or broadcast transmission by RTP when a content receiving / playing side receives content. It is something that can be done.
  • 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.
  • the payload format is defined so that it can be stored as it is in RTP packets more easily, that is, without breaking the box structure of fragmented MP4, which is a content stream chunk to be controlled by DASH.
  • 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 on the side of supplying content, and a large number of DASH clients 70 on the side of receiving and viewing the content.
  • the DASH client 70 can be connected to the content supply device 60 via the Internet 11, and can receive content to be unicast transmitted by HTTP. Also, 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 broadcasting network 12 includes a mobile broadcasting network such as MBMS (Multimedia Broadcast and Multicast Service) as well as a television broadcasting 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 / It has a multicast (BC / MC) service provider 68, which are interconnected via the Internet 11 and configured.
  • BC / MC broadcast / multicast
  • the content management server 61 manages content (including live broadcast content) to be supplied to the DASH client 70, and generates a plurality of streaming data with different bit rates from the content of the same content to the DASH segment streamer 62. Supply.
  • 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 divides streaming data of content into periods in time, and further divides into segments, and file and hold the content in segments. And notifies the DASH MPD server 63 of an address indicating the source of the file.
  • 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 be referred to when the DASH client 70 acquires 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, in response to a request from the DASH proxy server 64, the DASH MPD server 63 supplies the generated MPD.
  • 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 multicasted 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 sends the rewritten MPD to the DASH client 70. Also, the DASH client proxy 67 supplies the rewritten MPD to the broadcast / multicast service provider 68 to cause multicast transmission by FLUTE.
  • the DASH client proxy 67 acquires a segment of content to be unicast transmitted from the DASH segment streamer 62, stores the acquired segment as it is in the payload of the RTP packet without breaking the box structure, and broadcast / multicast service provider 68 to perform multicast transmission and broadcast transmission via the broadcast network 12 by RTP.
  • 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 the RTP packet in which the segment of the content is stored as it is, through the broadcast network 12.
  • 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 consisting of information on streaming data having the same content and 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 DASH client 70 can switch, receive, and reproduce appropriate stream data according to the communication environment, the decoding capability of the device, or the like.
  • FIG. 7 shows in detail the structure below the MPD Representation.
  • the address of the DASH segment streamer 62 as the source of the file in which the segment of content is stored is described. Specifically, when a plurality of segments are individually filed, the sequence of the address (url information) of each file is described. When a plurality of segments are stored together in one file, in addition to the address (Base URL) of the file, a sequence of the range (mediaRange) of each segment in the file is described. Note that FIG. 7 shows the latter example.
  • 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" indicates that the byte range from the 795th byte to the 83596th byte in the file is the first segment. .
  • MPD / Period / AdaptationSet / Representation / SegmentList / SegmentURL / @ mediaRange "" 83597-166046 "means that the byte range from byte 83597 to byte 166046 in the file is the second segment. It shows.
  • 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
  • stream data of segmented content is supplied to the DASH client 70 on the receiving side by unicast transmission by HTTP, multicast transmission by RTP, and broadcast transmission by RTP. Furthermore, these are seamlessly switched and received and reproduced by 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 identifying a section of a segment stream transmitted by multicast and broadcasted by RTP as a switching target of a segment unicasted 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 first segment consisting of data from the byte range 795th byte to the 83596th byte of the file unicast transmitted by HTTP is the segment stream transmitted by multicast transmission and broadcast transmission by RTP. It shows that the sections represented by 19961108 T143720.25Z to 19961108 T143730.25Z correspond.
  • the segment stream from multicast transmitted and broadcasted by RTP is transmitted from 19961108T143730.25Z. It shows that the section represented by 19961108T143740.25Z corresponds.
  • FIG. 10 shows an example of the XML schema of the ServiceLocationAttribute file specified by the serviceLocationAttributeUrl attribute.
  • FIG. 11 shows the ServiceLocation element newly introduced to the MPD.
  • 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.
  • a of FIG. 13 shows the hierarchical structure of the protocol in this case.
  • 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.
  • FIG. 13B shows the hierarchical structure of the protocol in this case.
  • FIG. 14 shows the data structure of an RTP packet.
  • the RTP packet is composed of an RTP header 81 and an RTP payload 82.
  • the RTP header 81 has fields of payload type (PT) 83, sequence number (SN) 84, and time stamp (TS) 85.
  • PT payload type
  • SN sequence number
  • TS time stamp
  • the payload type 83 describes information for indicating the type of content stored in the RTP payload 82.
  • information for indicating the type of codec of the content stored in the RTP payload 82 is described. Specifically, when AVC fragmented MP4 is stored in RTP payload 82, “AVC fragmented MP4 over RTP” is described, and when HEVC fragmented MP4 is stored in RTP payload 82, “HEVC fragmented MP4 over RTP” is Described.
  • the sequence number 84 describes the sequence number of RTP packets transmitted continuously. The presence or absence of a packet loss is detected by the sequence number.
  • the time stamp 85 differs from the conventional operation of the time stamp in the RTP packet, the transmission time of the first bit at the time of transmission of the RTP packet has a short format of 32 bits (clause 6 of IETF RFC 5905, NTP version 4) Default) NTP timestamp value is described.
  • the conventional operation of the time stamp in the RTP packet indicates that the time stamp of the sampling time of the first byte of the payload data of the RTP payload 82 is described.
  • the NTP timestamp value described in the timestamp 85 is mainly used for jitter removal on transfer, and is not used for presentation time control as in the conventional operation of the timestamp.
  • a time stamp value derived from the box structure of the fragmented MP 4 is used for presentation time control.
  • FIG. 15 shows the format of the RTP payload 82 when the payload type 83 is "AVC fragmented MP4 over RTP", that is, when the AVC fragmented MP4 is stored in the RTP payload 82.
  • FIG. 6A shows the format of the RTP payload 82 of the first mode.
  • RTP payload 82 in the first mode is composed of PayloadMode 91, SegmentBoundary 92, dash (ftyp) 93, moov 94, msix (styp) 95, sidx 96, moof 97, mdat header (mdat-h) 98 and AVC over RTP payload 99 .
  • PayloadMode 91 is a 1-byte value for representing a mode. In the present case, the value 1 is described to indicate that the mode is the first mode.
  • SegmentBoundary 92 a 1-byte identifier is described to represent the boundary of the segment of content stored in the RTP packet. If the RTP packet contains a NAL (Network Abstraction Layer) unit at the beginning of the segment of the content, 1 is stored, if the last NAL unit of the segment is stored, 3 otherwise. 2 is described.
  • NAL Network Abstraction Layer
  • styp brand name misx box and sidx box which are metadata of Media Segment in which chunks of media data in DASH are stored Only header information not including media data of moof box and mdat box is arranged.
  • the moof 97 stores information about only one track.
  • the DASH client 70 derives, as an RTP Timestamp, a CompositionTime indicating a sampling time of the first byte of Payload data based on the information stored in the moof 97.
  • AVC over RTP payload 99 a divided leading NAL unit, one NAL unit, according to RTP Payload Format for H.264 Video specified in rfc (request for comment) 3984 Or multiple NAL units are stored.
  • FIG. 7B shows the format of the RTP payload 82 of the second mode.
  • the RTP payload 82 of the second mode is composed of PayloadMode 91, SegmentBoundary 92, msix (styp) 95, sidx 96, moof 97, and AVC over RTP payload 99.
  • PayloadMode 91 describes a value 2 indicating that it is the second mode. Also, in the AVC over RTP payload 99, the divided leading NAL unit, one NAL unit, or a plurality of NAL units are stored according to the RTP payload format specification defined in rfc 3984.
  • FIG. 6C shows the format of the RTP payload 82 of the third mode.
  • the RTP payload 82 of the third mode is composed of PayloadMode 91, SegmentBoundary 92, and AVC over RTP payload 99.
  • PayloadMode 91 describes a value 3 indicating that the mode is the third mode. Also, in AVC over RTP payload 99, divided NAL units (except for the first one), one NAL unit, or multiple NAL units are stored according to the RTP payload format specification defined in rfc 3984. .
  • FIG. 16 shows the format of the RTP payload 82 when the payload type 83 is "HEVC fragmented MP4 over RTP", that is, when the RTP payload 82 stores HEVC fragmented MP4.
  • FIG. 6A shows the format of the RTP payload 82 of the first mode.
  • the RTP payload 82 in the first mode is composed of PayloadMode 101, SegmentBoundary 102, dash (ftyp) 103, moov 104, msix (styp) 105, sidx 106, moof 107, mdat header (mdat-h) 108 and HEVC over RTP payload 109 .
  • PayloadMode 101 is a 1-byte value for representing a mode. In the present case, the value 1 is described to indicate that the mode is the first mode.
  • SegmentBoundary 102 a 1-byte identifier is described to indicate the boundary of the segment of content stored in the RTP packet. If the RTP packet contains the first NAL unit of the content segment, 1 is described. If the last NAL unit of the segment is stored, 3 is described. Otherwise, 2 is described. Ru.
  • ftyp brand name dash box
  • moov box which are initialization segments in which initialization information such as a decoder in DASH is stored are arranged.
  • the header 98 of msix (styp) 105, sidx 106, moof 107, and mdat stores metadata styp (brand names msix) box, sidx box, and moof of Media Segment in which chunks of media data in DASH are stored. Only header information that does not include box and mdat box media data is placed.
  • the moof 107 stores information on only one track. Note that the DASH client 70 derives, as an RTP Timestamp, a CompositionTime representing a sampling time of the first byte of Payload data based on the information stored in the moof 107.
  • the divided first NAL unit according to RTP Payload Format for High Efficiency Video Coding specified in draft-schierl-payload-rtp-h265-01, One NAL unit or multiple NAL units are stored.
  • FIG. 7B shows the format of the RTP payload 82 of the second mode.
  • the RTP payload 82 of the second mode is composed of PayloadMode 101, SegmentBoundary 102, msix (styp) 105, sidx 106, moof 107, and HEVC over RTP payload 109.
  • PayloadMode 101 describes a value 2 indicating that it is the second mode.
  • HEVC over RTP payload 109 is divided into a leading NAL unit, one NAL unit, or a plurality of NAL units according to the RTP payload format specification defined in draft-schierl-payload-rtp-h265-01. NAL units are stored.
  • FIG. 6C shows the format of the RTP payload 82 of the third mode.
  • the RTP payload 82 of the third mode is configured of PayloadMode 101, SegmentBoundary 102, and HEVC over RTP payload 109.
  • PayloadMode 101 describes a value 3 indicating that the mode is the third mode.
  • NAL units except for the first one
  • one NAL according to the RTP payload format specification defined in draft-schierl-payload-rtp-h265-01.
  • a unit or multiple NAL units are stored.
  • FIG. 17 shows four examples of combination patterns of formats (first to third modes) that can be adopted for the RTP payload 82 of RTP packets transmitted continuously.
  • the first mode is adopted for the RTP payloads 82 of all RTP packets transmitted continuously.
  • the first RTP packet to the third RTP packet are one segment
  • the fourth RTP packet and the fifth RTP packet are one segment. .
  • a first mode, a second mode, a second mode are sequentially transmitted to the RTP payload 82 of the first to fifth RTP packets transmitted successively.
  • the first mode, and the second mode are adopted.
  • the first RTP packet to the third RTP packet are one segment
  • the fourth RTP packet and the fifth RTP packet are one segment. .
  • the third combination pattern shown in FIG. 6C is the first mode, the second mode, the third mode in order of the RTP payload 82 of the first to fifth RTP packets transmitted successively. , The first mode, and the third mode are adopted.
  • the first RTP packet to the third RTP packet are one segment
  • the fourth RTP packet and the fifth RTP packet are one segment. .
  • the fourth combination pattern shown in FIG. 6D is the first mode, the third mode, the third mode in order of the RTP payload 82 of the first to fifth RTP packets transmitted successively. , Third mode and third mode are adopted. In the case of the fourth combination pattern, the first RTP packet to the fifth RTP packet are one segment.
  • the combination pattern is not limited to that illustrated, but is optional, but the first mode is adopted for the RTP payload 82 of one or more of one or more RTP packets in which one segment is stored. There is a need.
  • FIG. 18 is a flowchart for explaining 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 it has started unicast transmission by HTTP.
  • the DASH MPD server 63 generates an MPD based on the file segment address notified of from the DASH segment streamer 62 and starts unicast transmission by HTTP.
  • 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 the transmission of MPD. It is assumed that the DASH client 70 knows in advance the address of the DASH MPD server 63.
  • step S11 the DASH MPD server 63 unicasts the MPD to the DASH client 70 via HTTP via the Internet 11.
  • 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.
  • an HTTP request is issued based on MPD's BaseURL and mediaRange to request the DASH segment streamer 62 for a DASH stream segment file.
  • the DASH segment streamer 62 unicasts 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 communication band of the Internet 11 in step S2, and from now on, unicast reception via the Internet 11 is likely to be unstable, and the DASH client 70 itself broadcasts. If multicast transmission or broadcast transmission of content via the network 12 can be received, the acquired MPD is transmitted to the MPD configurator 65, and rewriting of the MPD is requested.
  • the MPD configurator 65 In response to the MPD rewrite request from the DASH client 70, in step S21, the MPD configurator 65 confirms the use status of the broadcast bearer and the multicast bearer resources with the broadcast / multicast resource manager 66. Furthermore, the utilization is determined in consideration of the cost for combining the broadcast bearer and the multicast bearer, and the broadcast / multicast resource manager 66 is requested to reserve the resource. After being notified from the broadcast / multicast resource manager 66 that the resource has 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 monitoring the rewritten MPD requests the broadcast / multicast provider 68 for 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.
  • the DASH client proxy 67 that has received the stream segment unicasted by HTTP from the DASH segment streamer 62 in step S33 does not remove the stream segment stored in the HTTP packet without removing the box structure of the RTP packet RTP.
  • the DASH client proxy 67 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 S3 When switching to a stream segment multicast or broadcasted via RTP via broadcast network 12, the process proceeds to step S5.
  • 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 broadcasted via the broadcast network 12 by RTP, in step S5, the DASH client 70 transmits a segment stream unicasted by HTTP based on the rewritten MPD. , Switch the reception and reproduction to a protocol-converted stream segment that is multicast or broadcasted by RTP.
  • 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.
  • FIG. 19 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 they have started unicast transmission via HTTP.
  • the DASH MPD server 63 generates an MPD based on the file segment address notified of from the DASH segment streamer 62 and starts unicast transmission by HTTP.
  • step S71 the DASH client 70 that is going to receive and reproduce content requests the DASH MPD server 63 for 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 for the MPD in step S81.
  • the DASH MPD server 63 responsive to the request from the MPD proxy server 64 unicasts the MPD to the MPD proxy server 64 by HTTP in step S 91.
  • 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, in consideration of the cost of combining the broadcast bearer and the multicast bearer, the use thereof is determined, and the broadcast / multicast resource manager 66 is requested to reserve the resource. After receiving the notification from the broadcast / multicast resource manager 66 that the resource has 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 S112 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.
  • the DASH client proxy 67 that has received the stream segment unicasted by HTTP from the DASH segment streamer 62 in step S113 does not remove the stream segment stored in the HTTP packet without removing the box structure of the RTP packet RTP.
  • the DASH client proxy 67 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.
  • the DASH client 70 has already acquired the rewritten MPD.
  • the DASH client 70 receives a unicast transmission via the Internet 11 or a multicast transmission or broadcast via the broadcast network 12 based on the state of the communication band of the Internet 11, its own receiving function, decoding function, etc. Select whether to receive transmissions.
  • 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 S72 when it is selected to perform reception and reproduction of a stream segment multicast-transmitted or broadcast-transmitted through the broadcast network 12 by RTP, the process proceeds to step S75.
  • 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.
  • a stream segment to be unicast-transmitted by HTTP can be stored as it is in an RTP packet without breaking the box structure, and can be multicast-transmitted or broadcast-transmitted. it can. Therefore, the content supply side can easily prepare an alternative path in DASH.
  • 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. 206 is a block diagram showing an example of the hardware configuration of the computer described above.
  • a central processing unit (CPU) 201 a read only memory (ROM) 202, and a random access memory (RAM) 203 are mutually connected by a bus 204.
  • CPU central processing unit
  • ROM read only memory
  • RAM random access memory
  • an input / output interface 205 is connected to the bus 204.
  • An input unit 206, an output unit 207, a storage unit 208, a communication unit 209, and a drive 220 are connected to the input / output interface 205.
  • the input unit 206 includes a keyboard, a mouse, a microphone and the like.
  • the output unit 207 includes a display, a speaker, and the like.
  • the storage unit 208 includes a hard disk, a non-volatile memory, and the like.
  • the communication unit 209 is configured of a network interface or the like.
  • the drive 220 drives removable media 211 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.
  • the CPU 201 loads the program stored in the storage unit 208 into the RAM 203 via the input / output interface 205 and the bus 204 and executes the program. A series of processing is performed.
  • the program executed by the computer 200 can be provided by being recorded on, for example, a removable medium 211 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 208 via the input / output interface 205 by attaching the removable media 211 to the drive 220.
  • the program can be received by the communication unit 209 via a wired or wireless transmission medium and installed in the storage unit 208.
  • the program can be installed in advance in the ROM 202 or the storage unit 208.
  • the program executed by the computer 200 may be a program that performs processing in chronological order according to the order described in the present specification, or necessary timing such as when calling is performed in parallel or in parallel.
  • the program may be a program to be processed in
  • the present disclosure can also have the following configurations.
  • An HTTP transmitting unit for converting the streaming data into segments and transmitting the resulting segment file by HTTP using HTTP
  • An RTP transmission unit which stores the segment file as it is in an RTP packet and transmits the RTP packet by at least one of multicast and broadcast by RTP
  • a metafile that describes the correspondence in time between the segment file unicasted by HTTP and the segment file transmitted by multicast and / or broadcast by RTP is a metafile that is supplied to the receiver
  • a content supply apparatus comprising: a generation unit (2)
  • the streaming data of the content is fragmented MP4,
  • the RTP transmission unit stores the segment file in the RTP packet while maintaining the fragmented MP4 box structure, and transmits the RTP packet by at least one of multicast and broadcast by RTP.

Landscapes

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

Abstract

 本開示は、DASHを拡張し、ユニキャスト送信、マルチキャスト送信またはブロードキャスト送信の受信、再生をシームレスにスイッチングすることができるようにするコンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関する。 コンテンツ供給装置は、前記ストリーミングデータのセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、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と称する)が知られている(例えば、非特許文献1を参照)。
 DASHでは適応型ストリーミング技術が実現されている。すなわち、コンテンツの供給側は、同一内容のコンテンツであって画質や画角サイズが異なる複数のストリームを供給できる体制を整えており、受信側はインターネットの通信環境や受信側の能力や状態に応じて最適なストリームをスイッチングして視聴することができるようにされている。
 DASHにおいては、受信側がストリームを適応的にスイッチングするための情報として、供給側から受信側にMPD(Media Presentation Description)と称されるメタファイルが供給される。MPDには、チャンク化されたストリーミングデータ(Audio/Video/Subtitle等のメディアデータ)の供給元のサーバを表すアドレス(url情報)が記述されている。
 受信側は、該url情報に基づいて該サーバにアクセスし、HTTP送信されるストリーミングデータを取得、再生することができる。
 図1は、DASHに基づいてコンテンツをストリーミング配信するコンテンツ供給システムの構成の一例を示している。
 該コンテンツ供給システム20は、コンテンツを供給する側のコンテンツマネジメントサーバ21、DASHセグメントストリーマ22、およびDASH MPDサーバ23、並びにコンテンツを受信、視聴する側のDASHクライアント30から構成される。なお、図示は省略するが、DASHクライアント30は多数存在するものとする。
 コンテンツマネジメントサーバ21は、受信側に供給するコンテンツを管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ22に出力する。
 DASHセグメントストリーマ22は、コンテンツのストリーミングデータを時間的にセグメントに分割してそれぞれをファイル化して保持し、そのアドレスをDASH MPDサーバ23に通知する。さらに、DASHセグメントストリーマ22は、受信側のDASHクライアント30からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルを、インターネット11を介してDASHクライアント30にユニキャスト送信する。
 DASH MPDサーバ23は、セグメント化されたストリーミングデータのファイルの供給元となるDASHセグメントストリーマ22のアドレスなどを記述したMPDを生成する。また、DASH MPDサーバ23は、受信側のDASHクライアント30からの要求に応じ、HTTPサーバとして該MPDをインターネット11を介してDASHクライアント30にユニキャスト送信する。
 受信側のDASHクライアント30は、コンテンツを受信、再生するものであり、DASH MPDサーバ23から取得するMPDに基づいてHTTPサーバとしてのDASHセグメントストリーマ22にアクセスし、セグメント化されたストリーミングデータのファイルを受信、再生する。
 なお、インターネット11上にキャッシュサーバを設け、ユニキャスト送信されるMPDやセグメント化されたストリーミングデータのファイルなどキャッシングし、DASHセグメントストリーマ22やDASH MPDサーバ23の動作を代行させることもある。
「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEI ELECTRONICS 2012.3.19
 上述したように、DASHではHTTPによるユニキャスト送信によりコンテンツを供給する適応的ストリーミング技術が実現されている。
 ただし、例えば、リアルタイムのスポーツ中継のコンテンツなどのように、数多くのDASHクライアント30が同時に取得、再生する可能性があるコンテンツを、DASHにより同時に多数に供給する場合、HTTPを用いているために、CDN(Contents Delivery Network)のサポートが必要となる。しかしながら、CDNのサポートを受けるとしても、そのコスト的な制約から既存の放送配信に匹敵する程のスケーラビリティを求めることはできない。
 ところで、コンテンツを同時に多数の受信側に供給するには、テレビジョン放送網やモバイルネットワークを介したマルチキャストベアラやブロードキャストベアラを利用する方法があり、これには一般的にRTPが用いられる。
 よって、受信側がマルチキャスト送信またはブロードキャスト送信されるコンテンツを受信、再生可能であれば、DASHにおける代替パスとしてそれらを用い、受信側で適応的にストリームを選択できるようにすることが望ましい。
 しかしながら、現状のDASHの仕様においては、コンテンツのストリーミングデータをHTTPによりユニキャスト送信することのみを想定しており、マルチキャストベアラやブロードキャストベアラの利用は想定していない。
 したがって、DASHのMPDには、HTTPによりユニキャスト送信されるDASHセグメントと、そのセグメント区間に対応するマルチキャストベアラまたはブロードキャストベアラ上のRTPによってストリーミングされるコンテンツ区間との対応関係を記述することができない。
 また、現状においては、DASHの制御対象となるコンテンツストリームチャンクであるfragmented MP4のbox構造を壊すことなくそのままRTPパケットに格納できるようなペイロードフォーマットが規定されていない。
 よって、現状のDASHの規格では、コンテンツのユニキャスト送信とマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングの実現が困難である。
 本開示はこのような状況に鑑みてなされたものであり、コンテンツのHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングを実現できるようにするものである。
 本開示の第1の側面であるコンテンツ供給装置は、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置において、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部とを備える。
 前記コンテンツのストリーミングデータはfragmented MP4とすることができ、前記RTP送信部は、前記セグメントファイルを前記fragmented MP4のbox構造を維持したまま前記RTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信することができる。
 前記RTP送信部は、前記RTPパケットのRTPヘッダのタイムスタンプフィールドに、前記RTPパケットの送信時の先頭のビットの送信時刻を記述することができる。
 前記RTP送信部は、前記RTPパケットのRTPペイロードに、前記RTPペイロードのモードを表す情報と、セグメントの境界を表す情報とを記述し、ペイロードデータにNALユニットを配置することができる。
 前記RTP送信部は、さらに、前記RTPパケットのRTPペイロードに、前記MPEG-DASH で規定されているInitialization SegmentとMedia Segmentのメタデータの両方を配置するか、前記Media Segmentのメタデータを配置するか、または前記Initialization Segmentと前記Media Segmentのメタデータの両方を配置しないようにすることができる。
 本開示の第1の側面であるコンテンツ供給方法は、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、前記コンテンツ供給装置による、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信ステップと、前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信ステップと、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成ステップとを含む。
 本開示の第1の側面であるプログラムは、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンピュータを、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部として機能させる。
 本開示の第1の側面においては、ストリーミングデータがセグメント毎にファイル化され、その結果得られるセグメントファイルがHTTPによりユニキャスト送信され、前記セグメントファイルがそのままRTPパケットに格納され、前記RTPパケットがRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される。また、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルが生成されて受信側に供給される。
 本開示の第2の側面であるコンテンツ供給システムは、MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信するクライアント装置とから成るコンテンツ供給システムにおいて、前記コンテンツ供給装置が、前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と備える。また、前記クライアント装置が、取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとを切り替えて受信、再生する。
 本開示の第1および第2の側面によれば、コンテンツのHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信またはブロードキャスト送信との間のシームレスなスイッチングを実現できる。
DASHを利用する従来のコンテンツ供給システムの構成の一例を示すブロック図である。 本開示を適用したコンテンツ供給システムの構成例を示すブロック図である。 コンテンツの時間的区切りを説明する図である。 MPDの構成を示す図である。 MPDにおけるPeriod以下の階層構造を示す図である。 時間軸上にMPDの構成を並べた図である。 MPDのRepresentation以下の詳細な構造を示す図である。 MPDの一例を示す図である。 書き換えられたMPDの一例を示す図である。 ServiceLocation要素のXML Schemaの一例を示す図である。 ServiceLocation要素のデータ構造を示す図である。 User Searvice Descriptionの一例を示す図である。 プロトコルの階層構造を示す図である。 RTPパケットのデータ構造を表す図である。 RTPパケットにAVC fragmented MP4を格納する場合の図である。 RTPパケットにHEVC Segmented MP4を格納する場合の図である。 RTPペイロードのフォーマットの組み合わせパターンの例を示す図である。 コンテンツ供給システムの第1の動作を説明するフローチャートである。 コンテンツ供給システムの第2の動作を説明するフローチャートである。 コンピュータの構成例を示すブロック図である。
 以下、本開示を実施するための最良の形態(以下、実施の形態と称する)について、図面を参照しながら詳細に説明する。
[コンテンツ供給システムの構成例]
 本開示の実施の形態であるコンテンツ供給システムは、コンテンツを受信、再生する側がコンテンツを受信するに際し、HTTPによるユニキャスト送信、RTPによるマルチキャスト送信、またはRTPによるブロードキャスト送信の各コンテンツストリームをシームレスにスイッチングできるようにするものである。
 具体的には、HTTPによりユニキャスト送信されるコンテンツストリームの区間を示すmediaRangeと、RTPによりマルチキャスト送信またはブロードキャスト送信されるコンテンツストリームの区間を示すrtspRangeとの対応関係を記述できるようにDASHにおけるMPDを拡張する。
 また、より容易に、すなわち、DASHの制御対象となるコンテンツストリームチャンクであるfragmented MP4のbox構造を壊すことなく、そのままRTPパケットに格納できるようペイロードフォーマットを規定する。
 図2は、本開示の実施の形態であるコンテンツ供給システムの構成例を示している。
 該コンテンツ供給システム50は、コンテンツを供給する側のコンテンツ供給装置60と、コンテンツを受信、視聴する側の多数のDASHクライアント70から構成される。
 DASHクライアント70は、インターネット11を介してコンテンツ供給装置60に接続することができ、HTTPによるユニキャスト送信されるコンテンツを受信できる。また、DASHクライアント70は、コンテンツ供給装置60から放送網12を介してマルチキャスト送信およびブロードキャスト送信されるコンテンツを受信できる。
 ここで、放送網12には地上波や衛星波などを用いるテレビジョン放送網などの他、MBMS(Multimedia Broadcast and Multicast Service)などのモバイルネットワークも含まれるものとする。
 コンテンツ供給装置60は、コンテンツマネジメントサーバ61、DASHセグメントストリーマ62、DASH MPDサーバ63、MPDプロキシサーバ64、MPDコンフィギュレータ65、ブロードキャスト/マルチキャスト(BC/MC)リソースマネージャ66、DASHクライアントプロキシ67、およびブロードキャスト/マルチキャスト(BC/MC)サービスプロバイダ68を有し、これらがインターネット11を介して相互に接続されて構成される。
 コンテンツマネジメントサーバ61は、DASHクライアント70に供給するためのコンテンツ(ライブ放送コンテンツを含む)を管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ62に供給する。
 DASHセグメントストリーマ62は、コンテンツのストリーミングデータを時間的に分割する。
 図3は、コンテンツの時間的な区切りを示している。すなわち、DASHセグメントストリーマ62は、図3に示されるように、コンテンツのストリーミングデータを時間的にピリオド(period)に区切り、さらにセグメント(segment)に分割して、コンテンツをセグメント単位でファイル化して保持し、該ファイルの供給元を示すアドレスをDASH MPDサーバ63に通知する。
 また、DASHセグメントストリーマ62は、DASHクライアント70からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルを、インターネット11を介してHTTP送信する(HTTPを用いてユニキャスト送信する)。
 DASH MPDサーバ63は、HTTPによりユニキャスト送信されるコンテンツをDASHクライアント70が取得するに際して参照するMPDを生成し、該MPDをDASHクライアント70からの要求に応じ、インターネット11を介してHTTP送信する。また、DASH MPDサーバ63は、DASHプロクシサーバ64からの要求にも応じて、生成したMPDを供給する。
 MPDプロキシサーバ64は、DASH MPDサーバ63からMPDを取得してMPDコンフィギュレータ65に供給する。
 MPDコンフィギュレータ65は、HTTPによりユニキャスト送信されるコンテンツと同一内容の、ブロードキャスト送信およびマルチキャスト送信されるコンテンツをDASHクライアント70が取得できるようにMPDを書き換える。
 ブロードキャスト/マルチキャストリソースマネージャ66は、ブロードキャストベアラおよびマルチキャストベアラのリソースの状況をMPDコンフィギュレータ65に通知する。
 DASHクライアントプロキシ67は、書き換えられたMPDをDASHクライアント70に送信する。また、DASHクライアントプロキシ67は、書き換えられたMPDをブロードキャスト/マルチキャストサービスプロバイダ68に供給してFLUTEによりマルチキャスト送信させる。
 さらに、DASHクライアントプロキシ67は、DASHセグメントストリーマ62からユニキャスト送信されるコンテンツのセグメントを取得し、取得したセグメントを、そのままbox構造を壊すことなくRTPパケットのペイロードに格納してブロードキャスト/マルチキャストサービスプロバイダ68に供給し、RTPにより放送網12を介してマルチキャスト送信およびブロードキャスト送信させる。
 ブロードキャスト/マルチキャストサービスプロバイダ68は、書き換えられたMPDを、FLUTEにより放送網12を介してマルチキャスト送信する。また、ブロードキャスト/マルチキャストサービスプロバイダ68は、コンテンツのセグメントがそのまま格納されたRTPパケットを、放送網12を介してマルチキャスト送信およびブロードキャスト送信する。
[MPDの概要]
 次に、DASHにおけるMPDの概要について図4および図5を参照して説明する。
 図4はMPDのデータ構成を示している。図5はMPDにおけるPeriod以下の階層構造を示している。
 MPDには、コンテンツ(Media)に関する情報がPeriod毎に区分され、各Periodには同一内容であってビットレートなどのストリーム属性が異なるストリーミングデータに関する情報からなる複数のRepresentationが用意されている。Representationには、Periodをさらに時間的に細分化したSegmentに関する情報が格納されている。
 図6は、時間軸上にMPDの構造を並べた状態を示している。
 同図から明らかなように、MPDにおいては、コンテンツの同一のSegmentに対して複数のRepresentationが存在している。よって、これらのうちのいずれかをDASHクライアント70が適応的に選択することにより、通信環境や自己のデコード能力などに応じて適切なストリームデータをスイッチングして受信、再生することができる。
 図7は、MPDのRepresentation以下の構造を詳細に示している。
 Representationには、コンテンツのセグメントが格納されているファイルの供給元となるDASHセグメントストリーマ62のアドレスが記述される。具体的には、複数のセグメントがそれぞれ個別にファイル化されている場合には、各ファイルのアドレス(url情報)のシーケンスが記述される。また、複数のセグメントがまとめて1個のファイルに格納されている場合には、該ファイルのアドレス(Base URL)に加えて、該ファイルにおける各セグメントの範囲(mediaRange)のシーケンスが記述される。なお、図7には、後者の例が示されている。
 図8は、図7に示されたRepresentation以下の構造をXML形式で記述した一例を示している。
 MPD/Period/AdaptationSet/Representation/BaseURLには、コンテンツの複数のセグメントが1個のファイルに格納されている場合の該ファイルの供給元のアドレスが記述される。同図の場合、”http://example.com/counter-10mn_avc_dash.mp4”が該ファイルのアドレスを示している。
 MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeには、該ファイルにおける、各セグメントのバイト範囲のシーケンスが記述される。
 したがって、DASHクライアント70が、ファイルのurlとして”http://example.com/counter-10mn_avc_dash.mp4”を指定するとともに、そのRangeヘッダにmediaRangeを指定してHTTPリクエストを発行すれば、目的のセグメントを取得することができる。
 例えば、MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange=”795-83596”は、該ファイルにおけるバイト範囲795バイト目から83596バイト目までが1つ目のセグメントであることを示している。同様に、次のMPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange=”83597-166046”は、該ファイルにおけるバイト範囲83597バイト目から166046バイト目までが2つ目のセグメントであることを示している。
 したがって、1つ目のセグメントを取得するためには、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
 同様に、2つ目のセグメントを取得するためには、以下のHTTPリクエストを発行すればよい。
 GET /counter-10mn_avc_dash.mp4 HTTP/1.1
 Host: example.com
 Range: bytes=83597-166046
[MPDの書換え]
 本実施の形態においては、セグメント化されたコンテンツのストリームデータがHTTPによるユニキャスト送信と、RTPによるマルチキャスト送信と、RTPによるブロードキャスト送信とにより受信側のDASHクライアント70に供給される。さらに、DASHクライアント70にてこれらがシームレスにスイッチングして受信、再生される。
 これを実現するために、MPDにServiceLocation要素を新たに導入する。また、HTTPによりユニキャスト送信されるセグメントのバイト範囲に対応する、RTPによりマルチキャスト送信およびブロードキャスト送信されるストリームセグメントの区間を表すrtspRangeを追記する。
 図9は、図8に示された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フォーマットに限定されるものではない。
 例えば、図9の場合、HTTPによりユニキャスト送信されるファイルのバイト範囲795バイト目から83596バイト目までのデータから成る1つ目のセグメントには、RTPによりマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの19961108T143720.25Zから19961108T143730.25Zの表す区間が対応することを示している。
 同様に、HTTPによりユニキャスト送信されるファイルのバイト範囲83597バイト目から166046バイト目までのデータから成る2つ目のセグメントには、RTPによりマルチキャスト送信およびブロードキャスト送信されるセグメントストリームの19961108T143730.25Zから19961108T143740.25Zの表す区間が対応することを示している。
 図10は、serviceLocationAttributeUrl属性により指定されるServiceLocationAttributeファイルのXML schemaの一例を示している。
 図11は、MPDに新たに導入した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に記述される。
 図12は、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によりコンテンツストリームが運ばれるものとする。図13のAは、この場合におけるプロトコルの階層構造を示している。
 また、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の3項目の情報を指す。
 上述したように、ServiceLocation/DeliverySystem要素に格納されるDVBurlフォーマットにより取得されるDVB地上波網によるブロードキャストストリーム上に転送されるIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリームには、RTPプロトコルによりコンテンツストリームが運ばれるものとする。図13のBは、この場合におけるプロトコルの階層構造を示している。
[RTPパケットのデータ構造について]
 ここで、コンテンツストリームをマルチキャスト送信する場合、およびブロードキャスト送信する場合に用いるRTPパケットについて説明する。
 図14は、RTPパケットのデータ構造を示している。同図に示されるように、RTPパケットは、RTPヘッダ81とRTPペイロード82で構成される。RTPヘッダ81には、ペイロードタイプ(PT)83、シーケンスナンバ(SN)84、およびタイムスタンプ(TS)85の各フィールドが設けられている。
 ペイロードタイプ83には、RTPペイロード82に格納されるコンテンツの種類を示すための情報が記述される。本実施の形態の場合、RTPペイロード82に格納されるコンテンツのコーデックの種類を示すための情報が記述される。具体的には、RTPペイロード82にAVC fragmented MP4が格納される場合、"AVC fragmented MP4 over RTP"が記述され、RTPペイロード82にHEVC fragmented MP4が格納される場合、"HEVC fragmented MP4 over RTP"が記述される。
 シーケンスナンバ84には、連続して送信されるRTPパケットのシーケンス番号が記述される。該シーケンス番号によりパケットロスの有無が検出される。
 タイムスタンプ85は、RTPパケットにおけるタイムスタンプの従来の運用とは異なり、該RTPパケットの送信時の最初のビットの送信時刻が、32ビットのショートフォーマット(clause 6 of IETF RFC5905, NTP version 4 にて既定)のNTPタイムスタンプ値が記述される。ここで、RTPパケットにおけるタイムスタンプの従来の運用とは、RTPペイロード82のペイロードデータの先頭バイトのサンプリング時刻のタイムスタンプを記述することを指す。
 タイムスタンプ85に記述されたNTPタイムスタンプ値は、主に転送上のジッタ除去に利用され、タイムスタンプの従来の運用のような提示時刻制御には利用されない。なお、本実施の形態の場合、提示時刻制御にはfragmented MP4のbox構造(図15のmoof97または図16のmoof107)から導出されるタイムスタンプ値が利用される。
[RTPペイロード82のデータ構造について]
 図15は、ペイロードタイプ83が"AVC fragmented MP4 over RTP"である場合、すなわち、RTPペイロード82にAVC fragmented MP4が格納される場合のRTPペイロード82のフォーマットを示している。
 同図Aは、第1のモードのRTPペイロード82のフォーマットを示している。第1のモードのRTPペイロード82は、PayloadMode91、SegmentBoundary92、dash(ftyp)93、moov94、msix(styp)95、sidx96、moof97、mdatのヘッダ(mdat-h)98およびAVC over RTP payload99で構成される。
 PayloadMode91は、モードを表すための1バイトの値である。いまの場合、第1のモードであることを表す値1が記述される。
 SegmentBoundary92には、該RTPパケットに格納されているコンテンツのセグメントの境界を表すための1バイトの識別子が記述される。該RTPパケットにコンテンツのセグメントの先頭のNAL(Network Abstraction Layer)ユニットが格納されている場合には1が、セグメントの最後のNALユニットが格納されている場合には3が、それ以外の場合には2が記述される。
 dash(ftyp)93およびmoov94には、DASHにおけるデコーダ等の初期化情報が格納されているInitialization Segmentのftyp(ブラインド名dash)boxとmoov boxが配置される。
 msix(styp)95、sidx96、moof97、およびmdatのヘッダ98には、DASHにおけるメディアデータのチャンク(fragment)が格納されているMedia Segmentのメタデータであるstyp(ブランド名misx)boxとsidx boxとmoof boxとmdat boxのメディアデータを含まないヘッダ情報のみが配置される。moof97にはただ1つのtrackに関する情報が格納される。なお、DASHクライアント70では、moof97に格納されている情報に基づき、Payload dataの先頭バイトのサンプリング時刻を表すCompositionTimeがRTP Timestampとして導出される。
 AVC over RTP payload99には、rfc(request for comment)3984にて規定されたRTPペイロードフォーマット仕様(RTP Payload Format for H.264 Video)に従った、分割された先頭のNALユニット、1つのNALユニット、または複数のNALユニットが格納される。
 同図Bは、第2のモードのRTPペイロード82のフォーマットを示している。第2のモードのRTPペイロード82は、PayloadMode91、SegmentBoundary92、msix(styp)95、sidx96、moof97、およびAVC over RTP payload99で構成される。
 第2のモードの場合、PayloadMode91には、第2のモードであることを表す値2が記述される。また、AVC over RTP payload99には、rfc3984にて規定されたRTPペイロードフォーマット仕様に従った、分割された先頭のNALユニット、1つのNALユニット、または複数のNALユニットが格納される。
 同図Cは、第3のモードのRTPペイロード82のフォーマットを示している。第3のモードのRTPペイロード82は、PayloadMode91、SegmentBoundary92、およびAVC over RTP payload99で構成される。
 第3のモードの場合、PayloadMode91には、第3のモードであることを表す値3が記述される。また、AVC over RTP payload99には、rfc3984にて規定されたRTPペイロードフォーマット仕様に従った、分割されたNALユニット(先頭のものは除く)、1つのNALユニット、または複数のNALユニットが格納される。
 次に、図16は、ペイロードタイプ83が"HEVC fragmented MP4 over RTP"である場合、すなわち、RTPペイロード82にHEVC fragmented MP4が格納される場合のRTPペイロード82のフォーマットを示している。
 なお、RTPペイロード82にHEVC fragmented MP4が格納される場合も、図15に示された場合と同様、第1乃至第3のモードがあり、図16のA乃至図16のCに示されるとおりである。
 同図Aは、第1のモードのRTPペイロード82のフォーマットを示している。第1のモードのRTPペイロード82は、PayloadMode101、SegmentBoundary102、dash(ftyp)103、moov104、msix(styp)105、sidx106、moof107、mdatのヘッダ(mdat-h)108およびHEVC over RTP payload109で構成される。
 PayloadMode101は、モードを表すための1バイトの値である。いまの場合、第1のモードであることを表す値1が記述される。
 SegmentBoundary102には、該RTPパケットに格納されているコンテンツのセグメントの境界を表すための1バイトの識別子が記述される。該RTPパケットにコンテンツのセグメントの先頭のNALユニットが格納されている場合には1が、セグメントの最後のNALユニットが格納されている場合には3が、それ以外の場合には2が記述される。
 dash(ftyp)103およびmoov104には、DASHにおけるデコーダ等の初期化情報が格納されているInitialization Segmentであるftyp(ブランド名dash)boxとmoov boxが配置される。
 msix(styp)105、sidx106、moof107およびmdatのヘッダ98には、DASHにおけるメディアデータのチャンク(fragment)が格納されているMedia Segmentのメタデータであるstyp(ブランド名msix)boxとsidx boxとmoof boxとmdat boxのメディアデータを含まないヘッダ情報のみが配置される。moof107にはただ1つのtrackに関する情報が格納される。なお、DASHクライアント70では、moof107に格納されている情報に基づき、Payload dataの先頭バイトのサンプリング時刻を表すCompositionTimeがRTP Timestampとして導出される。
 HEVC over RTP payload108には、draft-schierl-payload-rtp-h265-01にて規定されているRTPペイロードフォーマット仕様(RTP Payload Format for High Efficiency Video Coding)に従った、分割された先頭のNALユニット、1つのNALユニット、または複数のNALユニットが格納される。
 同図Bは、第2のモードのRTPペイロード82のフォーマットを示している。第2のモードのRTPペイロード82は、PayloadMode101、SegmentBoundary102、msix(styp)105、sidx106、moof107、およびHEVC over RTP payload109で構成される。
 第2のモードの場合、PayloadMode101には、第2のモードであることを表す値2が記述される。また、HEVC over RTP payload109には、draft-schierl-payload-rtp-h265-01にて規定されているRTPペイロードフォーマット仕様に従った、分割された先頭のNALユニット、1つのNALユニット、または複数のNALユニットが格納される。
 同図Cは、第3のモードのRTPペイロード82のフォーマットを示している。第3のモードのRTPペイロード82は、PayloadMode101、SegmentBoundary102、およびHEVC over RTP payload109で構成される。
 第3のモードの場合、PayloadMode101には、第3のモードであることを表す値3が記述される。また、HEVC over RTP payload109には、draft-schierl-payload-rtp-h265-01にて規定されているRTPペイロードフォーマット仕様に従った、分割されたNALユニット(先頭のものは除く)、1つのNALユニット、または複数のNALユニットが格納される。
[RTPパケットの送信パターンについて]
 図17は、連続して送信されるRTPパケットのRTPペイロード82に採用し得るフォーマット(第1乃至第3のモード)の組み合わせパターンの4つの例を示している。
 同図Aに示される第1の組み合わせパターンは、連続して送信される全てのRTPパケットのRTPペイロード82に第1のモードが採用されている。なお、第1の組み合わせパターンの場合、1つ目のRTPパケットから3つ目のRTPパケットまでが1つのセグメントであり、4つ目のRTPパケットと5つ目のRTPパケットが1つのセグメントである。
 同図Bに示される第2の組み合わせパターンは、連続して送信される1つ目から5つ目のRTPパケットのRTPペイロード82に順に、第1のモード、第2のモード、第2のモード、第1のモード、第2のモードが採用されている。なお、第2の組み合わせパターンの場合、1つ目のRTPパケットから3つ目のRTPパケットまでが1つのセグメントであり、4つ目のRTPパケットと5つ目のRTPパケットが1つのセグメントである。
 同図Cに示される第3の組み合わせパターンは、連続して送信される1つ目から5つ目のRTPパケットのRTPペイロード82に順に、第1のモード、第2のモード、第3のモード、第1のモード、第3のモードが採用されている。なお、第3の組み合わせパターンの場合、1つ目のRTPパケットから3つ目のRTPパケットまでが1つのセグメントであり、4つ目のRTPパケットと5つ目のRTPパケットが1つのセグメントである。
 同図Dに示される第4の組み合わせパターンは、連続して送信される1つ目から5つ目のRTPパケットのRTPペイロード82に順に、第1のモード、第3のモード、第3のモード、第3のモード、第3のモードが採用されている。なお、第4の組み合わせパターンの場合、1つ目のRTPパケットから5つ目のRTPパケットまでが1つのセグメントである。
 なお、組み合わせパターンについては、図示したものに限るものではなく任意であるが、1つのセグメントが格納された1以上のRTPパケットのうちの1以上のもののRTPペイロード82に第1のモードを採用する必要がある。
[コンテンツ供給システム50の動作]
 次に、コンテンツ供給システム50の動作について説明する。
 図18は、コンテンツ供給システム50の第1の動作を説明するフローチャートである。該第1の動作では、DASHクライアント70からMPDコンフィギュレータ65に対してMPDの書き換えが自発的に依頼される。
 なお、該第1の動作の前提として、DASHセグメントストリーマ62は、コンテンツマネジメントサーバ61から、同一内容のコンテンツのビットレートなどが異なる複数のストリーミングデータを取得、各ストリーミングデータをセグメント化して保持しており、それのHTTPによるユニキャスト送信を開始しているものとする。
 また、DASH MPDサーバ63は、DASHセグメントストリーマ62から通知されたストリームセグメントのファイルのアドレスに基づいてMPDを生成しており、それのHTTPによるユニキャスト送信を開始しているものとする。
 ステップS1において、コンテンツを受信、再生しようとするDASHクライアント70は、インターネット11を介してDASH MPDサーバ63にアクセスしてMPDの送信を要求する。なお、DASHクライアント70はDASH MPDサーバ63のアドレスを予め知っているものとする。
 DASHクライアント70からの要求に応じ、ステップS11において、DASH MPDサーバ63は、インターネット11を介してDASHクライアント70にMPDをHTTPによりユニキャスト送信する。
 MPDを受信したDASHクライアント70は、該MPDに基づいてDASHセグメントストリーマ62にアクセスし、HTTPによりユニキャスト送信されるストリームセグメントを受信、再生する。
 具体的には、MPDのBaseURLとmediaRangeに基づいてHTTPリクエストを発行して、DASHセグメントストリーマ62にDASHストリームセグメントのファイルを要求する。この要求に応じ、DASHセグメントストリーマ62は、対応するファイルをインターネット11を介してDASHクライアント70にHTTPによってユニキャスト送信し、これをDASHクライアント70が受信して再生する。
 この受信の間、DASHクライアント70は、ステップS2として、インターネット11の通信帯域をモニタリングし、今後、インターネット11を介したユニキャスト受信が不安定になりそうであり、かつ、DASHクライアント70自身が放送網12を介したコンテンツのマルチキャスト送信やブロードキャスト送信を受信可能である場合、MPDコンフィギュレータ65に対して取得済みのMPDを送信し、該MPDの書き換えを要求する。
 DASHクライアント70からのMPDの書き換え要求に応じ、ステップS21において、MPDコンフィギュレータ65は、ブロードキャスト/マルチキャストリソースマネージャ66に対してブロードキャストベアラおよびマルチキャストベアラのリソースの利用状況を確認する。さらに、ブロードキャストベアラおよびマルチキャストベアラを併用することについてのコストを考慮してその利用を決定し、ブロードキャスト/マルチキャストリソースマネージャ66に対して該リソースの確保を要求する。ブロードキャスト/マルチキャストリソースマネージャ66から該リソースが確保できた旨の通知を受けた後、MPDコンフィギュレータ65は、MPDを書き換えてDASHクライアント70に送信する。なお、送信された、書き換えられたMPDは、DASHクライアント70で受信される前に、DASHクライアントプロキシ67にモニタリングされる。
 書き換えられたMPDをモニタリングしたDASHクライアントプロキシ67は、ステップS31において、ブロードキャスト/マルチキャストプロバイダ68に対して、放送網12のFLUTEにより該MPDの周期的なマルチキャスト送信を依頼する。この依頼に応じ、ステップS41において、ブロードキャスト/マルチキャストプロバイダ68は、書き換えられたMPDを、放送網12のFLUTEにより周期的にマルチキャスト送信する。このマルチキャスト送信により、MPDの書き換えを要求していないDASHクライアント70に対しても、書き換えられたMPDを供給することができる。
 ステップS32において、DASHクライアントプロキシ67は、モニタリングしたMPDに基づき、DASHクライアント70の代わりにDASHセグメントストリーマ62にストリームセグメントを要求する。この要求に応じたDASHセグメントストリーマ62は、ステップS51において、HTTPによりインターネット11を介して、DASHクライアントプロキシ67にストリームセグメントをユニキャスト送信する。
 DASHセグメントストリーマ62からHTTPによりユニキャスト送信されたストリームセグメントを受信したDASHクライアントプロキシ67は、ステップS33において、HTTPのパケットに格納されている該ストリームセグメントをbox構造を外すことなくそのままRTPパケットのRTPペイロード82に乗せ換えるプロトコル変換を行う。なお、このプロトコル変換は、図15または図16を参照して上述したように行なわれる。
 さらに、DASHクライアントプロキシ67は、ブロードキャスト/マルチキャストプロバイダ68に対して、プロトコル変換後のストリームセグメントのRTPによる放送網12を介したマルチキャスト送信およびブロードキャスト送信を依頼する。
 この依頼に応じ、ステップS42において、ブロードキャスト/マルチキャストプロバイダ68は、プロトコルが変換されたストリームセグメントのRTPによる放送網12を介したマルチキャスト送信およびブロードキャスト送信を開始する。
 なお、書き換えられたMPDを取得したDASHクライアント70は、その後、ステップS3またはステップS5に進む。
 すなわち、HTTPによりインターネット11を介してユニキャスト送信されるストリームセグメントの受信、再生を継続する場合、処理はステップS3に進むことになる。また、RTPにより放送網12を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントにスイッチングする場合、処理はステップS5に進むことになる。
 ユニキャスト送信されるストリームセグメントの受信、再生を継続する場合には、ステップS3において、DASHクライアント70は、該MPDに基づいてDASHセグメントストリーマ62にストリームセグメントを要求する。そして、ステップS4において、この要求に応じたDASHセグメントストリーマ62からのHTTPによるインターネット11を介したストリームセグメントのユニキャスト送信(ステップS52の処理)を受信、再生する。
 RTPにより放送網12を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントにスイッチングする場合には、ステップS5において、DASHクライアント70は、書き換えられたMPDに基づき、HTTPによりユニキャスト送信されているセグメントストリームから、RTPによりマルチキャスト送信またはブロードキャスト送信されている、プロトコル変換されたストリームセグメントに受信、再生をスイッチングする。
 このスイッチングのタイミングは、書き換えられたMPD上のマルチキャストストリームに対応するRepresentationに対応するSegment列に格納されているrtspRangeの時間区間情報を頼りに、ユニキャストで運ばれるRepresentationに対応するSegment列との対応関係に基づいて決定される。
 なお、DASHクライアント70における提示時刻制御には、RTPペイロード82のmoof97(またはmoof107)から導出されるタイムスタンプ値が利用される。
 この後においては、HTTPによりインターネット11を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網12を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。
 以上で、コンテンツ供給システム50の第1の動作の説明を終了する。
 次に、図19は、コンテンツ供給システム50の第2の動作を説明するフローチャートである。該第2の動作では、MPDプロキシサーバ64が主体となってMPDコンフィギュレータ65に対してMPDの書き換えが依頼される。
 なお、該第2の動作の前提として、DASHセグメントストリーマ62は、コンテンツマネジメントサーバ61から、同一内容のコンテンツのビットレートなどが異なる複数のストリーミングデータを取得、各ストリーミングデータをセグメント化して保持しており、それらのHTTPによるユニキャスト送信を開始しているものとする。
 また、DASH MPDサーバ63は、DASHセグメントストリーマ62から通知されたストリームセグメントのファイルのアドレスに基づいてMPDを生成しており、それのHTTPによるユニキャスト送信を開始しているものとする。
 ステップS71において、コンテンツを受信、再生しようとするDASHクライアント70は、インターネット11を介してDASH MPDサーバ63にMPDを要求する。この要求は、MPDプロキシサーバ64によって受信され、MPDプロキシサーバ64は、ステップS81において、DASH MPDサーバ63にMPDを要求する。
 MPDプロキシサーバ64からの要求に応じたDASH MPDサーバ63は、ステップS91において、MPDをMPDプロキシサーバ64に対してHTTPによりユニキャスト送信する。該MPDを受信したMPDプロキシサーバ64は、ステップS82において、受信したMPDをMPDコンフィギュレータ65に送信して該MPDの書き換えを要求する。
 MPDの書き換え要求に応じ、ステップS101において、MPDコンフィギュレータ65は、ブロードキャスト/マルチキャストリソースマネージャ66に対してブロードキャストベアラおよびマルチキャストベアラのリソースの利用状況を確認する。さらに、ブロードキャストベアラおよびマルチキャストベアラを併用することのコストを考慮して、その利用を決定し、ブロードキャスト/マルチキャストリソースマネージャ66に対して該リソースの確保を要求する。ブロードキャスト/マルチキャストリソースマネージャ66から該リソースが確保できた旨の通知を受けた後、MPDコンフィギュレータ65は、MPDを書き換えてMPDプロキシサーバ64に送信する。
 ステップS83において、MPDプロキシサーバ64は、書き換えられたMPDをDASHクライアント70に送信する。なお、送信された、書き換えられたMPDは、DASHクライアント70で受信される前に、DASHクライアントプロキシ67にモニタリングされる。
 書き換えられたMPDをモニタリングしたDASHクライアントプロキシ67は、ステップS111において、ブロードキャスト/マルチキャストプロバイダ68に対して、放送網12のFLUTEにより該MPDの周期的なマルチキャスト送信を依頼する。この依頼に応じ、ステップS121において、ブロードキャスト/マルチキャストプロバイダ68は、書き換えられたMPDを、放送網12のFLUTEにより周期的にマルチキャスト送信する。このマルチキャスト送信により、MPDの送信を要求していないDASHクライアント70に対しても、書き換えられたMPDを供給することができる。
 ステップS112において、DASHクライアントプロキシ67は、モニタリングした、書き換えられたMPDに基づき、DASHクライアント70の代わりにDASHセグメントストリーマ62にストリームセグメントを要求する。この要求に応じたDASHセグメントストリーマ62は、ステップS131において、HTTPによりインターネット11を介して、DASHクライアントプロキシ67にストリームセグメントをユニキャスト送信する。
 DASHセグメントストリーマ62からHTTPによりユニキャスト送信されたストリームセグメントを受信したDASHクライアントプロキシ67は、ステップS113において、HTTPのパケットに格納されている該ストリームセグメントをbox構造を外すことなくそのままRTPパケットのRTPペイロード82に乗せ換えるプロトコル変換を行う。なお、このプロトコル変換は、図15または図16を参照して上述したように行なわれる。
 さらに、DASHクライアントプロキシ67は、ブロードキャスト/マルチキャストプロバイダ68に対して、プロトコル変換後のストリームセグメントのRTPによる放送網12を介したマルチキャスト送信およびブロードキャスト送信を依頼する。
 この依頼に応じ、ステップS122において、ブロードキャスト/マルチキャストプロバイダ68は、プロトコルが変換されたストリームセグメントのRTPによる放送網12を介したマルチキャスト送信およびブロードキャスト送信を開始する。
 一方、DASHクライアント70は、書き換えられたMPDを既に取得している。ステップS72において、DASHクライアント70は、インターネット11の通信帯域の状態、自身の受信機能、デコード機能などに基づいて、インターネット11を介するユニキャスト送信を受信するか、放送網12を介するマルチキャスト送信またはブロードキャスト送信を受信するかを選択する。
 HTTPによりインターネット11を介してユニキャスト送信されるストリームセグメントの受信、再生を行うことが選択された場合、処理はステップS73に進められる。ステップS73において、DASHクライアント70は、該MPDに基づいてDASHセグメントストリーマ62にストリームセグメントを要求する。そして、ステップS74において、この要求に応じたDASHセグメントストリーマ62からのHTTPによるインターネット11を介したストリームセグメントのユニキャスト送信(ステップS132の処理)を受信、再生する。
 また、ステップS72において、RTPにより放送網12を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントの受信、再生を行うことが選択された場合、処理はステップS75に進められる。ステップS75において、DASHクライアント70は、書き換えられたMPDに基づき、RTPによりマルチキャスト送信またはブロードキャスト送信された、プロトコル変換されたストリームセグメントを受信、再生する。
 なお、DASHクライアント70における提示時刻制御には、RTPペイロード82のmoof97(またはmoof107)から導出されるタイムスタンプ値が利用される。
 この後においては、HTTPによりインターネット11を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網12を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。
 以上で、コンテンツ供給システム50の第2の動作の説明を終了する。
 以上説明したように、本実施の形態であるコンテンツ供給システム50によれば、HTTPによりインターネット11を介してユニキャスト送信されるストリームセグメントと、RTPにより放送網12を介してマルチキャスト送信またはブロードキャスト送信されたストリームセグメントとの間でシームレスにスイッチングを行なうことができる。したがって、DASHクライアント70のユーザは、同一内容のコンテンツであってパスが異なるストリームを適応的に選択し、視聴することができる。
 また、本実施の形態であるコンテンツ供給システム50によれば、HTTPによりユニキャスト送信されるストリームセグメントをbox構造を壊すことなくそのままRTPパケットに格納してマルチキャスト送信したりブロードキャスト送信したりすることができる。したがって、コンテンツの供給側は、容易にDASHにおける代替パスを用意することができる。
 ところで、上述した一連の処理を実行するコンテンツ供給装置60、およびDASHクライアント70は、それぞれをハードウェアにより構成する他、コンピュータがソフトウェアを実行することにより実現することもできる。このコンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
 図206は、上述したコンピュータのハードウェアの構成例を示すブロック図である。
 このコンピュータ200において、CPU(Central Processing Unit)201,ROM(Read Only Memory)202,RAM(Random Access Memory)203は、バス204により相互に接続されている。
 バス204には、さらに、入出力インタフェース205が接続されている。入出力インタフェース205には、入力部206、出力部207、記憶部208、通信部209、およびドライブ220が接続されている。
 入力部206は、キーボード、マウス、マイクロフォンなどよりなる。出力部207は、ディスプレイ、スピーカなどよりなる。記憶部208は、ハードディスクや不揮発性のメモリなどよりなる。通信部209は、ネットワークインタフェースなどよりなる。ドライブ220は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア211を駆動する。
 以上のように構成されるコンピュータ200では、CPU201が、例えば、記憶部208に記憶されているプログラムを、入出力インタフェース205およびバス204を介して、RAM203にロードして実行することにより、上述した一連の処理が行われる。
 コンピュータ200(CPU201)が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア211に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
 コンピュータ200では、プログラムは、リムーバブルメディア211をドライブ220に装着することにより、入出力インタフェース205を介して、記憶部208にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部209で受信し、記憶部208にインストールすることができる。その他、プログラムは、ROM202や記憶部208に、あらかじめインストールしておくことができる。
 なお、コンピュータ200が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであってもよい。
 なお、本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
 なお、本開示は以下のような構成も取ることができる。
(1)
 MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置において、
 前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
 前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
 HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
 を備えるコンテンツ供給装置。
(2)
 前記コンテンツのストリーミングデータはfragmented MP4であり、
 前記RTP送信部は、前記セグメントファイルを前記fragmented MP4のbox構造を維持したまま前記RTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信する
 前記(1)に記載のコンテンツ供給装置。
(3)
 前記RTP送信部は、前記RTPパケットのRTPヘッダのタイムスタンプフィールドに、前記RTPパケットの送信時の先頭のビットの送信時刻を記述する
 前記(1)または(2)に記載のコンテンツ供給装置。
(4)
 前記RTP送信部は、前記RTPパケットのRTPペイロードに、前記RTPペイロードのモードを表す情報と、セグメントの境界を表す情報とを記述し、ペイロードデータにNALユニットを配置する
 前記(1)から(2)のいずれかに記載のコンテンツ供給装置。
(5)
 前記RTP送信部は、さらに、前記RTPパケットのRTPペイロードに、前記MPEG-DASH で規定されているInitialization SegmentとMedia Segmentのメタデータの両方を配置するか、前記Media Segmentのメタデータを配置するか、または前記Initialization Segmentと前記Media Segmentのメタデータの両方を配置しない
 前記(4)に記載のコンテンツ供給装置。
 11 インターネット, 12 放送網, 50 コンテンツ供給システム, 60 コンテンツ供給装置, 61 コンテンツマネジメントサーバ, 62 DASHセグメントストリーマ, 63 DASH MPDサーバ, 64 MPDプロキシサーバ, 65 MPDコンフィギュレータ, 66 ブロードキャスト/マルチキャストリソースマネージャ, 67 DASHクライアントプロキシ, 68 ブロードキャスト/マルチキャストサービスプロバイダ, 70 DASHクライアント, 200 コンピュータ, 201 CPU

Claims (8)

  1.  MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置において、
     前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
     前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
     HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
     を備えるコンテンツ供給装置。
  2.  前記コンテンツのストリーミングデータはfragmented MP4であり、
     前記RTP送信部は、前記セグメントファイルを前記fragmented MP4のbox構造を維持したまま前記RTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信する
     請求項1に記載のコンテンツ供給装置。
  3.  前記RTP送信部は、前記RTPパケットのRTPヘッダのタイムスタンプフィールドに、前記RTPパケットの送信時の先頭のビットの送信時刻を記述する
     請求項2に記載のコンテンツ供給装置。
  4.  前記RTP送信部は、前記RTPパケットのRTPペイロードに、前記RTPペイロードのモードを表す情報と、セグメントの境界を表す情報とを記述し、ペイロードデータにNALユニットを配置する
     請求項2に記載のコンテンツ供給装置。
  5.  前記RTP送信部は、さらに、前記RTPパケットのRTPペイロードに、前記MPEG-DASH で規定されているInitialization SegmentとMedia Segmentのメタデータの両方を配置するか、前記Media Segmentのメタデータを配置するか、または前記Initialization Segmentと前記Media Segmentのメタデータの両方を配置しない
     請求項2に記載のコンテンツ供給装置。
  6.  MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、
     前記コンテンツ供給装置による、
      前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信ステップと、
      前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信ステップと、
      HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成ステップと
     を含むコンテンツ供給方法。
  7.  MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンピュータを、
     前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
     前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
     HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
     して機能させるプログラム。
  8.  MPEG-DASHに従ってコンテンツのストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信するクライアント装置とから成るコンテンツ供給システムにおいて、
     前記コンテンツ供給装置は、
      前記ストリーミングデータをセグメント毎にファイル化し、その結果得られるセグメントファイルをHTTPによりユニキャスト送信するHTTP送信部と、
      前記セグメントファイルをそのままRTPパケットに格納し、前記RTPパケットをRTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信するRTP送信部と、
      HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとの時間的な対応関係を記述したメタファイルを生成し、受信側に供給するメタファイル生成部と
     を備え、
     前記クライアント装置は、
      取得した前記メタファイルに基づいて、HTTPによりユニキャスト送信される前記セグメントファイルと、RTPによりマルチキャストまたはブロードキャストの少なくとも一方で送信される前記セグメントファイルとを切り替えて受信、再生する
     コンテンツ供給システム。
PCT/JP2014/062488 2013-05-22 2014-05-09 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム WO2014188886A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP14800786.7A EP3001690A4 (en) 2013-05-22 2014-05-09 Content supply device, content supply method, program, and content supply system
CN201480028025.0A CN105210372B (zh) 2013-05-22 2014-05-09 内容供应装置、内容供应方法、程序以及内容供应***
US14/891,023 US9942619B2 (en) 2013-05-22 2014-05-09 Content supply device, content supply method, program, and content supply system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2013107678A JP2014230055A (ja) 2013-05-22 2013-05-22 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JP2013-107678 2013-05-22

Publications (1)

Publication Number Publication Date
WO2014188886A1 true WO2014188886A1 (ja) 2014-11-27

Family

ID=51933449

Family Applications (1)

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

Country Status (5)

Country Link
US (1) US9942619B2 (ja)
EP (1) EP3001690A4 (ja)
JP (1) JP2014230055A (ja)
CN (2) CN105210372B (ja)
WO (1) WO2014188886A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106233703A (zh) * 2015-02-27 2016-12-14 索尼公司 接收设备、接收方法、传输设备以及传输方法
WO2017068794A1 (en) * 2015-10-23 2017-04-27 Sharp Kabushiki Kaisha File recovery
US10038922B2 (en) 2013-07-19 2018-07-31 Sony Corporation Information processing device and method for supplying data of partial images

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170030490A (ko) * 2014-07-07 2017-03-17 소니 주식회사 수신 장치, 수신 방법, 송신 장치, 및 송신 방법
WO2016080803A1 (ko) 2014-11-20 2016-05-26 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10924822B2 (en) * 2017-04-04 2021-02-16 Qualcomm Incorporated Segment types as delimiters and addressable resource identifiers
US20190020700A1 (en) * 2017-07-14 2019-01-17 Cisco Technology, Inc. Transport of Legacy Transport Streams Over ABR Networks
US10404713B2 (en) 2017-09-29 2019-09-03 Zott, Inc. Multi-source broadcasting architecture
EP3767964A4 (en) * 2018-03-15 2021-01-20 Sony Corporation INFORMATION PROCESSING DEVICE, INFORMATION PROCESSING DEVICE, AND PROGRAM
US20190364330A1 (en) * 2018-05-11 2019-11-28 Arris Enterprises Llc Broadcast Delivered HLS System
CN110519652B (zh) * 2018-05-22 2021-05-18 华为软件技术有限公司 Vr视频播放方法、终端及服务器
WO2020109496A1 (en) 2018-11-30 2020-06-04 British Telecommunications Public Limited Company Multicast to unicast conversion
CN111510789B (zh) * 2019-01-30 2021-09-21 上海哔哩哔哩科技有限公司 视频播放方法、***、计算机设备及计算机可读存储介质
US11184420B2 (en) * 2020-01-06 2021-11-23 Tencent America LLC Methods and apparatuses for dynamic adaptive streaming over HTTP
CN111901694B (zh) * 2020-08-06 2022-08-26 海信电子科技(深圳)有限公司 一种mmtp节目的播放方法及装置
JP7123517B1 (ja) 2021-12-20 2022-08-23 一般社団法人日本ケーブルラボ ブロードキャスト及びユニキャストでコンテンツを配信するコアシステム装置、端末、システム、プログラム及び方法

Citations (1)

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

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8031701B2 (en) * 2006-09-11 2011-10-04 Cisco Technology, Inc. Retransmission-based stream repair and stream join
CN101227745B (zh) * 2008-02-02 2011-02-09 华为软件技术有限公司 移动多媒体业务的网络切换方法、装置和***
JPWO2010050022A1 (ja) * 2008-10-29 2012-03-29 富士通株式会社 配信システム、代理サーバおよび配信方法
CN101998384B (zh) * 2009-08-18 2014-03-26 ***通信集团公司 一种加密传输媒体流的方法、加密服务器和移动终端
US9137482B2 (en) * 2010-03-31 2015-09-15 Verizon Patent And Licensing Inc. Methods and systems for resolution-based modification of recording instructions associated with a scheduled recording of a media content instance
US20130097334A1 (en) * 2010-06-14 2013-04-18 Thomson Licensing Method and apparatus for encapsulating coded multi-component video
JP2013532441A (ja) * 2010-06-14 2013-08-15 トムソン ライセンシング 符号化マルチコンポーネント・ビデオをカプセル化する方法および装置
US9781188B2 (en) * 2010-11-02 2017-10-03 Lg Electronics Inc. Method for transreceiving media content and device for transreceiving using same
US8854958B2 (en) * 2011-12-22 2014-10-07 Cygnus Broadband, Inc. Congestion induced video scaling

Patent Citations (1)

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

Non-Patent Citations (5)

* 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: "Achieving Uninterrupted Video Streaming Using Existing Web Servers Doga Haishin no Jisedai Hyojun 'MPEG-DASH' o Himotoku", NIKKEI ELECTRONICS, vol. 1078, 19 March 2012 (2012-03-19), pages 77 - 85, XP008182277 *
MITSUHIRO HIRABAYASHI: "Achieving Uninterrupted Video Streaming Using 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 12 - 14, XP055295670 *
See also references of EP3001690A4 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10038922B2 (en) 2013-07-19 2018-07-31 Sony Corporation Information processing device and method for supplying data of partial images
US10306273B2 (en) 2013-07-19 2019-05-28 Sony Corporation Information processing device and method for generating partial image information including group identification information
CN106233703A (zh) * 2015-02-27 2016-12-14 索尼公司 接收设备、接收方法、传输设备以及传输方法
EP3264729A4 (en) * 2015-02-27 2018-07-18 Sony Corporation Reception apparatus, reception method, transmission apparatus and transmission method
US10264296B2 (en) 2015-02-27 2019-04-16 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method
CN106233703B (zh) * 2015-02-27 2021-07-09 索尼公司 接收设备、接收方法、传输设备以及传输方法
EP3855771A1 (en) * 2015-02-27 2021-07-28 Sony Group Corporation Reception apparatus and reception method using a undirectional transport protocol
WO2017068794A1 (en) * 2015-10-23 2017-04-27 Sharp Kabushiki Kaisha File recovery

Also Published As

Publication number Publication date
EP3001690A4 (en) 2017-01-11
JP2014230055A (ja) 2014-12-08
EP3001690A1 (en) 2016-03-30
CN110213666B (zh) 2021-09-07
US20160127798A1 (en) 2016-05-05
CN105210372A (zh) 2015-12-30
US9942619B2 (en) 2018-04-10
CN110213666A (zh) 2019-09-06
CN105210372B (zh) 2019-05-17

Similar Documents

Publication Publication Date Title
WO2014188886A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JP6122982B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
RU2636123C2 (ru) Устройство предоставления содержания, способ предоставления содержания, программа и система предоставления содержания
JP6457931B2 (ja) コンテンツ供給装置、コンテンツ供給方法、コンテンツ受信装置、コンテンツ受信方法、プログラム、およびコンテンツ供給システム
JP6258856B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
JP6329964B2 (ja) 送信装置、送信方法、受信装置、及び、受信方法
WO2014208377A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
KR20120114016A (ko) 사용자 컨텐츠를 외부 단말기에서 네트워크 적응적으로 스트리밍하는 방법 및 장치
US20200021867A1 (en) Broadcast signal transmitting and receiving method and device
WO2016136489A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
WO2014196392A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
US10432989B2 (en) Transmission apparatus, transmission method, reception apparatus, receiving method, and program
WO2015001986A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015045917A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
RU2658672C2 (ru) Устройство предоставления контента, программа, оконечное устройство и система предоставления контента
WO2015012140A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015064384A1 (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: 14800786

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14891023

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2014800786

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE