Live reporting data processing method, device and computer equipment

Abstract

The present application relates to the field of computer technology, and provides a method, apparatus, and computer device for processing live broadcast reporting data. The method includes: receiving live broadcast reporting data sent by a viewing end, where the live broadcast reporting data includes first interface image data of the viewing end; when it is determined based on the live broadcast reporting data that a carding event occurs at the viewing end, determining, based on the first interface image data, the target terminal that causes the carding event and the carding reason, where the target terminal includes at least one of the viewing end and the host end, and the host end is the terminal corresponding to the live broadcast room where the viewing end is located when sending the live broadcast reporting data; sending a carding prompt message to the target terminal based on the carding reason, where the carding prompt message is used to prompt the target terminal of the carding reason that causes the carding event. The above method can analyze and determine whether the terminal that causes the carding event is the viewing end or the host end only based on the interface image of the viewing end, and determine the carding reason, and the efficiency of locating the reason for the live broadcast carding event is high.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device and computer equipment for processing live broadcast reporting data. Background Art

[0002] Live broadcast is a way of publishing information on the Internet that produces and releases information synchronously with the occurrence and development of events on the spot, with a two-way flow process. With the development of network technology, live broadcast has penetrated into various industries.

[0003] Affected by various factors, it is common for users to experience freezes when watching live broadcasts. Live broadcast freezes include but are not limited to situations where the live broadcast screen suddenly goes black or becomes unresponsive while the user is watching the live broadcast. Live broadcast freezes will bring a bad viewing experience to users. Therefore, when live broadcast freezes occur, the corresponding causes need to be analyzed in order to better provide live broadcast services to users. Summary of the invention

[0004] Based on this, it is necessary to provide a live broadcast reporting data processing method, device, computer equipment and storage medium that can automatically determine the cause of live broadcast freeze in response to the above technical problems.

[0005] A method for processing live broadcast report data, the method comprising:

[0006] Receiving live broadcast reporting data sent by a viewing terminal, wherein the live broadcast reporting data includes first interface image data of the viewing terminal;

[0007] When it is determined based on the live broadcast report data that a freeze event occurs on the viewing end, a target terminal causing the freeze event and a freeze cause are determined based on the first interface image data, wherein the target terminal includes at least one of the viewing end and the anchor end, wherein the anchor end is a terminal corresponding to the live broadcast room where the viewing end is located when sending the live broadcast report data;

[0008] Based on the freeze cause, freeze prompt information is sent to the target terminal, where the freeze prompt information is used to prompt the target terminal with the freeze cause that triggered the freeze event.

[0009] A live broadcast reporting data processing device, the device comprising:

[0010] A data receiving module, used for receiving live broadcast reporting data sent by a viewing terminal, wherein the live broadcast reporting data includes first interface image data of the viewing terminal;

[0011] A lag positioning module, configured to, when it is determined based on the live broadcast reporting data that a lag event occurs at the viewing end, determine a target terminal and a lag cause that trigger the lag event based on the first interface image data, where the target terminal includes at least one of the viewing end and the host end, and the host end is the terminal corresponding to the live broadcast room where the viewing end is located when sending the live broadcast reporting data;

[0012] A sending module, configured to send a lag prompt message to the target terminal based on the lag cause, where the lag prompt message is used to prompt the target terminal of the lag cause that triggers the lag event.

[0013] A computer device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0014] Receive live broadcast reporting data sent by a viewing end, where the live broadcast reporting data includes first interface image data of the viewing end;

[0015] When it is determined based on the live broadcast reporting data that a lag event occurs at the viewing end, determine a target terminal and a lag cause that trigger the lag event based on the first interface image data, where the target terminal includes at least one of the viewing end and the host end, and the host end is the terminal corresponding to the live broadcast room where the viewing end is located when sending the live broadcast reporting data;

[0016] Send a lag prompt message to the target terminal based on the lag cause, where the lag prompt message is used to prompt the target terminal of the lag cause that triggers the lag event.

[0017] A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0018] Receive live broadcast reporting data sent by a viewing end, where the live broadcast reporting data includes first interface image data of the viewing end;

[0019] When it is determined based on the live broadcast reporting data that a lag event occurs at the viewing end, determine a target terminal and a lag cause that trigger the lag event based on the first interface image data, where the target terminal includes at least one of the viewing end and the host end, and the host end is the terminal corresponding to the live broadcast room where the viewing end is located when sending the live broadcast reporting data;

[0020] Send a lag prompt message to the target terminal based on the lag cause, where the lag prompt message is used to prompt the target terminal of the lag cause that triggers the lag event.

[0021] The above live broadcast reporting data processing method, device, computer device and storage medium receive the reporting data for the live broadcast uploaded by the viewing end, including the first interface image data. When it is determined based on the first interface image data that a lag event occurs at the viewing end, the target terminal that causes the lag event and the cause of the lag are determined based on the first interface image data, and then a lag prompt message is sent to the target terminal based on the cause of the lag. The lag prompt message is used to prompt the target terminal of the cause of the lag event that occurs; wherein, the target terminal includes at least one of the viewing end or the host end, and the host end is the terminal corresponding to the live broadcast room where the viewing end is located when the live broadcast reporting data. In the above method, when the user watches the live broadcast, it is determined whether a lag event occurs based on the interface image obtained from the viewing end, and when it is determined that a lag event occurs, it is determined whether the cause of the lag event is the viewing end or the host end and the cause of the lag based on the interface image. Finally, a lag prompt message is sent to the target terminal based on the cause of the lag. It can be analyzed and determined only based on the interface image of the viewing end whether the terminal that causes the lag event is the viewing end or the host end, and the cause of the lag is determined, and the efficiency of locating the cause of the live broadcast lag event is high. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 It is an application environment diagram of the live broadcast reporting data processing method in an embodiment;

[0023] Figure 2 It is a flowchart of the live broadcast reporting data processing method in an embodiment;

[0024] Figure 3 It is a flowchart of determining the target terminal and the cause of the lag event that causes the lag event based on the first interface image data in an embodiment;

[0025] Figure 4 It is a schematic diagram of debugging floating layer information in a specific embodiment;

[0026] Figure 5 It is a flowchart of the live broadcast reporting data processing method in another embodiment;

[0027] Figure 6 It is a schematic diagram of function call information in a specific embodiment;

[0028] Figure 7 It is a flowchart of the live broadcast reporting data processing method in a specific embodiment;

[0029] Figure 8 It is a schematic diagram of a lag identifier in a specific embodiment;

[0030] Figure 9 It is a schematic diagram of an exception form in an embodiment;

[0031] Figure 10It is a structural block diagram of a live broadcast reporting data processing device in an embodiment;

[0032] Figure 11 It is an internal structure diagram of a computer device in an embodiment. Detailed implementation manners

[0033] In order to make the objectives, technical solutions and advantages of the present application clearer and more understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0034] In related technologies, when it is detected that the user experiences a freeze during the live broadcast, the user at the viewing end usually feeds back the freeze event. After the relevant personnel receive the feedback, they obtain the logs at that time to try to reproduce the problem, and manually analyze the cause of the freeze. Manual reproduction requires the relevant personnel to try various possible causes to analyze the cause of the freeze event; moreover, since the freeze may be caused by the viewing end or the live broadcast end, it is necessary to obtain the logs of the viewing end and the live broadcast end respectively for analysis. This method relies on manual analysis and positioning of the cause of the freeze, resulting in low efficiency. For this reason, the present application provides a live broadcast reporting data processing method.

[0035] The live broadcast reporting data processing method provided by the present application can be applied to, for example, Figure 1 the application environment shown in the figure. Among them, the detection server 104 communicates with the viewing end 101 and the host end 102 through the network. The server 104 receives the reporting data for the live broadcast from the viewing end 101, including the first interface image data. When it is determined based on the first interface image data that a freeze event occurs in the viewing end 101, the target terminal and the cause of the freeze event that trigger the freeze event are determined based on the first interface image data, and then a freeze prompt message is sent to the target terminal based on the cause of the freeze. The freeze prompt message is used to prompt the target terminal of the cause of the freeze event that triggers the freeze event; among them, the target terminal includes at least one of the viewing end 101 or the host end 102; the viewing end 101 is the terminal used by the user to watch the live broadcast, and the host end 102 is the terminal corresponding to the live broadcast room where the viewing end is located when reporting the live broadcast data. Among them, the viewing end 101 and the host end 102 can be, but are not limited to, various personal computers, laptop computers, smart phones, tablet computers and portable wearable devices, and the detection server 104 can be implemented by an independent server or a server cluster composed of multiple servers.

[0036] In one embodiment, as Figure 2 shown in the figure, a live broadcast reporting data processing method is provided. Taking this method applied to Figure 1 the detection server in the figure as an example for description, it includes steps S210 to S230.

[0037] Step S210: Receive the live broadcast reporting data sent by the viewing end. The live broadcast reporting data includes the first interface image data of the viewing end.

[0038] Herein, the viewing end refers to the terminal used by the user to watch the live broadcast. The viewing end reports the live broadcast reporting data to the detection server, and the live broadcast reporting data includes the interface image data of the viewing end. It should be noted that in this embodiment, in order to distinguish from the interface image data in the subsequent embodiments, the interface image data in the live broadcast reporting data is denoted as the first interface image data. The "first" and the "second" involved in the subsequent embodiments are only used for differentiating names and do not represent any actual meaning. In one embodiment, the number of the first interface image data can be one or more than two.

[0039] The interface image data represents the data containing the interface. Further, in this embodiment, the interface image data represents the interface image of the viewing end when watching the live broadcast in the live broadcast room, and can be static images such as screenshots, dynamic images or videos, etc. data; wherein, the static images such as screenshots, dynamic images or videos such as the data recorded by the screen recording application containing the screen change situation within a period of time. In one embodiment, the interface image data is the interface data of the live broadcast room when a stuttering event occurs, or the interface data displaying the relevant running data of the viewing end when a stuttering event occurs, and so on.

[0040] In one embodiment, the interface image data can be manually intercepted by the user, and the live broadcast reporting data is sent to the detection server based on the intercepted interface image data. Further, the user can intercept the interface image when watching the live broadcast in the live broadcast room at any time and report it, or can also intercept the image and report it when it is considered that a stuttering event occurs during watching the live broadcast, and so on. In this embodiment, when the user considers that a stuttering event occurs, the screenshot is uploaded, and the detection server determines whether a stuttering event of the live broadcast actually occurs at the viewing end based on the live broadcast reporting data.

[0041] In another embodiment, the interface image data can also be to automatically intercept the interface image of the viewing end at a predetermined time interval when the viewing end is in the live broadcast room, and the live broadcast reporting data is sent to the detection server based on the intercepted interface image. In this embodiment, the detection server regularly obtains the interface image data to detect whether a stuttering event occurs at the viewing end. In other embodiments, the viewing end can also send the live broadcast reporting data in other ways. By automatically intercepting the interface image and sending it to the detection server, when a live broadcast stuttering event occurs at the viewing end, it can be quickly detected, and the cause of the stuttering can be located and analyzed, improving the efficiency of live broadcast stuttering detection and stuttering cause location.

[0042] In one embodiment, the live broadcast reporting data includes interface image data and log data related to the operation of the live broadcast application program at the viewing end; in other embodiments, the live broadcast reporting data may also include other data.

[0043] Step S220, when it is determined based on the live broadcast reporting data that a freeze event occurs on the viewing end, the target terminal causing the freeze event and the freeze cause are determined based on the first interface image data, and the target terminal includes at least one of the viewing end and the host end.

[0044] Among them, the anchor end is the terminal corresponding to the live broadcast room where the viewing end is located when sending live broadcast reporting data.

[0045] In one embodiment, when the viewing end is in the live broadcast room watching the live broadcast, the live broadcast freeze event includes but is not limited to the black screen, the screen is not moving, and there is no response in the live broadcast. Further, by detecting whether there is a freeze object in the first interface image, it is determined whether a freeze event occurs at the viewing end. Among them, the freeze object includes one or more of a black screen image and a freeze mark; the black screen image represents the image displayed in the interface when a black screen occurs at the viewing end, and the black screen is a phenomenon during the video playback process; the freeze mark is an identifier indicating a freeze, and commonly used freeze marks include similar "circling daisy", text prompts "CPU is falling behind, let's see what's going on?" and so on. In this embodiment, by detecting whether the first interface image contains a black screen image and / or a freeze mark, it is determined whether a freeze event occurs at the viewing end.

[0046] In one embodiment, it is possible to determine whether there is a stuck object in the first interface image data by means of target detection. Target detection can detect whether there is a specific target from the image data, and further can determine the location information of the specific target when the specific target is included in the image. In this embodiment, target detection of the first interface image data can be implemented in any manner.

[0047] Furthermore, in one embodiment, detecting whether there is a black screen image in the first interface image data includes: performing hue-saturation-brightness HSB color mode extraction processing on the interface image data to obtain HSB information corresponding to the pixel points of the interface image data; determining the target pixel points whose hue H (hues) value in the HSB information is within a preset numerical range (which can be (35, 77)) from the pixel points of the interface image data; if the ratio of the target pixel points to the pixel points of the interface image data reaches a preset ratio threshold, determining that a black screen image appears in the interface image data. In another embodiment, detecting whether there is a jamming mark in the first interface image data can be performed by image recognition, such as training a model to detect whether the image contains a jamming mark. In other embodiments, other methods can also be used to detect whether the first interface image contains a black screen image and / or a jamming mark.

[0048] The process of users watching the live broadcast is as follows: First, the host side pushes the video stream to the cloud, and the cloud performs transcoding. Then, the viewing side pulls the stream and decodes it for playback, presenting it to the users. If there is a problem with the host side, both downstream users 1 and 2 will have problems. If it is a network problem on the viewing side, for a single user, user 1 can pull the stream normally and play it normally, while user 2 may experience abnormalities. That is, when a stuttering event occurs on the viewing side, it may be caused by the host side or the viewing side. Therefore, in this embodiment, when it is determined that a stuttering event occurs on the viewing side, the target terminal that causes the stuttering event is determined based on the first interface image data. The target terminal can be at least one of the host side or the viewing side. At the same time, the stuttering cause that causes the stuttering event is determined based on the first interface image data, such as the device and network reasons on the host side, and the device and network reasons on the viewing side, etc.

[0049] Furthermore, the specific process of determining the target terminal and stuttering cause that cause the stuttering event based on the first interface image data will be described in detail in the subsequent embodiments and will not be elaborated here.

[0050] Step S230, send a stuttering prompt message to the target terminal based on the stuttering cause.

[0051] Among them, the stuttering prompt message is used to prompt the target terminal of the stuttering cause that causes the stuttering event.

[0052] After analyzing and determining the target terminal and stuttering cause that cause the stuttering event, a stuttering prompt message can be sent to the target terminal to prompt the corresponding terminal or user to understand the cause of the stuttering event, and then take corresponding measures for the stuttering event. In a specific embodiment, when it is determined that the terminal causing the stuttering event is the viewing side, a stuttering prompt message can be sent to the viewing side, and the stuttering cause is sent to the user through the stuttering prompt message for awareness. If the host receives the stuttering prompt message on the host side and knows that the stuttering event is caused by the host side, operations such as trying to change the network and adjusting the live broadcast clarity can be attempted to solve the stuttering event.

[0053] In one embodiment, after determining the target terminal that causes the lag event and the cause of the lag based on the first interface image data, the following steps are further included: sending a solution corresponding to the cause of the lag to the target terminal; where when the cause of the lag is due to the host side, the solution includes: prompting the host to check the device and network; when the cause of the lag is due to the viewing side, the solution includes: prompting the user on the viewing side to try switching the network, refreshing the live broadcast room, or switching the clarity of the live broadcast data, at least one of them. In this embodiment, after receiving the solution on the host side, the host can check the problems of its own device and network according to the prompts of the solution; after receiving the solution on the viewing side, the user on the viewing side can try operations such as switching the network, refreshing the live broadcast room, and switching the clarity of the live broadcast data according to the prompts of the solution to solve the lag event.

[0054] In one embodiment, if it is determined that the target terminal that causes the lag event is the host side, in addition to sending a lag prompt message to the host side, a lag prompt message is also sent to the viewing side, and the lag prompt message is used to prompt the user on the viewing side that the reason for the live broadcast lag is due to the host side.

[0055] For the above live broadcast reporting data processing method, the reporting data for the live broadcast uploaded by the viewing side is received, including the first interface image data. When it is determined that a lag event occurs on the viewing side based on the first interface image data, the target terminal that causes the lag event and the cause of the lag are determined based on the first interface image data, and then a lag prompt message is sent to the target terminal based on the cause of the lag. The lag prompt message is used to prompt the target terminal of the cause of the lag event; where the target terminal includes at least one of the viewing side or the host side, and the host side is the terminal corresponding to the live broadcast room where the viewing side is located when reporting the live broadcast data. For the above method, when the user watches the live broadcast, it is determined whether a lag event occurs based on the interface image obtained from the viewing side, and when it is determined that a lag event occurs, it is determined whether the cause of the lag event is the viewing side or the host side and the cause of the lag based on the interface image. Finally, a lag prompt message is sent to the target terminal based on the cause of the lag. Only based on the interface image of the viewing side can it be analyzed and determined whether the terminal that causes the lag event is the viewing side or the host side, and the cause of the lag can be determined, and the efficiency of locating the cause of the live broadcast lag event is high.

[0056] In one embodiment, as Figure 3 shown, determining the target terminal that causes the lag event and the cause of the lag based on the first interface image data includes step S221: If it is detected that the first interface image data has a preset prompt message, determine that the target terminal that causes the lag event is the host side, and determine that the cause of the lag is due to the host side.

[0057] Among them, the preset prompt information is used to prompt abnormalities in the host end. In one embodiment, when an abnormality occurs in the host end, such as network disconnection, disconnection, etc., it may cause the video stream of the host end not to be normally transmitted to the cloud, resulting in the viewing end being unable to watch normally, thus causing lag. At this time, the preset prompt information is displayed in the interface of the viewing end to prompt the user of the viewing end that the current lag is caused by an abnormality in the host end. In a specific embodiment, the preset prompt information is "The current host device is unstable, please wait patiently"; in other embodiments, the preset prompt information can be set to other information according to the actual situation.

[0058] In one embodiment, it is possible to determine whether a field of the preset prompt information appears in the first interface image data by performing target field detection on the first interface image data. If it is determined that the preset prompt information exists in the first interface image data, it is determined that the cause of the lag is the host end. In one embodiment, a target field detection model for detecting the preset prompt information can be pre-trained, and the trained target field detection model is used to detect the first interface image data to determine whether the preset prompt information exists. In another embodiment, it is also possible to perform character recognition on the first interface image data, output the characters in the first interface image, and determine whether there is a field corresponding to the preset prompt information in the first interface image data by comparing the characters with the preset prompt information. Among them, character recognition of the image can be implemented by any method. In other embodiments, target field detection of the first interface image data can also be implemented by any other method.

[0059] If it is determined according to the log data that there is preset prompt information in the viewing end interface at the moment when the lag occurs, it can be determined that the target terminal causing this lag event is the host end, and further, it can be determined that the cause of this lag event is the host end reason. Further, after determining that the target terminal causing the lag event is the host end and the cause of the lag event is the host end reason, a lag prompt information is sent to the host end to prompt the host to take corresponding measures.

[0060] In this embodiment, by detecting whether there is preset prompt information in the first interface image data that prompts abnormalities in the host end to determine whether the terminal causing this lag event is the host end, it is possible to detect the live broadcast report data reported by the viewing end and determine that the cause of the lag event is in the host end, avoiding the need to analyze the data of the host end to determine whether it is the cause of the host end when a lag event occurs, quickly locating the cause of the lag, and improving the processing efficiency of the live broadcast report data.

[0061] In one embodiment, please continue to refer to Figure 3 above, the above method further includes step S222 and step S224.

[0062] Step S222, if it is detected that the preset prompt information does not exist in the first interface image data, obtain the debug floating layer information of the live broadcast room where the viewing end is located when sending the live broadcast report data.

[0063] Among them, the debug floating layer information represents the debug information of the viewing end at a certain moment, and is displayed in the form of a floating layer on the interface of the viewing end. In one embodiment, the debug floating layer information includes network operation data of the viewing end, the network address corresponding to the live data stream of the live broadcast room where the viewing end is currently located, the player type, the resolution, and so on.

[0064] In one embodiment, a switch control for the debug floating layer is set in the viewing end, and the user can select whether to display the debug floating layer information in the interface through this switch control. Further, in one embodiment, the live broadcast report data is actively uploaded by the user. When the user finds that the live broadcast is stuck, the user can choose to intercept the interface image including the debug floating layer information and upload it to the detection server, so that the detection server can locate the cause of the stuck event according to the debug floating layer information. In this embodiment, the debug floating layer information can be obtained from the live broadcast report data.

[0065] In another embodiment, the live broadcast report data is to automatically intercept the first interface image data and report it. In this embodiment, while automatically intercepting the first interface image data, obtain the debug information of the viewing end, and superimpose the obtained debug information on the first interface image data in the form of a floating layer. In this embodiment, obtain the debug floating layer information from the first interface image data. As Figure 4 shown is a schematic diagram of debug floating layer information in a specific embodiment.

[0066] Step S223, read the network operation data of the viewing end from the debug floating layer information.

[0067] Among them, the network operation data includes relevant data indicating the network operation status of the viewing end. Combining the network operation data, it can be determined whether the current network operation status of the viewing end is good. In one embodiment, the network operation data includes the reception speed, frame rate, video bit rate, audio bit rate, and so on. Among them, the reception speed represents the speed of receiving the live video stream, and the unit is kbps (kilobits per second). The frame rate is the frequency (rate) at which bitmap images appear continuously on the display in frames. The video bit rate is the number of video data bits transmitted per unit time during data transmission, and the unit generally used is kbps. The audio bit rate is the number of audio data bits transmitted per unit time during data transmission, and the unit generally used is kbps. In other embodiments, the operation data of the viewing end may also include other data. In other embodiments, the network operation data may also include other data.

[0068] Step S224, if it is determined according to the network operation data that the network condition of the viewing end reaches the preset carding condition, determine that the target terminal causing the carding event is the viewing end, and the reason for carding is the network reason of the viewing end.

[0069] Among them, the preset carding condition refers to the preset carding condition, which can be specifically set according to the actual situation. In one embodiment, if the network condition of the viewing end reaches the preset carding condition, it is determined that the network of the viewing end is carded and the network condition is poor.

[0070] In one embodiment, determining the network condition of the viewing end according to the network operation data includes: calculating the sum value of the audio reception bit rate and the video reception bit rate in the network operation data, comparing the sum value with the reception speed, determining the size comparison result of the sum value and the reception speed, and determining the network condition of the viewing end according to the size comparison result. Further, in a specific embodiment, if the sum value of the audio reception bit rate and the video reception bit rate is greater than the reception speed, it is determined that the network condition of the viewing end reaches the preset carding condition; if the sum value of the audio reception bit rate and the video reception bit rate is less than or equal to the reception speed, it is determined that the network condition of the viewing end does not reach the preset carding condition.

[0071] Further, if it is determined according to the operation data that the network condition of the viewing end reaches the preset carding condition, it means that the network condition of the viewing end is poor at the moment of carding. Furthermore, the target terminal causing the carding event is determined as the viewing end, and the reason for the carding event is determined as the network reason of the viewing end.

[0072] In this embodiment, by obtaining the debug floating layer information of the viewing end, the network condition when the viewing end sends the live broadcast carding data is determined, and based on the network condition, it is determined whether there is network carding at the viewing end. Furthermore, it is determined whether the reason for the carding event is the network reason of the viewing end. Further, if it is determined that the reason for carding is the network reason of the viewing end, a carding prompt message can be sent to the viewing end to prompt the user that the network condition is poor, and the user can try to switch the network to watch the live broadcast based on the carding prompt message.

[0073] In one embodiment, after determining that the network condition of the viewing end reaches the preset carding condition according to the network operation data, determining that the target terminal causing the carding event is the viewing end, and the reason for carding is the network reason of the viewing end, while sending a carding prompt message to the viewing end based on the reason for carding, it further includes: sending a solution to the viewing end, and the solution is used to prompt the user to try to switch the network to watch the live broadcast.

[0074] Further, in one embodiment, please continue to refer to Figure 3 , the above method further includes steps S225 to S227.

[0075] Step S225, if it is determined according to the running data that the network condition of the viewing end does not reach the preset lag condition, read the network address corresponding to the live data stream of the live broadcast room from the debug floating layer information.

[0076] If it is determined that the network condition of the viewing end does not reach the preset lag condition when sending the live broadcast report data, it means that the network condition of the viewing end may be okay, and the cause of the lag needs to be analyzed from other perspectives.

[0077] Among them, for the viewing end user to watch the live broadcast, the live data stream of the live broadcast room must be pulled from the cloud. Specifically, the live data stream is pulled from the network address corresponding to the live data stream; the network address corresponding to the live data stream of the live broadcast room represents the address for obtaining the live data stream. Based on this network address, the live data stream corresponding to the live broadcast room can be obtained. In a specific embodiment, the network address corresponding to the live data stream of the live broadcast room is a Uniform Resource Locator (URL, Uniform Resource Locator), which is also known as a web address and is the standard address of a resource on the Internet. In an embodiment, the live data stream of the live broadcast room can be pulled through the Uniform Resource Locator of the live data stream, and then the live broadcast can be watched.

[0078] Step S226, obtain the live data stream based on the network address, and perform a play detection on the live data stream based on the stream play platform to obtain a play detection result.

[0079] Among them, the stream play platform is a web (World Wide Web) end video player. When a normal stream address is input, the video live broadcast can be played normally. In this embodiment, input the network address of the live data stream in the stream play platform to check whether the live data stream can be played normally, and obtain a play detection result. In an embodiment, performing a play detection on the live data stream based on the stream play platform and the Uniform Resource Locator includes: uploading the Uniform Resource Locator to the stream play platform for playing to obtain a play detection result.

[0080] Step S227, if it is determined according to the play detection result that the play of the live data stream is normal, determine that the target terminal causing the lag event is the viewing end, and the cause of the lag is the viewing end reason.

[0081] If the play detection result shows that the live data stream of this live broadcast can be played normally in the stream play platform, it means that the lag event may be due to non-network reasons of the viewing end, such as incompatibility of the viewing end device; or it may be a network jitter problem of the viewing end. Therefore, in this embodiment, the cause of the lag event that causes the lag is located as the viewing end reason.

[0082] In this embodiment, if it is determined that there is no abnormality at the host end and the network of the viewing end is normal, the network address of the live data stream is obtained, and based on this network address, the live data stream is played and detected on the stream playback platform to determine whether the live stream has an abnormality and whether it can be played normally. If the live data stream can be played normally on the stream playback platform, the cause of the lag may still be due to the viewing end.

[0083] Further, in one embodiment, as Figure 5 , the above method further includes step S510: If it is determined according to the playback detection result that the playback of the live data stream is normal, a refresh prompt message is sent to the viewing end, and the refresh prompt message is used to prompt to refresh the live broadcast room.

[0084] If it is determined according to the playback detection result that the playback of the live data stream is normal, it means that the lag event has nothing to do with the live data stream pushed from the host end to the cloud. Therefore, a refresh prompt message is sent to the user to prompt to refresh the live broadcast room. In one embodiment, the live broadcast room can be refreshed actively by the user or automatically by the viewing end; the live broadcast room can be refreshed by the way of exiting the live broadcast room and re-entering, or by the way of reloading the live data stream. In other embodiments, the live broadcast room can also be refreshed by any other method. In this embodiment, the refresh prompt message is the solution described in the above embodiment.

[0085] Further, in one embodiment, please continue to refer to Figure 5 , after sending the refresh prompt message to the viewing end, it further includes steps S520 to S550. Among them:

[0086] Step S520, obtain the second interface image data of the viewing end.

[0087] In one embodiment, obtaining the second interface image data of the viewing end is to obtain the interface image data after the viewing end refreshes the live broadcast room based on the refresh prompt message, and determine whether there is still a lag event at the viewing end after refreshing the live broadcast room based on the second interface image data.

[0088] Step S530, when it is determined based on the second interface image data that a lag event occurs at the viewing end, obtain the log data of the viewing end.

[0089] Among them, the log data is the log data of the live application. A log refers to an ordered set of certain operations of a specified object of the system and their operation results over time. Each log file consists of log records, and each log record describes a single system event. Usually, the system log is a text file that users can directly read, which contains a timestamp and an information or other information specific to the subsystem. In one embodiment, the log data of the viewing end can be obtained by the detection server from the viewing end after it is determined that a stuttering event still occurs after the detection server determines that the viewing end refreshes the live broadcast room through the second interface image data; in another embodiment, the log data of the viewing end can be obtained when obtaining the second interface image data.

[0090] In one embodiment, when a stuttering object is detected in the second interface image data, it is determined that a stuttering event occurs at the viewing end; among them, the stuttering object includes one or more of a black screen image and a stuttering identifier.

[0091] In one embodiment, the log data of the viewing end may include: the network operation data of the viewing end corresponding to the second interface image data, the function call information of the live application program of the viewing end corresponding to the second interface image data, and whether a preset prompt message is displayed on the interface of the viewing end corresponding to the second interface image data. In other embodiments, the log data of the viewing end corresponding to the second interface image data may also include other contents.

[0092] Step S540, read the code call information of the live application program of the viewing end from the log data.

[0093] Among them, the live application program refers to the application program used by the user to watch the live broadcast; the code call information refers to the information on the call situation of each function when the live application program runs; the code call information can be read from the log data. For example Figure 6 The function call information shown, where the solid-line frames show paired start canvases and end canvases, and in this embodiment, it is detected whether the functions are called in pairs.

[0094] Step S550, if it is determined that the code call of the viewing end is abnormal according to the code call information, it is determined that the cause of the stuttering event that causes the stuttering is the abnormality of the application program of the viewing end.

[0095] In this embodiment, when it is determined that there is no abnormality at the host end and the network of the viewing end is normal, and the live data stream can be played normally, the code call situation of the program in the log data is detected to determine whether the code call of the live application program is abnormal. An abnormal code call is also a possible reason for the stuttering of the viewing end.

[0096] In one embodiment, normal code call scenarios can be preset. For example, for functions such as painting, the normal code call scenario is set to require paired calls. Thus, if it is analyzed and determined that the painting functions on the viewing end are not called in pairs, it is determined that there is an abnormality in the application program. At this time, an exception form is generated and sent to relevant personnel for detection. In other embodiments, the normal situations of other function calls can also be set, and then by analyzing the function call situations in the log data, it is determined whether there is an abnormal code call situation.

[0097] In another embodiment, if it is determined according to the playback detection result that the live data stream is played normally, it further includes obtaining the log data of the host end and reading the code call situation of the host end from the log data of the host end; and then determining whether there is an abnormality according to the code call situation of the host end. Among them, the detection of whether there is an abnormal code call situation at the host end can be the same as the detection method at the viewing end.

[0098] In this embodiment, if it is determined that there is no abnormality at the host end, the network at the viewing end is normal, the live data stream can be played normally, and there are still stuttering events after refreshing the live broadcast room, try to analyze whether there is an abnormality from the code call situation of the live application program to determine whether there is a problem with the code call situation of the live application program; if it is monitored that the calls of paired functions appear unpaired, it is very likely that the child thread calling the function continuously occupies the drawing, resulting in a soaring CPU (Central Processing Unit), and then there will be stuttering events in the live broadcast room; further, if it is determined according to the code call information that there is an abnormality in the code call of the live application program, an exception form is sent to relevant personnel (such as developers) to prompt relevant personnel to perform corresponding processing.

[0099] In another embodiment, if it is determined according to the second interface image data that there is a stuttering event at the viewing end, an exception form is generated based on the log data of the viewing end and sent to relevant personnel.

[0100] If it is determined according to the second interface image data that the viewing end still cannot watch the live broadcast normally after refreshing the live broadcast room, that is, a stuttering event occurs, an exception form needs to be sent to relevant personnel of the live application program to prompt relevant developers to access and determine the cause of the stuttering. In one embodiment, generating an exception form based on the log data of the viewing end includes: extracting the target data corresponding to the key fields in the log data and packing the target data to generate an exception form. Among them, the target data may include: the occurrence time of the stuttering event, whether there is a preset prompt message for prompting an abnormality at the host end when the stuttering occurs, the running data of the viewing end at the moment when the stuttering occurs, the network address of the live data stream, the code call information of the live application program at the viewing end, and so on.

[0101] The present application also provides an application scenario that applies the above-mentioned live broadcast reporting data processing method. Specifically, as Figure 7 shown, the application of the live broadcast reporting data processing method in this application scenario is as follows:

[0102] S100, receive the live broadcast reporting data sent by the viewing end, where the live broadcast reporting data includes first interface image data.

[0103] S200, determine whether a carding event occurs at the viewing end based on the live broadcast reporting data. Specifically, it is to detect whether there is a carding object in the first interface image data, such as a black screen image or a carding identifier (such as Figure 8 the carding identifier of the "spinning chrysanthemum" shown). Among them, the method of image recognition and / or color recognition can be used to detect the carding object in the first interface image data.

[0104] S300, determine that a carding event occurs based on the live broadcast reporting data.

[0105] S400, when it is determined that a carding event occurs based on the live broadcast reporting data, detect in the first interface image data to determine whether there is a preset prompt message for prompting an abnormality at the host end. If so, then S401, determine that the target terminal causing the carding event is the host end, and the carding reason for causing the carding event is the reason of the host end. S402, send a carding prompt message to the host end.

[0106] If it is determined that there is no preset prompt message in the first interface image data, start to check whether it is the reason of the viewing end:

[0107] Regarding the problem of the viewing end, first judge the network condition of the viewing end: S500, obtain the debugging floating layer information of the live broadcast room where the viewing end is located when sending the live broadcast reporting data; read the network operation data of the viewing end from the debugging floating layer information, including video bit rate, audio bit rate and reception rate; S501, if it is determined according to the network operation data that the network condition of the viewing end reaches the preset carding condition, determine that the target terminal causing the carding event is the viewing end, and the carding reason is the network reason of the viewing end. Among them, specifically: (video bit rate + audio bit rate)> reception rate, indicating that the network condition of the viewing end reaches the preset carding condition, determine that the viewing end causes the carding event, and determine that the carding reason is the network reason of the viewing end.

[0108] Secondly, if the network condition of the viewing end is normal, determine whether the live data stream of the live broadcast room is played normally: when (video bitrate + audio bitrate) <= reception rate, it is determined that the network condition of the viewing end does not reach the preset lag condition. In S502, read the network address (URL) corresponding to the live data stream of the live broadcast room from the debug floating layer information; obtain the live data stream based on the network address, and perform a play detection on the live data stream based on the stream play platform to obtain a play detection result; In S503, if it is determined that the live data stream is played normally according to the play detection result, determine that the target terminal causing the lag event is the viewing end. In S5041, the reason for the lag is the viewing end reason.

[0109] Further, in S5042, if it is determined that the live data stream is played normally according to the play detection result, send a refresh prompt message to the viewing end to prompt to refresh the live broadcast room. After prompting to refresh the live broadcast room, in S505, obtain the second interface image data of the viewing end; In S506, when it is determined that a lag event occurs at the viewing end based on the second interface image data, in S507, obtain the log data of the viewing end; In S508, read the code call information of the live application program of the viewing end from the log data; In S509, if it is determined that the code call of the viewing end is abnormal according to the code call information, in S5010, determine that the reason for the lag causing the lag event is the application program exception of the viewing end.

[0110] In another embodiment, if it is determined that the live data stream is played abnormally according to the play detection result, determine that the target terminal causing the lag event is the host end, and the reason for the lag causing the lag event is the host end reason.

[0111] Finally, if it is determined that the target terminal causing the lag event is the host end, send a lag prompt message to the host end to prompt the host of the reason for the lag event; if it is determined that the target terminal causing the lag event is the viewing end, send a lag prompt message to the viewing end to prompt the user watching the live broadcast of the reason for the lag event.

[0112] In another embodiment, if it is determined that the live data stream is played normally according to the play detection result, and it is determined that the code call of the live application program of the viewing end is normal according to the code call information in the log data, it means that the terminal and the reason for the lag event cannot be determined. Further, if the target terminal and / or the reason for the lag event of the live broadcast cannot be determined, or when the live application program is determined to be abnormal, an exception form can be generated and sent to the relevant personnel so that the relevant personnel can troubleshoot the lag event. As Figure 9 shown is a schematic diagram of an exception form for a specific embodiment.

[0113] The above live broadcast reporting data processing method, when receiving the live broadcast reporting data of a live broadcast, first determines whether a lag event occurs at the viewing end according to the live broadcast reporting data. If it is determined that a lag event occurs, the reasons for the lag event are sequentially checked according to the first interface image data to see if the reasons are the host end reason, the network reason of the viewing end, the network jitter of the viewing end, or the code call exception reason of the live broadcast application program of the viewing end. The entire process of checking the reasons for the lag is automated, using a variety of technical means. By analyzing whether there is a preset prompt message in the interface image data sent by the viewing end, whether the network conditions of the viewing end reach the preset lag conditions, whether the live data stream of the live broadcast room can be normally played in the streaming platform, and determining whether the code call of the live broadcast application program of the viewing end is abnormal based on the log data, the checking process is clear and concise, shortening the time for troubleshooting problems, thus solving the live broadcast lag problem faster and reducing the time when the problem affects users. This method is applicable to all live broadcast and on-demand services, has universality, and is also applicable to quickly locating problems during the daily system testing process. Among them, for problems at the code level, the code call situation of the application program is analyzed through log data to check for abnormalities. Avoid methods that are called in pairs like drawing, where there is only a start without an end. If such an abnormal situation is detected, a quick alarm is issued.

[0114] It should be understood that although the steps in each flowchart involved in the above embodiments are sequentially shown according to the indication of the arrows, these steps do not necessarily need to be executed in the order indicated by the arrows. Unless there is a clear indication in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in each flowchart involved in the above embodiments may include multiple steps or multiple stages. These steps or stages do not necessarily need to be executed at the same time, but can be executed at different times. The execution order of these steps or stages does not necessarily need to be sequential, but can be executed alternately or in turn with at least a part of other steps or steps or stages in other steps.

[0115] In one embodiment, as Figure 10 shown, a live broadcast reporting data processing device is provided. This device can be a software module, a hardware module, or a combination of the two to become a part of a computer device. Specifically, the device includes: a data receiving module 1010, a lag positioning module 1020, and a sending module 1030, where:

[0116] The data receiving module 1010 is used to receive the live broadcast reporting data sent by the viewing end, and the live broadcast reporting data includes the first interface image data of the viewing end;

[0117] The carding positioning module 1020 is used to determine the target terminal and the carding reason that cause the carding event based on the first interface image data when it is determined that a carding event occurs at the viewing end based on the live broadcast report data. The target terminal includes at least one of the viewing end and the host end, where the host end is the terminal corresponding to the live broadcast room where the viewing end is located when sending the live broadcast report data;

[0118] The sending module 1030 is used to send a carding prompt message to the target terminal based on the carding reason, and the carding prompt message is used to prompt the target terminal of the carding reason that causes the carding event.

[0119] The above live broadcast report data processing device receives the report data uploaded by the viewing end for the live broadcast, including the first interface image data. When it is determined that a carding event occurs at the viewing end based on the first interface image data, the target terminal and the carding reason that cause the carding event are determined based on the first interface image data, and then a carding prompt message is sent to the target terminal based on the carding reason. The carding prompt message is used to prompt the target terminal of the carding reason that causes the carding event; among them, the target terminal includes at least one of the viewing end or the host end, and the host end is the terminal corresponding to the live broadcast room where the viewing end is located when sending the live broadcast report data. The above method, when the user watches the live broadcast, determines whether a carding event occurs based on the interface image obtained from the viewing end, and when it is determined that a carding event occurs, determines whether the cause of the carding event is the viewing end or the host end and the carding reason based on the interface image. Finally, a carding prompt message is sent to the target terminal based on the carding reason. Only based on the interface image of the viewing end can it be analyzed and determined whether the terminal that causes the carding event is the viewing end or the host end, and the carding reason can be determined, and the efficiency of positioning the cause of the live broadcast carding event is high.

[0120] In one embodiment, the carding positioning module 1020 of the above device includes a prompt message detection unit, which is used to: if it is detected that the first interface image data has a preset prompt message, determine that the target terminal that causes the carding event is the host end, and determine that the carding reason is the host end reason, where the preset prompt message is used to prompt an abnormality of the host end.

[0121] In one embodiment, the carding positioning module 1020 of the above device further includes: a debugging floating layer information acquisition unit, which is used to acquire the debugging floating layer information of the live broadcast room where the viewing end is located when it is detected that the first interface image data does not have a preset prompt message; a network operation data acquisition unit, which is used to read the network operation data of the viewing end from the debugging floating layer information; a network condition judgment unit, which is used to determine that the target terminal that causes the carding event is the viewing end and the carding reason is the network reason of the viewing end if it is determined that the network condition of the viewing end reaches the preset carding condition according to the network operation data.

[0122] In one embodiment, the freeze positioning module 1020 of the above device further includes: a network address reading unit, configured to read the network address corresponding to the live data stream of the live broadcast room from the debug floating layer information if it is determined according to the running data that the network condition of the viewing end does not reach the preset freeze condition; a playback detection unit, configured to obtain the live data stream based on the network address and perform a playback detection on the live data stream based on the stream playback platform to obtain a playback detection result; the freeze positioning module 1020 is further configured to: if it is determined according to the playback detection result that the playback of the live data stream is normal, determine that the target terminal causing the freeze event is the viewing end, and the cause of the freeze is the viewing end reason.

[0123] In one embodiment, the network condition judgment unit of the above device is further configured to: when it is detected that the sum of the audio reception bit rate and the video reception bit rate is greater than the reception speed, determine that the network condition of the viewing end reaches the preset freeze condition; when it is detected that the sum of the audio reception bit rate and the video reception bit rate is less than or equal to the reception speed, determine that the network condition of the viewing end does not reach the preset freeze condition.

[0124] In one embodiment, the above device further includes: a prompt information sending module, configured to send a refresh prompt information to the viewing end if it is determined according to the playback detection result that the playback of the live data stream is normal, and the refresh prompt information is used to prompt to refresh the live broadcast room.

[0125] In one embodiment, the data reception module of the above device is further configured to: obtain the second interface image data of the viewing end; the above device further includes: a log acquisition module, configured to acquire the log data of the viewing end when it is determined based on the second interface image data that a freeze event occurs at the viewing end; a code call information reading module, configured to read the code call information of the live application program of the viewing end from the log data; the freeze positioning module 1020 of the above device is further configured to: if it is determined according to the code call information that the code call of the viewing end is abnormal, determine that the cause of the freeze event is the application program exception of the viewing end.

[0126] In one embodiment, the freeze positioning module 1020 of the above device is further configured to: when it is detected that there is a freeze object in the first interface image data or the second interface image data, determine that a freeze event occurs at the viewing end; wherein, the freeze object includes one or more of a black screen image and a freeze identifier.

[0127] For the specific embodiments of the live report data processing device, reference may be made to the embodiments of the live report data processing method described above, which will not be elaborated herein. Each module in the above live report data processing device can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in or independent of the processor in the computer device in the form of hardware, or stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above each module.

[0128] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structural diagram may be as shown in Figure 11 . The computer device includes a processor 1210, a memory 1220 (not shown in the figure), and a network interface 1230 connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium 1221 and an internal memory 1222. The non-volatile storage medium 1221 stores an operating system 12211, a computer program 12212, and a database 12213. The internal memory 1222 provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium 1221. The network interface 1230 of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, it implements a live reporting data processing method.

[0129] Those skilled in the art can understand that Figure 11 the structure shown in is only a block diagram of some structures related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0130] In one embodiment, a computer device is further provided, including a memory and a processor. A computer program is stored in the memory. When the processor executes the computer program, the steps in the above method embodiments are implemented.

[0131] In one embodiment, a computer-readable storage medium is provided, storing a computer program. When the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0132] In one embodiment, a computer program product or a computer program is provided. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in the above method embodiments.

[0133] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above various methods. Among them, any reference to a memory, storage, database, or other medium used in the various embodiments provided in the present application can include at least one of non-volatile and volatile memories. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0134] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the various technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0135] The above embodiments only represent several implementation manners of the present application. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application should be subject to the appended claims.

Claims

1. A method for processing live broadcast reported data, characterized in that, The method includes: Receiving live report data sent by a viewing end, where the live report data includes first interface image data of the viewing end; the first interface image data represents the interface image of the viewing end when watching a live broadcast in a live broadcast room. When it is determined based on the live report data that a lag event occurs in the viewing end, based on the first interface image data, determining the target terminal and the cause of the lag event that trigger the lag event, including: If it is detected that there is preset prompt information for indicating an abnormality of the host end in the first interface image data, determining that the target terminal that triggers the lag event is the host end, and determining that the cause of the lag is the host end reason, where the host end is the terminal corresponding to the live broadcast room where the viewing end is located when sending the live report data; the host end reason includes device reasons. If it is detected that the preset prompt information does not exist in the first interface image data, obtaining the debugging floating layer information of the live broadcast room where the viewing end is located when sending the live report data; the debugging floating layer information is displayed in the first interface image data in the form of a floating layer. Reading the network operation data of the viewing end from the debugging floating layer information. If it is determined based on the network operation data that the network condition of the viewing end reaches a preset lag condition, determining that the target terminal that triggers the lag event is the viewing end, and the cause of the lag is the network reason of the viewing end. If it is determined based on the network operation data that the network condition of the viewing end does not reach the preset lag condition, reading the network address corresponding to the live data stream of the live broadcast room from the debugging floating layer information. Obtaining the live data stream based on the network address, and performing a playback detection on the live data stream based on a streaming playback platform to obtain a playback detection result. If it is determined based on the playback detection result that the playback of the live data stream is normal, determining that the target terminal that triggers the lag event is the viewing end, and the cause of the lag is the viewing end reason. Sending a lag prompt message to the target terminal based on the cause of the lag, where the lag prompt message is used to prompt the target terminal of the cause of the lag event that triggers the lag event.

2. The live broadcast reporting data processing method according to claim 1, wherein, After reading the network operation data of the viewing end from the debugging floating layer information, it further includes: When it is detected that the sum value of the audio reception bit rate and the video reception bit rate is greater than the reception speed, determining that the network condition of the viewing end reaches a preset lag condition. When it is detected that the sum value of the audio reception bit rate and the video reception bit rate is less than or equal to the reception speed, determining that the network condition of the viewing end does not reach the preset lag condition.

3. The live broadcast reported data processing method according to claim 1, characterized in that It further includes: If it is determined based on the playback detection result that the playback of the live data stream is normal, sending a refresh prompt message to the viewing end, where the refresh prompt message is used to prompt to refresh the live broadcast room.

4. The live broadcast reported data processing method according to claim 3, wherein After sending the refresh prompt message to the viewing end, it further includes: Obtaining second interface image data of the viewing end. When it is determined based on the second interface image data that a lag event occurs in the viewing end, obtaining the log data of the viewing end. Reading the code call information of the live broadcast application program of the viewing end from the log data. If it is determined that the code call of the viewing end is abnormal according to the code call information, it is determined that the cause of the freeze event is the application exception of the viewing end.

5. The live broadcast reporting data processing method according to claim 1 or 4, characterized in that It further includes: When it is detected that there is a freeze object in the first interface image data or the second interface image data, it is determined that a freeze event occurs at the viewing end; wherein, the freeze object includes one or more of a black screen image and a freeze identifier.

6. A live broadcast reporting data processing device, characterized in that, The device includes: A data receiving module, configured to receive live report data sent by a viewing end, where the live report data includes first interface image data of the viewing end; the first interface image data represents an interface image of the viewing end when watching a live broadcast in a live broadcast room. A freeze positioning module, configured to, when it is determined that a freeze event occurs at the viewing end based on the live report data, determine a target terminal and a cause of the freeze event based on the first interface image data; the freeze positioning module includes: A prompt information detection unit, configured to, if it is detected that there is preset prompt information for indicating an abnormality of the host end in the first interface image data, determine that the target terminal causing the freeze event is the host end, and determine that the cause of the freeze is the host end reason, where the host end is the terminal corresponding to the live broadcast room where the viewing end is located when sending the live report data; the host end reason includes a device reason. A debugging floating layer information acquisition unit, configured to, if it is detected that the preset prompt information does not exist in the first interface image data, acquire debugging floating layer information of the live broadcast room where the viewing end is located when sending the live report data; the debugging floating layer information is displayed in the first interface image data in the form of a floating layer. A network operation data acquisition unit, configured to read network operation data of the viewing end from the debugging floating layer information. A network condition judgment unit, configured to, if it is determined that the network condition of the viewing end reaches a preset freeze condition according to the network operation data, determine that the target terminal causing the freeze event is the viewing end, and the cause of the freeze is the network reason of the viewing end. A network address reading unit, configured to, if it is determined that the network condition of the viewing end does not reach a preset freeze condition according to the network operation data, read the network address corresponding to the live data stream of the live broadcast room from the debugging floating layer information. A playback detection unit, configured to obtain the live data stream based on the network address, and perform a playback detection on the live data stream based on a stream playback platform to obtain a playback detection result. The freeze positioning module is further configured to: if it is determined that the playback of the live data stream is normal according to the playback detection result, determine that the target terminal causing the freeze event is the viewing end, and the cause of the freeze is the viewing end reason. The device further includes a sending module, configured to send a freeze prompt information to the target terminal based on the cause of the freeze, where the freeze prompt information is used to prompt the target terminal of the cause of the freeze event.

7. The live broadcast reporting data processing device according to claim 6, wherein The network condition judgment unit is further configured to: When it is detected that the sum value of the audio reception bit rate and the video reception bit rate is greater than the reception speed, it is determined that the network condition of the viewing end reaches a preset freeze condition. When it is detected that the sum of the audio reception bitrate and the video reception bitrate is less than or equal to the reception speed, it is determined that the network condition of the viewing end does not reach the preset lag condition.

8. The live broadcast reporting data processing device according to claim 6, characterized in that It further includes a prompt message sending module for: If it is determined according to the playback detection result that the playback of the live data stream is normal, a refresh prompt message is sent to the viewing end, and the refresh prompt message is used to prompt to refresh the live broadcast room.

9. The live broadcast reporting data processing device according to claim 8, wherein The data reception module is further configured to obtain the second interface image data of the viewing end; The device further includes: A log acquisition module, configured to acquire the log data of the viewing end when it is determined based on the second interface image data that a lag event occurs at the viewing end; A code call information reading module, configured to read the code call information of the live application program of the viewing end from the log data; The lag location module is further configured to: if it is determined according to the code call information that the code call of the viewing end is abnormal, determine that the cause of the lag event is the application program exception of the viewing end.

10. The live broadcast reported data processing device according to claim 6 or 9, characterized in that, The lag location module is further configured to: When it is detected that there is a lag object in the first interface image data or the second interface image data, it is determined that a lag event occurs at the viewing end; wherein, the lag object includes one or more of a black screen image and a lag identifier.

11. A computer device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, the steps of the method according to any one of claims 1 to 5 are implemented.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 5 are implemented.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images