Title of Invention
CONTENT SUPPLY DEVICE, CONTENT SUPPLY METHOD, PROGRAM, AND
CONTENT 5 SUPPLY SYSTEM
Technical Field
[0001]
The present disclosure relates to a content supply device, a content supply
10 method, a program, and a content supply system, and more particularly, to a content
supply device, a content supply method, a program, and a content supply system,
which are capable of multicast-transmitting or broadcast-transmitting content via a
broadcasting network by the Real-time Transport Protocol (RTP) as an alternative
path when content is unicast-transmitted via the Internet by the hypertext transfer
15 protocol (HTTP).
Background Art
[0002]
In recent years, over the top video (OTT-V) has become a mainstream of a
20 streaming service via the Internet, and as a fundamental technology thereof, Moving
Picture Experts Group-Dynamic Adaptive Streaming over HTTP (hereinafter,
referred to as "DASH") (MPEG-DASH) using a HTTP in which a supply side is
connected with a reception side in a point to point manner, similarly to browsing of a
web site or the like has been known (for example, see Non-Patent Literature 1).
25 [0003]
In the DASH, an adaptive streaming technique is implemented. In other
words, a content supply side has a system capable of supplying a plurality of streams
that include content of the same subject but differ in an image quality or an angle of
view size, and a reception side is configured to switch and view an optimal stream
30 according to according to a communication environment of the Internet or a
capability or a state of the reception side.
3
[0004]
In the DASH, as information enabling the reception side to adaptively
switch a stream, a metafile called a media presentation description (MPD) is supplied
from the supply side to the reception side. An address (url information) indicating a
server of a supply source of streaming data (media data such as audio/5 video/subtitle)
divided into chunks is described in the MPD.
[0005]
The reception side can access the server based on the url information and
acquire and reproduce HTTP-transmitted streaming data.
10 [0006]
FIG. 1 illustrates an example of a configuration of a content supply system
that delivers content in a streaming manner based on the DASH.
[0007]
A content supply system 20 includes a content management server 21, a
15 DASH segment streamer 22, and a DASH MPD server 23 which are arranged at a
side at which content is supplied and a DASH client 30 arranged at a side at which
content is received and viewed. Although not illustrated, there are assumed to be a
plurality of DASH clients 30.
[0008]
20 The content management server 21 manages content supplied to the
reception side, generates a plurality of pieces of streaming data having different bit
rates from content of the same subject, and outputs the generated streaming data to
the DASH segment streamer 22.
[0009]
25 The DASH segment streamer 22 temporally divides streaming data of
content into segments, holds each of the segments as a file, and notifies the DASH
MPD server 23 of an address of the files. Further, the DASH segment streamer 22
unicast-delivers the file of the segmented streaming data in response to a request
from the DASH client 30 of the reception side via the Internet 11 as an HTTP server.
30 [0010]
The DASH MPD server 23 generates an MPD in which, for example, an
4
address of the DASH segment streamer 22 serving as the supply source of the files of
the segmented streaming data is described. The DASH MPD server 23 unicasttransmits
the MPD to the DASH client 30 via the Internet 11 in response to the
request from the DASH client 30 of the reception side as the HTTP server.
5 [0011]
The DASH client 30 of the reception side receives and reproduces content,
and accesses the DASH segment streamer 22 serving as the HTTP server based on
the MPD acquired from the DASH MPD server 23 and receives and reproduces the
files of the segmented streaming data.
10 [0012]
There are cases in which a cache server is installed on the Internet 11 to
cache the unicast-transmitted MPD, the files of the segmented streaming data, or the
like and undertake an operation of the DASH segment streamer 22 or the DASH
MPD server 23.
15
Citation List
Non-Patent Literature
[0013]
Non-Patent Literature 1: Mitsuhiro Hirabayashi, "Achieving Uninterrupted
20 Video Streaming Using Existing Web Servers," NIKKEI ELECTRONICS, March 19,
2012
Summary of Invention
Technical Problem
25 [0014]
As described above, in the DASH, an adaptive streaming technique of
supplying content by unicast-transmission according to the HTTP is implemented.
[0015]
For example, when content that is likely to be simultaneously acquired and
30 reproduced by a number of DASH clients 30, like content of a real-time sports
broadcast, is simultaneously supplied to a number of devices through the DASH,
5
since the HTTP is used, support by a contents delivery network (CDN) is necessary.
However, although it is supported by the CDN, it is difficult to obtain scalability as
high as in existing broadcast-delivery due to a cost restriction.
[0016]
By the way, in order to supply content to a number 5 of reception sides
simultaneously, there is a method of using a multicast bearer or a broadcast bearer
via a television broadcasting network or a mobile network, and in this method, the
RTP is commonly used.
[0017]
10 Thus, when the reception side can receive and reproduce the multicasttransmitted
or broadcast-transmitted content, it is desirable that the reception side can
select a stream adaptively using the multicast transmission or the broadcast
transmission as an alternative path in the DASH.
[0018]
15 However, in the current specification of the DASH, only unicast delivery of
streaming data of content according to the HTTP is considered, and the use of the
multicast bearer or the broadcast bearer is not considered.
[0019]
Thus, in the MPD of the DASH, it is difficult to describe a correspondence
20 relation between a DASH segment unicast-transmitted according to the HTTP and a
content interval streamed according to the RTP on the multicast bearer or the
broadcast bearer corresponding to the segment interval.
[0020]
Further, currently, a payload format that can be stored in the RTP packet
25 without change and without destroying the box structure of the fragmented MP4 that
is a content stream chunk serving as a control target of the DASH is not specified.
[0021]
Thus, in the current standard of the DASH, it is difficult to implement
seamless switching of content between unicast delivery and either of multicast
30 transmission and broadcast transmission.
[0022]
6
The present disclosure was made in light of the foregoing, and it is desirable
to implement seamless switching of content between the unicast transmission
according to the HTTP and either of the multicast transmission and the broadcast
transmission according to the RTP.
5
Solution to Problem
[0023]
According to a first aspect of the present disclosure, there is provided a
content supply device that supplies streaming data of content according to MPEG10
DASH, the content supply device including: a HTTP transmitting unit configured to
convert the streaming data into files in units of segments and unicast-transmit the
resulting segment files according to HTTP; an RTP transmitting unit configured to
store the segment file in an RTP packet without change and transmit the RTP packet
through at least one of multicasting and broadcasting according to RTP; and a
15 metafile generating unit configured to generate a metafile in which a temporal
correspondence relation between the segment file unicast-transmitted according to
the HTTP and the segment file transmitted through the at least one of the
multicasting and the broadcasting according to the RTP is described and supply the
metafile to a reception side.
20 [0024]
The streaming data of the content can be a fragmented MP4. The RTP
transmitting unit can store the segment file in the RTP packet while maintaining a
box structure of the fragmented MP4, and transmit the RTP packet through the at
least one of the multicasting and the broadcasting according to the RTP.
25 [0025]
The RTP transmitting unit can describe a transmission time of a first bit at a
time of transmission of the RTP packet in a time stamp field of an RTP header of the
RTP packet.
[0026]
30 The RTP transmitting unit can describe information indicating a mode of an
RTP payload and information indicating a segment boundary in the RTP payload of
7
the RTP packet, and arrange an NAL unit in payload data.
[0027]
The RTP transmitting unit can arrange both metadata of an Initialization
Segment and metadata of a Media Segment specified in the MPEG-DASH in an RTP
payload of the RTP packet, arrange the metadata of the Media 5 Segment in the RTP
payload of the RTP packet, or arrange neither of the metadata of the Initialization
Segment and the metadata of the Media Segment in the RTP payload of the RTP
packet.
[0028]
10 According to the first aspect of the present disclosure, there is provided a
content supply method of a content supply device that supplies streaming data of
content according to MPEG-DASH, the content supply method including: a HTTP
transmission step of converting the streaming data into files in units of segments and
unicast-transmitting the resulting segment files according to HTTP through the
15 content supply device; an RTP transmission step of storing the segment file in an
RTP packet without change and transmitting the RTP packet through at least one of
multicasting and broadcasting according to RTP through the content supply device;
and a metafile generation step of generating a metafile in which a temporal
correspondence relation between the segment file unicast-transmitted according to
20 the HTTP and the segment file transmitted through the at least one of the
multicasting and the broadcasting according to the RTP is described and supplying
the metafile to a reception side through the content supply device.
[0029]
According to the first aspect of the present disclosure, there is provided a
25 program causing a computer that supplies streaming data of content according to
MPEG-DASH to function as: a HTTP transmitting unit configured to convert the
streaming data into files in units of segments and unicast-transmit the resulting
segment files according to HTTP; an RTP transmitting unit configured to store the
segment file in an RTP packet without change and transmit the RTP packet through at
30 least one of multicasting and broadcasting according to RTP; and a metafile
generating unit configured to generate a metafile in which a temporal correspondence
8
relation between the segment file unicast-transmitted according to the HTTP and the
segment file transmitted through the at least one of the multicasting and the
broadcasting according to the RTP is described and supply the metafile to a reception
side.
5 [0030]
In the first aspect of the present disclosure, streaming data is converted into
files in units of segments, and the resulting segment files are unicast-transmitted
according to HTTP. The segment file is stored in an RTP packet without change,
and the RTP packet is transmitted through at least one of multicasting and
10 broadcasting according to RTP. A metafile in which a temporal correspondence
relation between the segment file unicast-transmitted according to the HTTP and the
segment file transmitted through at least one of the multicasting and the broadcasting
according to the RTP is described is generated and supplied to a reception side.
[0031]
15 According to a second aspect of the present disclosure, there is provided a
content supply system including: a content supply device configured to supply
streaming data of content according to MPEG-DASH; and a client device configured
to receive the stream data. The content supply device includes a HTTP transmitting
unit configured to convert the streaming data into files in units of segments and
20 unicast-transmit the resulting segment files according to HTTP, an RTP transmitting
unit configured to store the segment file in an RTP packet without change and
transmit the RTP packet through at least one of multicasting and broadcasting
according to RTP, and a metafile generating unit configured to generate a metafile in
which a temporal correspondence relation between the segment file unicast25
transmitted according to the HTTP and the segment file transmitted through the at
least one of the multicasting and the broadcasting according to the RTP is described
and supply the metafile to a reception side. The client device performs switching
between the segment file unicast-transmitted according to the HTTP and the segment
file transmitted through the at least one of the multicasting and the broadcasting
30 according to the RTP based on the acquired metafile, and receives and reproduces the
segment file.
9
Advantageous Effects of Invention
[0032]
According to the first and second aspects of the present disclosure, it is
possible to implement seamless switching of content 5 between the unicast
transmission according to the HTTP and either of the multicast transmission and the
broadcast transmission according to the RTP.
Brief Description of Drawings
10 [0033]
[FIG. 1] FIG. 1 is a block diagram illustrating an example of a configuration of a
content supply system of the related art employing a DASH.
[FIG. 2] FIG. 2 is a block diagram illustrating an exemplary configuration of a
content supply system to which the present disclosure is applied.
15 [FIG. 3] FIG. 3 is a diagram for describing temporal delimiting of content.
[FIG. 4] FIG. 4 is a diagram illustrating a configuration of an MPD.
[FIG. 5] FIG. 5 is a diagram illustrating a hierarchical structure below a period in an
MPD.
[FIG. 6] FIG. 6 is a diagram illustrating a state in which a configuration of an MPD is
20 arranged on a time axis.
[FIG. 7] FIG. 7 is a diagram illustrating a detailed structure below a representation of
an MPD.
[FIG. 8] FIG. 8 is a diagram illustrating an example of an MPD.
[FIG. 9] FIG. 9 is a diagram illustrating an example of a modified MPD.
25 [FIG. 10] FIG. 10 is a diagram illustrating an example of an XML Schema of a
ServiceLocation element.
[FIG. 11] FIG. 11 is a diagram illustrating a data structure of a ServiceLocation
element.
[FIG. 12] FIG. 12 is a diagram illustrating an example of a User Service Description.
30 [FIG. 13] FIG. 13 is a diagram illustrating a hierarchical structure of a protocol.
[FIG. 14] FIG. 14 is a diagram illustrating a data structure of an RTP packet.
10
[FIG. 15] FIG. 15 is a diagram when an AVC fragmented MP4 is stored in an RTP
packet.
[FIG. 16] FIG. 16 is a diagram when an HEVC segmented MP4 is stored in an RTP
packet.
[FIG. 17] FIG. 17 is a diagram illustrating an example of a combination 5 pattern of a
format of an RTP payload.
[FIG. 18] FIG. 18 is a flowchart for describing a first operation of a content supply
system.
[FIG. 19] FIG. 19 is a flowchart for describing a second operation of a content supply
10 system.
[FIG. 20] FIG. 20 is a block diagram illustrating an exemplary configuration of a
computer.
Description of Embodiments
15
[0034]
Hereinafter, preferred modes (hereinafter, referred to as "embodiments") for
carrying out the present disclosure will be described in detail with reference to the
appended drawings.
20 [0035]
[Exemplary configuration of content supply system]
A content supply system according to an embodiment of the present
disclosure can perform seamless switching between a content stream of the unicast
transmission according to the HTTP and a content stream of either of the multicast
25 transmission according to the RTP and the broadcast transmission according to the
RTP when a side of receiving and reproducing content receives content.
[0036]
Specifically, the MPD in the DASH is extended to describe a
correspondence relation between a mediaRange indicating an interval of a content
30 stream unicast-delivered according to the HTTP and an rtspRange indicating an
interval of a content stream multicast-transmitted or broadcast-transmitted according
11
to the RTP.
[0037]
A payload format is specified to be stored in an RTP packet more easily
without change, that is, without destroying the box structure of the fragmented MP4
that is the content stream chunk serving as the control 5 target of the DASH.
[0038]
FIG. 2 illustrates an exemplary configuration of a content supply system
according to an embodiment of the present disclosure.
[0039]
10 A content supply system 50 includes a content supply device 60 at a side at
which content is supplied and a plurality of DASH clients 70 at a side at which
content is received and viewed.
[0040]
The DASH client 70 can be connected to the content supply device 60 via
15 the Internet 11 and receive content that is unicast-transmitted according to the HTTP.
The DASH client 70 can receive content that is multicast-transmitted and broadcasttransmitted
from the content supply device 60 via a broadcasting network 12.
[0041]
Here, the broadcasting network 12 is assumed to include a mobile network
20 such as a Multimedia Broadcast and Multicast Service (MBMS) as well as a
television broadcasting network using a ground wave, a satellite wave, or the like.
[0042]
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
25 MPD configurator 65, a broadcast/multicast (BC/MC) resource manager 66, a DASH
client proxy 67, and a broadcast/multicast (BC/MC) service provider 68, which are
connected to one another via the Internet 11.
[0043]
The content management server 61 manages content (including live
30 broadcasting content) to be supplied to the DASH client 70, generates a plurality of
pieces of streaming data having different bit rates from content of the same subject,
12
and supplies the plurality of pieces of streaming data having different bit rates to the
DASH segment streamer 62.
[0044]
The DASH segment streamer 62 temporally divides the streaming data of
5 content.
[0045]
FIG. 3 illustrates temporal delimiting of content. In other words, the
DASH segment streamer 62 temporally delimits the streaming data of content into
periods, divides each period into segments, and holds each segment as a file as
10 illustrated in FIG. 3, and notifies the DASH MPD server 63 of an address of a supply
source of the files.
[0046]
The DASH segment streamer 62 HTTP-transmits (unicast-transmits using
the HTTP) the files of the segmented streaming data via the Internet 11 in response
15 to a request from the DASH client 70 as the HTTP server.
[0047]
The DASH MPD server 63 generates an MPD that is referenced when the
DASH client 70 acquires content unicast-transmitted according to the HTTP, and
HTTP-transmits the MPD via the Internet 11 in response to a request from the DASH
20 client 70. The DASH MPD server 63 supplies the generated MPD in response to a
request from the DASH proxy server 64.
[0048]
The MPD proxy server 64 acquires the MPD from the DASH MPD server
63, and supplies the MPD to the MPD configurator 65.
25 [0049]
The MPD configurator 65 modifies the MPD so that the DASH client 70
can acquire broadcast-transmitted and multicast-transmitted content of the same
subject as content unicast-transmitted according to the HTTP.
[0050]
30 The broadcast/multicast resource manager 66 notifies the MPD configurator
65 of resource states of the broadcast bearer and the multicast bearer.
13
[0051]
The DASH client proxy 67 transmits the modified MPD to the DASH client
70. The DASH client proxy 67 supplies the modified MPD to the
broadcast/multicast service provider 68, and multicast-transmits the modified MPD
according 5 to the FLUTE.
[0052]
The DASH client proxy 67 acquires a segment of content unicasttransmitted
from the DASH segment streamer 62, stores the acquired segment in the
payload of the RTP packet without change and without destroying the box structure,
10 supplies the resultant RTP packet to the broadcast/multicast service provider 68, and
multicast-transmits and broadcast-transmits the RTP packet according to the RTP via
the broadcasting network 12.
[0053]
The broadcast/multicast service provider 68 multicast-transmits the
15 modified MPD according to the FLUTE via the broadcasting network 12. The
broadcast/multicast service provider 68 multicast-transmits and broadcast-transmits
the RTP packet in which the segment of content is stored without change via the
broadcasting network 12.
[0054]
20 [Overview of MPD]
Next, an overview of the MPD in the DASH will be described with
reference to FIGS. 4 and 5.
[0055]
FIG. 4 illustrates a data configuration of the MPD. FIG. 5 illustrates a
25 hierarchical structure below a period in the MPD.
[0056]
In the MPD, information related to content (Media) is divided in units of
periods, and in each period, a plurality of representations including information
related to streaming data of the same subject that differs in a stream attribute such as
30 a bit rate are prepared. The representation stores information related to a segment
obtained by further temporally dividing a period.
14
[0057]
FIG. 6 illustrates a state in which a structure of the MPD is arranged on a
time axis.
[0058]
As can be understood from FIG. 6, there are a plurality of 5 representations for
the same segment of content. Thus, the DASH client 70 can adaptively select any
of the representations, perform switching to appropriate stream data according to a
communication environment, a decoding capability of the DASH client 70, or the
like, and acquire and reproduce the appropriate stream data.
10 [0059]
FIG. 7 illustrates a structure below the representation of the MPD.
[0060]
An address of the DASH segment streamer 62 serving as the supply source
of the file storing the segment of content is described in the representation.
15 Specifically, when a plurality of segments are individually held as files, a sequence
of addresses (url information) of the respective files is described. Further, when a
plurality of segments are collectively held as one file, in addition to an address (Base
URL) of the file, a sequence of ranges (mediaRange) of segments in the file is
described. FIG. 7 illustrates the latter case.
20 [0061]
FIG. 8 illustrates an example in which the structure below the representation
illustrated in FIG. 7 is described in an XML format.
[0062]
The address of the supply source of the file when a plurality of segments of
25 content are stored one file is described in
MPD/Period/AdaptationSet/Representation/BaseURL. In the case of FIG. 8,
"http://example.com/counter-10mn_avc_dash.mp4" indicates the address of the file.
[0063]
A sequence of byte ranges of the segments in the file is described in
30 MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRang
e.
15
[0064]
Thus, the DASH client 70 can acquire a desired segment by designating
"http://example.com/counter-10mn_avc_dash.mp4" as a url of the file, designating
the mediaRange to the range header, and issuing the HTTP request.
5 [0065]
For example,
MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRang
e="795-83596" indicates that a byte range of a 795-th byte to an 83596-th byte in the
file is a first segment. Similarly, next
10 MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRang
e="83597-166046" indicates that a byte range of an 83597-th byte to an 166046-th
byte in the file is a second segment.
[0066]
Thus, in order to acquire the first segment, it is desirable to designate a url
15 "http://example.com/counter-10mn_avc_dash.mp4" of the file and describe the
mediaRange "795-83596" as a range designation in the HTTP request. At this time,
the HTTP request is as follows:
GET /counter-10mn_avc_dash.mp4 HTTP/1.1
Host: example.com
20 Range: bytes=795-83596
[0067]
Similarly, in order to acquire the second segment, it is desirable to issue the
following HTTP request.
GET /counter-10mn_avc_dash.mp4 HTTP/1.1
25 Host: example.com
Range: bytes=83597-166046
[0068]
[Modification of MPD]
In the present embodiment, segmented stream data of content is supplied to
30 the DASH client 70 of the reception side through the unicast transmission according
to the HTTP, the multicast transmission according to the RTP, and the broadcast
16
transmission according to the RTP. Further, the DASH client 70 receives and
reproduces the segmented stream data of content through seamless switching.
[0069]
To this end, a ServiceLocation element is newly introduced into the MPD.
An rtspRange that corresponds to a byte range of a segment 5 unicast-delivered
according to the HTTP and indicates an interval of a stream segment multicasttransmitted
and broadcast-transmitted according to the RTP is added.
[0070]
FIG. 9 illustrates an example in which the MPD illustrated in FIG. 8 is
10 modified.
[0071]
Specifically, an rtspRange attribute is arranged in a SegmentURL element as
an attribute specifying an interval of a segment stream that serves as a switching
target of a segment unicast-transmitted according to the HTTP and is multicast15
transmitted and broadcast-transmitted according to the RTP. A
ServiceLocationAttributeUrl attribute in which a url of a ServiceLocationAttribute
file storing a ServiceLocation element as a root element is described is arranged in
the BaseURL of the MPD.
[0072]
20 A character string of a format (a UTC format) of a range parameter
identifying an RTP stream interval defined in a Real Time Streaming Protocol
(RTSP) used for control of RTP streaming specified in request for comment (RFC)
2326 is stored in the rtspRange attribute of the SegmentURL element of the modified
MPD. The format of the information stored in the rtspRange attribute is not limited
25 to the UTC format.
[0073]
For example, in the case of FIG. 9, it is illustrated that an interval of
19961108T143720.25Z to 19961108T143730.25Z of a segment stream multicasttransmitted
and broadcast-transmitted according to the RTP corresponds to a first
30 segment including data of a byte range of a 795-th byte to an 83596-th byte of a file
unicast-transmitted according to the HTTP.
17
[0074]
Similarly, it is illustrated that an interval of 19961108T143730.25Z to
19961108T143740.25Z of a segment stream multicast-transmitted and broadcasttransmitted
according to the RTP corresponds to a second segment including data of
a byte range of an 83597-th byte to an 166046-th byte of a file 5 unicast-transmitted
according to the HTTP.
[0075]
FIG. 10 illustrates an example of an XML schema of the
ServiceLocationAttribute file designated by the serviceLocationAttributeUrl attribute.
10 [0076]
FIG. 11 illustrates the ServiceLocation element that is newly introduced into
the MPD.
[0077]
The ServiceLocation element includes a tuning parameter
15 (DeliverySystemAttributes) and an IP multicast address (IPMulticastAddress). A
url of the ServiceLocationAttribute file storing the ServiceLocation element as the
root element is described in the ServiceLocationAttributeUrl attribute arranged in the
BaseURL.
[0078]
20 For example, when the multicast bearer or the broadcast bearer of the
mobile network such as the MBMS or the like is used, a format identifier
(ID_MBMS in the case of the MBMS) of the data structure of the tuning parameter
employed for the multicast transmission or the broadcast transmission according to
the MBMS or the like is described in a DeliverySystemIdentifier of the
25 DeliverySystemAttributes.
[0079]
Further, for example, when the broadcast bearer of the existing television
broadcasting network such as the DVB terrestrial network is used, the format
identifier (ID_DVB_T in the case of the DVB terrestrial network) of the data
30 structure of the tuning parameter employed for the broadcast transmission of the
DVB terrestrial network is described.
18
[0080]
A data structure (a parameter itself) of a tuning parameter specified for the
broadcast delivery or the multicast delivery identified by the
DeliverySystemIdentifier is described in a DeliverySystemDescriptor of the
DeliverySystemAttributes. In practice, a byte sequence indicating 5 a parameter is
converted into a character string by base64 or the like and then described in the
DeliverySystemDescriptor.
[0081]
FIG. 12 illustrates an example of a data structure of a user service
10 description serving as the tuning parameter employed for the multicast transmission
or the broadcast-transmission according to the MBMS.
[0082]
A bundleDescription (namespace
"urn:3GPP:metadata:2005:MBMS:userServiceDescription") is an element for
15 bundling a plurality of userServiceDescriptions (namespace
"urn:3GPP:metadata:2005:MBMS:userServiceDescription"). The
userServiceDescription is an element storing information for acquiring
(tuning/joining) a stream that is identified by a serviceId attribute and broadcasttransmitted
or multicast-transmitted according to MBMS.
20 [0083]
A deliveryMethod (namespace
"urn:3GPP:metadata:2005:MBMS:userServiceDescription") is an element
designating a Session Description Protocol (SDP) in which a multicast address of a
stream is described. Specifically, a url of an SDP file is designated by the
25 sessionDescriptionURI attribute. A Registration (namespace
"urn:3GPP:metadata:2008:MBMS:userServiceDescription") is a process (linked to
an authentication session or the like performed by activating a server side script
designated by a registrationURL attribute (when a multicast stream is encrypted and
protected)) for acquiring, for example, a protection key of a stream or the like
30 necessary for registration in a multicast service.
[0084]
19
When the UserServiceDescription structure is stored in the
DeliveryServiceDescriptor as described above, if use registration is performed
according to a process defined in a rule of an MBMS service, it is possible to acquire
an MBMS broadcast stream or an MBMS multicast stream.
5 [0085]
A content stream is assumed to be carried, according to the RTP, on an IP
packet stream having a multicast address designated by a
ServiceLocation/IPMulticastAddress element among IP packet streams on the
MBMS broadcast stream or the MBMS multicast stream acquired by the information
10 stored in the ServiceLocation/DeliverySystem element as described above. A of
FIG. 13 illustrates a hierarchical structure of a protocol in this case.
[0086]
Further, when the broadcast bearer according to the DVB terrestrial network
is used, a DVBurl format dvb://.. including a DVB_Triplet
15 specified in "ETSI TS 102 851 V1.1.1 (2010-01) Digital Video Broadcasting (DVB);
Uniform Resource Identifiers (URI) for DVB Systems" is stored as the tuning
parameter, and the broadcast stream according to the DVB terrestrial network is
acquired with reference to the DVBurl format.
[0087]
20 Here, DVB_Triplet indicates information of third items of an original
network identifier ONid stored in a network information table NIT of DVB-SI and a
transport stream identifier TSid and a service identifier Sid stored in a stream
description table SDT of DVB-SI.
[0088]
25 A content stream is assumed to be carried, according to the RTP protocol, on
an IP packet stream having a multicast address designated by the
ServiceLocation/IPMulticastAddress element among IP packet streams on the
broadcast stream according to the DVB terrestrial network acquired by the DVBurl
format stored in the ServiceLocation/DeliverySystem element as described above.
30 B of FIG. 13 illustrates a hierarchical structure of a protocol in this case.
[0089]
20
[Data structure of RTP packet]
Here, an RTP packet when a content stream is multicast-transmitted and an
RTP packet when a content stream is broadcast-transmitted will be described.
[0090]
FIG. 14 illustrates a data structure of an RTP packet. As 5 illustrated in FIG.
14, the RTP packet includes an RTP header 81 and an RTP payload 82. The RTP
header 81 includes fields of a payload header (PT) 83, a sequence number (SN) 84,
and a time stamp (TS) 85.
[0091]
10 Information indicating a type of content stored in the RTP payload 82 is
described in the payload header 83. In the case of the present embodiment,
information indicating a type of codec of content stored in the RTP payload 82 is
described. Specifically, when an AVC fragmented MP4 is stored in the RTP
payload 82, "AVC fragmented MP4 over RTP" is described, and when a HEVC
15 fragmented MP4 is stored in the RTP payload 82, "HEVC fragmented MP4 over
RTP" is described.
[0092]
Sequence numbers of the RTP packet that is consecutively transmitted are
described in the sequence number 84. It is detected whether or not there is a lost
20 packet based on the sequence number.
[0093]
In the time stamp 85, unlike an operation of the time stamp in the RTP
packet according to the related art, a transmission time of a first bit at the time of
transmission of the RTP packet and an NTP time stamp value of a 32-bit short format
25 (specified in Clause 6 of IETF RFC5905, NTP version 4) are described. Here, in
the operation of the time stamp in the RTP packet according to the related art, a time
stamp of a sampling time of a first byte of payload data of the RTP payload 82 is
described.
[0094]
30 The NTP time stamp value described in the time stamp 85 is mainly used for
jitter removal for transfer but not used for presentation time control as in the
21
operation of the time stamp according to the related art. In the case of the present
embodiment, a time stamp value derived from the box structure (a moof 97 of FIG.
15 or a moof 107 of FIG. 16) of the fragmented MP4 is used for the presentation time
control.
5 [0095]
[Data structure of RTP payload 82]
FIG. 15 illustrates a format of the RTP payload 82 when the payload header
83 indicates the "AVC fragmented MP4 over RTP," that is, when the AVC
fragmented MP4 is stored in the RTP payload 82.
10 [0096]
A of FIG. 15 illustrates a format of the RTP payload 82 of a first mode.
The RTP payload 82 of the first mode includes a PayloadMode 91, a
SegmentBoundary 92, a dash (ftyp) 93, a moov 94, a msix (styp) 95, a sidx 96, a
moof 97, an mdat header (mdat-h) 98, and an AVC over RTP payload 99.
15 [0097]
The PayloadMode 91 is a 1-byte value indicating a mode. In this case, a
value of 1 indicating the first mode is described.
[0098]
A 1-byte identifier indicating a boundary of a segment of content stored in
20 the RTP packet is described in the SegmentBoundary 92. 1 is described when a first
Network Abstraction Layer (NAL) unit of a segment of content is stored in the RTP
packet, 3 is described when a last NAL unit of the segment is stored, and 2 is
described in the other cases.
[0099]
25 A ftyp (blind name: dash) box and a moov box of an Initialization Segment
storing initialization information such as a decoder in the DASH are arranged in the
dash (ftyp) 93 and the moov 94.
[0100]
A styp (brand name: misx) box, a sidx box, and a moof box that are
30 metadata of a Media Segment storing a chunk (fragment) of media data in the DASH
and only header information including no media data of the mdat box are arranged in
22
the msix (styp) 95, the sidx 96, the moof 97, and the mdat header 98. Information
related to only one track is stored in the moof 97. The DASH client 70 calculates a
CompositionTime indicating a sampling time of a first byte of Payload data as an
RTP Timestamp based on the information stored in the moof 97.
5 [0101]
A divided first NAL unit, one NAL unit, or a plurality of NAL units
according to an RTP payload format standard (RTP Payload Format for H.264 Video)
specified in a request for comment (rfc) 3984 are stored in the AVC over RTP
payload 99.
10 [0102]
B of FIG. 15 illustrates a format of the RTP payload 82 of a second mode.
The RTP payload 82 of the second mode includes a PayloadMode 91, a
SegmentBoundary 92, a msix (styp) 95, a sidx 96, a moof 97, and an AVC over RTP
payload 99.
15 [0103]
In the case of the second mode, a value of 2 indicating the second mode is
described in the PayloadMode 91. A divided first NAL unit, one NAL unit, or a
plurality of NAL units according to the RTP payload format standard specified in the
rfc 3984 are stored in the AVC over RTP payload 99.
20 [0104]
C of FIG. 15 illustrates a format of the RTP payload 82 of a third mode.
The RTP payload 82 of the third mode includes a PayloadMode 91, a
SegmentBoundary 92, and an AVC over RTP payload 99.
[0105]
25 In the case of the third mode, a value of 3 indicating the third mode is
described in the PayloadMode 91. A divided NAL unit (excluding a first NAL unit),
one NAL unit, or a plurality of NAL units according to the RTP payload format
standard specified in the rfc 3984 are stored in the AVC over RTP payload 99.
[0106]
30 Next, FIG. 16 illustrates a format of the RTP payload 82 when the payload
header 83 indicates the "HEVC fragmented MP4 over RTP," that is, when the HEVC
23
fragmented MP4 is stored in the RTP payload 82.
[0107]
Even when the HEVC fragmented MP4 is stored in the RTP payload 82, A
to C of FIG. 16 illustrate first to third modes, similarly to the case illustrated in FIG.
5 15.
[0108]
A of FIG. 16 illustrates a format of the RTP payload 82 of a first mode. the
RTP payload 82 of the first mode includes a PayloadMode 101, a SegmentBoundary
102, a dash (ftyp) 103, a moov 104, a msix (styp) 105, a sidx 106, a moof 107, an
10 mdat header (mdat-h) 108, and a HEVC over RTP payload 109.
[0109]
The PayloadMode 101 is a 1-byte value indicating a mode. In this case, a
value of 1 indicating the first mode is described.
[0110]
15 A 1-byte identifier indicating a boundary of a segment of content stored in
the RTP packet is described in the SegmentBoundary 102. 1 is described when a
first NAL unit of a segment of content is stored in the RTP packet, 3 is described
when a last NAL unit of the segment is stored, and 2 is described in the other cases.
[0111]
20 A ftyp (brand name: dash) box and a moov box of an Initialization Segment
storing initialization information such as a decoder in the DASH are arranged in the
dash (ftyp) 103 and the moov 104.
[0112]
A styp (a brand name misx) box, a sidx box, and a moof box that are
25 metadata of a Media Segment storing a chunk (fragment) of media data in the DASH
and only header information including no media data of the mdat box are arranged in
the msix (styp) 105, the sidx 106, the moof 107, and the mdat header 98.
Information related to only one track is stored in the moof 107. The DASH client
70 calculates a CompositionTime indicating a sampling time of a first byte of
30 Payload data as an RTP Timestamp based on the information stored in the moof 107.
[0113]
24
A divided first NAL unit, one NAL unit, or a plurality of NAL units
according to an RTP payload format standard (RTP Payload Format for High
Efficiency Video Coding) specified in a draft-schierl-payload-rtp-h265-01 are stored
in the HEVC over RTP payload 108.
5 [0114]
B of FIG. 16 illustrates a format of the RTP payload 82 of a second mode.
The RTP payload 82 of the second mode includes a PayloadMode 101, a
SegmentBoundary 102, a msix (styp) 105, a sidx 106, a moof 107, and a HEVC over
RTP payload 109.
10 [0115]
In the case of the second mode, a value of 2 indicating the second mode is
described in the PayloadMode 101. A divided first NAL unit, one NAL unit, or a
plurality of NAL units according to the RTP payload format standard specified in the
draft-schierl-payload-rtp-h265-01 are stored in the HEVC over RTP payload 109.
15 [0116]
C of FIG. 16 illustrates a format of the RTP payload 82 of a third mode.
The RTP payload 82 of the third mode includes a PayloadMode 101, a
SegmentBoundary 102, and a HEVC over RTP payload 109.
[0117]
20 In the case of the third mode, a value of 3 indicating the third mode is
described in the PayloadMode 101. A divided NAL unit (excluding a first NAL
unit), one NAL unit, or a plurality of NAL units according to the RTP payload format
standard specified in the draft-schierl-payload-rtp-h265-01 are stored in the HEVC
over RTP payload 109.
25 [0118]
[Transmission pattern of RTP packet]
FIG. 17 illustrates four examples of combination patterns of the formats (the
first to third modes) employed in the RTP payloads 82 of the RTP packets that are
consecutively transmitted.
30 [0119]
In a first combination pattern illustrated in A of FIG. 17, the first mode is
25
employed in the RTP payloads 82 of all the RTP packets that are consecutively
transmitted. In the case of the first combination pattern, first to third RTP packets
correspond to one segment, and fourth and fifth RTP packets correspond to one
segment.
5 [0120]
In a second combination pattern illustrated in B of FIG. 17, the first mode,
the second mode, the second mode, the first mode, and the second mode are
employed in order in the RTP payload 82 of first to fifth RTP packets that are
consecutively transmitted. In the case of the second combination pattern, the first to
10 third RTP packets correspond to one segment, and the fourth and fifth RTP packets
correspond to one segment.
[0121]
In a third combination pattern illustrated in C of FIG. 17, the first mode, the
second mode, the third mode, the first mode, and the third mode are employed in
15 order in the RTP payload 82 of first to fifth RTP packets that are consecutively
transmitted. In the case of the third combination pattern, the first to third RTP
packets correspond to one segment, and the fourth and fifth RTP packets correspond
to one segment.
[0122]
20 In a fourth combination pattern illustrated in D of FIG. 17, the first mode,
the third mode, the third mode, the third mode, and the third mode are employed in
order in the RTP payload 82 of first to fifth RTP packets that are consecutively
transmitted. In the case of the fourth combination pattern, the first to fifth RTP
packets correspond to one segment.
25 [0123]
The combination pattern is arbitrary and not limited to the illustrated
examples, but it is necessary to employ the first mode in one or more RTP payloads
82 among one or more RTP packets stored in one segment.
[0124]
30 [Operation of content supply system 50]
Next, an operation of the content supply system 50 will be described.
26
[0125]
FIG. 18 is a flowchart for describing a first operation of the content supply
system 50. In the first operation, the DASH client 70 voluntarily requests the MPD
configurator 65 to modify the MPD.
5 [0126]
As the premise of the first operation, the DASH segment streamer 62 is
assumed to acquire a plurality of pieces of streaming data of content of the same
subject having different bit rates from the content management server 61, divide each
streaming data into segments, hold the segments, and start the unicast delivery of the
10 segment according to the HTTP.
[0127]
Further, the DASH MPD server 63 is assumed to generate the MPD based
on the address of the file of the stream segment reported by the DASH segment
streamer 62 and start the unicast delivery of the MPD according to the HTTP.
15 [0128]
In step S1, the DASH client 70 that desires to receive and reproduce content
accesses the DASH MPD server 63 via the Internet 11, and requests the DASH MPD
server 63 to transmit the MPD. The DASH client 70 is assumed to hold the address
of the DASH MPD server 63 in advance.
20 [0129]
In step S11, the DASH MPD server 63 unicast-transmits the MPD to the
DASH client 70 via the Internet 11 according to the HTTP in response to the request
from the DASH client 70.
[0130]
25 The DASH client 70 that has received the MPD accesses the DASH
segment streamer 62 based on the MPD, and receives and reproduces the stream
segment unicast-delivered according to the HTTP.
[0131]
Specifically, the HTTP request is issued based on the BaseURL and the
30 mediaRange of the MPD to request the DASH segment streamer 62 to transmit the
file of the DASH stream segment. In response to this request, the DASH segment
27
streamer 62 unicast-transmits the corresponding file to the DASH client 70 via the
Internet 11 according to the HTTP, and the DASH client 70 receives and reproduces
the corresponding file.
[0132]
During this reception, in step S2, the DASH 5 client 70 monitors a
communication band of the Internet 11, and when unicast reception via the Internet
11 appears to be unstable, and the DASH client 70 can receive multicast transmission
or broadcast transmission of content via the broadcasting network 12, the DASH
client 70 transmits the acquired MPD to the MPD configurator 65, and requests the
10 MPD configurator 65 to modify the MPD.
[0133]
In step S21, in response to the MPD modification request from the DASH
client 70, the MPD configurator 65 checks resource usage states of the broadcast
bearer and the multicast bearer through the broadcast/multicast resource manager 66.
15 Further, the MPD configurator 65 decides whether or not both the broadcast bearer
and the multicast bearer are to be used in view of the cost, and requests the
broadcast/multicast resource manager 66 to secure corresponding resources. After
receiving a notification indicating that the resources can be secured from the
broadcast/multicast resource manager 66, the MPD configurator 65 modifies the
20 MPD, and transmits the modified MPD to the DASH client 70. The transmitted
modified MPD is monitored by the DASH client proxy 67 before being received by
the DASH client 70.
[0134]
In step S31, the DASH client proxy 67 that has monitored the modified
25 MPD requests the broadcast/multicast provider 68 to periodically multicast-transmit
the MPD according to the FLUTE of the broadcasting network 12. In step S41, the
broadcast/multicast provider 68 periodically multicast-transmits the modified MPD
according to the FLUTE of the broadcasting network 12 in response to this request.
Through the multicast transmission, the modified MPD can be supplied to even the
30 DASH client 70 that has not transmitted the request to modify the MPD.
[0135]
28
In step S32, the DASH client proxy 67 requests the DASH segment
streamer 62 instead of the DASH client 70 to transmit the stream segment based on
the monitored MPD. In step S51, the DASH segment streamer 62 unicast-delivers
the stream segment to the DASH client proxy 67 according to the HTTP via the
Internet 11 in response 5 to this request.
[0136]
In step S33, the DASH client proxy 67 that has received the stream segment
unicast-delivered according to the HTTP from the DASH segment streamer 62
performs a protocol conversion of transferring the stream segment stored in the
10 HTTP packet to the RTP payload 82 of the RTP packet without change and without
excluding the box structure. The protocol conversion is performed as described
above with reference to FIG. 15 or FIG. 16.
[0137]
Further, the DASH client proxy 67 requests the broadcast/multicast provider
15 68 to multicast-transmit and broadcast-transmit the stream segment that has
undergone the protocol conversion according to the RTP via the broadcasting
network 12.
[0138]
In step S42, the broadcast/multicast provider 68 starts to multicast-transmit
20 and broadcast-transmit the stream segment whose protocol has been converted
according to the RTP via the broadcasting network 12 in response to this request.
[0139]
Thereafter, the DASH client 70 that has acquired the modified MPD
proceeds to step S3 or step S5.
25 [0140]
In other words, when the stream segment unicast-delivered according to the
HTTP via the Internet 11 is continuously received and reproduced, the process
proceeds to step S3. Further, when switching to the stream segment multicasttransmitted
or broadcast-transmitted according to the RTP via the broadcasting
30 network 12 is performed, the process proceeds to step S5.
[0141]
29
In step S3, when the unicast-delivered stream segment is continuously
received and reproduced, the DASH client 70 requests the DASH segment streamer
62 to transmit the stream segment based on the MPD. Then, in step S4, the stream
segment unicast-delivered from the DASH segment streamer 62 according to the
HTTP via the Internet 11 in response to the request (process of 5 step S52) is received
and reproduced.
[0142]
In step S5, when switching to the stream segment multicast-transmitted or
broadcast-transmitted according to the RTP via the broadcasting network 12 is
10 performed, the DASH client 70 performs reception and reproduction by switching
from the segment stream unicast-transmitted according to the HTTP to the protocolconverted
stream segment multicast-transmitted or broadcast-transmitted according
to the RTP based on the modified MPD.
[0143]
15 A timing of the switching is decided based on a correspondence relation
with a segment sequence corresponding to a representation carried in the unicast
manner depending on time interval information of the rtspRange stored in the
segment sequence corresponding to the representation corresponding to the multicast
stream on the modified MPD.
20 [0144]
The time stamp value derived from the moof 97 (or the moof 107) of the
RTP payload 82 is used for the presentation time control in the DASH client 70.
[0145]
Thereafter, seamless switching can be performed between the stream
25 segment unicast-transmitted according to the HTTP via the Internet 11 and the
stream segment multicast-transmitted or broadcast-transmitted according to the RTP
via the broadcasting network 12.
[0146]
The description of the first operation of the content supply system 50 is now
30 finished.
[0147]
30
Next, FIG. 19 is a flowchart for describing a second operation of the content
supply system 50. In the second operation, the MPD proxy server 64 requests the
MPD configurator 65 to modify the MPD as a main agent.
[0148]
As the premise of the second operation, the DASH segment 5 streamer 62 is
assumed to acquire a plurality of pieces of streaming data of content of the same
subject having different bit rates from the content management server 61, divide each
streaming data into segments, hold the segments, and start the unicast transmission of
the segment according to the HTTP.
10 [0149]
Further, the DASH MPD server 63 is assumed to generate the MPD based
on the address of the file of the stream segment reported by the DASH segment
streamer 62 and start the unicast delivery of the MPD according to the HTTP.
[0150]
15 In step S71, the DASH client 70 that desires to receive and reproduce
content accesses the DASH MPD server 63 via the Internet 11, and requests the
DASH MPD server 63 to transmit the MPD. This request is received by the MPD
proxy server 64 and in step S81, the MPD proxy server 64 requests the DASH MPD
server 63 to transmit the MPD.
20 [0151]
In step S91, the DASH MPD server 63 unicast-transmits the MPD to the
MPD proxy server 64 according to the HTTP in response to the request from the
MPD proxy server 64. In step S82, the MPD proxy server 64 that has received the
MPD transmits the received MPD to the MPD configurator 65, and requests the
25 MPD configurator 65 to modify the MPD.
[0152]
In step S101, in response to the MPD modification request, the MPD
configurator 65 checks resource usage states of the broadcast bearer and the
multicast bearer through the broadcast/multicast resource manager 66. Further, the
30 MPD configurator 65 decides whether or not both the broadcast bearer and the
multicast bearer are to be used in view of the cost, and requests the
31
broadcast/multicast resource manager 66 to secure corresponding resources. After
receiving a notification indicating that the resources can be secured from the
broadcast/multicast resource manager 66, the MPD configurator 65 modifies the
MPD, and transmits the modified MPD to the MPD proxy server 64.
5 [0153]
In step S83, the MPD proxy server 64 transmits the modified MPD to the
DASH client 70. The transmitted modified MPD is monitored by the DASH client
proxy 67 before received by the DASH client 70.
[0154]
10 In step S111, the DASH client proxy 67 that has monitored the modified
MPD requests the broadcast/multicast provider 68 to periodically multicast-transmit
the MPD according to the FLUTE of the broadcasting network 12. In step S121,
the broadcast/multicast provider 68 periodically multicast-transmits the modified
MPD according to the FLUTE of the broadcasting network 12 in response to this
15 request. Through the multicast transmission, the modified MPD can be supplied to
even the DASH client 70 that has not transmitted the request to modify the MPD.
[0155]
In step S112, the DASH client proxy 67 requests the DASH segment
streamer 62 instead of the DASH client 70 to transmit the stream segment based on
20 the monitored modified MPD. In step S131, the DASH segment streamer 62
unicast-transmits the stream segment to the DASH client proxy 67 according to the
HTTP via the Internet 11 in response to this request.
[0156]
In step S113, the DASH client proxy 67 that has received the stream
25 segment unicast-transmitted according to the HTTP from the DASH segment
streamer 62 performs a protocol conversion of transferring the stream segment stored
in the HTTP packet to the RTP payload 82 of the RTP packet without change and
without excluding the box structure. The protocol conversion is performed as
described above with reference to FIG. 15 or FIG. 16.
30 [0157]
Further, the DASH client proxy 67 requests the broadcast/multicast provider
32
68 to multicast-transmit and broadcast-transmit the stream segment that has
undergone the protocol conversion according to the RTP via the broadcasting
network 12.
[0158]
In step S122, the broadcast/multicast provider 68 starts 5 to multicast-transmit
and broadcast-transmit the stream segment whose protocol has been converted
according to the RTP via the broadcasting network 12 in response to this request.
[0159]
Meanwhile, the DASH client 70 holds the modified MPD acquired
10 previously. In step S72, the DASH client 70 selects whether the unicast
transmission via the Internet 11 is to be received or the multicast transmission or the
broadcast transmission via the broadcasting network 12 is to be received based on the
communication band state of the Internet 11, the reception function and the decoding
function of the DASH client 70, or the like.
15 [0160]
When the reception and reproduction of the stream segment unicastdelivered
according to the HTTP via the Internet 11 are selected, the process
proceeds to step S73. In step S73, the DASH client 70 requests the DASH segment
streamer 62 to transmit the stream segment based on the MPD. Then, in step S74,
20 the stream segment unicast-transmitted from the DASH segment streamer 62
according to the HTTP via the Internet 11 in response to the request (process of step
S132) is received and reproduced.
[0161]
Further, when the reception and reception of the stream segment multicast25
transmitted or broadcast-transmitted according to the RTP via the broadcasting
network 12 are selected in step S72, the process proceeds to step S75. In step S75,
the DASH client 70 receives and reproduces the protocol-converted stream segment
multicast-transmitted or broadcast-transmitted according to the RTP based on the
modified MPD.
30 [0162]
The time stamp value derived from the moof 97 (or the moof 107) of the
33
RTP payload 82 is used for the presentation time control in the DASH client 70.
[0163]
Thereafter, seamless switching can be performed between the stream
segment unicast-transmitted according to the HTTP via the Internet 11 and the
stream segment multicast-transmitted or broadcast-transmitted 5 according to the RTP
via the broadcasting network 12.
[0164]
The description of the second operation of the content supply system 50 is
now finished.
10 [0165]
As described above, the content supply system 50 according to the present
embodiment can perform seamless switching between the stream segment unicasttransmitted
according to the HTTP via the Internet 11 and the stream segment
multicast-transmitted or broadcast-transmitted according to the RTP via the
15 broadcasting network 12. Thus, the user of the DASH client 70 can adaptively
select and view streams of content of the same subject having different paths.
[0166]
Further, the content supply system 50 according to the present embodiment
can store the stream segment unicast-transmitted according to the HTTP in the RTP
20 packet without change and without destroying the box structure and multicasttransmit
or broadcast-transmit the resultant RTP packet. Thus, the content supply
side can easily prepare an alternative path in the DASH.
[0167]
By the way, each of the content supply device 60 and the DASH client 70
25 that execute a series of processes described above can be configured with hardware
or can be implemented by executing software through a computer. Examples of the
computer include a computer embedded in dedicated hardware and a general-purpose
personal computer capable of installing various kinds of programs and executing
various kinds of functions.
30 [0168]
FIG. 206 is a block diagram illustrating an exemplary hardware
34
configuration of the computer.
[0169]
In a computer 200, a central processing unit (CPU) 201, a read only memory
(ROM) 202, and a random access memory (RAM) 203 are connected with one
another 5 via a bus 204.
[0170]
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.
10 [0171]
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 includes a network interface. The drive 220 drives a removable medium 211
15 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor
memory.
[0172]
In the computer 200 having the above-described configuration, for example,
a series of processes described above are performed by loading a program stored in
20 the storage unit 208 onto the RAM 203 through the input/output interface 205 and
the bus 204 and executing the loaded program through the CPU 201.
[0173]
For example, the program executed by the computer 200 (the CPU 201)
may be recorded in the removable medium 211 serving as a package medium or the
25 like and provided. The program may be provided via a wired or wireless
transmission medium such as a local area network, the Internet, or digital satellite
broadcasting.
[0174]
In the computer 200, the removable medium 211 may be mounted on the
30 drive 220, and the program may be installed in the storage unit 208 through the
input/output interface 205. The program may be received by the communication
35
unit 209 via a wired or wireless transmission medium and installed in the storage unit
208. Moreover, the program may be installed in the ROM 202 or the storage unit
208 in advance.
[0175]
Further, the program executed by the computer 200 5 may be a program in
which a process is chronologically performed according to the sequence described in
the present specification or may be a program in which a process is performed in
parallel or at a necessary timing, for example, when calling is performed.
[0176]
10 An embodiment of the present disclosure is not limited to the above
embodiments, and various changes can be made within the scope not departing from
the gist of the present disclosure.
[0177]
Additionally, the present technology may also be configured as below.
15 (1)
A content supply device that supplies streaming data of content according to
MPEG-DASH, the content supply device including:
a HTTP transmitting unit configured to convert the streaming data into files
in units of segments and unicast-transmit the resulting segment files according to
20 HTTP;
an RTP transmitting unit configured to store the segment file in an RTP
packet without change and transmit the RTP packet through at least one of
multicasting and broadcasting according to RTP; and
a metafile generating unit configured to generate a metafile in which a
25 temporal correspondence relation between the segment file unicast-transmitted
according to the HTTP and the segment file transmitted through the at least one of
the multicasting and the broadcasting according to the RTP is described and supply
the metafile to a reception side.
(2)
30 The content supply device according to (1),
wherein the streaming data of the content is a fragmented MP4, and
36
wherein the RTP transmitting unit stores the segment file in the RTP packet
while maintaining a box structure of the fragmented MP4, and transmits the RTP
packet through the at least one of the multicasting and the broadcasting according to
the RTP.
5 (3)
The content supply device according to (1) or (2),
wherein the RTP transmitting unit describes a transmission time of a first bit
at a time of transmission of the RTP packet in a time stamp field of an RTP header of
the RTP packet.
10 (4)
The content supply device according to any of (1) to (2),
wherein the RTP transmitting unit describes information indicating a mode
of an RTP payload and information indicating a segment boundary in the RTP
payload of the RTP packet, and arranges an NAL unit in payload data.
15 (5)
The content supply device according to (4),
wherein the RTP transmitting unit arranges both metadata of an
Initialization Segment and metadata of a Media Segment specified in the MPEGDASH
in an RTP payload of the RTP packet, arranges the metadata of the Media
20 Segment in the RTP payload of the RTP packet, or arranges neither of the metadata
of the Initialization Segment and the metadata of the Media Segment in the RTP
payload of the RTP packet.
Reference Signs List
25 [0178]
11 Internet
12 broadcasting network
50 content supply system
60 content supply device
30 61 content management server
62 DASH segment streamer
37
63 DASH MPD server
64 MPD proxy server
65 MPD configurator
66 broadcast/multicast resource manager
5 67 DASH client proxy
68 broadcast/multicast service provider
70 DASH client
200 computer
201 CPU
10
38
We Claim:
Claim 1
A content supply device that supplies streaming data of content according to
MPEG-DASH, the content supply 5 device comprising:
a HTTP transmitting unit configured to convert the streaming data, whose
data format is a fragmented MP4, into files in units of segments and unicast-transmit
the resulting segment files according to HTTP;
an RTP transmitting unit configured to store the segment file in an RTP
10 packet without change and without destroying a box structure of the fragmented MP4
and transmit the RTP packet through at least one of multicasting and broadcasting
according to RTP; and
a metafile generating unit configured to generate a metafile in which a
temporal correspondence relation between the segment file unicast-transmitted
15 according to the HTTP and the segment file transmitted through the at least one of
the multicasting and the broadcasting according to the RTP is described and supply
the metafile to a reception side.
Claim 2
20 The content supply device according to claim 1,
wherein the RTP transmitting unit describes a transmission time of a first bit
at a time of transmission of the RTP packet in a time stamp field of an RTP header of
the RTP packet.
25 Claim 3
The content supply device according to claim 2,
wherein the RTP transmitting unit describes information indicating a mode
of an RTP payload and information indicating a segment boundary in the RTP
payload of the RTP packet, and arranges an NAL unit in payload data.
30
39
Claim 4
The content supply device according to claim 2,
wherein the RTP transmitting unit arranges both metadata of an
Initialization Segment and metadata of a Media Segment specified in the MPEGDASH
in an RTP payload of the RTP packet, arranges the 5 metadata of the Media
Segment in the RTP payload of the RTP packet, or arranges neither of the metadata
of the Initialization Segment and the metadata of the Media Segment in the RTP
payload of the RTP packet.
10 Claim 5
A content supply method of a content supply device that supplies streaming data of
content according to MPEG-DASH, the content supply method comprising:
a HTTP transmission step of converting the streaming data, whose data
format is a fragmented MP4, into files in units of segments and unicast-transmitting
15 the resulting segment files according to HTTP through the content supply device;
an RTP transmission step of storing the segment file in an RTP packet
without change and without destroying a box structure of the fragmented MP4 and
transmitting the RTP packet through at least one of multicasting and broadcasting
according to RTP through the content supply device; and
20 a metafile generation step of generating a metafile in which a temporal
correspondence relation between the segment file unicast-transmitted according to
the HTTP and the segment file transmitted through the at least one of the
multicasting and the broadcasting according to the RTP is described and supplying
the metafile to a reception side through the content supply device.
25
Claim 6
A program causing a computer that supplies streaming data of content according to
MPEG-DASH to function as:
a HTTP transmitting unit configured to convert the streaming data into files
30 in units of segments and unicast-transmit the resulting segment files according to
HTTP;
40
an RTP transmitting unit configured to store the segment file, whose data
format is a fragmented MP4, in an RTP packet without change and without
destroying a box structure of the fragmented MP4 and transmit the RTP packet
through at least one of multicasting and broadcasting according to RTP; and
a metafile generating unit configured to generate a 5 metafile in which a
temporal correspondence relation between the segment file unicast-transmitted
according to the HTTP and the segment file transmitted through the at least one of
the multicasting and the broadcasting according to the RTP is described and supply
the metafile to a reception side.
10
Claim 7
A content supply system comprising:
a content supply device configured to supply streaming data of content
according to MPEG-DASH; and
15 a client device configured to receive the stream data,
wherein the content supply device includes
a HTTP transmitting unit configured to convert the streaming data,
whose data format is a fragmented MP4, into files in units of segments and unicasttransmit
the resulting segment files according to HTTP,
20 an RTP transmitting unit configured to store the segment file in an
RTP packet without change and without destroying a box structure of the fragmented
MP4 and transmit the RTP packet through at least one of multicasting and
broadcasting according to RTP, and
a metafile generating unit configured to generate a metafile in
25 which a temporal correspondence relation between the segment file unicasttransmitted
according to the HTTP and the segment file transmitted through the at
least one of the multicasting and the broadcasting according to the RTP is described
and supply the metafile to a reception side, and
wherein the client device performs switching between the segment file
30 unicast-transmitted according to the HTTP and the segment file transmitted through
the at least one of the multicasting and the broadcasting according to the RTP based
41
on the acquired metafile, and receives and reproduces the segment file.