Method and device for processing live broadcast data, medium and program product

Abstract

The invention provides a method and device for processing live broadcast data, a medium and a program product. The method comprises the following steps: in response to a received multi-region display instruction, dividing a live broadcast playing interface into a plurality of display regions so as to play video sources of different anchors in each display region; based on the interaction behavior data of the audience side in the live broadcast process, using a pre-trained model to obtain interaction weight values of the audience side and each anchor; determining one or more target anchors needing to be highlighted based on the obtained interaction weight values; and dynamically adjusting the layout of the playing interface based on the determined target anchor so as to highlight the target anchor. According to the method and the device, the picture of the live broadcast room is divided into a plurality of display areas, and each area plays the video sources of different anchors, so that rich view angle selection is provided for audiences, the target anchor can be flexibly and highlighted, the display requirements of other anchors are considered, and the interaction of live broadcast and the user experience are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer-readable medium, and computer program product for processing live data. Background Technology

[0002] Based on existing technologies, in live streaming scenarios with multiple streamers on the same stage, most platforms adopt a fixed split-screen mode. While this mode can display multiple streamers simultaneously, it lacks a flexible interactive focus mechanism, making it difficult for viewers to control the presentation of the live content in real time. Furthermore, existing multi-player PK live streams are generally limited to simple one-on-one battles, lacking gameplay elements such as battle record keeping, points progression, and character mechanics, making it difficult to build a sustainable competitive content ecosystem. In addition, viewer interactions are mostly limited to single-time tipping, commenting, and voting, lacking mechanisms such as vote cooldown and weighting levels, which can easily lead to an imbalance in interaction, affecting the viewing experience and fairness. Summary of the Invention

[0003] This application provides a method, apparatus, computer-readable medium, and computer program product for processing live data.

[0004] One aspect of this application provides a method for processing live streaming data, wherein the method includes: In response to receiving a multi-area display instruction, the live streaming interface is divided into multiple display areas to play video sources from different broadcasters in each display area; Based on the interactive behavior data of the audience during the live broadcast, the interaction weight values ​​between the audience and each streamer are obtained using a pre-trained model. Based on the obtained interaction weight values, identify one or more target broadcasters that need to be highlighted; Based on the identified target broadcaster, the layout of the playback interface is dynamically adjusted to highlight the target broadcaster.

[0005] One aspect of this application provides an apparatus for processing live streaming data, wherein the apparatus includes: The interface partitioning module is used to respond to the received multi-area display command, divide the live broadcast interface into multiple display areas, and play the video source of different broadcasters in each display area; The weight calculation module is used to obtain the interaction weight values ​​between the audience and each streamer based on the audience's interactive behavior data during the live broadcast using a pre-trained model. The target anchor identification module is used to identify one or more target anchors that need to be highlighted based on the obtained interaction weight values; The interface layout adjustment module is used to dynamically adjust the layout of the playback interface based on a determined target broadcaster, so as to highlight the target broadcaster.

[0006] In another aspect of this application, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of the application embodiment.

[0007] In another aspect, this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods of the embodiments of the application.

[0008] In another aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of the embodiments of the application.

[0009] The solution provided in this application divides the live stream screen into multiple display areas, each playing video sources from different broadcasters, offering viewers a rich selection of viewing angles. Based on viewer interaction data during the live stream, a pre-trained model calculates the interaction weight values ​​between the viewer and each broadcaster, and determines one or more target broadcasters to be highlighted based on these weight values. The model's intelligent analysis assigns corresponding weights to different interactive behaviors, making interaction measurement more scientific and accurate. This ensures that the focus of the live stream content always revolves around the broadcasters most interesting to the viewer, enhancing the live stream's appeal and viewer engagement. Through various dynamic... By dynamically adjusting the layout of the live stream screen, this application embodiment can flexibly highlight the target streamer while also accommodating the display needs of other streamers, thereby enhancing the interactivity and user experience of the live stream. Through the introduction of mechanisms such as challenge, challenge, queuing, and cooldown, as well as modules such as teams, points, and leaderboards, these multi-layered mechanisms not only create sustained competition and rotation but also accumulate interactive results, constructing a sustainable competitive content ecosystem. By adding control mechanisms such as voting cooldown, level weighting, and mini-game bonuses, the fairness of the live stream is enhanced while also bringing a more diverse interactive experience to the audience, making the audience's interaction more balanced and enjoyable. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A flowchart illustrating a method for processing live data according to an embodiment of this application is shown; Figure 2 A flowchart illustrating a method for processing live data on a server and a client according to an embodiment of this application is shown. Figure 3 A schematic diagram of an exemplary live streaming interface according to an embodiment of this application is shown; Figure 4 A schematic diagram of the structure of an apparatus for processing live data provided in an embodiment of this application is shown; Figure 5 This application provides a schematic diagram illustrating the structure of a server and client for processing live data according to an embodiment of the present application. Figure 6 A schematic diagram of the structure of a device suitable for implementing the scheme in the embodiments of this application is shown.

[0012] The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] In a typical configuration of this application, the terminal and the service network devices each include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0015] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0016] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer program instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only optical disc (CD-ROM), digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0017] Figure 1 The illustration shows a flowchart of a method for processing live data according to an embodiment of this application. The method includes at least steps S1, S2, S3, and S4.

[0018] In practical scenarios, the execution entity of this method can be a user device, or a device formed by integrating a user device and a network device through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0019] In a live streaming scenario, the method according to this embodiment can be executed by a server used for various live streaming services.

[0020] Reference Figure 1 In step S1, in response to receiving a multi-area display instruction, the live streaming interface is divided into multiple display areas so that video sources from different broadcasters can be played in each display area.

[0021] The multi-region display command can be automatically triggered by the live streaming service, such as when an event like "multi-host PK", "cross-room connection", or "team arena" is detected. Alternatively, it can be manually initiated by the viewer or the host, for example, by the room owner clicking the "open multi-window" button, the viewer voting to select the "same-screen comparison" mode, or by the administrator setting up "theme partitions" in the background and making them effective with one click.

[0022] The method described herein can employ various approaches to determine the display area corresponding to each broadcaster when dividing the playback interface. Optionally, a random allocation method can be chosen to assign a display area to each broadcaster. This approach can bring more uncertainty and novelty to the live broadcast, increasing the audience's anticipation.

[0023] Optionally, the display position of the anchors can be arranged according to the preset default layout rules. For example, the anchors can be placed in different display areas according to the order in which they join the live broadcast room, i.e. the order of connection. The anchors who connect first are displayed on the left or at the top, and the anchors who connect later are arranged in order. This order rule can make the audience understand the order in which the anchors join more intuitively, and enhance the transparency and fairness of the live broadcast.

[0024] In one embodiment, each display area corresponds to a different priority. For example, considering the importance of different broadcasters in a live stream, different priorities are assigned to each display area. Typically, higher-priority areas are placed in the center of the screen, and these areas are also relatively larger to more prominently display the content of key broadcasters. This layout makes it easier for viewers to focus on the performance or interaction of the core broadcasters, while also providing space for other broadcasters to showcase their work. Based on this approach, the display areas and priorities of broadcasters can be flexibly adjusted according to different live streaming scenarios and needs, thereby optimizing the visual effects of the live stream and the viewing experience for viewers.

[0025] In this process, after determining the display area corresponding to each broadcaster, each display area is bound to the video source of a broadcaster, that is, the broadcaster's video stream is associated with a specific display area to ensure that each area displays the corresponding broadcaster's image.

[0026] For example, after completing the region mapping, each display region is uniquely bound to a video stream. The live streaming platform writes the streamer's RTMP / WebRTC push address into the texture cache of the corresponding rendering unit and marks the region ID in the decoding thread to ensure that the sound, picture, bullet comments, and gift effects switch synchronously as the window moves.

[0027] Optionally, a dynamic grid scheme is used for the area size. For example, this dynamic grid scheme supports a maximum of 5 live streams. If there are 5 streams, meaning there are 5 streamers to be displayed in the playback interface, a default diamond layout of "2×2+1" is provided. During viewing, if a streamer leaves, reducing the number of streams to 4, it automatically degenerates into a "2×2" equally divided layout. Furthermore, if a streamer leaves subsequently, the remaining window is proportionally enlarged within 1 second to fill the blank space and avoid black borders.

[0028] In step S2, based on the interactive behavior data of the audience during the live broadcast, the interaction weight values ​​between the audience and each anchor are obtained using a pre-trained model.

[0029] The interactive behaviors include, but are not limited to, transferring virtual resources, liking, voting, commenting, and completing tasks. The interactive behavior data may include the quantity and frequency of virtual resource transfers, the content, quantity, and popularity of sent comments, and the number of likes.

[0030] The interaction weight value represents the importance of a particular interaction in the current live streaming context. It reflects the marginal contribution of the interaction to the live streaming outcome (such as win / loss, retention rate, etc.). Optionally, the interaction weight value is calculated by a pre-trained model based on real-time collected interaction data, dynamically reflecting the actual impact of each interaction.

[0031] Specifically, step S2 includes steps S21 to S22.

[0032] In step S21, the interactive behavior data of the audience during the live broadcast is acquired in real time.

[0033] The system collects real-time data on various interactive behaviors of viewers during the live stream. For example, when a viewer transfers virtual assets (such as gifting a streamer), the system obtains the type of virtual asset and the time of the transfer; when a viewer likes or votes, the system records the number and frequency of likes or votes; when a viewer posts a comment, the system obtains the content and timestamp of the comment; when a viewer completes a specific task, the system obtains the type of task and the completion status. This data will serve as the basis for subsequent weight calculations.

[0034] It should be noted that the interactive behaviors and other related data involved in the embodiments of this application were obtained with the consent or permission of the relevant parties, and the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0035] In step S22, the acquired interactive behavior data is input into a pre-trained model, allowing the model to predict the contribution of a single interaction to the final session based on the input data and output dynamic basic weights. This model has been trained offline using historical live stream data, enabling it to learn the impact of different interactive behaviors on the live stream results. In real-time computation, these pre-trained models are loaded, preparing for the calculation of interaction weight values.

[0036] Optionally, the model includes, but is not limited to, XGBoost, LightGBM, or neural networks.

[0037] The dynamic base weight represents the importance of a particular interaction in the current live streaming scenario. It reflects the marginal contribution of that interaction to the live streaming outcome (such as win / loss, retention rate, etc.).

[0038] According to one embodiment, the process by which the model predicts the contribution of a single interaction to the final session based on input data and outputs dynamic base weights includes: First, the collected interaction behavior data is preprocessed. This preprocessing includes, but is not limited to, data cleaning to remove outliers and noisy data, ensuring the accuracy and reliability of the data.

[0039] Next, for different types of interactive behaviors, corresponding feature data are extracted.

[0040] The feature data includes, but is not limited to, at least one of the following: 1) Characteristics of virtual resource transfer behavior: including the quantity of virtual resources transferred, the frequency of virtual resource transfer behavior, and the proportion of viewers participating in virtual resource transfer; 2) Characteristics of bullet screen behavior: including the total number of bullet screens sent, the frequency of bullet screens sent (such as the number of bullet screens per minute), the popularity of bullet screen content (calculated through keyword matching and popularity algorithm), and the diversity of bullet screen content (analyzing the distribution of different topics and keywords in bullet screens), etc. 3) Characteristics of liking behavior: This includes the total number of likes, the time of peak likes, and the distribution of viewers who like the posts. The live streaming platform's servers record relevant data in real time when viewers like posts, calculate the total number of likes, and analyze the time distribution of likes to identify key time points when viewers are highly emotional and likes are concentrated. 4) Sharing behavior characteristics: These include the number of shares, the sharing channel (whether it's shared to social media platforms, instant messaging software, or other platforms), and the number of new viewers acquired after sharing. These characteristic data are obtained by tracking the generation and spread of shared links, as well as records of new viewers entering the live stream through shared links.

[0041] Specifically, for the behavior of transferring virtual resources, the extracted feature data includes the number of virtual resources transferred, the frequency of virtual resource transfer behavior, and the proportion of viewers participating in the transfer of virtual resources; for the behavior of bullet comments, the extracted feature data includes the total number of bullet comments sent, the sending frequency, the content popularity, and the diversity; for the behavior of liking, the extracted feature data includes the total number of likes, the peak time point, and the distribution of likers; for the behavior of sharing, the extracted feature data includes the number of shares, the channels, and the number of new viewers brought in.

[0042] Next, the extracted feature data is fused and input into the pre-trained model to obtain the dynamic basic weights output by the model. Specifically, the model calculates the contribution of each interaction behavior to the final session based on a predetermined algorithm and parameters, and converts it into dynamic basic weights for output.

[0043] The fusion processing includes, but is not limited to, normalization, feature concatenation, weighted feature averaging, and feature dimensionality reduction. Normalization transforms feature data of different magnitudes to the same scale, enabling the model to process these features fairly. Feature concatenation merges feature vectors from different interactions into a more comprehensive feature vector, providing the model with richer information. Weighted feature averaging assigns different weights to each feature based on its importance and then calculates a weighted average to highlight the influence of important features. Feature dimensionality reduction reduces the dimensionality of features through methods such as Principal Component Analysis (PCA), removing redundant information and improving the model's efficiency and performance.

[0044] Optionally, to adapt to new live streaming data and audience behavior patterns, the model is periodically retrained offline. This process includes: data updates: regularly collecting the latest live streaming data, including new interactive behaviors and live streaming results; model updates: retraining the model using the latest data and updating the model parameters; performance evaluation: evaluating the performance of the updated model through methods such as cross-validation to ensure that the model can continuously adapt to changes in audience behavior and maintain the accuracy and timeliness of weight calculation.

[0045] In step S3, one or more target anchors that need to be highlighted are determined based on the obtained interaction weight values.

[0046] Specifically, the interaction weight value of each streamer is monitored and ranked in real time, and one or more streamers with the highest interaction weight value are selected as target streamers. This method ensures that changes in audience interaction behavior can be captured in a timely manner through continuous tracking and dynamic evaluation of interaction weight values, and the selection of target streamers can be adjusted accordingly. After the target streamer is confirmed, the subsequent layout adjustment process of the live broadcast interface will be automatically triggered to shift the focus of the screen to the target streamer, highlighting the streamer's image, thereby improving the audience's viewing experience and interactive engagement.

[0047] For example, during a live stream, the platform uses backend algorithms to monitor each streamer's interaction weight in real time. These weights are dynamically calculated based on various audience interactions (such as tipping, liking, and commenting), reflecting the streamer's popularity and audience engagement. When the system detects that a streamer has the highest interaction weight among all streamers, that streamer is identified as the target streamer. Once the target streamer is identified, the system immediately initiates a series of pre-set screen layout adjustments, such as enlarging and centering the target streamer's image while shrinking other streamers' images and placing them at the edges of the screen. This highlights the target streamer, attracts audience attention, and enhances the live stream's interactivity and watchability.

[0048] In step S4, the layout of the playback interface is dynamically adjusted based on the determined target broadcaster to highlight the target broadcaster.

[0049] Among these features, various adjustments to the position and size of the display area can be made to highlight the target anchor.

[0050] Optionally, highlighting the target streamer can be achieved by enlarging and centering their live stream in the playback interface, while shrinking other streamers' live streams into small, real-time windows displayed at the edge of the playback interface. This layout ensures that viewers' attention is focused on the most popular or active streamer, while also providing space for other streamers to showcase their talents, thus enhancing the interactivity and watchability of the live stream.

[0051] For example, refer to Figure 3 The diagram shown illustrates a live streaming interface. This interface plays live streams from five hosts (hosts A through E), where host A is the target host to be highlighted. The highlighting effect is as follows. Figure 3 As shown, the live stream of host A in the queue is displayed in the center of the playback interface, while the live streams of the other four hosts are displayed in small windows at the bottom of the interface.

[0052] Optionally, the target streamer's image can be enlarged and placed in the center of the screen, while the images of other streamers can be distributed around the screen in the form of smaller windows.

[0053] Optionally, when the target streamer's interaction weight value changes, the playback interface layout is automatically adjusted to reflect the audience's interactive behavior in real time. For example, if the target streamer's interaction weight value increases significantly, the live streaming system can further enlarge the target streamer's image or add special effects to the target streamer's image, such as highlighted borders or dynamic backgrounds, to attract the attention of live stream viewers. Simultaneously, the live streaming system can adjust the image size and position of other streamers to better complement the target streamer. This dynamic adjustment method ensures that the screen layout always remains consistent with the audience's interactive behavior, enhancing the interactivity of the live stream and the audience's sense of participation.

[0054] According to one embodiment, the target broadcaster corresponds to a preset main display area. If the target broadcaster changes, the live stream source in the main display area is switched to the newly determined target broadcaster. The main display area is used to highlight the broadcaster; for example, the centrally located display area is designated as the main display area.

[0055] Optionally, if the target broadcaster changes, the display area corresponding to all broadcasters in the current playback interface is dynamically adjusted based on preset rules. For example, when the interaction weight value of the target broadcaster increases significantly, the system automatically enlarges the display area of ​​the target broadcaster and adjusts the size and position of the display areas of other broadcasters.

[0056] Optionally, different live streaming interface layout strategies can be selected based on the live streaming scenario and content type. For example, in a "Dance Competition Arena," the system can adopt a "dual-view structure," displaying the champion on the left, the challenger on the right, and thumbnails of the waiting hosts at the bottom. In a "Multilingual Global Competition," the system uses a "circular six-part division with central commentary" template, displaying the commentator in the central area and hosts speaking different languages ​​in the surrounding areas. This scenario-based screen layout strategy can better adapt to different live streaming content and enhance the viewer's viewing experience.

[0057] According to one embodiment, the method obtains the interface layout settings information of the viewer's end, and adjusts the display area corresponding to all anchors in the current playback interface based on the viewer's screen layout settings information.

[0058] For example, the live streaming system incorporates personalized settings for viewers, allowing them to adjust the interface layout according to their preferences. Viewers can choose to display their target streamer's screen in full screen, or select to display other streamers' screens as a semi-transparent overlay in the background. Viewers can also choose different screen layout templates, such as a "2×2+1" diamond layout or a "3×3" grid layout. This personalized screen layout setting can meet the needs of different viewers, improving viewer satisfaction and engagement.

[0059] By using the above-mentioned methods to dynamically adjust the layout of the live streaming room, the embodiments of this application can flexibly highlight the target streamer while also taking into account the display needs of other streamers, thereby improving the interactivity and user experience of the live stream.

[0060] In one embodiment, the process of a streamer entering the arena is transformed into a state machine. This state machine includes states such as waiting, requesting to challenge, locking the challenge, battle in progress, result determination, cooldown / staying in the arena, and joining the team. Idempotent APIs and event sourcing technology are used in the backend to record state changes. This design ensures the clarity and traceability of the process.

[0061] Optionally, a message queue (such as Kafka) can be used to asynchronously broadcast the status to each client to ensure synchronization of the views on each viewing end, thereby improving the system's response speed, enhancing the stability of the live stream, and improving the user experience.

[0062] According to one embodiment, the method schedules waiting anchors based on priority.

[0063] For example, in a gaming team livestream scenario, each streamer waiting in the queue is assigned a comprehensive priority. This priority is calculated based on a weighted average of multiple factors, including the streamer's application order (ensuring fairness on a first-come, first-served basis), the ranking of their team (giving streamers from higher-ranked teams a weighted advantage), recent audience engagement (calculated using a moving average algorithm to reflect the streamer's current popularity), waiting time (as the streamer's waiting time in the queue increases, their priority increases linearly to prevent streamers with long waiting times from being consistently at a disadvantage), and a cooldown penalty (if a streamer is in a cooldown period, their priority is significantly reduced to prevent frequent appearances from affecting the diversity and fairness of the livestream). These factors are weighted using adjustable parameters, and the weighting coefficients can be automatically fine-tuned based on the results of online experiments or through machine learning models to achieve the best scheduling effect.

[0064] For example, in a live stream, if streamer A's application is submitted early, their team has a high ranking, and their recent engagement is high, then streamer A's overall priority will be relatively high, and the system will prioritize letting streamer A participate. Conversely, if streamer B's team has a high ranking, but they are currently in a cooldown period due to a recent failed attempt, their priority will be significantly reduced due to the cooldown penalty, resulting in them being placed later in the scheduling process. Through this dynamic scheduling strategy that comprehensively considers multiple factors, the system can ensure that the order in which streamers participate in the live stream is both fair and interactive, while also flexibly adjusting according to different live stream scenarios to improve the overall quality of the live stream and the viewer's engagement experience.

[0065] According to one embodiment, in the live-streaming challenge-grabbing mechanism, the method employs distributed transactions and optimistic locking to control concurrency and conflict handling, ensuring the fairness and efficiency of the challenge-grabbing process. Specifically, when multiple streamers simultaneously initiate challenge-grabbing requests, the backend utilizes a lightweight distributed coordination mechanism, such as the Redis SETNX command or Lua scripts, to ensure that only one streamer can successfully grab the challenge. This mechanism can quickly respond to concurrent requests and avoid conflicts caused by multiple streamers vying for the challenge simultaneously. For streamers who fail to grab the challenge, a retry or queuing message is returned, guiding them to try again or wait for the next opportunity.

[0066] Optionally, this application embodiment designs a "challenge-taking timer window" to increase the strategic nature and fairness of the challenge-taking process. Under this mechanism, successfully challenging someone requires not only the streamer to initiate a request but also the consumption of a certain number of "challenge tokens" or reaching a threshold of audience votes. This method effectively prevents streamers from frequently attempting to challenge others, thereby avoiding unnecessary interference with the live broadcast process.

[0067] According to one embodiment, when determining the winner among multiple streamers, the method employs a steady-state threshold mechanism. This means that a streamer is only considered a winner when their leading score exceeds a preset steady-state threshold and this lead persists for at least a preset duration. This mechanism effectively reduces frequent switching due to short-term score leads, improving the stability and reliability of the competition results.

[0068] Furthermore, to handle situations where scores are very close, this application embodiment designs an overtime / quick-match mechanism. According to this mechanism, when the scores of the two broadcasters are extremely close and it is difficult to determine a winner within the normal time, a pre-set duration (e.g., 30 seconds) of quick-match period is automatically entered. During this quick-match period, the broadcasters need to increase their scores as much as possible within the limited time to strive for final victory. This mechanism not only increases the tension and entertainment value of the competition but also avoids frequent switching due to excessively close scores, ensuring the smoothness of the competition and the viewing experience for the audience.

[0069] According to one embodiment, this application uses a dynamic adjustment mechanism to determine the winner's remaining time in order to maintain the rhythm and popularity of the live broadcast while ensuring fairness.

[0070] Optionally, the winner's remaining time consists of a base remaining time and a time dynamically adjusted based on the number of consecutive wins, the streamer's level / rank, and audience popularity. The remaining time is calculated using the following formula (1): lock_time=base_lock + f(consecutive_wins, anchor_rank, audience_heat) (1) Here, `lock_time` represents the final winner's remaining time, in seconds or minutes, indicating the total duration the winner can stay. `base_lock` represents the base remaining time, which is defaulted to 30 seconds or 1 minute by the system, ensuring basic fairness by guaranteeing that every winner can remain for at least this long. `consecutive_wins` represents the number of consecutive wins; more consecutive wins will result in longer remaining time as a reward, increasing the excitement of the streak and incentivizing the streamer to maintain a high level of performance. `anchor_rank` represents the streamer's level or ranking; high-ranking streamers generate more buzz, and the system will appropriately extend their remaining time to boost overall live stream popularity and attract more viewers. `audience_heat` represents audience heat; based on real-time interaction data (such as the number of bullet comments, gifts, likes, etc.), higher audience heat allows for extended remaining time, prolonging popular moments and increasing viewer engagement and viewing experience.

[0071] According to one embodiment, in the cooling-off and anti-spam mechanism of the live streaming room, this application embodiment maintains the fairness and order of the live streaming through cooling-off strategies and abnormal interaction behavior detection. Specifically, each streamer maintains a cooling-off mapping table to record the streamer's cooling-off end timestamp. During the cooling-off period, the streamer cannot participate in the competition, or although visible, cannot interact with the audience, and their interaction weight will decay to 0, ensuring the orderly conduct of the live streaming.

[0072] Optionally, a tiered cooling-off strategy can be adopted, setting different cooling-off types and durations based on different situations, including: Failure Cooling: When a streamer loses in the arena, the system will set a basic cooling-off time, such as 30 seconds, to prevent them from immediately returning to the arena and ensure the diversity of the live stream. Voluntary Removal Cooling: If a streamer voluntarily chooses to leave the arena, the system will set a shorter cooling-off time, such as 15 seconds, to encourage streamers to rest in a timely manner and give other streamers a chance to enter the arena. Forced Cooling: For streamers who violate the live stream rules, the system will impose a longer cooling-off time, such as 5 minutes, and may impose additional penalties to maintain a healthy live stream environment.

[0073] Optionally, to further optimize the cooling-off mechanism, the system sets different decay functions for different types of cooling to adapt to different live streaming scenarios: Linear decay: During the cooling-off period, the streamer's interaction weight decreases linearly until it decays to 0 at the end of the cooling-off period. This strategy is suitable for situations where it is necessary to gradually reduce the streamer's influence. Exponential decay: For serious situations such as non-compliance with regulations, the system uses an exponential decay function to cause the streamer's interaction weight to drop rapidly, thereby quickly reducing their influence during the cooling-off period.

[0074] According to one embodiment, audience behavior is monitored in real time. By setting rate thresholds, identifying repeated tipping patterns, and aggregating IP and device information, an online model (such as sliding window statistics combined with the IsolationForest algorithm) is used to detect abnormal accounts. Once abnormal behavior is detected, the system automatically reduces the account's weight or marks it as blocked, thereby effectively curbing abnormal interaction.

[0075] A reputation score mechanism is introduced: Each viewer account has a reputation score. Users with low reputation scores or those in specific situations (such as new users) will have their voting weight limited. As user behavior remains normal, their reputation score will gradually increase, granting them more interactive privileges. This mechanism helps foster a healthy community environment while preventing new or malicious users from affecting the fairness of the live stream through abnormal behavior.

[0076] Short-term instantaneous weighted upper limit constraint: In the queuing and contestant-grabbing algorithms, the system imposes an upper limit constraint on short-term instantaneous weighted behaviors, employing rate-limiter and token-bucket algorithms to prevent a few highly active behaviors from instantly undermining fairness. This ensures that the fairness of the live stream is guaranteed even in highly interactive scenarios.

[0077] According to one embodiment, a hybrid matching strategy is employed, comprehensively considering factors such as randomness, popularity, and ranking to select streamers as challengers. For example, there is a 60% probability of sampling from top-K popular streamers to improve the viewing experience; a 30% probability of selecting the next streamer from a priority queue to ensure fairness; and a 10% probability of random selection via blind boxes to bring surprises and unexpected twists to the live stream. Optionally, an ELO / Glicko points system is used to maintain the streamer's skill level and team ranking, referencing the level difference during matchmaking to control the tension of the game and prevent excessive gaps from causing the game to lose suspense, thereby maintaining the live stream's appeal.

[0078] Figure 2 A flowchart illustrating a method for processing live data on a server and a client according to an embodiment of this application is shown. The method includes steps S101 to S105 performed by the server, and steps S201 and S202 performed by the client.

[0079] In step S101, the server responds to the received multi-region display instruction by dividing the live streaming interface into multiple display regions.

[0080] In step S102, the server uses a pre-trained model to obtain the interaction weight values ​​between the viewer and each streamer based on the viewer's interactive behavior data during the live broadcast.

[0081] In step S103, the server determines one or more target anchors that need to be highlighted based on the obtained interaction weight values.

[0082] In step S104, the server dynamically adjusts the layout of the playback interface based on the determined target broadcaster to highlight the target broadcaster.

[0083] The operations of steps S101 to S104 have been described in the sections of steps S1 to S4, and will not be repeated here.

[0084] In step S105, the server generates a corresponding layout adjustment instruction based on the adjusted playback interface layout and sends it to the client.

[0085] In step S201, the client receives a layout adjustment instruction from the server. This instruction contains the adjusted layout information, allowing the client to re-render the live stream based on this information.

[0086] In step S202, the client dynamically adjusts the layout of the current playback interface based on the layout adjustment instruction to highlight the target broadcaster.

[0087] Optionally, to ensure smooth screen transitions, client-side GPU-accelerated animations are used. For example, once the target streamer is identified, the client utilizes GPU acceleration technology to quickly zoom in and adjust the position of the image. Simultaneously, the backend system uses keyframe injection and stream switching technology to ensure the smoothness and stability of the image during the transition, providing viewers with a seamless viewing experience. This technology not only improves the speed of screen transitions but also reduces stuttering caused by network latency or data transmission issues, ensuring a smooth live stream.

[0088] According to one embodiment, the switching process of the target broadcaster is achieved by outputting an IDR frame through a backend command streaming terminal or transcoding service. The IDR frame is a keyframe containing complete video frame information, capable of being decoded and displayed immediately, thus ensuring smoothness and seamless transition during the switching. Sending the IDR frame to the client ensures that the client can quickly receive and process the frame, achieving rapid screen switching.

[0089] The process of switching the live stream source in the target area to the newly identified target streamer includes: When it is necessary to switch the target broadcaster, the server-side instruction push streamer or transcoding service generates an IDR frame and sends the generated IDR frame to the client.

[0090] The client receives the IDR frame sent by the server. Then, the client decodes the received IDR frame and displays the new target anchor's image in the corresponding target display area after decoding.

[0091] This switching method ensures the immediacy and smoothness of the video transition, avoiding stuttering or black screens caused by the transition and improving the viewing experience. Through this mechanism, the system can efficiently switch the target broadcaster's video feed, ensuring the continuity and stability of the live stream.

[0092] According to one embodiment, a dual-stream design is adopted to further optimize the smoothness and stability of screen transitions. Each broadcaster simultaneously reports two encoded streams: one is a low-latency stream (L-stream) for fast switching; the other is a high-quality stream (H-stream) for providing a clear visual experience. The backend system ensures the synchronous generation and transmission of these two streams so that the client can seamlessly receive and process them.

[0093] Specifically, the server obtains the dual-stream data of each broadcaster displayed on the current playback interface. The dual-stream data includes a low-latency stream and a high-quality stream, and sends the dual-stream data of each broadcaster to the client.

[0094] When switching target broadcasters, the client, based on the dual-stream data sent by the server, first uses the locally cached low-latency stream to switch and display the new target broadcaster's image in the corresponding target display area. Simultaneously, a high-quality stream is loaded in the background to ensure image clarity and smoothness. This dual-stream design provides a high-quality visual experience while ensuring rapid image switching, meeting the needs of viewers in different network environments.

[0095] According to the method of this application embodiment, by dividing the live broadcast room screen into multiple display areas, each area plays video sources from different anchors, providing viewers with a rich selection of viewing angles; based on the interactive behavior data of the viewers during the live broadcast, a pre-trained model is used to calculate the interaction weight value between the viewers and each anchor, and based on the interaction weight value, one or more target anchors that need to be highlighted are determined. The model's intelligent analysis assigns corresponding weights to different interactive behaviors, making the measurement of interaction more scientific and accurate, ensuring that the focus of the live broadcast content always revolves around the anchors that viewers are most interested in, enhancing the attractiveness of the live broadcast and the viewers' sense of participation; through various dynamic... By dynamically adjusting the layout of the live stream screen, this application embodiment can flexibly highlight the target streamer while also accommodating the display needs of other streamers, thereby enhancing the interactivity and user experience of the live stream. Through the introduction of mechanisms such as challenge, challenge, queuing, and cooldown, as well as modules such as teams, points, and leaderboards, these multi-layered mechanisms not only create sustained competition and rotation but also accumulate interactive results, constructing a sustainable competitive content ecosystem. By adding control mechanisms such as voting cooldown, level weighting, and mini-game bonuses, the fairness of the live stream is enhanced while also bringing a more diverse interactive experience to the audience, making the audience's interaction more balanced and enjoyable.

[0096] Figure 4 A schematic diagram of the structure of an apparatus for processing live data provided in an embodiment of this application is shown.

[0097] The device includes: an interface differentiation module 1, a weight calculation module 2, a target anchor determination module 3, and an interface layout adjustment module 4.

[0098] The weight calculation module 2 uses a pre-trained model to obtain the interaction weight values ​​between the user and each streamer based on the user's interactive behavior data during the live broadcast.

[0099] Specifically, the weight calculation module 2 is used to: acquire user interaction behavior data in real time during the live broadcast; input the acquired interaction behavior data into the pre-trained model so that the model can predict the contribution of a single interaction to the final session based on the input data, and output dynamic basic weights.

[0100] According to one embodiment, the process by which the model predicts the contribution of a single interaction to the final session based on input data and outputs dynamic base weights includes: First, the collected interaction behavior data is preprocessed. This preprocessing includes, but is not limited to, data cleaning to remove outliers and noisy data, ensuring the accuracy and reliability of the data.

[0101] Next, corresponding feature data is extracted for different types of interactive behaviors. Specifically, for virtual resource transfer behavior, the extracted feature data includes the number of virtual resources transferred, the frequency of virtual resource transfer behavior, and the proportion of viewers participating in virtual resource transfer; for bullet screen behavior, the extracted feature data includes the total number of bullet screens sent, the sending frequency, content popularity, and diversity; for liking behavior, the extracted feature data includes the total number of likes, the peak time point, and the distribution of likers; for sharing behavior, the extracted feature data includes the number of shares, the channels, and the number of new viewers brought in.

[0102] Next, the extracted feature data is fused and then input into the pre-trained model to obtain the dynamic basic weights of the model output.

[0103] Optionally, to adapt to new live streaming data and audience behavior patterns, the model is periodically retrained offline. This process includes: data updates: regularly collecting the latest live streaming data, including new interactive behaviors and live streaming results; model updates: retraining the model using the latest data and updating the model parameters; performance evaluation: evaluating the performance of the updated model through methods such as cross-validation to ensure that the model can continuously adapt to changes in audience behavior and maintain the accuracy and timeliness of weight calculation.

[0104] The target anchor determination module 3 determines one or more target anchors that need to be highlighted based on the obtained interaction weight values.

[0105] The interface layout adjustment module 4 dynamically adjusts the layout of the playback interface based on the identified target broadcaster, in order to highlight the target broadcaster.

[0106] Among these features, various adjustments to the position and size of the display area can be made to highlight the target anchor.

[0107] Optionally, highlighting the target streamer can be achieved by enlarging and centering their live stream in the playback interface, while shrinking other streamers' live streams into small, real-time windows displayed at the edge of the playback interface. This layout ensures that viewers' attention is focused on the most popular or active streamer, while also providing space for other streamers to showcase their talents, thus enhancing the interactivity and watchability of the live stream.

[0108] Optionally, when the target streamer's interaction weight value changes, the playback interface layout is automatically adjusted to reflect the audience's interactive behavior in real time. For example, if the target streamer's interaction weight value increases significantly, the live streaming system can further enlarge the target streamer's image or add special effects to the target streamer's image, such as highlighted borders or dynamic backgrounds, to attract the attention of live stream viewers. Simultaneously, the live streaming system can adjust the image size and position of other streamers to better complement the target streamer. This dynamic adjustment method ensures that the screen layout always remains consistent with the audience's interactive behavior, enhancing the interactivity of the live stream and the audience's sense of participation.

[0109] According to one embodiment, the target broadcaster corresponds to a preset main display area. If the target broadcaster changes, the live stream source in the main display area is switched to the newly determined target broadcaster. The main display area is used to highlight the broadcaster; for example, the centrally located display area is designated as the main display area.

[0110] Optionally, if the target broadcaster changes, the display area corresponding to all broadcasters in the current playback interface is dynamically adjusted based on preset rules. For example, when the interaction weight value of the target broadcaster increases significantly, the system automatically enlarges the display area of ​​the target broadcaster and adjusts the size and position of the display areas of other broadcasters.

[0111] According to one embodiment, the method obtains the interface layout settings information of the viewer's end, and adjusts the display area corresponding to all anchors in the current playback interface based on the viewer's screen layout settings information.

[0112] In one embodiment, the process of a streamer entering the arena is transformed into a state machine. This state machine includes states such as waiting, requesting to challenge, locking the challenge, battle in progress, result determination, cooldown / staying in the arena, and joining the team. Idempotent APIs and event sourcing technology are used in the backend to record state changes. This design ensures the clarity and traceability of the process.

[0113] Optionally, a message queue (such as Kafka) can be used to asynchronously broadcast the status to each client to ensure synchronization of the views on each viewing end, thereby improving the system's response speed, enhancing the stability of the live stream, and improving the user experience.

[0114] Figure 5 This illustration shows a schematic diagram of the structure of a server and a client for processing live streaming data, as provided in an embodiment of this application. The server includes an interface differentiation device 101, a weight calculation device 102, a target broadcaster determination device 103, an interface layout adjustment device 104, and a layout instruction sending device 105. The client includes an instruction receiving device 201 and a partition display device 202.

[0115] The interface differentiation device 101 responds to receiving a multi-area display instruction by dividing the live broadcast interface into multiple display areas.

[0116] The weight calculation device 102 uses a pre-trained model to obtain the interaction weight values ​​between the viewer and each streamer based on the viewer's interactive behavior data during the live broadcast.

[0117] The target anchor determination device 103 determines one or more target anchors that need to be highlighted based on the obtained interaction weight values.

[0118] The interface layout adjustment device 104 server dynamically adjusts the layout of the playback interface based on the determined target broadcaster in order to highlight the target broadcaster.

[0119] The operation of the interface differentiation device 101, weight calculation device 102, target anchor determination device 103, and interface layout adjustment device 104 is the same as that of the interface differentiation module 101, weight calculation module 102, target anchor determination module 103, and interface layout adjustment module 104, and will not be described again here.

[0120] The layout instruction sending device 105 generates a corresponding layout adjustment instruction based on the adjusted layout of the playback interface and sends it to the client.

[0121] The instruction receiving device 201 receives a layout adjustment instruction from the server. This layout adjustment instruction includes adjusted layout information so that the client can re-render the live stream based on this information.

[0122] Based on the layout adjustment command, the partition display device 202 dynamically adjusts the layout of the current playback interface to highlight the target broadcaster.

[0123] Optionally, to ensure smooth screen transitions, client-side GPU-accelerated animations are used. For example, once the target streamer is identified, the client utilizes GPU acceleration technology to quickly zoom in and adjust the position of the image. Simultaneously, the backend system uses keyframe injection and stream switching technology to ensure the smoothness and stability of the image during the transition, providing viewers with a seamless viewing experience. This technology not only improves the speed of screen transitions but also reduces stuttering caused by network latency or data transmission issues, ensuring a smooth live stream.

[0124] According to one embodiment, the switching process of the target broadcaster is achieved by outputting an IDR frame through a backend command streaming terminal or transcoding service. The IDR frame is a keyframe containing complete video frame information, capable of being decoded and displayed immediately, thus ensuring smoothness and seamless transition during the switching. Sending the IDR frame to the client ensures that the client can quickly receive and process the frame, achieving rapid screen switching.

[0125] The process of switching the live stream source in the target area to the newly identified target streamer includes: When it is necessary to switch the target broadcaster, the server-side instruction push streamer or transcoding service generates an IDR frame and sends the generated IDR frame to the client.

[0126] The client receives the IDR frame sent by the server. Then, the client decodes the received IDR frame and displays the new target anchor's image in the corresponding target display area after decoding.

[0127] This switching method ensures the immediacy and smoothness of the video transition, avoiding stuttering or black screens caused by the transition and improving the viewing experience. Through this mechanism, the system can efficiently switch the target broadcaster's video feed, ensuring the continuity and stability of the live stream.

[0128] According to one embodiment, a dual-stream design is adopted to further optimize the smoothness and stability of screen transitions. Each broadcaster simultaneously reports two encoded streams: one is a low-latency stream (L-stream) for fast switching; the other is a high-quality stream (H-stream) for providing a clear visual experience. The backend system ensures the synchronous generation and transmission of these two streams so that the client can seamlessly receive and process them.

[0129] Specifically, the server obtains the dual-stream data of each broadcaster displayed on the current playback interface. The dual-stream data includes a low-latency stream and a high-quality stream, and sends the dual-stream data of each broadcaster to the client.

[0130] When switching target broadcasters, the client, based on the dual-stream data sent by the server, first uses the locally cached low-latency stream to switch and display the new target broadcaster's image in the corresponding target display area. Simultaneously, a high-quality stream is loaded in the background to ensure image clarity and smoothness. This dual-stream design provides a high-quality visual experience while ensuring rapid image switching, meeting the needs of viewers in different network environments.

[0131] The apparatus according to the embodiments of this application divides the live broadcast room screen into multiple display areas, each playing video sources from different anchors, providing viewers with a rich selection of viewing angles. Based on the interactive behavior data of the viewers during the live broadcast, a pre-trained model is used to calculate the interaction weight values ​​between the viewers and each anchor, and one or more target anchors that need to be highlighted are determined based on these interaction weight values. The intelligent analysis of the model assigns corresponding weights to different interactive behaviors, making the measurement of interaction more scientific and accurate, ensuring that the focus of the live broadcast content always revolves around the anchors that viewers are most interested in, thereby enhancing the attractiveness of the live broadcast and the viewers' sense of participation. Through various ways of dynamically adjusting the layout of the live broadcast room screen, the embodiments of this application can flexibly highlight target anchors while also taking into account the display needs of other anchors, improving the interactivity and user experience of the live broadcast.

[0132] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0133] The electronic device can be a user device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0134] Figure 6The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes based on a program stored in a Read Only Memory (ROM) 1202 or a program loaded from a storage portion 1208 into a Random Access Memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An Input / Output (I / O) interface 1205 is also connected to the bus 1204.

[0135] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, touchscreen, microphone, infrared sensor, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), LED display, OLED display, etc., and speakers, etc.; a storage section 1208 including one or more computer-readable media such as hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet.

[0136] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 1201, it performs the functions defined in the methods of this application.

[0137] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0138] Specifically, this embodiment may employ any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0139] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0140] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0141] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0142] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0143] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0144] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or page components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0145] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0146] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0147] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0148] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0149] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices described in an apparatus may also be implemented by a single unit or device through software or hardware. Terms such as "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A method for processing live streaming data, wherein, The method includes: In response to receiving a multi-area display instruction, the live streaming interface is divided into multiple display areas to play video sources from different broadcasters in each display area; Based on the interactive behavior data of the audience during the live broadcast, the interaction weight values ​​between the audience and each streamer are obtained using a pre-trained model. Based on the obtained interaction weight values, identify one or more target broadcasters that need to be highlighted; Based on the identified target broadcaster, the layout of the playback interface is dynamically adjusted to highlight the target broadcaster.

2. The method according to claim 1, wherein, The interaction weight values ​​between users and each streamer are obtained using a pre-trained model based on user interaction behavior data during the live broadcast. Real-time acquisition of audience interaction data during live streaming; The acquired interactive behavior data is input into a pre-trained model so that the model can predict the contribution of a single interaction to the final session based on the input data and output dynamic basic weights.

3. The method according to claim 2, wherein, The model predicts the contribution of a single interaction to the final session based on the input data and outputs dynamic basic weights including: Preprocess the collected interaction data; Extract relevant feature data for different types of interactive behaviors; The extracted feature data is processed by summation and then input into the pre-trained model to obtain the dynamic basic weights of the model output.

4. The method according to claim 3, wherein, The interactive behaviors include transferring virtual resources, sending bullet comments, liking, and sharing. Extracting corresponding feature data for different types of interactive behaviors includes: For the behavior of transferring virtual resources, the extracted feature data includes the number of virtual resources transferred, the frequency of virtual resource transfer behavior, and the proportion of viewers who participated in transferring virtual resources. For bullet screen behavior, the extracted feature data includes the total number of bullet screens sent, the sending frequency, the content popularity, and diversity characteristics; For the "like" behavior, the extracted feature data includes the total number of likes, the peak time point, and the distribution characteristics of the like audience; For sharing behavior, the extracted feature data includes the number of shares, the channels used, and the number of new viewers acquired.

5. The method according to claim 1, wherein, The method highlights the target broadcaster in the following ways: The target streamer's live stream is enlarged and centered in the playback interface, while other streamers' live streams are shrunk into small real-time windows and displayed at the edge of the playback interface.

6. The method according to claim 1 or 5, wherein, The target broadcaster corresponds to a preset main display area. The step of dynamically adjusting the layout of the playback interface based on the determined target broadcaster to highlight the broadcaster includes: If the target streamer changes, the live stream source in the main display area will be switched to the newly determined target streamer.

7. The method according to claim 1, wherein, The method further includes: The process of a streamer entering the arena is transformed into a state machine, and API and event tracing technology are used to record state changes. The state machine includes waiting, requesting to enter the arena, locking the arena, the battle in progress, result determination, cooldown / staying in the arena, and joining the team.

8. A method for processing live streaming data on a server side, wherein, The method includes: In response to receiving a multi-area display instruction, the live streaming interface is divided into multiple display areas; Based on the interactive behavior data of the audience during the live broadcast, the interaction weight values ​​between the audience and each streamer are obtained using a pre-trained model. Based on the obtained interaction weight values, identify one or more target broadcasters that need to be highlighted; Based on the identified target broadcaster, the layout of the playback interface is dynamically adjusted to highlight the target broadcaster. Based on the adjusted playback interface layout, corresponding layout adjustment instructions are generated and sent to the client.

9. The method according to claim 8, wherein, Live stream source switching is achieved by outputting an IDR frame through a backend command push terminal or transcoding service. The process of switching the live stream source of the target area to the newly determined target broadcaster includes: When it is necessary to switch the target broadcaster, the instruction push streaming end or transcoding service generates an IDR frame; The generated IDR frame is sent to the client.

10. The method according to claim 8 or 9, wherein, The method further includes: Obtain dual-stream data of each broadcaster displayed on the current playback interface, wherein the dual-stream data includes low-latency stream and high-quality stream; Send the dual-stream data of each broadcaster to the client.

11. A method for processing live streaming data on a client side, wherein, The method includes: Receive layout adjustment instructions from the server; Based on the layout adjustment command, the layout of the current playback interface is dynamically adjusted to highlight the target streamer; Receive IDR frames sent by the server; The received IDR frames are decoded, and the new target anchor's image is displayed in the corresponding target display area after decoding is completed.

12. The method according to claim 11, wherein, The method further includes: When it is necessary to switch the target broadcaster, the client first uses the locally cached low-latency stream to switch the screen of the new target broadcaster based on the dual-stream data sent by the server, and then loads the high-quality stream in parallel in the background.

13. An apparatus for processing live data, wherein, The device includes: The interface partitioning module is used to respond to the received multi-area display command, divide the live broadcast interface into multiple display areas, and play the video source of different broadcasters in each display area; The weight calculation module is used to obtain the interaction weight values ​​between users and each streamer based on the user's interactive behavior data during the live broadcast using a pre-trained model. The target anchor identification module is used to identify one or more target anchors that need to be highlighted based on the obtained interaction weight values; The interface layout adjustment module is used to dynamically adjust the layout of the playback interface based on a determined target broadcaster, so as to highlight the target broadcaster.

14. An electronic device, the electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 12.

15. A computer-readable medium having stored thereon computer program instructions that can be executed by a processor to implement the method as claimed in any one of claims 1 to 12.

16. A computer program product comprising a computer program that, when executed by a processor, implements the method of any one of claims 1 to 12.

Images