WO2015064384A1

WO2015064384A1 - Transmission apparatus, transmission method, reception apparatus, and reception method

Info

Publication number: WO2015064384A1
Application number: PCT/JP2014/077659
Authority: WO
Inventors: 山岸　靖明
Original assignee: ソニー株式会社
Priority date: 2013-10-30
Filing date: 2014-10-17
Publication date: 2015-05-07

Abstract

This technique relates to a transmission apparatus, a transmission method, a reception apparatus and a reception method for enabling data to be quickly delivered. A Layerd Coding Transport (LCT) packet, which has an LCT header including a priority level parameter used for indicating a priority level for packet processing, is delivered. A receiver having received the LCT packet can determine, on the basis of the priority level parameter included in the LCT header of the LCT packet, whether to process the LCT packet. This technique is applicable, for example, to a case of multicast delivery of contents or the like.

Description

Transmission apparatus, transmission method, reception apparatus, and reception method

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. .

In recent years, the mainstream of streaming services on the Internet has become OTT-V (Over The Top Video). For example, MPEG-DASH (Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)) (hereinafter, also referred to as DASH) is beginning to spread as a basic technology of OTT-V.

In DASH, for example, 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).

That is, in DASH, 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.

On the other hand, 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.

In DASH, metadata used for content reproduction control, called MPD, is distributed from the server to the client so that the client can adaptively select and receive a stream.

In the MPD, a URL (Uniform Resource Locator) or the like as an address of a segment (media data such as Audio / Video / Subtitle) obtained by dividing the content is described. 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. .

Since distribution of content by DASH is realized by point-to-point http streaming, it is applied, for example, to streaming of content (program) that may be viewed by a large number of users simultaneously, such as sports broadcasting. Requires the use (support) of CDN (Contents Delivery Network) such as Akamai.

However, even with the use of the CDN, it is difficult to obtain the scalability comparable to the existing broadcast distribution due to the cost limitation of the CDN.

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.

By the way, in the current DASH, files are distributed in segment units, with (segments of files) divided from the stream of content as file distribution units (control targets) in DASH.

Therefore, in the current DASH, in the case of multicast delivery of content (including broadcast delivery), it is necessary to wait for delivery of content until a segment is generated.

From now on, it is expected that video delivery with higher image quality will be commonplace, in which case the bit rate of the content stream will be high.

If the 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.

Therefore, waiting for completion of segment generation and delivering content on a segment basis will eventually delay the reception of content at the client and the start of buffering. It is requested to propose a technology to deliver

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 according to an embodiment of the present technology 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.

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.

In the transmission device and transmission method of the present technology as described above, 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 according to an embodiment of the present technology 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.

A receiving method according to the present technology 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.

In the receiving device and the receiving method of the present technology as described above, 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.

Note that the transmitting device and the receiving device may be independent devices or may be internal blocks constituting one device.

According to the present technology, data can be rapidly distributed.

In addition, the effect described here is not necessarily limited, and may be any effect described in the present disclosure.

BRIEF DESCRIPTION OF DRAWINGS 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. 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. It is a flowchart explaining the example of processing of reception of the content in a portion unit. It is a figure explaining the multicast delivery of the portion (and segment) by LCT packet. It is a figure which shows the format of a LCT packet. It is a figure which shows the format of a LCT header. It is a figure which shows the example of delivery of the content in a portion unit. It is a figure which shows the format of the extension header (Header Extentions) of a LCT header. It is a figure which shows the example of the definition of the new extension header which stores a priority parameter. It is a figure which shows the example of the definition of a priority parameter (Filtering Parameter). It is a figure which shows the example of the definition of MVC Filter. It is a flow chart explaining an example of processing of delivery of a LCT packet which has a priority parameter. It is a flow chart explaining an example of processing of packet filtering which client 12 performs. 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.

In FIG. 1, 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.

In the content providing system of FIG. 1, content is provided from the distribution server 11 to the client 12 via the network 10 using the DASH.

Here, in the current DASH, it is assumed that streaming itself is performed by unicast on the OTT / CDN (Over The Top / Contents Delivery Network), but in the content providing system of FIG. Besides unicast distribution, for example, 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. As the network 10, for example, MBMS (Multimedia Broadcast Multicast Service) (including eMBMS (Evolved MBMS)) or the like of 3rd Generation Partnership Project (3GPP) can be adopted.

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.

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.

In FIG. 2, 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.

Here, 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. When the channel streamers 21 to the web servers 26 are distributed and arranged on the network 10, 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.

That is, 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.

In addition, 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.

Here, 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.

That is, 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.

Furthermore, 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.

In addition, 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).

Here, as described above, (the segment or portion of the content) and the metadata are stored in the LCT packet from the FLUTE streamer 24, 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.

Here, as described above, the multicast server 25 and the web server 26 function as a distribution unit that distributes content and metadata.

In FIG. 2, 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.

In FIG. 3, 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.

That is, 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.

Then, 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.

Here, 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.

Then, when the MPD or segment requested by the http request output by the DASH client 32 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.

When the MPD or segment requested by the http request output from the DASH client 32 has already been received, the middleware 31 supplies the received MPD or segment to the DASH client 32.

On the other hand, when the MPD or segment requested by the http request output by the DASH client 32 is not distributed by multicast, 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.

Therefore, 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.

In 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.

Then, in 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 (FIG. 2) receives the content (a plurality of streaming data) supplied from the channel streamer 21 in step S21.

In 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.

Further, in step S24, the segmenter 22 generates segment relation information and supplies the information to the metadata generator 23.

In step S31, the metadata generator 23 (FIG. 2) receives the relationship information of the segments supplied from the segmenter 22 in step S24.

Then, in 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 (FIG. 2) 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.

Further, in 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 (FIG. 2) 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.

Then, in 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.

In 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.

Then, in step S63, when the http request for requesting metadata is transmitted from the client 12, the web server 26 receives the http request.

Thereafter, in step S64, the web server 26 unicasts the metadata requested by the http request from the client 12 to the client 12.

In 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.

Thereafter, in 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.

In the client 12 (FIG. 3), in step S71, the reception unit 30 receives (the LCT packet of) metadata to which the multicast server 25 performs multicast distribution in step S53.

Alternatively, in the client 12, 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.

In step S73, the reception unit 30 of the client 12 receives the metadata distributed in the unicast manner as described above.

Then, in 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.

Alternatively, in the client 12, in 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.

As described above, 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 .

In step S76, the reception unit 30 of the client 12 receives the content unicast-distributed as described above.

Then, in 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).

FIG. 5 is a diagram showing an example of data distributed via the network 10 in the content providing system of FIG.

In the content providing system, 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.

As 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.

Now, assuming that a certain program is a program of interest, 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.

Therefore, when 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.

Therefore, when the client 12 acquires the USD of the program of interest, 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.

In the SDP of the program of interest, an IP address for multicast distribution of the content of the program of interest and transport attributes such as port numbers are described.

Therefore, by acquiring the SDP of the program of interest, it is possible to receive the content of the program of interest being multicast-distributed based on the IP address and port number described in the SDP.

As described above, according to the combination of USD and SDP, and the combination of USD, SDP and OMA-ESG, the client 12 recognizes that the content is to be delivered by multicast, and the content is delivered by multicast Content can be received.

In the MPD of the program of interest, the URL of the segment of the program of interest, information necessary for playback control of the segment, and the like are described.

Therefore, by acquiring the MPD of the program of interest, the segment of the program of interest can be received in unicast based on the URL described in the MPD. In addition, the segment of the program of interest can be reproduced based on the MPD of the program of interest.

That is, 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.

Here, 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 (Media Segment) has styp (segment type) (box), necessary sidx (segment index) (box), and one or more fragments (MP4 fragments).

Here, when styp is 'msdh', the segment does not include sidx, and when styp is 'msix', the segment includes sidx. Hereinafter, the description of 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).

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.

In A of FIG. 8, each of three consecutive segments # 1, # 2, # 3 has one fragment.

In this case, assuming that the sequence_number (hereinafter also referred to as sqn) of one fragment of the first segment # 1 is 1, for example, the sqn of one fragment of the second segment # 2 is For example, the previous fragment sqn = 1 is incremented by 1 to 2. Furthermore, the sqn of one fragment included in the third segment # 3 is, for example, 3 obtained by incrementing the previous fragment sqn = 2 by one.

B of FIG. 8 shows a configuration example of a segment having a plurality of fragments.

In FIG. 8B, segment # 1 has 3 fragments.

In this case, assuming that the sqn of the first fragment of segment # 1 is 1, for example, the sqn of the second fragment of segment # 1 is, for example, 2 obtained by incrementing the previous fragment sqn = 1 by 1. Become. Furthermore, the sqn of the third fragment of segment # 1 is, for example, 3 obtained by incrementing the previous fragment sqn = 2 by one.

Hereinafter, in order to simplify the description, unless otherwise specified, 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.

In FIG. 9, 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.

Here, 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.

In addition, as a range of content to be fragmented (sample 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.

However, the range of content to be fragmented is not limited to the range of GOP.

As 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.

As a result, in the case of multicast delivery of a segment as a file delivery unit, it is necessary to wait for delivery of the segment at least only the time required for generating the segment.

In the future, it is expected that video delivery with higher image quality will be performed, in which case the data volume of the segment will be enormous. In the case where segments of such a large amount of data are to be distributed after waiting for the GOP time, the bandwidth of the network may be compressed and shaping may be necessary.

Therefore, if a segment is used as a file delivery unit, a delay will eventually occur in the reception of content at the client and the start of buffering.

Therefore, 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.

In FIG. 10, as in the case of FIG. 9, the sample groups # 1, # 2, and # 3 are sequentially generated as sample groups constituting fragments.

However, in FIG. 10, when the sample group # 1 is generated without waiting for the generation of the last sample group # 3 of the fragment to be completed in the segmenter 22 of the distribution server 11 (FIG. 2), 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.

Further, in FIG. 10, when the next sample group # 2 is generated in the segmenter 22, a portion as a file delivery unit including the sample group # 2 is generated, and in the FLUTE streamer 24 and the multicast server 25. , Multicast delivery.

Then, when generation of the last sample group # 3 of the fragment is completed in the segmenter 22, a portion as a file distribution unit including the sample group # 3 is generated, and multicast distribution is performed in the FLUTE streamer 24 and the multicast server 25. Be done.

As described above, 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.

Here, assuming that sample groups # 1 to # 3 are, for example, 1 GOP data, 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.

In A of FIG. 11, the segment 50 has styp 51 and (one) fragment 52.

Fragment 52 is composed of moof 53 and mdat 54.

In moof 53, as described in FIG. 7, the sequence number sqn of fragment 52 and BaseMediaDecodeTime representing the presentation time of the first sample of mdat 54 of fragment 52 (the first sample of sample group 56 in A of FIG. 11). Hereinafter, it is also called bmdt).

Here, in A of FIG. 11, 1 is set as the sequence number sqn of the fragment 52.

In the mdat 54, 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.

Of the three sample groups 56 to 58 stored in the mdat 54, 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.

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.

In FIG. 11A, the sample number of the first sample of the sample group 57 is n1, and 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.

That is, 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.

In FIG. 11, an http response (file) is adopted as the portion (file).

In FIG. 11B, 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).

Since a part of the fragment 52 included in the portion 60 including the version v of the http header 61 is the sample group 56 and the order of the sample group 56 in the fragment 52 is the first, 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. For example, when 6 (= 3 × 2) portions each including the divided sample group are generated, 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.

In FIG. 11B, 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.

In C of FIG. 11, 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 NTP time nt of the http header 71 represents the NTP time corresponding to bmdt stored in the moof 53 of the fragment 52 of which a portion (sample group 57) is partially included in the portion 70 including the NTP time nt. It is identical to time nt = NT.

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.

Since the first sample of the sample group 57 included in the portion 70 is the sample of the n1th sample from the top of the first sample group 56 as described in A of FIG. , 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.

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.

In FIG. 11D, 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.

Furthermore, since 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.

Thus, to receive a portion, eg, at client 12, according to version v, 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 NTP time nt of the http header 81 represents the NTP time corresponding to bmdt stored in the moof 53 of the fragment 52 whose part (sample group 58) is partially included in the portion 80 including the NTP time nt, and the

http headers

61 and 71 NTP time nt = identical to NT.

As described above, 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.

Therefore, 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.

Here, since 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.

As described above, since 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.

As described above, 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.

In addition, since the portion includes moof subsets, which are information of moof necessary for reproducing the sample group included in the portion, the client 12 receives all the portions (sample group) constituting the segment before receiving the portion. When one portion is received, 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 When the group is a reproducible sample group, 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.

Further, in FIG. 11, 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 Although 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 .

However, since the order of the first sample of the first sample group of fragments from the first sample of the fragment is always 1 and is a fixed value, the http header (version of the portion including the first sample group of fragments) For the http header (v is 1), as shown in B of FIG. 11, the sample count start scs can be omitted, whereby the size of the http header can be reduced.

Also, in the portion that is the http response, 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. When a portion is received, it is possible to reproduce a sample group included in the portion without the corresponding MPD.

That is, 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).

Here, the presentation time of the Nth sample of the fragment (PresendatioTime (CompositionTime) of Nth Sample) can be calculated according to the following equation.

PresentatioTime (CompositionTime) of Nth Sample =
BaseMediaDecodeTime + Sum of SampleDuration of (N-1) Samples + CompositionTimeOffset of Nth Sample

In addition, 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.

Since the NTP time corresponding to BaseMediaDecodeTime (BaseMediaDecodeTime = 0) that is the starting point is described in the DASH MPD, if the acquisition of the MPD is guaranteed, etc., the http header is stored in the fragment moof It is not necessary to include the NTP time nt corresponding to bmdt.

However, 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.

Also, in the portion that is the http response, 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.

That is, if it is guaranteed that the client 12 receives all of the portions that make up the segment, then 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.

However, when part of a plurality of parts constituting a segment is missing, the sample number is recognized without a sample count start scs for a sample included in the portion following the missing part. It is impossible to play and it becomes difficult to reproduce.

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.

In addition, since 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. In this case, 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, and 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.

Here, 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.

Here, for 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, and 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. Ru.

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.

In 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.

In 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.

That is, 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.

In 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.

In 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. By adding the http header, the http response as a portion is generated and supplied to the FLUTE streamer 24, and the process proceeds to step S105.

Here, when the segment including the fragment of interest includes a plurality of fragments and the fragment of interest is not the first fragment of the plurality of fragments, the http response as a portion generated in step S104 is styp (and Necessary sidx) is not included.

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 multicasts the LCT packet, and the process proceeds to step S106.

In 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.

In 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.

That is, 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.

In 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.

In 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.

In 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.

In step S111, the segmenter 22 determines whether the sample of interest is the last sample of the fragment of interest.

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.

Also, 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.

In 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.

In 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.

Then, the process returns from step S122 to step S121, and the same process is repeated thereafter.

As described above, 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.

As a result, it is possible to suppress the delay in the reception of content at the client 12 and the start of buffering.

FIG. 16 is a diagram for explaining multicast distribution of portions (and segments) by LCT packets.

In the FLUTE streamer 24, 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.

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).

The TSI is an identifier that identifies a session of the LCT packet. For example, 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 (FIG. 11) 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.

However, for example, in an LCT packet in which a small piece obtained by dividing the portion 60 is stored in the Encoding Symbol and in an LCT packet in which a small piece obtained by dividing the portion 70 is stored in the Encoding Symbol, data (small pieces) is stored in the Encoding Symbol. Since the objects are different between the

portions

60 and 70, the TOI is different between the LCT packet in which the small pieces dividing the portion 60 are stored in the Encoding Symbol and the LCT packet in which the small pieces dividing the portion 70 are stored in the Encoding Symbol .

In the client 12, when the TOI receives the same LCT packet, small pieces of the portion stored in the LCT packet can be collected to reconstruct the original portion.

FIG. 19 is a diagram illustrating an example of delivery of content in units of portions.

In FIG. 19, 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.

In the distribution of content in units of portions, the distribution server 11 generates portions #i including the sample group #i (i = 1, 2, 3...). Then, the portion #i is divided into small pieces, and the small portions of the portion #i are stored in the LCT packet #i and distributed.

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.

Here, as described above, in FIG. 19, 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.

As described above, in the case where 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).

That is, 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. Is the minimum necessary for a router on the delivery path of LCT packets (for example, a router for FLUTE multicast) or the network stack of client 12 (a block for processing LCT packets), or only LCT packets with high processing priority Can be selected to perform processing (processing such as transfer or stack).

In particular, in the case of content distribution using a mobile network, for example, where the network environment fluctuates sharply, 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.

As a method of performing packet filtering for discarding LCT packets on a unit-by-portion basis, for example, 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.) of a sample group is included that indicates something etc., and based on the attribute information of the sample group, 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.

However, by including the attribute information of the sample group included in the portion in the http header as a portion, 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.

Therefore, in the distribution server 11, 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.

In the present technology, 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.

In the first eight bits of the extension header, HET (Header Extension Type) representing the type of the extension header (the type of actual data stored as HEC in the extension header) is stored.

When 8-bit HET is less than 127, HET is followed by 8-bit HEL (Header Extension Length). In HEL, a value N representing the length 32 × N bits of the extension header is set.

Then, following the HEL, a 32 × N-8-8 bit variable length HEC (Header Extension Content) is stored. HEC is the actual data of the extension header.

On the other hand, when 8-bit HET is 128 or more, HET is followed by 32-bit HEC.

Although some values have already been defined for HET, in the present embodiment, 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.

For example, 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. In this case, since HET is 127 or less, HET is placed after HET as shown in FIG.

In HEL, an integer value HELN in the range of 0 to 255 is set. As the integer value 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.

In the Filtering Parameter Length, an integer value FPLN in the range of 0 to 255 is set. As 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).

For example, Filtering Scheme URI = 1000 represents the definition of FIG.

In FIG. 22, the priority parameter (Filtering 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.

In the Track Reference Index, 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

According to the Track Reference Index as a priority parameter, for example, 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. In Priority, 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.

According to 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.

In the Dependency Counter, the number K of subsequent LCT packets affected by the LCT packet including the Dependency Counter is set. If Dependency Counter = K, processing of the K subsequent L LCT packets of that Dependency Counter = K LCT packet depends on processing of the Dependency Counter = K LCT packet.

According to 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).

As the 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.

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, 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
Informally put, 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). The smaller the TID, the lower the frame rate. 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.

According to the MVC filter as described above, for example, when the LCT packet includes (a part of) a NAL unit as video, an LCT packet including a NAL unit having a high priority is preferentially selected based on the PID. Packet filtering can be performed.

Also, for example, on the basis of TID, video with a temporal layer below a predetermined layer (NAL unit), 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.

Furthermore, for example, based on the VID, packet filtering may be performed to preferentially select and process LCT packets including (a NAL unit of) a video of a predetermined view.

Besides, various information can be adopted as the priority parameter.

That is, for example, when 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. can do. In this case, packet filtering can be performed to preferentially select and process LCT packets including moving image or still image video.

Also, for example, if 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. In this case, for example, packet filtering may be performed to preferentially select and process LCT packets including base layer video.

Furthermore, for example, if the LCT packet contains video of any of the multiple views, then information representative of the video view may be employed as the priority parameter. In this case, for example, 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) It is possible to perform packet filtering for preferentially selecting and processing LCT packets including a video of a view taken from the back net side.

Also, for example, 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. In this case, for example, packet filtering may be performed to preferentially select and process an LCT packet including video of a predetermined resolution (below). As 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.

That is, for example, in packet filtering, based on the information representing the view of the video and the information representing the resolution as the priority parameter, for example, 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.

In 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.

In 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.

In 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. Are supplied to the multicast server 25 and the process proceeds to step S204.

In 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).

In 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.

In 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.

In 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.

In 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.

Next, the series of processes described above can be performed by hardware or software. When the series of processes are performed by software, a program constituting the software is installed in a general-purpose computer or the like.

Thus, 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.

Alternatively, 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. Here, 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.

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.

When an instruction is input by the user operating the input unit 307 or the like by the user via the input / output interface 310, the CPU 302 executes a program stored in a ROM (Read Only Memory) 303 accordingly. . Alternatively, the CPU 302 loads a program stored in the hard disk 305 into a random access memory (RAM) 304 and executes the program.

Thus, 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.

Here, in the present specification, 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.

Furthermore, in the present specification, 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. .

Note that the embodiments of the present technology are not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the present technology.

For example, 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.

Further, each step described in the above-described flowchart can be executed by one device or in a shared manner by a plurality of devices.

Furthermore, in the case where a plurality of processes are included in one step, 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.

Also, in the segmenter 22, 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).

That is, as 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 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.

Furthermore, as 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.

In addition, the present technology can be applied to delivery of arbitrary data other than content.

Here, the effects described in the present specification are merely examples and are not limited, and other effects may be present.

The present technology can be configured as follows.

<1>
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.
<2>
The transmission apparatus according to <1>, wherein the priority parameter is included in an extension header of the LCT header.
<3>
The transmission apparatus according to <2>, wherein the extension header includes, in addition to the priority parameter, a scheme identifier that defines the priority parameter.
<4>
In the case where the LCT packet contains video data,
The transmission apparatus according to any one of <1> to <3>, wherein 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.
<6>
In the case where the LCT packet contains video data of any of a plurality of views,
The transmission apparatus according to any one of <1> to <5>, wherein the priority parameter includes information representing a view of the video.
<7>
In the case where the LCT packet contains video data,
The transmission apparatus according to any one of <1> to <6>, wherein the priority parameter includes information representing a resolution of the video.
<8>
The transmission apparatus according to <7>, wherein the priority parameter includes information indicating a spatial resolution or temporal resolution of the video as the information indicating the resolution of the video.
<9>
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.
<10>
If the LCT packet contains part of a fragment of fragmented MP4:
The transmission apparatus according to any one of <1> to <9>, wherein the priority parameter includes information identifying a track to which a part of the fragment belongs.
<11>
In the case where the LCT packet includes data of Multiview Video Coding (MVC),
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.
<12>
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. The transmitter according to <11>, including one or more of VID (view_id).
<13>
The transmission apparatus according to any one of <1> to <12>, wherein the priority parameter includes information indicating the number of subsequent LCT packets affected by the LCT packet including the priority parameter.
<14>
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.
<15>
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.
<16>
The receiving apparatus according to <15>, wherein the priority parameter is included in an extension header of the LCT header.
<17>
The receiving device according to <16>, wherein the extension header includes, in addition to the priority parameter, a scheme identifier that defines the priority parameter.
<18>
In the case where the LCT packet contains video data,
The receiving device according to any one of <15> to <17>, wherein the priority parameter includes information indicating that the video is a moving image or a still image.
<19>
In the case where the LCT packet contains video data of any of the base layer and one or more non-base layers,
The receiving apparatus according to any one of <15> to <18>, wherein the priority parameter includes information representing a layer of the video.
<20>
In the case where the LCT packet contains video data of any of a plurality of views,
The receiver according to any one of <15> to <19>, wherein the priority parameter includes information representing a view of the video.
<21>
In the case where the LCT packet contains video data,
The receiving device according to any one of <15> to <20>, wherein the priority parameter includes information representing a resolution of the video.
<22>
The reception apparatus according to <21>, wherein the priority parameter includes information indicating a spatial resolution or temporal resolution of the video as the information indicating the resolution of the video.
<23>
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.
<24>
If the LCT packet contains part of a fragment of fragmented MP4:
The receiver according to any one of <15> to <23>, wherein the priority parameter includes information identifying a track to which a part of the fragment belongs.
<25>
In the case where the LCT packet includes data of Multiview Video Coding (MVC),
The receiving device according to any one of <15> to <24>, wherein the priority parameter includes information for performing filtering to select data of the MVC.
<26>
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. The receiving device according to <25>, including one or more of VID (view_id).
<27>
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.
<28>
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.

10 Network, 11 Distribution Server, 12 Client, 13 NTP Server, 21 Channel Streamer, 22 Segmenter, 23 Metadata Generator, 24 FLUTE Streamer, 25 Multicast Server, 26 Web Server, 30 Receiver, 31 Middleware, 32 DASH Client, 33 Reproduction unit, 301 bus, 302 CPU, 303 ROM, 304 RAM, 305 hard disk, 306 output unit, 307 input unit, 308 communication unit, 309 drive, 310 input / output interface, 311 removable recording medium

Claims

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.
The transmission apparatus according to claim 1, wherein the priority parameter is included in an extension header of the LCT header.
The transmitting apparatus according to claim 2, wherein the extension header includes, in addition to the priority parameter, a scheme identifier that defines the priority parameter.
In the case where the LCT packet contains video data,
The transmission apparatus according to claim 3, wherein the priority parameter includes information indicating that the video is a moving image or a still image.
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 claim 3, wherein the priority parameter includes information representing a layer of the video.
In the case where the LCT packet contains video data of any of a plurality of views,
The transmission apparatus according to claim 3, wherein the priority parameter includes information representing a view of the video.
In the case where the LCT packet contains video data,
The transmission apparatus according to claim 3, wherein the priority parameter includes information representing a resolution of the video.
The transmitting apparatus according to claim 7, wherein the priority parameter includes information representing a spatial resolution or temporal resolution of the video as the information representing the resolution of the video.
The transmitting apparatus according to claim 3, wherein the priority parameter includes an index indicating a processing priority of the LCT packet of each value TOI, which is set for each of the LCT packets having the same TOI (Transport Object Identifier). .
If the LCT packet contains part of a fragment of fragmented MP4:
The transmitting apparatus according to claim 3, wherein the priority parameter includes information identifying a track to which a part of the fragment belongs.
In the case where the LCT packet includes data of Multiview Video Coding (MVC),
The transmitting apparatus according to claim 3, 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. The transmission device according to claim 11, comprising one or more of VID (view_id).
The transmitting apparatus according to claim 3, wherein the priority parameter includes information indicating the number of subsequent LCT packets affected by the LCT packet including the priority parameter.
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 receiver according to claim 15, wherein the priority parameter is included in an extension header of the LCT header.
The receiving apparatus according to claim 16, wherein the extension header includes, in addition to the priority parameter, a scheme identifier that defines the priority parameter.
In the case where the LCT packet contains video data,
The receiving device according to claim 17, wherein the priority parameter includes information indicating that the video is a moving image or a still image.
In the case where the LCT packet contains video data of any of the base layer and one or more non-base layers,
The receiving apparatus according to claim 17, wherein the priority parameter includes information representing a layer of the video.
In the case where the LCT packet contains video data of any of a plurality of views,
The receiving device according to claim 17, wherein the priority parameter includes information representing a view of the video.
In the case where the LCT packet contains video data,
The receiving apparatus according to claim 17, wherein the priority parameter includes information representing a resolution of the video.
The receiving apparatus according to claim 21, wherein 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 receiving apparatus according to claim 17, wherein the priority parameter includes an index indicating a processing priority of the LCT packet of each value TOI, which is set for each of the LCT packets having the same TOI (Transport Object Identifier). .
If the LCT packet contains part of a fragment of fragmented MP4:
The receiver according to claim 17, wherein the priority parameter includes information identifying a track to which a part of the fragment belongs.
In the case where the LCT packet includes data of Multiview Video Coding (MVC),
The receiving apparatus according to claim 17, 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. 26. The receiving device according to claim 25, comprising one or more of VID (view_id).
The receiving apparatus according to claim 17, 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.