Distribution server, receiving device, and program

Abstract

To allow streaming content in a low-delay segment format to be reproduced even by a receiving device that is not compatible with the low-delay segment format.SOLUTION: A distribution server 10 includes: a segment conversion unit 14 that converts a low-delay segment having chunks that do not include intra frames into a normal segment in which all chunks include intra frames; a low-delay segment format compatibility determination unit 18 that determines whether a receiving device that requests a segment is compatible with the low-delay segment format; and a segment transmitting unit 19 that transmits a low-delay segment when the receiving device is compatible with the low-delay segment format, and transmits a normal segment when the receiving device is not compatible with the low-delay segment format.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a distribution server, a receiving device, and a program.

Background Art

[0002] In recent streaming video distribution on the Internet, a method of streaming distribution using the HTTP protocol by a general-purpose web server has become mainstream. As an example of such a streaming distribution method (adaptive streaming) using the HTTP protocol, there is the international standard MPEG-DASH (ISO / IEC 23009-1).

[0003] In MPEG-DASH, an initialization segment, a media segment, and a manifest file describing their URLs and attributes of video content are prepared in a web server. The media segment is a segment obtained by dividing a stream encoded with one or more qualities (parameters such as screen size and bit rate) of video content into files of about several seconds to several tens of seconds each. The initialization segment includes metadata necessary for presenting segments, such as generation parameters related to encoding and encryption of each stream. The receiving device selects appropriate quality in a timely manner in consideration of the screen size of the receiving device and the state of the network bandwidth of the transmission path from the manifest file, receives segments one after another, and connects them to reproduce one video content (see, for example, Non-Patent Document 1).

[0004] As the media container format of the segment, the ISO-BMFF (ISO-Base Media File Format) is mainly used, but CMAF (Common Media Application Format) in which finer units called chunks are defined in the segment based on the format has been standardized (see, for example, Non-Patent Document 2).

[0005] Figure 6 shows a comparison between a conventional segment and a segment created using CMAF (CMAF segment). An mdat (Media Data Box) is a box that stores media data such as video and audio, while a moof (Movie Fragment Box) is a box that stores metadata for the mdat immediately following it. A set of moof and mdat is called a "chunk."

[0006] In conventional segments, when media data is video, it was common to construct one chunk within a segment using a GOP (Group of Pictures) unit, which is a group of intraframes followed by multiple interframes, or multiple GOP units. Figure 6 shows an example of a conventional segment where one chunk is constructed using 2 GOP units. On the other hand, in CMAF segments, one chunk (CMAF chunk) is constructed using units of 1 to several frames. In other words, a CMAF segment is composed of multiple CMAF chunks. The CMAF segment shown in Figure 6 is composed of CMAF chunks a and c, which include intraframes, and CMAF chunks b and d, which do not include intraframes.

[0007] In the conventional segment shown in Figure 6, the segment could not be delivered until the encoding of the last byte of the mdat was complete. However, by using the CMAF segment format, the segment can be delivered sequentially from the moment the encoding of the last byte of the mdat in the first CMAF chunk is completed, enabling lower-latency live delivery (see, for example, Non-Patent Document 3).

[0008] Furthermore, Patent Document 1 discloses a multiplex signal converter that converts an MMT (MPEG Media Transport) stream to which CMAF is applied as a media container format into an MMT stream to which CMAF is not applied, thereby enabling playback even by receivers that do not support MMT streams with CMAF applied. [Prior art documents] [Patent Documents]

[0009] [Patent Document 1] Japanese Patent Publication No. 2021-197584 [Non-patent literature]

[0010] [Non-Patent Document 1] Mitsuhiro Hirabayashi, "Next-Generation Video Streaming Technology 'MPEG-DASH': Technical Overview, Standardization, and Related Technology Trends," Journal of the Institute of Image Information and Television Engineers, Vol. 67, No. 2, 2013, pp. 109-115. [Non-Patent Document 2] “ISO / IEC 23000-19:2020 Information technology - Multimedia application format (MPEG-A) - Part 19: Common media application format(CMAF) for segmented media”, International Organization for Standardization, March 2020 [Non-Patent Document 3] Yuhki Hanada, April 5, 2018, “CMAF and the realization of low-latency live streaming using CMAF”, [online], [Retrieved June 20, 2022], Internet<URL:https: / / www.akamai.com / ja / blog / performance / cmaf-cmaf-low-lalatency-live> [Overview of the project] [Problems that the invention aims to solve]

[0011] Due to the growing demand for lower latency in video streaming, low-latency segment-based streaming distribution using CMAF and similar technologies is expected to become increasingly widespread. However, some devices that have long supported conventional segment-based streaming distribution may not be compatible with playback of low-latency segment-based streaming distribution that includes chunks without intraframes within the mdat file. While it is possible to perform conventional segment-based streaming distribution for such receiving devices that do not support low-latency segment-based distribution, this always requires encoding two types of streams. Furthermore, the technology disclosed in Patent Document 1 did not solve this problem.

[0012] In view of these circumstances, the object of the present invention is to provide a distribution server, a receiving device, and a program that enable streaming content in low-latency segment format to be played back even by receiving devices that do not support the low-latency segment format. [Means for solving the problem]

[0013] To solve the above problems, a distribution server according to one embodiment is a distribution server that distributes content composed of multiple segments to a receiving device segment by segment, and comprises: a segment conversion unit that converts a low-latency segment having chunks that do not contain intraframes into a normal segment in which all chunks contain intraframes; a low-latency segment format compatibility determination unit that determines whether or not a receiving device requesting a segment supports the low-latency segment format; and a segment transmission unit that transmits the low-latency segment if the receiving device supports the low-latency segment format, and transmits the normal segment if the receiving device does not support the low-latency segment format.

[0014] Furthermore, in a distribution server according to one embodiment, the segment conversion unit may determine whether the first frame of a received chunk is an intraframe based on the metadata of the chunk, and generate the normal segment by combining a subsequent chunk whose first frame is not an intraframe with a chunk whose first frame is an intraframe.

[0015] To solve the above problems, a receiving device according to one embodiment is a receiving device that receives content consisting of multiple segments from a distribution server segment by segment, and comprises: a segment conversion unit that converts a low-latency segment having chunks that do not contain intraframes into a normal segment in which all chunks contain intraframes; a low-latency segment format compatibility determination unit that determines whether the receiving device supports the low-latency segment format; and a decoding and playback unit that decodes and plays back the low-latency segment if the receiving device supports the low-latency segment format, and decodes and plays back the normal segment if the receiving device does not support the low-latency segment format.

[0016] Furthermore, in a receiving device according to one embodiment, the segment conversion unit may determine whether the first frame of a received chunk is an intra frame based on the metadata of the chunk, and generate the normal segment by combining a subsequent chunk whose first frame is not an intra frame with a chunk whose first frame is an intra frame.

[0017] Furthermore, in order to solve the above problems, the program according to one embodiment causes the computer to function as the distribution server.

[0018] Furthermore, in order to solve the above problems, the program according to one embodiment causes the computer to function as the receiving device. [Effects of the Invention]

[0019] According to the present invention, streaming content in a low-latency segment format can be played back even on a receiving device that does not support the low-latency segment format. Therefore, it is possible to efficiently achieve low-latency distribution while ensuring backward compatibility.

Brief Description of the Drawings

[0020] [Figure 1] It is a block diagram showing a configuration example of a distribution system according to the first embodiment. [Figure 2] It is a block diagram showing a configuration example of a distribution server according to the first embodiment. [Figure 3] It is a flowchart showing an example of processing by a segment conversion unit in a distribution server according to the first embodiment. [Figure 4] It is a block diagram showing a configuration example of a distribution system according to the second embodiment. [Figure 5] It is a block diagram showing a configuration example of a receiving device according to the second embodiment. [Figure 6] It is a diagram showing a comparison between a conventional segment and a segment using CMAF.

Modes for Carrying Out the Invention

[0021] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

[0022] In this specification, a "low-latency segment" is a segment that constitutes one chunk in units of one to several frames like the CMAF segment shown in FIG. 6, and has a chunk that does not include an intra-frame. Also, a "normal segment" is a segment that constitutes one chunk in units of one or more GOPs like the conventional segment shown in FIG. 6, and does not have a chunk that does not include an intra-frame.

[0023] <First Embodiment> (Content Distribution System) Figure 1 is a diagram showing an example configuration of a content distribution system according to the first embodiment of the present invention. The content distribution system 1 shown in Figure 1 comprises a distribution server 10, a live encoder 20, a first receiving device 30, and a second receiving device 40. For convenience of the drawing, only one first receiving device 30 and one second receiving device 40 are shown in Figure 1, but the content distribution system 1 comprises one or more first receiving devices 30 and two second receiving devices 40.

[0024] The distribution server 10 and the live encoder 20 are connected via a communication network NW1. The communication network NW1 may be a dedicated local network or the internet. The distribution server 10, the first receiving device 30, and the second receiving device 40 are connected via a communication network NW2, such as the internet.

[0025] The live encoder 20 encodes the input video in a low-latency segment format such as CMAF and sequentially outputs the encoded low-latency segments to the distribution server 10. Encoding is performed using existing video encoding methods such as H.264|MPEG-4 AVC (Advanced Video Coding) and H.265|MPEG-H HEVC (High Efficiency Video Coding). The live encoder 20 establishes a session with the distribution server 10, for example, on a segment-by-segment basis using the HTTP / 1.1 Chunked Transfer Encoding format, and transmits the low-latency segments in chunk units.

[0026] The distribution server 10 distributes content, which consists of multiple segments, to the first receiving device 30 and the second receiving device 40, which request each segment.

[0027] The first receiving device 30 is a receiving device that supports low-latency segment formats (segment-type streaming methods such as MPEG-DASH), and is a terminal that sequentially requests and obtains segments from the distribution server 10, and then decodes and plays them back. The first receiving device 30 establishes a session with the distribution server 10 on a segment-by-segment basis, for example using the HTTP / 1.1 Chunked Transfer Encoding format, and receives segments in chunk units.

[0028] The second receiver 40 has the same basic configuration as the first receiver 30, but it is a receiver that does not support the low-latency segment format. In other words, the second receiver 40 does not support decoding and playback of chunks that do not contain intraframes (for example, CMAF chunks).

[0029] (Distribution server) Next, the details of the distribution server 10 will be described. Figure 2 is a block diagram showing an example configuration of the distribution server 10. The distribution server 10 shown in Figure 2 includes a first communication interface 11, a segment receiving unit 12, a buffer for low-latency segments 13, a segment conversion unit 14, a buffer for normal segments 15, a second communication interface 16, a request receiving unit 17, a low-latency segment format compatibility determination unit 18, and a segment transmission unit 19. Note that if the communication network NW1 and the communication network NW2 are common, the first communication interface 11 and the second communication interface 16 may be common.

[0030] The segment receiving unit 12 sequentially receives low-latency segments from the live encoder 20 via the first communication interface 11 and outputs them to the low-latency segment buffer 13. The live encoder 20 establishes a session on a segment-by-segment basis, for example using the HTTP / 1.1 Chunked Transfer Encoding format, and receives low-latency segments in chunk units. The segment receiving unit 12 outputs the segments to the low-latency segment buffer 13 in chunk units without waiting for the segment reception to be completed. It also simultaneously outputs the segments to the segment conversion unit 14 in chunk units.

[0031] The segment conversion unit 14 converts the low-latency segment input from the segment receiving unit 12 into a normal segment in which all chunks include intraframes, and outputs the converted normal segment to the normal segment buffer 15.

[0032] The segment conversion unit 14 determines whether the first frame of a received chunk is an intraframe based on the metadata of the chunk, and combines the chunk whose first frame is an intraframe with the subsequent chunk whose first frame is not an intraframe to generate a normal segment. Details of the processing of the segment conversion unit 14 will be described later.

[0033] The request receiving unit 17 receives a segment request from the first receiving device 30 or the second receiving device 40 via the second communication interface 16, and notifies the low-latency segment format compatibility determination unit 18 of the URL of the segment included in the request and the terminal information of the first receiving device 30 or the second receiving device 40. As terminal information, for example, User-Agent information included in an HTTP request can be used, but the terminal information is not limited to this.

[0034] The low-latency segment format compatibility determination unit 18 determines whether the receiving device requesting the segment supports the low-latency segment format based on the terminal information input from the request receiving unit 17. Support for the low-latency segment format means that the device can decode and reproduce low-latency segments. The low-latency segment format compatibility determination unit 18 may also determine whether the device supports the low-latency segment format by creating a compatibility list (or incompatibility list) in advance according to the browser, OS, receiving device model, etc., and comparing it with the information included in the terminal information.

[0035] If the low-latency segment format compatibility determination unit 18 determines that the receiving device supports the low-latency segment format, it retrieves the low-latency segment corresponding to the segment URL input from the request receiving unit 17 from the low-latency segment buffer 13 and outputs it to the segment transmission unit 19. On the other hand, if the low-latency segment format compatibility determination unit 18 determines that the receiving device does not support the low-latency segment format, it retrieves the normal segment corresponding to the segment URL from the normal segment buffer 15 and outputs it to the segment transmission unit 19.

[0036] The segment transmission unit 19 outputs the low-latency segment input from the low-latency segment format compatibility determination unit 18 to the first receiving device 30 via the second communication interface 16, and outputs the normal segment input from the low-latency segment format compatibility determination unit 18 to the second receiving device 40 via the second communication interface 16. In other words, the segment transmission unit 19 transmits the low-latency segment if the receiving device supports the low-latency segment format, and transmits the normal segment if the receiving device does not support the low-latency segment format.

[0037] (Segment conversion method) Next, the method for converting one segment into a low-latency segment by the segment conversion unit 14 will be explained with reference to the flowchart shown in Figure 3. Here, the media container format of the low-latency segment will conform to ISO-BMFF or CMAF.

[0038] In step S001, the segment conversion unit 14 receives one chunk from the segment receiving unit 12.

[0039] In step S002, the segment conversion unit 14 analyzes the moof box of the received chunk and obtains metadata of the media data contained in the mdat box. The metadata includes, for example, the decode time of the first frame (baseMediaDecodeTime), the number of frames in the chunk (sample_count), the duration of each frame (sample_duration), the data size (sample_size), a flag (sample_flag), and a time offset value (sample_composition_time_offset).

[0040] In step S003, the segment conversion unit 14 determines whether the first frame of the received chunk is an intraframe based on the metadata. For example, if the sample_depends_on value in the sample_flag of the first frame in the metadata is 2, it is determined that the first frame is an intraframe. If the segment conversion unit 14 determines that the first frame is not an intraframe (step S003-NO), it proceeds to step S004; if it determines that the first frame is an intraframe (step S003-YES), it proceeds to step S006.

[0041] In step S004, the segment conversion unit 14 stores the received chunk metadata and mdat in a primary buffer within the segment conversion unit 14. The primary buffer may be located outside the segment conversion unit 14.

[0042] In step S005, the segment conversion unit 14 determines whether the chunk stored in the primary buffer is the last chunk in a low-latency segment. If the stored chunk is not the last chunk in a low-latency segment (step S005-NO), the process returns to step S001. If the stored chunk is the last chunk in a low-latency segment (step S005-YES), the process proceeds to step S007.

[0043] In step S006, the segment conversion unit 14 checks whether data is stored in the primary buffer. If no data is stored in the primary buffer (step S006-NO), the process proceeds to step S004. If data is stored in the primary buffer (step S006-YES), the process proceeds to step S007.

[0044] In step S007, the segment conversion unit 14 retrieves the data stored in the primary buffer. Then, it concatenates the media data contained in each chunk of the mdat in the order in which it was stored in the primary buffer, and generates a reconstructed mdat according to the ISO-BMFF specification. This makes it possible to generate an mdat that includes intraframes.

[0045] In step S008, the segment conversion unit 14 generates a moof corresponding to the mdat in accordance with the ISO-BMFF specification, based on the chunk-by-chunk metadata stored in the primary buffer.

[0046] In step S009, the segment conversion unit 14 concatenates the generated moof and mdat to create a chunk in normal segment format and stores it in a secondary buffer within the segment conversion unit 14. The secondary buffer may be located outside the segment conversion unit 14.

[0047] In step S010, the segment conversion unit 14 determines whether processing of all chunks within a single low-latency segment has been completed. If processing of all chunks within the low-latency segment has been completed (step S010-YES), the process proceeds to step S011. If there are chunks within the low-latency segment that have not been processed (S010-NO), the process returns to step S004, and the metadata and mdat of the received chunks are stored in the primary buffer.

[0048] In step S011, the segment conversion unit 14 retrieves the chunks in normal segment format stored in the secondary buffer. It then combines them in the order they were stored in the secondary buffer to generate a normal segment, outputs it to the normal segment buffer 15, and terminates the process.

[0049] In this manner, the distribution server 10 converts the low-latency segment output from the live encoder 20 into a normal segment and then transmits it to the second receiving device 40, which does not support the low-latency segment format. Therefore, decoding and playback are possible even at the second receiving device 40.

[0050] <Second Embodiment> Next, a second embodiment of the present invention will be described. Figure 4 is a diagram showing an example configuration of a content distribution system according to the second embodiment of the present invention. The content distribution system 2 shown in Figure 4 comprises a distribution server 10a, a live encoder 20, and a receiving device 50. In Figure 4, for the sake of convenience in the drawing, only one receiving device 50 is shown, but the content distribution system 2 comprises one or more receiving devices 50. Note that the distribution server 10a and the live encoder 20 may be a single device configured as an integrated unit.

[0051] In Figure 4, the live encoder 20 and the distribution server 10a are connected via the communication network NW1. The communication network NW1 may be a dedicated local network or the internet. The distribution server 10a and the receiving device 50 are connected via the communication network NW2, such as the internet.

[0052] The live encoder 20 is the same as in the first embodiment and sends low-latency segments in chunk units to the distribution server 10a.

[0053] The distribution server 10a buffers the low-latency segments received from the live encoder 20. Then, in response to segment requests from the receiving device 50, the distribution server 10a distributes the low-latency segments to the receiving device 50.

[0054] The receiving device 50 sequentially requests segments from the distribution server 10a according to a segment-type streaming method such as MPEG-DASH. Then, it receives content consisting of multiple segments from the distribution server 10a, segment by segment.

[0055] (Receiving device) Next, the details of the receiving device 50 will be described. Figure 5 is a block diagram showing an example configuration of the receiving device 50. The receiving device 50 shown in Figure 5 includes a communication I / F 51, a segment request unit 52, a segment receiving unit 53, a low-latency segment format compatibility determination unit 54, a buffer 55, a segment conversion unit 56, and a decoding / reproduction unit 57.

[0056] The segment request unit 52 establishes a session with the distribution server 10a on a segment-by-segment basis, for example using the HTTP / 1.1 Chunked Transfer Encoding format, and requests the distribution server 10a to send a request containing the URL of the desired segment.

[0057] The segment receiving unit 53 receives a low-latency segment corresponding to the URL of a desired segment from the distribution server 10a via the first communication I / F 11 and outputs it to the low-latency segment format compatibility determination unit 54.

[0058] The low-latency segment format compatibility determination unit 54 determines whether the decoding / reproduction unit 57 in the receiving device 50 supports the low-latency segment format. For example, the determination may be based on the browser, OS, terminal model, etc., of the receiving device 50. Alternatively, a low-latency segment may be input to the decoding / reproduction unit 57 via a buffer in advance, and the determination may be made based on the result of verifying whether or not an error occurs.

[0059] If the low-latency segment format compatibility determination unit 54 determines that the decoding / playback unit 57 supports the low-latency segment format, it outputs the low-latency segment input from the segment receiving unit 53 to the buffer 55. On the other hand, if the low-latency segment format compatibility determination unit 54 determines that the decoding / playback unit 57 does not support the low-latency segment format, it outputs the low-latency segment to the segment conversion unit 56.

[0060] The segment conversion unit 56, similar to the first embodiment (see Figure 3), converts a low-latency segment having chunks that do not contain intraframes into a normal segment in which all chunks contain intraframes, and outputs the normal segment to the buffer 55.

[0061] Buffer 55 outputs segments input from the low-latency segment format compatibility determination unit 54, or normal segments input from the segment conversion unit 56, to the decoding and playback unit 57.

[0062] The decoding and playback unit 57 decodes and plays back the low-latency segment or normal segment input from the buffer 55. That is, if the receiving device 50 supports the low-latency segment format, the decoding and playback unit 57 decodes and plays back the low-latency segment, and if the receiving device 50 does not support the low-latency segment format, it decodes and plays back the normal segment.

[0063] Through the above processing, the receiving device 50 can receive and reproduce low-latency segments from the distribution server 10a, regardless of whether the decoding and playback unit 57 supports the low-latency segment format.

[0064] Furthermore, the segment conversion unit 56 can be implemented as software such as JavaScript. Therefore, it does not need to be incorporated at the time of shipment of the receiving device 50, and can be obtained and executed from an external website or the like prior to receiving content from the distribution server 10a. Thus, it is possible to achieve efficient low-latency distribution while ensuring backward compatibility.

[0065] (program) To function as the distribution server 10 and receiving device 50 described above, it is also possible to use computers capable of executing program instructions. Here, the computer may be a general-purpose computer, a dedicated computer, a workstation, a PC (Personal Computer), an electronic notepad, etc. The program instructions may be program code, code segments, etc., for executing the required tasks.

[0066] A computer comprises a processor, a memory unit, an input unit, an output unit, and a communication interface. The processor may be a CPU (Central Processing Unit), MPU (Micro Processing Unit), GPU (Graphics Processing Unit), DSP (Digital Signal Processor), SoC (System on a Chip), etc., and may be composed of multiple processors of the same or different types. The processor controls each of the above components and performs various calculations by reading and executing programs from the memory unit. At least a part of these processes may be implemented in hardware.

[0067] The program may be recorded on a computer-readable recording medium. Using such a medium, the program can be installed on the computer. The recording medium on which the program is recorded may be a non-transitory recording medium. Non-transitory recording media are not particularly limited, but may include, for example, CD-ROMs, DVD-ROMs, or USB (Universal Serial Bus) memory. Alternatively, the program may be downloaded from an external device via a network.

[0068] For example, a program to function as a distribution server 10 includes the steps of: converting a low-latency segment to a normal segment; determining whether a receiving device requesting a segment supports the low-latency segment format; sending a low-latency segment if the receiving device supports the low-latency segment format, and sending a normal segment if the receiving device does not support the low-latency segment format; and having the computer execute these steps.

[0069] For example, a program to make a receiving device 50 function includes the steps of: converting low-latency segments to normal segments; determining whether the receiving device 50 supports the low-latency segment format; decoding and reproducing the low-latency segments if the receiving device 50 supports the low-latency segment format; and decoding and reproducing normal segments if the receiving device 50 does not support the low-latency segment format, and having the computer execute these steps.

[0070] Furthermore, the distribution server 10 and the receiving device 50 described above may each be composed of one or more semiconductor chips. These semiconductor chips may be equipped with a CPU that executes a program describing the processing content that realizes each function of the distribution server 10 and the receiving device 50.

[0071] Although the embodiments described above are representative examples, it will be apparent to those skilled in the art that many modifications and substitutions are possible within the spirit and scope of the present invention. Therefore, the present invention should not be interpreted as being limited by the embodiments described above, and various modifications or changes are possible without departing from the scope of the claims. For example, it is possible to integrate multiple component blocks shown in the configuration diagram of the embodiments, or to divide a single component block. [Explanation of Symbols]

[0072] 1,2 Content distribution system 10,10a Distribution Server 11. First Communication Interface 16. Second Communication Interface 12 Segment Receiver 13 Buffer for low-latency segments 14,56 Segment Conversion Unit 15 Buffer for normal segments 16 Communication I / F 17 Request Receiving Section 18,54 Low-latency segment format compatibility determination unit 19 Segment Transmission Unit 20 Live Encoders 30 First receiving device 40. Second receiving device 50 Receiving device 51 Communication I / F 52 Segment Request Section 53 Segment Receiver 55 buffers 57 Decoding and Regeneration Unit

Claims

1. A distribution server that distributes content consisting of multiple segments to receiving devices segment by segment, A segment conversion unit converts a low-latency segment having chunks that do not contain intraframes into a normal segment in which all chunks contain intraframes. A low-latency segment format compatibility determination unit determines whether the receiving device requesting the segment supports the low-latency segment format, A segment transmission unit that transmits the low-latency segment if the receiving device supports the low-latency segment format, and transmits the normal segment if the receiving device does not support the low-latency segment format, A distribution server equipped with the following features.

2. The distribution server according to claim 1, wherein the segment conversion unit determines whether the first frame of a received chunk is an intra frame based on the metadata of the chunk, and combines a subsequent chunk whose first frame is not an intra frame with a chunk whose first frame is an intra frame to generate the normal segment.

3. A receiving device that receives content consisting of multiple segments from a distribution server, segment by segment, A segment conversion unit converts a low-latency segment having chunks that do not contain intraframes into a normal segment in which all chunks contain intraframes. A low-latency segment format compatibility determination unit that determines whether the receiving device supports the low-latency segment format, A decoding and playback unit that decodes and plays back the low-latency segment if the receiving device supports the low-latency segment format, and decodes and plays back the normal segment if the receiving device does not support the low-latency segment format, A receiving device equipped with the following features.

4. The receiving device according to claim 3, wherein the segment conversion unit determines whether the first frame of a received chunk is an intra frame based on the metadata of the chunk, and combines a subsequent chunk whose first frame is not an intra frame with a chunk whose first frame is an intra frame to generate the normal segment.

5. A program for causing a computer to function as a distribution server according to claim 1 or 2.

6. A program for causing a computer to function as a receiving device according to claim 3 or 4.

Images