High-availability TV time-shift and playback live recording method based on HLS protocol

Abstract

A high-availability live broadcast recording method for television time-shifting and playback based on the HLS protocol. This method, based on the HLS protocol, offers excellent adaptability and compatibility with cross-platform devices. This method utilizes multi-source reception, multi-machine hot standby, and timestamp-based slicing technology to enable seamless master-slave switching during live broadcast slicing, with no perceptible effect on the terminal viewing experience. This method is suitable for broadcast-grade television time-shifting and playback live channel recording and has great potential for widespread application in live television.

Description

Technical Field

[0001] The present invention relates to the field of streaming media, and in particular to a live broadcast recording method for high-availability television time-shifting and playback based on the HLS protocol. Background Art

[0002] Driven by the development of HTTP Live Streaming (HLS) over the past few years, the HLS playback protocol has rapidly expanded the OTT-based live streaming industry, leveraging its cross-platform adaptability and compatibility, as well as the ease of implementing time-shifting and playback. In broadcast-grade live recording systems for the broadcasting and television industry, HLS live recording systems require a fault identification and automatic switching mechanism that supports multiple live sources and multi-machine hot standby. Furthermore, during live slice recording, the video slices output by the primary and backup servers must be seamlessly connected. Therefore, a high-availability live recording method based on the HLS protocol with time-shifting and playback is urgently needed. Summary of the Invention

[0003] In order to overcome the deficiencies of the above technologies, the present invention provides a method for enabling seamless switching between primary and backup modes in the live streaming slice recording process without the terminal being aware of the effect.

[0004] The technical solution adopted by the present invention to overcome the technical problems is:

[0005] A live broadcast recording method for high-availability television time-shifting and playback based on the HLS protocol, comprising the following steps: a) constructing a live broadcast recording system consisting of a live broadcast signal source, a backup broadcast / pre-broadcast signal source, a live broadcast recording server as a master node, a live broadcast recording server as a backup node 1, a live broadcast recording server as a backup node 2, a CDN system, an edge streaming server, and a user terminal, wherein the live broadcast recording server of the master node and the live broadcast recording server of the backup node 1 simultaneously receive the live broadcast signal source, and the live broadcast recording server of the backup node 2 receives the backup broadcast or pre-broadcast signal source;

[0006] b) Set the video slicing period for the live video service to T when performing HLS slicing, and set the current system timestamp to s;

[0007] c) The live broadcast recording server of the master node, the live broadcast recording server of the backup node 1, and the live broadcast recording server of the backup node 2 each receive the corresponding live broadcast stream and write it into a slice file, which is named f;

[0008] d) The live broadcast recording server of the master node, the live broadcast recording server of the standby node 1, and the live broadcast recording server of the standby node 2 generate an expected end timestamp S when receiving and writing files;

[0009] e) When the system timestamps of the live broadcast recording server of the master node, the live broadcast recording server of the backup node 1, and the live broadcast recording server of the backup node 2 reach the expected end timestamp S, the live broadcast recording service begins to parse whether the received live broadcast stream contains an IDR frame. If no IDR frame is found, step e) is repeated until an IDR frame is found and step f) is executed;

[0010] f) The live broadcast recording service writes and saves the data before the IDR frame to file f, and writes the data after the IDR frame to a new file named f';

[0011] g) The live recording service sends a notification to the file upload thread, and after preparing to upload the slice file, the live recording service returns to step d);

[0012] h) When the file upload thread receives the notification, the live recording server of the master node, the live recording server of the backup node 1, and the live recording server of the backup node 2 are all delayed;

[0013] i) The CDN system checks whether a file with the same name already exists. If so, the corresponding live recording server does not need to upload the file, and the upload process ends. If not, proceed to step j);

[0014] j) The live broadcast recording server of the master node, the live broadcast recording server of the standby node 1, and the live broadcast recording server of the standby node 2 start uploading the slice files to the CDN system.

[0015] Preferably, in step b), the video slicing period T is 2-10 seconds.

[0016] Furthermore, in step b), the live broadcast recording server of the master node, the live broadcast recording server of standby node 1, and the live broadcast recording server of standby node 2 all regularly access the NTP time synchronization service to make their system timestamps consistent with each other. Furthermore, in step c), f = [s / T].

[0017] Furthermore, in step d), the expected end timestamp S is calculated by the formula S=[s / T]*T.

[0018] Preferably, in step h), the delay time of the live broadcast recording server of the master node is 0, the delay time of the live broadcast recording server of the standby node 1 is 2×T, and the delay time of the live broadcast recording server of the standby node 1 is 3×T.

[0019] The present invention has the following beneficial effects: TV time-shifting and playback, based on the HLS protocol, has good adaptability and compatibility with cross-platform devices. The present invention's high-availability time-shifting and playback technology, through multi-source reception, multi-machine hot standby, and timestamp-based slicing technology, enables seamless master-slave switching during live slicing recording, with no perceptible effect on the terminal viewing experience. This technology is suitable for broadcast-grade TV time-shifting and playback live channel recording, and has great potential for widespread application in live TV applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a system structure diagram of the present invention;

[0021] Figure 2 Flow chart of the method of the present invention. DETAILED DESCRIPTION

[0022] The following is combined with Figure 1 , Attachment Figure 2 The present invention is further described.

[0023] A high-availability live broadcast recording method for television time-shifting and playback based on the HLS protocol includes the following steps: a) constructing a live broadcast recording system consisting of a live broadcast signal source, a backup / pre-broadcast signal source, a live broadcast recording server serving as a master node, a live broadcast recording server serving as backup node 1, a live broadcast recording server serving as backup node 2, a CDN system, an edge streaming server, and user terminals. The live broadcast recording server of the master node and the live broadcast recording server of backup node 1 simultaneously receive the live broadcast signal source, and the live broadcast recording server of backup node 2 receives the backup or pre-broadcast signal source. The workflow is consistent for each live broadcast recording server, differing only in the possible differences in the received live broadcast source and the upload delay.

[0024] b) Set the video slicing period of the live video service during HLS slicing to T and the current system timestamp to s.

[0025] c) The live broadcast recording server of the master node, the live broadcast recording server of the standby node 1, and the live broadcast recording server of the standby node 2 each receive the corresponding live broadcast stream and write it into a slice file, and the slice file is named f.

[0026] d) The live broadcast recording server of the master node, the live broadcast recording server of the standby node 1, and the live broadcast recording server of the standby node 2 generate an expected end timestamp S when receiving and writing files.

[0027] e) When the system timestamps of the live broadcast recording server of the master node, the live broadcast recording server of the backup node 1, and the live broadcast recording server of the backup node 2 reach the expected end timestamp S, the live broadcast recording service begins to parse whether the received live broadcast stream contains an IDR frame. If no IDR frame is found, step e) is repeated until an IDR frame is found and step f) is executed.

[0028] f) The live recording service writes and saves the data before the IDR frame to file f. The live recording service writes the data after the IDR frame to a new file named f'. The new file name f' can be named in the same way as in step c), i.e., recalculated using the formula f' = [s / T].

[0029] g) The live broadcast recording service sends a notification to the file upload thread, and after preparing to upload the slice file, the live broadcast recording service returns to execute step d).

[0030] h) When the file upload thread receives the notification, the live broadcast recording server of the master node, the live broadcast recording server of the backup node 1, and the live broadcast recording server of the backup node 2 are all delayed.

[0031] i) The CDN system checks whether a file with the same name already exists. If so, it means that the active / standby level of other node servers is higher and other servers have completed file upload. In this case, the corresponding live recording server does not need to upload and the upload process ends. If not, it means that the active / standby level of this server is higher or other servers with higher active / standby levels have failed to upload the file, and then step j) is executed.

[0032] j) The live broadcast recording server of the master node, the live broadcast recording server of the standby node 1, and the live broadcast recording server of the standby node 2 start uploading the slice files to the CDN system.

[0033] TV time-shifting and playback are based on the HLS protocol, offering excellent adaptability and compatibility across devices across multiple platforms. This high-availability time-shifting and playback technology utilizes multi-source reception, multi-machine hot standby, and timestamp-based slicing technology to enable seamless master-slave switching during live slicing recording, with no perceptible end-user experience. This technology is suitable for broadcast-grade TV time-shifting and playback live channel recording and has significant potential for widespread adoption in live TV applications.

[0034] In a specific embodiment of the present invention, in step b), the live recording server of the master node, the live recording server of the backup node 1, and the live recording server of the backup node 2 all regularly access the NTP time synchronization service to make their system timestamps consistent with each other. The three servers ensure that the video slice file names recorded at the same time are exactly the same. The three upload the recorded video slice files to the CDN system with different delays. For files with the same name, the CDN system will only retain the earliest uploaded file. At this point, regardless of whether any live source signal is interrupted or any recording server fails, it can be ensured that the CDN system can successfully receive uninterrupted live slice files. Especially during the switching process between the master node and the backup node 1, the video slice files generated by the two can be seamlessly connected.

[0035] Furthermore, in step c), the file name f is obtained by dividing the system timestamp by the slicing period and rounding up, that is:

[0036] Furthermore, in step d), the formula Calculate the expected end timestamp S.

[0037] Furthermore, in step h), the delay time of the live broadcast recording server of the master node is 0, the delay time of the live broadcast recording server of the standby node 1 is 2×T, and the delay time of the live broadcast recording server of the standby node 1 is 3×T.

[0038] As attached Figure 1 The structure shown in the diagram above requires a live source and a backup source for each live TV channel. If costs are limited, multiple live channels can share a single backup source, which can be a general information announcement video.

[0039] For a set of live TV channels, three live recording servers are required. Each server can record a different number of channels, depending on its processing power and receive / transmit bandwidth capabilities. The main factors affecting the number of live channels a server can handle are: server CPU processing power, server network card bandwidth limit, and live source video bitrate.

[0040] When performing HLS slicing, the live streaming recording service first needs to determine the video slicing period, which determines the average video duration of the sliced ​​files. The slicing period should not be too long, as this can prevent timely switching in the event of a failure and hinder video buffering for terminal playback. The slicing period should also be short enough to ensure sufficient IDR frames in the live stream. The specific slicing period should be determined based on the video encoding of the live source.

[0041] The video slicing period, T, can range from 2 seconds to 10 seconds, but integers such as 2 seconds, 4 seconds, 5 seconds, and 10 seconds are commonly used in actual project applications. This is primarily because these numbers are easily divisible and easy to calculate for troubleshooting. Generally speaking, a 5-second period is appropriate for live broadcast files. In step b), the video slicing period, T, is set to 5 seconds. This embodiment will be described using a 5-second slicing period.

[0042] The three live recording servers each receive the corresponding live stream and write it into a slice file. The name of the slice file is obtained by dividing the system timestamp by the slice period and rounding up. Assume that the current system time is: January 1, 2023 00:01, its system timestamp is 1672502401 (in this embodiment, it is assumed that the system time zone is Beijing time in the Eastern Time Zone 8, and in order to simplify the calculation process, the timestamp is in seconds. In actual applications, it is recommended to use milliseconds as the unit to obtain higher accuracy). At this time, the slice file name algorithm is That is, the file name is 334500481.

[0043] When the live recording service receives and writes files, it will also generate an expected end timestamp. The algorithm is as follows: That is to say, the server's current timestamp is 1672502401, and there are 4 seconds left from the expected end timestamp 1672502405.

[0044] When the server's system timestamp reaches the expected end timestamp 1672502405, the live streaming recording service will begin parsing the received live stream to see if it contains an IDR frame. If no IDR frame is found, this step will be repeated until an IDR frame is found.

[0045] When an IDR frame is found, the live recording service will write and save the data before the IDR frame to file 334500481, and write the data after the IDR frame to a new file. The naming method of the new file will be reused. Assuming that the system timestamp has changed to 1672502406, the formula can be applied to obtain That is, the new file name is 334500482, which is exactly 1 more than the value of the previous file name.

[0046] After the live recording service completes writing and saving a file, it will send a notification to the file upload thread to prepare to upload the sliced ​​file. At the same time, the live recording service will continue to repeat the live stream reception and file writing process. When the file upload thread receives the notification, the live recording service will wait for a period of time based on its own server role before starting to upload the file. Among them, the upload delay of the master node is 0, which means that the sliced ​​file will be uploaded to the CDN immediately after completion. The upload delay of the backup node 1 is twice the slice duration, which means that the file will be uploaded after a delay of 10 seconds. The upload delay of the backup node 2 is 3 times the slice duration, which means that the file will be uploaded after a delay of 15 seconds.

[0047] In this embodiment, when the terminal device needs to watch TV time-shift or replay, it will request the HLS playback address from the CDN edge streaming server. The streaming server will dynamically generate a specific m3u8 file based on the time-shift or replay parameters requested by the terminal device. Taking TV time-shift as an example:

[0048] To play the time-shifted video from 600 seconds ago on CCTV1 channel, the terminal device requests the following URL: http: / / server / channel / cctv1 / shift / 1800 / video.m3u8

[0049] The following is an example of the m3u8 content returned by the streaming server:

[0050] #EXTM3U

[0051] #EXT-X-VERSION:3

[0052] #EXT-X-MEDIA-SEQUENCE:334500481

[0053] #EXT-X-ALLOW-CACHE:YES

[0054] #EXT-X-TARGETDURATION:5

[0055] #EXTINF:5.0,

[0056] channel / cctv1 / 334500481.ts

[0057] #EXTINF:5.0,

[0058] channel / cctv1 / 334500482.ts

[0059] #EXTINF:5.0,

[0060] channel / cctv1 / 334500483.ts ...

[0062] The ts file name in the m3u8 file mentioned above can be generated by reverse engineering the system timestamp of the streaming server and the time shift offset requested by the terminal. Similarly, the m3u8 file for TV playback uses a similar process and will not be repeated here.

[0063] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art will be able to modify the technical solutions described in the aforementioned embodiments or substitute equivalent features for some of the technical features. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A method for high-availability TV time-shift and playback live recording based on the HLS protocol, characterized in that: The steps include: a) Construct a live broadcast recording system consisting of a live broadcast signal source, a backup broadcast / primary broadcast signal source, a live broadcast recording server as a master node, a live broadcast recording server as a backup node 1, a live broadcast recording server as a backup node 2, a CDN system, an edge streaming server, and a user terminal. The live broadcast recording server of the master node and the live broadcast recording server of the backup node 1 simultaneously receive the live broadcast signal source, and the live broadcast recording server of the backup node 2 receives the backup broadcast or primary broadcast signal source; b) Set the video slicing period for the live video service to T when performing HLS slicing, and set the current system timestamp to s; c) The live broadcast recording server of the master node, the live broadcast recording server of the backup node 1, and the live broadcast recording server of the backup node 2 each receive the corresponding live broadcast stream and write it into a slice file, which is named f; d) The live broadcast recording server of the master node, the live broadcast recording server of standby node 1, and the live broadcast recording server of standby node 2 generate an expected end timestamp S when receiving and writing the slice file named f; e) When the system timestamps of the live broadcast recording server of the master node, the live broadcast recording server of the backup node 1, and the live broadcast recording server of the backup node 2 reach the expected end timestamp S, the live broadcast recording service begins to parse whether the received live broadcast stream contains an IDR frame. If no IDR frame is found, step e) is repeated until an IDR frame is found and step f) is executed; f) The live broadcast recording service writes and saves the data before the IDR frame to file f, and writes the data after the IDR frame to a new file named f'; g) The live recording service sends a notification to the file upload thread, and after preparing to upload the slice file, the live recording service returns to step d); h) When the file upload thread receives the notification, the live recording server of the master node, the live recording server of the backup node 1, and the live recording server of the backup node 2 are all delayed; i) The CDN system checks whether a file with the same name already exists. If so, the corresponding live recording server does not need to upload the file, and the upload process ends. If not, proceed to step j); j) The live broadcast recording server of the master node, the live broadcast recording server of the standby node 1, and the live broadcast recording server of the standby node 2 start uploading the slice file named f to the CDN system.

2. The method for high-availability TV time-shift and playback live broadcast recording based on the HLS protocol according to claim 1, characterized in that: In step b), the video slicing period T is set to a value of 2-10 seconds.

3. The method for high-availability TV time-shift and playback live broadcast recording based on the HLS protocol according to claim 1, characterized in that: In step b), the live broadcast recording server of the master node, the live broadcast recording server of the standby node 1, and the live broadcast recording server of the standby node 2 all regularly access the NTP time synchronization service to make their system timestamps consistent with each other.

4. The method for high-availability TV time-shift and playback live broadcast recording based on the HLS protocol according to claim 1, characterized in that: In step c), the name f of the slice file is calculated by the formula f=⌈s / T⌉, where T is the video slicing period set for the live video service when performing HLS slicing, and s is the current system timestamp.

5. The method for high-availability TV time-shift and playback live broadcast recording based on the HLS protocol according to claim 1, characterized in that: In step d), the expected end timestamp S is calculated using the formula S=⌈s / T⌉*T.

6. The method for high-availability TV time-shift and playback live broadcast recording based on the HLS protocol according to claim 1, characterized in that: In step h), the delay time of the live broadcast recording server of the master node is 0, the delay time of the live broadcast recording server of the standby node 1 is 2×T, and the delay time of the live broadcast recording server of the standby node 1 is 3×T.

Images