Live streaming switching and pushing method and device

Abstract

This application discloses a live stream forwarding processing method and apparatus. During the process of pushing live stream data from the broadcaster's end to an edge computing node, push performance data corresponding to the live stream data is collected. During the process of forwarding live stream data from the edge computing node to a forwarding device, forwarding performance data corresponding to the live stream data is collected. Based on the push performance data and forwarding performance data, the jitter of the live stream data during the forwarding process is analyzed to obtain a forwarding jitter analysis result. If the forwarding jitter analysis result indicates that there is continuous jitter during the forwarding process, a forwarding jitter recovery task is executed. This application analyzes jitter by collecting push performance data and forwarding performance data. This method is compatible with various scenarios and can automatically execute forwarding jitter recovery tasks based on continuous jitter to promptly resolve forwarding anomalies, saving manpower while improving forwarding response speed and live stream quality.

Description

Technical Field

[0001] This application relates to the field of Internet technology, specifically to a live stream forwarding and pushing processing method and apparatus. Background Technology

[0002] In a live streaming system, the broadcaster pushes the stream to edge computing nodes, which then forward it to a Content Delivery Network (CDN) or other self-built service machines (such as transcoding clusters). Figure 1 This diagram illustrates the live stream transmission process in the prior art, such as... Figure 1 As shown, the broadcaster pushes the live stream data to the edge computing nodes, which then forward the live stream data to the CDN and transcoding cluster via the public network. Furthermore, the transcoding cluster can provide the broadcaster's room with more viewing resolution options through transcoding.

[0003] In existing technologies, streaming commonly uses the Routing Table Maintenance Protocol (RTMP). The RTMP protocol is based on the Transmission Control Protocol (TCP). Therefore, if jitter occurs at any point during the transmission over the public network, the jitter will continue and cannot be automatically recovered. In this case, simply disconnecting the transmission and re-establishing the transmission link can restore normal operation.

[0004] However, the entire live streaming platform usually needs to maintain many live stream data at the same time. It cannot constantly compare whether the live stream data pushed by the broadcaster and the live stream data forwarded by the edge computing node are stable. It will only be restored when the user reports poor forwarding quality and actively disconnects the transmission. Therefore, how to accurately detect forwarding quality problems and re-establish the transmission link in a timely manner to improve the quality of live stream transmission services is an urgent technical problem to be solved. Summary of the Invention

[0005] In view of the above problems, this application proposes a live stream forwarding processing method, apparatus, computing device and computer storage medium to solve the following problems: the existing technology cannot accurately detect forwarding quality problems and it is difficult to restore forwarding in a timely manner, resulting in low quality of live stream transmission services.

[0006] According to one aspect of the embodiments of this application, a live stream forwarding and pushing processing method is provided, including:

[0007] During the process of pushing live stream data from the broadcaster's end to the edge computing node, the corresponding push performance data of the live stream data is collected.

[0008] During the process of pushing live stream data from edge computing nodes to push devices, the corresponding push performance data of the live stream data is collected.

[0009] Based on push performance data and retweet performance data, the jitter of live stream data during the retweet process is analyzed to obtain retweet jitter analysis results;

[0010] If the retweet jitter analysis results indicate that there is continuous jitter during the retweet process, then the retweet jitter recovery task will be executed.

[0011] Furthermore, the collection of push performance data corresponding to the live stream data further includes: setting sampling points according to a preset sampling period, and collecting push performance data corresponding to the live stream data from the broadcaster's end according to the sampling points.

[0012] The data collected for the relay performance of the live stream data further includes: collecting the relay performance data of the live stream data from edge computing nodes or relay devices according to the sampling points.

[0013] Furthermore, based on push performance data and retweet performance data, the jitter of the live stream data during the retweet process is analyzed, and the retweet jitter analysis results further include:

[0014] The push performance data is divided into a first set corresponding to multiple preset time periods, and the forwarding performance data is divided into a second set corresponding to multiple preset time periods.

[0015] For each preset time period among multiple preset time periods, the first set corresponding to the preset time period is analyzed to obtain the push jitter parameters corresponding to the preset time period, and the second set corresponding to the preset time period is analyzed to obtain the retweet jitter parameters corresponding to the preset time period.

[0016] The push jitter parameters and the corresponding retweet jitter parameters corresponding to the first preset number of consecutive preset time periods are analyzed to obtain the retweet jitter analysis results.

[0017] Furthermore, dividing push performance data into a first set corresponding to multiple preset time periods, and dividing retweet performance data into a second set corresponding to multiple preset time periods, further includes:

[0018] The push performance data collected within each preset time period will form a first set corresponding to that preset time period, and the retweet performance data collected within each preset time period will form a second set corresponding to that preset time period.

[0019] Furthermore, for each of the multiple preset time periods, the push jitter parameters corresponding to the first set corresponding to the preset time period are obtained by analyzing the first set corresponding to the preset time period, and the retweet jitter parameters corresponding to the preset time period are obtained by analyzing the second set corresponding to the preset time period, further including:

[0020] Calculate the difference between any two adjacent push performance data in the first set corresponding to the preset time period to obtain multiple first difference values, and use the sum of multiple first difference values ​​as the push jitter parameter corresponding to the preset time period;

[0021] Calculate the difference between any two adjacent push performance data in the second set corresponding to the preset time period to obtain multiple second difference values, and use the sum of multiple second difference values ​​as the push jitter parameter corresponding to the preset time period.

[0022] Furthermore, the push jitter parameters and corresponding retweet jitter parameters corresponding to a first preset number of consecutive preset time periods are analyzed to obtain retweet jitter analysis results, which further include:

[0023] For each preset time period in a consecutive first preset number of preset time periods, the push jitter parameter and the retweet jitter parameter corresponding to the preset time period are compared with a preset jitter threshold respectively to obtain the comparison result corresponding to the preset time period, and the periodic jitter analysis result corresponding to the preset time period is determined based on the comparison result corresponding to the preset time period.

[0024] Analyze the period jitter analysis results corresponding to the first preset number of consecutive preset time periods to determine the push jitter analysis results.

[0025] Furthermore, based on the comparison results corresponding to the preset time period, the periodic jitter analysis results corresponding to the preset time period further include:

[0026] If the comparison result corresponding to the preset time period is that the push jitter parameter is less than the preset jitter threshold and the forwarding jitter parameter is greater than or equal to the preset jitter threshold, then the periodic jitter analysis result corresponding to the preset time period is determined to be that there is jitter in the forwarding process;

[0027] If the comparison result corresponding to the preset time period is that the push jitter parameter is greater than or equal to the preset jitter threshold and the retweet jitter parameter is greater than or equal to the preset jitter threshold, then it is determined that the periodic jitter analysis result corresponding to the preset time period is that there is jitter in both the push process and the retweet process of the broadcaster.

[0028] Furthermore, based on the comparison results corresponding to the preset time period, the periodic jitter analysis results corresponding to the preset time period further include:

[0029] If the comparison result corresponding to the preset time period is that the push jitter parameter is less than the preset jitter threshold and the forward jitter parameter is less than the preset jitter threshold, then the periodic jitter analysis result corresponding to the preset time period is determined according to the first set corresponding to the preset time period and the second set corresponding to the preset time period.

[0030] Furthermore, based on the first set corresponding to the preset time period and the second set corresponding to the preset time period, the periodic jitter analysis results corresponding to the preset time period further include:

[0031] Based on the first set and the second set corresponding to the preset time period, calculate the percentage of retweet jitter corresponding to the preset time period;

[0032] If the percentage of retweet jitter corresponding to the preset time period is less than the preset percentage threshold, then the periodic jitter analysis result corresponding to the preset time period is determined to be that there is no jitter in the retweet process;

[0033] If the percentage of retweet jitter corresponding to the preset time period is greater than or equal to the preset percentage threshold, then the periodic jitter analysis result corresponding to the preset time period is determined to indicate that there is jitter in the retweet process.

[0034] Furthermore, calculating the retweet jitter percentage corresponding to the preset time period based on the first set and the second set corresponding to the preset time period further includes:

[0035] For each push performance data in the first set corresponding to the preset time period, the corresponding retweet performance data is obtained from the second set corresponding to the preset time period. The corresponding retweet jitter amplitude is calculated using the push performance data and the corresponding retweet performance data, and the retweet jitter amplitude is added to the third set corresponding to the preset time period.

[0036] Based on the third set corresponding to the preset time period, calculate the percentage of retweet jitter corresponding to the preset time period.

[0037] Furthermore, based on the third set corresponding to the preset time period, calculating the retweet jitter percentage corresponding to the preset time period further includes:

[0038] If the amplitude of any push jitter in the third set corresponding to the preset time period is greater than the preset amplitude threshold, then the amplitude of the push jitter is regarded as an abnormal amplitude.

[0039] The percentage of abnormal amplitudes in the third set corresponding to the preset time period is taken as the percentage of retweet jitter corresponding to the preset time period.

[0040] Furthermore, by analyzing the periodic jitter analysis results corresponding to a first preset number of consecutive preset time periods, the push jitter analysis results are determined to further include:

[0041] The target number of periodic jitter analysis results corresponding to the first preset number of consecutive preset time periods includes the periodic jitter analysis results where jitter exists in the push process;

[0042] If the target number is greater than the second preset number, the retweet jitter analysis result is determined to be that there is continuous jitter in the retweet process; if the target number is less than or equal to the second preset number, the retweet jitter analysis result is determined to be that there is no continuous jitter in the retweet process.

[0043] Furthermore, performing the push jitter recovery task further includes:

[0044] Disconnect the corresponding push link and re-establish the push link connection.

[0045] Furthermore, the push performance data includes: the number of frames per second and / or the transmission bitrate of live stream data pushed from the broadcaster to the edge computing node;

[0046] The push performance data includes: the number of frames per second and / or the transmission bitrate of the live stream data pushed by the edge computing node to the push device; or, the push performance data includes: the number of frames per second and / or the transmission bitrate of the live stream data received by the push device.

[0047] According to another aspect of the embodiments of this application, a live stream switching and pushing processing apparatus is provided, including:

[0048] The data acquisition module is used to collect push performance data corresponding to the live stream data during the process of pushing live stream data from the broadcaster to the edge computing node; and to collect push performance data corresponding to the live stream data during the process of pushing live stream data from the edge computing node to the push device.

[0049] The analysis module is used to analyze the jitter of live stream data during the retweet process based on push performance data and retweet performance data, and obtain retweet jitter analysis results.

[0050] The processing module is used to execute a retweet jitter recovery task if the retweet jitter analysis result indicates that there is continuous jitter in the retweet process.

[0051] According to another aspect of the embodiments of this application, a computing device is provided, including: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus;

[0052] The memory is used to store at least one executable instruction, which causes the processor to perform the operation corresponding to one of the live stream push processing methods described above.

[0053] According to another aspect of the embodiments of this application, a computer storage medium is provided, wherein the storage medium stores at least one executable instruction, the executable instruction causing a processor to perform an operation corresponding to the above-described live stream push processing method.

[0054] According to the embodiments of this application, a live stream forwarding processing method and apparatus are provided. During the process of pushing live stream data from the broadcaster's end to the edge computing node, push performance data corresponding to the live stream data is collected. During the process of forwarding live stream data from the edge computing node to the forwarding device, forwarding performance data corresponding to the live stream data is collected. Based on the push performance data and the forwarding performance data, the jitter of the live stream data during the forwarding process is analyzed to obtain a forwarding jitter analysis result. If the forwarding jitter analysis result indicates that there is continuous jitter during the forwarding process, a forwarding jitter recovery task is executed. This method collects push performance data and relay performance data during the process of pushing live stream data from the broadcaster to the edge computing node and relaying live stream data from the edge computing node to the relay device, and analyzes the jitter situation. This method is compatible with various scenarios and can automatically execute relay jitter recovery tasks based on continuous jitter to promptly resolve relay anomalies, saving manpower while improving relay response speed and live stream quality. This application uses the FPS of the broadcaster's push and relay processes as corresponding performance data, calculates the difference between two adjacent FPS, and applies the first-order difference principle to detect the stability between adjacent FPS, thereby determining the relay jitter situation. For situations where the broadcaster's push performance data is stable but the relay performance data is slightly unstable, the jitter amplitude is calculated, and additional algorithms are used to accommodate this situation, thereby more accurately identifying and distinguishing relay instability and better improving the user experience.

[0055] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of the embodiments of this application are described below. Attached Figure Description

[0056] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0057] Figure 1This diagram illustrates the live stream transmission process in the prior art.

[0058] Figure 2 A flowchart illustrating a live stream forwarding and pushing method according to an embodiment of this application is shown.

[0059] Figure 3 A flowchart illustrating a live stream forwarding and pushing method according to another embodiment of this application is shown;

[0060] Figure 4 A structural block diagram of a live stream forwarding and pushing processing apparatus according to an embodiment of this application is shown;

[0061] Figure 5 A schematic diagram of the structure of a computing device according to an embodiment of this application is shown. Detailed Implementation

[0062] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0063] First, the terms and concepts involved in one or more embodiments of this application will be explained.

[0064] Live stream data: The transmission of live audio and video data, which can be transmitted to viewers over the network as a stable and continuous stream.

[0065] Broadcaster-side streaming: refers to the process by which broadcasters push live stream data to a designated streaming media server using live streaming tools.

[0066] Content Delivery Network (CDN): It is an intelligent virtual network built on the existing network infrastructure. Relying on edge servers deployed in various locations, it enables users to obtain the content they need from the nearest location through the load balancing, content distribution, and scheduling functions of the central platform, thereby reducing network congestion and improving user access response speed and hit rate.

[0067] Push performance data: This is data collected during the process of the broadcaster pushing live stream data to edge computing nodes (i.e., the push process), which can be used to reflect the push performance and whether the push process is stable.

[0068] Retransmission performance data: This data is collected during the process of retransmitting live stream data from edge computing nodes to CDN and other retransmission devices. It can be used to reflect the retransmission performance and whether the retransmission process is stable.

[0069] Edge computing node: In this application example, the edge computing node refers to the uplink edge computing node, which is a streaming media service node used to receive live stream data pushed by the broadcaster.

[0070] Edge computing is a distributed computing architecture that moves the computation of applications, data, and services from the central nodes of the network to logically edge nodes.

[0071] Routing Table Maintenance Protocol (RTMP): This is a network protocol used for real-time data communication. It is mainly used for audio, video and data communication between streaming media / interactive servers that run across operating systems (Flash / AIR platform) and support the RTMP protocol.

[0072] Frames Per Second (FPS): This refers to the number of frames transmitted per second, which is simply the number of frames in an animation or video. FPS measures the amount of information used to store and display dynamic video. The more frames per second, the smoother the displayed motion.

[0073] Figure 2 A flowchart illustrating a live stream forwarding and pushing method according to an embodiment of this application is shown, as follows: Figure 2 As shown, the method includes the following steps:

[0074] Step S210: During the process of pushing live stream data from the broadcaster to the edge computing node, collect the push performance data corresponding to the live stream data.

[0075] Step S220: During the process of the edge computing node forwarding live stream data to the forwarding device, collect the forwarding performance data corresponding to the live stream data.

[0076] Depend on Figure 1 As shown in the diagram of the live stream transmission process, in the live streaming system, the broadcaster pushes the live stream data to the edge computing node. The push performance data collected during the broadcaster's push process (i.e., the push process) is referred to as Data A. The edge computing node then forwards the live stream data to the forwarding device, which may include CDN and transcoding clusters, etc. Figure 1 The image shows an edge computing node forwarding live stream data to a CDN via the public network. The forwarding performance data collected during this public network forwarding process is referred to as Data B. Figure 1The document also shows that edge computing nodes transmit live stream data to a transcoding cluster via the public network. The transcoding cluster can transcode the live stream data to provide the room where the broadcaster is located with more viewing clarity options. The transcoding performance data corresponding to the live stream data transposed from the edge computing nodes is referred to as Data C, and the transcoding performance data corresponding to the live stream data received from the transcoding cluster is referred to as Data D.

[0077] In step S210, during the process of pushing live stream data from the broadcaster's end to the edge computing node, that is... Figure 1 During the live streaming process, sampling points are set according to a preset sampling period (e.g., every 1 second). Push performance data corresponding to the live stream data is collected from the broadcaster's end according to these sampling points; this is known as Data Collection A. In step S220, push performance data corresponding to the live stream data can also be collected from edge computing nodes or push-forwarding devices according to the sampling points. Specifically, when the push-forwarding device is a CDN, push performance data corresponding to the live stream data can be collected from the edge computing node during the process of pushing live stream data from the edge computing node to the CDN; this is known as Data Collection B. When the push-forwarding device is a transcoding cluster, push performance data corresponding to the live stream data can be collected from the edge computing node during the process of pushing live stream data from the transcoding cluster; this is known as Data Collection C. Alternatively, push performance data corresponding to the live stream data can also be collected from the transcoding cluster; this is known as Data Collection D.

[0078] Buffering in a single live stream refers to a situation where the transmission of a live stream changes within a short period of time, and this change exceeds a certain preset range. This indicates that the stream is experiencing jitter, which can cause buffering for the user.

[0079] In the live streaming field, the broadcaster sends data to the uplink edge computing nodes in the cloud server at a relatively stable FPS transmission rate. If the edge computing nodes process the data normally, the received FPS value remains stable. However, if the edge computing nodes experience data anomalies or are overloaded, they cannot process more frames and can only receive a portion of the frames transmitted by the broadcaster. The remaining frames are stored on the broadcaster's end and will be received instantly once the edge computing nodes' load returns to normal. This results in a large fluctuation in the FPS value between transmissions. The same principle applies when the edge computing nodes forward live stream data to the push devices.

[0080] In this embodiment, push performance data refers to data collected during the process of the broadcaster pushing live stream data to the edge computing node, which can reflect push performance. Redirect performance data refers to data collected during the process of the edge computing node redirecting live stream data to CDN or other redirecting devices, which can reflect redirecting performance. Redirecting performance data can be collected from either the edge computing node or the redirecting device. Specifically, push performance data may include: the number of frames per second (fps) and / or the transmission bitrate of the live stream data pushed from the broadcaster to the edge computing node. Redirecting performance data may include: the number of fps and / or the transmission bitrate of the live stream data redirected from the edge computing node to the redirecting device; or, redirecting performance data may include: the number of fps and / or the transmission bitrate of the live stream data received by the redirecting device. In practical applications, to facilitate the analysis of redirecting jitter analysis results, FPS can be used as a factor to determine stuttering; that is, push performance data and redirecting performance data may include FPS and other data.

[0081] Step S230: Based on the push performance data and retweet performance data, analyze the jitter of the live stream data during the retweet process to obtain the retweet jitter analysis results.

[0082] Specifically, by comparing and calculating the streaming performance data and the retweet performance data, the jitter of the live stream data during the retweet process is analyzed to obtain the retweet jitter analysis results. For example, a jitter range can be preset. If the jitter range is met, it can be determined that continuous jitter occurs during the retweet process.

[0083] Step S240: If the retweet jitter analysis result indicates that there is continuous jitter in the retweet process, then execute the retweet jitter recovery task.

[0084] In this step, if the jitter analysis results indicate continuous jitter during the retweet process, it means the retweet quality of the live stream data is poor. In this case, the jitter recovery task can be performed by disconnecting the corresponding retweet link and then re-establishing it. Specifically, during the process of retweeting live stream data from the edge computing node to the CDN, the jitter can be recovered by disconnecting... Figure 1 The link corresponding to public network forwarding B shown in the diagram is interrupted, thus breaking the forwarding link; during the process of edge computing nodes forwarding live stream data to the transcoding cluster, this can be achieved by disconnecting... Figure 1 The link corresponding to push C shown in the diagram is interrupted, and then the link is re-established.

[0085] A live stream forwarding processing method provided in this application involves collecting push performance data corresponding to the live stream data during the process of pushing live stream data from the broadcaster's end to the edge computing node; collecting forwarding performance data corresponding to the live stream data during the process of forwarding live stream data from the edge computing node to the forwarding device; analyzing the jitter of the live stream data during the forwarding process based on the push performance data and the forwarding performance data to obtain a forwarding jitter analysis result; if the forwarding jitter analysis result indicates that there is continuous jitter during the forwarding process, a forwarding jitter recovery task is executed. This method collects push performance data and forwarding performance data and analyzes jitter during the processes of pushing live stream data from the broadcaster's end to the edge computing node and from the edge computing node to the forwarding device. This approach is compatible with various scenarios and can automatically execute a forwarding jitter recovery task based on continuous jitter to promptly resolve forwarding anomalies, saving manpower while improving forwarding response speed and live stream quality.

[0086] Figure 3 A flowchart illustrating a live stream forwarding and pushing method according to another embodiment of this application is shown, as follows: Figure 3 As shown, the method includes the following steps:

[0087] Step S310: During the process of pushing live stream data from the broadcaster to the edge computing node, sampling points are set according to the preset sampling period, and push performance data corresponding to the live stream data is collected from the broadcaster according to the sampling points.

[0088] In this step, sampling points can be set according to a preset sampling period, for example, one sampling point can be set every 1 second. According to the sampling points, during the process of pushing live stream data from the broadcaster to the edge computing node, push performance data corresponding to the live stream data can be continuously collected from the broadcaster, for example, push performance data corresponding to the live stream data can be collected once every 1 second.

[0089] Step S320: During the process of pushing live stream data from the edge computing node to the push device, the push performance data corresponding to the live stream data is collected from the edge computing node or the push device according to the sampling point.

[0090] During the process of pushing live stream data from edge computing nodes to CDN or transcoding clusters and other push devices, the push performance data corresponding to the live stream data is continuously collected from the edge computing nodes or push devices according to the set sampling points. For example, the push performance data corresponding to the live stream data is collected once every 1 second.

[0091] Step S330: Divide the push performance data into a first set corresponding to multiple preset time periods, and divide the retweet performance data into a second set corresponding to multiple preset time periods.

[0092] Generally, the collected push performance data and retweet performance data are grouped into corresponding sets according to a preset time period. Specifically, the push performance data collected within each preset time period forms a first set corresponding to that preset time period, and the retweet performance data collected within each preset time period forms a second set corresponding to that preset time period. For example, if the preset time period is 20 seconds, a sampling point is set every 1 second, and push performance data and retweet performance data are collected once at each sampling point. Whenever multiple push performance data points generated within this 20-second period can be collected, a first set is formed, corresponding to the preset time period; whenever multiple retweet performance data points generated within this 20-second period can be collected, a second set is formed, corresponding to the preset time period. The push performance data collected from multiple sampling points forms a first set, and there is a one-to-one correspondence between the sampling points and the push performance data within the first set; similarly, the retweet performance data collected from multiple sampling points forms a second set, and there is also a one-to-one correspondence between the sampling points and the retweet performance data within the second set.

[0093] Step S340: For each preset time period among multiple preset time periods, analyze the first set corresponding to the preset time period to obtain the push jitter parameters corresponding to the preset time period, and analyze the second set corresponding to the preset time period to obtain the retweet jitter parameters corresponding to the preset time period.

[0094] Based on multiple streaming performance data within the first set, it is calculated whether the live stream data experiences jitter within the time period corresponding to the first set. In this embodiment, the streaming jitter parameter and the forwarding jitter parameter of the live stream data in the current time period can be calculated. For example, taking 20 seconds as the preset time period and the streaming jitter parameter and the forwarding jitter parameter as FPS, the first set is assumed to be (15, 32, 48, 48, 20, 29, 30, 31, 30, 32, 35, 36, 30, 29, 28, 45, 29, 30, 27, 28).

[0095] In an optional implementation, step S340 further includes: calculating the difference between any two adjacent push performance data in the first set corresponding to the preset time period to obtain a plurality of first difference values, and using the sum of the plurality of first difference values ​​as the push jitter parameter corresponding to the preset time period; calculating the difference between any two adjacent forwarding performance data in the second set corresponding to the preset time period to obtain a plurality of second difference values, and using the sum of the plurality of second difference values ​​as the forwarding jitter parameter corresponding to the preset time period.

[0096] Specifically, the first and second differences can be calculated using the first-order difference method. The first-order difference method detects the stationarity of a time series based on the difference between adjacent values ​​in the set. The calculation process is as follows: Let the function be y = f(x), where y is defined only for non-negative integer values ​​of x. When the independent variable x takes all non-negative integer values, i.e., x = 0, 1, 2, ..., the corresponding function values ​​are:

[0097] f(0), f(1), f(2), f(3), ...; denoted as y0, y1, y2, y3, ...;

[0098] Definition 1: When the independent variable changes from x to x+1, the change in the function y = y(x) is given by the following equation (1):

[0099] Δy x =y(x+1)-y(x),(x=0,1,2,…); (1)

[0100] Equation (1) above is called the first difference of the function y(x) at point x, and is usually denoted as equation (2) below:

[0101] Δy x =y x+1 -y x ,(x=0,1,2,…); (2)

[0102] Assuming a preset time period corresponds to a first set of data (15, 32, 48, 48, 20, 29, 30, 31, 30, 32, 35, 36, 30, 29, 28, 45, 29, 30, 27, 28), the difference between any two adjacent push performance data points in this first set is calculated to obtain multiple first difference values. The sum of these multiple first difference values ​​is used as the push jitter parameter corresponding to this preset time period. For example, if the first push performance data point in the first set is 15 and the second is 32, the calculated first difference value is 17. Multiple first difference values ​​can be obtained sequentially, and the sum of these multiple first difference values ​​is used as the push jitter parameter corresponding to this preset time period. The forwarding jitter parameter is calculated using a similar method. By analyzing the push jitter parameter and the corresponding forwarding jitter parameter for each preset time period, it is determined whether there is jitter in the forwarding process of the live stream data within each preset time period.

[0103] Step S350: Analyze the push jitter parameters and the corresponding forwarding jitter parameters corresponding to the first preset number of preset time periods to obtain the forwarding jitter analysis results.

[0104] In an optional implementation, step S350 further includes: for each preset time period in a consecutive first preset number of preset time periods, comparing the push jitter parameter and the retweet jitter parameter corresponding to the preset time period with a preset jitter threshold respectively to obtain the comparison result corresponding to the preset time period, and determining the periodic jitter analysis result corresponding to the preset time period based on the comparison result corresponding to the preset time period; analyzing the periodic jitter analysis results corresponding to the consecutive first preset number of preset time periods to determine the retweet jitter analysis result.

[0105] For a given preset time period, taking the push jitter parameter A' and the retweet jitter parameter B' corresponding to the preset time period as examples, in one optional implementation, the periodic jitter analysis result corresponding to the preset time period is determined based on the comparison result, and further includes the following cases:

[0106] Case 1: If the comparison result corresponding to the preset time period is that the push jitter parameter is less than the preset jitter threshold and the retweet jitter parameter is greater than or equal to the preset jitter threshold, then the periodic jitter analysis result corresponding to the preset time period is determined to be that there is jitter in the retweet process.

[0107] Specifically, the judgment condition for Case 1 is that A' < preset jitter threshold and B' ≥ preset jitter threshold; this case indicates that the streamer's push is stable, but the live stream data has jitter during the re-pushing process.

[0108] Scenario 2: If the comparison result corresponding to the preset time period is that the push jitter parameter is greater than or equal to the preset jitter threshold and the retweet jitter parameter is greater than or equal to the preset jitter threshold, then it is determined that the periodic jitter analysis result corresponding to the preset time period is that there is jitter in both the push process and the retweet process of the broadcaster.

[0109] Specifically, the judgment condition for case 2 is that A'≥ preset jitter threshold and B'≥ preset jitter threshold. This case indicates that the live stream data is unstable during the push and re-pushing process of the broadcaster and the broadcaster. Both cases involve jitter.

[0110] Case 3: If the comparison result corresponding to the preset time period is that the push jitter parameter is less than the preset jitter threshold and the forward jitter parameter is less than the preset jitter threshold, then the periodic jitter analysis result corresponding to the preset time period is determined according to the first set and the second set corresponding to the preset time period.

[0111] Specifically, the judgment condition for case 3 is that A' < preset jitter threshold and B' < preset jitter threshold. This case indicates that the streamer's push is stable. However, although B' is less than the preset jitter threshold in this case, the preset jitter threshold is usually set relatively high in order to prevent false alarms, so as to be compatible with general jitter situations. However, unstable push will significantly affect the live broadcast quality, so it is necessary to further judge whether the push is stable.

[0112] In one optional implementation, for case 3, the percentage of retweet jitter corresponding to the preset time period can be calculated based on the first set and the second set corresponding to the preset time period. If the percentage of retweet jitter corresponding to the preset time period is less than a preset percentage threshold, the periodic jitter analysis result corresponding to the preset time period is determined to be that there is no jitter in the retweet process. If the percentage of retweet jitter corresponding to the preset time period is greater than or equal to the preset percentage threshold, the periodic jitter analysis result corresponding to the preset time period is determined to be that there is jitter in the retweet process.

[0113] Specifically, for each push performance data in the first set corresponding to the preset time period, the corresponding retweet performance data is obtained from the second set corresponding to the preset time period. The corresponding retweet jitter amplitude is calculated using the push performance data and the corresponding retweet performance data, and the retweet jitter amplitude is added to the third set corresponding to the preset time period. Based on the third set corresponding to the preset time period, the retweet jitter ratio corresponding to the preset time period is calculated.

[0114] Specifically, calculating the retweet jitter percentage corresponding to the preset time period based on the third set corresponding to the preset time period further includes: if any retweet jitter amplitude in the third set corresponding to the preset time period is greater than a preset amplitude threshold, then the retweet jitter amplitude is regarded as an abnormal amplitude; the proportion of the number of abnormal amplitudes in the third set corresponding to the preset time period is taken as the retweet jitter percentage corresponding to the preset time period.

[0115] For scenario 3, the FPS in the push performance data and the FPS in the corresponding retweet performance data can be compared and calculated one by one to determine the period jitter analysis result corresponding to the preset time period. For each push performance data in the first set corresponding to the preset time period, the retweet performance data corresponding to the push performance data is obtained from the second set corresponding to the preset time period. The corresponding retweet jitter amplitude is calculated using the push performance data and the retweet performance data corresponding to the push performance data. The formula for calculating the retweet jitter amplitude is as follows (3):

[0116] Retweet jitter amplitude = |(FPS in push performance data - FPS in retweet performance data)| / FPS in push performance data; (3)

[0117] In equation (3), "||" represents the absolute value. If the forward jitter amplitude is greater than the preset amplitude threshold, it means that the forwarding process corresponding to the sampling point is jittering, and the forward jitter amplitude is regarded as an abnormal amplitude; if the number of abnormal amplitudes in the third set exceeds a certain proportion, it means that the forwarding of the third set is unstable.

[0118] For example, taking a preset amplitude threshold of 10% and a preset percentage threshold of 30% as an example, the FPS of the push performance data in the first set is (30, 30, 29, 26, 26, 31, 28), and the FPS of the retweet performance data in the second set is (28, 35, 28, 33, 30, 25, 28). According to the above formula (3), the corresponding retweet jitter amplitude is calculated, and the third set is (6.6%, 16.6%, 3.4%, 13.3%, 3.8%, 19.3%, 0%). The preset amplitude threshold is 10%. Then, the retweet jitter amplitude in the third set is greater than 10%, which is an abnormal amplitude. Among the 7 retweet jitter amplitudes in the third set, 3 retweet jitter amplitudes are abnormal amplitudes, and the retweet jitter percentage is 3 / 7 = 42%, which is greater than the preset percentage threshold of 30%. Therefore, the periodic jitter analysis result corresponding to the preset time period is determined to be that there is jitter in the retweet process.

[0119] Specifically, analyzing the periodic jitter analysis results corresponding to a first preset number of consecutive preset time periods, and determining the push jitter analysis results further includes: counting the target number of periodic jitter analysis results that include jitter in the push process among the periodic jitter analysis results corresponding to a first preset number of consecutive preset time periods; if the target number is greater than a second preset number, then the push jitter analysis result is determined to be that there is continuous jitter in the push process; if the target number is less than or equal to the second preset number, then the push jitter analysis result is determined to be that there is no continuous jitter in the push process.

[0120] Specifically, taking a preset time period of 20 seconds as an example, the push performance data and retweet performance data collected within 20 seconds form corresponding sets. The first and second sets each contain 20 data points. First, it is determined whether jitter exists in the first and second sets respectively. The target number of periodic jitter analysis results including jitter in the retweet process is counted among the periodic jitter analysis results corresponding to multiple consecutive 20-second time periods. If the target number is greater than the second preset number, the retweet jitter analysis result is determined to indicate continuous jitter in the retweet process. For example, taking 3 minutes as a continuous jitter analysis time period, 3 minutes includes 9 preset time periods of 20 seconds. The target number of periodic jitter analysis results including jitter in the retweet process is counted among the periodic jitter analysis results corresponding to 9 consecutive 20-second time periods. For example, the target number is N. If N is greater than the second preset number, the retweet jitter analysis result is determined to indicate continuous jitter in the retweet process, and step S360 is continued; if N is less than or equal to the second preset number, no processing is performed. The second preset number is less than the first preset number.

[0121] Step S360: If the jitter analysis result indicates that there is continuous jitter in the retweet process, disconnect the corresponding retweet link and re-establish the retweet link.

[0122] In this step, if the jitter analysis indicates continuous jitter during the forwarding process, the relevant interface is invoked to disconnect the corresponding forwarding link and then re-establish it. Specifically, during the process of forwarding live stream data from edge computing nodes to the CDN, this can be achieved by disconnecting... Figure 1 The link corresponding to public network forwarding B shown in the diagram is interrupted, thus breaking the forwarding link; during the process of edge computing nodes forwarding live stream data to the transcoding cluster, this can be achieved by disconnecting... Figure 1 The link corresponding to push C shown in the diagram is interrupted, and then the link is re-established.

[0123] According to the embodiments of this application, a live stream forwarding processing method is provided. During the process of pushing live stream data from the broadcaster's end to the edge computing node and the edge computing node forwarding live stream data to the forwarding device, push performance data and forwarding performance data are collected to analyze jitter. This method is compatible with various scenarios and can automatically execute forwarding jitter recovery tasks based on continuous jitter to promptly resolve forwarding anomalies, saving manpower while improving forwarding response speed and live stream quality. This application uses the FPS of the broadcaster's push and forwarding processes as corresponding performance data, calculates the difference between two adjacent FPS, and applies the first-order difference principle to detect the stability between adjacent FPS, thereby determining the forwarding jitter. For situations where the broadcaster's push performance data is stable but the forwarding performance data is slightly unstable, the jitter amplitude is calculated, and additional algorithms are used to accommodate this situation, thereby more accurately identifying and distinguishing unstable forwarding conditions and better improving the user experience.

[0124] Figure 4 A structural block diagram of a live stream forwarding and pushing processing apparatus according to an embodiment of this application is shown, as follows: Figure 4 As shown, the device includes: a data acquisition module 410, an analysis module 420, and a processing module 430.

[0125] The data acquisition module 410 is used to collect push performance data corresponding to the live stream data during the process of pushing live stream data from the broadcaster to the edge computing node; and to collect push performance data corresponding to the live stream data during the process of pushing live stream data from the edge computing node to the push device.

[0126] In an optional implementation, the data acquisition module 410 is further configured to: set sampling points according to a preset sampling period, and collect push performance data corresponding to the live stream data from the broadcaster's terminal according to the sampling points; and collect push performance data corresponding to the live stream data from edge computing nodes or push devices according to the sampling points.

[0127] The push performance data includes: the number of frames per second and / or the transmission bitrate of live stream data pushed from the broadcaster to the edge computing node. The forwarding performance data includes: the number of frames per second and / or the transmission bitrate of live stream data forwarded from the edge computing node to the forwarding device; or, the forwarding performance data includes: the number of frames per second and / or the transmission bitrate of live stream data received by the forwarding device.

[0128] The analysis module 420 is used to analyze the jitter of the live stream data during the retweet process based on push performance data and retweet performance data, and obtain the retweet jitter analysis results.

[0129] In an optional implementation, the analysis module 420 is further configured to: divide the push performance data into a first set corresponding to multiple preset time periods, and divide the retweet performance data into a second set corresponding to multiple preset time periods; for each preset time period, analyze the first set corresponding to the preset time period to obtain the push jitter parameter corresponding to the preset time period, and analyze the second set corresponding to the preset time period to obtain the retweet jitter parameter corresponding to the preset time period; analyze the push jitter parameter and the corresponding retweet jitter parameter corresponding to a first preset number of consecutive preset time periods to obtain the retweet jitter analysis result.

[0130] In an optional implementation, the analysis module 420 is further configured to: form a first set corresponding to the preset time period by the push performance data collected in each preset time period, and form a second set corresponding to the preset time period by the retweet performance data collected in each preset time period.

[0131] In an optional implementation, the analysis module 420 is further configured to: calculate the difference between any two adjacent push performance data in the first set corresponding to the preset time period to obtain a plurality of first difference values, and use the sum of the plurality of first difference values ​​as the push jitter parameter corresponding to the preset time period; calculate the difference between any two adjacent forwarding performance data in the second set corresponding to the preset time period to obtain a plurality of second difference values, and use the sum of the plurality of second difference values ​​as the forwarding jitter parameter corresponding to the preset time period.

[0132] In an optional implementation, the analysis module 420 is further configured to: for each preset time period in a consecutive first preset number of preset time periods, compare the push jitter parameter and the retweet jitter parameter corresponding to the preset time period with a preset jitter threshold respectively, obtain the comparison result corresponding to the preset time period, and determine the periodic jitter analysis result corresponding to the preset time period based on the comparison result corresponding to the preset time period; analyze the periodic jitter analysis results corresponding to the consecutive first preset number of preset time periods to determine the retweet jitter analysis result.

[0133] In an optional implementation, the analysis module 420 is further configured to: if the comparison result corresponding to the preset time period is that the push jitter parameter is less than the preset jitter threshold and the retweet jitter parameter is greater than or equal to the preset jitter threshold, then determine that the periodic jitter analysis result corresponding to the preset time period is that there is jitter in the retweet process; if the comparison result corresponding to the preset time period is that the push jitter parameter is greater than or equal to the preset jitter threshold and the retweet jitter parameter is greater than or equal to the preset jitter threshold, then determine that the periodic jitter analysis result corresponding to the preset time period is that there is jitter in both the push process and the retweet process of the broadcaster.

[0134] In an optional implementation, the analysis module 420 is further configured to: if the comparison result corresponding to the preset time period is that the push jitter parameter is less than the preset jitter threshold and the forward jitter parameter is less than the preset jitter threshold, then determine the periodic jitter analysis result corresponding to the preset time period based on the first set corresponding to the preset time period and the second set corresponding to the preset time period.

[0135] In an optional implementation, the analysis module 420 is further configured to: calculate the retweet jitter percentage corresponding to the preset time period based on the first set corresponding to the preset time period and the second set corresponding to the preset time period; if the retweet jitter percentage corresponding to the preset time period is less than a preset percentage threshold, then determine that the periodic jitter analysis result corresponding to the preset time period is that there is no jitter in the retweet process; if the retweet jitter percentage corresponding to the preset time period is greater than or equal to the preset percentage threshold, then determine that the periodic jitter analysis result corresponding to the preset time period is that there is jitter in the retweet process.

[0136] In an optional implementation, the analysis module 420 is further configured to: for each push performance data in the first set corresponding to the preset time period, obtain the corresponding retweet performance data from the second set corresponding to the preset time period; calculate the corresponding retweet jitter amplitude using the push performance data and the corresponding retweet performance data; and add the retweet jitter amplitude to the third set corresponding to the preset time period; and calculate the retweet jitter percentage corresponding to the preset time period based on the third set corresponding to the preset time period.

[0137] In an optional implementation, the analysis module 420 is further configured to: if any retweet jitter amplitude in the third set corresponding to the preset time period is greater than a preset amplitude threshold, then the retweet jitter amplitude is regarded as an abnormal amplitude; and the proportion of the number of abnormal amplitudes in the third set corresponding to the preset time period is regarded as the retweet jitter proportion corresponding to the preset time period.

[0138] In an optional implementation, the analysis module 420 is further configured to: count the target number of period jitter analysis results corresponding to a first preset number of preset time periods, including the period jitter analysis results where jitter exists in the retweet process; if the target number is greater than a second preset number, then determine that the retweet jitter analysis result indicates that there is continuous jitter in the retweet process; if the target number is less than or equal to the second preset number, then determine that the retweet jitter analysis result indicates that there is no continuous jitter in the retweet process.

[0139] The processing module 430 is used to perform a retweet jitter recovery task if the retweet jitter analysis result indicates that there is continuous jitter in the retweet process.

[0140] In an optional implementation, the processing module 430 is further configured to: disconnect the corresponding push link and re-establish the push link.

[0141] The descriptions of the above modules refer to the corresponding descriptions in the method embodiments, and will not be repeated here.

[0142] According to an embodiment of this application, a live stream forwarding processing device collects push performance data and forwarding performance data during the process of pushing live stream data from the broadcaster to the edge computing node and the edge computing node forwarding live stream data to the forwarding device, and analyzes the jitter situation. This method is compatible with various scenarios and can automatically execute forwarding jitter recovery tasks based on continuous jitter to solve forwarding anomalies, saving manpower while improving forwarding response speed and live streaming quality. The device samples the FPS of the broadcaster's push process and the forwarding process as corresponding performance data, calculates the difference between two adjacent FPS, and applies the first-order difference principle to detect the stability between adjacent FPS to determine the forwarding jitter situation. For situations where the broadcaster's push performance data is stable but the forwarding performance data is slightly unstable, the device calculates the jitter amplitude and uses additional algorithms to accommodate this situation, thereby more accurately identifying and distinguishing the unstable forwarding situation and better improving the user experience.

[0143] This application also provides a non-volatile computer storage medium storing at least one executable instruction that can execute a live stream push processing method in any of the above method embodiments.

[0144] Figure 5 The diagram shows a structural schematic of a computing device according to an embodiment of the present application. The specific embodiments of the present application do not limit the specific implementation of the computing device.

[0145] like Figure 5As shown, the computing device may include: a processor 502, a communications interface 504, a memory 506, and a communications bus 608.

[0146] in:

[0147] The processor 502, communication interface 504, and memory 506 communicate with each other via communication bus 508.

[0148] Communication interface 504 is used to communicate with other network elements such as clients or other servers.

[0149] The processor 502 is used to execute program 510, which can specifically execute the relevant steps in the above-described live stream push processing method embodiment.

[0150] Specifically, program 510 may include program code that includes computer operation instructions.

[0151] Processor 502 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The computing device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0152] Memory 506 is used to store program 510. Memory 506 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0153] Specifically, program 510 can be used to cause processor 502 to execute a live stream forwarding processing method in any of the above method embodiments. The specific implementation of each step in program 510 can be found in the corresponding descriptions of the steps and units in the above-described live stream forwarding processing method embodiments, and will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the devices and modules described above can be referred to the corresponding process descriptions in the foregoing method embodiments, and will not be repeated here.

[0154] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the contents of the embodiments of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best implementation of the embodiments of this application.

[0155] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0156] Similarly, it should be understood that, in order to simplify this disclosure and aid in understanding one or more of the various inventive aspects, in the foregoing description of exemplary embodiments of the present application, various features of the present application embodiments are sometimes grouped together into a single embodiment, figure, or description thereof. However, this approach to disclosure should not be construed as reflecting an intention that the claimed embodiments of the present application require more features than expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the present application.

[0157] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0158] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are meant to be within the scope of the embodiments of this application and form different embodiments. For example, in the following claims, any one of the claimed embodiments can be used in any combination.

[0159] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components according to the embodiments of this application. The embodiments of this application can also be implemented as device or apparatus programs (e.g., computer programs and computer program products) for performing part or all of the methods described herein. Such programs implementing the embodiments of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0160] It should be noted that the above embodiments are illustrative of the embodiments of this application and not limiting of the embodiments of this application, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Embodiments of this application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

Claims

1. A method for processing live stream forwarding and pushing, comprising: During the process of pushing live stream data from the broadcaster's end to the edge computing node, the push performance data corresponding to the live stream data is collected. During the process of the edge computing node forwarding the live stream data to the forwarding device, the forwarding performance data corresponding to the live stream data is collected; Based on the push performance data and the retweet performance data, the jitter of the live stream data during the retweet process is analyzed to obtain the retweet jitter analysis results; If the retweet jitter analysis result indicates that there is continuous jitter in the retweet process, then a retweet jitter recovery task is executed; The step of analyzing the jitter of the live stream data during the retweet process based on the push performance data and the retweet performance data to obtain the retweet jitter analysis results further includes: The push performance data is divided into a first set corresponding to multiple preset time periods, and the forwarding performance data is divided into a second set corresponding to multiple preset time periods. For each preset time period in a consecutive first preset number of preset time periods, the cycle jitter analysis result corresponding to the preset time period is determined based on the comparison result corresponding to the preset time period; wherein, the process of determining the cycle jitter analysis result corresponding to the preset time period includes: calculating the retweet jitter ratio corresponding to the preset time period based on the first set and the second set corresponding to the preset time period, and determining the cycle jitter analysis result corresponding to the preset time period based on the retweet jitter ratio corresponding to the preset time period; Analyze the period jitter analysis results corresponding to the first preset number of consecutive preset time periods to determine the push jitter analysis results.

2. The method of claim 1, wherein, The step of collecting the push performance data corresponding to the live stream data further includes: setting sampling points according to a preset sampling period, and collecting the push performance data corresponding to the live stream data from the broadcaster's end according to the sampling points; The process of collecting the relay performance data corresponding to the live stream data further includes: collecting the relay performance data corresponding to the live stream data from the edge computing node or the relay device according to the sampling point.

3. The method according to claim 1, wherein, The step of analyzing the jitter of the live stream data during the retweet process based on the push performance data and the retweet performance data, and obtaining the retweet jitter analysis results, further includes: For each of the plurality of preset time periods, the push jitter parameters corresponding to the preset time period are obtained by analyzing the first set corresponding to the preset time period, and the retweet jitter parameters corresponding to the preset time period are obtained by analyzing the second set corresponding to the preset time period.

4. The method according to claim 3, wherein, The step of dividing the push performance data into a first set corresponding to multiple preset time periods, and the step of dividing the retweet performance data into a second set corresponding to multiple preset time periods, further includes: The push performance data collected within each preset time period will form a first set corresponding to that preset time period, and the retweet performance data collected within each preset time period will form a second set corresponding to that preset time period.

5. The method according to claim 3, wherein, The step of analyzing the first set corresponding to each of the plurality of preset time periods to obtain the push jitter parameters corresponding to that preset time period, and analyzing the second set corresponding to that preset time period to obtain the retweet jitter parameters corresponding to that preset time period, further includes: Calculate the difference between any two adjacent push performance data in the first set corresponding to the preset time period to obtain multiple first difference values, and use the sum of the multiple first difference values ​​as the push jitter parameter corresponding to the preset time period; The difference between any two adjacent push performance data in the second set corresponding to the preset time period is calculated to obtain multiple second difference values, and the sum of the multiple second difference values ​​is used as the push jitter parameter corresponding to the preset time period.

6. The method according to claim 1, wherein, Before determining the period jitter analysis result corresponding to the preset time period based on the comparison result corresponding to the preset time period, the method further includes: The push jitter parameters and retweet jitter parameters corresponding to the preset time period are compared with the preset jitter threshold to obtain the comparison results corresponding to the preset time period.

7. The method according to claim 6, wherein, The step of determining the period jitter analysis result corresponding to the preset time period based on the comparison result of the preset time period further includes: If the comparison result corresponding to the preset time period is that the push jitter parameter is less than the preset jitter threshold and the forwarding jitter parameter is greater than or equal to the preset jitter threshold, then the periodic jitter analysis result corresponding to the preset time period is determined to be that there is jitter in the forwarding process; If the comparison result corresponding to the preset time period is that the push jitter parameter is greater than or equal to the preset jitter threshold and the retweet jitter parameter is greater than or equal to the preset jitter threshold, then it is determined that the periodic jitter analysis result corresponding to the preset time period is that there is jitter in both the push process and the retweet process of the broadcaster.

8. The method according to claim 6, wherein, The step of determining the period jitter analysis result corresponding to the preset time period based on the comparison result of the preset time period further includes: If the comparison result corresponding to the preset time period is that the push jitter parameter is less than the preset jitter threshold and the retweet jitter parameter is less than the preset jitter threshold, then the retweet jitter ratio corresponding to the preset time period is calculated based on the first set and the second set corresponding to the preset time period, and the periodic jitter analysis result corresponding to the preset time period is determined based on the retweet jitter ratio corresponding to the preset time period.

9. The method according to claim 8, wherein, The step of determining the periodic jitter analysis result corresponding to the preset time period based on the percentage of retweet jitter corresponding to the preset time period further includes: If the percentage of retweet jitter corresponding to the preset time period is less than the preset percentage threshold, then the periodic jitter analysis result corresponding to the preset time period is determined to be that there is no jitter in the retweet process; If the percentage of retweet jitter corresponding to the preset time period is greater than or equal to the preset percentage threshold, then the periodic jitter analysis result corresponding to the preset time period is determined to indicate that there is jitter in the retweet process.

10. The method according to claim 8, wherein, The step of calculating the retweet jitter percentage corresponding to the preset time period based on the first set and the second set corresponding to the preset time period further includes: For each push performance data in the first set corresponding to the preset time period, the retweet performance data corresponding to the push performance data is obtained from the second set corresponding to the preset time period. The corresponding retweet jitter amplitude is calculated using the push performance data and the retweet performance data corresponding to the push performance data, and the retweet jitter amplitude is added to the third set corresponding to the preset time period. Based on the third set corresponding to the preset time period, calculate the percentage of retweet jitter corresponding to the preset time period.

11. The method according to claim 10, wherein, The step of calculating the percentage of retweet jitter corresponding to the preset time period based on the third set corresponding to the preset time period further includes: If the amplitude of any push jitter in the third set corresponding to the preset time period is greater than the preset amplitude threshold, then the amplitude of the push jitter is regarded as an abnormal amplitude. The proportion of the number of abnormal amplitudes in the third set corresponding to the preset time period is taken as the proportion of push jitter corresponding to the preset time period.

12. The method according to any one of claims 1-10, wherein, The step of analyzing the period jitter analysis results corresponding to the first preset number of consecutive preset time periods, and determining the push jitter analysis results, further includes: The target number of period jitter analysis results corresponding to the first preset number of consecutive preset time periods includes the period jitter analysis results where jitter exists in the push process; If the target number is greater than the second preset number, the retweet jitter analysis result is determined to be that there is continuous jitter in the retweet process; if the target number is less than or equal to the second preset number, the retweet jitter analysis result is determined to be that there is no continuous jitter in the retweet process.

13. The method according to any one of claims 1-10, wherein, The execution of the push jitter recovery task further includes: Disconnect the corresponding push link and re-establish the push link.

14. The method according to any one of claims 1-10, wherein, The push performance data includes: the number of frames per second and / or the transmission bitrate of the live stream data pushed by the broadcaster to the edge computing node; The relay performance data includes: the number of frames per second and / or the transmission bitrate of the live stream data relayed by the edge computing node to the relay device; or, the relay performance data includes: the number of frames per second and / or the transmission bitrate of the live stream data received by the relay device.

15. A live stream forwarding and pushing processing device, comprising: The data acquisition module is used to collect push performance data corresponding to the live stream data during the process of pushing live stream data from the broadcaster's end to the edge computing node; During the process of the edge computing node forwarding the live stream data to the forwarding device, the forwarding performance data corresponding to the live stream data is collected; The analysis module is used to analyze the jitter of the live stream data during the retweet process based on the push performance data and the retweet performance data, and obtain the retweet jitter analysis results. The processing module is used to execute a retweet jitter recovery task if the retweet jitter analysis result indicates that there is continuous jitter in the retweet process. The analysis module is further used for: The push performance data is divided into a first set corresponding to multiple preset time periods, and the forwarding performance data is divided into a second set corresponding to multiple preset time periods. For each preset time period in a consecutive first preset number of preset time periods, the cycle jitter analysis result corresponding to the preset time period is determined based on the comparison result corresponding to the preset time period; wherein, the process of determining the cycle jitter analysis result corresponding to the preset time period includes: calculating the retweet jitter ratio corresponding to the preset time period based on the first set and the second set corresponding to the preset time period, and determining the cycle jitter analysis result corresponding to the preset time period based on the retweet jitter ratio corresponding to the preset time period; Analyze the period jitter analysis results corresponding to the first preset number of consecutive preset time periods to determine the push jitter analysis results.

16. A computing device, comprising: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform an operation corresponding to a live stream push processing method as described in any one of claims 1-14.

17. A computer storage medium storing at least one executable instruction that causes a processor to perform an operation corresponding to a live stream push processing method as described in any one of claims 1-14.

18. A computer program product comprising at least one executable instruction that causes a processor to perform an operation corresponding to a live stream push processing method as described in any one of claims 1-14.

Images