CN113094239A

CN113094239A - Method for determining reason of live broadcast abnormity and server

Info

Publication number: CN113094239A
Application number: CN202110462368.XA
Authority: CN
Inventors: 孙袁袁; 柴黎明; 邵高原
Original assignee: Shanghai Bilibili Technology Co Ltd
Current assignee: Shanghai Bilibili Technology Co Ltd
Priority date: 2021-04-27
Filing date: 2021-04-27
Publication date: 2021-07-09
Anticipated expiration: 2041-04-27
Also published as: CN113094239B

Abstract

The application provides a method for determining a reason of live broadcast abnormity and a server, wherein the method for determining the reason of live broadcast abnormity comprises the following steps: under the condition that a server side detection condition is met, acquiring a live broadcast stream in an edge node, and determining whether live broadcast abnormity comprises a first reference reason or not according to the quality of the live broadcast stream; acquiring pause information reported by a user side from a pause statistical system, and determining whether the live broadcast abnormity comprises a second reference reason or not according to the pause information; and under the condition that the live broadcast abnormity comprises the first reference reason and/or the second reference reason, determining a server-side reason of the live broadcast abnormity according to the first reference reason and/or the second reference reason. Therefore, the server reason of the live broadcast abnormity can be quickly and accurately determined in a short time, the processing time is greatly saved, the efficiency of determining the reason of the live broadcast abnormity is improved, and the response speed of the live broadcast abnormity is improved.

Description

Method for determining reason of live broadcast abnormity and server

Technical Field

The application relates to the technical field of live broadcast, in particular to a method for determining a reason of live broadcast abnormity. The application also relates to a server for determining the reason of the live broadcast abnormity, a computing device and a computer readable storage medium.

Background

With the rapid development of computer technology and network technology, various live broadcasts are increasingly popularized in work, life and entertainment of people. In the existing live broadcast system, a link from a main broadcast end to a user end is very long, influence factors are various, any link has problems, and live broadcast watched by a user can be blocked or cannot be watched.

In the prior art, a user contacts with a customer service feedback problem under the condition that the live broadcast is blocked or cannot be watched, then the customer service enters a feedback work order, waits for a conclusion given by related research and development personnel, and then feeds the result back to the user by the customer service. However, the flow causing the live broadcast to be blocked or incapable of being watched is complex, research and development personnel are required to eliminate each link one by one, and finally the reason of the live broadcast abnormity is determined.

Disclosure of Invention

In view of this, the embodiment of the present application provides a method for determining a reason for a live broadcast abnormality. The application also relates to a server for determining the reason of the live broadcast abnormity, a computing device and a computer readable storage medium, which are used for solving the problem of low efficiency in determining the reason of the live broadcast abnormity in the prior art.

According to a first aspect of the embodiments of the present application, a method for determining a reason for a live broadcast abnormality is provided, including:

under the condition that a server side detection condition is met, acquiring a live broadcast stream in an edge node, and determining whether live broadcast abnormity comprises a first reference reason or not according to the quality of the live broadcast stream;

acquiring pause information reported by a user side from a pause statistical system, and determining whether the live broadcast abnormity comprises a second reference reason or not according to the pause information;

and under the condition that the live broadcast abnormity comprises the first reference reason and/or the second reference reason, determining a server-side reason of the live broadcast abnormity according to the first reference reason and/or the second reference reason.

According to a second aspect of the embodiments of the present application, a server for determining a reason for a live broadcast exception is provided, including:

the first acquisition module is configured to acquire a live broadcast stream in an edge node under the condition that a server detection condition is met, and determine whether live broadcast abnormity comprises a first reference reason or not according to the quality of the live broadcast stream;

the second acquisition module is configured to acquire the pause information reported by the user side from the pause statistical system and determine whether the live broadcast abnormity comprises a second reference reason or not according to the pause information;

the first determining module is configured to determine a server-side reason of the live broadcast abnormality according to the first reference reason and/or the second reference reason when the live broadcast abnormality is determined to include the first reference reason and/or the second reference reason.

According to a third aspect of embodiments herein, there is provided a computing device comprising:

a memory and a processor;

the memory is configured to store computer-executable instructions, and the processor is configured to execute the computer-executable instructions to implement the method of:

According to a fourth aspect of embodiments of the present application, there is provided a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of any of the live broadcast abnormality cause determination methods.

The method for determining the reason of the live broadcast abnormity comprises the steps of acquiring a live broadcast stream in an edge node under the condition that a server side detection condition is met, and determining whether the live broadcast abnormity comprises a first reference reason or not according to the quality of the live broadcast stream; acquiring pause information reported by a user side from a pause statistical system, and determining whether the live broadcast abnormity comprises a second reference reason or not according to the pause information; and under the condition that the live broadcast abnormity comprises the first reference reason and/or the second reference reason, determining a server-side reason of the live broadcast abnormity according to the first reference reason and/or the second reference reason. Under the condition, data in the edge nodes and the stuck statistical system can be integrated, the server abnormity which possibly occurs when the main broadcast end pushes the stream to the link of the user end pull stream is automatically processed and judged, so that the server reason of the live broadcast abnormity can be quickly determined in a short time, a feedback result is given, the processing time is greatly saved, the efficiency of determining the reason of the live broadcast abnormity is improved, the response speed of the live broadcast abnormity is improved, research and development personnel do not need to eliminate each link one by one, the capability requirement on the research and development personnel is reduced, and the labor cost is saved. In addition, due to the fact that the pause information reported by the plurality of user sides in the pause statistical system can be combined, the abnormity of the service side can be analyzed and determined, the substantial reason of the problems of the live broadcast can be analyzed from the perspective of the plurality of user sides, the complaint problem can be fundamentally solved, the accuracy of determining the reason of the abnormity of the live broadcast is improved, the abnormity of the service side can be timely processed, and the same abnormity fed back by most users can be avoided.

Drawings

Fig. 1 is a flowchart of a method for determining a reason for a live broadcast exception according to an embodiment of the present application;

fig. 2 is an overall link diagram of an anchor push stream according to an embodiment of the present application;

fig. 3 is a schematic diagram of a process for determining a reason for a live broadcast abnormality according to an embodiment of the present application;

fig. 4 is a flowchart of another method for determining a reason for a live broadcast exception according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of a server for determining a reason for a live broadcast exception according to an embodiment of the present application;

fig. 6 is a block diagram of a computing device according to an embodiment of the present application.

Detailed Description

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. This application is capable of implementation in many different ways than those herein set forth and of similar import by those skilled in the art without departing from the spirit of this application and is therefore not limited to the specific implementations disclosed below.

The terminology used in the one or more embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the present application. As used in one or more embodiments of the present application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used in one or more embodiments of the present application refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It will be understood that, although the terms first, second, etc. may be used herein in one or more embodiments of the present application to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, a first aspect may be termed a second aspect, and, similarly, a second aspect may be termed a first aspect, without departing from the scope of one or more embodiments of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

First, the noun terms to which one or more embodiments of the present application relate are explained.

Live streaming: live audiovisual data transmission that can be transmitted as a steady and continuous stream over a network for viewing by an audience.

Pushing flow: the anchor acquires the streaming address from the live broadcast platform through the anchor terminal, and pushes the acquired streaming media to the receiving terminal of the live broadcast platform in real time through the streaming address.

Drawing flow: the live streaming refers to a process of pulling the live streaming from a source station specified by a user through a live streaming cloud platform.

CDN (Content delivery network): the CDN is a content delivery network constructed on the network, and the basic principle of the CDN is that various cache servers are widely adopted and distributed to a region or a network where user access is relatively concentrated, when a user accesses a website, the access of the user is directed to the cache server which is closest to the cache server and works normally by using a global load technology, and the cache server directly responds to a user request, so that the access response speed and the hit rate of the user are improved. The key technologies of the CDN mainly include a content storage technology, a content delivery technology, and a load balancing technology.

Code rate: the bit number of data transmitted in unit time during data transmission, and the code rate is also called bit rate, which indicates how many bits are needed to represent audio and video data after compression and encoding per second, that is, the data amount after compressing an image displayed per second, generally adopts the unit of kbps, namely kilobits per second. The popular understanding is that the sampling rate is higher, the higher the sampling rate in unit time is, the higher the precision is, the closer the processed file is to the original file, that is, the more the details of the picture are rich.

Edge operation: the distributed computing architecture is also called edge computing, and is a distributed computing architecture, in which the computation of application programs, data and services is moved from a central node of the network to an edge node of the network logic for processing. That is, edge operations can decompose large services originally handled completely by the central node, cut them into smaller and more manageable parts, and distribute them to the edge nodes for processing. The edge node is closer to the user terminal device, so that the processing and transmission speed of the data can be increased, and the delay can be reduced. The edge nodes in the method can be small plug flow nodes deployed all over the country, and the cost is low.

DNS resolution: is a service that points domain names to a web space IP so that the web site can be conveniently accessed through the registered domain names. People are used to memorize domain names, but machines only recognize IP addresses, the domain names and the IP addresses are in one-to-one correspondence, the conversion work between the machines is called domain name resolution, the domain name resolution needs to be completed by a special domain name resolution server, and the whole process is automatically carried out.

Next, an application scenario of the present application is introduced.

In the existing live broadcast system, a link from a main broadcast end to a user end is very long, influence factors are various, and any link has a problem, which can cause the live broadcast watched by a user to be blocked or incapable of being watched. The user can contact the customer service feedback problem under the condition that the live broadcast is blocked or cannot be watched, so that how to timely process various feedbacks of the user is realized, different results are responded according to different feedbacks, and the method has an important effect on optimizing user experience and timely finding hidden dangers.

In the current customer service processing flow, generally, a user feeds back a problem to a customer service through a user side owned by the user, the customer service enters a feedback work order, waits for a conclusion given by a related research and development staff, and then feeds back the result to the user through the customer service.

However, the flow causing the live broadcast to be blocked or incapable of being watched is complex, research and development personnel are required to eliminate each link one by one, and finally the reason of the live broadcast abnormity is determined.

In addition, after a single user side feeds back, troubleshooting analysis is performed on the problem fed back by the single user side, and only the problem encountered by the single user side can be simply found and solved, but if a problem occurs in a certain link in the stream pushing process, most users are likely to be affected, so that analysis is performed on the feedback of the single user side to determine the reason of the live broadcast abnormity, the universality is not always realized, the actual reason of the live broadcast abnormity cannot be determined, the real problem cannot be responded in time and solved, and certain loss is brought.

Therefore, the client service feedback work order can be automatically docked, each link of live broadcast is automatically processed and judged by utilizing the user feedback log and combining the stuck statistical system, whether each link is abnormal or not is statistically analyzed in real time, influence factors can be comprehensively judged, and the substantial cause of stuck is found, so that the feedback result is given in a short time, and large-area feedback is reduced.

The present application also relates to a server for determining a reason of live broadcast exception, a computing device, and a computer-readable storage medium, which are described in detail in the following embodiments one by one.

Fig. 1 shows a flowchart of a method for determining a reason for a live broadcast exception according to an embodiment of the present application, which specifically includes the following steps:

step 102: and under the condition of meeting the detection condition of the server, acquiring the live broadcast stream in the edge node, and determining whether the live broadcast abnormity comprises a first reference reason or not according to the quality of the live broadcast stream.

Specifically, the server detection condition is a condition that whether the server is abnormal needs to be detected and analyzed, and if the user side does not determine the abnormality, the probability is that the server is abnormal, which causes live broadcast blockage, and therefore, under the condition that the user side is not determined to be abnormal, the server detection condition is satisfied, and the server can be further detected deeply, that is, the server detection condition can be that the user side is not determined to be abnormal; or, if a large number of users feedback abnormality in a short time, it indicates that a large probability may be that the server side has abnormality, and a large area of the user side is affected, and at this time, it indicates that the server side detection condition is satisfied, and deep detection can be further performed on the server side, that is, the server side detection condition may be that the number of users initiating abnormal feedback in a preset time length is too large.

Fig. 2 is a schematic diagram of an overall link of an anchor push stream according to an embodiment of the present application, and as shown in fig. 2, an anchor side pushes acquired multimedia data to an edge node 1 (corresponding to the link 1), and the edge node 1 respectively forwards a received live stream to a CDNA (corresponding to the link 2) and a CDN B (corresponding to the link 3). The edge node a1 in the CDNA performs internal forwarding, that is, the edge node a1 internally forwards the live stream to the service node a2 (corresponding to the link 4a) and the service node A3 (corresponding to the link 4b), so that the live stream in the service node a2 is viewed by the user 1 (that is, the user side pull stream corresponding to the user 1 corresponds to the link 5), and the live stream in the service node A3 is viewed by the user 2 (that is, the user side pull stream corresponding to the user 2 corresponds to the link 6). An edge node B1 in the CDN B performs internal forwarding, that is, the edge node B1 internally forwards the live stream to a service node B2 (corresponding to the link 4c) and a service node B3 (corresponding to the link 4d), the live stream in the service node B2 is provided for the user 3 to view (that is, the user side pull stream corresponding to the user 3 corresponds to the link 7), and the live stream in the service node B3 is provided for the user 4 to view (that is, the user side pull stream corresponding to the user 4 corresponds to the link 8).

It should be noted that, from the link shown in fig. 2, it can be determined that the factors that may affect the live broadcast, which are the factors that the user end itself may watch from the main broadcast end: (1) the DNS of the user side is abnormal, and the service node in the CDN cannot be obtained through analysis, so that live broadcast cannot be watched; (2) the network of the user side is abnormal, the network speed is too low, the bandwidth for live broadcast watching is not enough, and finally the live broadcast is blocked, namely links 5, 6, 7 and 8 in fig. 2; (3) the performance of a user end is poor, and the user end equipment used by the user is aged or the performance of the equipment is poor, so that the encoding and decoding are abnormal, and further the live broadcast is blocked. Non-user side issues: (4) the push streaming network of the anchor end has problems, and the push streaming network is too poor, so that the quality of pushed streaming data is problematic, and the live broadcast watched by a user has problems, namely a link 1 in fig. 2; (5) the problem exists in the network where the edge node is forwarded to the CDN node, namely link 2 in fig. 2; (6) the CDN service nodes have problems with service nodes a2, A3, B2, B3 in fig. 2; (7) the problem of the area where the user side is located, the problem occurs to provincial operators (mostly small operators) where the user side is located, and a large-area network is not available; (8) the method comprises the following steps that a transcoding stream has problems, a live stream watched by a user side is the transcoding stream, after the user pulls the stream, if the code rate is too high and the number of people watched is large, a main broadcasting end starts transcoding to provide multi-path definition for selection, and under the condition that the user side pulls the stream without problems, the transcoding stream causes the watched live stream to be blocked, and the transcoding stream possibly has problems; (9) the CDN service provider has a problem, and after accessing multiple CDN service providers, a single CDN service provider may also have a problem with the pull-stream viewing service of the CDN, thereby affecting user viewing in a large range.

In practical application, a user can feed back to a customer service through a user side used for watching live broadcast and problems are met when the user watches live broadcast in a stuck state or cannot watch the live broadcast, after the customer service receives feedback of the user side, the customer service can be guided to submit stuck logs through the user side used, the customer service actively initiates a flow for determining the reason of live broadcast abnormity, the flow can be divided into 2 parts, one part is to analyze the user side to determine whether the user side is abnormal, the other part is to analyze a deeper server side to determine whether each link of the server side is abnormal, and finally comprehensive judgment is carried out to determine the actual reason of live broadcast stuck.

In an optional implementation manner of this embodiment, before performing deeper analysis on the server, the method may further include, before analyzing the client with abnormal feedback to determine whether the client is abnormal, that is, before acquiring the live stream in the edge node under the condition that the detection condition of the server is satisfied, the method further includes:

under the condition of receiving an abnormal detection request, acquiring log data of a target user side corresponding to the abnormal detection request;

and analyzing the target user side according to the log data.

Specifically, the anomaly detection request may be a request initiated by the customer service through a preset operation, and the anomaly detection request may enable the central service to automatically interface with the customer service to feed back the work order, and obtain log data of the target user side that feeds back the anomaly to the customer service, so as to analyze the log data of the target user side and determine whether the target user side is anomalous. The preset operation may be a click operation of the detection control, and the target user side may be a user side that gives feedback to the customer service about the abnormality.

It should be noted that, when a user watches live broadcast through a target user side owned by the user, if the live broadcast is blocked or cannot be watched, the user can feed back an abnormal condition to a customer service through the target user side owned by the user, the customer service can guide the target user side to submit blocked log data, then the customer service can initiate an abnormal detection request through a preset operation, and when the customer service initiates the abnormal detection request, the customer service can carry an identifier of the target user side fed back abnormally in the abnormal detection request, so that the central service can obtain the log data of the target user side corresponding to the abnormal detection request and analyze the log data, thereby determining whether the target user side is abnormal.

In addition, except that the user side feeds back the abnormity to the customer service and then the customer service initiates an abnormity detection request, the user side can also directly feed back the abnormity to the central service, namely the user side initiates the abnormity detection request and submits the log data of the live broadcast card thereof, so that the central service directly analyzes the log data and determines whether the target user side has abnormity.

In an optional implementation manner of this embodiment, the central service may specify, in advance, abnormal fields corresponding to various abnormalities with a player of the user side, when the player of the user side monitors that a certain abnormality occurs in a live broadcast playing process of the user side, at this time, a corresponding abnormal field may be added to log data of the user side, after the central service acquires the log data, it is only necessary to search whether the abnormal field exists, and it may be determined whether the user side has an abnormality, that is, the target user side is analyzed according to the log data, and a specific implementation process may be as follows:

determining whether a preset abnormal field exists in the log data;

and under the condition that the preset abnormal field exists in the log data, determining and feeding back the user side reason of the live broadcast abnormality according to the abnormal field.

It should be noted that the preset exception field is a field corresponding to various exceptions that the central service has agreed with the player at the user side in advance. For example, the default exception field corresponding to the network exception of the user side is AA, the default exception field corresponding to the DNS resolution exception of the user side is BB, and the default exception field corresponding to the poor performance of the user side is CC.

In practical application, after the central service acquires the log data submitted by the target user side, the central service can automatically search and analyze the log data, determine whether a preset abnormal field exists in the log data, determine that the target user side is abnormal under the condition that the preset abnormal field is searched, determine the specific abnormality of the target user side (namely the reason of the abnormal live user side) according to the abnormal field, and perform record feedback according to the specific abnormality reason.

It should be noted that, if the user-side reason for the live broadcast abnormality is determined for the target user side, it is indicated that the target user side is abnormal, and at this time, the specific abnormality of the determined target user side can be summarized and recorded, and a corresponding solution can be provided. Therefore, one user side submits the live complaint, and if the abnormal condition is determined to be abnormal by the user side according to the analysis of the log data, the abnormal report can be directly fed back to the user side to inform the abnormal reason and timely respond and solve the complaint, so that the complaint response speed is improved, and repeated complaints caused by untimely response or self network reasons are reduced.

If the found preset abnormal field is AA, the network of the target user side is abnormal, and the analysis result of the target user side is recorded as a network problem; if the found preset abnormal field is BB, indicating that DNS analysis of the target user side is abnormal, and recording an analysis result of the target user side as a DNS analysis problem; if the found preset abnormal field is CC, the performance of the target user side is poor, the analysis result of the target user side is recorded as the problem of the equipment, and equipment switching is suggested.

In an optional implementation manner of this embodiment, before acquiring the live stream in the edge node under the condition that the server detection condition is satisfied, the method further includes:

and determining that the server side detection condition is met under the condition that the preset abnormal field does not exist in the log data.

It should be noted that, when the preset abnormal field does not exist in the log data, it is indicated that the target user side does not have an abnormality, and at this time, the server side has an abnormality with a high probability, which causes a live broadcast jam, and at this time, it is necessary to further analyze in a deep level whether the server side has an abnormality, that is, the server side detection condition is satisfied at this time.

determining the number of received abnormal detection requests in a preset time before the current time;

and determining that the server side detection condition is met under the condition that the number of the abnormal detection requests exceeds an abnormal number threshold value.

Specifically, the preset time duration refers to a preset time duration, and the preset time duration is generally set to be shorter, and can be 1 minute, 2 minutes, 3 minutes and the like; the abnormal number threshold is a preset value, and is used for determining whether the abnormal detection requests received within a preset time period are excessive, for example, the abnormal number threshold may be 50, 100, 500, or the like.

It should be noted that after receiving a single feedback abnormality of the target user terminal, if it is determined that the target user terminal is abnormal, the feedback abnormality can be directly fed back to the target user terminal. In addition, whether the target user side is determined to have abnormality or not, if a large number of abnormality detection requests are received within a preset time, it is indicated that a large number of users have problems in the short time when watching the live broadcast, and at this time, the server side is most likely to have abnormality and a large-area user side is affected, so that the server side detection conditions are determined to be met at this time, and whether the server side has abnormality or not can be further deeply analyzed subsequently.

In an optional implementation manner of this embodiment, an edge node is configured to receive a live stream pushed by a main terminal, and push the received live stream to a node in a corresponding content distribution network, so that there are two live streams in the edge node, and it may be determined whether there is an abnormality in the corresponding node according to qualities of the two live streams, that is, a live stream in the edge node is obtained, and it is determined whether the live stream abnormality includes a first reference reason according to the quality of the live stream, where the method includes at least any one of the following:

acquiring a live stream received by the edge node, and determining that the live stream abnormality comprises the first reference reason under the condition that the quality of the received live stream is lower than a quality threshold, wherein the first reference reason is a main broadcast network abnormality;

and acquiring a live broadcast stream sent by the edge node, and determining that the live broadcast exception comprises the first reference reason under the condition that the quality of the sent live broadcast stream is lower than a quality threshold, wherein the first reference reason is the edge node exception.

Specifically, an edge node refers to a node that receives a live stream from a main broadcast end, and the edge node may push the received live stream to different Content Delivery Networks (CDNs). In addition, the quality of the live stream may refer to the definition of the live stream, may also refer to the fluency of the live stream, and may also be other parameters that may indicate the quality of the live stream, which is not limited in the present application; the quality threshold may be a preset value, and the quality threshold is used to determine whether the quality of the live broadcast stream is poor, and different quality metrics may correspond to different quality thresholds.

It should be noted that, it may be determined whether an abnormality exists in the process of pushing the live stream by the anchor terminal according to the quality of the live stream received by the edge node, and when the quality of the live stream received by the edge node is lower than a quality threshold, it indicates that the quality of the live stream pushed to the edge node by the anchor terminal is poor, and at this time, it indicates that the live stream network may have a problem, so that it is determined that the first reference reason for the abnormality in the live stream is the abnormality in the anchor network.

In addition, whether the process of pushing the live stream by the edge node is abnormal or not can be determined according to the quality of the live stream pushed by the edge node, and under the condition that the quality of the live stream pushed by the edge node is lower than a quality threshold value, the quality of the live stream pushed by the edge node is poor, and at the moment, the edge node possibly has problems, so that the first reference reason for the abnormal live stream is determined to be the abnormal edge node.

According to the method and the device, under the condition that the detection condition of the server is met, the live stream received and/or sent out in the edge node is obtained, and then whether the abnormality exists in the anchor terminal and/or whether the abnormality exists in the edge node is determined according to the quality of the obtained live stream, so that the reason of the server with the abnormal live stream is automatically, efficiently and accurately determined.

Step 104: and acquiring the pause information reported by the user side from the pause statistical system, and determining whether the live broadcast abnormity comprises a second reference reason or not according to the pause information.

It should be noted that the live broadcast player in the user side can automatically monitor each watching behavior of the user, and if the live broadcast is stuck in the watching process of the user, the user side can automatically report stuck information to the stuck statistical system, where the reported stuck information may include: the live broadcast stream to be watched, the watching time, the service node in the content distribution network corresponding to the pull stream, the service provider of the content distribution network, the operator used by the user to access the live broadcast, the area where the user is located, and the like.

In addition, after receiving the pause information reported by each user, the pause statistical system can calculate the corresponding pause rate from different dimensions, wherein the pause rate is equal to the pause times of unit time divided by the playing time length.

In an optional implementation manner of this embodiment, each user may report the morton information to the morton statistical system when the live broadcast is morton or cannot be watched, so that the morton information reported by each user may be stored in the morton statistical system, and when it is necessary to analyze the server, and it is determined whether the server is abnormal, it is possible to determine whether the corresponding node is abnormal by obtaining the corresponding morton information from the morton statistical system, that is, obtaining the morton information reported by the user from the morton statistical system, and according to the morton information, determining whether the live broadcast abnormality includes the second reference reason, where the method includes at least any one of the following:

determining a target service node in a content distribution network accessed by the user side, acquiring a pause reporting number aiming at the target network node in a preset counting period from the pause counting system, and determining that the live broadcast abnormity comprises the second reference reason under the condition that the pause reporting number is greater than a reporting threshold value, wherein the second reference reason is the abnormity of the target service node;

under the condition that the live stream accessed by the user side is determined to be a target code rate live stream obtained through transcoding, acquiring a pause rate of an original code rate live stream and a pause rate of the target code rate live stream in a preset counting period from the pause counting system, and under the condition that a pause rate difference value between the pause rate of the target code rate live stream and the pause rate of the original code rate live stream is greater than a difference threshold value, determining that the live broadcast abnormity comprises a second reference reason, wherein the second reference reason is that the target code rate live stream is abnormal;

determining a region and an operator where the user side is located when accessing live broadcast, obtaining a pause rate corresponding to the region in a current preset statistical period from the pause statistical system, calculating a pause growth rate of the current preset statistical period relative to a last preset statistical period, and determining that the live broadcast abnormality comprises the second reference reason and the second reference reason is abnormal because of the operator under the condition that the pause growth rate is greater than a growth rate threshold;

determining a content distribution network service provider accessed by the user side, obtaining a pause rate corresponding to the content distribution network service provider in a current preset statistical period from the pause statistical system, calculating a pause growth rate of the current preset statistical period relative to a last preset statistical period, and determining that the live broadcast abnormality comprises the second reference reason under the condition that the pause growth rate is greater than a growth rate threshold value, wherein the second reference reason is the content distribution network service provider abnormality.

Specifically, the service node refers to a node that provides a live stream to a user terminal in a content distribution network. The preset statistical period is a preset time period, and whether a node is abnormal or not can be determined by analyzing the stuck information in the time period, for example, the preset statistical period may be 5 minutes or 10 minutes, or 1 hour or 2 hours. In addition, the source code rate direct broadcast stream refers to a code rate direct broadcast stream pushed by the anchor side, and the target code rate direct broadcast stream is a direct broadcast stream obtained by transcoding the source code rate direct broadcast stream.

In addition, the reporting threshold may be a preset value, and the value is used to determine whether the number of calton reports for a certain service node in a period of time is excessive, so as to determine whether the service node is abnormal. The difference threshold may be a preset value, and the value is used to determine whether the pause rate of the target-rate live stream obtained by transcoding within a period of time is greater than the pause rate of the source-rate live stream, so as to determine whether the target-rate live stream obtained by transcoding is abnormal.

It should be noted that, since the morton statistical system receives the morton information reported by the multiple clients within the preset statistical period, the morton information reported by each client in the morton statistical system can be analyzed in different dimensions, so as to determine the reason for the live broadcast abnormality from different dimensions.

In practical application, if a large number of hiton reports occur for a certain target service node in a content distribution network, a problem exists in the target service node due to a high probability, and therefore it can be determined that the second reference reason for the live broadcast abnormality is the abnormality of the target service node.

Along the above example, as shown in fig. 2, the central service reads that the user side accesses the service node a2 in the CDN, and then may query from the katon statistical system, and in a preset statistical period, it indicates that the service node a2 is abnormal, and the user side accessing the service node has a problem, for whether a large number of katon reports occur to the service node a 2.

In addition, after the user side pulls the stream, if the code rate is too high, the number of people watching the stream is more, the anchor side can start transcoding to provide multi-path definition for selection, and under the condition that the source stream pulled by the user side has no problem, the transcoded stream possibly causes the watching live broadcast to be blocked, so that when the live broadcast stream accessed by the user side is determined to be the target code rate live broadcast stream obtained by transcoding, the blockage rate of the source code rate live broadcast stream and the blockage rate of the target code rate live broadcast stream in a preset statistical period can be obtained from a blockage statistical system, whether the blockage rate of the target code rate live broadcast stream is far greater than that of the source code rate live broadcast stream or not is determined, if yes, the target code rate live broadcast stream obtained after the statistics is shown, and namely the second reference reason for the live broadcast abnormality is determined to be the target code rate stream abnormality.

Furthermore, the central service can also read an operator used by the user side when the user side accesses the live broadcast, determine a region where the user side is located when the user side accesses the live broadcast, then query the operator from the card pause statistical system, determine the card pause rates of all live broadcast streams in the region in the current preset statistical period, and determine the card pause rates of all live broadcast streams in the region in the last preset statistical period, thereby calculating the card pause growth rate in the region, and if the card pause growth rate steeply increases in the current preset statistical period, it indicates that the service of the operator has a problem in the current preset statistical period, that is, the determined second reference reason for the abnormal live broadcast is abnormal because the operator is abnormal.

In addition, if the card pause rate reported by a certain content distribution network service provider is suddenly increased within a period of time, the probability indicates that the content distribution network service provider has a problem, so the central service can also inquire from the card pause statistical system, calculate the card pause growth rate of the content distribution network service provider by inquiring all the card pause rates reported by the content distribution network service provider in the current preset statistical period and all the card pause rates reported by the content distribution network service provider in the last preset statistical period, and indicate that the service of the content distribution network service provider may have a problem in the current preset statistical period if the card pause growth rate is suddenly increased in the current preset statistical period, that is, the determined second reference reason of the live broadcast abnormality is the content distribution network service provider abnormality.

According to the method and the device, under the condition that detection conditions of the server are met, the card pause information reported by each user side in the card pause statistical system can be analyzed and counted according to different dimensions, and the reason of the live broadcast abnormity is determined according to different dimensions, so that the reason of the server with the live broadcast abnormity can be automatically, efficiently and accurately determined.

It should be noted that, the above-mentioned step 104 is described after the step 102, and is only an exemplary description sequence, in practical applications, the above-mentioned step 102 obtains the live stream in the edge node, determines a first reference reason of the live stream abnormality according to the quality of the live stream, and obtains the hiton information reported by the user end from the hiton statistical system in the step 104, and determines a second reference reason of the live stream abnormality according to the hiton information, and there may be no precedence order relationship in execution, and the execution may be performed concurrently, or may be sequential detection, that is, the step 102 is executed first, and then the step 104 is executed, or certainly, the step 104 is executed first, then the step 102 is executed, which is not limited in this application.

Step 106: and under the condition that the live broadcast abnormity comprises the first reference reason and/or the second reference reason, determining a server-side reason of the live broadcast abnormity according to the first reference reason and/or the second reference reason.

In an optional implementation manner of this embodiment, the server cause of the live broadcast abnormality is determined according to the first reference cause and/or the second reference cause, and a specific implementation process may be as follows:

merging the first reference reason and/or the second reference reason;

and determining the merged first reference reason and/or second reference reason as a server-side reason of the live broadcast abnormity.

It should be noted that, it may be determined whether the live broadcast abnormality includes a first reference reason according to the edge node, and it may be determined whether the live broadcast abnormality includes a second reference reason according to the hiton information reported by the user side in the hiton statistical system, and in the case that it is determined that the live broadcast abnormality includes the first reference reason and/or the second reference reason, all the determined reference reasons may be directly used as the last server side reason of the live broadcast abnormality for feedback and processing.

determining a target reference cause of the first reference cause and/or the second reference cause;

and determining the target reference reason as a server-side reason of the live broadcast abnormity.

It should be noted that, the number of the clients that can be affected by the determined first reference reason and/or second reference reason is different, that is, the degrees of the influence of the live broadcast abnormality are different, so that when it is determined that the live broadcast abnormality includes the first reference reason and/or the second reference reason, the target reference reason reflecting the deepest degree of the live broadcast abnormality may be determined as the last server reason of the live broadcast abnormality.

As an example, it is determined that the second reference reason is an operator anomaly, and it is further determined that the second reference reason is a content distribution network service provider anomaly, since the operator anomaly affects all user terminals (without limiting the operator) using the operator, and the content distribution network service provider anomaly affects all user terminals (without limiting the operator) using the content distribution network service provider, the content distribution network service provider anomaly has a deeper influence on the live broadcast process, and thus the operator anomaly may be an appearance, and the content distribution network service provider anomaly is a substance, at this time, the content distribution network service provider anomaly may be determined as the last service end reason of the live broadcast anomaly, and feedback and processing may be performed.

In an optional implementation manner of this embodiment, determining, according to the first reference reason and/or the second reference reason, a server reason of the live broadcast abnormality includes:

under the condition that the live broadcast abnormity is determined to comprise any first reference reason or second reference reason, stopping continuously executing the operation step of determining whether the live broadcast abnormity comprises other first reference reasons or second reference reasons;

and determining the first reference reason or the second reference reason included by the determined live broadcast abnormity as the server side reason of the live broadcast abnormity.

It should be noted that when it is determined that the live broadcast abnormality includes any reference reason, the continuous detection may be stopped, that is, if any abnormality is matched to the server, the continuous detection is stopped to detect whether other abnormality exists in the server. And taking the determined reference reason as the reason of the last server side with abnormal live broadcast, and feeding back and processing the reason.

Furthermore, after the user side reason and the server side reason of the live broadcast abnormity are determined, different processing measures can be adopted according to different reasons to perform different feedbacks. During specific implementation, if it is determined that a single user side is abnormal, a corresponding report can be provided for the single user side, the complaint response speed is improved, and repeated complaints caused by untimely response or self network reasons are reduced.

If the reason that the server side with the abnormal live broadcast is determined to be the network abnormality of the anchor side, the push flow abnormality of the anchor side can be returned to the customer service, the customer service is informed to contact the anchor, and the push flow quality is adjusted; if the reason that the server side with the abnormal live broadcast is determined to be the edge node abnormality, the center service can actively inform the edge computing node, disconnect the forwarding, reinitiate the connection, return the processed data to the customer service and ask the user to refresh and retry; and if the reason that the server side with the abnormal live broadcast is determined to be the abnormal target service node, automatically feeding the target service node back to the content distribution network service provider, informing the opposite side to remove the abnormal service node, returning the processed service node to the customer service provider, and asking the user to refresh and retry.

If the reason that the server side with the abnormal live broadcast is determined to be the abnormal target code rate live broadcast stream, automatically feeding back the abnormal target code rate live broadcast stream information to developers, and simultaneously returning back to a customer service to suggest a user to switch the watching in a clear manner; if the reason that the server side with the abnormal live broadcast is determined to be abnormal by the operator, the server side returns a suggestion that the user contacts the operator for solving or switches the network to the customer service; if the reason that the server side with the abnormal live broadcast is determined to be the abnormal content distribution network service provider, the content distribution network service provider can be informed to determine whether the service is normal or not, the abnormal content distribution network service provider is returned to the customer service, and the customer service provider is required to retry the abnormal content distribution network service provider later.

In an optional implementation manner of this embodiment, after determining, according to the first reference reason and/or the second reference reason, the server reason for the live broadcast abnormality further includes:

recording the abnormity determining time for determining the reason of the server side with abnormal live broadcast;

determining a reception time of a new anomaly detection request in case of receiving the new anomaly detection request;

determining whether a time difference between the reception time and the abnormality determination time is less than a time threshold;

and if so, determining an abnormal reason corresponding to the new abnormal detection request according to the determined reason of the abnormal live broadcast server.

Specifically, the time threshold is a preset value, and is used to determine whether the difference between the received new anomaly detection request and the anomaly determination time is large, that is, whether the received new anomaly detection request is received within a preset time period.

It should be noted that, after the reason for the live broadcast abnormality is located to the reason for the certain service end, for the user feedback or complaint newly received within the preset time, after determining whether the user end has an abnormality, the located reason for the service end can be preferentially detected, so as to improve the detection efficiency.

For example, if the reason for the live broadcast abnormality is determined to be that the content distribution network service provider is abnormal according to the feedback of the plurality of user terminals, after newly receiving user feedback within 10 minutes (i.e., within a preset time), the user terminal corresponding to the newly received user feedback is first detected, and if the user terminal is not abnormal, whether the content distribution network service provider is abnormal or not is preferentially detected.

Next, an overall flow of the live broadcast abnormality determining method is schematically described with reference to fig. 3, where fig. 3 is a schematic diagram of a determining process of a live broadcast abnormality cause according to an embodiment of the present application. As shown in fig. 3, after the customer service initiates the detection process, the first part may detect a problem at the user end, including determining whether to include a device exception field, determining whether to include a network exception field, and determining whether to include a DNS resolution exception field. The second part can carry out deep-level service end detection, including determining whether a push flow end has a problem, determining whether a forwarding link has a problem, determining whether a CDN node has a problem, determining whether a forwarding stream has a problem, determining whether a regional operator has a problem, and determining whether a CDN service provider has a problem. Therefore, based on the detection of the two parts, the conclusion of the live broadcast abnormity is given.

The method for determining the reason of the live broadcast abnormity comprises the steps of acquiring a live broadcast stream in an edge node under the condition that a server side detection condition is met, and determining whether the live broadcast abnormity comprises a first reference reason or not according to the quality of the live broadcast stream; acquiring pause information reported by a user side from a pause statistical system, and determining whether the live broadcast abnormity comprises a second reference reason or not according to the pause information; and determining a server-side reason of the live broadcast abnormity according to the first reference reason and the second reference reason. Under the condition, data in the edge nodes and the cardon statistical system can be integrated, the server abnormity possibly occurring in the link of the client pushed by the anchor terminal is automatically processed and judged, so that the server reason of the live broadcast abnormity can be quickly determined in a short time, a feedback result is given, the processing time is greatly saved, the efficiency of determining the reason of the live broadcast abnormity is improved, the response speed of the live broadcast abnormity is improved, research and development personnel do not need to eliminate each link one by one, the capability requirement on the research and development personnel is reduced, and the labor cost is saved. In addition, due to the fact that the pause information reported by the plurality of user sides in the pause statistical system can be combined, the abnormity of the service side can be analyzed and determined, the substantial reason of the problems of the live broadcast can be analyzed from the angle of the plurality of user sides, the accuracy of determining the reason of the abnormity of the live broadcast is improved, the abnormity of the service side can be timely processed, and most users are prevented from feeding back the same abnormity.

The method for determining the reason of the live broadcast abnormity comprises the steps of acquiring a live broadcast stream in an edge node under the condition that a server side detection condition is met, and determining whether the live broadcast abnormity comprises a first reference reason or not according to the quality of the live broadcast stream; acquiring pause information reported by a user side from a pause statistical system, and determining whether the live broadcast abnormity comprises a second reference reason or not according to the pause information; and under the condition that the live broadcast abnormity comprises the first reference reason and/or the second reference reason, determining a server-side reason of the live broadcast abnormity according to the first reference reason and/or the second reference reason. Under the condition, under the condition that an abnormity detection request is received, a user side can be detected firstly to determine whether the user side is abnormal or not, then under the condition that a service side detection condition is met, data in an edge node and a stuck statistical system are further integrated, automatic processing is carried out to judge whether the main broadcast side pushes a flow to a user side pull flow link, the service side is abnormal possibly, the user side and the service side reason of the live broadcast abnormity can be rapidly determined in a short time, a feedback result is given, processing time is greatly saved, efficiency of determining the reason of the live broadcast abnormity is improved, response speed of the live broadcast abnormity is improved, research and development personnel do not need to eliminate all links one by one, the capacity requirement on the research and development personnel is reduced, and labor cost is saved. In addition, due to the fact that the pause information reported by the plurality of user sides in the pause statistical system can be combined, the abnormity of the service side can be analyzed and determined, the substantial reason of the problems of the live broadcast can be analyzed from the perspective of the plurality of user sides, the complaint problem can be fundamentally solved, the accuracy of determining the reason of the abnormity of the live broadcast is improved, the abnormity of the service side can be timely processed, and the same abnormity fed back by most users can be avoided.

Fig. 4 is a flowchart illustrating another method for determining a reason for a live broadcast abnormality according to an embodiment of the present application, which specifically includes the following steps:

step 402: under the condition of receiving an abnormal detection request, acquiring log data of a target user side corresponding to the abnormal detection request, and determining whether a preset abnormal field exists in the log data.

Step 404: and under the condition that the preset abnormal field exists in the log data, determining and feeding back the user side reason of the live broadcast abnormality according to the abnormal field.

Step 406: under the condition that the preset abnormal field does not exist in the log data, acquiring a live broadcast stream in an edge node, and determining whether the live broadcast abnormality comprises a first reference reason or not according to the quality of the live broadcast stream; and acquiring pause information reported by the user side from the pause statistical system, and determining whether the live broadcast abnormity comprises a second reference reason or not according to the pause information.

Step 408: and under the condition that the live broadcast abnormity comprises the first reference reason and/or the second reference reason, determining a server-side reason of the live broadcast abnormity according to the first reference reason and/or the second reference reason.

According to the method for determining the reason of the live broadcast abnormity, under the condition that an abnormity detection request is received, the user side can be detected firstly, whether the user side is abnormal or not is determined, then under the condition that the detection condition of the service side is met, data in the edge node and the stuck statistical system are further integrated, automatic processing is conducted, the fact that the main broadcast side pushes and flows to a pull-flow link of the user side is judged, the possible abnormality of the service side is caused, the reason of the user side and the service side which are abnormal in the live broadcast is rapidly determined in a short time, a feedback result is given, processing time is greatly saved, the efficiency of determining the reason of the abnormal live broadcast is improved, the response speed of the abnormal live broadcast is improved, all links do not need to be eliminated by research and development personnel one by one, the capability requirement of research and development personnel is. In addition, due to the fact that the pause information reported by the plurality of user sides in the pause statistical system can be combined, the abnormity of the service side can be analyzed and determined, the substantial reason of the problems of the live broadcast can be analyzed from the perspective of the plurality of user sides, the complaint problem can be fundamentally solved, the accuracy of determining the reason of the abnormity of the live broadcast is improved, the abnormity of the service side can be timely processed, and the same abnormity fed back by most users can be avoided.

The foregoing is an exemplary scheme of a method for determining a reason for live broadcast abnormality in this embodiment. It should be noted that the technical solution of the method for determining a reason for a live broadcast abnormality belongs to the same concept as the technical solution of the method for determining a reason for a live broadcast abnormality shown in fig. 1, and details of the technical solution of the method for determining a reason for a live broadcast abnormality shown in fig. 4, which are not described in detail, can be referred to the description of the technical solution of the method for determining a reason for a live broadcast abnormality shown in fig. 1.

Corresponding to the above method embodiment, the present application further provides an embodiment of a server for determining a reason of live broadcast exception, and fig. 5 shows a schematic structural diagram of a server for determining a reason of live broadcast exception provided by an embodiment of the present application. As shown in fig. 5, the server includes:

a first obtaining module 502, configured to obtain a live stream in an edge node when a server detection condition is met, and determine whether a live broadcast exception includes a first reference reason according to quality of the live stream;

a second obtaining module 504, configured to obtain the hiton information reported by the user side from the hiton statistical system, and determine whether the live broadcast abnormality includes a second reference reason according to the hiton information;

a first determining module 506, configured to determine, according to the first reference reason and/or the second reference reason, a server-side reason of the live broadcast abnormality when it is determined that the live broadcast abnormality includes the first reference reason and/or the second reference reason.

Optionally, the first obtaining module 502 is further configured to at least any one of:

acquiring a live stream received by the edge node, and determining that the live stream abnormality comprises the first reference reason under the condition that the quality of the received live stream is lower than a quality threshold, wherein the first reference reason is an abnormality of a main broadcasting end;

Optionally, the second obtaining module 504 is further configured to at least any one of:

determining a target service node in a content distribution network accessed by the user side, acquiring a pause reporting number aiming at the target service node in a preset statistical period from the pause statistical system, and determining that the live broadcast abnormity comprises the second reference reason under the condition that the pause reporting number is greater than a reporting threshold value, wherein the second reference reason is the abnormity of the target service node;

Optionally, the first determining module 506 is further configured to:

merging the first reference reason and/or the second reference reason;

Optionally, the first determining module 506 is further configured to:

Optionally, the server further comprises an analysis module configured to:

and analyzing the target user side according to the log data.

Optionally, the analysis module is further configured to:

determining whether a preset abnormal field exists in the log data;

Optionally, the server further comprises a second determining module configured to:

Optionally, the server further comprises a third determining module configured to:

Optionally, the server further comprises a fourth determining module configured to:

The server for determining the reason of the live broadcast abnormity can detect the user side firstly under the condition of receiving the abnormity detection request, determine whether the user side is abnormal, then further synthesize data in the edge node and the stuck statistical system under the condition of meeting the detection condition of the service side, automatically process and judge that the main broadcast side pushes the stream to the pull stream link of the user side, the service side which possibly occurs is abnormal, thereby rapidly determining the reason of the user side and the service side which are abnormal in the live broadcast in a short time, giving a feedback result, greatly saving processing time, improving the efficiency for determining the reason of the abnormal live broadcast, improving the response speed of the abnormal live broadcast, eliminating each link one by one without research and development personnel, reducing the capability requirement on research and development personnel, and saving labor cost. In addition, due to the fact that the pause information reported by the plurality of user sides in the pause statistical system can be combined, the abnormity of the service side can be analyzed and determined, the substantial reason of the problems of the live broadcast can be analyzed from the perspective of the plurality of user sides, the complaint problem can be fundamentally solved, the accuracy of determining the reason of the abnormity of the live broadcast is improved, the abnormity of the service side can be timely processed, and the same abnormity fed back by most users can be avoided.

The above is an illustrative scheme of the server for determining a reason for a live broadcast abnormality in this embodiment. It should be noted that the technical solution of the server for determining the reason for the live broadcast abnormality and the technical solution of the method for determining the reason for the live broadcast abnormality belong to the same concept, and details of the technical solution of the server for determining the reason for the live broadcast abnormality, which are not described in detail, can be referred to in the description of the technical solution of the method for determining the reason for the live broadcast abnormality.

Fig. 6 illustrates a block diagram of a computing device 600 provided according to an embodiment of the present application. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is coupled to the memory 610 via a bus 630 and a database 650 is used to store data.

Computing device 600 also includes access device 640, access device 640 enabling computing device 600 to communicate via one or more networks 660. Examples of such networks include the Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the internet. Access device 640 may include one or more of any type of network interface (e.g., a Network Interface Card (NIC)) whether wired or wireless, such as an IEEE802.11 Wireless Local Area Network (WLAN) wireless interface, a worldwide interoperability for microwave access (Wi-MAX) interface, an ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a bluetooth interface, a Near Field Communication (NFC) interface, and so forth.

In one embodiment of the present application, the above-described components of computing device 600, as well as other components not shown in FIG. 6, may also be connected to each other, such as by a bus. It should be understood that the block diagram of the computing device architecture shown in FIG. 6 is for purposes of example only and is not limiting as to the scope of the present application. Those skilled in the art may add or replace other components as desired.

Computing device 600 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., tablet, personal digital assistant, laptop, notebook, netbook, etc.), mobile phone (e.g., smartphone), wearable computing device (e.g., smartwatch, smartglasses, etc.), or other type of mobile device, or a stationary computing device such as a desktop computer or PC. Computing device 600 may also be a mobile or stationary server.

Wherein processor 620 is configured to execute the following computer-executable instructions:

The above is an illustrative scheme of a computing device of the present embodiment. It should be noted that the technical solution of the computing device and the technical solution of the above method for determining a reason for a live broadcast abnormality belong to the same concept, and details that are not described in detail in the technical solution of the computing device can be referred to the description of the technical solution of the above method for determining a reason for a live broadcast abnormality.

An embodiment of the present application further provides a computer-readable storage medium, which stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the computer-executable instructions are used to implement any one of the steps of the method for determining a reason for a live broadcast abnormality.

The above is an illustrative scheme of a computer-readable storage medium of the present embodiment. It should be noted that the technical solution of the storage medium and the technical solution of the above method for determining a reason for a live broadcast abnormality belong to the same concept, and details that are not described in detail in the technical solution of the storage medium can be referred to in the description of the technical solution of the above method for determining a reason for a live broadcast abnormality.

The foregoing description of specific embodiments of the present application has been presented. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The computer instructions comprise computer program code which may be in the form of source code, object code, an executable file or some intermediate form, or the like. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.

It should be noted that, for the sake of simplicity, the above-mentioned method embodiments are described as a series of acts or combinations, but those skilled in the art should understand that the present application is not limited by the described order of acts, as some steps may be performed in other orders or simultaneously according to the present application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

The preferred embodiments of the present application disclosed above are intended only to aid in the explanation of the application. Alternative embodiments are not exhaustive and do not limit the invention to the precise embodiments described. Obviously, many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the application and its practical applications, to thereby enable others skilled in the art to best understand and utilize the application. The application is limited only by the claims and their full scope and equivalents.

Claims

1. A method for determining a reason for a live broadcast abnormality is characterized by comprising the following steps:

2. The method for determining the reason for the live broadcast abnormality according to claim 1, wherein the step of acquiring a live broadcast stream in an edge node, and determining whether the live broadcast abnormality includes a first reference reason or not according to the quality of the live broadcast stream includes at least any one of:

3. The method for determining the reason for the live broadcast abnormality according to claim 1, wherein the method for obtaining the pause information reported by the user side from the pause statistical system, and determining whether the live broadcast abnormality includes the second reference reason according to the pause information includes at least any one of the following:

4. The method for determining the reason for the live broadcast abnormality according to any one of claims 1 to 3, wherein determining the server-side reason for the live broadcast abnormality according to the first reference reason and/or the second reference reason includes:

merging the first reference reason and/or the second reference reason;

5. The method for determining the reason for the live broadcast abnormality according to any one of claims 1 to 3, wherein determining the server-side reason for the live broadcast abnormality according to the first reference reason and/or the second reference reason includes:

6. The method for determining the reason for the live broadcast abnormality according to any one of claims 1 to 3, wherein determining the server-side reason for the live broadcast abnormality according to the first reference reason and/or the second reference reason includes:

7. The method for determining the reason for the live broadcast abnormality according to any one of claims 1 to 3, wherein before acquiring the live broadcast stream in the edge node, when the server detection condition is satisfied, the method further includes:

and analyzing the target user side according to the log data.

8. The method for determining the reason for the live broadcast abnormality according to claim 7, wherein analyzing the target user side according to the log data includes:

determining whether a preset abnormal field exists in the log data;

9. The method for determining the reason for the live broadcast abnormality according to claim 8, wherein before acquiring the live broadcast stream in the edge node when the server detection condition is satisfied, the method further includes:

10. The method for determining the reason for the live broadcast abnormality according to claim 7, wherein before acquiring the live broadcast stream in the edge node when the server detection condition is satisfied, the method further includes:

11. The method for determining the reason for the live broadcast abnormality according to any one of claims 1 to 3, wherein after determining the reason for the server side of the live broadcast abnormality according to the first reference reason and the second reference reason, the method further includes:

12. A server for determining a cause of a live broadcast abnormality, comprising:

13. A computing device, comprising:

a memory and a processor;

14. A computer-readable storage medium storing computer-executable instructions which, when executed by a processor, implement the steps of the method for determining a cause of a live broadcast abnormality according to any one of claims 1 to 11.