Description
Title of Invention
CONTENT SUPPLY DEVICE, CONTENT SUPPLY METHOD, PROGRAM, TERMINAL DEVICE, AND CONTENT SUPPLY SYSTEM5
Technical Field
[0001]
The present disclosure relates to a content supply device, a content supply method, a program, a terminal device, and a content supply system, and in particular 10 to a content supply device, a content supply method, a program, a terminal device, and a content supply systemsuited for use when delivering content over FLUTE (File Delivery over Unidirectional Transport) multicast.
Background Art15
[0002]
In recent years, the mainstream of streaming services utilizing the Internet has been OTT-V (Over The Top Video), and as a globally standardized moving picture delivery protocol that can be used for it, there is known the MPEG-DASH (Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP, 20 hereinbelow called DASH), which uses HTTP similar to the browsing of websites and the like (for example, refer to Non-Patent Literature 1).
[0003]
In DASH, adaptive streaming technology is achieved. That is to say, on the content supply side, multiple streams of the same content but whose bit rates 25 differ by differences inimage quality and field angle size are prepared and delivered. On the other hand, the reception side can select, receive and play backthe optimum stream in accordance withthe Internet communication environment, its own decoding capability, and the like among the plurality of streams the supply side has prepared.30
[0004]3

Metafiles called MPD (Media Presentation Description) are supplied from the supply side to the reception side so that the reception side can adaptively select, receive, and play backstreams.
[0005]
The address (urlinformation) of the server supplying streams of chunked 5 content (media data such as Audio/Video/Subtitle) is describedin the MPD. The reception side, based on the urlinformation, accesses the server that is the supply source of the content to requesta stream, receives the stream delivered over HTTPunicastfrom the server in accordance with the request, and plays it back.
[0006]10
FIG. 1 shows an example of the constitution of a content supply system that streams content based on DASH.
[0007]
This content supply system 10 is constituted from a plurality of content supply devices 20 that supply content and a plurality of DASH clients 30 that receive 15 and play back content. The DASH client 30 is connected to the content supply device 20 via a CDN (Contents Delivery Network) 12 that utilizes the Internet 11.
[0008]
The content supply device 20 delivers a plurality of streams having the same content but different bit rates. The content supply device 20 has a content 20 management server 21, a DASH segment streamer 22, and a DASH MPD server 23.
[0009]
The content managementserver 21 manages the source data of content for delivery to the DASH client 30, generates a plurality of streaming data of different bit rates from the source data and outputs them to the DASH segment streamer 22.25
[0010]
The DASH segment streamer 22, bydividing each streaming data temporally into segments, to generate a segment stream such as Fragmented MP4 and the like, and files and holds the generated segment stream. Moreover, the DASH segment streamer 22, as a WEB server, in accordance with a request (HTTP 30 request) from the DASH client 30, delivers over HTTPunicastthe file of the 4

segment stream it holdsto the request source.Furthermore, the DASH segment streamer 22 notifies the DASH MPD server 23 of metadataincluding the address expressing thesupply source of the segment stream file.
[0011]
The DASH MPD server 23 generates an MPD containing an address or the 5 like indicating the supply source (that is, the DASH segment streamer 22) of the segment stream file. Also, the DASH MPD server 23, as a WEB server, in accordance with a request (HTTP request) from the DASH client 30, delivers over HTTPunicastthe generated MPDto the request source.
[0012]10
The DASH client 30 requests the MPD from the DASH MPD server 23, and in response, receives the MPD delivered over HTTPunicast. Moreover, the DASH client 30, based on the received MPD, requests a segment stream file from the DASH segment streamer 22, and in response receives and plays back the segment stream file that is delivered over HTTPunicast.15
[0013]
Note that the CDN 12 includes a caching server (not illustrated), and the caching server caches the MPD and segment stream file deliveredover HTTPunicastvia the CDN12. The caching server, instead of the DASH MPD server 23 or the DASH segment streamer 22 as WEB servers, can deliver over HTTPunicastthe 20 cached MPD andsegment stream file to the DASH client 30 of the request source.
Citation List
Non-Patent Literature
[0014]25
Non-Patent Literature 1:Hirabayashi, Mitsuhiro. “Realizing Moving Image Delivery With No Drop-outs in an Existing Web Server.”Nikkei Electronics, March 19, 2012
Summary of Invention30
Technical Problem5

[0015]
As mentioned above, in DASH, adaptive streaming technology is achieved using HTTP unicastdelivery.
[0016]
If the reception side is compatible not only with HTTPunicastdeliverybut 5 also FLUTEmulticastdelivery using for example a mobile telephone communication network, it is desirable to use it for delivering a streamto be able to adaptively select a stream on thereception side.
[0017]
That is, in FLUTEmulticastdelivery, since the QoS (guaranteed 10 band/delay) is guaranteed, in the case of delivering content in which a real-time property is required such as live video, compared to HTTPunicastdelivery stable reception and playback can be expected on the reception side.
[0018]
However, in the case of the reception side receiving and playing back a 15 stream that is delivered over FLUTEmulticast, when, after starting to receive theFLUTE session, the FDT contained therein is not analyzed, it is not possible to know the content of the packets (ALC/LCT packets) being transmitted in the FLUTE session. In contrast, in acquiring packets that are transmitted in a subsequent FLUTE session after receiving and analyzing the FDT, it is sometimes not possible 20 to receive the desired packets. In particular, in cases whereimmediacy is required such as in live streaming and retransmission frequency of the same packet is low, that tendency increases.
[0019]
Accordingly,if the reception side acquiring a FLUTE session were notified 25 of the reception mode,such as “Necessaryto acquire all packets (meaning since thesame packets will not be resent or the retransmission frequency is low, it is better to receive all packets)”, it wouldbe convenient for the reception side. However, presently such a method has not been established.
[0020]30
The present disclosure was achieved in view of the above circumstances, 6

and is able to notify the reception side that acquires a FLUTE session of a reception mode.
Solution to Problem
[0021]5
According to a first aspect of the present disclosure, a content supply device that delivers content over FLUTE multicast includes: a fragment stream generating portion that generates a fragment stream on the basis of source data of the content; a FLUTE-stream generating portion that generates a FLUTE stream from the generated fragment stream; an SDP creation portion that creates an SDP including a 10 reception mode in the case of a reception side receiving a FLUTE session including the FLUTE stream; and a multicast delivery portion that delivers the FLUTE stream over FLUTE multicast and, prior to delivery of the FLUTE stream over FLUTE multicast, delivers the SDP over FLUTE multicast.
[0022]15
The SDP creation portioncan create the SDP including as the receptionmode any of Promiscuous, One-copy, and Keep-updated.
[0023]
The SDP creation portion can createthe SDP including as the reception mode any of Promiscuous, One-copy, Keep-updated, and combinations of the 20 Promiscuous, the One-copy, and the Keep-updated.
[0024]
The SDP creation portion can create the SDP additionally including an attribute type showing that the FLUTE session includes an elementary stream of a single media type.25
[0025]
The content supply deviceaccording to the first aspect of the present disclosure can further include:a unicast delivery portion that delivers over HTTP unicast the generated fragment stream.
[0026]30
According to the first aspect of the present disclosure, acontent supply 7

methodof a content supplydevice that delivers content over FLUTE multicast includes:a fragment stream generating step of generating, by the content supply device, a fragment stream on the basis of source data of the content;a FLUTE-stream generating step of generating, by the content supply device, a FLUTE stream from the generated fragment stream;an SDP creation step of creating, by the content 5 supply device, an SDP including a reception mode in the case of a reception side receiving a FLUTE session including the FLUTE stream; anda multicast delivery step of delivering, by the content supply device, the FLUTE stream over FLUTE multicast and, prior to delivery of the FLUTE stream over FLUTE multicast, delivering the SDP over FLUTE multicast.10
[0027]
According to thefirst aspect of the present disclosure,aprogram causes a computer that delivers content over FLUTE multicast to function as:a fragment stream generating portion that generates a fragment stream on the basis of source data of the content;a FLUTE-stream generating portion that generates a FLUTE 15 stream from the generated fragment stream;an SDP creation portion that creates an SDP including a reception mode in the case of a reception side receiving a FLUTE session including the FLUTE stream; andamulticast delivery portion that delivers the FLUTE stream over FLUTE multicast and, prior to delivery of the FLUTE stream over FLUTE multicast, delivers the SDP over FLUTE multicast.20
[0028]
In the first aspect of the present disclosure, a fragment streamis generated on the basis of source dataof content, a FLUTE stream is generated from the fragment streamthat is generated, an SDP including thereception mode when the reception side receives a FLUTE session including the FLUTE stream is created, and 25 the SDP is delivered over FLUTE multicast prior to FLUTE multicast delivery of the FLUTE stream.
[0029]
According to a secondaspect of the present disclosure,a terminal device receives and plays back a FLUTE stream delivered over FLUTE multicast from a 30 content supply device including a fragment stream generating portion that generates 8

a fragment stream on the basis of source data of content, a FLUTE-stream generating portion that generates the FLUTE stream from the generated fragment stream, an SDP creation portion that creates an SDP including a reception mode in the case of a reception side receiving a FLUTE session including the FLUTE stream, and a multicast delivery portion that delivers the FLUTE stream over FLUTE multicast and, 5 prior to delivery of the FLUTE stream over FLUTE multicast, delivers the SDP over FLUTE multicast. The terminal device acquires the SDP prior to reception of the FLUTE stream, and in accordance with the reception mode included in the SDP, receives the FLUTE stream.
[0030]10
In the case of acquiring the SDP prior to reception of the FLUTE stream, and the reception mode included in the SDP being promiscuous, the terminal device according to thesecondaspect of the present disclosurecan receiveall packets of the FLUTE session including the FLUTE stream.
[0031]15
In the second aspect of the present disclosure, an SDP is acquired prior to reception of the FLUTE stream, and in accordance with the reception mode included in the SDP, the FLUTE stream is received.
[0032]
According to a thirdaspect of the present disclosure,a content supply 20 system includes: a content supply device; and a terminal device.The content supply device includes a fragment stream generating portion that generates a fragment stream on the basis of source data of content, a FLUTE-stream generating portion that generates a FLUTE stream from the generated fragment stream, an SDP creation portion that creates an SDP including a reception mode in the case of a 25 reception side receiving a FLUTE session including the FLUTE stream, and a multicast delivery portion that delivers the FLUTE stream over FLUTE multicast and, prior to delivery of the FLUTE stream over FLUTE multicast, delivers the SDP over FLUTE multicast. The terminal device acquires the SDP prior to reception of the FLUTE stream, and in accordance with the reception mode included in the SDP, 30 receives the FLUTE stream.9

[0033]
In the third aspect of the present disclosure, by a content supply device,a fragment stream is generatedon the basis of source dataof content, a FLUTE stream is generated from the fragment stream that is generated, an SDP including thereception mode when the reception side receives a FLUTE session including the 5 FLUTE stream is created, and the SDP is delivered over FLUTE multicast prior to FLUTE multicast delivery of the FLUTE stream.Also, by a terminal device, an SDP is acquired prior to reception of the FLUTE stream, and in accordance with the reception mode included in the SDP, the FLUTE stream is received.
10
Advantageous Effects of Invention
[0034]
According to the first aspect of the presentdisclosure,it is possible to notify a reception side that acquires a FLUTE session of a reception mode.
[0035]15
According to the second aspect of the presentdisclosure,it is possible to inhibit the omission of packets transmitted in a FLUTE session.
[0036]
According to the third aspect of the presentdisclosure,it is possible to deliver a content stream over FLUTE multicast.20
Brief Description of Drawings
[0037]
[FIG. 1] FIG. 1 isa block drawing that shows an example of the constitution of a conventional content supply system.25
[FIG. 2] FIG. 2 is a drawing that showsan outline of the scheme in which packets are transmitted in a FLUTE session.
[FIG. 3] FIG. 3 is a block drawing that showsa configuration example of the content supply system that applies the present disclosure.
[FIG. 4] FIG. 4 is a drawing that shows an SDP description example.30
[FIG. 5] FIG. 5 is a flowchart that describes the processingof the content supply 10

device.
[FIG. 6] FIG. 6 is a block drawing that shows a configuration example of a computer.
Description of Embodiments
5
[0038]
Hereinafter, the best mode for carrying out the present disclosure (henceforth called the embodiment) will be described, but prior to that the scheme of packets being transmitted in a FLUTE session and an outline of the present embodiment will be described.10
[0039]
FIG. 2 shows an outline of the scheme of packets being transmitted in a FLUTE session. As shown in the drawing, in a FLUTE session specified by Source IP Address and TSI (Transport Session Identifier), ALC/LCT packets are transmitted. In each ALC/LCT packet, for example a video stream oraudio stream isstored, and a 15 unique TOI (Transport Object Identifier) is given in the FLUTE session. Note that it is specified that TOI=0 be given to ALC/LCT packets in which the FDT (File Delivery Table) is housed.For packets in which other data is stored, when the data source is the same, a common TOI is given. For example, a common TOI is given to all ALC/LCT packets in which a video stream is divided and housed.Similarly, a 20 common TOI is given to all ALC/LCT packets in which an audio stream is divided and housed.
[0040]
The FDT is periodically transmitted during a FLUTE session, with attribute information relating to data housed in ALC/LCT packets other than TOI=0 and 25 information for reconstructingthem being described therein.
[0041]
The side receivingthe FLUTE sessionobtainsthe TOI=0 FDT bythe FLUTE session, and by analyzing the obtained FDT receives the desired ALC/LCT packets. For example, in the case of wanting to receive ALC/LCT packets in which 30 a video stream is housed, it analyzes the FDT, confirms the TOI of the ALC/LCT 11

packets in which the video stream is housed, acquiresthe ALC/LCT packets to which the TOI is given from the FLUTE session, performs reconstructionand playback.
[0042]
However, in such a case, during acquisition and analysis of the FDT, the ALC/LCT packets in which a desired video stream is housed cannot be received, and 5 so not being able to play back the desired video stream without drop-outs may occur.This is noticeablewhen the retransmission frequency of ALC/LCT packets is low, or when retransmission is not performed such as during live streaming.
[0043]
Therefore, in the present embodiment,to transmit the elementary stream of 10 a single media type by a FLUTE session, prior to acquiring the FLUTE session, using the SDP (Session Media Protocol) transmitted by the FLUTE presentation layer, it attempts to notify the reception side of the media type and reception mode.
[0044]
Here, the three types of Promiscuous, One-copy, and Keep-update that are 15 defined by 3GPP are envisionedas the reception modes.
[0045]
Promiscuous is a reception mode for urging the reception side to receive all ALC/LCT packets that are transmitted in a FLUTE session.Notification of the employment of promiscuous is assumed when for example the retransmission 20 frequency of ALC/LCT packets is low, or when retransmission is not performed such as during live streaming.
[0046]
One-copy is a reception mode for notifying the reception side that there is no need to monitor for the presence of an update tothe ALC/LCT packets sincethere 25 is no transmission of an update to the content of the ALC/LCTpackets which have beenonce transmitted. Keep-updated is a receptionmode for notifying the reception side that there is a need to monitor for the presence of an update to the ALC/LCT packets since there will be the transmission of an update to the content of the ALC/LCT packets which have beenonce transmitted.30
[0047]12

Moreover, it is possible to add combinations of the aforementioned three types of reception modes, for example, Promiscuous+Keep-updated, to the receptions modes.
[0048]
Configuration Example of Content Supply System5
FIG. 3 shows a configuration example of the content supply system that is the embodiment of the present disclosure.
[0049]
The content supply system 50 is constituted from a plurality of content supply devices 60 and a plurality of terminal devices 80. The content supply 10 devices 60 and the terminal devices 80 can be connected via a network 51.
[0050]
The network 51 is one that includes, besides a two-way communication networkrepresented by the Internet and a CDN that uses it, various broadcast networks using terrestrial broadcasting,satellite broadcasting,and mobile broadcast 15 (e)MBMS.
[0051]
The content supply device 60delivers content streams both over HTTP unicast and over FLUTE multicast, and has a channel server 61, a segmenter 62, an MPD generator 63, a FLUTE streamer 64, a WEBserver 65, and a multicast server 20 66.
[0052]
Note that the channel server 61 to the multicast server 66 that the content supply device 60 has may be arranged integrally in one location, and may be arranged distributed over the Internet or the like.25
[0053]
The channel server 61 generates a plurality of streaming data of differing bit rates from source data of the content for delivery to the terminal devices 80 and outputs them to the segmenter 62.
[0054]30
The segmenter 62, by dividing each streaming data temporally into 13

segments, generates a segment stream such as Fragmented MP4 and outputs the generated segment stream to the FLUTE streamer 64 and the WEB server 65. Also, the segmenter 62 notifies the MPD generator 63 of metadata including an address that expresses the supply source of the file of the segment stream.
[0055]5
The FLUTE streamer 64 converts the segment streams sequentially input from the segmenter 62 to FLUTE streams and outputs them to the multicast server 66. In addition, the FLUTE streamer 64 stores the MPD generated by the MPD generator 63 in the FLUTE packets and outputs them to the multicast server 66. Furthermore, the FLUTE streamer 64 createsthe SDP relating to the FLUTE session and outputs it 10 to the multicast server 66.
[0056]
The MPD generator 63, based on the metadata notified from the segmenter 62, generates an MPD that describes the address and the like expressing the supply source of the segment stream file (WEB server 65) and outputs it to the FLUTE 15 streamer 64 and the WEB server 65. In this MPD is described the acquisition source of the SDP in which is described the source IP address of the FLUTE session of the FLUTE stream delivered over FLUTE multicast,switchable from the segment stream delivered over HTTP unicast.
[0057]20
The WEB server65,in accordance with the MPD request (HTTP request) from the terminal device 80, delivers over HTTP unicast the MPD inputted from the MPD generator 63to the request source. Also, the WEBserver 65, in accordance with the segment-stream request (HTTP request) from the terminal device 80,delivers over HTTP unicast the file of the segment stream to the request source.25
[0058]
The multicast server 66 delivers over FLUTE multicast the MPD.Also, the multicast server 66 delivers overFLUTE multicast the SDP.In addition, the multicast server 66 delivers over FLUTE multicast the FLUTE stream.
[0059]30
The terminal device 80 acquires the MPD from the content supply device 60 14

via the network 51. Specifically,it transmitsan HTTP request, and in response either receives the MPD delivered over HTTP unicast, or receives the MPD delivered over FLUTE multicast. Note that when the terminal device 80 receives an MPD delivered over FLUTE multicast, announcement information containing the portal channel of the multicast server 66 performing the FLUTE multicastdelivery is5 referenced.
[0060]
The announcement information is well known via the interaction channel or broadcast/multicast channel by the USD (User Service Description) in MBMS when FLUTE multicast delivery is performed via a mobile broadcast (e)MBMS contained 10 in the network 51. The announcement information is well known via the interaction channel or broadcast/multicast channel by the DVB-H(IPDC) ESG (Electronic Service Guide), when FLUTE multicast delivery is performed over a terrestrial broadcast or satellite broadcast contained in the network 51.
[0061]15
Also, the terminal device 80 requests a segment stream from the WEB server 65 based on the acquired MPD, and in response receives and plays back the segment stream file delivered over HTTP multicast.
[0062]
Moreover, the terminal device 80 acquires the SDP based on the acquired 20 MPD, and receives and plays back the FLUTE stream delivered over FLUTE multicastbased on the SDP. At this time, the reception mode described in the SDP is referenced, and so for example if the reception mode is Promiscuous, all of the ALC/LCT packets being transmittedin the corresponding FLUTE session are immediately received.25
[0063]
However, since it is possible that the reception side does not have a sufficient buffer for holding all of the ALC/LCT packets, it is left to the receiving side whether or not it executes an operation corresponding to the reception mode notified by the SDP.30
[0064]15

SDP Description Example
Next, FIG. 4 shows a description example of an SDP.
[0065]
The SDP is constituted froma session description and a media description, with each includinga plurality of lines having as a basic constitution a single text 5 stringin the format of =. is designated by one alphabetic character, and expresses the meaning over the protocol that a line has. is the character string that is described, and depending on the type of the corresponding , a uniqueformat and meaningare respectively specified.
[0066]10
For example, the meaning of the text described in of the session description is as follows.
v=(protocol version)
o=(transmission source and session identifier)
s=(session name)15
i=(session information)
a=(attribute concerning entire session)
t=(time that session is active)
[0067]
The meaning of the text described in of the media description is as 20 follows.
m=(media name and transmission address)
c=(connection information –option when including in a session label option)
b=(ban information of 0 or more lines)25
a=attribute relating to media)
[0068]
In the present embodiment, the attribute classification defined by the format shown below is introduced in the media description.
a=single-fmt:30
[0069]16

shows the media type, describing for example video, audio and the like.
shows the encoding format, and describes H.264, H.261, GSM (registered trademark) and the like.
shows the reception mode, and promiscuous, One-copy, or 5 Keep-updated is described. Note that it is also possible to add a combination such as Promiscuous+Keep-updated to the reception mode.
[0070]
a=single-fmt:video H264/9000 promiscouos described in the example of FIG. 4 indicates that the media type is video, the encoding format is H.264, the time 10 scale is 90KHz, and the reception mode is promiscouos.
[0071]
Note that a=single-fmt: may also be introduced in the session description. In that case, the attribute classification is handled as information relating to the entire FLUTE session.15
[0072]
Operation of Content Supply System 50
Next, the operation of the content supply system 50 will be described.
[0073]
FIG. 5 is a flowchart that describes the process of the content supply device 20 60 delivering a segment stream of content over HTTP unicast, and delivering a FLUTE stream over FLUTE multicast (hereinbelow called the content supply device process).
[0074]
In Step S1, the channel server 61 generates a plurality of streaming data of 25 differing bit rates from the source data of the content for delivery to the terminal device 80 and outputs them to the segmenter 62. In Step S2, the segmenter 62 generates a segment stream such as fragmented MP4 based on each streaming data and outputs it to the FLUTE streamer 64 and the WEB server 65. Also, the segmenter 62 informs the MPD generator 63 of the metadata including the address 30 showing the supply source of the segment stream.17

[0075]
In Step S3, the FLUTE streamer 64 converts the segment stream input from the segmenter 62 to a FLUTE stream and outputs it to the multicast server 66. Also, the FLUTE streamer 64 stores the MPD generated bythe MPD generated 63 in the FLUTE packetsand outputs them to the multicast server 66. Moreover, the FLUTE 5 streamer 64 generates anSDP relating to the FLUTE session and outputs it the multicast server 66.
[0076]
In Step S4, the MDP generator 63 generates an MPD describing the address expressingthe supply source (WEB server 65) of the file of the segment stream 10 being delivered over HTTP unicast, and the acquisition source of the SDP in which is described the source IP address of the FLUTEsession of the FLUTE stream delivered over FLUTE multicast, switchable from the segment stream, and outputs it to the multicast server 66.
[0077]15
In Step S5, the multicast server 66 delivers the MPD and the SDP over FLUTE multicast.
[0078]
In Step S6, in the case of there being an MPD request from the terminal device 80, the WEB server 65 delivers over HTTP unicast the MPD input from the 20 MPD generator 63 to the request source.
[0079]
When the terminal device 80 that received the MPD issues an HTTP request requesting a segment stream based on the MPD, in Step S7, the WEB server 65 delivers over HTTP unicast the file of the requested segment stream to the request 25 source. The segment stream delivered over HTTP unicast is received and played back by the terminal device 80.
[0080]
On the other hand, the multicast server 66, in Step S8, delivers over FLUTE multicast the FLUTE stream. The FLUTE session including the FLUTE stream 30 delivered over FLUTE multicast is received and played back by the terminal device18

80 that acquires the SDP based on the acquired MPD and analysed the SDP, andindoing so the reception mode described in the SDP is referred to. Specifically, when the reception mode is Promiscuous, all of the ALC/LCT packets transmitted by the corresponding FLUTE session are immediately received prior to acquisition and analysis of the FDT. However, it is left to the receiving side whether or not it 5 executes an operation corresponding to the reception mode notified by the SDP, and the supply side may not forcefully control the operation of the terminal device 80.
[0081]
As described above, according to the processing of the content supply device, prior to the terminal device 80 starting reception of a FLUTE session, it is 10 possible to notify the terminaldevice 80 of the reception mode suited to the reception. Therefore, it is possible to inhibit the omission of ALC/LCT packets at the terminal device 80 side. Also, since this notification is not something that forcefully controls the operation of the terminal device 80 side, it is possible to inhibit the triggering of the state such that the buffer on the terminal device 80 side overflows.15
[0082]
The content supply device 60 that executes a series of processes described above and the terminal device 80 can be realized by a computer executing software, in addition to constituting them with hardware. A computer built with special-purpose hardware, or for example a general-purpose personal computer or the like 20 capable of executing various functions by installing various programs are included in such a computer.
[0083]
FIG. 6is a block drawing that shows a configuration example of hardware of the aforementioned computer.25
[0084]
In this computer 200, a CPU (Central Processing Unit) 201, ROM (Read Only Memory) 202, and RAM (Random Access Memory) 203 are connected to each other by a bus 204.
[0085]30
An input/output interface 205 is also connected to the bus 204. An input 19

portion 206, an output portion 207, a storage portion 208, a communication portion 209, and a drive 210 are connected to the input/output interface 205.
[0086]
The input portion 206 includesa keyboard, a mouse, a microphone or the like. The output portion 207 includesa display, a speaker, or the like. The storage 5 portion 208 includesa hard disk, a non-volatile memory, or the like. The communication portion 209 includesa network interface or the like. The drive 210 drives a removable media 211 such as a magnetic disk, an optical disk, a magnetic-optical disk, or a semiconductor memory.
[0087]10
In the computer 200 that is constituted in the above manner, the CPU 201 loads and executes a program stored in the storage portion 208 via the input/output interface 205 and the bus 204, whereby the aforementioned series of processes are performed.
[0088]15
The program that the computer 200 (CPU 201) executes may be provided by being recorded for example on the removable media 211 such as a package media. Alternatively, the program may be provided via a wired or wireless transmission medium such as a local area network, the Internet, and a digital satellite broadcast.
[0089]20
The program may be installed in the storage portion 208 via the input/output interface 205 by loading the removable media 211 in the drive 210. Also, the program can be received by the communication portion 209 via a wired or wireless transmission medium and installed in the storage portion 208. In addition, the program can also be installed in advance in the ROM 202 or the storage portion 208.25
[0090]
The program executed bythe computer 200 may be a program in which the processing is performed in chronological order in the sequence described in the present specification, or a program in which the processing is performed in parallel or at a required timing, such as when called.30
[0091]20

An embodiment of the present disclosure isnot limited to the above embodiment, and may assume various alterations within the scope of the present disclosure.
[0092]
Additionally, the present technology may also be configured as below.5
(1)
A content supply device that delivers content over FLUTE multicast, the content supply device including:
a fragment stream generating portion that generates a fragment stream on the basis of source data of the content;10
a FLUTE-stream generating portion thatgenerates a FLUTE stream from the generated fragment stream;
an SDP creation portion that creates an SDP including a reception mode in the case of a reception side receiving a FLUTE session including the FLUTE stream; and15
a multicast delivery portion that delivers the FLUTE stream over FLUTE multicast and, prior to delivery of the FLUTE stream over FLUTE multicast, delivers the SDP over FLUTE multicast.
(2)
The content supply device according to (1), wherein20
the SDP creation portion creates the SDP including as the reception mode any of Promiscuous, One-copy, and Keep-updated.
(3)
The content supply device according to (1), wherein
the SDP creation portion creates the SDP including as the reception mode 25 any of Promiscuous, One-copy, Keep-updated, and combinations of the Promiscuous, the One-copy, and the Keep-updated.
(4)
The content supply device according to any of (1) to (3), wherein
the SDP creation portion creates the SDP additionally including an attribute 30 type showing that the FLUTE session includes an elementary stream of a single 21

media type.
(5)
The content supply device according to any of (1) to (4), further including:
a unicast delivery portion that delivers over HTTP unicast the generated fragment stream.5

Reference Signs List
[0093]
50content supply system
51network10
60content supply device
61channel server
62segmenter
63generator
64FLUTE streamer15
65WEBserver
66multicasting server
80terminal device
200computer
201CPU20 22

CLAIMS

Claim 1
A content supply device that delivers content over FLUTE multicast, thecontent supply devicecomprising:5
a fragment stream generating portion that generates a fragment stream on the basis of source dataof the content;
a FLUTE-stream generating portion that generates a FLUTE stream from the generated fragment stream;
an SDP creationportion that creates an SDP including a reception mode in 10 the case of a reception side receiving a FLUTE session including the FLUTE stream; and
amulticast delivery portion that for each of the FLUTE sessions delivers over FLUTE multicast the FLUTE stream corresponding to anelementary stream of a single media typeand,prior to delivery over FLUTE multicast of the FLUTE 15 stream,delivers the SDP over FLUTE multicast.
Claim 2
The content supply device according to claim 1,wherein
the SDP creation portion creates the SDP including as the receptionmode 20 any of Promiscuous, One-copy, and Keep-updated.
Claim 3
The content supply device according toclaim 1,wherein
the SDP creation portion creates the SDP including as the reception mode 25 any of Promiscuous, One-copy, Keep-updated,and combinations of the Promiscuous, the One-copy, and the Keep-updated.
Claim 4
The content supply device according to claim 2,wherein30
the SDP creation portion creates the SDP additionally including an attribute 23

type showing that the FLUTE session includes an elementary stream of a single media type.
Claim 5
The content supply device according to claim 2, further comprising:5
a unicast delivery portion that delivers over HTTP unicast the generated fragment stream.
Claim 6
A content supply method of a content supplydevice that delivers content 10 over FLUTE multicast, the content supply method comprising:
a fragment stream generating step of generating,by the content supply device,a fragment stream on the basis of source dataof the content;
a FLUTE-stream generatingstep of generating,by the content supply device,a FLUTE stream from the generated fragment stream;15
an SDP creationstep of creating,by the content supply device,an SDP including a reception mode in the case of a reception side receiving a FLUTE session including the FLUTE stream; and
a multicast deliverystep of for each of the FLUTE sessions delivering over FLUTE multicast,by the content supply device,the FLUTE stream corresponding to 20 an elementary stream of a single media type and,prior to delivery over FLUTE multicast of the FLUTE stream,delivering the SDP over FLUTE multicast.
Claim 7
A program that causes a computer that delivers content over FLUTE 25 multicast to function as:
a fragment stream generating portion that generates a fragment stream on the basis of source dataof the content;
a FLUTE-stream generating portion that generates a FLUTE stream from the generated fragment stream;30
an SDP creationportion that creates an SDP including a reception mode in 24

the case of a reception side receiving a FLUTE session including the FLUTE stream; and
a multicast delivery portion that for each of the FLUTE sessions delivers over FLUTE multicast the FLUTE stream corresponding to an elementary stream of a single media type and,prior to delivery over FLUTE multicast of the FLUTE 5 stream,delivers the SDP over FLUTE multicast.
Claim 8
A terminal device that receives and plays back a FLUTE stream delivered over FLUTE multicast from a content supply device including 10
a fragment stream generating portion that generates a fragment stream on the basis of source dataof content,
a FLUTE-stream generating portion that generates the FLUTE stream from the generated fragment stream,
an SDP creationportion that creates an SDP including a reception mode in 15 the case of a reception side receiving a FLUTE session including the FLUTEstream, and
a multicast delivery portion that for each of the FLUTE sessions delivers over FLUTE multicast the FLUTE stream corresponding to an elementary stream of a single media type and,prior to delivery over FLUTE multicast of the FLUTE 20 stream,delivers the SDP over FLUTE multicast,
wherein the terminal device acquires the SDP prior to reception of the FLUTE stream, and in accordance with the reception mode included in the SDP, receives the FLUTE stream.
25
Claim 9
The terminal device according to claim 8,wherein
in the case of acquiring the SDP prior to reception of the FLUTE stream, and the reception mode included in the SDP being promiscuous, the terminal device receives all packets of the FLUTE session including the FLUTE stream.30 25

Claim 10
A content supply system comprising:
a content supply device;and
a terminal device,
wherein the content supply device includes5
a fragment stream generating portion that generates a fragment stream on the basis of source dataof content,
a FLUTE-stream generating portion that generates a FLUTE stream from the generated fragment stream,
an SDP creationportion that creates an SDP including a reception mode in 10 the case of a reception side receiving a FLUTE session including the FLUTE stream, and
a multicast delivery portion that for each of the FLUTE sessions delivers over FLUTE multicast the FLUTE stream corresponding to an elementary stream of a single media type and,prior to delivery over FLUTE multicast of the FLUTE 15 stream,delivers the SDP over FLUTE multicast,and
wherein the terminal device acquires the SDP prior to reception of the FLUTE stream, and in accordance with the reception mode included in the SDP, receives the FLUTE stream.