CN115314719A

CN115314719A - Live broadcast reported data processing method and device and computer equipment

Info

Publication number: CN115314719A
Application number: CN202110499027.XA
Authority: CN
Inventors: 蒋政胜
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-05-08
Filing date: 2021-05-08
Publication date: 2022-11-08

Abstract

The application relates to the technical field of computers, and provides a live broadcast reported data processing method, a live broadcast reported data processing device and computer equipment, wherein the method comprises the following steps: receiving live broadcast reported data sent by a watching end, wherein the live broadcast reported data comprises first interface image data of the watching end; when the fact that the watching end is blocked is determined based on the live broadcast reported data, a target terminal and a blocking reason for triggering the blocking event are determined based on the first interface image data, the target terminal comprises at least one terminal of the watching end and a main broadcast end, and the main broadcast end is a terminal corresponding to a live broadcast room where the watching end is located when the live broadcast reported data are sent; and sending a jamming prompt message to the target terminal based on the jamming reason, wherein the jamming prompt message is used for prompting the target terminal to trigger the jamming reason of the jamming event. The method can analyze and determine whether the terminal which gives rise to the pause event is the watching end or the anchor end only according to the interface image of the watching end, determines the pause reason, and has high efficiency in positioning the reason of the live pause event.

Description

Live broadcast reported data processing method and device and computer equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a live broadcast reported data processing method and apparatus, and a computer device.

Background

The live broadcast is an information network distribution mode which synchronously makes and distributes information along with the occurrence and development processes of events and has a bidirectional circulation process on site. With the development of network technology, live broadcasting has been deeply conducted into various industries.

Under the influence of various factors, the phenomena of blockage and the like when a user watches live broadcast are common, and the blockage of the live broadcast includes but is not limited to the situations that a live broadcast picture is suddenly blacked and has no response and the like in the process of watching the live broadcast. Live broadcast card pause can bring bad experience to the user watching, so that corresponding reasons need to be analyzed when the live broadcast card pause occurs, and the live broadcast service can be better provided for the user.

Disclosure of Invention

Therefore, in order to solve the above technical problems, it is necessary to provide a live broadcast reported data processing method, a live broadcast reported data processing apparatus, a computer device, and a storage medium, which are capable of automatically determining a live broadcast stuck reason.

A live broadcast reported data processing method comprises the following steps:

receiving live broadcast reported data sent by a watching end, wherein the live broadcast reported data comprises first interface image data of the watching end;

when the watching end is determined to have a stuck event based on the live broadcast reported data, determining a target terminal and a stuck reason for causing the stuck event based on the first interface image data, wherein the target terminal comprises at least one terminal of the watching end and a main broadcasting end, and the main broadcasting end is a terminal corresponding to a live broadcast room where the watching end is located when the watching end sends the live broadcast reported data;

and sending a jamming prompt message to the target terminal based on the jamming reason, wherein the jamming prompt message is used for prompting the target terminal to cause the jamming reason of the jamming event.

A live report data processing apparatus, the apparatus comprising:

the data receiving module is used for receiving live broadcast reported data sent by a watching end, wherein the live broadcast reported data comprises first interface image data of the watching end;

the system comprises a click-through positioning module, a click-through positioning module and a click-through positioning module, wherein the click-through positioning module is used for determining a target terminal and a click-through reason for causing a click-through event based on the live broadcast report data when the fact that the watching end has the click-through event is determined based on the live broadcast report data, the target terminal comprises at least one terminal of the watching end and a main broadcast end, and the main broadcast end is a terminal corresponding to a live broadcast room where the watching end is located when the live broadcast report data is sent;

and the sending module is used for sending a jamming prompt message to the target terminal based on the jamming reason, wherein the jamming prompt message is used for prompting the target terminal to cause the jamming reason of the jamming event.

A computer device comprising a memory storing a computer program and a processor implementing the following steps when the computer program is executed:

A computer-readable storage medium, on which a computer program is stored which, when executed by a processor, carries out the steps of:

and sending a jamming prompt message to the target terminal based on the jamming reason, wherein the jamming prompt message is used for prompting the jamming reason of the jamming event caused by the target terminal.

The live broadcast reported data processing method, the live broadcast reported data processing device, the computer equipment and the storage medium receive reported data which are uploaded by a viewing terminal and aim at live broadcast, wherein the reported data comprise first interface image data; the target terminal comprises at least one of a watching terminal or a main broadcasting terminal, and the main broadcasting terminal is a terminal corresponding to a live broadcasting room where the watching terminal is located when data is reported in a live broadcasting mode. According to the method, when a user watches live broadcast, whether a stuck event occurs or not is determined based on the interface image acquired from the watching end, when the stuck event occurs, whether the reason for issuing the stuck event is the watching end or the anchor end and the stuck reason is determined based on the interface image, the stuck prompt information is sent to the target terminal based on the stuck reason, whether the terminal for issuing the stuck event is the watching end or the anchor end can be analyzed and determined only according to the interface image of the watching end, the stuck reason is determined, and the efficiency of locating the reason for generating the live broadcast stuck event is high.

Drawings

Fig. 1 is a diagram of an application environment of a live broadcast reporting data processing method in an embodiment;

fig. 2 is a schematic flowchart illustrating a live broadcast report data processing method according to an embodiment;

FIG. 3 is a flowchart illustrating an embodiment of determining a target terminal initiating a stuck event and a stuck reason based on first interface image data;

FIG. 4 is a diagram illustrating debugging of floating layer information in an embodiment;

fig. 5 is a schematic flow chart of a live broadcast reported data processing method in another embodiment;

FIG. 6 is a diagram illustrating function call information in an exemplary embodiment;

fig. 7 is a schematic flow chart of a live broadcast reported data processing method in an embodiment;

FIG. 8 is a schematic diagram of a stuck flag in one embodiment;

FIG. 9 is a diagram of an exception sheet in one embodiment;

fig. 10 is a block diagram of a live broadcast report data processing apparatus according to an embodiment;

FIG. 11 is a diagram illustrating an internal structure of a computer device in one embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of and not restrictive on the broad application.

In the related technology, when a pause in a process of watching live broadcast by a user is detected, the user at a watching end generally feeds back a pause event, related personnel obtain a current log after receiving the feedback to try to reproduce, the reason of pause is manually analyzed, and the reason of pause caused by manual reproduction needs to be analyzed by the related personnel to try various possible reasons; moreover, because the jam may be caused by the viewing end or the playing end, the logs of the viewing end and the playing end need to be acquired respectively for analysis. The manual analysis and positioning of the cause of the blockage are carried out in the mode, and the efficiency is low. Therefore, the application provides a live broadcast reported data processing method.

The live broadcast reported data processing method provided by the application can be applied to the application environment shown in fig. 1. Wherein the detection server 104 communicates with the viewer side 101 and the anchor side 102 via a network. The server 104 receives reported data of the watching end 101 for live broadcasting, wherein the reported data include first interface image data, when a jam event occurs in the watching end 101 based on the first interface image data, a target terminal and a jam reason for issuing the jam event are determined based on the first interface image data, and then a jam prompt message is sent to the target terminal based on the jam reason, and the jam prompt message is used for prompting the target terminal to issue the jam reason for the jam event; the target terminal comprises at least one of a watching end 101 or an anchor end 102; the watching terminal 101 is a terminal used by a user to watch live broadcast, and the anchor terminal 102 is a terminal corresponding to a live broadcast room where the watching terminal is located when data is reported in live broadcast. The watching end 101 and the anchor end 102 may be, but not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices, and the detection server 104 may be implemented by an independent server or a server cluster composed of a plurality of servers.

In an embodiment, as shown in fig. 2, a live broadcast report data processing method is provided, which is described by taking the method applied to the detection server in fig. 1 as an example, and includes steps S210 to S230.

Step S210, receiving live broadcast reported data sent by a watching end, wherein the live broadcast reported data comprises first interface image data of the watching end.

Wherein, the viewing end represents a terminal used when the user views the live broadcast. And the watching end reports the live broadcast reported data to the detection server, wherein the live broadcast reported data comprises interface image data of the watching end. It should be noted that, in this embodiment, in order to distinguish from the interface image data in the following embodiment, the interface image data in the live broadcast report data is denoted as the first interface image data, and the "first" and the "second" referred to in the following embodiment are only used for distinguishing and naming, and do not represent any actual meaning. In one embodiment, the number of the first interface image data may be one or more than two.

The interface image data represents data including an interface; further, in this embodiment, the interface image data represents an interface image when the viewing end views live broadcast in a live broadcast room, and may be a static image such as a screenshot, a dynamic image, or a video; wherein, the static image is a screenshot, the dynamic image or the video is data recorded by a screen recording application and containing the screen change situation in a period of time. In one embodiment, the interface image data is live room interface data when a stuck event occurs, or interface data displaying viewing-end related operation data when a stuck event occurs, or the like.

In one embodiment, the interface image data can be manually intercepted by a user, and live broadcast reporting data is sent to the detection server based on the intercepted interface image data; furthermore, the user can intercept and report the interface image when watching the live broadcast in the live broadcast room at any time, and can also intercept and report the image when considering that a pause event occurs when watching the live broadcast, and the like; in this embodiment, the user uploads the screenshot when considering that the click-through event occurs, and the detection server determines whether the live click-through event actually occurs at the watching end based on the live broadcast report data.

In another embodiment, the interface image data may also be interface images of the viewing terminal that are automatically captured at predetermined intervals when the viewing terminal is in the live broadcast room, and live broadcast report data is sent to the detection server based on the captured interface images. In other embodiments, the viewer may send the live report data in other manners. The interface image is sent to the detection server through automatic interception, and when a live broadcast blockage event occurs at the watching end, the live broadcast blockage event can be detected quickly, positioning and analysis of blockage reasons are carried out, and live broadcast blockage detection and blockage reason positioning efficiency is improved.

In one embodiment, the live broadcast reported data comprises interface image data and log data related to the operation of a live broadcast application program of a watching end; in other embodiments, the live report data may also include other data.

And step S220, when the fact that the watching end is blocked is determined based on the live broadcast reported data, a target terminal and a blockage reason for triggering the blockage event are determined based on the first interface image data, wherein the target terminal comprises at least one terminal of the watching end and the anchor end.

The anchor terminal is a terminal corresponding to the live broadcast room where the watching terminal is located when sending the live broadcast reported data.

In one embodiment, when the viewing terminal is in a live broadcast room to view a live broadcast, the live broadcast pause event includes, but is not limited to, a situation that a live broadcast picture is blacked, does not move, has no response, and the like. Further, whether the watching end generates the jamming event is determined by detecting whether the jamming object exists in the first interface image. The card pause object comprises one or more of a black screen image and a card pause identification; the black screen image represents an image displayed in an interface when the viewing end has a black screen, and the black screen is a phenomenon in the video playing process; the katton mark is a mark representing katton, and the commonly used katton mark is similar to a ' chrysanthemum with turns ', and a character prompt ' how to see how soon after the CPU strays? "and the like. In the embodiment, whether the watching end generates the stuck event or not is determined by detecting whether the first interface image contains the black screen image and/or the stuck identification or not.

In one embodiment, whether a stuck object exists in the first interface image data may be determined by means of object detection. The object detection may detect whether or not a specific object exists from the image data, and further may determine position information of the specific object when the specific object is included in the image. In this embodiment, the target detection of the first interface image data may be implemented in any manner.

Further, in one embodiment, detecting whether a black screen image exists 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 a pixel point of the interface image data; determining a target pixel point of which the hue H (hue) value is within a preset numerical range (which may be (35,77)) in the HSB information from the pixel points of the interface image data; and if the ratio of the target pixel point to the pixel point of the interface image data reaches a preset ratio threshold, determining that the interface image data has a black screen image. In another embodiment, detecting whether the image data of the first interface contains the stuck flag may be performed by image recognition, such as training a model to detect whether the image contains the stuck flag. In other embodiments, whether the first interface image includes the black screen image and/or the katon identifier may be detected in other manners.

The live broadcast watching process of the user is that firstly, the anchor side pushes the picture stream to the cloud side, the cloud side carries out transcoding, then the watching side carries out stream pulling decoding playing and presents the picture stream to the user, and if the anchor side has problems, the downlink user 1 and the downlink user 2 both have problems; if the network problem is a network problem of the viewing end, the user 1 pulls the stream normally and plays normally, and the user 2 may have an abnormality. That is, when the viewing end has a stuck event, it may be the anchor end or the viewing end that has triggered, so in this embodiment, when it is determined that the viewing end has a stuck event, a target terminal that triggers the stuck event is determined based on the first interface image data, and the target terminal may be at least one of the anchor end or the viewing end, and at the same time, a stuck reason that triggers the stuck event is determined based on the first interface image data, such as a device of the anchor end, a network reason, a device of the viewing end, a network reason, and the like.

Further, the specific process of determining the target terminal and the cause of the stuck event based on the first interface image data will be described in detail in the following embodiments, and will not be described herein again.

And step S230, sending the jamming prompt information to the target terminal based on the jamming reason.

The card pause prompting information is used for prompting the target terminal to trigger the card pause reason of the card pause event.

After analyzing and determining the target terminal and the cause of the stuck event, the stuck prompt message may be sent to the target terminal to prompt the corresponding terminal or the user to know the cause of the stuck event, and then corresponding measures may be taken for the stuck event. In one embodiment, when the terminal that triggers the katoon event is determined to be the watching terminal, the katoon prompting message can be sent to the watching terminal, and the cause of the katoon event is sent to the user to know through the katoon prompting message. If the anchor receives the pause prompt message at the anchor, the anchor is informed that the pause event is caused by the anchor, and operations such as changing the network, adjusting the live broadcast definition and the like can be tried to solve the pause event.

In one embodiment, after determining the target terminal and the cause of the morton event based on the first interface image data, the method further includes: sending a solution corresponding to the cause of the jamming to the target terminal; wherein, when the card dun reason is the anchor reason, the solution includes: prompting the anchor to check the equipment and the network; when the cause of katton is the cause of the watching end, the solution comprises the following steps: and prompting the user at the watching end to try to switch networks, refresh the live broadcast room or switch the definition of the live broadcast data. In this embodiment, after the anchor receives the solution at the anchor, the anchor can check the device and network problems according to the prompt of the solution; after receiving the solution at the watching end, the user at the watching end can try to switch the network, refresh the live broadcast room, switch the definition of live broadcast data and the like according to the prompt of the solution so as to solve the pause event.

In one embodiment, if it is determined that the target terminal which gives rise to the stuck event is the anchor terminal, in addition to sending the stuck prompt message to the anchor terminal, the method further includes sending the stuck prompt message to the watching terminal, where the stuck prompt message is used to prompt the watching terminal user that the reason for causing the live stuck is the anchor terminal reason.

The live broadcast reported data processing method comprises the steps of receiving reported data which are uploaded by a watching end and aim at live broadcast, wherein the reported data comprise first interface image data, when a jam event occurs at the watching end based on the first interface image data, a target terminal and a jam reason which lead the jam event based on the first interface image data are determined, and then jam prompt information is sent to the target terminal based on the jam reason and is used for prompting the target terminal to lead the jam reason of the jam event; the target terminal comprises at least one of a watching terminal or a main broadcasting terminal, and the main broadcasting terminal is a terminal corresponding to a live broadcasting room where the watching terminal is located when data is reported in a live broadcasting mode. According to the method, when a user watches live broadcast, whether a stuck event occurs or not is determined based on the interface image acquired from the watching end, when the stuck event occurs, whether the reason for issuing the stuck event is the watching end or the anchor end and the stuck reason is determined based on the interface image, the stuck prompt information is sent to the target terminal based on the stuck reason, whether the terminal for issuing the stuck event is the watching end or the anchor end can be analyzed and determined only according to the interface image of the watching end, the stuck reason is determined, and the efficiency of locating the reason for generating the live broadcast stuck event is high.

In one embodiment, as shown in fig. 3, determining a target terminal and a morton reason for triggering a morton event based on first interface image data includes step S221: and if the preset prompt information exists in the first interface image data, determining that a target terminal which triggers the card pause event is a main broadcasting terminal, and determining that the card pause reason is the main broadcasting terminal reason.

The preset prompting information is used for prompting the abnormality of the anchor terminal. In an embodiment, when it is detected that the anchor terminal is abnormal, such as a network outage or a line drop, and the like, the picture stream of the anchor terminal may not be normally transmitted to the cloud, and the viewing terminal cannot normally view the picture stream, so that a jam occurs, a preset prompt message is displayed in an interface of the viewing terminal to prompt a user at the viewing terminal that the current jam is caused by the abnormality of the anchor terminal. In one embodiment, the preset prompt message is "please endure for waiting if the current anchor equipment is unstable"; in other embodiments, the preset prompting message can be set as other messages according to actual conditions.

In an embodiment, whether a field with preset prompt information appears in the first interface image data or not can be determined by performing target field detection on the first interface image data, and if the preset prompt information exists in the first interface image data, the cause of the pause is determined to be the cause of the anchor. In one embodiment, a target field detection model for detecting the preset prompting information may be trained in advance, and the trained target field detection model is used to detect the first interface image data to determine whether the preset prompting information exists. In another embodiment, the character recognition may be performed on the first interface image data to output the character in the first interface image, and the field comparison between the character and the preset prompting information may determine whether the field corresponding to the preset prompting information exists in the first interface image data. The character recognition of the image can be realized in any mode. In other embodiments, the target field detection of the first interface image data may be implemented by any other manner.

If the preset prompt information exists in the viewing terminal interface at the time of the occurrence of the pause according to the log data, the target terminal which causes the current pause event can be determined as the anchor terminal, and further the reason which causes the current pause event can be determined as the anchor terminal reason. Further, after determining that the target terminal which triggers the stuck event is the anchor terminal and the stuck reason which triggers the stuck event is the anchor terminal, sending stuck prompt information to the anchor terminal to prompt the anchor to take corresponding measures.

In this embodiment, whether a terminal that causes a current stuck event is a anchor terminal is determined by detecting whether preset prompt information that prompts an abnormality of the anchor terminal exists in the first interface image data, so that live broadcast report data reported by a viewing terminal can be detected and the reason why the stuck event is caused is determined at the anchor terminal, thereby avoiding the problem that the data of the anchor terminal needs to be analyzed and the reason whether the live broadcast report data is the anchor terminal when the stuck event occurs, quickly locating the stuck reason, and improving the processing efficiency of the live broadcast report data.

In one embodiment, please continue to refer to fig. 3, the method further includes step S222 and step S224.

Step S222, if the first interface image data is detected to have no preset prompt information, debugging floating layer information of a live broadcast room where the watching end is located when sending the live broadcast reported data is obtained.

The debugging floating layer information represents debugging information of the watching end at a certain moment, and is displayed in an interface of the watching end in a floating layer mode. In one embodiment, the debugging floating layer information includes network operation data of the viewing end, a network address corresponding to a live data stream of a live broadcast room where the viewing end is currently located, a player type, a resolution, and the like.

In one embodiment, a switch control of the debugging floating layer is arranged in the watching end, and a user can select whether to display the debugging floating layer information in the interface or not through the switch control. Further, in an embodiment, the live broadcast report data is actively uploaded by the user, and when the user finds a live broadcast pause, the user may select to intercept an interface image including the debugging floating layer information and upload the interface image to the detection server, so that the detection server locates a pause reason for triggering a pause event according to the debugging floating layer information.

In another embodiment, the live broadcast reporting data is to automatically intercept and report the first interface image data, in this embodiment, debug information of a viewing end is acquired while the first interface image data is automatically intercepted, and the acquired debug information is superimposed in the first interface image data in a floating layer manner, in this embodiment, debug floating layer information is acquired from the first interface image data. FIG. 4 is a diagram illustrating debugging of floating layer information in an exemplary embodiment.

Step S223, reading the network operation data of the viewing end from the debugging floating layer information.

The network operation data includes related data representing the network operation status of the watching end, and whether the current network operation status of the watching end is good or not can be determined by combining the network operation data. Where the receiving speed denotes the speed of receiving a live video stream in kbps (kilobits per second). The Frame rate (Frame rate) is the frequency (rate) at which bitmap images called units of frames appear continuously on the display. The video rate is the number of bits of video data transmitted per unit time during data transmission, and is generally set to kbps. The audio code rate video code rate is the number of bits of audio data transmitted per unit time during data transmission, and is generally used in kbps. In other embodiments, the operational data of the viewer may also include other data. In other embodiments, the network operational data may also include other data.

Step S224, if the network condition of the watching end is determined to reach the preset blocking condition according to the network operation data, determining that the target terminal which triggers the blocking event is the watching end, and the blocking reason is the network reason of the watching end.

The preset stuck condition refers to a preset stuck condition, and can be specifically set according to actual conditions. In one embodiment, when the network condition of the watching end reaches a preset stuck condition, the network condition is determined to be poor if the network of the watching end is stuck.

In one embodiment, determining the network condition of the viewer based on the network operational data comprises: calculating the sum of the audio receiving code rate and the video receiving code rate in the network operation data, comparing the sum with the receiving speed, determining the comparison result of the sum and the receiving speed, and determining the network condition of the watching end according to the comparison result. Further, in a specific embodiment, if the sum of the audio receiving code rate and the video receiving code rate is greater than the receiving speed, determining that the network condition of the watching end reaches a preset blocking condition; and if the sum of the audio receiving code rate and the video receiving code rate is less than or equal to the receiving speed, determining that the network condition of the watching end does not reach the preset pause condition.

Further, if the fact that the network condition of the watching end reaches the preset blocking condition is determined according to the operation data, the fact that the network condition of the watching end is poor at the blocking moment is indicated, the target terminal which gives rise to the blocking event is determined as the watching end, and the blocking reason which gives rise to the blocking event is determined as the network reason of the watching end.

In this embodiment, the network condition when the watching end sends live broadcast morton data is determined by obtaining the debugging floating layer information of the watching end, and whether the watching end has the network morton is determined based on the network condition, so as to determine whether the morton reason of the morton event is the network reason of the watching end. Further, if the cause of the stuck is determined to be the cause of the network of the watching end, the stuck prompt message can be sent to the watching end to prompt the user that the network condition is poor, and the user can try to switch the network to watch live broadcast based on the stuck prompt message.

In one embodiment, after determining that the network condition of the watching end reaches a preset stuck condition according to the network operation data, determining that a target terminal which causes a stuck event is the watching end, and the stuck reason is a network reason of the watching end, sending stuck prompt information to the watching end based on the stuck reason, the method further includes: and sending a solution to the watching end, wherein the solution is used for prompting the user to try to switch the network to watch the live broadcast.

Further, in an embodiment, please continue to refer to fig. 3, the method further includes steps S225 to S227.

And step S225, if the network condition of the watching end is determined to not reach the preset stuck condition according to the running data, reading the network address corresponding to the live broadcast data stream of the live broadcast room from the debugging floating layer information.

If the network condition of the watching end when sending the live broadcast reported data is determined not to reach the preset stuck condition, the network condition of the watching end is indicated to possibly have no problem, and the stuck reason needs to be analyzed from other angles.

The method comprises the following steps that a watching end user watches live broadcast, and a live broadcast data stream of a live broadcast room is pulled from a cloud end, specifically, the live broadcast data stream is pulled from a network address corresponding to the live broadcast data stream; the network address corresponding to the live data stream in the live broadcast room indicates an address for acquiring the live data stream. And acquiring the live broadcast data stream of the corresponding live broadcast room based on the network address. In one embodiment, the network address corresponding to the live data stream of the live broadcast room is a Uniform Resource Locator (URL), also called a web address, which is a standard address of a resource on the internet. In one embodiment, the live data stream of the live room can be pulled through the uniform resource locator of the live data stream, so that the live data stream can be watched.

Step S226, acquiring the live data stream based on the network address, and performing play detection on the live data stream based on the streaming playing platform to obtain a play detection result.

The streaming playing platform is a Web Wide Web (World Wide Web) end video player, a normal streaming address is input, and live video can be played normally. In this embodiment, a network address of a live data stream is input in a stream playing platform to check whether the live data stream can be normally played, so as to obtain a playing detection result. In one embodiment, the detection of playing the live data stream based on the stream playing platform and the uniform resource locator includes: and uploading the uniform resource locator to a stream playing platform for playing to obtain a playing detection result.

Step S227, if it is determined that the playing of the live data stream is normal according to the playing detection result, determining that the target terminal that triggers the stuck event is the watching end, and the cause of the stuck event is the reason of the watching end.

If the playing detection result shows that the live broadcast data stream can be normally played on the stream playing platform, the pause event is represented to be possibly caused by the non-network reason of the watching end, such as the equipment of the watching end is incompatible; it may also be a network jitter problem at the viewing end, so in this embodiment, the cause of the stuck event is located as the viewing end cause.

In this embodiment, if it is determined that the anchor terminal is not abnormal and the network of the viewing terminal is not abnormal, the network address of the live broadcast data stream is obtained, and the live broadcast data stream is detected by playing on the stream playing platform based on the network address, so as to determine whether the live broadcast stream is abnormal or not and can be normally played. If the live data stream can be played normally on the stream playing platform, the cause of the pause may still be the reason of the viewing end.

Further, in an embodiment, as shown in fig. 5, the method further includes step S510: and if the broadcast of the live broadcast data stream is determined to be normal according to the broadcast detection result, sending refreshing prompt information to the watching end, wherein the refreshing prompt information is used for prompting refreshing of the live broadcast room.

And if the broadcast of the live broadcast data stream is determined to be normal according to the broadcast detection result, the fact that the card pause triggering event is irrelevant to the live broadcast data stream pushed to the cloud end by the anchor broadcast end is shown, and therefore refreshing prompt information is sent to a user and used for prompting refreshing of a live broadcast room. In one embodiment, the refreshing live broadcast room can be actively refreshed by a user, and can also be automatically refreshed by a watching end; the live broadcasting room can be refreshed in a mode of exiting the live broadcasting room and reentering the live broadcasting room, and a mode of reloading the live broadcasting data stream can also be adopted. In other embodiments, refreshing the live room may also be accomplished in any other manner. In this embodiment, the refresh prompt information is the solution described in the above embodiments.

Further, in an embodiment, please continue to refer to fig. 5, after the refresh prompt message is sent to the viewer, the method further includes steps S520 to S550. Wherein:

step S520, acquiring second interface image data of the viewing end.

In one embodiment, the second interface image data of the watching end is the interface image data of the watching end after the live broadcasting room is refreshed based on the refreshing prompt information, and whether a stuck event still exists in the watching end after the live broadcasting room is refreshed is determined based on the second interface image data.

In step S530, when it is determined that the viewing end has a stuck event based on the second interface image data, log data of the viewing end is acquired.

The log data is log data of live broadcast application. The Log (Log) refers to a collection of operations of the specified objects of the system and the operation results thereof in order of time. Each log file is made up of log records, each describing a separate system event. Typically, the system log is a text file that the user can read directly, containing a timestamp and an information or other information specific to the subsystem. In one embodiment, the log data of the watching end can be acquired from the watching end by the detection server after the detection server determines that the card pause event still occurs after the watching end refreshes the live broadcast room through the second interface image data; in another embodiment, the log data of the viewer may be obtained when the second interface image data is obtained.

In one embodiment, when the fact that the jamming object exists in the second interface image data is detected, the fact that the jamming event occurs at the watching end is judged; wherein the stuck object comprises one or more of a black screen image and a stuck logo.

In one embodiment, the log data of the viewer may include: the method comprises the steps that network operation data of a watching end at the moment corresponding to second interface image data, function call information of a live broadcast application program of the watching end at the moment corresponding to the second interface image data, and whether a preset prompt message is displayed on an interface of the watching end at the moment 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 further include other contents.

Step S540, reading the code calling information of the live application program of the viewer from the log data.

The live broadcast application program represents an application program used when a user watches live broadcast; the code calling information represents calling condition information of each function when the live application program runs; the code call information may be read from the log data. For example, the function call information shown in fig. 6, where a pair of start canvas and end canvas is shown in a solid box, in the embodiment, it is detected whether the function is called in pair.

In 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 stuck event is an application program abnormality of the viewing end.

In this embodiment, when it is determined that the anchor side is not abnormal, the network of the viewing side is not abnormal, and the live broadcast data stream can be normally played, a code calling condition of a program in log data is detected, and it is determined whether a code calling of a live broadcast application program is abnormal, and the abnormal code calling is also a cause that the viewing side is likely to be stuck.

In an embodiment, a normal code calling situation may be preset, for example, for a function such as drawing, the normal code calling situation is set to be a paired call, so that when it is determined by analysis that the drawing function at the viewing end is not paired, it is determined that an application program is abnormal, and at this time, an abnormal list is generated and sent to a relevant person for detection. In other embodiments, the normal condition of other function calls can be set, and then whether the abnormal condition of the code call exists or not can be determined by analyzing the function call condition in the log data.

In another embodiment, if the live data stream is determined to be played normally according to the play detection result, acquiring the log data of the anchor terminal, and reading the code calling condition of the anchor terminal from the log data of the anchor terminal; and then determining whether the exception exists according to the code calling condition of the anchor terminal. The detection of whether the code calling condition of the anchor terminal is abnormal or not can be the same as the detection mode of the watching terminal.

In the embodiment, if it is determined that the anchor terminal is not abnormal and the network of the watching terminal is not abnormal, the live broadcast data stream can be normally played, and a pause event still exists after the live broadcast room is refreshed, whether an abnormality exists is analyzed from the code calling condition of the live broadcast application program so as to determine whether the code calling condition of the live broadcast application program has a problem; if the function existing in a pair is not called in a pair, a child thread calling the function possibly continuously occupies a drawing, so that a Central Processing Unit (CPU) is surged, and then a pause event occurs in a live broadcast room; further, if the code calling of the live application program is determined to have abnormality according to the code calling information, an abnormality sheet is sent to related personnel (such as developers) to prompt the related personnel to perform corresponding processing.

In another embodiment, if the fact that the watching end has the Kanton event is determined according to the second interface image data, an abnormal sheet is generated based on log data of the watching end, and the abnormal sheet is sent to related personnel.

If the watching end still cannot normally watch the live broadcast after the live broadcast room is determined to be refreshed according to the second interface image data, namely a seizure event occurs, an abnormal order needs to be sent to related personnel of the live broadcast application program, and related developers are prompted to access to determine the seizure reason. In one embodiment, generating the exception sheet based on the log data of the watching end comprises: extracting target data corresponding to the key fields in the log data, and packaging the target data to generate an exception list. Wherein the target data may include: the method comprises the steps of determining the occurrence time of a pause event, determining whether preset prompt information for prompting the abnormality of a main broadcasting end exists or not when the pause event occurs, operating data of a watching end at the moment of the pause event, a network address of a live broadcast data stream, code calling information of a live broadcast application program of the watching end and the like.

The application also provides an application scene, and the application scene applies the live broadcast reported data processing method. Specifically, as shown in fig. 7, the application of the live broadcast reported data processing method in the application scenario is as follows:

s100, receiving live broadcast reported data sent by a watching end, wherein the live broadcast reported data comprises first interface image data.

S200, determining whether a jamming event occurs at the watching end based on the live broadcast reported data. Specifically, whether a stuck object, such as a black screen image or a stuck mark (e.g., a stuck mark of "chrysanthemum of circles" shown in fig. 8) exists in the first interface image data is detected. The detection of the stuck object in the first interface image data can be realized by image recognition and/or color recognition.

S300, sending a stuck event based on live broadcast reported data

S400, when a stuck event is sent based on live broadcast reported data, detecting in first interface image data, determining whether preset prompting information for prompting abnormality of a main broadcasting end exists in the first interface image data, if so, S401, determining that a target terminal for triggering the stuck event is the main broadcasting end, and a stuck reason for triggering the stuck event is a main broadcasting end reason. S402, sending the morton prompt message to the anchor terminal.

If the first interface image data is determined to have no preset prompt information, whether the first interface image data is the reason of the watching end or not is checked:

for the problem of the watching end, firstly, judging the network condition of the watching end: s500, acquiring debugging floating layer information of a live broadcast room where a watching end is positioned when sending live broadcast report data; reading network operation data of a watching end from the debugging floating layer information, wherein the network operation data comprises a video code rate, an audio code rate and a receiving rate; s501, if the fact that the network condition of the watching end reaches the preset blocking condition is determined according to the network operation data, the target terminal which gives rise to the blocking event is determined to be the watching end, and the blocking reason is the network reason of the watching end. The method specifically comprises the following steps: (video code rate + audio code rate) > receiving rate, which indicates that the network condition of the watching end reaches a preset blocking condition, the blocking event is caused by the watching end, and the blocking reason is determined to be the network reason of the watching end.

Secondly, if the network condition of the watching end is normal, judging whether the live broadcast data stream of the live broadcast room is normally played: when the (video code rate + audio code rate) < = receiving rate, determining that the network condition of the watching end does not reach a preset pause condition, S502, reading a network address (URL) corresponding to a live broadcast data stream of a live broadcast room from debugging floating layer information; acquiring a live data stream based on the network address, and performing play detection on the live data stream based on the stream playing platform to obtain a play detection result; s503, if the playing of the live data stream is determined to be normal according to the playing detection result, the target terminal which gives the katton event is determined to be the watching end, and S5041, the katton reason is the reason of the watching end.

Further, in S5042, if it is determined that the live data stream is played normally according to the play detection result, a refresh prompt message is sent to the viewing end to prompt refreshing of the live room. After prompting to refresh the live broadcast room, S505, acquiring second interface image data of a watching end; s506, when the fact that the watching end is blocked is determined based on the second interface image data, S507, log data of the watching end are obtained; s508, reading code calling information of a live broadcast application program of a watching end from log data; s509, if the code calling abnormality of the watching end is determined according to the code calling information, S5010, determining that the cause of the card pause event is the application program abnormality of the watching end.

In another embodiment, if it is determined that the playing of the live data stream is abnormal according to the playing detection result, it is determined that the target terminal which triggers the stuck event is the anchor terminal, and the stuck reason which triggers the stuck event is the anchor terminal reason.

Finally, if the target terminal which gives off the stuck event is determined to be the anchor terminal, sending stuck prompt information to the anchor terminal to prompt the anchor terminal to give off the stuck reason of the stuck event; and if the target terminal for issuing the stuck event is determined to be the watching end, sending stuck prompt information to the watching end to prompt a user watching the live broadcast to issue the stuck reason of the stuck event.

In another embodiment, if the live broadcast data stream is determined to be normally broadcast according to the broadcast detection result, the code is determined to be normally invoked according to the code invoking information of the live broadcast application program of the watching terminal, which indicates that the terminal and the cause of the pause event cannot be determined. Further, if the target terminal and/or the cause of the seizure causing the live broadcast seizure event cannot be determined, or if the live broadcast application program is determined to be abnormal, an abnormal sheet can be generated and sent to related personnel, so that the related personnel can investigate the seizure event. FIG. 9 is a schematic diagram of an exception sheet according to an exemplary embodiment.

According to the live broadcast reported data processing method, when live broadcast reported data of a live broadcast is received, whether a jam event occurs at a watching end is determined according to the live broadcast reported data, if the jam event occurs, whether the jam event causing the jam event is a main broadcasting end reason, a network reason of the watching end, network jitter of the watching end and other reasons are sequentially checked according to first interface image data, abnormal reasons are called by codes of a live broadcast application program of the watching end, automation of the whole check process of the jam event is achieved, various technical means are used, whether preset prompt information exists in the interface image data sent by the watching end, whether the network condition of the watching end reaches a preset jam condition or not, whether live broadcast data flow in a live broadcast room can be normally played in a streaming playing platform or not is analyzed, whether the code calling of the application program of the watching end is abnormal or not is determined based on log data, the check process is clear, the check time is shortened, the live broadcast jam problem is solved more quickly, and the time of a user is reduced. The method is suitable for all live broadcast on-demand services, has universality and is suitable for the problem of quick positioning in the daily system test process. For the problem of the code level, whether the code calling condition of the application program is abnormal or not is analyzed through log data, a method called in pairs like drawing is avoided, only start is carried out, end is not carried out, and if the abnormal condition is detected, a rapid alarm is given.

It should be understood that, although the steps in the flowcharts involved in the above embodiments are shown in sequence as indicated by the arrows, the steps are not necessarily performed in sequence as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least a part of the steps in each flowchart involved in the above embodiments may include multiple steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of performing the steps or stages is not necessarily sequential, but may be performed alternately or alternately with other steps or at least a part of the steps or stages in other steps.

In an embodiment, as shown in fig. 10, there is provided a live report data processing apparatus, where the apparatus may adopt a software module or a hardware module, or a combination of the two modules to form a part of a computer device, and the apparatus specifically includes: data receiving module 1010, stuck location module 1020 and sending module 1030, wherein:

the data receiving module 1010 is configured to receive live broadcast report data sent by a watching end, where the live broadcast report data includes first interface image data of the watching end;

the mortgage positioning module 1020 is configured to determine, based on the first interface image data, a target terminal and a mortgage reason for issuing a mortgage event when it is determined that a viewing end has a mortgage event based on live broadcast report data, where the target terminal includes at least one of the viewing end and a anchor end, and the anchor end is a terminal corresponding to a live broadcast room where the viewing end is located when the live broadcast report data is sent;

the sending module 1030 is configured to send a stuck prompt message to the target terminal based on the stuck reason, where the stuck prompt message is used to prompt the target terminal to send the stuck reason of the stuck event.

The live broadcast reported data processing device receives reported data which are uploaded by a viewing end and aim at live broadcast, wherein the reported data comprise first interface image data, when a jam event occurs at the viewing end based on the first interface image data, a target terminal and a jam reason which lead the jam event are determined based on the first interface image data, and then jam prompt information is sent to the target terminal based on the jam reason and is used for prompting the target terminal to lead the jam reason of the jam event; the target terminal comprises at least one of a watching terminal or a main broadcasting terminal, and the main broadcasting terminal is a terminal corresponding to a live broadcasting room where the watching terminal is located when data is reported in a live broadcasting mode. According to the method, when a user watches live broadcast, whether a stuck event occurs or not is determined based on the interface image acquired from the watching end, when the stuck event occurs, whether the reason for issuing the stuck event is the watching end or the anchor end and the stuck reason is determined based on the interface image, the stuck prompt information is sent to the target terminal based on the stuck reason, whether the terminal for issuing the stuck event is the watching end or the anchor end can be analyzed and determined only according to the interface image of the watching end, the stuck reason is determined, and the efficiency of locating the reason for generating the live broadcast stuck event is high.

In one embodiment, the morton location module 1020 of the apparatus includes a prompt message detection unit configured to: and if the preset prompt information is detected to exist in the first interface image data, determining that a target terminal which triggers the card pause event is a main broadcasting terminal, and determining that the card pause reason is the main broadcasting terminal reason, wherein the preset prompt information is used for prompting the abnormality of the main broadcasting terminal.

In one embodiment, the morton positioning module 1020 of the apparatus further comprises: the debugging floating layer information acquisition unit is used for acquiring debugging floating layer information of a live broadcast room where the watching end is positioned when sending live broadcast reported data if the first interface image data is detected to have no preset prompt information; the network operation data acquisition unit is used for reading the network operation data of the watching end from the debugging floating layer information; and the network condition judging unit is used for determining that the target terminal which gives rise to the stuck event is the watching terminal and the stuck reason is the network reason of the watching terminal if the network condition of the watching terminal reaches the preset stuck condition according to the network operation data.

In one embodiment, the morton positioning module 1020 of the apparatus further comprises: the network address reading unit is used for reading a network address corresponding to a live broadcast data stream of the live broadcast room from the debugging floating layer information if the network condition of the watching end is determined to not reach the preset pause condition according to the running data; the playing detection unit is used for acquiring the live data stream based on the network address and carrying out playing detection on the live data stream based on the streaming playing platform to obtain a playing detection result; the morton positioning module 1020 is further configured to: and if the live data stream is determined to be normally played according to the play detection result, determining that the target terminal which gives rise to the pause event is the viewing terminal, and the pause reason is the viewing terminal reason.

In an embodiment, the network condition determining unit of the apparatus is further configured to: when the sum of the audio receiving code rate and the video receiving code rate is detected to be larger than the receiving speed, determining that the network condition of the watching end reaches a preset blocking condition; and when the sum of the audio receiving code rate and the video receiving code rate is detected to be less than or equal to the receiving speed, determining that the network condition of the watching end does not reach the preset pause condition.

In one embodiment, the above apparatus further comprises: and the prompt information sending module is used for sending refreshing prompt information to the watching end if the playing of the live broadcast data stream is determined to be normal according to the playing detection result, and the refreshing prompt information is used for prompting the refreshing of the live broadcast room.

In an embodiment, the data receiving module of the apparatus is further configured to: acquiring second interface image data of a watching end; the above-mentioned device still includes: the log acquisition module is used for acquiring log data of the watching end when the fact that the watching end is blocked is determined based on the second interface image data; the code calling information reading module is used for reading code calling information of a live application program of a watching end from log data; the morton positioning module 1020 of the above apparatus is further configured to: and if the code calling exception of the viewing end is determined according to the code calling information, determining that the cause of the card pause event is the exception of the application program of the viewing end.

In one embodiment, the stuck position module 1020 of the apparatus is further configured to: when the fact that a stuck object exists in the first interface image data or the second interface image data is detected, judging that a stuck event occurs at the watching end; wherein the stuck object comprises one or more of a black screen image and a stuck logo.

For a specific embodiment of the live broadcast reported data processing apparatus, reference may be made to the above embodiment of the live broadcast reported data processing method, which is not described herein again. All modules in the live broadcast reported data processing device can be completely or partially realized by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as shown in fig. 11. The computer device includes a processor 1210, memory 1220 (not shown), and a network interface 1230, which are connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium 1221, 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 an operating system and computer programs in the nonvolatile storage medium 1221. The network interface 1230 of the computer apparatus is used for communication with an external terminal through a network connection. The computer program is executed by a processor to realize a live broadcast reported data processing method.

Those skilled in the art will appreciate that the architecture shown in fig. 11 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

In an embodiment, a computer device is further provided, which includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of the above method embodiments when executing the computer program.

In an embodiment, a computer-readable storage medium is provided, in which a computer program is stored which, when being executed by a processor, carries out the steps of the above-mentioned method embodiments.

In one embodiment, a computer program product or computer program is provided that includes computer instructions stored in a computer-readable storage medium. The computer instructions are read by a processor of a computer device from a computer-readable storage medium, and the computer instructions are executed by the processor to cause the computer device to perform the steps in the above-mentioned method embodiments.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware related to instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database or other medium used in the embodiments provided herein can include at least one of non-volatile and volatile memory. Non-volatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical storage, or the like. Volatile Memory can include Random Access Memory (RAM) or external cache Memory. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM), among others.

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above examples only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A live broadcast reported data processing method is characterized by comprising the following steps:

when the watching end is determined to generate a jam event based on the live broadcast reported data, determining a target terminal and a jam reason for causing the jam event based on the first interface image data, wherein the target terminal comprises at least one terminal of the watching end and a main broadcasting end, and the main broadcasting end is a terminal corresponding to a live broadcasting room where the watching end is located when the watching end sends the live broadcast reported data;

2. The live broadcast reported data processing method of claim 1, wherein the determining, based on the first interface image data, a target terminal and a cause of a stuck event that causes the stuck event includes:

and if the first interface image data is detected to have preset prompt information, determining that a target terminal causing the jam event is the anchor terminal, and determining that the jam reason is the anchor terminal, wherein the preset prompt information is used for prompting the abnormality of the anchor terminal.

3. The live report data processing method of claim 2, further comprising:

if detecting that the first interface image data does not have preset prompt information, acquiring debugging floating layer information of a live broadcast room where the watching end is located when sending the live broadcast reported data;

reading the network operation data of the watching end from the debugging floating layer information;

and if the fact that the network condition of the watching end reaches the preset blocking condition is determined according to the network operation data, determining that a target terminal causing the blocking event is the watching end, wherein the blocking reason is the network reason of the watching end.

4. The live report data processing method of claim 3, further comprising:

if the network condition of the watching end does not reach the preset pause condition according to the running data, reading a network address corresponding to the live broadcast data stream of the live broadcast room from the debugging floating layer information;

acquiring the live data stream based on the network address, and performing play detection on the live data stream based on a stream playing platform to obtain a play detection result;

and if the live data stream is determined to be played normally according to the playing detection result, determining that the target terminal causing the pause event is the viewing terminal, and determining that the pause reason is the viewing terminal reason.

5. The live report data processing method of claim 3 or 4, wherein after the network operation data of the watching end is read from the debugging floating layer information, the method further comprises:

when the sum of the audio receiving code rate and the video receiving code rate is detected to be larger than the receiving speed, determining that the network condition of the watching end reaches a preset pause condition;

and when the sum of the audio receiving code rate and the video receiving code rate is detected to be less than or equal to the receiving speed, determining that the network condition of the watching end does not reach a preset blocking condition.

6. The live report data processing method of claim 4, further comprising:

and if the broadcast of the live broadcast data stream is determined to be normal according to the broadcast detection result, sending refreshing prompt information to the watching end, wherein the refreshing prompt information is used for prompting to refresh the live broadcast room.

7. The method for processing live report data according to claim 6, further comprising, after sending the refresh-notice information to said watcher:

acquiring second interface image data of the watching end;

when the fact that the watching end is blocked is determined based on the second interface image data, log data of the watching end are obtained;

reading code calling information of a live application program of the watching end from the log data;

and if the code calling exception of the viewing end is determined according to the code calling information, determining that the cause of the pause event is the exception of the application program of the viewing end.

8. The live report data processing method according to claim 1 or 7, further comprising:

when the fact that a stuck object exists in the first interface image data or the second interface image data is detected, judging that a stuck event occurs at the watching end; wherein the stuck object comprises one or more of a black screen image and a stuck logo.

9. A live report data processing apparatus, the apparatus comprising:

10. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method of any of claims 1 to 8.