Lens switching method and device, storage medium and program product

Abstract

The embodiment of the invention provides a lens switching method and device, a storage medium and a program product. In the method, a plurality of game events with attribute information, which are sequentially generated, can be obtained based on a game log generated in a live broadcast process of a target event; dividing the event into a plurality of event fragments according to a fixed time window and a timestamp; inputting the event fragments into an artificial intelligence event selection model, scoring the game events in each event fragment through the scoring dimension, and screening out target game events meeting a preset score condition; and generating a corresponding switching instruction according to a preset lens switching strategy, and controlling the playback OB equipment to complete lens switching. Through the mode, the wonderful lens can be accurately captured, and the switching of the visual angle of the playback OB lens can be efficiently carried out.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a lens switching method, device, storage medium, and program product. Background Technology

[0002] In live game tournament broadcasts, a replay OB (Observer) device is needed to play the matches, and during playback, camera shots or scenes need to be replayed. Current technology relies on manual switching of the replay OB camera perspective. The operator of the replay OB device must watch the live OB screen, determine the events appearing in the live OB screen, subjectively judge the priority of each game event, select the target event to be replayed based on the priority, and memorize the shortcut keys corresponding to each player's name in that target event. Then, based on the selected target event and the shortcut keys for each player's name, the operator switches the camera on the replay OB device to achieve the scene replay. Here, the live OB device refers to the computer host connected to the zero-latency spectating server, while the replay OB device refers to the computer host connected to the latency spectating server.

[0003] This manual method places a heavy burden on operators, hindering efficient switching of OB (Out-of-Box) camera viewpoints during playback. Furthermore, the subjective selection of shots for playback is highly susceptible to subjective factors, resulting in low accuracy and a subpar presentation of the highlights to the audience. Therefore, a solution is urgently needed to improve the efficiency and accuracy of OB camera viewpoint switching during playback. Summary of the Invention

[0004] This application provides a method, apparatus, storage medium, and program product for switching camera angles, which can capture exciting shots more accurately and switch playback OB camera angles more efficiently.

[0005] This application provides a camera switching method applicable to electronic devices. The electronic devices are communicatively connected to a replay OB device. The method includes: acquiring multiple game events sequentially generated during the live broadcast of a target event based on game logs generated during the live broadcast; different game events having different attribute information; dividing the multiple game events into multiple event segments according to a fixed time window based on the attribute information of the multiple game events, with each event segment including at least one game event; inputting the multiple event segments into an artificial intelligence-based event selection model, determining a scoring dimension based on the attribute information of the game events in each event segment, scoring the game events in each event segment based on the scoring dimension, and identifying target game events whose scores meet preset scoring conditions from the game events; generating a camera switching instruction corresponding to each target game event according to a preset camera switching strategy, and controlling the replay OB device to perform camera switching according to the camera switching instruction corresponding to each target game event.

[0006] Optionally, the electronic device is communicatively connected to a real-time observer (OB) device; based on game logs generated during the live broadcast of the target event, multiple game events generated sequentially during the live broadcast are obtained, including: obtaining game logs generated during the live broadcast of the target event and real-time status information of the target event from the real-time OB device and the replay OB device; parsing the game logs to obtain multiple game events; each game event has initial attribute information; for each game event, selecting a target information item corresponding to the event type of the game event from the real-time status information of the target event, and fusing the target information item with the initial attribute information of the game event to obtain the attribute information of the game event.

[0007] Optionally, the electronic device is configured with an event buffer and an event pre-blocker; based on the attribute information of the multiple game events, the multiple game events are divided into multiple event slices according to a fixed time window, including: inputting the multiple game events sequentially into the event buffer, the event buffer sending game events to the event pre-blocker according to the anti-shake buffer duration; whenever the anti-shake buffer duration ends, sending the game events buffered in the event buffer during the anti-shake buffer duration to the event pre-blocker; in the event pre-blocker, based on the attribute information of the multiple game events, determining multiple first game events that meet preset blocking rules from the multiple game events; and dividing the multiple first game events into multiple event slices according to a fixed time window.

[0008] Optionally, the attribute information includes at least one of the following sub-information: timestamp, type, identifier, and event status information; based on the attribute information of the multiple game events, determining multiple first game events that conform to a preset blocking rule from the multiple game events includes: for any game event, matching each sub-information of the game event with the blocking rule; if there is sub-information that does not conform to the blocking rule, then the game event does not conform to the blocking rule; and / or, based on the type of the game event, querying the first historical timestamp of the same type of event of the game event; if the difference between the first historical timestamp and the timestamp of the game event is less than a preset first cooldown time, then the game event does not conform to the blocking rule; and / or, based on the type of the game event, querying the second historical timestamp of the associated type of event of the game event; if the difference between the second historical timestamp and the timestamp of the game event is less than a preset second cooldown time, then the game event does not conform to the blocking rule.

[0009] Optionally, the plurality of first game events are divided into multiple event slices according to a fixed time window, including: sorting the plurality of first game events according to timestamp order and creating event slices multiple times; wherein, each time an event slice is created, the first game event at the top of the first game events that have not been sliced ​​is determined as the baseline event; if the timestamp difference between the other first game events and the baseline event is not greater than a preset anti-shake time window, then the baseline event and the other first game events are added to the event slice.

[0010] Optionally, the event status information includes: operation method information, player location information, and game resource utilization information; scoring the game events in each event segment from the scoring dimension includes: for any game event in each event segment, determining a base score matching the type of the game event; the game event is initiated by the target player; extracting a first feature corresponding to the type from the operation method information, and determining the operation difficulty value of the target player in the game event based on the first feature; determining a first corrected score for the game event from the operation method dimension based on the operation difficulty value; extracting the type from the player location information. The corresponding second feature is used to characterize the relative positional relationship between the target player and other related players in the game event; from the player position dimension, a second corrected score for the game event is determined based on the second feature; a third feature corresponding to the type is extracted from the game resource utilization information, the third feature being used to characterize the target player's item usage and / or weapon usage in the game event; from the resource utilization dimension, a third corrected score for the game event is determined based on the third feature; the base score is corrected using the first corrected score, the second corrected score, and / or the third corrected score to obtain the score for the game event.

[0011] Optionally, controlling the playback OB device to perform camera switching according to the camera switching instruction corresponding to each target game event includes: adding the camera switching instruction corresponding to each target game event to an instruction queue in sequence according to the timestamp of each target game event; for any camera switching instruction in the instruction queue, if the difference between the timestamp of the last camera switching and the timestamp of the target game event corresponding to the camera switching instruction is within a preset release range, then sending the camera switching instruction to the playback OB device to control the playback OB device to perform camera switching.

[0012] This application also provides an electronic device, including: a memory and a processor; wherein the memory is used to: store one or more computer instructions; and the processor is used to execute the one or more computer instructions to: perform the steps in the lens switching method.

[0013] This application also provides a computer-readable storage medium that, when executed by a processor, enables the processor to implement the steps in the lens switching method.

[0014] This application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, enable the processor to implement the steps in the lens switching method.

[0015] In this embodiment, multiple sequentially generated game events with attribute information can be obtained based on game logs generated during the live broadcast of the target event. These events are then divided into multiple event segments according to timestamps and fixed time windows. The event segments are input into an artificial intelligence event selection model, which scores the game events in each event segment using a scoring dimension, and filters out target game events that meet preset score conditions. A corresponding switching command is generated according to a preset camera switching strategy to control the replay OB device to complete the camera switching. In this way, exciting moments can be captured relatively accurately, and the switching of replay OB camera perspectives can be performed relatively efficiently. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 A schematic flowchart illustrating a lens switching method provided in an exemplary embodiment of this application;

[0018] Figure 2 A schematic diagram of the structure of a lens switching device provided in an exemplary embodiment of this application;

[0019] Figure 3 A schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding access points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0022] Existing technology relies on manual switching of OB (Out-of-Box) camera viewpoints during playback, which places a heavy burden on operators and makes it difficult to switch OB camera viewpoints efficiently. In addition, the manual selection of shots to be played back is greatly affected by subjective factors, resulting in low accuracy and a poor playback effect for the audience.

[0023] To address the aforementioned technical problems, this application provides a technical solution that can acquire multiple sequentially generated game events with attribute information based on game logs generated during a live broadcast of a target event; divide these events into multiple event segments according to timestamps and fixed time windows; input the event segments into an artificial intelligence event selection model, score the game events in each event segment using a scoring dimension, and filter out target game events that meet preset score conditions; generate corresponding switching instructions according to a preset camera switching strategy, and control the replay OB device to complete the camera switching. In this way, exciting moments can be captured more accurately, and the switching of replay OB camera perspectives can be performed more efficiently.

[0024] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings. Figure 1 The lens switching method provided in this exemplary embodiment is applicable to electronic devices that can communicate with playback OB devices. The electronic device can be any device such as a mobile phone, tablet computer, server, or computer; this embodiment does not impose any limitation on this.

[0025] like Figure 1 As shown, the method may include the following steps:

[0026] Step 11: Based on the game logs generated during the live broadcast of the target event, obtain multiple game events generated sequentially during the live broadcast; different game events have different attribute information.

[0027] Step 12: Based on the attribute information of multiple game events, divide the multiple game events into multiple event slices according to a fixed time window. Each event slice includes at least one game event.

[0028] Step 13: Input multiple event segments into the AI-based event selection model, determine the scoring dimensions based on the attribute information of the game events in each event segment, score the game events in each event segment based on the scoring dimensions, and identify the target game events whose scores meet the preset scoring conditions from the game events.

[0029] Step 14: Generate a camera switching instruction corresponding to each target game event according to the preset camera switching strategy, and control the playback OB device to switch cameras according to the camera switching instruction corresponding to each target game event.

[0030] In this embodiment, the target event can be any type of event, such as a sports event or an e-sports event, and this embodiment is not limited to any particular type. Game logs can be generated during the live broadcast of the target event, and these game logs can record various data related to the live broadcast process. Based on the game logs generated during the live broadcast of the target event, multiple game events generated sequentially during the live broadcast can be obtained. This embodiment does not limit the specific implementation of the game events; they can be set to any event according to actual design requirements, such as a kill event or an item throwing event. For example, the multiple game events generated sequentially could be a kill event, an item throwing event, and an entry into the endgame event, etc.

[0031] Different game events possess different attribute information. This attribute information describes the nature or characteristics of the game event and may include, but is not limited to, at least one of the following sub-information: timestamp, type, identifier, and event status information. Specifically, the timestamp represents the time when the game event occurred; the type describes the category to which the game event belongs, such as healing, kill, resource gathering, defense, and item throwing; the identifier is a specific symbol, code, name, or other form of marking information used to uniquely distinguish and identify each game event; and the event status information describes the player actions, player location, and resource usage involved in the game event. It should be noted that the timestamp of a game event can be represented by the frame number of the frame in which the game event occurs. In other words, the earlier the frame number of a game event is compared to the frame numbers of other game events, the earlier its timestamp appears, meaning the game event occurred earlier.

[0032] In this embodiment, multiple game events can be divided into multiple event slices according to a fixed time window based on their attribute information. Each event slice includes at least one game event. Event slices can also be understood as event groups or event sets. This embodiment does not limit the value of the time window; it can be freely set according to the actual event debouncing requirements, such as 3s, 4s, or 5s.

[0033] By generating event slices, debouncing can be applied to multiple game events. In subsequent steps, this helps the event selection model to select better game events more efficiently and accurately within the event slices at the granularity of the event slices.

[0034] In this embodiment, multiple event segments can be input into an AI-based event selection model. A scoring dimension is determined based on the attribute information of the game events in each event segment, and the game events in each event segment are scored according to this scoring dimension. Specifically, the attribute information of the game events in each event segment can be parsed to obtain the sub-information contained therein. The scoring dimension is determined based on a preset correspondence between the sub-information and the scoring dimension. This embodiment does not limit the number of scoring dimensions; there can be one or more. A scoring dimension can be determined when the attribute information includes multiple sub-information, and one scoring dimension can be determined when the attribute information includes only one sub-information. A scoring dimension refers to a specific evaluation angle used in the event selection model to measure the value, characteristics, or performance of a game event. This embodiment does not limit the specific implementation of the scoring dimension and can freely set it according to actual needs. Optionally, any scoring dimension can be an operation method dimension, a player position relationship dimension, or a resource utilization dimension. The operation method dimension refers to the dimension of the player's operation method involved in the game event; the player position relationship dimension refers to the dimension of the relative position between players involved in the game event; and the resource utilization dimension refers to the dimension of how players use in-game resources involved in the game event.

[0035] Subsequently, the event selection model can determine the target game event whose score meets the preset score condition from the game events. This embodiment does not limit the specific implementation of the preset score condition, and it can be to select the game event with the highest score, etc.

[0036] After obtaining the target game events for each of the multiple event segments based on the above steps, a camera switching command corresponding to each target game event can be generated according to a preset camera switching strategy. The playback OB device can then be controlled to switch cameras based on this camera switching command. The camera switching strategy presets the camera switching objects for different game events. For example, for a kill event, the camera switching objects can be the player who kills and the player who is killed. Therefore, the camera switching command generated based on the camera switching strategy can be used to switch to the first-person perspective of the player who kills. Of course, the above is only an illustrative example; this embodiment does not limit the implementation of the camera switching strategy and can be freely set to any strategy according to actual camera switching needs. Afterwards, the playback OB device can be controlled to switch cameras according to the camera switching command corresponding to each target game event.

[0037] In this embodiment, multiple sequentially generated game events with attribute information can be obtained based on game logs generated during the live broadcast of the target event. These events are then divided into multiple event segments according to timestamps and fixed time windows. The event segments are input into an artificial intelligence event selection model, which scores the game events in each event segment using a scoring dimension, and filters out target game events that meet preset score conditions. A corresponding switching command is generated according to a preset camera switching strategy to control the replay OB device to complete the camera switching. In this way, exciting moments can be captured relatively accurately, and the switching of replay OB camera perspectives can be performed relatively efficiently.

[0038] In some optional embodiments, the electronic device can also communicate with a real-time observer (OB) device; based on the game logs generated during the live broadcast of the target event, when obtaining multiple game events sequentially generated during the live broadcast, the game logs generated during the live broadcast of the target event and the real-time status information of the target event can be obtained from the real-time OB device and the replay OB device. The real-time status information may include detailed game status data such as player position, weapon status, and match round information.

[0039] Specifically, the electronic device can maintain a long-lived connection with the client consoles of the real-time observer (OB) device and the replay OB device to obtain game logs from both client consoles. The electronic device can also expose an HTTP interface to connect to the GSI (Game State Integration) interface of the real-time OB device and the replay OB device to obtain GSI data, which is the real-time status information of the target event.

[0040] After acquiring the above information, the game logs can be parsed to obtain multiple game events, each with initial attribute information. For any given game event, a target information item corresponding to the event type can be selected from the real-time status information of the target event. Different event types may correspond to different target information items. In other words, the information fusion requirements for game events of different event types differ; some game events require a specific information item from the real-time status information, while others do not. Then, the target information item can be fused with the initial attribute information of the game event to obtain the attribute information possessed by the game event.

[0041] For example, the initial attribute information of a game event includes data such as the player's ID (identification), assister ID, damage amount, and distance on the server. After mixing in GSI data (real-time status information), data such as the location data of the attacker and victim, and whether the real-time observer has switched to that perspective are added.

[0042] In this way, multiple game events generated sequentially during a live stream can be obtained relatively accurately based on information fusion.

[0043] In some optional embodiments, the electronic device may be configured with an event buffer and an event pre-blocker. Based on this, step 12 in the aforementioned embodiments, "dividing multiple game events into multiple event slices according to the attribute information of multiple game events and a fixed time window," can be implemented based on the following steps:

[0044] Step S1: Input multiple game events sequentially into the event buffer. The event buffer can send game events to the event pre-blocker according to the anti-shake buffer duration. The anti-shake buffer duration is the event anti-shake window, which can perform anti-shake processing on multiple game events to prevent a large number of game events from arriving at short intervals, thus avoiding frequent camera switching for the audience and reducing the quality of camera replays. The anti-shake buffer duration can be preset to any value according to actual needs; this embodiment does not impose any restrictions. Optionally, considering that sometimes during live streaming, it may be undesirable to switch to the perspective of a certain type of event (such as throwing props), when inputting multiple game events sequentially into the event buffer, the required events (such as kills, throwing props, causing damage, entering the endgame, etc.) can be passed into the event buffer according to the event on / off settings. In other words, parameters can be adjusted in real time through front-end settings to control the activation and deactivation of various game events; when deactivated, it is not necessary to send the deactivated events to the event buffer.

[0045] Step S2: Whenever the debouncing buffer duration ends, the game events cached in the event buffer during that duration are sent to the event pre-blocker. Since the game events cached in the event buffer during the debouncing buffer duration will be sent to the event pre-blocker when the debouncing buffer duration ends, the process of the event buffer sending multiple game events to the event pre-blocker is a periodic loop, where the period is the debouncing buffer duration. That is, when there are many game events, multiple game events will not be sent to the event pre-blocker all at once. Instead, the event buffer debouncing multiple game events will be used to send them to the event pre-blocker in stages / batches. For example, there are 10 game events. The event buffer can buffer 2 game events within the first debouncing buffer duration. When the debouncing buffer duration ends, the 2 game events buffered in the event buffer during the debouncing buffer duration can be sent to the event pre-blocker. The event buffer can buffer 3 game events within the second debouncing buffer duration. When the debouncing buffer duration ends, the 3 game events buffered in the event buffer during the debouncing buffer duration can be sent to the event pre-blocker. The event buffer can buffer 5 game events within the third debouncing buffer duration. When the debouncing buffer duration ends, the 5 game events buffered in the event buffer during the debouncing buffer duration can be sent to the event pre-blocker.

[0046] Step S3: In the event pre-blocker, based on the attribute information of multiple game events, determine multiple first game events that conform to preset blocking rules from the multiple game events. Specifically, the attribute information may include at least one of the following sub-information: timestamp, type, identifier, and event status information. Based on this, the above step S3 can be implemented based on at least one of the following implementation methods:

[0047] Implementation Method 1: For any game event, each sub-information of the game event is matched against the blocking rules. If there is sub-information that does not conform to the blocking rules, then the game event does not conform to the blocking rules. For example, if a game event is of the item throwing type, when matching the timestamp, type, and identifier against the blocking rules, if the blocking rules indicate that item throwing type game events need to be blocked, then this item throwing type game event does not conform to the blocking rules.

[0048] Implementation Method Two: Based on the type of game event, query the first historical timestamp of similar events. If the difference between the first historical timestamp and the game event's timestamp is less than a preset first cooldown time, the game event does not meet the blocking rules. For example, if the game event is a kill event, and the difference between the first historical timestamp and the game event's timestamp is less than the preset first cooldown time, it indicates that the time of the kill event is too close to the time of the previous kill event. Considering that frequently showing the same type of event to the audience may cause viewer fatigue, it is necessary to block this type of game event.

[0049] Implementation Method 3: Based on the type of the game event, query the second historical timestamp of the associated type event. If the difference between the second historical timestamp and the game event's timestamp is less than a preset second cooldown time, the game event does not meet the blocking rules. The association between game event types can be freely set according to actual design needs; this embodiment does not impose restrictions. For example, a kill type can be associated with an item throwing type, and an item throwing event is an associated type event of a kill event. For instance, if the game event is a kill event and the associated type event is an item throwing event, and the difference between the second historical timestamp and the game event's timestamp is less than the preset second cooldown time, it indicates that the time of the kill event and the time of the item throwing event are too close, therefore, this type of game event needs to be blocked.

[0050] In other words, the above-described implementation methods two and three provide an event cooldown mechanism. This involves setting a separate cooldown time for each type of event relative to other event types and its own type. For example, the cooldown time for a throwing item event is 5 seconds relative to other throwing item events and 10 seconds relative to a kill event. With this setting, when a throwing item event is received, the received game event is compared to the previous throwing item event and kill event. If the cooldown time is less than the corresponding cooldown time, the event is ignored. In this way, the time difference between any two commands to switch the throwing item perspective will not be less than 5 seconds, and throwing item events will not be processed within 10 seconds after each kill event. To illustrate this in a practical scenario, during live event broadcasts, when players are frequently exchanging fire and resulting in kills, viewers are more interested in continuing to focus on the firefights. Relatively speaking, the importance of throwing items during these firefights is lower. Implementation methods two and three prevent other less important events from being triggered when a more important type of event occurs frequently.

[0051] It should be noted that each time a game event is received from the event buffer within the debouncing buffer duration, the blocking rule can be determined for any game event in the cached game event based on at least one of the above embodiments one to three. Of course, the embodiments of this application do not limit the determination of the blocking rule. In some other exemplary embodiments, the blocking rule can also be determined when the number of game events received by the event pre-blocker reaches a preset number threshold.

[0052] Step S4: Divide multiple first game events into multiple event slices according to a fixed time window.

[0053] Specifically, multiple first game events can be sorted according to their timestamp order, and event slices can be created multiple times. Each time an event slice is created, the first game event that is not sliced ​​is determined from the first game events that have not been sliced, and it is used as the base event. If the timestamp difference between the other first game events and the base event is not greater than the preset anti-shake time window, then the base event and other first game events are added to the event slice.

[0054] For example, if the stabilization time window is 3 seconds, sorting the six first game events according to their timestamps yields the following sequence: Event 1, Event 2, Event 3, Event 4, Event 5, and Event 6. First, determine the first game event (Event 1) as the baseline event. Then, iterate through all other events except Event 1 to identify Event 2, whose timestamp difference from the baseline event is no greater than the preset stabilization time window. Therefore, Event 1-2 can be used as the first event slice. Next, determine the first game event (Event 3) from the unsliced ​​first game events (i.e., events other than Event 1 and Event 2). Then, iterate through all other events except Event 1-3 to identify Event 4 and Event 5, whose timestamp difference from the baseline event is no greater than the preset stabilization time window. Event 3-5 can be used as the second event slice. Event 6, which has not been sliced, can be used as the third event slice. Through this method, events 1-6 can be sliced ​​to obtain three event slices.

[0055] Based on the above steps S1-S4, multiple game events can be divided into multiple event segments according to a fixed time window through multiple event debouncing and event blocking filtering.

[0056] In some optional embodiments, the event status information in the attribute information may include: operation method information, player location information, and game resource usage information.

[0057] Therefore, when there are multiple scoring dimensions, step 13 of the aforementioned embodiment, "scoring the game events in each event slice according to the scoring dimensions," can be implemented based on the following steps:

[0058] Step 141: For any game event in each event segment, determine the base score that matches the type of the game event; the game event is initiated by the target player. The base score matching the type of game event can be determined based on the correspondence between the game event type and the base score. This correspondence can be preset according to actual design requirements, and this embodiment does not impose any restrictions.

[0059] Step 142: Extract the first feature corresponding to the type from the operation method information, and determine the operation difficulty value of the target player based on the first feature. The first feature refers to a set of features that can reflect / characterize the key attributes of the operation behavior in this type of game event. It is used to quantitatively describe the complexity, accuracy, effectiveness, specificity, or fit with the game mechanics of the operation behavior, providing a specific basis for subsequently determining the operation difficulty value.

[0060] For example, in kill events, features related to "kill effectiveness" such as aiming accuracy (e.g., shooting deviation value) and skill release timing (e.g., whether the attack is launched during the enemy's skill cooldown period) can be extracted from the operation method information. Features related to "kill specialness" such as the target player's field of vision and attack path at the time of the game event can also be extracted. The reason for extracting features related to "blind kill" and "kill specialness" is that "penetrating kill" requires overcoming field of vision restrictions or physical obstacles, and its operation difficulty is higher than that of ordinary kill (e.g., direct kill without field of vision restrictions or penetration requirements). Moreover, the more obstacles / units are penetrated or the greater the degree of field of vision loss, the higher the operation difficulty will be.

[0061] For example, in healing events, features related to "healing value" can be extracted from the operation method information, such as the timing of healing (e.g., response speed when teammates' health is below 30%) and the number of people covered by group healing skills. Similarly, in resource gathering events, features related to "gathering ability" can be extracted from the operation method information, such as gathering efficiency (e.g., the amount gathered per unit time) and whether gathering acceleration skills were used.

[0062] Subsequently, a first corrected score for the game event can be determined based on the difficulty value of the operation, from the perspective of operation method. The difficulty value and the first corrected score are positively correlated. The operation method dimension is an evaluation perspective of the player's actions during the game event, used to measure the complexity, accuracy, or fit of the actions with the game mechanics.

[0063] Step 143: Extract the second feature corresponding to the type from the player location information, and use the second feature to characterize the relative positional relationship between the target player and other related players. The relative positional relationship can be used to describe the orientation relationship and distance between the target player and other related players. For example, in a kill event, the orientation relationship between the killer (target player) and the killed player (related player) and the distance between the killer and the killed player at the time of the kill can be specifically extracted from the player location information. As another example, in a healing event, features related to "healing risk," such as "the distance between the target player and the injured teammate (long-range support / close-range healing)" and "whether the target player is exposed to the fire range of other related players (such as enemies)," can be specifically extracted from the player location information.

[0064] Next, from the player position dimension, a second corrected score for the game event is determined based on the second feature. This involves determining the relative positional relationship between the target player and other related players based on the second feature, and then determining the second corrected score based on this relative positional relationship. The player position dimension is the evaluation perspective of the spatial positional relationship between the players (or players and non-player characters / objects) involved in the game event within the game scene. Different orientation relationships correspond to different corrected scores; therefore, the second corrected score for the game event can be determined based on the correspondence between orientation relationships and corrected scores. For example, a kill from behind corresponds to a higher second corrected score compared to other kill methods. Similarly, different distances correspond to different corrected scores; therefore, the second corrected score for the game event can be determined based on the correspondence between distance and corrected scores. For example, long-range healing corresponds to a higher second corrected score compared to close-range healing.

[0065] Step 144: Extract features from the game resource information to obtain a third feature. This third feature represents at least one of the target player's item usage and weapon usage. Game resources can include items and weapons. The difficulty of completing game events using different items varies.

[0066] Taking kill events as an example, we can extract specific information from game resource usage data, such as "weapon attribute information" and "item attribute information." For instance, using a short-range stun gun to achieve a kill is more difficult than using other weapons. Similarly, using item A to achieve a kill is more difficult than using item B. Taking resource gathering events as another example, we can extract specific features related to "resource utilization rationality," such as "gathering tool durability consumption rate" and "whether rare resources are prioritized," from game resource usage data.

[0067] Therefore, from the resource utilization dimension, the third modified score of a game event can be determined based on the third characteristic. This means determining at least one of the characteristics represented by the third characteristic: item usage and weapon usage. The resource utilization dimension is the evaluation perspective of how players allocate, consume, or utilize in-game resources during a game event, used to measure the rationality, efficiency, or value of resource utilization.

[0068] It is important to emphasize here that the feature extraction in steps 142-144 above is targeted feature extraction based on the game event type. That is, for different types of game events, specific features directly related to the core evaluation elements of that type are extracted from operation method information, player position information, or game resource utilization information, rather than using a uniform feature extraction standard for all event types. This ensures that the extracted features match the essential attributes of the event type. For example, when evaluating kill events, the focus is on attack accuracy, and when evaluating healing events, the focus is on the timing of healing. This avoids using a uniform standard to extract irrelevant features (such as not needing to extract "aiming accuracy" when evaluating healing events), thus making the game event score more accurately reflect the actual value of the game event.

[0069] Step 145: Adjust the base score using at least one of the first, second, and third adjusted scores to obtain the game event score. Optionally, at least one of the first, second, and third adjusted scores can be directly added to the base score to obtain the game event score. Optionally, different weight values ​​corresponding to different adjusted scores can be obtained according to the type of game event, where the weight values ​​corresponding to each adjusted score are different for different game event types. A candidate score is obtained by weighted summing at least one of the first, second, and third adjusted scores using the weight values, and then added to the base score to obtain the game event score.

[0070] By following steps 141-145 above, game events in each event segment can be scored relatively accurately from a scoring perspective.

[0071] In some optional embodiments, step 14 of the foregoing embodiment, "controlling the playback OB device to switch cameras according to the camera switching command corresponding to each target game event," can be implemented based on the following steps:

[0072] Step 141: Based on the timestamp of each target game event, add the camera switching command corresponding to each target game event to the command queue in sequence.

[0073] Step 142: For any camera switching command in the command queue, if the difference between the timestamp of the last camera switching and the timestamp of the target game event corresponding to the camera switching command is within the preset release range, the camera switching command is sent to the playback OB device to control the playback OB device to perform camera switching.

[0074] The preset release range consists of a minimum value (command queue release threshold) and a maximum value (command queue release limit). The command queue release threshold is the minimum difference between the timestamp of the last camera switch and the timestamp of the target game event corresponding to the camera switch command. Setting the command queue release threshold ensures a slight delay after the previous exciting kill event before switching to the next event, even when commands are sparse, thus ensuring optimal viewing for the audience. The command queue release limit, on the other hand, is the maximum difference between the timestamp of the last camera switch and the timestamp of the target game event corresponding to the camera switch command. If this difference exceeds the preset command queue release threshold, it indicates that too much time has passed since the previous exciting kill event, and the audience will miss the upcoming exciting scene.

[0075] In this way, the playback OB device can be controlled to switch lenses more accurately based on the range judgment of the preset release range.

[0076] Optionally, in actual scenarios, when controlling the replay OB device to switch cameras according to the camera switching instructions corresponding to each target game event, pre-set camera switching logic can be further incorporated. Taking a kill event as an example, if the currently spectating player is killed, and there are subsequent instructions in the instruction queue, the viewpoint corresponding to the next instruction can be switched directly; if the enemy player who killed the current player is still alive, the viewpoint of the enemy player can be switched; if none of the above conditions are met, the viewpoint of any surviving player can be randomly switched.

[0077] It should be emphasized that, based on the above embodiments, at least the following technical effects can be achieved: ① Fully automated capture of exciting kills, effectively reducing the problems of incorrect or missed cuts caused by delayed judgments and misoperations when manually switching replay shots; ② Ability to reliably and accurately select the most entertaining kill events, ensuring that replay shots capture key kill moments and switch shots at the appropriate time, improving the audience experience and reducing the uncertainty caused by manual switching; ③ Good versatility and scalability, reducing the manpower required for event production, improving overall production efficiency and quality stability, and reducing production costs.

[0078] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 11 to 14 can be device A; or the execution subject of steps 11 to 12 can be device A, and the execution subject of steps 13 to 14 can be device B; and so on.

[0079] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 12, 13, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0080] It should be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0081] Figure 2 This is a schematic diagram of a camera switching device provided in an exemplary embodiment of this application. The camera switching device can be communicatively connected to a playback OB device. The device may include: an acquisition module 201, used to: acquire multiple game events generated sequentially during the live broadcast of a target event based on game logs generated during the live broadcast; different game events have different attribute information; a segmentation module 202, used to: divide the multiple game events into multiple event segments according to the attribute information of the multiple game events, each event segment including at least one game event; a scoring module 203, used to: input the multiple event segments into an artificial intelligence-based event selection model, determine a scoring dimension according to the attribute information of the game events in each event segment, score the game events in each event segment from the scoring dimension, and determine the target game events whose scores meet the preset scoring conditions from the game events; and a switching module 204, used to: generate a camera switching instruction corresponding to each target game event according to a preset camera switching strategy, and control the playback OB device to perform camera switching according to the camera switching instruction corresponding to each target game event.

[0082] Optionally, the camera switching device is communicatively connected to the real-time observer (OB) device; when the acquisition module 201 acquires multiple game events sequentially generated during the live broadcast of the target event based on the game logs generated during the live broadcast, it is specifically used to: acquire the game logs generated during the live broadcast of the target event and the real-time status information of the target event from the real-time OB device and the replay OB device; parse the game logs to obtain multiple game events; each game event has initial attribute information; for each game event, select a target information item corresponding to the event type of the game event from the real-time status information of the target event, and fuse the target information item with the initial attribute information of the game event to obtain the attribute information of the game event.

[0083] Optionally, the lens switching device is configured with an event buffer and an event pre-blocker; when the segmentation module 202 divides the multiple game events into multiple event segments according to the attribute information of the multiple game events in a fixed time window, it is specifically used for: inputting the multiple game events sequentially into the event buffer, the event buffer sending game events to the event pre-blocker according to the image stabilization buffer duration; whenever the image stabilization buffer duration ends, sending the game events cached in the event buffer within the image stabilization buffer duration to the event pre-blocker; in the event pre-blocker, determining multiple first game events that meet the preset blocking rules from the multiple game events according to the attribute information of the multiple game events; and dividing the multiple first game events into multiple event segments according to the fixed time window.

[0084] Optionally, the attribute information includes at least one of the following sub-information: timestamp, type, identifier, and event status information; when the sharding module 202 determines multiple first game events that conform to a preset blocking rule from the multiple game events based on the attribute information of the multiple game events, it is specifically used to: for any game event, match each sub-information of the game event with the blocking rule respectively; if there is sub-information that does not conform to the blocking rule, then the game event does not conform to the blocking rule; and / or, according to the type of the game event, query the first historical timestamp of the same type of event of the game event; if the difference between the first historical timestamp and the timestamp of the game event is less than a preset first cooldown time, then the game event does not conform to the blocking rule; and / or, according to the type of the game event, query the second historical timestamp of the associated type of event of the game event; if the difference between the second historical timestamp and the timestamp of the game event is less than a preset second cooldown time, then the game event does not conform to the blocking rule.

[0085] Optionally, when the sharding module 202 divides the plurality of first game events into multiple event shards according to a fixed time window, it is specifically used to: sort the plurality of first game events according to timestamp order and establish event shards multiple times; wherein, each time an event shard is established, the first game event at the top of the first game events that have not been sharded is determined as the base event, and if the timestamp difference between the other first game events and the base event is not greater than a preset anti-shake time window, then the base event and the other first game events are added to the event shard.

[0086] Optionally, the event status information includes: operation method information, player location information, and game resource utilization information; when the scoring module 203 scores the game events in each event segment from the scoring dimension, it is specifically used for: determining a base score matching the type of the game event for any game event in each event segment; the game event is initiated by the target player; extracting a first feature corresponding to the type from the operation method information, and determining the operation difficulty value of the target player in the game event based on the first feature; determining a first corrected score for the game event from the operation method dimension based on the operation difficulty value; extracting from the player location information... A second feature corresponding to the type is used to characterize the relative positional relationship between the target player and other related players in the game event; a second corrected score for the game event is determined based on the second feature from the player position dimension; a third feature corresponding to the type is extracted from the game resource utilization information, the third feature being used to characterize the target player's item usage and / or weapon usage in the game event; a third corrected score for the game event is determined based on the third feature from the resource utilization dimension; the base score is corrected using the first corrected score, the second corrected score, and / or the third corrected score to obtain the score for the game event. Optionally, when the switching module 204 controls the playback OB device to perform camera switching according to the camera switching instruction corresponding to each target game event, it is specifically used to: add the camera switching instruction corresponding to each target game event to the instruction queue in sequence according to the timestamp of each target game event; for any camera switching instruction in the instruction queue, if the difference between the timestamp of the last camera switching and the timestamp of the target game event corresponding to the camera switching instruction is within a preset release range, then send the camera switching instruction to the playback OB device to control the playback OB device to perform camera switching.

[0087] In this embodiment, multiple sequentially generated game events with attribute information can be obtained based on game logs generated during the live broadcast of the target event. These events are then divided into multiple event segments according to timestamps and fixed time windows. The event segments are input into an artificial intelligence event selection model, which scores the game events in each event segment using a scoring dimension, and filters out target game events that meet preset score conditions. A corresponding switching command is generated according to a preset camera switching strategy to control the replay OB device to complete the camera switching. In this way, exciting moments can be captured relatively accurately, and the switching of replay OB camera perspectives can be performed relatively efficiently.

[0088] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application. This electronic device is applicable to the lens switching method provided in the foregoing embodiments, such as... Figure 3 As shown, the electronic device may include: a memory 301, a processor 302, and a communication component 303.

[0089] Memory 301 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, contact data, phone book data, messages, pictures, videos, etc.

[0090] In some exemplary embodiments, processor 302, coupled to memory 301, is used to execute a computer program in memory 301 for: acquiring multiple game events sequentially generated during the live broadcast of a target event based on game logs generated during the broadcast; different game events have different attribute information; dividing the multiple game events into multiple event segments according to the attribute information of the multiple game events, each event segment including at least one game event; inputting the multiple event segments into an artificial intelligence-based event selection model, determining a scoring dimension according to the attribute information of the game events in each event segment, scoring the game events in each event segment according to the scoring dimension, and determining target game events whose scores meet preset scoring conditions from the game events; generating a camera switching instruction corresponding to each target game event according to a preset camera switching strategy, and controlling the replay OB device to perform camera switching according to the camera switching instruction corresponding to each target game event.

[0091] Optionally, the electronic device is communicatively connected to the real-time observer device; when the processor 302 obtains multiple game events sequentially generated during the live broadcast of the target event based on the game logs generated during the live broadcast, it is specifically used to: obtain the game logs generated during the live broadcast of the target event and the real-time status information of the target event from the real-time observer device and the replay observer device; parse the game logs to obtain multiple game events; each game event has initial attribute information; for each game event, select a target information item corresponding to the event type of the game event from the real-time status information of the target event, and fuse the target information item with the initial attribute information of the game event to obtain the attribute information of the game event.

[0092] Optionally, the electronic device is configured with an event buffer and an event pre-blocker; when the processor 302 divides the multiple game events into multiple event slices according to the attribute information of the multiple game events in a fixed time window, it is specifically used for: inputting the multiple game events sequentially into the event buffer, the event buffer sending game events to the event pre-blocker according to the anti-shake buffer duration; whenever the anti-shake buffer duration ends, sending the game events cached in the event buffer within the anti-shake buffer duration to the event pre-blocker; in the event pre-blocker, determining multiple first game events that meet the preset blocking rules from the multiple game events according to the attribute information of the multiple game events; and dividing the multiple first game events into multiple event slices according to the fixed time window.

[0093] Optionally, the attribute information includes at least one of the following sub-information: timestamp, type, identifier, and event status information; when the processor 302 determines multiple first game events that conform to a preset blocking rule from the multiple game events based on the attribute information of the multiple game events, it is specifically used to: for any game event, match each sub-information of the game event with the blocking rule respectively; if there is sub-information that does not conform to the blocking rule, then the game event does not conform to the blocking rule; and / or, according to the type of the game event, query the first historical timestamp of the same type of event of the game event; if the difference between the first historical timestamp and the timestamp of the game event is less than a preset first cooldown time, then the game event does not conform to the blocking rule; and / or, according to the type of the game event, query the second historical timestamp of the associated type of event of the game event; if the difference between the second historical timestamp and the timestamp of the game event is less than a preset second cooldown time, then the game event does not conform to the blocking rule.

[0094] Optionally, when the processor 302 divides the plurality of first game events into multiple event slices according to a fixed time window, it is specifically used to: sort the plurality of first game events according to timestamp order and establish event slices multiple times; wherein, each time an event slice is established, the first game event at the top of the first game events that have not been sliced ​​is determined as the reference event; if the timestamp difference between the other first game events and the reference event is not greater than a preset anti-shake time window, then the reference event and the other first game events are added to the event slice.

[0095] Optionally, the event status information includes: operation method information, player location information, and game resource utilization information; when the processor 302 scores the game events in each event segment from the scoring dimension, it is specifically used to: for any game event in each event segment, determine a base score matching the type of the game event; the game event is initiated by the target player; extract a first feature corresponding to the type from the operation method information, and determine the operation difficulty value of the target player in the game event based on the first feature; determine a first corrected score for the game event from the operation method dimension based on the operation difficulty value; extract information from the player location information that matches the type of the game event. The second feature corresponding to the type is used to characterize the relative positional relationship between the target player and other related players in the game event; from the player position dimension, a second corrected score for the game event is determined based on the second feature; a third feature corresponding to the type is extracted from the game resource utilization information, the third feature being used to characterize the target player's item usage and / or weapon usage in the game event; from the resource utilization dimension, a third corrected score for the game event is determined based on the third feature; the base score is corrected using the first corrected score, the second corrected score, and / or the third corrected score to obtain the score for the game event.

[0096] Optionally, when the processor 302 controls the playback OB device to perform camera switching according to the camera switching instruction corresponding to each target game event, it is specifically configured to: add the camera switching instruction corresponding to each target game event to the instruction queue in sequence according to the timestamp of each target game event; for any camera switching instruction in the instruction queue, if the difference between the timestamp of the last camera switching and the timestamp of the target game event corresponding to the camera switching instruction is within a preset release range, then send the camera switching instruction to the playback OB device to control the playback OB device to perform camera switching.

[0097] Furthermore, such as Figure 3 As shown, the electronic device also includes other components such as a display 304, a power supply component 305, and an audio component 306. Figure 3 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 3 The components shown.

[0098] This application also provides a computer-readable storage medium that, when executed by a processor, enables the processor to implement the steps in the lens switching method.

[0099] This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, performs the steps in the lens switching method.

[0100] In this embodiment, multiple sequentially generated game events with attribute information can be obtained based on game logs generated during the live broadcast of the target event. These events are then divided into multiple event segments according to timestamps and fixed time windows. The event segments are input into an artificial intelligence event selection model, which scores the game events in each event segment using a scoring dimension, and filters out target game events that meet preset score conditions. A corresponding switching command is generated according to a preset camera switching strategy to control the replay OB device to complete the camera switching. In this way, exciting moments can be captured relatively accurately, and the switching of replay OB camera perspectives can be performed relatively efficiently.

[0101] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0102] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0103] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0104] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0105] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0106] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0107] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0108] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0109] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0110] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

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

[0112] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access 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, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0113] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0114] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A lens switching method, characterized in that, Applicable to an electronic device that is communicatively connected to a playback OB device, the method includes: Based on the game logs generated during the live broadcast of the target event, multiple game events generated sequentially during the live broadcast are obtained; different game events have different attribute information. Based on the attribute information of the multiple game events, the multiple game events are divided into multiple event segments according to a fixed time window, and each event segment includes at least one game event; The multiple event segments are input into an AI-based event selection model. The scoring dimension is determined based on the attribute information of the game events in each event segment. The game events in each event segment are scored based on the scoring dimension. Target game events whose scores meet the preset scoring conditions are then identified from the game events. According to the preset camera switching strategy, a camera switching instruction corresponding to each target game event is generated, and the playback OB device is controlled to switch cameras according to the camera switching instruction corresponding to each target game event.

2. The method according to claim 1, characterized in that, The electronic device is communicatively connected to the real-time OB device; Based on the game logs generated during the live stream of the target event, multiple game events generated sequentially during the live stream are obtained, including: The game logs generated during the live broadcast of the target event and the real-time status information of the target event are obtained from the real-time OB device and the replay OB device. The game logs are parsed to obtain multiple game events; each game event has initial attribute information. For any game event, select a target information item corresponding to the event type of the game event from the real-time status information of the target event, and fuse the target information item with the initial attribute information of the game event to obtain the attribute information of the game event.

3. The method according to claim 1, characterized in that, The electronic device is equipped with an event buffer and an event pre-blocker; based on the attribute information of the multiple game events, the multiple game events are divided into multiple event slices according to a fixed time window, including: The multiple game events are sequentially input into the event buffer, and the event buffer sends the game events to the event pre-blocker according to the anti-shake buffer duration. Whenever the anti-shake buffer duration ends, the game events cached in the event buffer during the anti-shake buffer duration are sent to the event pre-blocker; In the event pre-blocker, based on the attribute information of the multiple game events, multiple first game events that conform to preset blocking rules are determined from the multiple game events; The multiple first game events are divided into multiple event slices according to a fixed time window.

4. The method according to claim 3, characterized in that, The attribute information includes at least one of the following sub-information: timestamp, type, identifier, and event status information; Based on the attribute information of the multiple game events, a plurality of first game events that conform to preset blocking rules are determined from the multiple game events, including: For any game event, each sub-information of the game event is matched against the blocking rule. If there is sub-information that does not conform to the blocking rule, then the game event does not conform to the blocking rule; and / or, Based on the type of the game event, query the first historical timestamp of the same type of event; if the difference between the first historical timestamp and the timestamp of the game event is less than a preset first cooldown time, then the game event does not meet the blocking rule; and / or, Based on the type of the game event, query the second historical timestamp of the associated type of event of the game event. If the difference between the second historical timestamp and the timestamp of the game event is less than the preset second cooldown time, then the game event does not meet the blocking rule.

5. The method according to claim 3, characterized in that, The multiple first game events are divided into multiple event slices according to a fixed time window, including: The multiple first game events are sorted according to their timestamps, and event slices are created multiple times. Each time an event slice is created, the first game event that is the first one in the unsliced ​​first game events is determined as the baseline event. If the timestamp difference between the other first game events and the baseline event is not greater than a preset anti-shake time window, then the baseline event and the other first game events are added to the event slice.

6. The method according to claim 4, characterized in that, The event status information includes: operation method information, player location information, and game resource usage information; The game events in each event slice are scored according to the scoring dimensions, including: For any game event in each event segment, a base score matching the type of the game event is determined; the game event is initiated by the target player. Extract a first feature corresponding to the type from the operation method information, and determine the operation difficulty value of the target player in the game event based on the first feature; determine a first corrected score of the game event from the operation method dimension based on the operation difficulty value; A second feature corresponding to the type is extracted from the player location information. The second feature is used to characterize the relative positional relationship between the target player and other related players in the game event. From the player location dimension, a second corrected score of the game event is determined based on the second feature. A third feature corresponding to the type is extracted from the game resource utilization information. The third feature is used to characterize the target player's item usage and / or weapon usage in the game event. From the resource utilization dimension, a third modified score for the game event is determined based on the third feature. The base score is adjusted using the first adjusted score, the second adjusted score, and / or the third adjusted score to obtain the score of the game event.

7. The method according to any one of claims 1-6, characterized in that, Controlling the playback OB device to switch cameras according to the camera switching command corresponding to each target game event includes: Based on the timestamp of each target game event, the camera switching command corresponding to each target game event is added to the command queue in sequence; for any camera switching command in the command queue, if the difference between the timestamp of the last camera switching and the timestamp of the target game event corresponding to the camera switching command is within a preset release range, the camera switching command is sent to the playback OB device to control the playback OB device to perform camera switching.

8. An electronic device, characterized in that, include: A memory and a processor; wherein the memory is configured to: store one or more computer instructions; and the processor is configured to execute the one or more computer instructions to: perform the steps of the method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, causes the processor to perform the steps of the method according to any one of claims 1-7.

Images