CN114116278A

CN114116278A - Live broadcast fault detection processing method and device, equipment, medium and product thereof

Info

Publication number: CN114116278A
Application number: CN202111290322.0A
Authority: CN
Inventors: 曾家乐
Original assignee: Guangzhou Cubesili Information Technology Co Ltd
Current assignee: Guangzhou Cubesili Information Technology Co Ltd
Priority date: 2021-11-02
Filing date: 2021-11-02
Publication date: 2022-03-01

Abstract

The application discloses a live broadcast fault detection processing method and a device, equipment, a medium and a product thereof, wherein the method comprises the following steps: responding to a fault reporting event, detecting a fault type of a client triggering the event in a current live broadcast room, and storing fault information containing the fault type into a fault log; broadcasting fault information in a fault log to a current live broadcast room, and driving the current live broadcast room to output the fault information to a fault voting control so as to acquire fault voting information pushed by a client through the fault voting control; and determining the priority of the fault types contained in each fault information in the fault log according to the fault voting information, and selecting part of the fault types with higher priority to send corresponding notifications to the current live broadcast room. The application of the application can provide fault feedback service for users in the live broadcast room so as to determine faults existing in the live broadcast room, and further carry out fault notification, and pertinently repair the collected faults, and improve the operation stability of the live broadcast room.

Description

Live broadcast fault detection processing method and device, equipment, medium and product thereof

Technical Field

The present application relates to the field of live broadcast technologies, and in particular, to a live broadcast fault detection processing method, and further, to an apparatus, a device, a non-volatile storage medium, and a computer program product corresponding to the method.

Background

Various types of live broadcast functions exist in live broadcast room online services provided by the existing live broadcast platform so as to meet the use experience of audience users or anchor users using the live broadcast services, but the live broadcast function with rich live broadcast service is easy to have corresponding fault, so that the user can not use the corresponding live broadcast function to carry out live broadcast activity, however, when the live application program run by the user fails, the feedback can be performed only by sending an e-mail to the live platform, the live broadcast platform is informed to repair the fault, the fault feedback flow which is separated from the live broadcast service often causes that the user can not feed back immediately, the fault existing in the live broadcast room often can only be tested by the tester of the platform, therefore, the fault existing in the live broadcast room can not be repaired in time, and the experience of the user in using the live broadcast service is influenced.

In view of the above problems, the present applicant has made a corresponding search in view of solving the problems.

Disclosure of Invention

The application aims to meet the requirements of users and provides a live broadcast fault detection processing method, and further relates to a corresponding device, equipment, a non-volatile storage medium and a computer program product of the method.

In order to realize the purpose of the application, the following technical scheme is adopted:

the method for detecting and processing the live broadcast fault, which is suitable for the purpose of the application, comprises the following steps:

responding to a fault reporting event, detecting a fault type existing in a current live broadcast room of a client triggering the event, and storing fault information containing the fault type into a fault log;

broadcasting fault information in the fault log to a current live broadcast room, and driving the current live broadcast room to output the fault information to a fault voting control so as to acquire fault voting information pushed by a client through the fault voting control;

and determining the priority of the fault types contained in each fault information in the fault log according to the fault voting information, and selecting part of the fault types with higher priority to send corresponding notifications to the current live broadcast room.

In a further embodiment, before responding to the failure reporting event, the method includes the following pre-steps executed by the client in the current live broadcast room:

responding to a fault message body editing event, and acquiring a fault reporting text and a fault screenshot of a fault reporting control in a current live broadcast room, wherein the fault reporting control is used by a client for editing the fault reporting text and the fault screenshot;

and pushing a fault message body containing the fault reporting text and the fault screenshot to a server so as to trigger the server to detect the fault type existing in the current live broadcast room according to the fault message body.

In a further embodiment, the step of responding to the failure reporting event and detecting a failure type existing in the current live broadcast room by the client that triggered the event includes the following steps:

receiving a fault message body pushed by a client in the current live broadcast room, and transmitting a fault report text in the fault message body to a text semantic recognition model trained to be in a convergence state;

acquiring a semantic recognition result generated by the text semantic recognition model according to the fault report text, and determining a fault type represented by the semantic recognition result;

and generating fault information containing the fault type and the fault screenshot in the fault message body, and storing the fault information into the fault log.

monitoring a live broadcast audio stream of a main broadcast client in a current live broadcast room, and transmitting the live broadcast audio stream to an audio semantic recognition model trained to a convergence state;

acquiring an audio recognition result generated by the audio semantic recognition model according to the fault report text, and determining a fault type represented by the audio recognition result;

and generating fault information containing the fault type, and storing the fault information into the fault log.

In a further embodiment, the step of broadcasting the fault information in the fault log to the current live broadcast room, and driving the current live broadcast room to output the fault information to the fault voting control, so as to obtain the fault voting information pushed by the client through the fault voting control, includes the following steps executed by the client:

acquiring one or more pieces of fault information broadcasted by a server, and outputting the fault information to the fault voting control for display;

responding to a failure voting event acting on the failure voting control, and generating failure voting information which contains failure types in failure information pointed by the event;

and pushing the failure voting information to a server so that the server determines the priority of the failure type according to the failure voting information.

In a further embodiment, the step of determining the priority of the fault type included in each fault information in the fault log according to the fault voting information, and selecting a part of fault types with higher priorities to send corresponding notifications to the current live broadcast room includes the following steps:

counting the respective vote number of each fault type according to the fault type pointed by the fault voting information pushed by each client;

determining the respective priorities of the fault types according to the votes of the fault types and the heights of the votes;

and generating a fault notification of a fault type with higher priority, and pushing the fault notification to a target client of the current live broadcast room.

In a preferred embodiment, after the step of determining the priority of the fault type included in each fault information in the fault log according to the fault voting information, and selecting a part of fault types with higher priorities to send corresponding notifications to the current live broadcast room, the step includes:

pushing fault repairing patches for repairing fault types corresponding to fault information in the fault logs to a client in the current live broadcast room, wherein the fault repairing patches are used for repairing faults existing in the current live broadcast room;

and acquiring feedback opinion information pushed by a client in the current live broadcast room, and storing the feedback opinion information into a repair log.

Adapt to the purpose of this application and a live broadcast fault detection processing apparatus that proposes, it includes:

the fault detection module is used for responding to a fault reporting event, detecting the fault type of a client triggering the event in the current live broadcast room, and storing fault information containing the fault type into a fault log;

the fault information broadcasting module is used for broadcasting the fault information in the fault log to the current live broadcast room and driving the current live broadcast room to output the fault information to the fault voting control so as to acquire the fault voting information pushed by the client through the fault voting control;

and the priority determining module is used for determining the priority of the fault types contained in the fault information in the fault log according to the fault voting information, and selecting part of the fault types with higher priorities to send corresponding notifications to the current live broadcast room.

In a further embodiment, the fault detection module comprises:

the message body receiving submodule is used for receiving a fault message body pushed by a client in the current live broadcast room and transmitting a fault report text in the fault message body to a text semantic recognition model trained to be in a convergence state;

the semantic recognition result acquisition submodule is used for acquiring a semantic recognition result generated by the text semantic recognition model according to the fault report text and determining a fault type represented by the semantic recognition result;

and the fault information storage submodule is used for generating fault information containing the fault type and the fault screenshot in the fault message body and storing the fault information into the fault log.

In a preferred embodiment, the fault detection module further includes:

the audio stream monitoring sub-module is used for monitoring a live audio stream of a main broadcast client in a current live broadcast room and transmitting the live audio stream to an audio semantic recognition model trained to be in a convergence state;

the audio recognition result acquisition submodule is used for acquiring an audio recognition result generated by the audio semantic recognition model according to the fault report text and determining the fault type represented by the audio recognition result;

and the fault information generation submodule is used for generating fault information containing the fault type and storing the fault information into the fault log.

In a further embodiment, the priority determination module comprises:

the vote counting submodule is used for counting the respective vote number of each fault type according to the fault type pointed by the fault voting information pushed by each client;

the priority determining submodule is used for determining the respective priority of the fault types according to the votes of the fault types and the heights of the votes;

and the fault notification generation submodule is used for generating a fault notification of a fault type with higher priority and pushing the fault notification to a target client of the current live broadcast room.

In order to solve the above technical problem, an embodiment of the present invention further provides a computer device, including a memory and a processor, where the memory stores computer readable instructions, and the computer readable instructions, when executed by the processor, cause the processor to execute the steps of the live broadcast fault detection processing method.

In order to solve the above technical problem, an embodiment of the present invention further provides a storage medium storing computer readable instructions, where the computer readable instructions, when executed by one or more processors, cause the one or more processors to perform the steps of the live broadcast fault detection processing method.

In order to solve the foregoing technical problem, an embodiment of the present application further provides a computer program product, which includes a computer program and computer instructions, and when the computer program and the computer instructions are executed by a processor, the processor executes the steps of the live broadcast fault detection processing method.

Compared with the prior art, the application has the following advantages:

this application is through providing trouble feedback service to the user in the live broadcast room, with the trouble that exists in the detection live broadcast room, and carry out trouble consultation in the fault feedback broadcast to the live broadcast room with the collection, whether these faults exist in the most customer end in the live broadcast room, and then carry out the priority of fault type and confirm, the fault type that exists in the prediction live broadcast room is the fault problem that the equipment of customer end exists or the fault problem that the business system of live broadcast room exists, prevent that the resource waste from restoreing not for the fault that the business system exists of live broadcast, and then promote the repair efficiency of the fault that exists in the live broadcast room, with the higher trouble of priority in the main broadcast live broadcast room of notice live broadcast room, be convenient for the main broadcast carries out the adjustment of live broadcast business, promote the use experience of each type user who uses live broadcast service.

Secondly, the fault feedback service provided by the application is combined with the live broadcast service system, a user can quickly feed back faults existing in each live broadcast function in the live broadcast service through the live broadcast platform, the faults found by the user are prevented from being fed back everywhere, the platform fault detection efficiency is improved, the platform can efficiently repair the fed back faults, and the overall stability of the live broadcast service system is effectively improved.

Drawings

The foregoing and/or additional aspects and advantages of the present application will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:

fig. 1 is a schematic diagram of a typical network deployment architecture related to implementing the technical solution of the present application;

fig. 2 is a schematic flowchart of an exemplary embodiment of a live broadcast fault detection processing method according to the present application;

FIG. 3 is a schematic diagram of a fault reporting control of the present application shown in a graphical user interface;

fig. 4 is a schematic diagram of a graphical user interface of a current live broadcast room when a fault exists in the current live broadcast room in the present application;

FIG. 5 is a schematic diagram of a voting control component of the present application shown in a graphical user interface;

FIG. 6 is a schematic illustration of a presentation of a fault notification of the present application in a graphical user interface of a current live broadcast room;

fig. 7 is a schematic flowchart illustrating an embodiment executed by a client in a current live broadcast room before a server responds to a failure reporting event;

FIG. 8 is a schematic flow chart illustrating a specific embodiment of invoking a text semantic recognition model for fault type detection when a server responds to a fault reporting event according to the present application;

FIG. 9 is a schematic flow chart illustrating a specific embodiment of invoking an audio semantic recognition model for fault type detection when a server responds to a fault reporting event according to the present application;

fig. 10 is a schematic flowchart illustrating a specific embodiment of a vote failure control in a client in a current live broadcast room according to the present application;

FIG. 11 is a schematic flow chart illustrating the determination of the priority of each fault type according to an embodiment of the present disclosure;

FIG. 12 is a flowchart illustrating an embodiment of pushing a failover patch and receiving feedback information from a server according to the present application;

fig. 13 is a functional block diagram of an exemplary embodiment of a live fault detection processing apparatus of the present application;

fig. 14 is a block diagram of a basic structure of a computer device according to an embodiment of the present application.

Detailed Description

Reference will now be made in detail to embodiments of the present application, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are exemplary only for the purpose of explaining the present application and are not to be construed as limiting the present application.

As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may also be present. Further, "connected" or "coupled" as used herein may include wirelessly connected or wirelessly coupled. As used herein, the term "and/or" includes all or any element and all combinations of one or more of the associated listed items.

It will be understood by those within the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

As will be appreciated by those skilled in the art, "client," "terminal," and "terminal device" as used herein include both devices that are wireless signal receivers, which are devices having only wireless signal receivers without transmit capability, and devices that are receive and transmit hardware, which have receive and transmit hardware capable of two-way communication over a two-way communication link. Such a device may include: cellular or other communication devices such as personal computers, tablets, etc. having single or multi-line displays or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service), which may combine voice, data processing, facsimile and/or data communication capabilities; a PDA (Personal Digital Assistant), which may include a radio frequency receiver, a pager, internet/intranet access, a web browser, a notepad, a calendar and/or a GPS (Global Positioning System) receiver; a conventional laptop and/or palmtop computer or other device having and/or including a radio frequency receiver. As used herein, a "client," "terminal device" can be portable, transportable, installed in a vehicle (aeronautical, maritime, and/or land-based), or situated and/or configured to operate locally and/or in a distributed fashion at any other location(s) on earth and/or in space. The "client", "terminal Device" used herein may also be a communication terminal, a web terminal, a music/video playing terminal, such as a PDA, an MID (Mobile Internet Device) and/or a Mobile phone with music/video playing function, and may also be a smart tv, a set-top box, and the like.

The hardware referred to by the names "server", "client", "service node", etc. is essentially an electronic device with the performance of a personal computer, and is a hardware device having necessary components disclosed by the von neumann principle such as a central processing unit (including an arithmetic unit and a controller), a memory, an input device, an output device, etc., a computer program is stored in the memory, and the central processing unit calls a program stored in an external memory into the internal memory to run, executes instructions in the program, and interacts with the input and output devices, thereby completing a specific function.

It should be noted that the concept of "server" as referred to in this application can be extended to the case of a server cluster. According to the network deployment principle understood by those skilled in the art, the servers should be logically divided, and in physical space, the servers may be independent from each other but can be called through an interface, or may be integrated into one physical computer or a set of computer clusters. Those skilled in the art will appreciate this variation and should not be so limited as to restrict the implementation of the network deployment of the present application.

Referring to fig. 1, the hardware basis required for implementing the related art embodiments of the present application may be deployed according to the architecture shown in the figure. The server 80 is deployed at the cloud end, and serves as a business server, and is responsible for further connecting to a related data server and other servers providing related support, so as to form a logically associated server cluster to provide services for related terminal devices, such as a smart phone 81 and a personal computer 82 shown in the figure, or a third-party server (not shown in the figure). Both the smart phone and the personal computer can access the internet through a known network access mode, and establish a data communication link with the cloud server 80 so as to run a terminal application program related to the service provided by the server.

For the server, the application program is usually constructed as a service process, and a corresponding program interface is opened for remote call of the application program running on various terminal devices.

The application program refers to an application program running on a server or a terminal device, the application program implements the related technical scheme of the application in a programming mode, a program code of the application program can be saved in a nonvolatile storage medium which can be identified by a computer in a form of a computer executable instruction, and is called into a memory by a central processing unit to run, and the related device of the application is constructed by running the application program on the computer.

For various terminal devices which are popular at present, particularly for mobile devices such as tablets and mobile phones, camera devices such as a camera are usually built in, or a personal computer can be externally connected to the camera devices.

The technical scheme suitable for being implemented in the terminal device in the application can also be programmed and built in an application program providing live webcasting, and the technical scheme is used as a part of extended functions. The live webcast refers to a live webcast room network service realized based on the network deployment architecture.

The live broadcast room is a video chat room realized by means of an internet technology, generally has an audio and video broadcast control function and comprises a main broadcast user and audience users, wherein the audience users can comprise registered users registered in a platform or unregistered tourist users; either registered users who are interested in the anchor user or registered or unregistered users who are not interested in the anchor user. The interaction between the anchor user and the audience user can be realized through known online interaction modes such as voice, video, characters and the like, generally, the anchor user performs programs for the audience user in the form of audio and video streams, and economic transaction behaviors can also be generated in the interaction process. Of course, the application form of the live broadcast room is not limited to online entertainment, and can be popularized to other relevant scenes, such as an educational training scene, a video conference scene, a product recommendation and sale scene, and any other scene needing similar interaction.

The person skilled in the art will know this: although the various methods of the present application are described based on the same concept so as to be common to each other, they may be independently performed unless otherwise specified. In the same way, for each embodiment disclosed in the present application, it is proposed based on the same inventive concept, and therefore, concepts of the same expression and concepts of which expressions are different but are appropriately changed only for convenience should be equally understood.

Referring to fig. 2, in an exemplary embodiment of a live broadcast fault detection processing method according to the present application, the method includes the following steps:

step S11, responding to the failure reporting event, detecting the failure type existing in the current live broadcast room by the client that triggered the event, and storing the failure information including the failure type in the failure log:

and the server responds to the fault reporting event to detect the fault type of the client in the current live broadcast room, and stores the fault information containing the fault type into a fault log so as to broadcast and push the fault information in the subsequent process.

The fault reporting event is generally triggered and generated by a client in a live broadcast room, so that the server responds to the fault reporting event, detects a fault type existing in the live broadcast room where the client is located, and further generates and stores fault information containing the detected fault type.

The failure types generally include failures that occur in a live broadcast room, such as the fact that a client in the live broadcast room cannot present a virtual gift to an anchor broadcast, the fact that a viewer client in the live broadcast room cannot receive a live broadcast stream pushed by the anchor broadcast client, or the fact that the client in the live broadcast room cannot adjust the playing volume of the live broadcast stream.

The client generally refers to a viewer client or a main broadcasting client in a live broadcasting room.

When a client side has a fault in the current live broadcast room, a fault reporting text for representing the current fault can be edited in a fault reporting control displayed in the current live broadcast room, screenshot operation is carried out on a graphical user interface in the current live broadcast room through the fault reporting control to generate a fault screenshot of an image with the fault appearing in the graphical user interface in the current live broadcast room, a fault message body containing the fault reporting text and the fault screenshot is pushed to a server, the server is triggered to carry out fault detection according to the fault message body, and the fault type appearing in the client side pushing the fault message body in the current live broadcast room is determined.

Specifically, referring to fig. 3 and 4, when a client has an error in the current live broadcast room, a fault reporting control shown in fig. 3 may be invoked in a graphical user interface of the current live broadcast room, in the fault reporting control shown, a user of the client may edit the fault reporting text through a fault reporting text editing box 301, and may intercept the graphical user interface having the error in the current live broadcast room shown in fig. 4 through a screenshot control 302, and display a fault screenshot generated through the screenshot in a fault screenshot browsing control 303, after the editing of the fault reporting text and the fault screenshot is completed, by touching a push message body control 304 in the fault reporting control, the client is triggered to generate a fault message body including the fault reporting text and the fault screenshot, and push the fault message body to the server, so that the server can detect the fault type.

After receiving the fault message body pushed by a client in the current live broadcast room, the server analyzes the fault message body, acquires the fault report text and the fault screenshot contained in the fault message body, transmits the fault report text to a text semantic recognition model trained to be in a convergence state, recognizes a semantic result of the fault type represented in the fault recognition text by the text semantic recognition model so that the server can acquire the semantic result, determines the fault type represented by the semantic result as the fault type of the client in the current live broadcast room, packages the fault type and the fault screenshot, generates fault information containing the fault type and the fault screenshot, and stores the fault information into the fault log.

The fault log is used to store fault information including fault types detected by the server, so that the server records faults existing in the live broadcast room through the fault log, and broadcasts one or more fault information stored in the fault log to the live broadcast room, and queries whether a client in the current live broadcast room has a fault type represented by the fault information, so as to determine priorities of the fault types and perform corresponding fault notification and fault repair processing.

The current server can detect the fault type through the fault message body, and can also detect live broadcast audio streams generated by monitoring live broadcast of a main broadcast client in a current live broadcast room, specifically, the server transmits the obtained live broadcast audio streams of the main broadcast client in the current live broadcast room to an audio semantic recognition model trained to be in a convergence state, obtains an audio recognition result generated by the audio semantic recognition model according to the fault report text, determines the fault type represented by the audio recognition result, generates fault information containing the fault type, and stores the fault information into the fault log.

Step S12, broadcasting the fault information in the fault log to the current live broadcast room, and driving the current live broadcast room to output the fault information to the fault voting control, so as to obtain the fault voting information pushed by the client through the fault voting control:

the server broadcasts one or more fault information stored in the fault log to the client side in the current live broadcast room, so that the client side can output the fault information to a fault voting control in a graphical user interface of the current live broadcast room for display after acquiring the fault information, the fault type existing in the current live broadcast room is selected from the fault information through the fault voting control, and the fault voting information containing the fault type corresponding to the selected fault information is pushed to the server for feedback.

The live broadcast room generally has the fault log used for storing the fault information of the live broadcast room, the server determines the fault log corresponding to the current live broadcast room, and broadcasts all the fault information in the fault log to all the clients in the current live broadcast room.

In one embodiment, the fault log stores fault information corresponding to each live broadcast room, each fault information carries a live broadcast room identifier representing the fault information associated with the fault information, and when a server needs to broadcast and push the fault information corresponding to the current live broadcast room, the fault log is queried for one or more fault information corresponding to the live broadcast room identifier corresponding to the current live broadcast room, so that the fault information is broadcast to a client in the current live broadcast room.

After receiving all fault information in the fault log broadcast and pushed by the server, any client in the current live broadcast room outputs the fault information to the fault voting control for displaying, so that the client selects the fault information through the fault voting control to push the fault voting information, specifically, the client responds to a fault voting event acting in the fault voting control to generate the fault voting information containing the fault type in the fault information pointed by the fault voting event, and pushes the fault voting information to the server, so that the subsequent server determines the priority of each fault type according to a plurality of fault voting information pushed by each client in the current live broadcast room.

Referring to fig. 5, fig. 5 is a schematic view of a control of the failure voting control, when any client in the current live broadcast room receives all failure information in the failure log broadcast and pushed by the server, the failure information is output to the failure voting control shown in fig. 5 for display, so that the user performs voting operation on the failure information from the failure voting control, for example, when the failure information that cannot be played in the live broadcast stream is selected through the failure voting control, the client generates failure voting information pointing to a failure type that cannot be played in the live broadcast stream by touching the voting control 501 of the failure information, and pushes the failure voting information to the server, and accordingly, if the client does not have a failure in the current live broadcast room, the client can cancel voting control 502 without a failure in the live broadcast room in fig. 5 by touching, and closing the display of the failure voting control in the graphical user interface of the current live broadcast room.

Step S13, according to the failure voting information, determining the priority of the failure type included in each failure information in the failure log, and selecting a portion of failure types with higher priority to send a corresponding notification to the current live broadcast:

after the server acquires the failure voting information pushed by each client in the current live broadcast room through the failure voting control, the server analyzes and determines the failure types corresponding to the failure voting information, so as to receive the failure voting information corresponding to the failure types through the server and determine the priorities corresponding to the failure types.

Specifically, the server counts respective votes of the fault types according to the fault types pointed by the fault voting information pushed by each client in the current live broadcast room, and determines respective priorities of the fault types according to the respective votes of the fault types and the heights of the votes of the fault types, wherein the higher the votes, the higher the priority of the fault types is.

After determining the priority of each fault type, the server selects the fault type with higher priority from the fault types, generates a fault notification for the fault types, and pushes the fault notification to the client of the anchor terminal in the current live broadcast room for display so as to notify the anchor user in the current live broadcast room of the fault type existing in the live broadcast room, so that the anchor user and the audience user in the current live broadcast room can conveniently communicate with each other about the topic of the audience type.

In one embodiment, the server may broadcast a failure notification including a failure type with a higher priority to the client in the current live broadcast room for display, so as to remind the client of the failure type existing in the current live broadcast room, and the failure notification includes an expected repair time of the failure type for display, so as to notify the viewer user in the current live broadcast room of the repair time of the failure type.

Referring to fig. 6, fig. 6 is a schematic diagram illustrating the fault notification in the gui of the current live broadcast room, where the fault notification 601 is displayed at the top of the layer of the gui of the current live broadcast room to prompt the client of the fault type existing in the current live broadcast room.

It can be understood that the present application performs semantic analysis through fault feedback of a user in a live broadcast room, and monitors an audio stream of a main broadcast end in the live broadcast room to perform audio analysis, so as to detect one or more fault types existing in the live broadcast room, and pushes detected fault information to a client in the live broadcast room to perform fault consultation, so as to determine whether the fault types exist in most of the clients in the live broadcast room, and further perform priority of the fault types, predict whether the fault types existing in the live broadcast room are fault problems existing in equipment of the client or fault problems existing in a service system of the live broadcast room, generally determine the fault type with higher priority as a fault problem caused by a service system of the live broadcast room, and push a notification message containing the fault type with higher priority to the main broadcast end in the live broadcast room to notify so that the main broadcast user knows the fault existing in the live broadcast room, meanwhile, the notification message is pushed to a management end of the live broadcast platform, so that faults existing in the live broadcast room are rapidly notified, and the fault repairing efficiency is improved.

The above exemplary embodiments and their variations disclose the implementation of the method for live fault detection processing of the present application sufficiently, but many variations of the method can be deduced by transforming and augmenting some technical means, and other embodiments are summarized as follows:

in an embodiment, referring to fig. 3, fig. 4 and fig. 7, before the server responds to the failure reporting event, the method includes the following pre-steps executed by the client in the current live broadcast room:

step S09, responding to the fault message body editing event, acquiring the fault reporting text and fault screenshot of the fault reporting control in the current live broadcast room, wherein the fault reporting control is used by the client for editing the fault reporting text and fault screenshot:

and the client in the current live broadcast room responds to the fault message body editing event so as to obtain a fault equipment text and a fault screenshot of the fault equipment control in the current live broadcast room.

Specifically, referring to fig. 3, when the client has a fault in the current live broadcast room, a fault reporting control shown in fig. 3 may be called in the graphical user interface of the current live broadcast room, so as to edit the fault reporting text through a fault reporting text editing box 301 in the fault reporting control, and the graphical user interface with the fault in the current live broadcast room shown in fig. 4 may be intercepted through a screenshot control 302, and after the editing of the fault reporting text and the fault screenshot is completed, the fault message body editing event is triggered and generated by touching a push message body control 304 in the fault reporting control, and the client side responds to the fault message body editing event to generate a fault message body containing the fault reporting text and the fault screenshot, and the fault message body is pushed to the server so that the server can detect the fault type.

Step S10, a fault message body including the fault report text and the fault screenshot is pushed to the server, so as to trigger the server to detect the fault type existing in the current live broadcast room according to the fault message body:

and after the client generates a fault message body containing the edited fault reporting text and the fault screenshot of the fault reporting control in the graphical user interface of the current live broadcast room, the message body is pushed to the server, and the server detects the fault type of the current live broadcast room according to the fault message body.

In this embodiment, through the design of the fault reporting control, the user in the live broadcast room can edit the fault reporting text and the fault screenshot through the fault reporting control, so as to feed back the fault existing in the current live broadcast room to the server, and further trigger the server to call the semantic recognition model, and detect the fault type represented by the fault reporting text.

In an embodiment, referring to fig. 8, a specific implementation manner of a server responding to a failure reporting event and invoking a text semantic recognition model to detect a failure type existing in a current live broadcast room of a client that triggers the event includes the following specific steps:

step S111, receiving a fault message body pushed by a client in the current live broadcast room, and transmitting a fault report text in the fault message body to a text semantic recognition model trained to a convergence state:

and after receiving the fault message body pushed by the client in the current live broadcast room, the server analyzes the fault message body, acquires the fault report text contained in the fault message body, and transmits the fault report text to a text semantic recognition model trained to be in a convergence state for semantic recognition so as to determine the fault type represented by the fault report text.

The text semantic recognition model is trained to be in a convergence state, the fault report text is imported into a convolutional neural network for recognizing text semantics for semantic analysis, the fault type of the fault report text which completes the semantic analysis is classified by normalization processing, and then a semantic result for representing the fault type corresponding to the fault report text is output.

Step S112, obtaining the semantic recognition result generated by the text semantic recognition model according to the fault report text, and determining the fault type represented by the semantic recognition result:

and the server acquires a semantic recognition result generated by the text semantic recognition model according to the fault report text, and determines the fault type represented by the semantic recognition result so as to generate fault information containing the fault type.

Step S113, generating fault information including the fault type and the fault screenshot in the fault message body, and storing the fault information in the fault log:

and the server generates fault information containing the fault type and the fault screenshot contained in the fault message body, and stores the fault information into the fault log so as to broadcast the fault information to the current live broadcast room for fault voting service.

In the embodiment, the fault message body pushed by the current live broadcast room is obtained, the text semantic recognition model trained to the convergence state is called to perform semantic recognition on the fault report text contained in the message body, the fault type represented by the fault report text is determined, and the fault detection is performed by combining the neural network model, so that the time spent on determining the fault type manually is saved, and the overall efficiency of fault detection is effectively improved.

In an embodiment, referring to fig. 9, a specific implementation manner of a server responding to a failure reporting event, monitoring a live broadcast audio stream of a main broadcast end, and detecting a failure type existing in a current live broadcast room of a client end triggering the event in combination with an audio semantic recognition model includes the following specific steps:

step S111', monitoring live broadcast audio stream of a main broadcast client in a current live broadcast room, and transmitting the live broadcast audio stream to an audio semantic recognition model trained to a convergence state:

the server monitors the live audio stream pushed to a media server by a client of a main broadcasting user in a current live broadcasting room so as to acquire the live audio stream and transmit the live audio stream to an audio semantic recognition model trained to be in a convergence state for audio recognition, and a fault type represented by the live audio stream is recognized.

And the server transmits the live broadcast audio stream to the audio semantic recognition model so that the audio semantic recognition model can recognize the audio semantic output by the live broadcast audio stream, and further determines the fault type corresponding to the audio semantic, and further generates an audio recognition result for representing the fault type corresponding to the live broadcast audio stream.

Step S112', obtaining an audio recognition result generated by the audio semantic recognition model according to the fault report text, and determining a fault type represented by the audio recognition result:

and the server acquires an audio recognition result generated by the audio semantic recognition model according to the fault report text, and determines the fault type represented by the audio recognition result so as to generate fault information containing the fault type.

Step S113', generating fault information including the fault type, and storing the fault information in the fault log:

and the server generates fault information containing the fault type and stores the fault information into the fault log so as to broadcast the fault information to the current live broadcast room for fault voting service.

In the embodiment, semantic recognition is performed on the live broadcast audio stream through the live broadcast audio stream of the anchor terminal in the live broadcast room today and the audio semantic recognition model trained to the convergence state is called to determine the fault type represented by the live broadcast audio stream so as to determine the fault existing in the current live broadcast room from the audio of the anchor user, and fault detection is performed by combining with the neural network model, so that the time spent on determining the fault type manually is saved, and the overall efficiency of fault detection is effectively improved.

In an embodiment, referring to fig. 5 and 10, the step of receiving the failure information broadcasted by the server and outputting the failure information to the failure voting control and pushing the failure voting information by the client in the current live broadcast room includes the following steps executed by the client:

step S121, acquiring one or more pieces of failure information broadcasted by the server, and outputting the pieces of failure information to the failure voting control for display:

after receiving one or more pieces of fault information broadcasted by the server, any client of the current live broadcast room calls the fault voting control in a graphical user interface of the current live broadcast room so as to generate and display the fault information in the fault voting control, so that fault information corresponding to the fault in the current live broadcast room is selected from the fault information displayed in the fault voting control.

The failure voting control is configured to output and display the failure information, and the failure information displayed in the control has respective corresponding voting controls so as to perform a selection operation of the failure information, specifically, please refer to fig. 5, where fig. 5 is a control schematic diagram of the failure voting control, when any client in the current live broadcast room receives all the failure information in the failure log broadcast and pushed by the server, the failure information is output to the failure voting control shown in fig. 5 for displaying, so that a user performs a voting operation of the failure information from the failure voting control, for example, when the user selects the failure information that cannot be played in the live broadcast stream through the failure voting control, the client generates the failure voting information pointing to the failure type that cannot be played in the live broadcast stream through the voting control 501 for touching the failure information, and the failure voting information is pushed to the server, and correspondingly, if the client side does not have a failure in the current live broadcast room, the display of the failure voting control in the graphical user interface of the current live broadcast room can be closed by touching the failure-free voting cancellation control 502 in the live broadcast room in fig. 5.

Step S122, in response to the failure voting event acting on the failure voting control, generating the failure voting information including the failure type in the failure information pointed by the event:

and the client side responds to the fault voting event triggered by the fault information selection operation of the user through the fault voting control, determines the fault information pointed by the event, and generates the fault voting information containing the fault type in the fault information pointed by the event.

Step S123, pushing the failure voting information to a server, so that the server determines the priority of the failure type according to the failure voting information:

and after the client generates the fault voting information containing the fault type in the fault information selected by the fault voting control, pushing the fault voting information to a server so that the server determines the priority of the fault type according to the fault voting information.

In this embodiment, through the design of the failure voting control, a failure information voting service is provided for a user in the live broadcast room, so that the user can select a failure type corresponding to a failure occurring in the live broadcast room in which the user is located through the failure voting control, and the client side pushes failure voting information containing the failure type to the server, so that the server determines the priority of each failure type according to the failure voting information pushed by each client side.

In an embodiment, referring to fig. 6 and 11, a specific implementation manner that a server determines priorities of fault types included in each fault information in the fault log according to the fault voting information, and selects a part of fault types with higher priorities to send corresponding notifications to a current live broadcast room includes the following specific implementation steps:

step S131, according to the fault types pointed by the fault voting information pushed by each client, counting the respective votes of the fault types:

after receiving the failure voting information pushed by each client in the current live broadcast room, the server determines the failure types pointed by the failure voting information, and counts the voting number of the failure types according to the number of the failure voting information corresponding to the failure types.

Step S132, according to the votes of the fault types, determining the respective priorities of the fault types according to the votes:

after the server counts the votes corresponding to all the fault types, the server determines the priorities corresponding to the fault types according to the votes corresponding to the fault types, for example, when the votes of a certain fault type are the highest among the votes of all the fault types, the priority of the fault type is the highest among the fault types.

Step S133, generating a failure notification of a failure type with a higher priority, and pushing the failure notification to a target client in the current live broadcast:

after determining the priorities corresponding to all the fault types, the server determines one or more fault types with higher priorities among the fault types to generate a fault notification including the fault types, specifically, generally, generates a fault notification including a first fault type in a priority ranking among the fault types, or generates a fault notification including a first fault type in a priority ranking among the fault types.

After the server generates the fault notification, the fault notification is pushed to a client of an anchor terminal in a current live broadcast room for display, as shown in a display schematic diagram of the fault notification in a graphical user interface of the live broadcast room in fig. 6, so as to notify a live broadcast user of a fault type existing in the live broadcast room in the current live broadcast room, so that the live broadcast user and a viewer user in the current live broadcast room can conveniently perform topic communication about the viewer type, correspondingly, the server can also push the fault notification to a client of a management terminal in the current live broadcast room, so as to quickly notify the management terminal to perform repair of the fault type represented by the fault notification, and improve the overall fault repair efficiency.

In the embodiment, the priority of each fault type is determined according to the vote number of the fault type by the user in the live broadcast room, so that the fault types of most of the clients in the current live broadcast room are determined, the fault notification containing the fault types is generated and pushed, the main broadcast user in the current live broadcast room or the management user in the management live broadcast room is notified of the fault types in the current live broadcast room, the live broadcast service adjustment of the main broadcast user is facilitated, and the fault repairing efficiency of the management user is improved.

In an embodiment, referring to fig. 12, after the step of determining the priority of the fault types included in each fault information in the fault log according to the fault voting information, and selecting a part of the fault types with higher priorities to send corresponding notifications to the current live broadcast room, the method includes:

step S14, a fault repair patch for repairing a fault type corresponding to each fault information in the fault log is pushed to the client in the current live broadcast room, so as to repair a fault existing in the current live broadcast room:

and after the server acquires the fault repairing patch for repairing the fault type existing in the current live broadcast room in the fault log, pushing the fault repairing patch to each client of the current live broadcast room so that the clients can repair the fault existing in the current live broadcast room according to the fault repairing patch.

The fault repairing patch is generally pushed to a server by a management end of a live broadcast platform, and the management end constructs the fault repairing patch aiming at fault types represented by the fault information through the fault information stored in the fault log so as to repair the fault types corresponding to the fault information in the fault log in the current live broadcast room.

Step S15, obtaining feedback opinion information pushed by the client in the current live broadcast room, and storing the feedback opinion information in a repair log:

after the client in the current live broadcast room receives the fault repairing patch to repair, the client can push the feedback opinion information representing the repairing condition of the current live broadcast room to the server, and after the server receives the feedback opinion information, the feedback opinion information is stored in a repairing log, so that the server can push the feedback opinion information to the management end, and the management end can determine the repairing effect of the fault repairing patch through the feedback opinion information.

In the embodiment, the fault repairing patch is pushed by the client side of the current live broadcast room to repair the fault existing in the live broadcast room, and feedback opinion information of the repairing condition of the patch represented by the client side is collected, so that the use experience of a repaired user can be known through the feedback opinion information, the management user can further repair the patch, and the user experience of the live broadcast room is improved.

Further, a live broadcast fault detection processing apparatus of the present application may be constructed by functionalizing the steps in the method disclosed in the above embodiments, and according to this idea, please refer to fig. 13, wherein in an exemplary embodiment, the apparatus includes: the fault detection module 11 is configured to respond to a fault reporting event, detect a fault type existing in a current live broadcast room at a client that triggers the event, and store fault information including the fault type in a fault log; the fault information broadcasting module 12 is configured to broadcast fault information in the fault log to a current live broadcast room, and drive the current live broadcast room to output the fault information to a fault voting control, so as to obtain fault voting information pushed by a client through the fault voting control; and a priority determining module 13, configured to determine, according to the failure voting information, a priority of a failure type included in each failure information in the failure log, and select a part of failure types with higher priorities to send a corresponding notification to the current live broadcast room.

In one embodiment, the fault detection module 11 includes: the message body receiving submodule is used for receiving a fault message body pushed by a client in the current live broadcast room and transmitting a fault report text in the fault message body to a text semantic recognition model trained to be in a convergence state; the semantic recognition result acquisition submodule is used for acquiring a semantic recognition result generated by the text semantic recognition model according to the fault report text and determining a fault type represented by the semantic recognition result; and the fault information storage submodule is used for generating fault information containing the fault type and the fault screenshot in the fault message body and storing the fault information into the fault log.

In another embodiment, the fault detection module 11 further includes: the audio stream monitoring sub-module is used for monitoring a live audio stream of a main broadcast client in a current live broadcast room and transmitting the live audio stream to an audio semantic recognition model trained to be in a convergence state; the audio recognition result acquisition submodule is used for acquiring an audio recognition result generated by the audio semantic recognition model according to the fault report text and determining the fault type represented by the audio recognition result; and the fault information generation submodule is used for generating fault information containing the fault type and storing the fault information into the fault log.

In one embodiment, the priority determining module 13 includes: the vote counting submodule is used for counting the respective vote number of each fault type according to the fault type pointed by the fault voting information pushed by each client; the priority determining submodule is used for determining the respective priority of the fault types according to the votes of the fault types and the heights of the votes; and the fault notification generation submodule is used for generating a fault notification of a fault type with higher priority and pushing the fault notification to a target client of the current live broadcast room.

In order to solve the above technical problem, an embodiment of the present application further provides a computer device, configured to run a computer program implemented according to the live broadcast fault detection processing method. Referring to fig. 14, fig. 14 is a block diagram of a basic structure of a computer device according to the present embodiment.

As shown in fig. 14, the internal structure of the computer device is schematically illustrated. The computer device includes a processor, a non-volatile storage medium, a memory, and a network interface connected by a system bus. The non-volatile storage medium of the computer device stores an operating system, a database and computer readable instructions, the database can store control information sequences, and the computer readable instructions, when executed by the processor, can enable the processor to realize a live broadcast fault detection processing method. The processor of the computer device is used for providing calculation and control capability and supporting the operation of the whole computer device. The memory of the computer device may have stored therein computer readable instructions that, when executed by the processor, may cause the processor to perform a live fault detection processing method. The network interface of the computer device is used for connecting and communicating with the terminal. Those skilled in the art will appreciate that the architecture shown in fig. 14 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 this embodiment, the processor is configured to execute specific functions of each module/sub-module in the live broadcast fault detection processing apparatus of the present application, and the memory stores program codes and various data required for executing the modules. The network interface is used for data transmission to and from a user terminal or a server. The memory in this embodiment stores program codes and data required for executing all modules/submodules in the live broadcast fault detection processing device, and the server can call the program codes and data of the server to execute the functions of all the submodules.

The present application further provides a non-volatile storage medium, where the live broadcast fault detection processing method is written as a computer program and stored in the storage medium in the form of computer readable instructions, where the computer readable instructions, when executed by one or more processors, mean the execution of the program in a computer, so as to cause the one or more processors to execute the steps of the live broadcast fault detection processing method according to any one of the above 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 a computer program, which can be stored in a computer-readable storage medium, and can include the processes of the embodiments of the methods described above when the computer program is executed. The storage medium may be a non-volatile storage medium such as a magnetic disk, an optical disk, a Read-Only Memory (ROM), or a Random Access Memory (RAM).

To sum up, the application of this application can provide trouble feedback service to the user in the live broadcast room to confirm the trouble that exists in the live broadcast room, and then carry out the fault notice, and carry out the pertinence to the trouble of collection and restore, promote the operating stability in live broadcast room.

It should be understood that, although the steps in the flowcharts of the figures are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and may be performed in other orders unless explicitly stated herein. Moreover, at least a portion of the steps in the flow chart of the figure may include multiple sub-steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, which are not necessarily performed in sequence, but may be performed alternately or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

Those of skill in the art will appreciate that the various operations, methods, steps in the processes, acts, or solutions discussed in this application can be interchanged, modified, combined, or eliminated. Further, other steps, measures, or schemes in various operations, methods, or flows that have been discussed in this application can be alternated, altered, rearranged, broken down, combined, or deleted. Further, steps, measures, schemes in the prior art having various operations, methods, procedures disclosed in the present application may also be alternated, modified, rearranged, decomposed, combined, or deleted.

The foregoing is only a partial embodiment of the present application, and it should be noted that, for those skilled in the art, several modifications and decorations can be made without departing from the principle of the present application, and these modifications and decorations should also be regarded as the protection scope of the present application.

Claims

1. A live broadcast fault detection processing method is characterized by comprising the following steps:

2. The method of claim 1, wherein prior to responding to the failure reporting event, comprising the pre-step performed by the client in the current live broadcast room of:

3. The method according to claim 2, wherein the step of detecting a fault type existing in the current live broadcast room at the client terminal triggering the event in response to the fault reporting event comprises the steps of:

4. The method according to claim 1, wherein the step of detecting a fault type existing in the current live broadcast room at the client terminal triggering the event in response to the fault reporting event comprises the steps of:

5. The method according to claim 1, wherein the step of broadcasting the fault information in the fault log to the current live broadcast room, and driving the current live broadcast room to output the fault information to the fault voting control to obtain the fault voting information pushed by the client through the fault voting control comprises the following steps executed by the client:

6. The method according to claim 1, wherein the step of determining the priority of the fault types included in each fault information in the fault log according to the fault voting information, and selecting a part of the fault types with higher priority to send corresponding notifications to the current live broadcast room comprises the following steps:

7. The method according to any one of claims 1 to 6, wherein after the step of determining the priority of the fault types included in each fault information in the fault log according to the fault voting information, and selecting part of the fault types with higher priority to send corresponding notifications to the current live broadcast room, the method comprises:

8. An electronic device comprising a central processor and a memory, wherein the central processor is configured to invoke execution of a computer program stored in the memory to perform the steps of the method according to any one of claims 1 to 7.

9. A non-volatile storage medium, characterized in that it stores, in the form of computer-readable instructions, a computer program implemented according to the method of any one of claims 1 to 7, which, when invoked by a computer, performs the steps comprised by the method.

10. A computer program product comprising computer program/instructions, characterized in that the computer program/instructions, when executed by a processor, implement the steps of the method of any one of claims 1 to 7.