Distribution system, distribution control program, edge server, and program distribution method

Abstract

To provide a distribution system, distribution control program, edge server, and program distribution method that in a linear distribution service in an HAS system, can quickly cope with a sudden change in a program schedule without increasing loads on a network and a server and cope with program provision personalized for each viewer.SOLUTION: When a program schedule is changed, program organization information on a CDN edge is updated to quickly distribute an after-change program, in which the schedule change is reflected, to a player without updating a manifest file held by the player.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a distribution system, a distribution control program, an edge server, and a program distribution method for linear video distribution over the Internet, and in particular to elemental technologies that constitute a function for quickly responding to sudden changes in program schedules in an HAS-based linear distribution service. [Background technology]

[0002] In recent years, linear distribution services such as FAST (Free Ad-Supported Streaming TV) offered by broadcasters and OTT (Over-The-Top) service providers have become widespread. Linear distribution is a service in which multiple programs are scheduled in advance on a single channel, similar to television broadcasting, and the programs are switched and distributed according to the scheduled program start and end times. OTT service providers are businesses that provide content and services such as messages, audio, and video over the Internet without relying on telecommunications carriers or Internet service providers (ISPs).

[0003] For video distribution over the Internet, HAS (HTTP Adaptive Streaming) standards using ABR (Adaptive Bit-Rate) technology, such as MPEG-DASH (MPEG-Dynamic Adaptive Streaming over HTTP) and HLS (HTTP Live Streaming) (see Non-Patent Document 1), are often used, and in recent years, CMAF (Common Media Application Format), an HAS format that standardizes the media container format of MPEG-DASH and HLS, has begun to be used. The HAS format is a streaming distribution method using the HTTP protocol from a general-purpose web server.

[0004] With these methods, video is encoded at multiple qualities with different bit rates and resolutions, and then fragmented (divided) into segment files (fragmented mp4, etc.) of a few seconds each. The viewing player (hereafter simply referred to as "player") running on the viewing device determines the next video quality segment to acquire based on the screen size of the viewing device and fluctuating Internet congestion conditions, and plays back the segment of the quality appropriate to the network conditions while requesting it via HTTP, allowing for stable viewing even during times of Internet congestion. These methods make it possible to provide large-scale services from multiple edge servers by using a CDN (Content Delivery Network).

[0005] In both MPEG-DASH and HLS, streaming data is broadly composed of two types of files: the segment files mentioned above, and a manifest file. Information about the quality of the segments and the request destination (URL) for each segment is written in the manifest file, and the player first obtains this manifest file before requesting the segments. MPEG-DASH uses a file called an MPD (Media Presentation Description), which is written in XML, as the manifest file, while HLS uses a file called an M3U8. Hereinafter, in this specification, an example will be described in which MPEG-DASH is adopted as the standard for the HAS system.

[0006] Furthermore, MPD allows multiple different contents to be scheduled chronologically in a multi-period format, and the player can switch the content segments to be played according to the start time of each period (program start time), allowing viewers to watch programs according to the schedule. Also, by replacing the programs of some periods with programs that match the viewer's attributes, personalized viewing is possible, allowing each viewer to watch a different program during that time slot (often used for personalized advertising). This type of linear distribution and personalization can also be implemented with HLS using a similar mechanism.

[0007] In this case, if you want to change the pre-organized program schedule due to breaking news, etc., the distributor must first change the program information for the period in the manifest file, and then all players must obtain and update the changed manifest file. Therefore, viewers will not be able to watch the changed video until the player's manifest file has been updated.

[0008] Furthermore, manifest files are generally obtained by players via HTTP requests. Therefore, in order to quickly reflect schedule changes, players must constantly update the manifest file at high frequencies, but frequent HTTP requests increase the load on the network and server (in the case of MPD, updates are generally infrequent, about once every 10 seconds). Furthermore, a dynamic ad insertion technology known as Dynamic Ad Insertion, which utilizes technology such as that described in Non-Patent Document 2, also requires updating the manifest file in the same way as above.

[0009] In recent years, CDNs have become capable of using edge processing, where an HTTP request from a player triggers a program to be executed on the CDN's edge server, which then returns an HTTP response after processing. Furthermore, because CDN edge servers (hereafter referred to as "CDN edges") are distributed over a large scale, it is possible to perform individual processing for each viewer in a scalable manner.

[0010] This paper describes a linear delivery method that uses edge processing on a CDN to enable rapid schedule changes, and also describes how to achieve personalization with this linear delivery method. [Prior art documents] [Non-patent literature]

[0011] [Non-Patent Document 1] ISO / IEC 23009-1: Information Technology - Dynamic Adaptive Streaming over HTTP (DASH) - Part 1: Media Presentation Description and Segment Formats

[0012] [Non-patent document 2] ANSI / SCTE-35: Digital Program Insertion Cueing Message for Cable Summary of the Invention [Problem to be solved by the invention]

[0013] In a linear distribution system where program schedules are written in a manifest file and players switch programs based on the manifest file, any sudden changes to the program schedule require all players to update the manifest file, which takes time for the changes to be reflected, making it impossible to quickly provide viewers with emergency news, including evacuation information. Furthermore, frequently updating manifest files by all players to quickly change the schedule increases the load on networks and servers.

[0014] The present invention has been made in consideration of the above-mentioned problems, and its purpose is to provide a distribution system, distribution method, and distribution control program that can quickly respond to sudden changes in program schedules in an HAS-type linear distribution service without increasing the load on the network or server, and that can also provide programs personalized for each viewer. [Means for solving the problem]

[0015] When a player requests a segment from the CDN edge, the distribution control program running on the CDN edge distributes the scheduled segment of the corresponding program to the player based on the program information, the segment number and video quality written in the request path, thereby realizing linear video distribution using the HAS method.

[0016] The distribution system of the present invention, which is compatible with an HAS-type linear video distribution service, includes an origin server that stores videos of live programs transmitted from a live encoder and videos of recorded programs that have been uploaded in advance, and a program scheduling system in which program distribution schedule information is registered, and an edge server on a CDN that stores copies of the videos stored by the origin server and program scheduling information, and distributes multiple segments into which the videos are divided to the player based on the program scheduling information in response to requests from the player, wherein requests from the player are made based on manifest files corresponding to the segments, and when there is a change in the distribution schedule information, the program scheduling system updates the program scheduling information on the edge server.

[0017] In addition, the edge server in the distribution system retrieves the segments from the origin server or its own cache in accordance with the program scheduling information on the edge server, rewrites the timestamps so that the timestamps are continuous, and distributes the segments to the player as they are received, starting with the segments for which the timestamp rewrite operation has been completed.

[0018] Furthermore, the distribution control program according to the present invention implements the functions of the program scheduling system and edge server on a cloud platform as software.

[0019] The edge server in the distribution system also includes a request information management unit that acquires request information from the player, manages the segment type and quality number, the segment number of the segment, and attribute information of the viewer watching the program on the player, and notifies the segment determination and acquisition unit; a program scheduling information management unit that acquires the program scheduling information and notifies the segment determination and acquisition unit; a personalized information management unit that acquires personalized information of the viewer and notifies the segment determination and acquisition unit; a segment determination and acquisition unit that determines a segment to be distributed to the player based on the request information, the program scheduling information, and the personalized information, acquires the segment from the origin server or its own cache, and passes it to the segment operation unit; a segment operation unit that rewrites the timestamp of the segment based on the segment number requested by the player and passes it to the segment distribution unit; and a segment distribution unit that distributes the segment passed from the segment operation unit to the player.

[0020] Furthermore, the program distribution method executed by an edge server on a CDN compatible with the HAS-type linear video distribution service of the present invention includes the steps of receiving a segment request (HTTP request) from a player, searching for the corresponding program based on program scheduling information and segment number upon receiving the segment request, determining whether personalization of the corresponding program is permitted, and if personalization of the corresponding program is permitted, determining the program based on attribute information of the viewer watching the program on the player and personalized program information, and if personalization of the corresponding program is not permitted, determining which segment to acquire from an origin server based on the segment number requested by the player and the start time of the corresponding program, determining whether the segment to be acquired is already in its own cache, and if the segment to be acquired is not in its own cache, acquiring the segment from the origin server, rewriting the timestamp of the acquired segment, and delivering the acquired segment to the player as an HTTP response.

[0021] When a distribution schedule changes, the program scheduling system updates the program scheduling information on the CDN edge, allowing the revised program to be quickly distributed to the player without updating the player's manifest file. Furthermore, because there is no need to update the manifest file for schedule changes, the load on the network and servers caused by updating the manifest file is reduced. Furthermore, during program time slots where program personalization is permitted, the player notifies the CDN edge of viewer attribute information when requesting a segment. The CDN edge then determines and distributes programs based on the viewer attributes, enabling the provision of personalized programs for each viewer in the same way as before. This allows for delivery quality control using ABR, as is also done in conventional linear distribution, and scalable distribution of personalized programs, while also enabling rapid schedule changes.

[0022] The present invention also relates to a delivery control program that can run on a CDN edge and a method for writing program scheduling information. However, the delivery control program does not necessarily have to run on a CDN edge, and can also run on a virtual machine on a general cloud or on an on-premise (operated on-premise) server. In this specification, we will explain the case where the delivery control program runs on a CDN edge as an example. [Effects of the Invention]

[0023] Linear video distribution over the Internet allows for quick changes to program schedules, and makes it possible to quickly provide viewers with breaking news and other information via linear distribution, just like on television. In addition, since there is no longer a need to frequently update the MPD as in the past, it is possible to reduce the load on the network and server. [Brief explanation of the drawings]

[0024] [Figure 1] 1 is a diagram showing the overall configuration of a distribution system according to an embodiment of the present invention; [Figure 2] FIG. 2 illustrates an example of a functional configuration of an edge server on which a delivery control program is executed. [Figure 3] FIG. 10 illustrates an example of a control flow of a distribution control program. DETAILED DESCRIPTION OF THE INVENTION

[0025] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. (Outline of the distribution system) Figure 1 shows the overall configuration of a distribution system according to one embodiment of the present invention. The distribution system comprises a live encoder (DASH encoder) 1, an origin server 2, a program scheduling system 3, an edge server (CDN edge) 4 on a CDN where the distribution control program of the present invention is executed, and a viewing terminal 5 on which a viewing player operates. Each device is capable of IP communication with each other via the Internet or the like.

[0026] (Live Encoder 1) The live encoder 1 is installed at each of the various locations (live program production locations) where live programs (news, sports broadcasts, etc.) are produced, such as broadcast stations and stadiums. The live encoder 1 is a device capable of transmitting live streams (ISOBMFF (ISO Base Media File Format) format) such as MPEG-DASH in real time, and the live stream from the live encoder 1 is transmitted to the origin server 2 via the Internet or a dedicated IP line. To reduce latency, the live encoder 1 may encode the data in CMAF chunk format, in which each segment is divided into multiple moofs, using chunked encoding based on CMAF-ULL (CMAF-Ultra-Low-Latency) technology, and transmit the encoded data using HTTP 1.1 chunked transfer encoding.

[0027] The live encoder 1 at each location has its own encoding schedule information preset in advance. The encoding schedule information includes Destination_url, which indicates the IP address of the origin server 2 where the stream generated by the live encoder 1 is stored, Start_time, which indicates the start time of encoding the live program, and End_time, which indicates the end time of encoding. The live encoder 1 starts the encoding process and sends the live stream to the origin server 2 at the start time and stops them at the end time. The stream generated by the live encoder 1 is sent to the storage destination on the origin server 2 specified by Destination_url.

[0028] (Origin Server 2) The origin server 2 is a server based on web technologies such as HTTP and MPEG-DASH. The origin server 2 stores MPEG-DASH format segments of various qualities transmitted in real time from the live encoder 1 at the live program production base, as well as pre-encoded and uploaded static content (segments of recorded programs, commercials, etc.). The origin server 2 is a general HTTP server that returns a response with the requested content in response to an HTTP request. The origin server 2 may support HTTP 1.1 chunked transfer encoding to reduce latency. Furthermore, since the distribution system of this embodiment performs CDN edge processing, the edge server 4 that receives a request from the player makes a request to the origin server 2, and the edge server 4 returns a response to the player. If the edge server 4 has a replica (cache) of the content of the origin server 2, the edge server 4 returns an HTTP response from its own cache without making a request to the origin server 2.

[0029] Although each program is encoded and packaged individually, the encoding method and parameters are common. This allows the initializing segments, which contain meta-information for decoding required when starting playback or switching quality, to be common for each program. In addition, the MPD and initializing segments are prepared in advance and are static (fixed), so when the player 5 requests them from the CDN edge 4, they can be delivered to the player 5 without any special processing, just as in the past.

[0030] In this embodiment, segment names (other than initialized segments) stored in the origin server 2 will be described using $RepresentationID$-$Number$.m4s as an example. RepresentationID=0 represents an audio segment file, RepresentationID=1 represents a high-quality video segment, and RepresentationID=2 represents a low-quality video segment file. The player 5 acquires video of either high or low quality depending on the network conditions determined by ABR control. However, the relationship between RepresentationID and video quality or audio is arbitrary, and video quality may be configured with more qualities than just high and low.

[0031] In this embodiment, Number represents the segment number, and an example will be described in which the first segment number of a program is 1, the segment length is 1 second, and the video frame rate is 60 fps. In this case, a segment with Number (segment number) = 1 contains video or audio from 0 to 1 second of the program, and one video segment contains 60 frames of video data.

[0032] These program segments are stored in separate directories on origin server 2. For example, if the host domain name of origin server 2 where segments of program 2 are stored is originA and the directory name is program2, when edge server 4 makes an HTTP request to origin server 2 (http: / / originA / program2 / 1-3.m4s), a segment containing high-quality video from 2 to 3 seconds of program 2 will be returned.

[0033] (Programming System 3) The program scheduling system 3 stores program schedule information. The program schedule information is registered, for example, by a program production base (such as a broadcast station) and can be changed when a program schedule is added or updated, or when a manual operation is performed to interrupt a news event such as breaking news when an incident or disaster occurs. Furthermore, the program scheduling system 3 stores and updates the program scheduling information in a data store on the CDN edge 4 based on the program schedule information.

[0034] (Edge server on CDN (CDN edge) 4) The edge server 4 on the CDN executes a pre-registered distribution control program in response to a request from the player, and returns an HTTP response to the player. Programming information is stored in a data store on the CDN edge 4, and the program scheduling information can be updated instantly by the program scheduling system 3 at any time.

[0035] An example of programming information written in JSON (JavaScript Object Notation) format is shown below. Programming information has the following properties: program_id, which is the program ID, start, which is the program start time, end, which is the program end time, origin, which is the host domain name of origin server 2 where the program segments are stored, path, which is the directory name, personalization, which indicates whether personalization is allowed, and personaliz_id, which is the ID of the personalization information. The program start and end times are expressed as the number of seconds elapsed from the availabilityStartTime described in the MPD, which is described later. For example, when availabilityStartTime="1970-01-01T00:00:00Z" is specified, if "start":"30" and "end":"60", this indicates that the program will start at 00:00:30 on January 1, 1970, and end at 00:01:00 on January 1, 1970. "personalization:true" indicates that personalization is permitted for the program.

[0036] (Example of program schedule information (JSON format)) {[ …., { program_id : "Program 2","start": t, "end": t+30, "origin":"originA","path": " / program2 / ", “personalization”:false}, { program_id : "Program 3","start": t+30, "end": t+60 ,"originA": "national", "path": " / program3 / ", “personalization”:true, personaliz_id :1} ]}

[0037] (Viewing terminal (player) 5) The viewing terminal (player) 5 obtains the MPD from the origin server 2 via the CDN edge 4 and over the Internet, downloads the relevant segments, and obtains and views program content including recorded programs, live programs, and emergency programs. The viewing terminal player 5 can be a player that complies with the commonly used MPEG-DASH standard, such as dash.js, an open-source media player. The MPD used in this embodiment is an MPD for live streaming that is written in a single period and has type=dynamic. An example of an MPD used in this embodiment is shown below.

[0038] (MPD example) <mpd type="dynamic" xmlns="urn:mpeg:dash:schema:mpd:2011" availabilitystarttime="1970-01-01T00:00:00.000Z" maxsegmentduration="PT1.0S" minbuffertime="PT1.0S" minimumupdateperiod="PT500S" ····> <period id="0" start="PT0.0S"> <adaptationset bitstreamswitching="true" contenttype="video" framerate="60" id="0" maxheight="2160" maxwidth="3840" par="16:9"> <SegmentTemplate availabilityTimeComplete="false" availabilityTimeOffset="0.983" duration="1000000" initialization="init-stream$RepresentationID$.m4s" media="$RepresentationID$-$Number%10d$.m4s" startNumber="1" ..."> <representation bandwidth="12000000" codecs="hev1.2.4.L153.0" height="2160" id="1" mimetype="video / mp4" width="3840">< / representation> ...

[0039] Player 5 requests segments from the endpoint of CDN edge 4 listed in the BaseURL according to the above MPD. For example, at 00:01:00 on January 1, 1970, Player 5 requests http: / / egde-endpoint / ch1 / $RepresentationID$-1.m4s from CDN edge 4. RepresentationID contains the video quality number determined by Player 5's ABR control, or 0, which represents audio. Player 5 performs ABR control and makes requests while simply incrementing the segment number, just like when watching a single live stream.

[0040] Furthermore, viewer attribute information may be notified to the CDN edge 4 for personalization, which will be described later. For example, this may be done as an HTTP query when a segment request is made, or by using the HTTP POST or PUT method to describe the attribute information in the request body. Alternatively, if there is a database in which viewer attribute information is stored, token information for accessing the database may be notified to the CDN edge 4 using the above method. In this case, the CDN edge 4 can use the token to obtain viewer attribute information from the database.

[0041] Next, the delivery control program of the CDN edge 4 when the player 5 requests http: / / egde-endopoint / ch1 / $RepresentationID$-“k”.m4s from the CDN edge 4 according to the above procedure will be described. Here, k is a variable of the segment number requested by the player 5. When there is a request to egde-endopoin / ch1 / , the CDN edge 4 is assumed to execute the delivery control program assigned to this endpoint. When there is a request from the player 5, the CDN edge 4 first refers to the program scheduling information in the data store. Next, it searches for a program that satisfies Start < k ≦ end from the program scheduling information for k.

[0042] The processing when the "personalization" of the corresponding program is false will be shown. According to the "origin" and "path" of the program, a segment request is made to the origin server 2 where the corresponding program is stored. The quality of the segment requested at this time uses the $RepresentationID$ requested from the player 5, and the segment number is the number obtained by subtracting Start from k. Taking the above program scheduling information as an example, when t < k ≦ t + 30 for k, the CDN edge 4 executes an HTTP request as http: / / originA / program2 / $RepresentationID$-“k - t”.m4s to obtain the segment at the specified time of program 2. If the specified segment has already been cached in the CDN edge 4, it is obtained from the cache.

[0043] Next, an operation to rewrite the timestamp of the obtained segment is performed. The timestamp to be rewritten is described in the tfdt of the moof box in the case of a segment in the ISOBMFF format (fmp4). Regarding the rewrite operation, when the time scale of the segment timestamp is timescale, it is rewritten as timescale×(k - 1).

[0044] Also, if a segment is in CMAF chunk format divided into multiple moofs, the tfdt of the first moof box is timescale × (k-1), and for subsequent tfdts, a timescale corresponding to the number of frames is added, based on timescale × (k-1). For example, if a video CMAF chunk is composed of one frame at a time, the i-th tfdt will be timescale × (k-1) + timescale / {(60 × (i-1))} (*for 60fps video). The same timestamp rewriting operation is performed for audio.

[0045] The CDN edge 4 returns an HTTP response to the player by chunked transfer encoding from the data for which the rewriting operation has been completed, so that the present invention can support low-latency distribution using CMAF-ULL.

[0046] The edge processing described above enables the player 5 to play programs according to the program schedule. Furthermore, because the timestamps are rewritten according to the program distribution time, even when programs switch, the timestamps remain continuous, allowing the player to decode the programs as if they were a single continuous live stream, enabling seamless program switching.

[0047] Next, the processing when "personalization" of the corresponding program is "true" is shown. In this case, the CDN edge 4 first checks the viewer attribute information, and if there is no viewer attribute information, it performs the processing described above when "personalization" of the corresponding program is false. If there is viewer attribute information, it references personaliz_id and references the corresponding personalized information. Note that this specification does not go into details about the personalization information, but it is assumed that it contains information regarding matching with viewer attribute information regarding personalized programs, as well as information about the origin and path of each personalized program.

[0048] At this time, the CDN edge 4 uses an appropriate recommendation algorithm based on the viewer attribute information to determine one personalized program and saves it in the data store. Next, it obtains the segments of that personalized program in the same way as when "personalization" for the program in question is false, performs timestamp manipulation, and delivers them to the player 5, thereby achieving personalized delivery. If a segment is requested from the player 5 for the same program slot from the second time onwards, the determined personalized program saved in the data store is delivered, eliminating the need for calculation processing for recommendations from the second time onwards.

[0049] When a schedule change occurs, the program scheduling system 3 updates the program scheduling information of the CDN edge 4, and the CDN edge 4 distributes program segments based on the changed program scheduling information, thereby quickly reflecting the schedule change. In this case, unlike conventional systems, the player 5 does not need to update the MPD in response to the schedule change.

[0050] Event information (such as information about an earthquake) can be included in the program scheduling information, and by multiplexing this information into a segment as an emsg box along with the timestamp rewrite operation, the event information can be notified to the player 5. For example, based on this event information, the player 5 can overlay an emergency earthquake alert caption onto the video. Furthermore, when there are multiple linear distribution channels based on the above method, a player 5 viewing one channel can seamlessly switch channels by requesting a switching segment from the endpoint of another channel, thereby enabling seamless zapping.

[0051] (Example of functional configuration of edge server 4 on CDN) FIG. 2 shows an example of the functional configuration of an edge server (CDN edge) 4 on a CDN in an embodiment of the present invention in which a delivery control program is executed. As shown in Figure 2, the CDN edge 4 is configured to include, as functional blocks, a request information management unit 6, a program scheduling information management unit 7, a personalized information management unit 8, a segment determination / acquisition unit 9, a segment operation unit 10, and a segment distribution unit 11. Note that the above-mentioned parts are regarded as multiple functional blocks provided by the CDN edge 4, and each function is realized by executing each step of the delivery control program on the CDN edge 4, and do not exist as hardware.

[0052] The request information management unit 6 acquires HTTP request information from the player 5, manages the segment type, quality number, segment number, and viewer attribute information, and notifies the segment determination and acquisition unit 9 of the information. The program scheduling information management unit 7 acquires the program scheduling information from the data store and notifies the segment determination and acquisition unit 9 of the information.

[0053] The personalized information management unit 8 acquires personalized information from the data store and notifies the segment determination and acquisition unit 9 of the information. The segment determination and acquisition unit 9 determines the segment to be delivered to the player 5 based on the request information, program information, and personalization information, acquires the segment from the origin server 2 or its own cache, and passes it to the segment operation unit 10. At that time, the segment number requested by the player 5 is also notified.

[0054] Based on the segment number requested by the player 5, the segment operation unit 10 rewrites the segment timestamp [timescale×(k−1)+timescale / {(60×(i−1))}] and passes it to the segment distribution unit 11. The segment distribution unit 11 distributes the segments to the player 5 as an HTTP response.

[0055] (CDN Edge 4 processing flow) FIG. 3 shows the processing flow of the CDN edge 4 including the ABR control of the player 5 in this embodiment. First, a segment request (HTTP request) is received from the player 5 (step S1). When a segment request is received, the corresponding program is searched for based on the program scheduling information and segment number (step S2).

[0056] Next, it is determined from "personalization" whether personalization of the program is permitted (step S3). If it is permitted (determined YES), the process proceeds to step S4, which will be described later, and if it is not permitted (determined NO), the process proceeds to step S5, which will be described later. If personalization of the program is permitted, the program is determined based on the viewer attribute information and personalized program information, and the process proceeds to step S5 (described later) (step S4).

[0057] If personalization of the program is not permitted, it is determined which segment to obtain from the origin server 2 based on the segment number requested by the player 5 and the start time (start) of the program (step S5). Next, it is determined whether the segment to be acquired is already present in its own cache (step S6). If it is present in its own cache (determination result is YES), it proceeds to step S8, which will be described later, and if it is not present (determination result is NO), it proceeds to step S7, which will be described later.

[0058] The specified segment is acquired from the origin server 2, and the process proceeds to step S8 (step S7), which will be described later. The timestamp of the acquired segment is rewritten (step S8). The segment is delivered to the player 5 as an HTTP response (step S9). This completes the process.

[0059] This invention is expected to be used as a new distribution method in Internet linear distribution services such as FAST (Free Ad-Supported Streaming TV). Furthermore, the personalization method and program schedule change method of this method can also be used for personalized advertisement insertion and dynamic advertisement insertion, respectively.

[0060] The above describes one embodiment of the present invention, but the distribution system, distribution control program, edge server, and distribution method of the present invention are not limited to the above-described embodiment, and include modifications, improvements, etc. within the scope that can achieve the purpose.

[0061] For example, the above-described embodiment has been described using an example in which MPEG-DASH is used as the standard for the HAS system, but this is not limiting. For example, HLS can also be used as the standard for the HAS system. In the case of HLS, the manifest file is M3U8 instead of MPD.

[0062] In addition, the above-described embodiment also relates to a method for describing a distribution control program and program scheduling information that can run on a CDN edge, but the distribution control program does not necessarily have to run on a CDN edge, and can also be run on a virtual machine on a general cloud or on an on-premise (operated within the company's premises) server.

[0063] As described above, the functions of the program scheduling system and edge server that constitute the distribution system of the present invention can be implemented as software on a cloud platform. Here, "implementing as software" means implementing by loading and executing a program on a computer, and a distribution control program for implementing these functions on a cloud platform is also included in the scope of the present invention.

[0064] The distribution control program can be stored and supplied to a computer using various types of non-transitory computer-readable media. Non-transitory computer-readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic storage media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical storage media (e.g., magneto-optical disks), CD-ROMs (Read Only Memory), CD-Rs, CD-R / Ws, and semiconductor memories (e.g., mask ROMs, PROMs (Programmable ROMs), EPROMs (Erasable PROMs), flash ROMs, and RAMs). The program may also be supplied to a computer by various types of transitory computer-readable media. Examples of transitory computer-readable media include electrical signals, optical signals, and electromagnetic waves. The transitory computer-readable media can supply the program to a computer via wired communication paths such as electrical wires and optical fibers, or via wireless communication paths. [Explanation of symbols]

[0065] 1 Live Encoder (DASH Encoder) 2 Origin Server 3 Programming system (programming server) 4. Edge servers on CDN (CDN edge) 5. Viewing device (viewing player) 6. Request Information Management Department 7 Programming Information Management Department 8 Personalized Information Management Department 9 Segment determination and acquisition section 10 Segment operation section 11 Segment Distribution Department< / adaptationset> < / period> < / mpd>

Claims

1. A distribution system compatible with HAS linear video distribution services, a program scheduling system including an origin server that stores videos of live programs transmitted from a live encoder and videos of recorded programs that have been uploaded in advance, and in which distribution schedule information of programs is registered; an edge server on a CDN that stores a copy of the video stored in the origin server and program scheduling information, and that delivers a plurality of segments obtained by dividing the video to the player based on the program scheduling information in response to a request from the player; the request from the player is made based on a manifest file corresponding to the segment; When the distribution schedule information is changed, the program scheduling system updates the program scheduling information on the edge server.

2. The edge server According to the program information on the edge server, the segment is acquired from the origin server or its own cache, and the timestamp is rewritten so that the timestamps are continuous; 2. The distribution system according to claim 1, wherein the segments for which the timestamp rewriting operation has been completed are distributed to the player as needed.

3. A distribution control program for implementing the functions of the program scheduling system and edge server according to claim 1 or 2 on a cloud platform in software.

4. An edge server in the distribution system according to claim 1 or 2, a request information management unit that acquires request information from the player, manages the segment type and quality number, the segment number of the segment, and attribute information of the viewer who watches the program on the player, and notifies the segment determination and acquisition unit of the information; a program scheduling information management unit that acquires the program scheduling information and notifies the segment determination / acquisition unit; a personalized information management unit that acquires personalized information of the viewer and notifies the segment determination and acquisition unit; a segment determination / acquisition unit that determines a segment to be delivered to the player based on the request information, the program organization information, and the personalized information, acquires the segment from the origin server or its own cache, and passes the segment to a segment operation unit; a segment operation unit that rewrites the timestamp of the segment based on the segment number requested by the player and passes the rewritten timestamp to a segment distribution unit; a segment distribution unit that distributes the segment passed from the segment operation unit to the player; An edge server comprising:

5. A program distribution method executed by an edge server on a CDN compatible with a HAS-type linear video distribution service, comprising: receiving a segment request (HTTP request) from a player; Upon receiving the segment request, searching for the corresponding program based on program scheduling information and segment number; determining whether personalization of the program is permitted; If personalization of the program is permitted, determining the program based on attribute information of a viewer who will watch the program on the player and personalized program information; if personalization of the program is not permitted, determining which segment to retrieve from the origin server based on the segment number requested by the player and the start time of the program; determining whether the segment to be retrieved is already in its cache; If the segment to be acquired does not exist in the cache, acquiring the segment from the origin server; a step of rewriting the timestamp of the acquired segment; delivering the acquired segment to the player as an HTTP response; A program distribution method including:

Images