JP6804164B2 - Content distribution system - Google Patents

Description

The present invention relates to a content distribution system that multicasts video content such as television broadcasting.

Various video distribution services are provided, such as a television broadcast distribution service that distributes television broadcasts using a communication network. Since many viewers watch television broadcasts at the same time, it is preferable to use multicast transmission (Patent Document 1 and Patent Document 2). By the way, on the Internet, HTTP is often used as an upper layer protocol, and a video distribution service for transmitting a video in accordance with HTTP is provided (for example, HTTP Live Streaming of Apple Inc. of the United States). In such a video distribution service, a plurality of video segment files are distributed with reference to playlist information. However, when an attempt is made to realize an HTTP-compliant video distribution service by multicast transmission, communication loss is likely to occur because connectionless UDP is used, which causes playback loss for each segment file. In the case of normal digital television broadcasting, information loss occurs in units of MPEG2-TS packets (fixed length of 188 bytes), and streaky noise with a thickness of 16 dots appears in the video for about 0.5 seconds. However, if information loss occurs in segment file units due to IP multicast UDP packets, the video will stop for several seconds to several tens of seconds.

The above-mentioned prior art and its problems are described only for the purpose of explaining a part of the background of the present invention. It should be noted that the present invention is not limited to the above-mentioned prior art and problems.

JP-A-2002-185943 Japanese Patent Application Laid-Open No. 2003-522442

The present invention has been made in consideration of the above circumstances, and is a content distribution technology that uses IP multicast communication and further reduces playback loss as much as possible when distributing a moving image in accordance with HTTP. It is intended to be provided.

According to the present invention, in order to achieve the above-mentioned object, the configuration as described in the claims is adopted. Here, prior to explaining the invention in detail, the description of the scope of claims will be supplementarily explained.

According to one aspect of the present invention, in order to achieve the above object, a video content processing device that can be connected to a communication network: a UDP packet that decomposes a video file containing a plurality of TS packets and is transmitted by IP multicast. The UDP packet receiving means for receiving the above; the video file reconstructing means for reconstructing the UDP packet received by the UDP packet receiving means into the video file; the video file reconstructed by the video file reconstructing means for the communication net. It is configured to include a transmission means for transmitting to the user terminal via the work in accordance with HTTP; the video file reconstructing means receives at least one UDP packet out of a plurality of UDP packets corresponding to the video file. If it is not received, the moving image file is reconstructed in a manner containing only a complete TS packet.

Further, according to another aspect of the present invention, in order to achieve the above object, a user terminal that can connect to a communication network: a playback means for playing a moving image file containing a plurality of TS packets; and a plurality of TS packets. With a UDP packet receiving means that decomposes a video file containing the above and receives a UDP packet transmitted by IP multicast; the UDP packet received by the UDP packet receiving means is reconstructed into the video file and reproduced in accordance with HTTP. It is configured to include a video file rebuilding means to be supplied to the means; the video file rebuilding means is complete if it does not receive at least one UDP packet out of a plurality of UDP packets corresponding to the video file. The moving image file is reconstructed so as to include only the TS packet.

Further, according to another aspect of the present invention, in order to achieve the above object, a computer program uses a user terminal that can connect to a communication network: a playback means for playing a moving image file containing a plurality of TS packets; UDP packet receiving means that decomposes the moving image file including the TS packet of the above and receives the UDP packet transmitted by multicast; the above moving image file is reconstructed from the UDP packet received by the above UDP packet receiving means and the above is compliant with HTTP. It is used to realize as a video file reconstructing means to be supplied to the playback means; the video file restructuring means does not receive at least one UDP packet among the plurality of UDP packets corresponding to the video file. The moving image file is reconstructed so as to include only a complete TS packet.

Further, according to another aspect of the present invention, in order to achieve the above-mentioned object, a computer program uses a video content processing device that can be connected to a communication network: a video file containing a plurality of TS packets is decomposed into IP. UDP packet receiving means for receiving the UDP packet transmitted by multicast; video file reconstructing means for reconstructing the UDP packet received by the UDP packet receiving means into the video file; the video reconstructed by the video file reconstructing means used files in order to achieve a transmission means for transmitting in conformity with HTTP to the user terminal via the communication network; the video file reconstruction means, among a plurality of UDP packets corresponding to the video file When at least one UDP packet is not received, the moving image file is reconstructed in a manner including only a complete TS packet.

In this configuration, the moving image file may be reconstructed in such a manner that the null packet of the TS packet is used in the portion corresponding to the UDP packet that has not been received and only the complete TS packet is included.

In this configuration, the first processing device may prevent any TS packet from being divided across two preceding and following UDP packets.

Further, in this configuration, the UDP packet transmitted from the first processing device includes a complete plurality of TS packets and a pad unit, and the second processing device includes a complete UDP packet included in the received UDP packet. The video content processing device according to claim 6, wherein the video file is reconstructed from a plurality of TS packets.

Further, in this configuration, the above-mentioned moving image file is HTTP Live Streaming (trademark of Apple Inc., USA), MPEG-DASH (ISO / IEC23009-1), HTTP Dynamic Streaming (trademark of Adobe Systems, Inc., USA), or Smart Streaming (Microsoft, USA). It may be transmitted by the HTTP streaming method (trademark of Microsoft Corporation, USA).

Furthermore, the technical features described here will be summarized. According to one aspect of the technical features described here, in order to achieve the above objectives, a video content distribution system: a video file containing a plurality of TS packets is decomposed into UDP packets and IP multicast is transmitted. And a second processing device that receives the UDP packet transmitted by IP multicast from the first processing device, reconstructs it into a moving image file, and transmits it to the user terminal in accordance with HTTP. However, when the second processing device does not receive at least one UDP packet among the plurality of UDP packets corresponding to the moving image file, the second processing device reconstructs the moving image file in a manner including only a complete TS packet. I am doing it.

The TS packet is a packet (transport stream packet) that constitutes a transport stream, and is typically an MPEG-2 TS packet defined in the MPEG2-TS (Moving Picture Experts Group 2 Transport Stream) standard. However, it is not limited to this.

The moving image file may include video data and audio data, and typically includes HTTP Live Streaming (Apple, USA), MPEG-DASH (ISO / IEC23009-1), HTTP Dynamic Streaming (Adapted Systems, USA), Smooth. It may be a moving image file (segment file) transmitted by an HTTP streaming method such as Streaming (Microsoft, USA).

In this configuration, the moving image file may be reconstructed in a manner in which only a complete TS packet is included by using a null packet (Null packet) of the TS packet in the portion corresponding to the UDP packet that has not been received.

A null packet (Null packet) indicates that the content of the packet is invalid, and all bits including the header are "1". Instead of a null packet, when playing a video, a packet indicating that the contents of the packet are not available, or if the playback side is configured to do so, such a particular packet. You may adopt it. Alternatively, the packet may have the transport error indicator flag set in the header of the MPEG-2 TS packet set to "1".

In addition, the first processing device may prevent any TS packet from being divided across two previous and subsequent UDP packets.

In this case, the UDP packet transmitted from the first processing device may include a complete plurality of TS packets and a pad unit, and the second processing device includes the complete UDP packet included in the received UDP packet. The above moving image file may be reconstructed from a plurality of TS packets.

In addition, the first processing device may receive a moving image file including a plurality of TS packets from the moving image server in accordance with HTTP, decompose the moving image file into UDP packets, and transmit it by multicast.

Further, according to another aspect of the technical features described here, in order to achieve the above-mentioned object, the video file containing a plurality of TS packets is decomposed and the UDP packet transmitted by IP multicast is received and described above. When the processing device that reconstructs the video file does not receive at least one UDP packet among the plurality of UDP packets corresponding to the video file, the processing device reconstructs the video file in a manner including only a complete TS packet. ..

Further, according to another aspect of the technical features described here, in order to achieve the above-mentioned object, a moving image file containing a plurality of TS packets is decomposed and an UDP packet transmitted by IP multicast is received and described above. When the user terminal that reconstructs the video file and plays it back does not receive at least one UDP packet among the plurality of UDP packets corresponding to the video file, the user terminal displays the video file in a manner including only a complete TS packet. Rebuild.

Also, according to another aspect of the technical features described herein, in order to achieve the above objectives, a computer program decomposes a video file containing multiple TS packets into a user terminal that can connect to a communication network. As a means for receiving the UDP packet transmitted by IP multicast; a means for reconstructing the video file from the received UDP packet; and a means for realizing and reconstructing the reconstructed video file. Reconstructs the video file in a manner including only a complete TS packet when it does not receive at least one UDP packet among the plurality of UDP packets corresponding to the video file.

Further, according to another aspect of the technical features described here, to the video content distribution system: a first method of decomposing a video file containing a plurality of TS packets received from an HTTP server into UDP packets and performing IP multicast transmission. A processing device and a second processing device that receives the UDP packet transmitted by IP multicast from the first processing device, reconstructs it into a moving image file, and transmits it to the user terminal in accordance with HTTP. There is.

Further, according to still another aspect of the technical features described herein, the video distribution system: a first processing device that decomposes a video file containing a plurality of TS packets into UDP packets and transmits them by IP multicast; A second processing device that receives the UDP packet transmitted by IP multicast from the first processing device, reconstructs it into a moving image file, and transmits it to the user terminal in accordance with HTTP is provided; the second processing device is described above. , When an HTTP request is received from a client device to send a video file containing the UDP packet when the UDP packet corresponding to the HTTP header is not received, an HTTP response indicating that the content length is zero is sent. I am trying to return it.

If the HTTP header part of the video file is not described correctly due to the loss of the UDP packet, there is a problem such as the playback freezes, but in this configuration, the playback of the video file is skipped and the subsequent video file Becomes playable as appropriate.

It should be noted that the present invention can be realized not only as an apparatus or a system but also as a method. In addition, it goes without saying that a part of such an invention can be configured as software. It is also natural that the software products used to execute such software on a computer are also included in the technical scope of the present invention.

The above-mentioned aspects and other aspects of the present invention are described in the claims and will be described in detail with reference to the following examples.

It is a figure explaining the environment in which the moving image content distribution system of the Example of this invention is executed. It is a figure explaining the outline of the operation example of the moving image content distribution system of FIG. It is a functional block diagram which shows the configuration example of the file packetizing apparatus 300 of FIG. It is a figure explaining an example of packetizing an HTTP file. It is a functional block diagram which shows the configuration example of the file reconstruction apparatus 400 of FIG. It is a figure explaining the operation example of the file reconstruction apparatus 400 of FIG. It is a figure explaining the operation example of the null packet insertion part 403 of FIG. FIG. 5 is a functional block diagram illustrating a configuration example of a mobile terminal forming the UDP non-compliant terminal device 600 of FIG. 1. It is a figure explaining the conventional HTTP compliant video distribution service. It is a figure explaining the operation example of the moving image distribution service of FIG. It is a figure explaining the HTTP message sample in the operation example of FIG. FIG. 6 is a functional block diagram showing a configuration example of the UDP-compatible terminal device 700 of FIG. It is a figure explaining the modification.

Hereinafter, examples of the present invention will be described.

FIG. 1 shows one embodiment of the video content distribution system of the present invention. In this figure, the video content distribution system 100 includes an HTTP distribution server 200, a file packetization device 300, a file reconstruction device 400, and content distribution. It is configured to include a network 500, a UDP non-compatible terminal device 600, a UDP compatible terminal device 700, and the like. As will be described later, the file reconstruction device 400 receives UDP packets from the file packetization device 300 by IP multicast, and typically a plurality of file reconstruction devices 400 are provided. Although only one UDP-compatible terminal device 600 and one UDP-compatible terminal device 700 are shown in the figure, a plurality of UDP-compatible terminal devices 600 are typically provided. The UDP non-compatible terminal device 600 can determine which file reconstruction device 400 to access based on the location information or the like.

The content distribution network 500 is a network that can efficiently realize multicast communication in addition to unicast communication. The content distribution network 500 preferably uses a dedicated network service in order to efficiently realize multicast communication, but is not limited to this.

The HTTP distribution server 200 distributes a file of video content, for example, television broadcast content, using HTTP. The HTTP distribution server 200 transmits a file to a client in accordance with HTTP to distribute video content. For example, it is an HLS (HTTP Live Streaming) system of Apple Inc. in the United States, and is a Web server conforming to HTTP. It is feasible with. In this example, although the HTTP distribution server 200 is connected to a communication network (not shown), it may be connected to the content distribution network 500. Further, the UDP non-compatible terminal device 600 or the like may use the video content distribution service by IP unicast from the HTTP distribution server 200, as in the conventional mode.

The HTTP-compliant video distribution service prepares a playlist file (for example, m3u8 file) and one or more video segment files (MPEG2-TS segment file) as shown in FIG. In the example of FIG. 9, a plurality (two) alternative playlists having different resolutions can be selected by using the master index file. There may be only one playlist. The alternative playlist (playlist) may be rewritten and repeatedly transmitted. Video segment files can be retrieved in sequence by referring to the playlist.

The HTTP distribution server 200 substitutes the master index file based on the playlist request (master index, request for alternative playlist) from the file packetizing device 300 which is the HTTP client, similarly to the conventional HTTP procedure shown in FIG. The playlist file (hereinafter, may be simply referred to as a playlist) is returned to the file packetizing device 300. After that, the HTTP distribution server 200 sequentially returns the moving image segment file in response to the segment request from the file packetizing device 300. The moving image segment file is configured to include, for example, an MPEG2-TS packet.

The file packetization device 300 receives the playlist file and the video segment file of the video distribution service as a client of the HTTP distribution server 200, divides these files into UDP packets, and performs IP multicast transmission in a predetermined multicast group. As shown in FIG. 3, the file packetization device 300 includes an HTTP client processing unit 301, a storage unit 302, a packetization unit 303, and a transmission unit 304.

The HTTP client processing unit 301 of the file packetization device 300 receives the playlist file and the moving image segment file from the HTTP distribution server 200. The column (a) of FIG. 4 shows an example of a moving image segment file received by the HTTP client processing unit 301. The storage unit 302 stores the received file. The packetizing unit 303 decomposes the file received by the HTTP client processing unit 301 into UDP packets. Column (b) of FIG. 4 is a decomposition of the moving image segment file of column (a) of FIG. 4 into UDP packets. The moving image segment file in column (a) of FIG. 4 is typically data having a length of several seconds to several tens of seconds, but is not limited to this. The UDP packet in column (b) of FIG. 4 includes a packetization header, an HTTP header, and a payload, and the packet header includes a header size (header_size), a stream identifier (stream_id), and a start flag as shown in column (c). (Start_flag), total size (total_size), payload size (payload_size), and payload offset (payload_offset) are included. The header size (header_size) indicates the total size of the packetized header and the HTTP header, the stream identifier (stream_id) is an identifier indicating which file the UDP packet belongs to, and the start flag (start_flag) is the head. The total size (headal_size) indicates the total number of bytes of the file, and the payload size (payload_size) indicates the number of bytes of the file part sent in the UDP packet, and the header offset. (Payload_offset) indicates the start position of the file portion sent in the UDP packet. In addition, a forward error correction code (FEC) or the like may be included. UDP packets typically have a fixed length of 1500 bytes or less in accordance with Ethernet, but are not limited to this. The TS packet of the moving image content is included in one UDP packet without being divided, and if there is a residue in the payload portion in each UDP packet, an embedded portion (pad) may be included.

Playlist files are also UDP packetized, except for considerations related to TS packets.

The transmission unit 304 specifies a multicast group and delivers UDP packets by IP multicast.

The file reconstruction device 400 appropriately joins the multicast group of the file packetization device 300, receives the UDP packet transmitted from the file packetization device 300 via the content distribution network 500 by IP multicast, and receives the playlist file. And rebuild the video segment file.

As shown in FIG. 5, the file reconstruction device 400 includes a UDP packet receiving unit 401, a UDP packet loss detecting unit 402, a null packet inserting unit 403, a packet connecting unit 404, a storage unit 405, and an HTTP service unit 406. The UDP packet receiving unit 401 participates in the IP multicast group and receives the UDP packet at the destination port. When the UDP packet constituting the video segment file is not received, the UDP packet loss detection unit 402 detects this based on, for example, payload-size, CRC check code, checksum, etc., and further detects the UDP packet at the loss position on payload-. Detecting from 0ffset, the null packet insertion unit 403 inserts a null packet of the TS packet instead (FIG. 6). A null packet is a packet in which all bits including the header take a value of "1". Since the playlist file is repeatedly transmitted, when UDP packet loss is detected, the file may be discarded and the playlist file to be sent next time may be received. Whether the UDP packet belongs to a video segment file or a playlist file can be determined based on the content type included in the HPPT header of the UDP packet. For example, as shown in FIG. 7A, "Conent-Type: video" In the case of "/ MP2", it is determined that it is a UDP packet of the moving image segment file, and a null packet of the TS packet is inserted in the loss portion. Alternatively, as shown in FIG. 7B, a field for the NP (NULL Packet) completion flag may be provided in the HTTP header, and the NP completion flag may be flagged in the HTTP header of the UDP packet of the moving image segment file.

When a serial number is assigned to a UDP packet, the UDP packet loss detection unit 402 may determine the loss of the UDP packet based on the continuity.

Examples of the HTTP message of the playlist response and the segment file response are as shown in FIGS. 11A and 11B, and "Conent-Type" is underlined.

The packet connection unit 404 reconstructs the file by ordering the UDP packets based on the layout-offset and the like, and inserting the null packet of the TS packet into the missing position of the moving image segment file. When rebuilding the file, unnecessary embeddings (pads) are removed. A predetermined file storage management unit stores and manages the reconstructed playlist file and the moving image segment file in the storage unit 405.

The HTTP service unit 406 returns the playlist file and the moving image segment file to the non-UDP compatible terminal device 600 in the same manner as that shown in FIG. 10 based on the request of HTTP from the non-UDP compatible terminal device 600. The UDP non-compatible terminal device 600 plays a moving image based on the received file. The UDP non-compatible terminal device 600 may be any kind as long as it can function as an HTTP terminal, and is typically a mobile terminal such as a smartphone, but is not limited to this, and any information terminal (informatization). (Including home appliances).

An example of a mobile terminal constituting the UDP non-compliant terminal device 600 is as shown in FIG. In FIG. 8, the mobile terminal 800 includes a processing system 810, a memory 820, an input / output subsystem 830, a high frequency circuit unit 840, and a voice circuit unit 850. Each of the components can be realized as appropriate by hardware, software, including signal processing integrated circuits, application-specific integrated circuits, or a combination thereof. The high frequency circuit unit 840 is used to transmit and receive information on a wireless link or network to other devices, and in order to perform this function, an antenna system, an RF transmitter / receiver, an amplifier, a tuner, an oscillator, Includes, but is not limited to, digital signal processors, codec chipsets, memories, and other well-known circuit configurations. The high frequency circuit unit 840 is used for mobile communication such as time division multiple access (TDMA) and code division multiple access (CDMA), wireless LAN (IEEE802.11b, IEEE802.11a, IEEE802.11g and / or IEEE802.11N), Bluetooth Communication protocols such as (IEEE802.5.1) and Wi-MAX (IEEE802.16) can be used, but are not limited thereto. The voice circuit unit 850 is connected to the voice speaker 851 and the microphone 852. The processing system 810 includes a processor 811, a memory controller 812, and a peripheral interface 813. The memory 820 stores code and data executed by the processor 811. The memory 820 may include any storage device such as RAM, ROM, FLASH, disk drive, magnetic tape and the like. Processor 811 executes various software components stored in memory 820. For example, software components include an operating system 821, a communication module 822, a contact / operation module 823, a graphics module 824, an application 825, a timer module 826, and a web browser module 827. The application 825 includes a browser, an address book, e-mail, encryption, a positioning function such as a Global Positioning System (GPS), and a video content playback function. In this embodiment, the mobile terminal operates as, for example, a UDP non-compliant terminal device 600, and at least a part of the HTTP client and the moving image reproduction unit is realized as an application 825. By installing the corresponding application in the memory 820, the mobile terminal 800 functions as an HTTP client and a moving image playback unit.

The UDP-compatible terminal device 700 has the function of the file reconstruction device 400, and receives the UDP packet delivered by IP multicast from the file packetization device 300 to reconstruct the playlist file and the video segment file. It plays a video. The UDP-compatible terminal device 700 can deal with UDP packet loss by a functional unit equivalent to the UDP packet loss detection unit 402 and the null packet insertion unit 403 of the file reconstruction device 400. The UDP compatible terminal device 700 can be realized by the mobile terminal shown in FIG. That is, as shown in FIG. 12, the UDP compatible device 700 includes the UDP packet receiving unit 701, the UDP packet loss detecting unit 702, the null packet inserting unit 703, the packet connecting unit 704, the storage unit 705, and the moving image reproduction unit 706. It is composed. Of these, the UDP packet reception unit 701, the UDP packet loss detection unit 702, the null packet insertion unit 703, the packet connection unit 704, and the storage unit 705 are the UDP packet reception unit 401 and the UDP packet loss detection unit of the file reconstruction device 400. It may be configured in the same manner as 402, null packet insertion unit 403, packet connection unit 404, and storage unit 405. The moving image reproduction unit 706 reproduces a moving image using the playlist file and the moving image segment file stored in the storage unit 705. In this case, the file may be configured to be accessed directly, or the file may be acquired in accordance with HTTP. The UDP packet receiving unit 701, the UDP packet loss detecting unit 702, the null packet inserting unit 703, the packet connecting unit 704, and the like shown in FIG. 12 may be realized by the application 825 of the mobile terminal 800.

FIG. 2 shows the general operation of the moving image content distribution system 100 of FIG. In FIG. 2, the moving image content is sent from the HTTP distribution server 200 to the file packetizing device 300 by IP unicast, further sent from the file packetizing device 300 to the file reconstructing device 400 by IP multicast, and further, non-UDP. It is sent to the corresponding terminal device 600 by IP unicast. Although not shown in FIG. 2, the UDP-compatible terminal device 700 is arranged at the position of the file reconstruction device 400, receives the moving image content from the file packetizing device 300 by IP multicast, and reproduces the moving image.

First, the file packetization device 300 sends a playlist file acquisition request to the HTTP distribution server 200 (X01). The HTTP distribution server 200 returns the playlist to the file packetizing device 300 in response to this (X02). After that, the file packetizing device 300 sequentially sends acquisition requests for the video segment files described in the playlist to the HTTP distribution server 200 (X03), and the HTTP distribution server 200 sequentially transmits the video segment files accordingly. Returned to the file packetizing device 300 (X04).

The file packetization device 300 decomposes the received playlist file and video segment file into UDP packets and distributes them to the file reconstruction device 400 by IP multicast (X05). The above processes X01 to X05 are repeatedly executed.

The file reconstruction device 400 reconstructs the playlist file and the moving image segment file from the received UDP packet and stores and holds them in the storage unit 405 (X06, X07). If there is a UDP packet loss when reconstructing the moving image segment file, replace it with a null packet. If there is a loss of UDP packets when reconstructing the playlist file, the playlist file under construction is discarded and the playlist file is reconstructed by the UDP packet of the playlist file delivered next time.

The file reconstruction device 400 functions as an HTTP server for the UDP non-compatible terminal device 600. That is, the UDP non-compatible terminal device 600 sends a playlist file acquisition request to the file reconstruction device 400 (X08). The file reconstruction device 400 returns the playlist to the UDP non-compatible terminal device 600 accordingly (X09). After that, the terminal device 600 that does not support UDP sequentially sends acquisition requests for the video segment files described in the playlist to the file reconstruction device 400 (X10), and the file reconstruction device 400 responds to the video segment files. Is sequentially returned to the terminal device 600 that does not support UDP (X11). The UDP non-compatible terminal device 600 sequentially generates moving images based on the moving image segment file.

This is the end of the description of the examples.

It should be noted that the present invention is determined based on the description of the scope of claims, and is not limited to the specific configuration, problems, and effects of the examples. The present invention is not limited to the above-described embodiment, and various modifications can be made without departing from the spirit of the present invention.

In the above example, although the null packet of the TS packet is inserted in the portion corresponding to the lost UDP packet, the null packet of the TS packet may not be inserted as long as it includes only the complete TS packet. For example, in the example of FIG. 6, the file may be reconstructed to include the complete HTTP header and complete TS packet contained in the successfully received UDP packet, excluding the null packet.

Further, when the loss UDP packet of the segment file corresponds to the HTTP header, the HTTP header is damaged. To deal with this, when there is an HTTP request from the client for the segment file, an HTTP response indicating that the content length (Conent-Length) is zero, for example, an HTTP response as shown in FIG. 13 is returned. It's okay. In FIG. 13, the description of the content length is indicated by an arrow. In this configuration, the reproduction of the moving image file is skipped, and the succeeding moving image file can be reproduced as appropriate, for example, at a timing based on the time stamp of the TS stream. The body is not included in this HTTP response.

Further, in the above example, the file packetizing device 300 acquires the files for HTTP-compliant video distribution from the HTTP distribution server 200 by HTTP, but these files are generated by the file packetizing device 300 itself. It may be prepared or obtained from any source.

100 Video content distribution system 200 HTTP distribution server 300 File packetization device 400 File reconstruction device 500 Content distribution network 600 UDP non-compatible terminal device 700 UDP compatible terminal device 800 Mobile terminal

Claims (5)

In a video content processing device that can be connected to a communication network
A UDP packet receiving means that decomposes a video file containing a plurality of TS packets and receives a UDP packet transmitted by IP multicast.
A video file reconstructing means for reconstructing a video file from a UDP packet received by the UDP packet receiving means, and
The video file reconstructing means has a transmission means for transmitting the reconstructed video file to a user terminal via the communication network in accordance with HTTP.
The moving image file reconstructing means has a UDP packet loss detecting means for detecting that a UDP packet is not received, and based on the detection output of the UDP packet loss detecting means, a plurality of UDP packets corresponding to the moving image file are used. When at least one of the UDP packets is not received, the moving image file is reconstructed in a manner in which a predetermined TS packet is replenished in place of the TS packet that should be included in the at least one UDP packet that is not received. A video content processing device characterized by. A video content processing device that can be connected to a communication network
UDP packet receiving means that decomposes a video file containing multiple TS packets and receives UDP packets transmitted by IP multicast.
A video file reconstructing means for reconstructing a video file from a UDP packet received by the UDP packet receiving means,
It is used to realize the video file reconstructed by the video file reconstructing means as a transmission means for transmitting the reconstructed video file to a user terminal via the communication network in accordance with HTTP.
The moving image file reconstructing means has a UDP packet loss detecting means for detecting that a UDP packet is not received, and based on the detection output of the UDP packet loss detecting means, a plurality of UDP packets corresponding to the moving image file are used. When at least one of the UDP packets is not received, the moving image file is reconstructed in a manner in which a predetermined TS packet is replenished in place of the TS packet that should be included in the at least one UDP packet that is not received. A computer program characterized by. The video content processing device according to claim 1, wherein the predetermined TS packet is a null packet. The moving image content processing device according to claim 1 or 3, wherein the predetermined TS packet has the same number of TS packets as the TS packet to be included in at least one UDP packet that is not received. The above video files are HTTP Live Streaming (trademark of Apple Inc. in the United States), MPEG-DASH (ISO / IEC23009-1), HTTP Dynamic Streaming (trademark of Adobe Systems in the United States), or Smart Streaming (trademark in the United States). The moving image content processing device according to any one of claims 1, 3 or 4 , which is transmitted by the HTTP streaming method of.

Images