WO2015064384A1 - Appareil et procédé de transmission et appareil et procédé de réception - Google Patents

Appareil et procédé de transmission et appareil et procédé de réception Download PDF

Info

Publication number
WO2015064384A1
WO2015064384A1 PCT/JP2014/077659 JP2014077659W WO2015064384A1 WO 2015064384 A1 WO2015064384 A1 WO 2015064384A1 JP 2014077659 W JP2014077659 W JP 2014077659W WO 2015064384 A1 WO2015064384 A1 WO 2015064384A1
Authority
WO
WIPO (PCT)
Prior art keywords
lct
priority parameter
priority
packet
header
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2014/077659
Other languages
English (en)
Japanese (ja)
Inventor
山岸　靖明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Publication of WO2015064384A1 publication Critical patent/WO2015064384A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting

Definitions

  • the present technology relates to a transmitting device, a transmitting method, a receiving device, and a receiving method, and more particularly to, for example, a transmitting device, a transmitting method, a receiving device, and a receiving method that enables data to be rapidly distributed. .
  • OTT-V Over The Top Video
  • MPEG-DASH Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)
  • DASH Dynamic Adaptive Streaming over HTTP
  • a server that delivers a stream notifies an MPD (Media Presentation Description) as metadata including attribute information for optimally selecting a stream having different characteristics from the same source to a client that receives the stream.
  • the client can realize network environment adaptive streaming by using the MPD (see, for example, Non-Patent Document 1).
  • the server prepares, as content of the same content, a plurality of streams having different image quality, image size, and the like according to the communication environment of the distribution path, the capability, the state, and the like of the client.
  • the client adaptively selects a stream that can be received by the client and that is suitable for the client's capability (such as decoding capability) among a plurality of streams prepared by the server, and receives that stream To play.
  • Metadata used for content reproduction control is distributed from the server to the client so that the client can adaptively select and receive a stream.
  • a URL Uniform Resource Locator
  • the client transmits an http request to the (web) server as a content distribution source based on the URL or the like described in the MPD, and receives and reproduces a segment to which the server performs unicast distribution in response to the http request. .
  • DASH is based on a streaming protocol that uses http, but for content etc. that a large number of users view simultaneously, for example, multicast and broadcast such as RTP (Real-time Transport Protocol) and FLUTE (File Delivery over Unidirectional Transport) It is desirable to perform simultaneous broadcast delivery and reduce the load on network resources by using (MC / BC) bearers together.
  • RTP Real-time Transport Protocol
  • FLUTE File Delivery over Unidirectional Transport
  • files are distributed in segment units, with (segments of files) divided from the stream of content as file distribution units (control targets) in DASH.
  • bit rate of the content stream is high, distribution of content, ie, bulk transfer, is performed in segment units, waiting for segment generation to be completed, and network bandwidth is compressed and shaping is performed May be required.
  • the present technology has been made in view of such a situation, and makes it possible to rapidly distribute data such as content.
  • a transmitting device is a transmitting device that includes a distribution unit that distributes an LCT packet having an LCT (Layered Coding Transport) header including a priority parameter for indicating the priority of processing of the packet.
  • LCT Layered Coding Transport
  • the transmission method of the present technology is a transmission method including the step of delivering an LCT packet having a Layered Coding Transport (LCT) header including a priority parameter for indicating the priority of processing of the packet.
  • LCT Layered Coding Transport
  • an LCT packet having an LCT (Layered Coding Transport) header including a priority parameter for indicating the priority of processing of the packet is distributed.
  • a receiver is a receiver including a receiver configured to receive an LCT packet having an LCT (Layered Coding Transport) header including a priority parameter for indicating a priority of processing of a packet.
  • LCT Layered Coding Transport
  • a receiving method is a receiving method including a step of receiving an LCT packet having a Layered Coding Transport (LCT) header including a priority parameter for indicating the priority of processing of the packet.
  • LCT Layered Coding Transport
  • an LCT packet having a Layered Coding Transport (LCT) header including a priority parameter for indicating the priority of processing of the packet is received.
  • LCT Layered Coding Transport
  • the transmitting device and the receiving device may be independent devices or may be internal blocks constituting one device.
  • data can be rapidly distributed.
  • FIG. 1 is a block diagram showing a configuration example of an embodiment of a content providing system to which the present technology is applied.
  • FIG. 2 is a block diagram showing a configuration example of a distribution server 11.
  • FIG. 2 is a block diagram showing an example of the configuration of a client 12; It is a figure explaining an example of processing of offer of contents by a contents offer system.
  • FIG. 2 is a diagram showing an example of data distributed via the network 10 in the content providing system. It is a figure explaining MPD, SDP, USD, and OMA-ESG. It is a figure explaining the composition of the segment which is a file delivery unit of DASH.
  • FIG. It is a figure which shows the structural example of the segment which has one fragment, and the segment which has several fragments. It is a figure which shows the example of delivery of the content which makes a segment a file delivery unit in DASH. It is a figure explaining the outline of distribution of the content which makes a potion a file distribution unit in the distribution server 11.
  • FIG. It is a figure which shows the example of the relationship between a segment and a portion. It is a figure which shows the example of the http response as the portion 60.
  • FIG. It is a figure which shows the example of the http response as the portion 70.
  • FIG. It is a flowchart explaining the example of processing of delivery of the content in a portion unit.
  • Fig. 21 is a block diagram illustrating a configuration example of an embodiment of a computer to which the present technology is applied.
  • FIG. 1 is a block diagram showing a configuration example of an embodiment of a content providing system to which the present technology is applied.
  • the content providing system is configured by connecting one or more distribution servers 11, one or more clients 12, and an NTP (Network Time Protocol) server 13 to the network 10.
  • NTP Network Time Protocol
  • content is provided from the distribution server 11 to the client 12 via the network 10 using the DASH.
  • streaming itself is performed by unicast on the OTT / CDN (Over The Top / Contents Delivery Network), but in the content providing system of FIG.
  • multicast distribution can be performed on a guaranteed multicast network (eMBMS etc.) with guaranteed quality on the mobile network.
  • the network 10 includes a bidirectional network such as the Internet which is capable of unicasting and multicasting, and a broadcast network which is capable of broadcasting and multicasting.
  • a bidirectional network such as the Internet which is capable of unicasting and multicasting
  • a broadcast network which is capable of broadcasting and multicasting.
  • MBMS Multimedia Broadcast Multicast Service
  • eMBMS evolved MBMS
  • 3GPP 3rd Generation Partnership Project
  • the distribution server 11 corresponds to, for example, a broadcast station, and is a stream of content having the same contents as a program of a channel (service) of the broadcast station, and a plurality of streams having different bit rates, image sizes, etc. Deliver through.
  • the client 12 receives (plays) (the stream of) the content distributed by the distribution server 11 via the network 10 and reproduces it.
  • the NTP server 13 provides an NTP time, which is time information according to Coordinated Universal Time (UTC) time format, via the network 10.
  • UTC Coordinated Universal Time
  • the distribution server 11 and the client 12 can operate in synchronization with the NTP time provided by the NTP server 13.
  • the program distributed by the distribution server 11 may be a real-time program (a program of live broadcasting) or a recorded program.
  • FIG. 2 is a block diagram showing a configuration example of the distribution server 11 of FIG.
  • the delivery server 11 includes a channel streamer 21, a segmenter 22, a metadata generator 23, a file delivery over unidirectional transport (FLUTE) streamer 24, a multicast server 25, and a web server 26.
  • FLUTE unidirectional transport
  • the channel streamer 21 to the web server 26 can be disposed at one place on the network 10 or can be disposed on the network 10 in a distributed manner.
  • communication between each other can be performed via a dedicated line other than the network 10 or any other communication line.
  • the channel streamer 21 manages video, audio, subtitles, and the like as source data of content to be distributed as a program of a channel of the distribution server 11, and a plurality of different bit rates from video, etc. as source data of the content.
  • the streaming data of is generated and supplied to the segmenter 22.
  • the segmenter 22 generates a file of segments obtained by dividing each streaming data from the channel streamer 21 in the time direction, and supplies the file to the FLUTE streamer 24 and the web server 26.
  • the segmenter 22 divides streaming data to generate, for example, fragments of fragmented MP 4 (moof and mdat), collects one or more of the fragments, and generates a file of a segment.
  • the segmenter 22 includes the URL of the segment (the URL of the server providing the segment (for example, the distribution server 11)), the range of the segment (information representing the range in content such as video included in the segment), etc.
  • the metadata generator 23 is supplied with the related information related to the segments necessary for the generation of the MPD.
  • the segmenter 22 is not a segment that collects the fragments, but during the generation of the fragments, generates segments, which will be described later, which are configured as part of the fragments, and supplies the portions to the FLUTE streamer 24 instead of the segments. be able to.
  • the metadata generator 23 uses, for example, the MBMS (User Service Description) of MBMS, as metadata of content necessary for reception of a segment by the client 12 using segment relation information etc. supplied from the segmenter 22.
  • MPD and a combination of Session Description Protocol (SDP) (file) of the Internet Engineering Task Force (IETF) or their USD, MPD, and SDP in OMA-ESG (Open Mobile Alliance-Electronic Service Guide) To generate a combination.
  • SDP Session Description Protocol
  • IETF Internet Engineering Task Force
  • OMA-ESG Open Mobile Alliance-Electronic Service Guide
  • the metadata generator 23 uses the relationship information of the segments supplied from the segmenter 22 to generate an MPD in which the URL of the segment, etc. necessary for the client 12 to receive the segment and control the reproduction is described. Do.
  • the metadata generator 23 generates USD and SDP, or USD, SDP, and OMA-ESG as announcement information that announces that content is to be multicast-distributed (including broadcast distribution).
  • the metadata generator 23 supplies metadata to the FLUTE streamer 24 and the web server 26.
  • the FLUTE streamer 24 means (a segment or a portion of) the content supplied from the segmenter 22 as a FLUTE packet, that is, an LCT (Layered Coding Transport) packet (in the present embodiment, a packet having an LCT header; (Asynchronous Layered Coding) packet is stored and supplied to the multicast server 25.
  • LCT Layered Coding Transport
  • the FLUTE streamer 24 stores the metadata supplied from the metadata generator 23 in an LCT packet, and supplies the LCT packet to the multicast server 25.
  • the multicast server 25 multicasts the LCT packet from the FLUTE streamer 24 via the network 10 (FLUTE).
  • the multicast server 25 distributes the content and the metadata in the multicast distribution. It will be done.
  • the web server 26 responds to a request (http request) from the client 12 to send the metadata from the metadata generator 23 and (the segment of the content from the segmenter 22 to the client 12 via the network 10 ( http) Unicast delivery.
  • the multicast server 25 and the web server 26 function as a distribution unit that distributes content and metadata.
  • the web server 26 unicasts the segment of the content, but the web server 26 unicasts the portion, not the segment of the content, like the multicast server 25. Can.
  • FIG. 3 is a block diagram showing a configuration example of the client 12 of FIG.
  • the client 12 has a receiving unit 30 and a reproduction unit 33.
  • the receiving unit 30 functions as a receiving unit that receives content and metadata distributed from the distribution server 11 according to, for example, an operation of the client 12 by the user.
  • the receiving unit 30 receives the metadata distributed from the distribution server 11. Furthermore, the receiving unit 30 receives (segments or portions of) the content distributed from the distribution server 11 based on the metadata received from the distribution server 11 according to, for example, the user's operation of the client 12 or the like.
  • the reception unit 30 supplies the content received from the distribution server 11 to the reproduction unit 33, and controls the reproduction of the content in the reproduction unit 33 based on the metadata received from the distribution server 11.
  • the reproduction unit 33 reproduces video, audio, subtitles, and the like as the content supplied from the reception unit 30 according to the control of the reception unit 30.
  • the receiving unit 30 includes the middleware 31 and the DASH client 32.
  • the DASH client 32 outputs, to the middleware 31, an http request for requesting an MPD and an http request for requesting a segment of content, as necessary.
  • the middleware 31 receives (segments and portions of) contents and segments distributed by multicast from the distribution server 11 as needed, and when the DASH client 32 outputs an http request, it is requested by the http request. Based on the metadata, it is determined whether the MPD or segment in question is multicast-distributed.
  • the middleware 31 is a portion including the MPD or segment (or a part of the segment) to be multicast-distributed. ) Is supplied to the DASH client 32.
  • the middleware 31 supplies the received MPD or segment to the DASH client 32.
  • the middleware 31 directly transmits the http request output by the DASH client 32 to the Send to). Then, in response to the http request, the middleware 31 receives the MPD or segment unicast-distributed (from the distribution server 11) and supplies the MPD or segment to the DASH client 32.
  • the DASH client 32 outputs an http request for requesting a necessary MPD or segment as in a general DASH client, and receives the MPD or segment supplied from the middleware 31 in response to the http request. To process.
  • FIG. 4 is a diagram for explaining an example of processing of providing content by the content providing system of FIG.
  • step S11 the channel streamer 21 (FIG. 2) generates a plurality of streaming data having different bit rates from video or the like as source data of content to be distributed as a program of the channel of the distribution server 11.
  • step S12 the channel streamer 21 supplies the segmenter 22 with a plurality of streaming data having different bit rates of the content.
  • the segmenter 22 receives the content (a plurality of streaming data) supplied from the channel streamer 21 in step S21.
  • step S22 the segmenter 22 generates a segment which is a file distribution unit of DASH from the content from the channel streamer 21 and supplies the segment to the FLUTE streamer 24 and the web server 26 in step S23.
  • step S24 the segmenter 22 generates segment relation information and supplies the information to the metadata generator 23.
  • step S31 the metadata generator 23 (FIG. 2) receives the relationship information of the segments supplied from the segmenter 22 in step S24.
  • step S32 the metadata generator 23 generates metadata of the content using the relationship information and the like from the segmenter 22 and supplies the metadata to the FLUTE streamer 24 and the web server 26.
  • the FLUTE streamer 24 receives (the segment of) the content supplied from the segmenter 22 in step S23 in step S41, generates an LCT packet including the content in step S42, and sends it to the multicast server 25. Supply.
  • step S43 the FLUTE streamer 24 receives the metadata supplied from the metadata generator 23 in step S32, generates an LCT packet including the metadata in step S44, and supplies it to the multicast server 25. .
  • the multicast server 25 receives the LCT packet including the content supplied from the FLUTE streamer 24 in step S42 in step S51, and receives the LCT packet including metadata in step S52.
  • step S53 the multicast server 25 multicast-distributes the LCT packet including the metadata from the FLUTE streamer 24, and, in step S54, multicasts the LCT packet including the content from the FLUTE streamer 24.
  • step S61 the web server 26 (FIG. 2) receives (the segment of) the content supplied from the segmenter 22 in step S23, and in step S62 receives the metadata supplied from the metadata generator 23 in step S32 Do.
  • step S63 when the http request for requesting metadata is transmitted from the client 12, the web server 26 receives the http request.
  • step S64 the web server 26 unicasts the metadata requested by the http request from the client 12 to the client 12.
  • step S65 when an http request for requesting (a segment of) content is transmitted from the client 12, the web server 26 receives the http request.
  • step S66 the web server 26 unicasts (the segment of) the content requested by the http request from the client 12 to the client 12.
  • step S71 the reception unit 30 receives (the LCT packet of) metadata to which the multicast server 25 performs multicast distribution in step S53.
  • the receiving unit 30 transmits an http request for requesting metadata in step S72.
  • the http request transmitted by the client 12 in step S72 is received by the web server 26 in step S63 as described above, and in step S64, the metadata requested by the http request is unicasted to the client 12 Do.
  • step S73 the reception unit 30 of the client 12 receives the metadata distributed in the unicast manner as described above.
  • step S74 the reception unit 30 of the client 12 receives (the LCT packet of) the content to which the multicast server 25 performs multicast distribution in step S54 based on the metadata received in step S71 or S73.
  • step S75 the receiving unit 30 transmits an http request for requesting content based on the metadata received in step S71 or S73 in step S75.
  • the web server 26 receives the http request transmitted by the client 12 in step S75 in step S65, and in step S66 unicasts the content requested by the http request to the client 12 .
  • step S76 the reception unit 30 of the client 12 receives the content unicast-distributed as described above.
  • step S77 the reproduction unit 33 of the client 12 reproduces the content received by the reception unit 30 in step S74 or S76 based on metadata (MPD).
  • MPD metadata
  • FIG. 5 is a diagram showing an example of data distributed via the network 10 in the content providing system of FIG.
  • Metadata such as MPD, SDP, USD, OMA-ESG, and the like (segments or portions of the content) are distributed to the client 12.
  • Metadata and content can be distributed by multicast or unicast.
  • Metadata a combination of MPD, SDP, and USD, or a combination of them with OMA-ESG is used.
  • FIG. 6 is a diagram for explaining MPD, SDP, USD, and OMA-ESG.
  • the OMA-ESG of the program of interest describes detailed information of the program of interest, a method of accessing the USD of the program of interest, and the like.
  • the client 12 acquires the OMA-ESG of the program of interest
  • the USD of the program of interest can be acquired by referring to the method for accessing the USD described in the OMA-ESG.
  • the USD of the program of interest describes the URI (Uniform Resource Identifier) of the SDP of the program of interest, the URI of the MPD of the program of interest, and the like.
  • URI Uniform Resource Identifier
  • the SDP and MPD of the program of interest can be acquired by referring to the URI of SDP and MPD described in the USD.
  • IP address for multicast distribution of the content of the program of interest and transport attributes such as port numbers are described.
  • the client 12 recognizes that the content is to be delivered by multicast, and the content is delivered by multicast Content can be received.
  • the segment of the program of interest can be received in unicast based on the URL described in the MPD.
  • the segment of the program of interest can be reproduced based on the MPD of the program of interest.
  • the MPD since the MPD contains information necessary for segment reproduction control, the MPD is necessary not only to receive the segment in unicast but also to reproduce the segment.
  • FIG. 7 is a diagram for explaining the configuration of a segment which is a file delivery unit of DASH.
  • the format of the content delivered by DASH is not particularly limited, but in this embodiment, (a file of fragmented MP4) is adopted as the format of the content delivered by DASH, for example.
  • a segment has styp (segment type) (box), necessary sidx (segment index) (box), and one or more fragments (MP4 fragments).
  • the segment when styp is 'msdh', the segment does not include sidx, and when styp is 'msix', the segment includes sidx.
  • sidx will be omitted as appropriate.
  • the fragment has moof (movie fragment) (box) and mdat (media data) (box).
  • the mdat has an mdat header and one or more samples.
  • a sample is a minimum access unit when accessing media data (data such as video) in an MP4 file. Therefore, media data in the MP4 file can not be accessed in units smaller than the sample.
  • Moof has mfhd (movie fragment header) (box) and traf (track fragment) (box).
  • sequence_number A sequence number (sequence_number) is stored in mfhd.
  • sequence_number represents the order of fragments having the sequence_number.
  • the traf has tfhd (track fragment header) (box), tfdt (track fragment decode time) (box), trun (track fragment run) (box), sdtp (independent samples) (box) and the like.
  • BaseMediaDecodeTime is stored in tfdt.
  • BaseMediaDecodeTime represents the presentation time of the first sample among the samples included in the fragment having that BaseMediaDecodeTime.
  • the trun stores information necessary to calculate the presentation time of each sample included in the fragment having the trun.
  • FIG. 8 is a diagram showing a configuration example of a segment having one fragment and a segment having a plurality of fragments.
  • a of FIG. 8 shows a configuration example of a segment having one fragment.
  • each of three consecutive segments # 1, # 2, # 3 has one fragment.
  • FIG. 8 shows a configuration example of a segment having a plurality of fragments.
  • segment # 1 has 3 fragments.
  • the segment has one fragment, as shown in A of FIG.
  • FIG. 9 is a diagram illustrating an example of delivery of content in which a segment is a file delivery unit in DASH.
  • sample groups # 1, # 2, and # 3 each of which is one or more samples, are sequentially generated as sample groups constituting fragments. Then, after the segmenter 22 of the delivery server 11 (FIG. 2) completes generation of the last sample group # 3 of fragments, mdat in which those sample groups # 1 to # 3 are arranged, and sample groups # 1 to # 3. The fragments including the fragments are generated, and the segments including the fragments are generated, and then the segments are distributed in the FLUTE streamer 24 and the multicast server 25.
  • the moof of the sample groups # 1 to # 3 is performed, for example, in parallel with the generation of the sample groups # 1 to # 3.
  • example groups # 1 to # 3 arranged as mdat of fragment for example, it is possible to adopt a range of GOP (Group Of Picture) which is a minimum unit which can be randomly accessed. it can.
  • GOP Group Of Picture
  • the range of content to be fragmented is not limited to the range of GOP.
  • the GOP time for example, about 0.5 to 2 seconds is often employed. Therefore, when adopting the range of the GOP as the range of the content to be fragmented, the moof, and hence the segment is generated waiting for the time of the GOP which is at least about 0.5 to 2 seconds. That is, it takes at least the time of GOP to generate a segment.
  • the bandwidth of the network may be compressed and shaping may be necessary.
  • the distribution server 11 rapidly distributes (the data of) content by multicasting a portion smaller than a segment (hereinafter also referred to as a portion) as a file distribution unit. Deliver and thereby control the delay that results in the reception of content at the client and the onset of buffering.
  • FIG. 10 is a diagram for explaining an outline of distribution of content in which the portion is a file distribution unit in the distribution server 11.
  • the sample A portion as a file distribution unit including group # 1 is generated, and is distributed by multicast in the FLUTE streamer 24 and the multicast server 25.
  • a portion including a sample group (a sample group # 1, # 2, # 3 in FIG. 10) smaller than the segment and smaller than the segment is generated, and the content is multicasted by distributing the portion. Can be delivered quickly, and the delay caused to receive content at the client and start of buffering can be suppressed.
  • sample group # 1 corresponds to, for example, I picture data to be first encoded in the GOP.
  • the sample group # 2 corresponds to data of one or more P pictures and B pictures encoded after the I picture of the GOP, and the sample group # 3 is data of the remaining P pictures and B pictures of the GOP. It corresponds to
  • FIG. 11 is a diagram showing an example of the relationship between segments and portions.
  • a of FIG. 11 shows an example of the segment.
  • the segment 50 has styp 51 and (one) fragment 52.
  • Fragment 52 is composed of moof 53 and mdat 54.
  • 1 is set as the sequence number sqn of the fragment 52.
  • an mdat header 55 and three sample groups 56, 57 and 58 are stored in that order.
  • the sample groups 56 to 58 correspond to, for example, sample groups # 1 to # 3 in FIG.
  • the first sample of the second sample group 57 is the sample of the n1th sample from the top of the first sample group 56.
  • the first sample of the third sample group 58 among the three sample groups 56 to 58 is the sample of the n2 (> n1) sample from the top of the first sample group 56.
  • sample number here, it is also referred to as a sample number below which sample a certain sample stored in mdat is from the first sample of the mdat.
  • the sample number of the first sample of the sample group 57 is n1
  • the sample number of the first sample of the sample group 58 is n2.
  • FIG. 11B, FIG. 11C, and FIG. 11D show examples of portions including a part of the fragments 52 included in the segment 50 when the segment 50 of A in FIG. 11 is generated. ing.
  • FIG. 11B shows an example of a portion including the sample group 56 as a part of the fragment 52.
  • 11C shows an example of a portion including a sample group 57 as another part of the fragment 52, and D in FIG. 11 shows a sample group 58 as another part of the fragment 52.
  • An example of the potion is shown.
  • portion 60 is an http response including the first sample group 56 of fragment 52, and portion 60 includes http header 61, MS / BR 62, styp 51, moof subset 64, MS / BR 65, mdat header. 55, MS / BR 66, sample group 56, and MS 67 are arranged in this order.
  • the http header 61 is an http header indicating that the message body is a multipart message body.
  • the http header 61 includes a sequence number sqn, a version v, and an NTP time nt.
  • the sequence number sqn of the http header 61 is set to 1 identical to the sequence number sqn stored in the moof 53 of the fragment 52 including the sample group 56 (as part of the fragment 52) included in the portion 60.
  • the version v represents the order in the fragment of the sample group as a part of the fragment included in the portion including the version v.
  • the version v is an integer which is incremented by one, for example, with an initial value of 1 for the same sequence number sqn (with a sqn scope).
  • the version v of the http header 61 Is set to 1.
  • Each segment includes, for example, a plurality of three fragments as shown in FIG. 9, and the sequence numbers sqn of the three fragments are 1, 2, and 3, respectively.
  • the set of sequence numbers sqn and version v of each of the 6 portions is generated (sqn , v) become (1, 1), (1, 2), (2, 1), (2, 2), (3, 1), (3, 2), respectively.
  • the NTP time nt of the http header 61 is bmdt (BaseMediaDecodeTime) stored in the moof 53 of the fragment 52 whose portion 60 (the sample group 56) is included in the portion 60 including the NTP time nt, that is, the sample at the beginning of the fragment 52 ( Represents an NTP time NT corresponding to bmdt representing a presentation time of the first sample of the sample group 56).
  • MS / BR 62 represents a multipart separator (multipart-separator) and a byte range of styp 51 arranged immediately after that.
  • MS / BR 63 represents the multi-part separator and the byte range of the moof subset 64 placed immediately after it.
  • the moof subset 64 is a subset of moof 53 that can be generated before the generation of the first (first) sample group 56 placed in the portion 60 out of the three sample groups 56 to 58 of the fragment 52. And includes sequence numbers sqn and bmdt stored in moof 53.
  • the sample group 56 can be reproduced according to the moof subset 64 which is a subset of the moof 53 that can be generated before the sample group 56 is generated.
  • MS / BR 65 represents the multi-part separator and the byte range of the mdat header 55 placed immediately after that.
  • MS / BR 66 represents the multi-part separator and the byte range of sample group 56 placed immediately after that.
  • MS67 represents a multipart separator.
  • styp 51 is included in the portion 60 in which the first sample group 56 of the fragment 52 is included, but styp 51 (further not shown, sidx) is an http different from the portion 60. It can be included in the response and delivered.
  • the portion 70 is an http response including the second sample group 57 of the fragment 52, and the portion 70 includes the http header 71, MS / BR 72, moof subset 73, MS / BR 74, sample group 57. , And MS 75 are arranged in that order.
  • the http header 71 is an http header indicating that the message body is a multipart message body, and the http header 71 includes a sequence number sqn, a version v, an NTP time nt, and a sample count start scs (SampleCountStart). Is included.
  • the sequence number sqn of the http header 71 is set to 1 identical to the sequence number sqn stored in the moof 53 of the fragment 52 including the sample group 57 (as part of the fragment 52) included in the portion 70.
  • the version v of the http header 71 is set to 2. That is, since the portion 70 includes the second sample group 57 of the sample groups 56 to 58 of the fragment 52, 2 is set in the version v of the http header 71.
  • the sample count start scs represents the order of the sample at the beginning of the sample group included in the portion including the sample count start scs from the sample at the beginning of the fragment.
  • N1 is set.
  • MS / BR 72 represents the multi-part separator and the byte range of the moof subset 73 placed immediately after it.
  • the moof subset 73 is a subset of moof 53 that can be generated before the generation of the second sample group 57 placed in the portion 70 out of the three sample groups 56 to 58 of the fragment 52, the moof 53 Includes sequence numbers sqn and bmdt stored in.
  • moof subset 73 which is a subset of moof 53 that can be generated before sample group 57 is generated, information necessary for reproducing sample group 57 is included in moof subset 64 generated before sample group 56 is generated.
  • the moof subset 73 is added, so that the sample group 57, and further, the sample group 56 generated before the sample group 57 is generated can be reproduced.
  • MS / BR 74 represents the multi-part separator and the byte range of sample group 57 placed immediately after that.
  • MS 75 represents a multi-part separator.
  • a portion 80 is an http response including the third sample group 58 of the fragment 52, and the portion 80 includes an http header 81, MS / BR 82, moof subset 83, MS / BR 84, sample group 58. , And MS 85 are arranged in that order.
  • the http header 81 is an http header indicating that the message body is a multipart message body, and the http header 81 includes a sequence number sqn, a version v, an NTP time nt, and a sample count start scs. .
  • the sequence number sqn of the http header 81 is set to 1 identical to the sequence number sqn stored in the moof 53 of the fragment 52 including the sample group 58 (as part of the fragment 52) included in the portion 80.
  • the version v of the http header 81 is set to 3. That is, since the portion 80 includes the third sample group 58 of the sample groups 56 to 58 of the fragment 52, the version v of the http header 81 is set to 3.
  • the sample group 58 included in the portion 80 is the last sample group of the fragment 52, that is, the last sample group whose sequence number sqn is 1, the version v of the http header 81 is , And the order 3 of the sample group 58 in the fragment 52, and "-end" as information indicating that it is the last sample group of the fragment is set.
  • the order of the samples (as part of the fragment) included in the portion and whether that sample is the last sample of the fragment can be recognized.
  • the sample count start scs represents the order of the sample at the head of the sample group included in the portion including the sample count start scs from the sample at the head of the fragment.
  • n2 is set in the sample count start scs of the http header 81. That is, since the first sample of the sample group 58 included in the portion 80 is the sample of the n2th sample from the top of the first sample group 56 as described in A of FIG. n2 is set to scs.
  • MS / BR 82 represents the multi-part separator and the byte range of the moof subset 83 placed immediately after it.
  • the moof subset 83 is a subset of moof 53 that can be generated by the third sample group 56 to 58 of the fragment 52 until the third sample group 58 placed in the portion 80 is generated. Includes sequence numbers sqn and bmdt stored in.
  • the moof subset 83 is a subset of moof 53 that can be generated before the generation of the third sample group 58 placed in the portion 80, ie, the last sample group 58 of the fragment 52, the moof 53 be equivalent to.
  • the moof subset 83 which is a subset of the moof 53, which can be generated until the sample group 58 is generated, is equal to the moof 53, according to the moof subset 83, the sample group 58, further, the sample group Sample groups 56 and 57 can be regenerated before 58 is generated.
  • MS / BR 84 represents the multi-part separator and the byte range of the sample group 58 placed immediately after that.
  • MS85 represents a multi-part separator.
  • the client 12 since the portion that is the http response includes the sequence number sqn and the version v in the http header, the client 12 (other device) that has received the portion receives the sequence number sqn and the version v. Based on this, it is possible to recognize and reproduce the order in the segment of the sample group included in the portion and to construct and reproduce the segment as required.
  • the client 12 receives all the portions (sample group) constituting the segment before receiving the portion.
  • the sample group included in the one portion is a sample group that can be independently reproduced (for example, a sample group of I picture), or a sample that has already been received
  • reproduction of the sample group included in one received portion can be started.
  • the version v can be included in the moof subset together with the sequence number sqn. However, when the version v is included in the moof subset together with the sequence number sqn, it is necessary to extend the existing moof definition to include the version v in the moof. If you include version v in the http header, you do not need to extend the existing moof definition.
  • the http headers 71 and 81 of the portions 70 and 80 including the second and subsequent sample groups 57 and 58 of the fragment 52 respectively include the sample count start scs, and the first sample group 56 of the fragment 52
  • the http header 61 of the portion 60 containing does not contain the sample count start scs
  • the sample count start scs can also be included in the http header 61 of the portion 60 containing the first sample group 56 of the fragment 52 .
  • the http header (version of the portion including the first sample group of fragments)
  • the sample count start scs can be omitted, whereby the size of the http header can be reduced.
  • the http header can include the NTP time nt corresponding to bmdt (bmdt representing the presentation time of the first sample of the fragment) stored in the moof of the fragment.
  • the content includes, for example, content such as a program of live broadcasting which needs to control the timing of reproduction on the time axis of absolute time represented by NTP time, and each sample of such content is It is necessary to calculate the NTP time as an absolute time to which the sample is mapped (displayed).
  • the presentation time of the Nth sample of the fragment (PresendatioTime (CompositionTime) of Nth Sample) can be calculated according to the following equation.
  • Sum of SampleDuration of (N-1) Samples and CompositionTimeOffset of Nth Sample can be obtained from information (sampleCount, SampleDuration, CompositionTimeOffset) stored in moof of fragment, and BaseMediaDecodeTime is momd as bmdt. It is stored.
  • the absolute time of a sample can be determined if the NTP time corresponding to BaseMediaDecodeTime used to calculate the presentation time of the sample is known.
  • the client 12 receives the portion by including the NTP time nt corresponding to bmdt (bmdt representing the presentation time of the first sample of the fragment) stored in the moof of the fragment in the http header. Based on the NTP time nt included in the http header of the portion, even if there is no corresponding MPD, calculate the NTP time as the absolute time of each sample of the sample group included in the portion and calculate the samples according to the NTP time It can be played back.
  • bmdt bmdt representing the presentation time of the first sample of the fragment
  • the http header can include the sample count start scs that represents the order of the first sample of the sample group included in the portion from the first sample of the fragment, so the segment is configured. Even if a portion of a plurality of portions (a plurality of portions including each of a plurality of sample groups included in the segment) is missing, the portion (sample group included in) following the missing portion is reproduced be able to.
  • each sample from each portion starts from the first sample of the fragment, even without the sample count start scs. It is possible to recognize the sample number of what sample it is, and based on the sample number, it is possible to obtain information necessary for reproducing the sample from the moof subset and reproduce the sample.
  • sample count start scs By including the sample count start scs in the http header of the portion, even if a portion of the plurality of portions constituting the segment is missing, the sample included in the portion following the missing portion The sample number can be recognized and reproduced by the sample count start scs.
  • the portion can include moof subset which is a subset of moof 53, which can be generated before generating a sample group included in the portion
  • the client 12 receiving the portion waits for the subsequent portion without waiting. Then, the reproduction of the sample group included in the received portion can be started based on the moof subset included in the portion.
  • the http header of the portion may further include, for example, FDT (File Delivery Table) which is various attribute information distributed by FLUTE for multicasting the portion.
  • FDT Fra Delivery Table
  • the client 12 can use the FDT included in the http header of the portion for reception of FLUTE multicast distributed data.
  • FIG. 12 is a diagram showing an example of the description of the http response as the portion 60 of FIG.
  • the description 100 is an http header 61, and "X-MoofSeqNumVersion" in the description 101 of the http header 61 and "X-NTPTimeStamp" in the description 102 are newly defined headers.
  • “X-MoofSeqNumVersion” in the description 101 is a sequence number sqn, a header representing a version v, and has a variable sqn representing the sequence number and a variable v representing a version.
  • the variable sqn is set to 1, which is the sequence number sqn of the fragment 52
  • the variable v is set to 1, which is the order in the fragment 52 of the sample group 56 included in the portion 60.
  • X-NTPTimeStamp in the description 102 is a header representing an NTP time nt (corresponding to BaseMediaDecodeTime), and in FIG. 12, the sample at the beginning of the fragment 52 (the sample at the beginning of the sample group 56) in “X-NTPTimeStamp” 2890844526 is set as an NTP time NT corresponding to bmdt representing the presentation time of.
  • the description 103 is MS / BR 62, and "SEPARATER_STRING" in the description 103 represents a multi-part separator. Also, “Content-range: bytes 492-499 / 124567654" in the description 103 represents the byte range of styp 51 immediately after.
  • the byte range "Content-range: bytes 492-499 / 124567654" in the description 103 is that the size of the fragment is 124567654 bytes and that the styp51 immediately after is 492-499 bytes of the 124567654 bytes. Represents
  • the description 103 is followed by the styp51 byte sequence.
  • the description 104 after the byte string of styp 51 is MS / BR 63, and "Content-range: bytes 500-991 / 124567654" in the description 104 represents the byte range of the moof subset 64 immediately after.
  • the byte range of the moof subset the byte range of the moof of the fragment (moof 53 in FIG. 11) is predicted when the portion (in FIG. 11, the portion 60 in FIG. 11) including the first sample group of fragments is generated.
  • the predicted value of the moof byte range is adopted as the byte range of the moof subset of each portion (in FIG. 11, portions 60, 70, and 80 in FIG. 11) including a sample group of fragments. Therefore, the byte range of the moof subset 64 of the portion 60, the moof subset 73 of the portion 70, and the moof subset 83 of the portion 80 become the same value (the predicted value of the moof 53 byte range).
  • the description 104 is followed by the moof subset 64 byte sequence.
  • the description 105 after the byte string of the moof subset 64 is MS / BR 65, and "Content-range: bytes 992-999 / 124567654" in the description 105 represents the byte range of the mdat header 55 immediately after.
  • the description 105 is followed by the byte string of the mdat header 55.
  • the description 106 after the byte string of the mdat header 55 is MS / BR 66, and "Content-range: bytes 1000-4999 / 124567654" in the description 106 represents the byte range of the sample group 56 immediately after.
  • the description 106 is followed by a byte sequence of samples 56.
  • the description 107 of the byte string of the sample group 56 is MS67.
  • FIG. 13 is a diagram showing an example of the description of the http response as the portion 70 of FIG.
  • the description 120 is an http header 71, and "X-MoofSeqNumVersion” in the description 121 of the http header 71, "X-NTPTimeStamp” in the description 122, and "X-SampleCountStart” in the description 123 are newly defined. It is a header.
  • “X-MoofSeqNumVersion” in the description 121 is a header representing the sequence number sqn and the version v as described in FIG.
  • the variable sqn representing the sequence number is set to 1 which is the sequence number sqn of the fragment 52
  • the variable v representing the version is set to 2 which is the order in the fragment 52 of the sample group 57 included in the portion 70.
  • the “X-NTPTimeStamp” in the description 122 is a header representing the NTP time nt as described in FIG. 12, and is an NTP time NT corresponding to bmdt representing the presentation time of the first sample of the fragment 52 in FIG. The same 2890844526 as the case is set.
  • “X-SampleCountStart” in the description 123 is a header representing a sample count start scs, and in FIG. 13, the sample number n1 of the first sample of the sample group 57 included in the fragment 70 is set to “X-SampleCountStart”. ing.
  • the description 124 is MS / BR 72, and the "Content-range: bytes 500-991 / 124567654" in the description 124 represents the byte range of the moof subset 73 immediately after it, and the byte range of the moof subset 64 in the description 105 of FIG. It is the same as (the prediction value of moof53 byte range).
  • the description 124 is followed by the moof subset 73 bytes.
  • the description 125 after the byte string of the moof subset 73 is MS / BR 74, and "Content-range: bytes 5000-7999 / 124567654" in the description 125 represents the byte range of the sample group 57 immediately after.
  • the description 125 is followed by the byte series of the sample group 57.
  • the description 126 of the byte string of the sample group 57 is MS75.
  • the portion 80 of FIG. 11 is configured in the same manner as the portion 70 of FIG.
  • FIG. 14 is a flow chart for explaining an example of processing of delivery of content in units of portions.
  • step S101 the segmenter 22 of the distribution server 11 (FIG. 2) sets the fragment (eg, the fragment 52 of FIG. 11) for which a sample group is to be generated as the target fragment, the mdat header of the target fragment, and the first sample A group is generated, and the process proceeds to step S102.
  • the fragment eg, the fragment 52 of FIG. 11
  • step S102 the segmenter 22 generates an http header (for example, the http header 61 in FIG. 11) for the first sample group, and the process proceeds to step S103.
  • an http header for example, the http header 61 in FIG. 11
  • the segmenter 22 is stored in the sequence number sqn which is the same as the sequence number stored in the moof of the fragment of interest, the version v which is 1 representing the order in the fragment of interest of the first sample group, and the moof of the fragment of interest
  • the http header including the NTP time nt corresponding to bmdt is generated as the http header for the first sample group.
  • step S103 the segmenter 22 can generate a part of the moof necessary for reproducing the first sample group, which has been able to generate the first sample group for the fragment of interest. After acquiring as a subset, the process proceeds to step S104.
  • step S104 the segmenter 22 sets the styp (and necessary sidx) of the segment including the fragment of interest, the moof subset for the first sample group, the mdat header of the fragment of interest, and the first sample group for the first sample group.
  • the http response as a portion is generated and supplied to the FLUTE streamer 24, and the process proceeds to step S105.
  • the http response as a portion generated in step S104 is styp (and Necessary sidx) is not included.
  • step S105 the FLUTE streamer 24 packetizes the http response as a portion from the segmenter 22 into an LCT packet, the multicast server 25 multicasts the LCT packet, and the process proceeds to step S106.
  • step S106 the segmenter 22 generates the next sample group as the sample of interest for the fragment of interest, and the process proceeds to step S107.
  • step S107 the segmenter 22 generates an http header (for example, the http headers 71 and 81 in FIG. 11) for the sample of interest, and the process proceeds to step S108.
  • an http header for example, the http headers 71 and 81 in FIG. 11
  • the segmenter 22 has the same sequence number sqn as the sequence number stored in the moof of the fragment of interest, the version v representing the order of the fragments of interest of the sample group of interest, and the NTP corresponding to bmdt stored in the moof of the fragment of interest.
  • An http header including a time nt and a sample count start scs indicating the sample number of the first sample of the sample of interest is generated as an http header for the sample of interest.
  • step S108 the segmenter 22 can generate the sample of interest, and the group of samples generated before generating the sample of interest of the fragment of interest, which were able to be generated before generating the sample of interest for the fragment of interest. ) Is acquired as the moof subset for the sample group of interest, and the process proceeds to step S109.
  • step S109 the segmenter 22 generates an http response as a portion by adding the http header for the sample of interest to the moof subset for the sample of interest and the sample of interest, and supplies it to the FLUTE streamer 24. Then, the process proceeds to step S110.
  • step S110 as in step S105, the FLUTE streamer 24 packetizes the http response as a portion from the segmenter 22 into an LCT packet, the multicast server 25 distributes the LCT packet by multicast, and the process Go to S111.
  • step S111 the segmenter 22 determines whether the sample of interest is the last sample of the fragment of interest.
  • step S111 If it is determined in step S111 that the sample of interest group is not the last sample group of the fragment of interest, that is, if there is a sample group following the sample of interest group in the fragment of interest, the process returns to step S106 The same process is repeated with the next sample group of sample groups as a new sample group of interest.
  • step S111 determines whether the sample of interest group is the last sample group of the fragment of interest. If it is determined in step S111 that the sample of interest group is the last sample group of the fragment of interest, the process returns to step S101, and for example, the next fragment of the fragment of interest is taken as the new fragment of interest. Hereinafter, the same processing is repeated.
  • FIG. 15 is a flowchart illustrating an example of processing of receiving content in units of portions.
  • step S121 the reception unit 31 of the client 12 (FIG. 3) waits for the http response as a portion to be multicast-distributed, receives the http response as the portion, and the process proceeds to step S122.
  • step S122 the reproduction unit 33 reproduces the sample group included in the http response as the portion received by the reception unit 31 according to the moof subset included in the http response and the sequence included in the http header of the http response.
  • the number sqn, the version v, the NTP time nt, and the sample count start scs are used as needed.
  • step S122 returns from step S122 to step S121, and the same process is repeated thereafter.
  • the distribution server 11 does not wait for a segment to be generated, and when a sample group which is a part of a fragment included in the segment is generated, the http as a portion including the sample group is generated. Since the response is delivered, the content can be delivered quickly.
  • FIG. 16 is a diagram for explaining multicast distribution of portions (and segments) by LCT packets.
  • portions (and segments) are packetized into LCT packets, and the multicast server 25 multicasts the LCT packets.
  • Packetization of portions into LCT packets in the FLUTE streamer 24 is performed, for example, by dividing the portions into small pieces of a predetermined size and storing each small piece in an LCT packet, as shown in FIG. It will be.
  • FIG. 17 is a diagram showing the format of the LCT packet.
  • the LCT packet is configured by arranging an LCT header (LCT Header), an FEC Payload ID, and an Encoding Symbol (s) in that order.
  • LCT Header LCT Header
  • FEC Payload ID FEC Payload ID
  • Encoding Symbol s
  • Portions of portions are stored in LCT packets as Encoding Symbols.
  • FIG. 18 shows the format of the LCT header.
  • the LCT header includes a Transport Session Identifier (TSI), a Transport Object Identifier (TOI), and a necessary extension header (Header Extensions).
  • TSI Transport Session Identifier
  • TOI Transport Object Identifier
  • Header Extensions a necessary extension header
  • the TSI is an identifier that identifies a session of the LCT packet.
  • the TSIs of LCT packets obtained by packetizing portions 60, 70, and 80 each including sample groups 56, 57, and 58 to be originally delivered in one segment 50 are identical to each other. Set to a value.
  • the TOI is an identifier that identifies an object whose data is stored in the Encoding Symbol of the LCT packet. For example, the TOI of the LCT packet in which the small pieces obtained by dividing the portion 60 are stored in the Encoding Symbol is set to the same value.
  • FIG. 19 is a diagram illustrating an example of delivery of content in units of portions.
  • a certain fragment has sample groups # 1, # 2, # 3,.
  • the sample group # 1 is, for example, a video of a base view (a view of the base layer) which does not refer to another view, and the sample groups # 2, # 3,. It is a non-base view (enhanced layer view) video that may refer to other views.
  • the client 12 Since the TOI of the LCT packet #i in which the small piece of a portion #i is stored has the same value, the client 12 receives the LCT packet, and among the received LCT packets, the TOI is the same. By collecting pieces of portion #i stored in the LCT packet, the original portion #i can be reconstructed.
  • the sample group # 1 included in the portion # 1 is a video of the base view, and the sample groups # 2, # 3,. It is a video.
  • the sample group included in the portion is data (processing unit) that can be classified based on some standard, such as a base view video or a non-base view video. It is possible to perform packet filtering for discarding LCT packets on a sample group basis included).
  • LCT packets for example, when it is difficult to allocate sufficient resources (including the resources of the client 12 that finally receives the LCT packet) to delivery of the LCT packet due to, for example, fluctuations in the network environment to which the LCT packet is delivered.
  • a router on the delivery path of LCT packets for example, a router for FLUTE multicast
  • the network stack of client 12 a block for processing LCT packets
  • only LCT packets with high processing priority Can be selected to perform processing (processing such as transfer or stack).
  • packet filtering is performed by selecting and processing only the minimum necessary LCT packets and LCT packets with high processing priority as described above.
  • the demand for technology is high.
  • the sample group included in the portion may be a base view video or a non-base view video in the http header as the portion.
  • Attribute information for example, FDT etc.
  • the LCT packet in which a portion (piece) of the portion including the sample group is stored is discarded There is a way to choose.
  • the LCT packet can be used to recognize the attribute information of the sample group each time the packet filtering is performed. Portions must be reconfigured, making it difficult to perform packet filtering efficiently.
  • the FLUTE streamer 24 generates an LCT packet having an LCT header including a priority parameter indicating the priority of processing of the LCT packet, and the multicast server 25 generates an LCT including such a priority parameter.
  • Multicast delivery of LCT packets with a header enables efficient packet filtering, which enables the required LCT packets to be delivered and processed quickly.
  • a priority parameter is included in the LCT header by extending the extension header of the LCT header so that the priority parameter can be stored.
  • FIG. 20 is a diagram showing a format of an extension header (Header Extentions) of the LCT header of FIG.
  • HET Header Extension Type
  • HET When 8-bit HET is less than 127, HET is followed by 8-bit HEL (Header Extension Length).
  • HEL Header Extension Length
  • a value N representing the length 32 ⁇ N bits of the extension header is set.
  • HEC Header Extension Content
  • a new extension header for storing priority parameters is defined by adopting a value not yet defined for HET. Do.
  • FIG. 21 is a diagram showing an example of definition of a new extension header storing priority parameters.
  • the new extension header is configured by arranging 8 bits of HET, 8 bits of HEL, 8 bits of Filtering Scheme URI, 8 bits of Filtering Parameter Length, and 8 ⁇ FPLN bits of Filtering Parameters in that order.
  • 120 is set in the extension header as a value indicating that the priority parameter is stored in the HET of the new extension header.
  • HET since HET is 127 or less, HET is placed after HET as shown in FIG.
  • HEL an integer value HELN in the range of 0 to 255 is set.
  • HELN a value such that 32 ⁇ HELN is the length of the extension header is adopted.
  • Filtering Scheme URI is a scheme identifier (SchemeURI) that defines Filtering Parameter.
  • an integer value FPLN in the range of 0 to 255 is set.
  • the integer value FPLN 32 ⁇ FPLN is adopted as a value which is the length of the Filtering Parameter.
  • Filtering Parameter is a priority parameter, and its definition (structure) is specified by Filtering Scheme URI.
  • FIG. 22 is a diagram showing an example of definition of priority parameter (Filtering Parameter).
  • the priority parameter is 64 bits, 8-bit Track Reference Index, 8-bit Priority, 8-bit Dependency Counter, 8-bit MVC Filter Length, and 32-bit MVC Filter Are arranged and configured in that order.
  • a sample group as a part of a fragment stored in the LCT packet out of integer values in the range of 0 to 255 (a sample group included in a portion where a small piece is stored in the LCT packet)
  • a value is set that identifies the track (track of the MP4 file) to which the
  • packet filtering can be performed to preferentially select and process an LCT packet in which a small piece of portion including a sample group to which a predetermined track belongs is stored.
  • Priority is set for each LCT packet with the same TOI.
  • an index indicating the priority of processing of the LCT packet of TOI of each value is set.
  • the index set to “Priority” is an integer value in the range of 0 to 255 which ranks the priority of processing of the LCT packet. For example, the larger the value, the lower the priority.
  • Priority as a priority parameter, for example, it is possible to perform packet filtering for preferentially selecting and processing an LCT packet of TOI in which Priority equal to or less than a predetermined value is set.
  • Dependency Counter as a priority parameter, for example, packet filtering is performed to preferentially select and process an LCT packet with a Dependency Counter of 1 or more, that is, an LCT packet affecting one or more subsequent LCT packets. be able to.
  • MVC Filter Length takes a Boolean value, and when True, indicates that the subsequent MVC Filter exists.
  • the MVC Filter is information for performing filtering to select and select data of MVC (Multiview Video Coding) when the sample group included in the portion in which the small pieces are stored in the LCT packet is data of MVC (Multiview Video Coding).
  • MVC Filter for example, one or more of PRID (priority_id), TID (tempral_id), and VID (View_id) defined as a header of an MVC NAL (Network Abstraction Layer) unit stored in an RTP packet is adopted. can do.
  • PRID priority_id
  • TID tempral_id
  • VID View_id
  • FIG. 23 is a diagram illustrating an example of the definition of the MVC Filter.
  • the 32-bit MVC Filter is configured by arranging 6-bit priority_id (PRID), 3-bit temporal_id (TID), 10-bit view_id (VID), and 13-bit Reserved in that order.
  • PRID priority_id
  • TID 3-bit temporal_id
  • VID 10-bit view_id
  • 13-bit Reserved 13-bit Reserved
  • PRID TID, VID, and Reserved are defined as follows.
  • PRID 6 bits This flag speci? es a priority identifier for the NAL unit. A lower value of PRIdicates a higher priority.
  • TID 3 bits
  • a temporal layer consistent with a view component with a less temporal_id correspond to lower frame rate.
  • temporal_id This component species the temporal layer (or frame rate) hierarchy. A given temporal layer typically depends on the lower temporal layers (ie the temporal layers with less temporal_id values) but never depends on any higher temporal layer (ie a temporal layers with higher temporal_id value).
  • VID 10 bits This component specifies the view identifier of the view NAL unit belongs to. Reserved: 13 bits (Reserved bit for future expansion)
  • the PID represents the priority of the NAL unit (when the sample group included in the portion in which the small pieces are stored in the LCT packet is the NAL unit). The smaller the PID, the higher the priority of the NAL unit.
  • TID represents a temporal layer (or frame rate) of video (when a sample group included in a portion in which a small piece is stored in a LCT packet is (data of) video).
  • a layer may depend on a lower layer whose TID is smaller than that of the layer but does not depend on an upper layer whose TID is large.
  • VID represents the view to which the NAL unit belongs.
  • Reserved is a reserved bit for the future.
  • an LCT packet including a NAL unit having a high priority is preferentially selected based on the PID. Packet filtering can be performed.
  • video with a temporal layer below a predetermined layer that is, LCT packets including video with a frame rate as a temporal resolution lower than a predetermined value is preferentially selected. It can perform packet filtering to process.
  • packet filtering may be performed to preferentially select and process LCT packets including (a NAL unit of) a video of a predetermined view.
  • the LCT packet includes any video of moving image and still image
  • information indicating that the video is moving image or still image is adopted as the priority parameter.
  • packet filtering can be performed to preferentially select and process LCT packets including moving image or still image video.
  • the LCT packet contains video of any layer of the base layer that does not refer to other layers and one or more non-base layers that may refer to other layers.
  • the information representing the layer of can be adopted as a priority parameter.
  • packet filtering may be performed to preferentially select and process LCT packets including base layer video.
  • the LCT packet contains video of any of the multiple views
  • information representative of the video view may be employed as the priority parameter.
  • a video of a view desired by the user e.g., a video of a plurality of views taken from a plurality of positions such as a first base, a third base, and a back net side in baseball broadcasting
  • the LCT packet when the LCT packet includes video of any one of a plurality of resolutions, information representing the resolution can be adopted as the priority parameter.
  • packet filtering may be performed to preferentially select and process an LCT packet including video of a predetermined resolution (below).
  • information representing resolution as a priority parameter information of either or both of a temporal resolution and a spatial resolution can be adopted.
  • Packet filtering can be performed based on one or more types of priority parameters in addition to one type of priority parameter.
  • the video of the predetermined view and including the video of the predetermined resolution LCT packets can be preferentially selected and processed.
  • FIG. 24 is a flowchart for explaining an example of processing of delivery of an LCT packet having a priority parameter.
  • step S201 the FLUTE streamer 24 (FIG. 2) of the delivery server 11 stores the data (a small piece of the portion supplied from the segmenter 22) stored in the encoding symbol (FIG. 17) of the LCT packet.
  • the priority parameter is set based on the operation or the like of the operator, and the process proceeds to step S202.
  • step S202 the FLUTE streamer 24 generates an extension header (FIG. 21) (FIG. 22) including the priority parameter set in step S201, and the process proceeds to step S203.
  • the FLUTE streamer 24 has an LCT header (FIG. 18) including the extension header generated in step S202, and an LCT packet (FIG. 17) in which a small piece of portion supplied from the segmenter 22 is arranged in the encoding symbol.
  • LCT header FOG. 18
  • LCT packet FOG. 17
  • step S204 the multicast server 25 distributes by multicast the LCT packet from the FLUTE streamer 24, and the process returns to step S201, and the same process is repeated thereafter.
  • FIG. 25 is a flowchart illustrating an example of packet filtering processing performed by the client 12 (other devices such as a router that receives an LCT packet to be multicast-distributed).
  • step S211 the receiving unit 30 (FIG. 3) of the client 12 sets a threshold for processing the LCT packet based on the network environment, the resource of the apparatus (client 12), the user's operation, the user's preference, etc. Degree (hereinafter, also referred to as threshold priority) is set, and the process proceeds to step S212.
  • a threshold for processing the LCT packet based on the network environment, the resource of the apparatus (client 12), the user's operation, the user's preference, etc.
  • Degree hereinafter, also referred to as threshold priority
  • step S212 the reception unit 30 waits for the LCT packet to be multicast-distributed, and receives the LCT packet, and the process proceeds to step S213.
  • step S213 the receiving unit 30 determines whether to process the LCT packet based on the priority parameter included in the LCT header of the LCT packet received in step S212 and the threshold priority set in step S211. And the process proceeds to step S214.
  • step S214 the receiving unit 30 selects and discards the LCT packet according to the determination result of the availability determination in step S213, and cancels the process for an LCT packet having a priority parameter whose priority is lower than the threshold priority, Processing is continued for LCT packets having a priority parameter with priority equal to or higher than the threshold priority. Then, the process returns from step S214 to step S211, and the same process is repeated thereafter.
  • FIG. 26 shows a configuration example of an embodiment of a computer in which a program for executing the series of processes described above is installed.
  • the program can be recorded in advance in a hard disk 305 or ROM 303 as a recording medium built in the computer.
  • the program can be stored (recorded) in the removable recording medium 311.
  • Such removable recording medium 311 can be provided as so-called package software.
  • examples of the removable recording medium 311 include a flexible disc, a compact disc read only memory (CD-ROM), a magneto optical disc (MO), a digital versatile disc (DVD), a magnetic disc, a semiconductor memory, and the like.
  • the program may be installed on the computer from the removable recording medium 311 as described above, or may be downloaded to the computer via a communication network or a broadcast network and installed on the built-in hard disk 305. That is, for example, the program is wirelessly transferred from the download site to the computer via an artificial satellite for digital satellite broadcasting, or transferred to the computer via a network such as a LAN (Local Area Network) or the Internet. be able to.
  • a network such as a LAN (Local Area Network) or the Internet.
  • the computer incorporates a CPU (Central Processing Unit) 302, and an input / output interface 310 is connected to the CPU 302 via a bus 301.
  • a CPU Central Processing Unit
  • the CPU 302 executes a program stored in a ROM (Read Only Memory) 303 accordingly. .
  • the CPU 302 loads a program stored in the hard disk 305 into a random access memory (RAM) 304 and executes the program.
  • RAM random access memory
  • the CPU 302 performs the processing according to the above-described flowchart or the processing performed by the configuration of the above-described block diagram. Then, the CPU 302 causes the processing result to be output from the output unit 306, transmitted from the communication unit 308, or recorded in the hard disk 305, for example, via the input / output interface 310, as necessary.
  • the input unit 307 is configured of a keyboard, a mouse, a microphone, and the like.
  • the output unit 306 is configured of an LCD (Liquid Crystal Display), a speaker, and the like.
  • the processing performed by the computer according to the program does not necessarily have to be performed chronologically in the order described as the flowchart. That is, the processing performed by the computer according to the program includes processing executed in parallel or separately (for example, parallel processing or processing by an object).
  • the program may be processed by one computer (processor) or may be distributed and processed by a plurality of computers. Furthermore, the program may be transferred to a remote computer for execution.
  • the system means a set of a plurality of components (apparatus, modules (parts), etc.), and it does not matter whether all the components are in the same housing or not. Therefore, a plurality of devices housed in separate housings and connected via a network, and one device housing a plurality of modules in one housing are all systems. .
  • the present technology can have a cloud computing configuration in which one function is shared and processed by a plurality of devices via a network.
  • each step described in the above-described flowchart can be executed by one device or in a shared manner by a plurality of devices.
  • the plurality of processes included in one step can be executed by being shared by a plurality of devices in addition to being executed by one device.
  • fragments (parts of data) of any data format can be adopted as fragments for which portions are to be generated, in addition to fragments of fragmented MP 4 (ISO / IEC 14496-14).
  • fragments for which portions are to be generated for example, ISO base media file format (ISO / IEC 14496-12), a format specified in ISO / IEC 14496-15, QuickTime format, and other so-called boxes
  • ISO base media file format ISO / IEC 14496-12
  • a format specified in ISO / IEC 14496-15 QuickTime format
  • other so-called boxes A fragment of a data format having a structure, or a fragment obtained by fragmenting data of a data format having no box structure (for example, TS (Transport Stream) etc.) can be employed.
  • a fragment for which a portion is to be generated for example, a MPEG TS (Transport Stream), a webM, or any other moving image format fragment can be adopted.
  • MPEG TS Transport Stream
  • webM webM
  • the present technology can be applied to delivery of arbitrary data other than content.
  • the present technology can be configured as follows.
  • a transmitter comprising: a distribution unit configured to distribute an LCT packet having a Layered Coding Transport (LCT) header including a priority parameter for indicating the priority of processing of the packet.
  • LCT Layered Coding Transport
  • the extension header includes, in addition to the priority parameter, a scheme identifier that defines the priority parameter.
  • the priority parameter includes information indicating that the video is a moving image or a still image.
  • ⁇ 5> In the case where the LCT packet contains video data of any of the base layer and one or more non-base layers, The transmission apparatus according to any one of ⁇ 1> to ⁇ 4>, wherein the priority parameter includes information representing a layer of the video.
  • the priority parameter includes information representing a view of the video.
  • the priority parameter includes information representing a resolution of the video.
  • the priority parameter includes information indicating a spatial resolution or temporal resolution of the video as the information indicating the resolution of the video.
  • the priority parameter includes an index indicating the priority of processing of the LCT packet of each value TOI, which is set for each of the LCT packets having the same TOI (Transport Object Identifier) ⁇ 1> to ⁇ 8>
  • the transmitter according to any one of the above.
  • the LCT packet includes data of Multiview Video Coding (MVC)
  • MVC Multiview Video Coding
  • the transmission apparatus according to any one of ⁇ 1> to ⁇ 10>, wherein the priority parameter includes information for performing filtering to select data of the MVC.
  • the information for performing the filtering may be PRID (priority_id), TID (tempral_id), and PRID defined as a header of a Network Abstraction Layer (NAL) unit of MVC stored in a Real-time Transport Protocol (RTP) packet.
  • PRID priority_id
  • TID Temporal_id
  • RTP Real-time Transport Protocol
  • the transmitter according to ⁇ 11>, including one or more of VID (view_id).
  • a transmission method including the step of delivering an LCT packet having a Layered Coding Transport (LCT) header including a priority parameter for indicating the priority of processing of the packet.
  • a receiving apparatus comprising: a receiving unit that receives an LCT packet having a Layered Coding Transport (LCT) header including a priority parameter for indicating a priority of processing of the packet.
  • the priority parameter is included in an extension header of the LCT header.
  • the receiving device includes, in addition to the priority parameter, a scheme identifier that defines the priority parameter.
  • the priority parameter includes information indicating that the video is a moving image or a still image.
  • the priority parameter includes information representing a layer of the video.
  • the priority parameter includes information representing a view of the video.
  • the receiving device according to any one of ⁇ 15> to ⁇ 20>, wherein the priority parameter includes information representing a resolution of the video.
  • the priority parameter includes information indicating a spatial resolution or temporal resolution of the video as the information indicating the resolution of the video.
  • the priority parameter includes an index indicating the priority of processing of the LCT packet of each value TOI, which is set for each of the LCT packets having the same TOI (Transport Object Identifier) ⁇ 15> to ⁇ 22>
  • the receiver according to any one.
  • the priority parameter includes information for performing filtering to select data of the MVC.
  • the information for performing the filtering may be PRID (priority_id), TID (tempral_id), and PRID defined as a header of a Network Abstraction Layer (NAL) unit of MVC stored in a Real-time Transport Protocol (RTP) packet.
  • PRID Priority_id
  • TID Temporal_id
  • PRID defined as a header of a Network Abstraction Layer (NAL) unit of MVC stored in a Real-time Transport Protocol (RTP) packet.
  • the receiving device according to ⁇ 25>, including one or more of VID (view_id).
  • the receiving apparatus according to any one of ⁇ 15> to ⁇ 26>, wherein the priority parameter includes information indicating the number of subsequent LCT packets affected by the LCT packet including the priority parameter.
  • a receiving method comprising: receiving an LCT packet having a Layered Coding Transport (LCT) header including a priority parameter for indicating a priority of processing of the packet.
  • LCT Layered Coding Transport

Landscapes

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

Abstract

La présente invention concerne un appareil et un procédé de transmission et un appareil et un procédé de réception permettant de distribuer rapidement des données. Un paquet de transport de codage en couches (LCT), qui présente un en-tête LCT comprenant un paramètre de niveau de priorité utilisé pour indiquer un niveau de priorité pour un traitement de paquet, est distribué. Un récepteur ayant reçu le paquet LCT peut déterminer, sur la base du paramètre de niveau de priorité compris dans l'en-tête LCT du paquet LCT, s'il convient de traiter le paquet LCT. Cette technique peut s'appliquer, par exemple, à un cas de distribution de contenu en multidiffusion ou analogue.
PCT/JP2014/077659 2013-10-30 2014-10-17 Appareil et procédé de transmission et appareil et procédé de réception Ceased WO2015064384A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2013-225541 2013-10-30
JP2013225541 2013-10-30

Publications (1)

Publication Number Publication Date
WO2015064384A1 true WO2015064384A1 (fr) 2015-05-07

Family

ID=53003993

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/077659 Ceased WO2015064384A1 (fr) 2013-10-30 2014-10-17 Appareil et procédé de transmission et appareil et procédé de réception

Country Status (1)

Country Link
WO (1) WO2015064384A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015146647A1 (fr) * 2014-03-28 2015-10-01 ソニー株式会社 Dispositif d'émission, procédé d'émission, dispositif de réception, procédé de réception et programme

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080046575A1 (en) * 2006-08-21 2008-02-21 Nokia Corporation Caching directives for a file delivery protocol
JP2011101156A (ja) * 2009-11-05 2011-05-19 Nippon Hoso Kyokai <Nhk> 受信装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080046575A1 (en) * 2006-08-21 2008-02-21 Nokia Corporation Caching directives for a file delivery protocol
JP2011101156A (ja) * 2009-11-05 2011-05-19 Nippon Hoso Kyokai <Nhk> 受信装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015146647A1 (fr) * 2014-03-28 2015-10-01 ソニー株式会社 Dispositif d'émission, procédé d'émission, dispositif de réception, procédé de réception et programme
EP3125563A4 (fr) * 2014-03-28 2017-09-06 Sony Corporation Dispositif d'émission, procédé d'émission, dispositif de réception, procédé de réception et programme
US10432989B2 (en) 2014-03-28 2019-10-01 Saturn Licensing Llc Transmission apparatus, transmission method, reception apparatus, receiving method, and program

Similar Documents

Publication Publication Date Title
JP6329964B2 (ja) 送信装置、送信方法、受信装置、及び、受信方法
JP6845223B2 (ja) コーディングされたオーディオデータのトランスポート
CN110213666B (zh) 一种接收装置、接收方法及存储介质
TW201725911A (zh) 決定用於媒體傳輸的媒體傳遞事件位置
CN105325005B (zh) 内容供应装置、内容供应方法、存储介质、终端装置以及内容供应系统
KR102499231B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
KR20120114016A (ko) 사용자 컨텐츠를 외부 단말기에서 네트워크 적응적으로 스트리밍하는 방법 및 장치
CA2904959A1 (fr) Appareils de communication, procede de production de donnees de communication et procede de traitement de donnees de communication
KR102137858B1 (ko) 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
JPWO2015001986A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
CN105900437A (zh) 通信设备、通信数据生成方法和通信数据处理方法
WO2015064384A1 (fr) Appareil et procédé de transmission et appareil et procédé de réception
RU2658672C2 (ru) Устройство предоставления контента, программа, оконечное устройство и система предоставления контента
Eberhard et al. Nextsharepc: an open-source bittorrent-based p2p client supporting svc
WO2015012140A1 (fr) Dispositif de fourniture de contenu, procédé de fourniture de contenu, programme, dispositif de terminal et système de fourniture de contenu

Legal Events

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

Ref document number: 14858669

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14858669

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP