Interaction method, device and system for linkage live broadcast room

Abstract

The application provides an interaction method, device, system, electronic equipment, computer readable medium and program product of a linkage live room. A specific embodiment of the application includes: determining a pre-defined type of interaction message in a time window in a plurality of linkage live rooms, wherein the time window dynamically advances with the live time; generating a linkage interaction event of the plurality of linkage live rooms according to the interaction message with a conflict association relationship in the time window; and displaying the interaction effect corresponding to the linkage interaction event through the client of each of the plurality of linkage live rooms. The application aligns the interaction messages of the plurality of linkage live rooms in a unified time window, and performs cross-live room interaction of the plurality of linkage live rooms through a unified linkage interaction event corresponding to the time window, thereby reducing the out-of-order rate, missed triggering rate and repeated determination probability of the cross-live room interaction event, and improving the consistency of the cross-live room interaction result.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an interactive method, apparatus, system, electronic device, computer-readable medium, and program product for linking live streaming rooms. Background Technology

[0002] Live streaming platforms often feature interconnected scenarios between multiple live streams, such as live chat collaborations, cross-venue interactions, dual commentary for events, and joint activities across multiple live streams. To enhance the interactive atmosphere, platforms typically allow viewers to trigger specific interactive effects by sending bullet comments (danmaku), such as cross-room cheering, progressing through collaborative tasks, unlocking bullet comment counts, and highlighting cross-room statuses.

[0003] In existing technologies, most interactive message processing methods are still centered on a single live streaming room. That is, each live streaming room receives interactive messages from its own room, completes the message parsing, trigger condition judgment, and interactive result generation processes locally or in the corresponding service node, and then broadcasts the results to other linked live streaming rooms through the server, or copies the results of one linked live streaming room to other linked live streaming rooms.

[0004] This section is intended to provide background or context for the embodiments of this application as set forth in the claims. The description herein is not to be construed as prior art simply because it is included in this section. Summary of the Invention

[0005] This application provides a method, apparatus, system, electronic device, computer-readable storage medium, and program product for interactive live streaming rooms. Addressing the technical problem that existing solutions process interactive messages in a single live streaming room, leading to different trigger times for the same interactive intent in different linked live streaming rooms and inconsistent cross-live streaming room interaction results, this application aligns interactive messages from multiple linked live streaming rooms within a unified time window. By using unified linked interactive events corresponding to the time window for cross-live streaming room interaction, the application reduces the out-of-order rate, missed trigger rate, and duplicate judgment probability of cross-live streaming room interactive events, thereby improving the consistency of cross-live streaming room interaction results.

[0006] One aspect of this application provides an interactive method for linked live streaming rooms, comprising: determining predefined types of interactive messages within a time window in multiple linked live streaming rooms, wherein the time window dynamically advances with the live streaming time; generating linked interactive events for multiple linked live streaming rooms based on interactive messages with conflicting relationships within the time window; and displaying the interactive effects corresponding to the linked interactive events through the respective clients of the multiple linked live streaming rooms.

[0007] Another aspect of this application provides an interactive device for linking live streaming rooms, comprising: a message determination unit configured to determine predefined type interactive messages within a time window in multiple linked live streaming rooms, wherein the time window dynamically advances with the live streaming time; an event generation unit configured to generate linked interactive events for multiple linked live streaming rooms based on interactive messages with conflicting relationships within the time window; and a linked interactive unit configured to display the interactive effects corresponding to the linked interactive events through the respective clients of the multiple linked live streaming rooms.

[0008] Another aspect of this application provides a linked live streaming system, including a client and a server. The server is used to: determine predefined types of interactive messages within a time window in multiple linked live streaming rooms, wherein the time window dynamically advances with the live streaming time; and generate linked interactive events for multiple linked live streaming rooms based on interactive messages with conflicting relationships within the time window. The client is used to: display the interactive effects corresponding to the linked interactive events on the live streaming interface of the linked live streaming rooms.

[0009] In another aspect of this application, an electronic device is provided, comprising: 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, the instructions being executed by the at least one processor to enable the at least one processor to perform the interactive method of the linked live streaming room as described above.

[0010] Another aspect 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 interactive method of the linked live streaming room as shown above.

[0011] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the interactive method of the linked live streaming room as described above.

[0012] The solution provided in this application identifies predefined types of interactive messages within a time window in multiple linked live streaming rooms, where the time window dynamically advances with the live streaming time. Based on interactive messages with conflicting relationships within the time window, linked interactive events for multiple linked live streaming rooms are generated. The interactive effects corresponding to the linked interactive events are displayed through the respective live streaming devices of each of the multiple linked live streaming rooms. This achieves unified time window alignment of the interactive messages in multiple linked live streaming rooms, and enables cross-live streaming room interaction through the unified linked interactive events corresponding to the time window. This reduces the out-of-order rate, missed trigger rate, and duplicate judgment probability of cross-live streaming room interactive events, thereby improving the consistency of cross-live streaming room interaction results.

[0013] Furthermore, through a cross-live-room conflict arbitration mechanism, a unique and valid linked interactive event is output when interactive events are triggered simultaneously or nearly simultaneously in multiple live-rooms, effectively avoiding the problems of event duplication and mutual overwriting; through a versioned incremental synchronization mechanism for interactive states, only the changed parts (incremental state fragments) relative to the previous stable interactive state are synchronized, reducing the transmission overhead and client processing pressure during cross-live-room linkage; through confirmation receipts, resending, and rollback mechanisms, the recovery capability in some live-room synchronization failure scenarios is improved, enhancing the consistency and controllability of multi-live-room interactive results. Attached Figure Description

[0014] 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.

[0015] 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:

[0016] Figure 1 A flowchart illustrating an interactive method for a linked live streaming room provided in an embodiment of this application;

[0017] Figure 2A A schematic diagram of the mounting points in the rendering interface for live streaming interactive effects.

[0018] Figure 2B This is a schematic diagram illustrating the live streaming scenario linked to this application;

[0019] Figure 3 A flowchart illustrating an interactive method for a linked live streaming room, provided as another embodiment of this application;

[0020] Figure 4 A schematic diagram of the structure of an interactive device for a live streaming room provided in an embodiment of this application;

[0021] Figure 5 This is a schematic diagram of the structure of a live streaming system provided in an embodiment of this application;

[0022] Figure 6 A schematic diagram of the structure of a device suitable for implementing the solutions in the embodiments of this application.

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

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] This application provides an interactive method for linked live streaming rooms. It identifies predefined types of interactive messages within a time window in multiple linked live streaming rooms, where the time window dynamically advances with the live streaming time. Based on interactive messages with conflicting relationships within the time window, it generates linked interactive events for multiple linked live streaming rooms. The interactive effects corresponding to these linked interactive events are displayed on the respective live streaming devices of each of the multiple linked live streaming rooms. This achieves unified time window alignment of the interactive messages across multiple linked live streaming rooms, and enables cross-live streaming room interaction through the unified linked interactive events corresponding to the time windows. This reduces the out-of-order rate, missed trigger rate, and duplicate judgment probability of cross-live streaming room interactive events, thereby improving the consistency of cross-live streaming room interaction results.

[0029] It should be noted that in the technical solution of this application, the collection, storage, use, etc. of any type of data such as user data comply with relevant national laws and regulations and are carried out on the premise of obtaining the clear authorization of the user.

[0030] In an actual scenario, the execution entity of this method can be a user device, or a device formed by integrating the user device and a network device through a network, or it can also be an application program running on the above-mentioned device. The above-mentioned user devices include but are not limited to various terminal devices such as computers, mobile phones, tablet computers, smart watches, and bracelets. The above-mentioned network devices include but are not limited to implementations such as network hosts, single network servers, multiple network server sets, or computer collections based on cloud computing. Here, the cloud consists of a large number of hosts or network servers based on cloud computing (Cloud Computing). Among them, cloud computing is a type of distributed computing and consists of a virtual computer formed by a group of loosely coupled computers.

[0031] Figure 1 Fig. 100 shows the processing flow of an interactive method for a linked live room provided by an embodiment of this application. Among them, the processing flow 100 includes the following steps:

[0032] Step 101, determine the interactive messages of a predefined type within a time window in multiple linked live rooms.

[0033] A linked live room refers to multiple independent live rooms that are logically associated based on the same activity or interaction rule, so that specific interactive behaviors generated in one room can affect the display effect or status of other rooms. For example, when two live users conduct a co-hosting interaction, their respective rooms form a group of linked live rooms; when live users in multiple branch venues participate in a joint activity together, all the branch venue rooms form a group of linked live rooms; in a sports event live broadcast, the main live room and multiple commentator live rooms form a linked live room for synchronizing the bullet screen interaction task.

[0034] The time window is a time interval that dynamically advances along the live time axis and is used to define the time range within which the system needs to collect and process interactive messages. The window has a length (duration) and a sliding step (for a sliding window) or fixed round boundaries (for a fixed window), and is updated in real time as the live time progresses. Its function is to absorb the differences in the arrival times of events caused by clock deviations and network transmission delays between different live rooms, so that interactive messages belonging to the same round of linked intentions can be grouped into the same window for processing.

[0035] Taking a fixed time window as an example, with the start time of the linkage as zero, each 5-second interval is divided into a window, successively [0s, 5s), [5s, 10s), [10s, 15s), etc. The window boundaries do not overlap and advance continuously. Taking a sliding time window as an example, the window length is 5 seconds, and the system recalculates the current window every 0.5 seconds, always covering messages within the range of [current time - 5s, current time).

[0036] The length of the window can be preset or dynamically adjusted based on factors such as the linked scenario, the number of linked live streaming rooms, and network latency.

[0037] In interactive scenarios, window length is related to factors such as the response sensitivity requirements of the interactive scenario, message concurrency density, the natural rhythm of interactive effects, and the intensity of resource conflicts. For example:

[0038] In scenarios requiring high responsiveness (rapid feedback), such as instantaneous competitive interactions (resource grabbing, highlighting applications) and high-frequency counting interactions (real-time cheering leaderboard, bursts of likes), the window length should be relatively short (e.g., 0.5 to 2 seconds) to ensure that the interactive effect is presented in a timely manner and reduce the user's perceived delay.

[0039] In scenarios with low response sensitivity requirements (tolerating a certain delay), such as long-cycle task advancement (joint task accumulation, phase unlocking) and low-density interaction (linkage between sub-venues with fewer live streaming sessions), the window length can be longer (usually 3 to 10 seconds) to reduce arbitration frequency and synchronization overhead.

[0040] In scenarios with high message concurrency (large number of bullet comments / likes), the window length should be appropriately shortened to avoid excessive arbitration calculation pressure and window processing latency exceeding limits due to too many candidate events in a single window.

[0041] In scenarios with low message concurrency density (sparse interaction), the window length should be appropriately extended to ensure that a sufficient number of candidate events are accumulated within the window, making aggregation and arbitration meaningful and avoiding frequent output of empty results or invalid events.

[0042] Regarding the natural rhythm of interactive effects, if the interactive effect itself cycles in a short period (such as a heartbeat effect per second), the window length should match the rhythm; if the effect progresses in a longer phase (such as a progress bar updating in segments), the window length can be increased accordingly.

[0043] Depending on the intensity of resource conflicts, for competitive scenarios involving shared resources (unique highlighting, exclusive effects), the window length should be short to facilitate quick adjudication and resource release; for low-conflict scenarios (independent counting, non-preemptive tasks), the window length can be set longer to simplify the processing logic.

[0044] Under the factor of the number of linked live rooms, the length of the window can be positively correlated with the number of linked live rooms. That is, the more the number of linked live rooms, the longer the length of the window; the fewer the number of linked live rooms, the shorter the length of the window.

[0045] Under the factor of the network latency of linked live rooms, the length of the window can be positively correlated with the network latency of linked live rooms. That is, the greater the network latency of linked live rooms, the longer the length of the window; the smaller the network latency of linked live rooms, the shorter the length of the window.

[0046] An interactive message refers to a data unit generated by a live user in a linked live room, with an interactive intention and can be received by the system. It can be text, instructions, digital signals or structured events, usually encapsulated by the client and reported to the server. Interactive messages include, for example, bullet screen text, like events, gift giving, task operations, co-host requests, etc.

[0047] The predefined type refers to the message category in which an interactive message is recognized as being able to trigger a linked interaction. The message content or behavior of the interactive message under the predefined type matches the preset rules, and after a successful match, it can initiate the subsequent process of generating linked interaction events. For example, the interactive message carries specific keywords, instruction formats, counting identifiers or task progress identifiers; the user operation corresponding to the interactive message has a clear linked intention (such as cheering, completing a task, applying for resources, etc.); the system has pre-configured matching rules, and only messages that meet the rules are classified into the predefined type.

[0048] Taking the interactive message as a bullet screen as an example, its specified keywords are, for example, preset words such as "cheering" and "go go go"; its specified instruction format is, for example, the bullet screen starts with " / ", "@" or a specific symbol, such as " / help" and "@task"; taking the specified task progress type bullet screen as an example, the bullet screen contains words related to task progress such as "contribute 1 point" and "check in"; taking the specified counting type bullet screen as an example, the bullet screen contains words for counting accumulation such as "light up" and "heat + 1".

[0049] For other forms of interactive messages, taking likes as an example, when the number of consecutive likes reaches a preset number (such as 3 times), it is regarded as a counting accumulation type interactive message in the predefined type; taking forwarding as an example, the user's behavior of forwarding the live room to other platforms is regarded as a task progress type interactive message (such as completing a sharing task); taking gifts as an example, giving a specific gift (such as "cheering rocket") is regarded as an interactive message of the predefined keyword type; taking a co-host request as an example, when the user initiates a co-host request, it is regarded as a predefined message of the resource competition type (requiring arbitration).

[0050] As an example, the system pre-sets a fixed window length (e.g., 5 seconds) and divides the live stream timeline into continuous, non-overlapping fixed windows, starting from the moment the live stream begins. The system maintains a current window in real time, defined by its start and end times, where the end time equals the start time plus the window length. As the live stream progresses, when the system time exceeds the current window's end time, the system immediately updates the start time to the original end time and the end time to the new start time plus the window length, thus dynamically advancing the window (i.e., switching to the next window).

[0051] For each reported interactive message, the system first determines whether it belongs to a predefined type. If it does, the system performs the following checks based on the standardized timestamp carried in the message (adjusted for room offset and network compensation):

[0052] If the standardized timestamp is greater than or equal to the start time of the current window and less than the end time of the current window, then the message is included in the processing pool of the current window.

[0053] If the standardized timestamp is less than the start time of the current window (i.e. the message is too old), it is discarded or ignored (considered as expired).

[0054] If the standardized timestamp is greater than or equal to the end time of the current window (i.e., the message belongs to a future window), it can be temporarily stored in the buffer and re-evaluated after the current window advances (or directly postponed until the corresponding window is activated before processing).

[0055] As another example, the system presets a time window length (e.g., 3 seconds) and a sliding period (e.g., 0.5 seconds). The system maintains a floating range with the current system time as the end boundary, backwards through the window length, i.e., [current time - window length, current time]. Every sliding period, the system recalculates the start and end times of the current window. For each real-time reported interactive message, the system first performs a predefined type determination, and then determines whether the adjusted timestamp falls within the start and end range of the current window. If it falls within the range, the message is immediately added to the pending set of the current window; if it does not fall within the current window, it is discarded or delayed to a subsequent window as needed (if the message timestamp is greater than the end time of the current window, it can be temporarily stored and re-evaluated after the window slides). Simultaneously, for messages already added to the current window, when the window slides (i.e., the new window no longer contains the message timestamp), the system clears or archives the data of the old window and begins processing the message set in the new window.

[0056] In some optional implementations of this embodiment, step 101 is performed as follows: First, for interactive messages of predefined types in multiple linked live streaming rooms, the timestamp of the interactive message is adjusted according to the time offset correction parameter of the live streaming room to which the interactive message belongs and the network compensation parameter corresponding to the network quality of the live streaming room, so as to obtain the adjusted timestamp; then, interactive messages in multiple linked live streaming rooms whose adjusted timestamps are within the time window are determined.

[0057] The time offset correction parameter is used to characterize the time difference between the local system time of a single linked live streaming room and the server's standard reference time, and is used to correct the local clock deviation of each live streaming room. The server periodically synchronizes its time with each linked live streaming room, compares the difference between the local time of the live streaming room and the server's standard time, and fixes it as the time offset correction parameter specific to that live streaming room.

[0058] Network compensation parameters are correlated with the real-time network quality of the live streaming room and are used to correct latency in the transmission of interactive messages, thus smoothing out the transmission time differences caused by varying network speeds in different live streaming rooms. The server monitors the average transmission latency and network jitter metrics of each live streaming room in real time, maps and matches preset latency compensation levels according to network quality levels, and generates corresponding network compensation parameters for each live streaming room.

[0059] As an example, during the collaborative live streaming process, the predefined type interactive messages generated by each collaborative live streaming room carry the original timestamp generated locally on the client and are reported to the server.

[0060] The server retrieves the pre-calibrated time offset correction parameters of the live broadcast room to which the interactive message belongs, and corrects the reference time deviation caused by the inconsistency of the local clock; then, it combines the network compensation parameters corresponding to the current network quality of the live broadcast room to compensate for the link latency caused during message transmission.

[0061] The server combines two parameters to overlay and correct the original timestamp, calculating the adjusted timestamp. Then, it compares the adjusted timestamp with the start and end times of the time window that dynamically advances with the live broadcast time, and only selects interactive messages whose adjusted timestamps fall within the time window range, which are then included in the subsequent linkage processing flow.

[0062] In this implementation, message timestamps are corrected by using both clock offset and network latency parameters, unifying the timing benchmark across multiple live streaming rooms, eliminating filtering errors caused by clock differences and network fluctuations, and making cross-room message timing determination more accurate.

[0063] Step 102: Generate interactive events for multiple linked live streaming rooms based on interactive messages with conflicting relationships within the time window.

[0064] Conflict relationships refer to the competing, repeatedly triggered, or resource-conflicting relationships between multiple interactive messages from one or more interconnected live streaming rooms within the same time window. These relationships prevent the system from directly responding to all messages simultaneously, requiring adjudication or merging to output a unified interactive result.

[0065] In competitive relationships, the interactive messages generated by different collaborative live streams may have exclusive or priority differences in the expected collaborative effects. For example, if two people simultaneously apply for a globally unique special effect resource (such as highlighting or full-screen animation), only one can succeed. For instance, if room A and room B send the "grab the banner" command in the chat almost simultaneously, the system needs to determine which room will receive the banner display.

[0066] For conflicting relationships that are repeatedly triggered, the same intention to link together is expressed repeatedly in multiple interactive messages, but according to the activity rules, it only needs to be counted as once or needs to be merged. For example, two live stream users send "check-in" bullet comments in the same link window, but the rules stipulate that the check-in effect should only be triggered once in each window, so the system needs to remove duplicates.

[0067] In resource conflicts, the shared resources requested by the interactive message (such as task progress limits, counting thresholds, and device status) are already occupied or temporarily unavailable, causing subsequent messages to wait, be downgraded, or be discarded. For example, if a linkage rule limits "only one room is allowed to initiate an acceleration request at a time," then when a room has already occupied acceleration resources, acceleration requests from other rooms will result in a resource conflict.

[0068] A linked interactive event refers to the unique and valid interactive result output by the system after adjudicating or merging multiple interactive messages with conflicting relationships. This event carries the final linkage intent of all related messages within the current time window (such as numerical accumulation, resource granting, progress updating, or effect triggering) and serves as the atomic unit for subsequent cross-room status synchronization and effect display. Linked interactive events are unique and deterministic, and typically include information such as event type, influencing parameters, and time markers.

[0069] As an example, if the system detects multiple interactive messages competing for or conflicting resources within the current time window (e.g., simultaneously requesting the same exclusive resource), the system will directly select one message from these messages based on a preset decision-making strategy (such as order of arrival, preset weight of the message's source room, or priority identifier carried by the message itself), and output its expressed interactive intent as the linked interactive event for this window. Messages not selected will not produce any linked effects. This linked interactive event is the only valid output within the window.

[0070] For example, two linked live streams each send an interactive message requesting "full-screen effect" within the same time window. The system uses the order of message arrival as the decision strategy, selecting the first message to arrive to generate a linked interactive event with the content "trigger full-screen effect". The other message is ignored. The window ultimately outputs a single linked interactive event.

[0071] As another example, the system detects multiple interactive messages within the current time window that exhibit repeated triggering or cumulative relationships (e.g., expressing the same intention to advance a count multiple times). In this case, the system does not compete to select these messages. Instead, based on a pre-defined merging logic, it accumulates the values ​​or counts carried by the multiple messages as a whole (or takes a single valid value), and outputs the accumulated result as the content of the linked interactive event. This linked interactive event is the only valid output within the window, representing the combined contribution of all related messages.

[0072] For example, three interconnected live streams send "task progress" interactive messages within the same time window, each carrying a progress value of 1, 1, and 2 respectively. The system calculates the total progress value to 4 using a "numerical accumulation" merging logic, generating a single interconnected interactive event: "Total Progress + 4". The window ultimately outputs this single interconnected interactive event, instead of three separate events.

[0073] In some optional implementations of this embodiment, multiple interactive events for linked live streaming rooms are generated based on interactive messages with conflicting relationships within a time window in the following manner:

[0074] The first step is to generate candidate interactive events representing interactive messages within a time window based on the predefined type to which the interactive messages belong. The second step is to identify linked interactive events from multiple candidate interactive events that have conflicting relationships.

[0075] As an example, based on the predefined type of the interactive message, candidate interactive events are generated by aggregating the interactive messages from each linked live stream within the current time window, either individually or by type. Each candidate interactive event carries at least the event's time window identifier, the associated linked live stream identifier, the interactive message type identifier, interactive behavior characteristic information, event trigger attributes, and event priority information. The relationships between multiple candidate interactive events are identified; those that are mutually exclusive in terms of triggering timing, display resource consumption, and linked business requirements, and cannot be effective simultaneously, are determined to have conflicting relationships. From this group of conflicting candidate interactive events, one is selected as the final effective linked interactive event; the remaining conflicting candidate interactive events are invalidated and do not participate in subsequent effect display.

[0076] As another example, based on the predefined type category corresponding to each interactive message, the interactive messages within the dynamically advancing current time window are categorized and sorted. Candidate interactive events are constructed by generating them independently for each individual interactive message or by aggregating similar interactive messages. All generated candidate interactive events within the current time window are traversed. Based on the inherent constraints of the business scenario, it is determined whether multiple candidate interactive events have related restrictions such as business logic conflicts, display level conflicts, or mutual exclusion of linkage triggers. Multiple candidate interactive events that meet the mutual exclusion restrictions are divided into a set of candidate events with conflicting relationships. Within this set of candidate events with conflicting relationships, a unique linkage interactive event is determined to be officially effective for displaying the corresponding interactive effect on each client. The remaining conflicting candidate interactive events are not activated.

[0077] In this implementation, candidate interactive events are generated according to predefined types, conflicting relationships between events are identified, and the best linked interactive events are selected. This avoids mutual exclusion interference between events and ensures that the interaction between multiple links is triggered in an orderly and accurate manner.

[0078] In some optional implementations of this embodiment, the second step described above is performed in the following manner to determine the linked interactive events from multiple candidate interactive events that have conflict relationships: First, a target conflict arbitration rule is determined from the set of conflict arbitration rules; then, the target conflict arbitration rule is used to determine the linked interactive events from multiple candidate interactive events that have conflict relationships.

[0079] Conflict arbitration rules are a set of rules pre-configured on the server side for selecting and controlling the selection of multiple candidate interactive events with conflicting relationships. They are used to make unified decisions to select a unique linked interactive event in scenarios such as multiple events being mutually exclusive, resource competition, and duplicate intentions, so as to avoid display confusion and logical conflicts caused by multiple events being triggered simultaneously.

[0080] The set of conflict arbitration rules includes, but is not limited to, the following conflict arbitration rules:

[0081] The master control room priority rule stipulates that for multiple linked live streaming rooms in a linkage group, one live streaming room is pre-designated as the master control room. When candidate interactive events generated by different live streaming rooms conflict, the candidate event corresponding to the master control room is selected as the event to be taken into effect, and the conflicting events in the other slave control rooms are temporarily not effective.

[0082] Event priority rules pre-set fixed priority levels for candidate interactive events corresponding to different predefined types. When event conflicts occur, the candidate event of the higher priority type is selected directly, and the lower priority event is not effective.

[0083] The event freshness rule, when conflicting candidate events have the same priority, selects the candidate event that is closer to the center of the current time window or closer to the baseline time of this round of processing based on the timestamp of the corresponding interaction message.

[0084] Resource occupancy rules stipulate that if shared resources such as interface rendering resources and motion effect channels corresponding to a certain interactive effect are still occupied and not released, conflicting candidate events will be handled by delaying triggering, directly discarding, or downgrading to low resource consumption effects.

[0085] The deduplication rule is as follows: if multiple live streaming rooms generate candidate interactive events that are determined to be duplicate events with the same linkage intention and the same business requirement, only one will be retained as a valid event, and the rest will be marked as events from the same source and merged, and will not trigger the linkage process again.

[0086] As an example, the server pre-builds and stores a set of conflict arbitration rules, which includes conflict arbitration rules for various applicable scenarios, and marks the applicable conditions and priority of each rule. After identifying multiple candidate interactive events with conflict relationships, the server matches and selects the appropriate target conflict arbitration rule from the set of conflict arbitration rules based on the current live streaming scenario, the type characteristics of the conflict events, their source, and resource usage status.

[0087] The server calls the judgment logic of the target conflict arbitration rule to compare, verify and select the best candidate interaction event from multiple candidate interaction events with conflict relationships. According to the rule constraints, the server selects the unique event as the linkage interaction event and does not select the other conflict candidate events, so as to ensure that only one valid linkage interaction event is output under the same conflict combination.

[0088] As another example, the server pre-classifies and configures each rule in the conflict arbitration rule set, distinguishing different rule categories by live room identity, event type, time sequence freshness, resource status, and intention deduplication.

[0089] After forming a group of candidate interactive events with conflict relationships, the server first identifies the cause type of the conflict and determines whether it is an identity conflict, type priority conflict, time sequence conflict, resource contention conflict, or duplicate intent conflict; based on the cause type of the conflict, it determines the matching target conflict arbitration rule from the rule set.

[0090] The server executes the target conflict arbitration rules, which organizes, discards, or merges candidate conflict events to determine the final linkage interaction event. This resolves the conflict between candidate events and ensures that the linkage interaction event output is unique, the decision logic is standardized, and it is configurable.

[0091] In this implementation, multiple types of conflict arbitration rules are pre-set to enable selection as needed. This standardizes the resolution of conflicts between candidate events, rationally selects the best interactive events, avoids the chaos of multiple concurrent events, and ensures the stability and controllability of cross-live room linkage logic.

[0092] In some optional implementations of this embodiment, the first step described above is performed in the following manner: based on the predefined type to which the interactive message belongs, candidate interactive events representing interactive messages within a time window are generated: for interactive messages of the count accumulation type within a time window, interactive messages within the same live broadcast room are aggregated to generate candidate interactive events.

[0093] The cumulative count type is a predefined type of interactive message that allows for the accumulation and counting of frequencies and quantities within the same live stream. It eliminates the need for individual event triggers for each message and is suitable for aggregation and processing based on quantity. For example, live stream users' check-in, support, and assist-type bullet comments, as well as similar interactive behavior messages such as likes and small assists / gifts that can be accumulated and counted, all belong to the cumulative count type.

[0094] As an example, within a single time window that dynamically progresses with the live stream, the server first filters out all interactive messages belonging to the cumulative count type and categorizes them by their respective live stream rooms. For each linked live stream room, all interactive messages of the cumulative count type within the same live stream room in that window are aggregated, counted, and integrated into a single event data point representing the overall count status of that live stream room. Based on the aggregated statistical results, corresponding candidate interactive events are generated, instead of generating separate candidate events for individual interactive messages.

[0095] In this implementation, similar counting interaction messages in the same live broadcast room are aggregated and merged to reduce the number of scattered candidate events generated, reduce the system event processing pressure, and at the same time fit the business logic that counting interactions need to be presented in a holistic statistical manner.

[0096] In some optional implementations of this embodiment, the first step described above is performed in the following manner: based on the predefined type to which the interactive message belongs, candidate interactive events for the interactive message within the time window are generated: for interactive messages under other predefined types besides the count accumulation type within the time window, candidate interactive events representing the interactive message are generated.

[0097] As an example, within the current time window that dynamically progresses with the live stream, the server first distinguishes and filters out other types of interactive messages that do not belong to the count accumulation type from the predefined types, such as interactive messages with specified keywords, specified instruction formats, and specified task advancements. For each of these types of interactive messages that has a complete business intent and does not require count accumulation, no aggregation processing of messages from the same room is performed. Instead, each interactive message is used as the smallest unit, and corresponding candidate interactive events are generated independently for each message. Each candidate interactive event separately carries the content attributes, source live stream room, and event characteristic information of the interactive message, fully preserving the independent linkage requirements of a single interactive message.

[0098] In this implementation, candidate events are generated one by one for interactive messages that are not countable and have independent business meaning. This can fully preserve the independent linkage intent of each message and avoid the loss of personalized triggering requirements due to aggregation and merging.

[0099] Step 103: Display the interactive effects corresponding to the linked interactive events through the respective clients of multiple linked live streaming rooms.

[0100] Interactive effects refer to the visual, auditory, or interactive feedback presented to livestream users on multiple linked livestream client applications after a linked interactive event is determined. Interactive effects are a direct representation of the linked results, enabling users to perceive the occurrence, progress, or outcome of cross-room interactions. Interactive effects can be instantaneous (such as playing animations) or continuous (such as updating status bar values).

[0101] As an example, after the server generates a linked interactive event, it broadcasts the event to all clients corresponding to the linked live stream rooms. Upon receiving the linked interactive event, the client immediately renders the corresponding interactive effect on its local live stream interface based on the event type and parameters (such as effect identifiers, numerical increments, target rooms, etc.). The display logic of all clients remains consistent, ensuring that users in different rooms see the same effect simultaneously (or a variation of the effect for the same event). The server does not wait for client confirmation and sends the event directly; each client completes its display independently.

[0102] As another example, the interactive event is first uniformly encapsulated, carrying standard display specifications, hierarchical priority, and adaptation rules, and then pushed in batches to the clients corresponding to all linked live stream rooms. After receiving the interactive event, each client does not render it immediately, but first performs compliance adaptation and hierarchical avoidance based on its own client version, screen resolution, and existing control layout of the live stream interface to avoid obscuring the core live stream content; after completing localization adaptation verification, it renders and displays the interactive graphics, pop-ups, or animation effects corresponding to the interactive event in the compliant position of its respective live stream interface according to a unified time sequence node.

[0103] In this embodiment, the client pre-configures corresponding interface mounting points for different interactive effects. (Continue to refer to...) Figure 2A This diagram illustrates the mounting points in the live stream interactive effect rendering interface. Full-screen effects are mounted on the video overlay (mounting point 201), the counting accumulation effect is mounted on the live stream user information bar (mounting point 202), and the task progress bar is mounted on the bottom activity panel (mounting point 203). When the client receives a linked interactive event, it renders the corresponding effect to the designated mounting point based on the event type, thus achieving a decoupled and flexibly controllable interactive effect display from the live stream interface layout.

[0104] Continue to refer to Figure 2B In a specific scenario example 200, three live streaming users (A, B, and C) start a joint live streaming event with the theme of "Three-location Relay Challenge". Viewers send "Go for it!" messages in their respective live streaming rooms to cheer on their favorite live streaming users.

[0105] The server sets up a 10-second sliding time window that dynamically advances with the live stream time to continuously collect interactive messages from the three live stream rooms.

[0106] Within the current time window, the three live stream rooms received the following bullet comments: Live stream room A received 4200 "Go for it!" comments; Live stream room B received 3800 "Go for it!" comments; and Live stream room C received 4500 "Go for it!" comments.

[0107] These "cheer up" comments belong to a predefined type of interactive message with an accumulated count, and their timestamps all fall within the current 10-second window, so they were selected.

[0108] The event rules stipulate that when the total number of "cheering" comments in all three live streams is ≥3000 within the same time window, a "successful support in three locations" linkage event will be triggered.

[0109] Server-side statistics show that the number of "cheering" messages in the three live stream rooms within the current window has reached the target. These messages are deemed to meet the linkage conditions, generating a unified linkage interactive event: triggering a synchronized "three-location support" effect across the live stream rooms.

[0110] The server sends the linkage event to the clients in the three live streaming rooms, and all clients trigger the display simultaneously: the text effect and ribbon animation of "Support Successful in Three Locations" appear on the live streaming screen at the same time; the background elements of the three live streaming rooms switch to exciting support music at the same time; all three live streaming users and viewers can see the same interactive effect at the same time, completing a cross-room linkage interaction.

[0111] In some optional implementations of this embodiment, step 103 is performed as follows: First, an incremental state fragment is generated based on the linkage interaction event, wherein the incremental state fragment represents the amount of change in the global interaction state of the linkage interaction event relative to the corresponding preceding dependent version; then, multiple clients update the state based on the incremental state fragment and display the interactive effect corresponding to the updated global interaction state.

[0112] Incremental state fragments are global interaction states relative to their predecessor versions. They record only data segments that cause state differences due to the current interactive event, carrying state changes in a differential form rather than the complete full state data. For example, an incremental state fragment includes a predecessor version identifier, a new version identifier, a state change field, the change value, corresponding interaction effect configuration information, and state activation constraints.

[0113] As an example, after the server determines the final interactive event, it retrieves the previous dependency version corresponding to the current global interaction state, compares the previous version with the target global interaction state after the interactive event is triggered, calculates the change in state between the two, and generates an incremental state fragment accordingly.

[0114] The server sends the incremental state fragment to the clients in each linked live stream room. The clients do not need to load the complete global state data; they only need to locally update their cached global interaction state based on the changes in the incremental state fragment. After completing the local state update, the clients match and render the corresponding linked interactive effects based on the updated global interaction state.

[0115] In this implementation, only incremental data showing state changes is transmitted instead of the full data, which reduces data transmission overhead and client computation, while ensuring that the global state of each client is synchronized and consistent, resulting in a more real-time and smoother display of the linkage effect.

[0116] In some optional implementations of this embodiment, the server may also perform the following operations: First step, in response to not receiving a confirmation receipt from the client for the incremental state fragment, determine the client's exception type; Second step, according to the interaction state synchronization method corresponding to the exception type, synchronize the global interaction state of the client's linked live broadcast room.

[0117] The confirmation receipt is a response data sent by the live streaming client to the server after successfully receiving and parsing the incremental state fragment and completing the local global interactive state update. It is used to inform the server that the "state update is complete" and is the core basis for the server to determine the client's state synchronization status.

[0118] The exception type is the specific category of client state synchronization exception determined by the server based on characteristics such as client communication status and historical synchronization records when the server does not receive a confirmation reply from the client within a preset time limit. This is used to accurately locate the cause of synchronization failure.

[0119] The interaction state synchronization method is a specific processing method pre-defined by the server for different client exception types, used to synchronize the global interaction state of the client to the latest valid state, adapting to the synchronization needs of different exception scenarios.

[0120] For example, for the exception type of incremental state fragment reception failure (no fragment data received), the interaction state synchronization method is that the server resends the corresponding incremental state fragment to the client, and the client completes the state update after receiving it.

[0121] For the exception type of incremental state fragment parsing failure (data corruption / format error), the interaction state synchronization method is that the server re-encapsulates the incremental state fragment and sends it down, and the client re-parses and completes the state update.

[0122] For the exception type of "state update failure" (fragment reception and parsing are normal, but local update is not complete), the interaction state synchronization method is for the server to issue a state update command to guide the client to re-execute the update operation until synchronization is complete.

[0123] As an example, after the server sends incremental status fragments to each linked live streaming client, it starts a timing mechanism and sets a fixed receipt waiting time limit (such as 3 seconds) to wait for the client to provide a confirmation receipt.

[0124] During the waiting period, the server monitors the feedback status of each client in real time. If a client fails to provide a confirmation receipt on time, the exception judgment process is immediately triggered: the historical communication records and fragment reception logs of the client are retrieved, and the specific exception type of the client is determined by combining the current network connection status (such as incremental fragment reception failure, parsing failure, or update failure).

[0125] Based on the identified exception type, the server matches the pre-defined corresponding interaction state synchronization method and performs differentiated synchronization operations for different exception types: if the reception fails, the incremental state fragment is resent; if the parsing fails, the fragment is repackaged and sent; if the update fails, an update command is sent to guide the client to update again.

[0126] The client completes the synchronization update of its local global interaction state according to the synchronization method specified by the server. After the update is completed, it sends a confirmation receipt to the server again. After receiving the receipt, the server terminates the client's exception handling process to ensure that the client's global interaction state is consistent with the server's.

[0127] In this implementation, for abnormal scenarios where the client does not provide feedback, the state synchronization deviation can be quickly repaired by accurately determining the exception type and matching the corresponding synchronization method, avoiding the disconnection of the state of a single client and ensuring the consistency of the global interactive state of all linked live broadcast rooms.

[0128] In some optional implementations of this embodiment, the second step described above is performed in the following manner to synchronize the global interactive state of the linked live room on the client: in response to the exception type being missing incremental state fragment, the missing incremental state fragment of the linked live room is determined, and the client updates the state based on the missing incremental state fragment.

[0129] As an example, after determining that the client's anomaly is a missing incremental state fragment, the server immediately initiates a missing fragment investigation process. It retrieves the client's currently cached global interaction state version identifier and compares it with the latest global interaction state version identifier recorded by the server to accurately determine the client's missing incremental state fragment. If the comparison reveals that the client is missing only a single version of the incremental state fragment, the server directly locates the incremental state fragment corresponding to that missing version, repackages the fragment data, and resends the corresponding incremental state fragment to the client via a real-time communication link, along with the version identifier, ensuring that the client can accurately identify the corresponding missing fragment.

[0130] If the comparison determines that the client is missing multiple consecutive version incremental state fragments, the server organizes and integrates all the missing consecutive version incremental state fragments in chronological order to generate a version patch set. The version order and prerequisite dependencies of each fragment are clearly marked in the set to avoid version confusion during client updates. The server sends the version patch set to the client all at once. After receiving it, the client parses each missing incremental state fragment sequentially according to the version order in the patch set, gradually completing the update of the local global interactive state. After the update is complete, a confirmation receipt is sent to the server. Upon receiving the receipt, the server confirms that the client's state synchronization is complete and terminates the exception handling process.

[0131] In this implementation, for anomalies involving missing incremental state fragments, the corresponding fragment or patch set is accurately distributed to ensure that the client efficiently completes the state, avoids state disconnection, and guarantees the accuracy and integrity of global interactive state synchronization.

[0132] In some optional implementations of this embodiment, the second step described above is performed in the following manner to synchronize the global interaction state of the linked live room on the client: in response to an exception type of global interaction state failure, the latest global interaction state snapshot is determined, and the client updates the state based on the global interaction state snapshot and subsequent incremental segments of the global interaction state snapshot.

[0133] Global interaction state failure refers to an abnormal state in which the global interaction state currently stored on the client is inconsistent with the latest state on the server due to reasons such as client caching errors, data transmission interruptions, and state synchronization errors, thus failing to respond normally to linkage requirements.

[0134] After the server determines that the client's anomaly is a global interactive state failure, it identifies that the local state of the linked live stream room is corrupted and cannot be recovered by resending incremental fragments. The server retrieves and selects the most recent stable global interactive state snapshot from historical versions and sends it to the corresponding client; at the same time, it compiles all incremental state fragments generated sequentially after the generation of this stable snapshot version and before the current latest version, and sends them along with the snapshot.

[0135] After receiving instructions and data, the client abandons the current invalid local state, actively rolls back and resets to the most recent stable snapshot version as the new state baseline; then, in version chronological order, it applies all incremental state fragments following the snapshot one by one, gradually completing the complete repair and synchronization of the local global interactive state, and finally aligning with the latest global interactive state on the server, and rendering the corresponding interactive effects normally.

[0136] In this implementation, when the local state on the client is completely unrecoverable, the state baseline is rebuilt based on a stable snapshot, and then incremental fragments are added to complete the version. There is no need to retransmit the entire data, which efficiently repairs the state disorder and maintains the consistency of the interactive state of multiple live broadcast rooms.

[0137] In some optional implementations of this embodiment, the server may also perform the following operations: in response to the invalidation of the target linkage event, generate a reversal-type state fragment, wherein the reversal-type state fragment is used to offset the state increment caused by the target linkage event, and the target linkage event represents a linkage interaction event that has been synchronized to the client through the incremental state fragment but has not yet triggered the interaction effect; and update the state through the respective clients of multiple linkage live broadcast rooms according to the reversal-type state fragment.

[0138] The undo state fragment is a special incremental data fragment specifically used to reverse the state increment generated by a target linkage event that has been synchronized and taken effect but was subsequently determined to be invalid. It can roll back the global interaction state to the baseline before the target linkage event took effect, ensuring that the states of multiple clients converge and remain consistent.

[0139] The server marks incremental status fragments that have been distributed and synchronized to each client, but which have not yet triggered interactive effects due to timeout, business judgment failure, or being overwritten by new events, as target linkage events and determines them to be invalid.

[0140] As an example, the server reverse-calculates the incremental change in the global interaction state caused by the invalid target linkage event, and generates a corresponding undo state fragment to accurately offset the state change brought about by the event.

[0141] The server broadcasts the undo state fragment to all linked live streaming clients. After receiving it, each client rolls back its local global interaction state based on the undo state fragment, cancels the state increment of the corresponding event, and abandons the rendering of the interactive effect corresponding to the invalid event, so that the interaction state of all rooms converges back to a unified benchmark.

[0142] In this implementation, undo fragments are generated for timeout, invalid, or overwritten non-triggered events to accurately roll back invalid state changes, avoid state bifurcation caused by residual dirty data, and ensure that the interactive states of multi-linked rooms always converge and become unified.

[0143] Figure 3 This paper illustrates another processing flow 300 of an interactive method for linking live streaming rooms provided in an embodiment of this application. The processing flow 300 includes the following steps:

[0144] Step 301: For interactive messages of predefined types in multiple linked live streaming rooms, adjust the timestamp of the interactive message according to the time offset correction parameter of the live streaming room to which the interactive message belongs and the network compensation parameter corresponding to the network quality of the live streaming room, to obtain the adjusted timestamp.

[0145] Step 302: Identify interactive messages of a predefined type whose adjusted timestamps are within the time window across multiple linked live streaming rooms.

[0146] Step 303: Generate candidate interactive events representing interactive messages within a time window based on the predefined type to which the interactive message belongs.

[0147] Step 304: Determine the target conflict arbitration rule from the set of conflict arbitration rules.

[0148] Step 305: Using the target conflict arbitration rule, identify the linked interaction events from multiple candidate interaction events that have conflict relationships.

[0149] Step 306: Generate incremental state fragments based on the linked interaction events, wherein the incremental state fragments represent the amount of change in the global interaction state of the linked interaction events relative to the corresponding predecessor dependent versions.

[0150] Step 307: Update the state through multiple clients based on incremental state fragments, and display the interactive effects corresponding to the updated global interactive state.

[0151] As can be seen from this embodiment, with Figure 1Compared with the corresponding embodiments, the process 300 of the interactive method for linking live streaming rooms in this embodiment specifically describes the process of determining interactive messages within the time window, the process of generating linked interactive events based on conflict arbitration rules, and the process of linked interactive events based on incremental state fragments. While ensuring the consistency of interactive results across live streaming rooms, it reduces the transmission overhead and client processing pressure in the process of linking live streaming rooms.

[0152] Furthermore, this application also provides an interactive device for linking a live streaming room, the structure of which is as follows: Figure 4 As shown.

[0153] An interactive device 400 for linked live streaming rooms includes: a message determination unit 401, configured to determine predefined types of interactive messages within a time window in multiple linked live streaming rooms, wherein the time window dynamically advances with the live streaming time; an event generation unit 402, configured to generate linked interactive events for multiple linked live streaming rooms based on interactive messages with conflicting relationships within the time window; and a linked interactive unit 403, configured to display the interactive effects corresponding to the linked interactive events through the respective clients of the multiple linked live streaming rooms.

[0154] In some optional implementations of this embodiment, the event generation unit 402 is further configured to: generate candidate interactive events representing interactive messages within a time window according to the predefined type to which the interactive message belongs; and determine the linked interactive events from multiple candidate interactive events that have conflicting relationships.

[0155] In some optional implementations of this embodiment, the event generation unit 402 is further configured to: determine a target conflict arbitration rule from the set of conflict arbitration rules; and use the target conflict arbitration rule to determine a linked interactive event from multiple candidate interactive events that have conflict relationships.

[0156] In some optional implementations of this embodiment, the event generation unit 402 is further configured to: aggregate interactive messages in the same live broadcast room and generate candidate interactive events for interactive messages of the count accumulation type within the time window.

[0157] In some optional implementations of this embodiment, the event generation unit 402 is further configured to generate candidate interactive events representing interactive messages of other predefined types besides the count accumulation type within the time window.

[0158] In some optional implementations of this embodiment, the message determination unit 401 is further configured to: for interactive messages of a predefined type in multiple linked live streaming rooms, adjust the timestamp of the interactive message according to the time offset correction parameter of the live streaming room to which the interactive message belongs and the network compensation parameter corresponding to the network quality of the live streaming room, and obtain the adjusted timestamp; determine the interactive messages in multiple linked live streaming rooms whose adjusted timestamps are within the time window.

[0159] In some optional implementations of this embodiment, the linkage interaction unit 403 is further configured to: generate incremental state fragments based on linkage interaction events, wherein the incremental state fragments represent the amount of change in the global interaction state of the linkage interaction event relative to the corresponding preceding dependent version; update the state through multiple clients based on the incremental state fragments, and display the interactive effect corresponding to the updated global interaction state.

[0160] In some optional implementations of this embodiment, the above-mentioned device further includes: an exception handling unit, configured to: determine the exception type of the client in response to not receiving an acknowledgment from the client for the incremental state segment; and synchronize the global interactive state of the client's linked live broadcast room according to the interaction state synchronization method corresponding to the exception type.

[0161] In some optional implementations of this embodiment, the exception handling unit is further configured to: in response to an exception type of missing incremental state fragment, determine the missing incremental state fragment in the linked live broadcast room, and update the state through the client based on the missing incremental state fragment.

[0162] In some optional implementations of this embodiment, the exception handling unit is further configured to: in response to an exception type of global interaction state failure, determine the latest global interaction state snapshot, and update the state through the client based on the global interaction state snapshot and subsequent incremental fragments of the global interaction state snapshot.

[0163] In some optional implementations of this embodiment, the above-mentioned device further includes: a state cancellation unit, configured to: generate a cancellation-type state fragment in response to the invalidation of the target linkage event, wherein the cancellation-type state fragment is used to offset the state increment caused by the target linkage event, the target linkage event representing a linkage interaction event that has been synchronized to the client through the incremental state fragment but has not yet triggered the interaction effect; and update the state through the respective clients of multiple linkage live broadcast rooms according to the cancellation-type state fragment.

[0164] In the interactive device for linked live streaming rooms provided in this application embodiment, the message determination unit determines predefined types of interactive messages within a time window in multiple linked live streaming rooms, wherein the time window dynamically advances with the live streaming time; the event generation unit generates linked interactive events for multiple linked live streaming rooms based on interactive messages with conflicting relationships within the time window; the linked interactive unit displays the interactive effects corresponding to the linked interactive events through the respective clients of multiple linked live streaming rooms, thereby aligning the interactive messages of multiple linked live streaming rooms in a unified time window, and performing cross-live streaming room interaction through the unified linked interactive events corresponding to the time window, reducing the out-of-order rate, missed trigger rate, and duplicate judgment probability of cross-live streaming room interactive events, and improving the consistency of cross-live streaming room interaction results.

[0165] Furthermore, this application also provides a live streaming linkage system, the structure of which is as follows: Figure 5 As shown.

[0166] A collaborative live streaming system 500 includes a client 501 and a server 502. The server 502 is used to: determine interactive messages of a predefined type that are within a time window in multiple collaborative live streaming rooms, wherein the time window dynamically advances with the live streaming time; and generate collaborative interactive events for multiple collaborative live streaming rooms based on interactive messages with conflicting relationships within the time window. The client 501 is used to: display the interactive effects corresponding to the collaborative interactive events on the live streaming interface of the collaborative live streaming rooms.

[0167] In some optional implementations of this embodiment, the server 502 is further configured to: generate candidate interactive events representing interactive messages within a time window based on the predefined type to which the interactive message belongs; and determine linked interactive events from multiple candidate interactive events that have conflicting relationships.

[0168] In some optional implementations of this embodiment, the server 502 is further configured to: determine a target conflict arbitration rule from the set of conflict arbitration rules; and use the target conflict arbitration rule to determine a linked interaction event from multiple candidate interaction events that have conflict relationships.

[0169] In some optional implementations of this embodiment, the server 502 is further configured to: aggregate interactive messages in the same live broadcast room and generate candidate interactive events for interactive messages of the count accumulation type within the time window.

[0170] In some optional implementations of this embodiment, the server 502 is further configured to: generate candidate interactive events representing interactive messages for interactive messages of other predefined types besides the count accumulation type within the time window.

[0171] In some optional implementations of this embodiment, the server 502 is further configured to: for interactive messages of a predefined type in multiple linked live streaming rooms, adjust the timestamp of the interactive message according to the time offset correction parameter of the live streaming room to which the interactive message belongs and the network compensation parameter corresponding to the network quality of the live streaming room, to obtain the adjusted timestamp; and determine the interactive messages in multiple linked live streaming rooms whose adjusted timestamps are within the time window.

[0172] In some optional implementations of this embodiment, the server 502 is further configured to: generate incremental state fragments based on the linkage interaction event, wherein the incremental state fragment represents the amount of change in the global interaction state of the linkage interaction event relative to the corresponding preceding dependent version; the client 501 is further configured to: update the state based on the incremental state fragment, display the interactive effect corresponding to the updated global interaction state on the live broadcast interface, and send a confirmation receipt of the incremental state fragment to the server 502.

[0173] In some optional implementations of this embodiment, the server 502 is further configured to: determine the exception type of the client 501 in response to not receiving an acknowledgment from the client 501 for the incremental state fragment; and synchronize the global interaction state of the client 501's linked live broadcast room according to the interaction state synchronization method corresponding to the exception type.

[0174] In some optional implementations of this embodiment, the server 502 is further configured to: determine the missing incremental state fragment in response to an exception type of missing incremental state fragment; the client 501 is further configured to: update the state based on the missing incremental state fragment.

[0175] In some optional implementations of this embodiment, the server 502 is further configured to: determine the latest global interaction state snapshot in response to an exception type of global interaction state failure; the client 501 is further configured to: update the state based on the global interaction state snapshot and subsequent incremental fragments of the global interaction state snapshot.

[0176] In some optional implementations of this embodiment, the incremental state fragment includes the version number of the previous dependent version and the latest version number of the current global interaction state including the incremental state fragment, and the client 501 is further used to: update the state according to the incremental state fragment in response to the local version number and the previous dependent version number being consistent, and update the local version number according to the latest version number.

[0177] As an example, when the server generates an incremental state fragment, it embeds two version identifiers within the fragment: one is the version number of the predecessor dependency on which the increment depends, i.e., the base version number before this state change; the other is the latest version number of the global interactive state after applying this increment.

[0178] After the incremental status fragment is sent to each linked live streaming client, the client reads the current local version number recorded in its own local cache and compares and verifies it with the version number of the predecessor dependency in the incremental fragment.

[0179] If the comparison result shows that the local version number is completely consistent with the version number of the predecessor dependency, it means that the current local state of the client is exactly the legal baseline for this incremental update, and there is no version jump or gap. The client then performs a partial update of the local global interaction state based on the state change data in the incremental state fragment. After the update is completed, the client replaces its own stored local version number with the latest version number in the incremental fragment, completes the version iteration retention, and uses it as the baseline version for the next incremental update.

[0180] In this implementation, a baseline verification is performed using both version numbers. Incremental updates are only allowed when the local version matches the dependent version, effectively preventing version mismatches and ensuring orderly and reliable client state iteration.

[0181] In some optional implementations of this embodiment, the client 501 is further configured to: send the local version number to the server 502 in response to the inconsistency between the local version number and the version number of the preceding dependency; the server 502 is further configured to: determine the incremental state fragments missing from the global interaction state corresponding to the local version number relative to the current global interaction state; the client 501 is further configured to: update the state based on the missing incremental state fragments.

[0182] As an example, when the version numbers of the two are determined to be inconsistent, the client does not perform the incremental update and proactively reports its current local version number to the server. After receiving the local version number reported by the client, the server uses that version as a benchmark to compare with the latest global interactive state version on the server, accurately calculating all missing incremental state fragments between the client's local version and the latest version.

[0183] The server sends the identified missing incremental state fragments to the client in version order. The client receives and parses the missing application fragments one by one, completing the local global interactive state update step by step. After the update is completed, the local version number is refreshed to keep it aligned with the server version.

[0184] In this implementation, when the local version does not match, the version information is actively reported, and the server accurately locates the missing incremental segment and fills in the update, avoiding cross-version update errors and ensuring smooth alignment of multiple client states without gaps.

[0185] In some optional implementations of this embodiment, the server 502 is further configured to: generate a reversal-type state fragment in response to the invalidity of the target linkage event, wherein the reversal-type state fragment is used to offset the state increment caused by the target linkage event, and the target linkage event represents a linkage interaction event that has been synchronized to the client 501 through the incremental state fragment but has not yet triggered the interaction effect; the client 501 is further configured to: update the state according to the reversal-type state fragment.

[0186] In the collaborative live streaming system provided in this application embodiment, the server is used to determine predefined types of interactive messages within a time window in multiple collaborative live streaming rooms, wherein the time window dynamically advances with the live streaming time; based on interactive messages with conflicting relationships within the time window, collaborative interactive events for multiple collaborative live streaming rooms are generated; the client is used to display the interactive effects corresponding to the collaborative interactive events on the live streaming interface of the collaborative live streaming rooms, thereby aligning the interactive messages of multiple collaborative live streaming rooms in a unified time window, and performing cross-live streaming room interactions through unified collaborative interactive events corresponding to the time window, reducing the out-of-order rate, missed trigger rate, and duplicate judgment probability of cross-live streaming room interactive events, and improving the consistency of cross-live streaming room interaction results.

[0187] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the interactive method of the linked live broadcast room 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 various embodiments of this application.

[0188] The aforementioned electronic devices can be user devices, or devices composed of user devices and network devices integrated through a network, or applications running on such devices. The user devices include, but are not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network devices include, but are 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.

[0189] 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 600 includes a Central Processing Unit (CPU) 601, which can perform various appropriate actions and processes based on a program stored in a Read Only Memory (ROM) 602 or a program loaded from a storage portion 608 into a Random Access Memory (RAM) 603. The RAM 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An Input / Output (I / O) interface 605 is also connected to the bus 604.

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

[0191] 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 a central processing unit (CPU) 601, it performs the functions defined in the methods of this application.

[0192] 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.

[0193] 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 connection with an instruction execution system, apparatus, or device.

[0194] 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.

[0195] The 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.

[0196] 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++, as well as 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 can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0197] 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.

[0198] 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.

[0199] 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.

[0200] 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.

[0201] 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.

[0202] 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.

[0203] 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.

[0204] 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 recited in a device claim may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. An interactive method for linking live streaming rooms, wherein, The method includes: Identify predefined types of interactive messages within a time window in multiple interconnected live streaming rooms, wherein the time window dynamically advances with the live streaming time; Based on the interactive messages with conflicting relationships within the time window, generate multiple collaborative interactive events for the collaborative live streaming rooms; The interactive effects corresponding to the linked interactive events are displayed through the respective clients of multiple linked live streaming rooms.

2. The method according to claim 1, wherein, The step of generating multiple collaborative interactive events for the linked live streaming rooms based on interactive messages with conflicting relationships within the time window includes: Based on the predefined type to which the interactive message belongs, generate candidate interactive events that represent the interactive messages within the time window; The linked interaction event is determined from a plurality of candidate interaction events that have the aforementioned conflict relationship.

3. The method according to claim 2, wherein, The step of determining the linked interaction event from multiple candidate interaction events that have the aforementioned conflict relationship includes: Identify the target conflict arbitration rule from the set of conflict arbitration rules; Using the target conflict arbitration rule, the linked interaction event is determined from multiple candidate interaction events that have the conflict relationship.

4. The method according to claim 2, wherein, The step of generating candidate interactive events representing interactive messages within the time window based on the predefined type to which the interactive message belongs includes: For interactive messages of the count accumulation type within the time window, aggregate interactive messages within the same live broadcast room to generate the candidate interactive events.

5. The method according to claim 2, wherein, The step of generating candidate interactive events for interactive messages within the time window based on the predefined type to which the interactive message belongs includes: For interactive messages of other predefined types besides the count accumulation type within the time window, generate candidate interactive events that represent the interactive messages.

6. The method according to claim 1, wherein, The determination of predefined types of interactive messages within a time window in multiple linked live streaming rooms includes: For interactive messages of predefined types in multiple linked live streaming rooms, the timestamp of the interactive message is adjusted according to the time offset correction parameter of the live streaming room to which the interactive message belongs and the network compensation parameter corresponding to the network quality of the live streaming room, so as to obtain the adjusted timestamp. Identify interactive messages in multiple linked live streaming rooms whose adjusted timestamps fall within the time window.

7. The method according to any one of claims 1-6, wherein, The step of displaying the interactive effects corresponding to the linked interactive events through the respective clients of multiple linked live streaming rooms includes: An incremental state fragment is generated based on the linked interactive event, wherein the incremental state fragment represents the amount of change in the global interactive state of the linked interactive event relative to the corresponding preceding dependent version. Multiple clients update the state based on the incremental state fragments and display the interactive effects corresponding to the updated global interactive state.

8. The method according to claim 7, wherein, Also includes: In response to not receiving an acknowledgment from the client regarding the incremental state segment, the client's exception type is determined; The global interaction state of the linked live broadcast room on the client is synchronized according to the interaction state synchronization method corresponding to the anomaly type.

9. The method according to claim 8, wherein, The step of synchronizing the global interaction state of the client's linked live broadcast room according to the interaction state synchronization method corresponding to the exception type includes: In response to the exception type being missing incremental state fragment, the missing incremental state fragment in the linked live broadcast room is determined, and the client updates the state based on the missing incremental state fragment.

10. The method according to claim 8, wherein, The step of synchronizing the global interaction state of the client's linked live broadcast room according to the interaction state synchronization method corresponding to the exception type includes: In response to the exception type being global interaction state failure, a latest global interaction state snapshot is determined, and the client updates the state based on the global interaction state snapshot and subsequent incremental segments of the global interaction state snapshot.

11. The method according to claim 7, wherein, Also includes: In response to the invalidation of the target linkage event, a cancellation state fragment is generated, wherein the cancellation state fragment is used to cancel the state increment caused by the target linkage event, and the target linkage event represents a linkage interaction event that has been synchronized to the client through the incremental state fragment but has not yet triggered the interaction effect; The client of each of the multiple linked live streaming rooms updates its status based on the revocation-type status fragment.

12. An interactive device for linking a live streaming room, wherein, The device includes: The message determination unit is configured to determine interactive messages of a predefined type that are within a time window in multiple linked live streaming rooms, wherein the time window dynamically advances with the live streaming time; The event generation unit is configured to generate multiple interactive events for the linked live streaming rooms based on interactive messages with conflicting relationships within the time window. The interactive unit is configured to display the interactive effects corresponding to the interactive events through the respective clients of the multiple interactive live streaming rooms.

13. A live streaming system comprising a client and a server, wherein: The server is used to: determine predefined types of interactive messages within a time window in multiple linked live streaming rooms, wherein the time window dynamically advances with the live streaming time; and generate linked interactive events for multiple linked live streaming rooms based on interactive messages with conflicting relationships within the time window. The client is used to display the interactive effects corresponding to the collaborative interactive events on the live streaming interface of the collaborative live streaming room.

14. The system according to claim 13, wherein, The server is further used for: Based on the predefined type to which the interactive message belongs, candidate interactive events representing interactive messages within the time window are generated; the linked interactive event is determined from multiple candidate interactive events that have the conflict relationship.

15. The system according to claim 14, wherein, The server is further used for: A target conflict arbitration rule is determined from the set of conflict arbitration rules; using the target conflict arbitration rule, the linked interaction event is determined from multiple candidate interaction events that have the conflict relationship.

16. The system according to claim 14, wherein, The server is further used for: For interactive messages of the count accumulation type within the time window, aggregate interactive messages within the same live broadcast room to generate the candidate interactive events.

17. The system according to claim 14, wherein, The server is further used for: For interactive messages of other predefined types besides the count accumulation type within the time window, generate candidate interactive events that represent the interactive messages.

18. The system according to claim 13, wherein, The server is further used for: For interactive messages of predefined types in multiple linked live streaming rooms, the timestamp of the interactive message is adjusted according to the time offset correction parameter of the live streaming room to which the interactive message belongs and the network compensation parameter corresponding to the network quality of the live streaming room, so as to obtain the adjusted timestamp. Identify interactive messages in multiple linked live streaming rooms whose adjusted timestamps fall within the time window.

19. The system according to any one of claims 13-18, wherein, The server is further used for: An incremental state fragment is generated based on the linked interactive event, wherein the incremental state fragment represents the amount of change in the global interactive state of the linked interactive event relative to the corresponding preceding dependent version. The client is further used for: The status is updated based on the incremental status fragment, the interactive effect corresponding to the updated global interactive status is displayed on the live broadcast interface, and a confirmation receipt of the incremental status fragment is sent to the server.

20. The system according to claim 19, wherein, The server is also used for: In response to the lack of a confirmation receipt from the client for the incremental state segment, the client's exception type is determined; and the global interaction state of the client's linked live broadcast room is synchronized according to the interaction state synchronization method corresponding to the exception type.

21. The system according to claim 20, wherein, The server is further used for: In response to the exception type being a missing incremental state fragment, the missing incremental state fragment in the linked live broadcast room is determined. The client is further used for: Update the state based on the missing incremental state fragments.

22. The system according to claim 20, wherein, The server is further used for: In response to the exception type being global interaction state failure, determine the latest global interaction state snapshot; The client is further used for: The state is updated based on the global interaction state snapshot and subsequent incremental fragments of the global interaction state snapshot.

23. The system according to claim 19, wherein, The incremental state fragment includes the version number of the preceding dependent version and the latest version number of the current global interaction state, including the incremental state fragment. The client is further used for: In response to the local version number being consistent with the version number of the preceding dependencies, the state is updated according to the incremental state fragment, and the local version number is updated according to the latest version number.

24. The system according to claim 23, wherein, The client is further used for: In response to the inconsistency between the local version number and the version number of the preceding dependencies, the local version number is sent to the server. The server is also used for: Determine the missing incremental state fragments of the global interaction state corresponding to the local version number relative to the current global interaction state. The client is further used for: Update the state based on the missing incremental state fragments.

25. The system according to claim 19, wherein, The server is also used for: In response to the invalidation of the target linkage event, a cancellation state fragment is generated, wherein the cancellation state fragment is used to cancel the state increment caused by the target linkage event, and the target linkage event represents a linkage interaction event that has been synchronized to the client through the incremental state fragment but has not yet triggered the interaction effect; The client is also used for: The state is updated based on the revocation-type state fragment.

26. 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 that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 11.

27. 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 11.

28. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 11.

Images