Data processing method and apparatus, storage medium, device, and program product

Abstract

The method comprises: in response to a triggering event, acquiring a current scene feature of a terminal; performing a matching operation in a historical experience library according to the scene feature to obtain historical scheduling experience information adapted to the current scene; predicting a waiting parameter corresponding to a main request of a first data source in a current data request based on the matched historical scheduling experience information, and determining a starting time of a backup request of a second data source and a first priority of the first data source and the second data source in a request starting phase according to the waiting parameter; and performing a cooperative scheduling interaction between the main request of the first data source and the backup request of the second data source according to the waiting parameter, the starting time and the first priority to obtain response data, so as to optimize data request scheduling and improve data transmission efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to a data processing method, apparatus, storage medium, device, and program product. Background Technology

[0002] With the rapid development of internet technology, users' demand for online data services is increasing, especially in high-bandwidth scenarios such as video playback and online gaming, where users expect a smooth and stable data transmission experience. However, in practical applications, the complexity and variability of the network environment, such as the diversity of network types (Wi-Fi, 4G, 5G, etc.), fluctuations in signal strength, and differences in terminal device performance, can all lead to delays and stuttering during data requests and transmissions, severely impacting the user experience.

[0003] Especially in multi-data source environments, intelligently and efficiently scheduling data requests from different data sources becomes crucial for improving user experience. Traditional methods often rely on fixed scheduling strategies, which cannot be dynamically adjusted according to real-time changes in the network environment and terminal scenario characteristics. This results in inflexible data request scheduling, an inability to fully utilize the advantages of each data source, and may even exacerbate network congestion and reduce data transmission efficiency in some cases.

[0004] Furthermore, for specific application scenarios such as video playback, users have higher requirements for the real-time performance and stability of data requests. Improper data request scheduling can lead to problems such as video playback stuttering and latency, severely impacting the user's viewing experience. Therefore, optimizing data request scheduling strategies according to the needs of specific application scenarios such as video playback has become an urgent technical problem to be solved. Summary of the Invention

[0005] This disclosure provides a data processing method, apparatus, storage medium, device, and program product. By adaptively predicting the waiting parameters of data requests based on the current scene characteristics of the terminal, and realizing dynamic collaborative scheduling between the primary request of the first data source and the backup request of the second data source based on the waiting parameters, the data request scheduling is optimized and the data transmission efficiency is improved.

[0006] On one hand, this disclosure provides a data processing method, the method comprising: in response to a triggering event, acquiring current scene characteristics of a terminal; performing a matching operation in a historical experience database based on the scene characteristics to obtain historical scheduling experience information adapted to the current scene; predicting the waiting parameters corresponding to the main request of a first data source in the current data request based on the matched historical scheduling experience information, and determining the start time of the backup request of a second data source and the first priority of the first data source and the second data source in the request start phase based on the waiting parameters, the start time, and the first priority; and performing a collaborative scheduling interaction between the main request of the first data source and the backup request of the second data source to obtain response data based on the waiting parameters, the start time, and the first priority.

[0007] On the other hand, embodiments of this disclosure provide a data processing apparatus, the apparatus comprising: The acquisition unit is used to acquire the current scene features of the terminal in response to the triggering event; The matching unit is used to perform a matching operation in the historical experience database according to the scene characteristics in order to obtain historical scheduling experience information that is compatible with the current scene. The first processing unit is used to predict the waiting parameters corresponding to the main request of the first data source in this data request based on the matched historical scheduling experience information, and determine the start time of the backup request of the second data source and the first priority of the first data source and the second data source in the request start phase according to the waiting parameters. The second processing unit is configured to perform a coordinated scheduling interaction between the main request of the first data source and the backup request of the second data source according to the waiting parameters, the startup timing, and the first priority, so as to obtain response data.

[0008] On the other hand, embodiments of this disclosure provide a computer-readable storage medium storing a computer program adapted for loading by a processor to perform the data processing method as described in any of the above embodiments.

[0009] On the other hand, embodiments of this disclosure provide a computer device, the computer device including a processor and a memory, the memory storing a computer program, the processor executing the data processing method as described in any of the above embodiments by calling the computer program stored in the memory.

[0010] On the other hand, embodiments of this disclosure provide a computer program product, including computer instructions, which, when executed by a processor, implement the data processing method as described in any of the above embodiments.

[0011] The data processing method provided in this disclosure, in response to a triggering event, acquires the current scene characteristics of the terminal, enabling scheduling decisions to perceive the real-time environmental state of the terminal. Based on the scene characteristics, a matching operation is performed in a historical experience database to obtain historical scheduling experience information adapted to the current scene, ensuring scheduling availability. Based on the matched historical scheduling experience information, the waiting parameters corresponding to the main request of the first data source in this data request are predicted, and the start time of the backup request of the second data source and the first priority of the first and second data sources during the request start phase are determined according to the waiting parameters, allowing the waiting parameters to be adaptively adjusted. Based on the waiting parameters, start time, and first priority, a collaborative scheduling interaction is performed between the main request of the first data source and the backup request of the second data source to obtain response data, achieving orderly coordination between the main request and the backup request in the time dimension. This disclosure, by acquiring the current scene characteristics of the terminal in response to a triggering event and performing a matching operation in a historical experience database based on the scene characteristics to obtain historical scheduling experience information adapted to the current scene, predicts the waiting parameters of the current data request, and performs collaborative scheduling interaction to obtain response data, transforms data request scheduling from fixed static execution to adaptive execution based on the terminal scene and historical scheduling experience information, thereby optimizing data request scheduling and improving data transmission efficiency. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram illustrating an application scenario of the data processing system provided in an embodiment of this disclosure.

[0014] Figure 2 This is a schematic flowchart of a data processing method provided in an embodiment of the present disclosure.

[0015] Figure 3 This is a schematic diagram of the structure of a data processing apparatus provided in an embodiment of the present disclosure.

[0016] Figure 4 A schematic diagram of the structure of a computer device provided in an embodiment of this disclosure. Detailed Implementation

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

[0018] First, the following explanations are given for some of the nouns or terms that appear in the embodiments of this disclosure: Peer-to-peer data source: refers to the data transmission source based on peer-to-peer network (P2P) technology, where the terminal acts as a client to download data and also as a server to upload data to other terminals, and data is exchanged directly between terminal nodes.

[0019] Content Delivery Network (CDN) data source: refers to the data transmission source based on Content Delivery Network (CDN) technology, which provides data to the terminal through cache nodes deployed at the network edge.

[0020] Triggering event: refers to an event that triggers the execution of the data processing method in this embodiment of the disclosure. It can be a specific operation initiated by the user, such as a video playback triggering event, specifically including the user clicking the video play button, resuming playback after the user drags the playback progress bar, resuming playback after a network switch, or resuming playback after the application switches to the foreground. It can also be a specific condition automatically detected by the system, such as changes in network status or device status.

[0021] Scene characteristics: refers to multi-dimensional information used to characterize the current environment and state of the terminal, including but not limited to network type, signal strength, current time period, location category, city level, historical data source request success rate, historical data source average response time, network stability, and density of connectable peer nodes.

[0022] Scene representation: refers to the data format obtained after encoding or vectorizing scene features, which is easy for computers to match and compare. It can be multi-dimensional vectors, feature sets, or encoding structures.

[0023] Historical experience database: refers to a database or storage structure used to store historical scheduling experience information. It can be deployed on the terminal side, server side, edge node side, or in an end-to-cloud collaborative manner. The historical experience database uses experience units as the basic storage unit. Each experience unit records information such as scheduling parameters, sample size, confidence level, and update time corresponding to a certain type of scenario.

[0024] Historical scheduling experience information: refers to historical scheduling records stored in the historical experience database that are associated with a certain scenario, including at least the scheduling parameters and sample size under that scenario; the scheduling parameters include waiting time or statistical indicators related to waiting time.

[0025] Multi-granularity scene matching: refers to a matching mechanism that prioritizes matching according to more granular scene constraints when searching for historical scheduling experience information in the historical experience database that is suitable for the current scene. When there is insufficient historical experience in the granular scene, the scene constraints are gradually relaxed until usable historical experience is obtained.

[0026] Fine-grained scenario constraints refer to matching conditions composed of multiple scenario dimensions such as network type, location category, city level, time period, signal strength, and network stability. These conditions are used to match historical scheduling experience information in the historical experience database that is closest to the current scenario.

[0027] Medium-granularity scene constraints: These are matching conditions consisting of network type and location category. They are scene constraints obtained by relaxing the dimensions such as city level, time period, signal strength and network stability when historical experience is insufficient under fine-grained scene constraints.

[0028] Coarse-grained scene constraints: These are matching conditions composed of network types. They are scene constraints obtained by further removing location categories when historical experience is still insufficient under medium-grained scene constraints.

[0029] Response data: refers to the data obtained by the terminal in response to a triggering event through the coordinated scheduling interaction between the first data source master request and the second data source backup request; in one embodiment, the response data is video playback data.

[0030] Waiting parameters: These are parameters used to control the waiting time for the primary request from the first data source. They can take the form of at least one of the following: waiting time, backup request trigger threshold, switching conditions, or concurrency control strategy parameters.

[0031] Waiting time: refers to the length of time from the initiation of the first data source master request to the triggering of the second data source backup request or the making of a data source switching decision.

[0032] Waiting window: refers to the time interval during which the terminal waits for the first data source to return data during the data request initiation phase. The duration of the waiting window is determined at least according to the waiting parameters. It can be equal to the waiting duration in the waiting parameters, or it can be increased or decreased by a preset offset based on the waiting duration. Within this waiting window, the terminal waits for the first data source to return data and does not initiate a formal data request from the second data source, so as to give the first data source sufficient opportunity to respond.

[0033] First priority: refers to the scheduling tendency determined by the terminal based on the waiting parameters during the request start phase, including priority of the first data source, priority of the second data source, or coordinated scheduling state of the first data source and the second data source.

[0034] Playback conditions met: This means that the data returned by the data source has met the requirements for starting or continuing playback, including obtaining the data segment required to decode the first frame, the total amount of media data reaching the preset buffer threshold, or the amount of data required to meet the specified continuous playback duration.

[0035] Actual feedback information refers to the actual data collected during or after a data request to reflect the result of the request, including the actual waiting time, whether each data source successfully returned data, the actual response time, the final data source used, the time taken for the first frame, and the result of playback interruption or switching.

[0036] Target waiting parameter: refers to the better waiting parameter calculated based on the actual feedback information of this request in this scenario, which is used to update the scheduling parameters of the corresponding experience unit in the historical experience base.

[0037] Update step size: refers to the weight ratio of the target waiting parameter in the weighted average update when updating historical scheduling experience information, and is used to control the response speed of the experience unit to feedback information.

[0038] Freshness decay: refers to the management operation of reducing the matching weight or confidence of historical scheduling experience information that was created earlier or has not been hit for a long time.

[0039] Drift reset: refers to the process of reducing the confidence level, resetting the sample size, or quickly relearning when the prediction results of historical scheduling experience information deviate significantly from the actual feedback results.

[0040] Discrete dimension: refers to the dimension in scene features that takes discrete categories rather than continuous values, including network type, location category and city level, etc., and is used to map scene features to candidate scene buckets for efficient matching.

[0041] Estimated response time quantile: refers to the specific quantile value of the response time of the first data source in the current scenario, which is predicted based on the historical response time distribution of the first data source recorded in historical scheduling experience information, and is used to calculate the waiting time of this data request.

[0042] Estimated success rate level: This refers to the evaluation result of the success rate of the first data source request in the current scenario, which is predicted based on the historical request success rate of the first data source recorded in the historical scheduling experience information. It is used to calculate the waiting time of this data request.

[0043] Coordinated scheduling interaction refers to the request execution process in which the primary request from the first data source and the backup request from the second data source cooperate with each other in terms of time and priority. Coordinated scheduling interaction reflects the coordinated relationship between the primary request and the backup request in terms of time sequence, priority, and final selection.

[0044] This disclosure provides a data processing method, apparatus, storage medium, device, and program product. Specifically, the data processing method of this disclosure can be executed by a computer device, which can be a terminal or server, etc.

[0045] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of the data processing system provided in this embodiment. The data processing system includes a terminal 10 and a server 20, etc.; the terminal 10 and server 20 are connected via a network, such as a wired or wireless network. The terminal 10 can be a smartphone, tablet, laptop, personal computer, desktop computer, smart TV, wearable smart device, smart vehicle terminal, head-mounted virtual reality device, etc. The terminal may also include a client, which can be an application client, browser client, instant messaging client, or mini-program, etc. The server 20 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN), and big data and artificial intelligence platforms.

[0046] Terminal 10 can be used to display a graphical user interface. Terminal 10 is used to interact with the user through the graphical user interface, such as downloading and installing a corresponding client and running it, calling and running a corresponding app, or presenting the corresponding graphical user interface by logging into the client.

[0047] It should be noted that, in this embodiment of the disclosure, the entity executing the data processing method can be a terminal device or a server. The terminal device can be a local terminal device or the aforementioned client device. This embodiment of the disclosure does not limit the type of the entity executing the method.

[0048] Please see Figure 2 , Figure 2 This is a flowchart illustrating a data processing method provided in an embodiment of the present disclosure. It should be noted that the steps shown may be executed in a logical order different from that shown in the flowchart. The method may include the following steps: Step 110: In response to the trigger event, obtain the current scene characteristics of the terminal.

[0049] In some embodiments, the triggering event is a video playback triggering event, and the scene feature is a scene feature of the video playback startup phase. The video playback triggering event includes any of the following: user clicking the video play button, resumption of playback after the user drags the playback progress bar, resumption of playback after network switching, or resumption of playback after the application switches to the foreground. When the terminal detects any of the above triggering events, it immediately collects a scene snapshot of the current moment as the scene feature of this data request to ensure that the scene information can accurately reflect the terminal environment state at the moment playback starts.

[0050] In some embodiments, the scene features include one or more of the following dimensions: network type, signal strength, current time period, location category of the terminal, city level, success rate of the first data source request within a preset time window, average response time of the first data source within the preset time window, network stability, and density of connectable peer nodes.

[0051] Among them, the network type is used to distinguish the type of network environment that the current terminal is accessing, such as wireless LAN, 5G mobile communication network, 4G mobile communication network, 3G mobile communication network or Ethernet, etc. Different network types have significant differences in bandwidth, latency and stability, which directly affect the response speed of the primary data source request.

[0052] Signal strength is used to quantify the strength of the current network signal. It can be measured by indicators such as reference signal received power, signal-to-interference-plus-noise ratio, or received signal strength indication. Network signal strength directly affects the success rate and response time of data transmission.

[0053] The current time period is used to reflect the impact of intraday time changes on network congestion and the number of online peer nodes. For example, network congestion during the evening peak hours may cause the first data source to respond slowly, while the network is relatively idle during the late night hours and the first data source may respond faster.

[0054] Among them, location category and city level are used to reflect the differences in the distribution density of peer nodes in different geographical regions. First-tier cities usually have more peer nodes and richer resources, while third-tier cities and below have relatively sparse peer nodes.

[0055] The success rate of the first data source request within the preset time window and the average response time of the first data source within the preset time window are used to characterize the performance of the first data source in historical requests under this scenario. The success rate of the first data source request reflects the availability of the first data source under this scenario, and the average response time of the first data source reflects the response speed of the first data source under this scenario. For example, the preset time window can be the past 1 hour, past 3 hours, past 6 hours, past 12 hours, past 24 hours, past 3 days, or past 7 days. The specific window duration can be configured according to the scenario type and terminal storage capacity to ensure a balance between the timeliness and statistical significance of historical statistical information.

[0056] Network stability characterizes the degree of fluctuation in the current network and can be comprehensively evaluated through indicators such as the variance of network signal strength per unit time, retransmission rate, or connection interruption frequency. Network stability directly affects the reliability of the primary data source request returning data within the waiting window. Connectable peer node density characterizes the number of peer nodes that can act as the primary data source provider in the current scenario. The higher the node density, the greater the probability and speed of the primary data source request receiving a data response.

[0057] By collecting the aforementioned multi-dimensional scene information, the terminal can finely depict the current scene from multiple perspectives, such as network environment, spatiotemporal attributes, and historical performance, providing a rich and accurate scene representation foundation for subsequent multi-granularity matching, thereby improving the accuracy of scene recognition and the pertinence of scheduling decisions.

[0058] In some embodiments, the different dimensional information in the scene features are preprocessed in one or more of the following ways: each dimensional feature is uniformly normalized; the time dimension adopts a periodic encoding method to retain intraday periodicity; the location information adopts categorized information obtained locally by the terminal, the categorized information including cell identifier of base station positioning, wireless LAN media access control address clustering, or gridded encoding of GPS coordinates.

[0059] In this context, the unified normalization of features across dimensions refers to mapping scene feature dimensions with different dimensions and value ranges to a unified numerical range. For example, mapping the values ​​of each dimension to the range [0,1] can eliminate matching biases caused by differences in dimensions between different dimensions, making each dimension comparable in subsequent similarity calculations or scene matching.

[0060] The use of periodic encoding in the time dimension refers to encoding time information into periodic feature vectors. For example, using sine-cosine pair encoding to map timestamps to a periodic space allows similar time points to have similar vector representations in the feature space, thus preserving the intraday time periodicity and avoiding the incorrect representation of 23:59 and 00:00, two adjacent time points, as two distant points in the feature space.

[0061] The location information using categorized information acquired locally by the terminal refers to using easily obtainable and stable coarse-grained location identifiers instead of precise positioning. Specifically, this includes one or more of the following: cell identifiers from base station positioning, i.e., the cell number of the infrastructure base station currently connected to the terminal, with different cell identifiers corresponding to different geographical areas; wireless LAN media access control address clustering, i.e., determining the terminal's location area by performing cluster analysis on the scanned wireless LAN access point media access control addresses; or gridded encoding of GPS coordinates, i.e., mapping precise positioning coordinates to grid cells of a preset size (e.g., a grid with sides of 500 meters or 1000 meters), using the grid cell number as the location category identifier. By using categorized location information instead of precise positioning, user location privacy can be protected and system resource overhead reduced while preserving the influence of location category on scheduling decisions.

[0062] The terminal converts the preprocessed multidimensional scene features into a scene representation. This scene representation can take various forms, such as multidimensional vectors, feature sets, or coding structures, and is used for subsequent matching operations in the historical experience base. The scene representation is not limited to fixed-dimensional vectors; it can also use feature sets, coding structures, or other comparable representations, as long as it can reflect the feature distribution of the current scene and support matching or similarity comparison with scene representations in historical experience units.

[0063] Step 120: Based on the scene characteristics, perform a matching operation in the historical experience database to obtain historical scheduling experience information that is compatible with the current scene.

[0064] The data processing system where the terminal resides maintains a historical experience database. This database can be deployed on the terminal side, server side, edge node side, or in an end-to-cloud collaborative manner to record historical scheduling experience information. The historical experience database uses experience units as the basic storage unit. Each experience unit records information such as scenario characteristics (or scenario representations), scheduling parameters, cumulative sample size, confidence level, and last update time for a specific scenario. The scheduling parameters include at least the waiting time or related statistical indicators for that scenario. The cumulative sample size reflects the statistical reliability of the experience unit, the confidence level measures its reliability in the current scenario, and the last update time supports the freshness assessment and lifecycle management of the experience unit. In one embodiment, the historical experience database is maintained locally by the terminal and stored in the terminal's non-volatile storage medium to support independent scheduling decisions by the terminal in offline or network-free environments. In another embodiment, the historical experience database is deployed on the server side or edge node, with multiple terminals sharing the same database to achieve cross-terminal experience accumulation and knowledge sharing. In another embodiment, the historical experience database is deployed using an edge-cloud collaborative approach. The terminal maintains a subset of frequently used experience data locally, while the server maintains the full dataset. When a local match fails, the terminal sends a query request to the server. The server returns a matching result for the terminal's reference, and the terminal updates its local experience subset and server-side experience data based on the local feedback. After responding to a trigger event and completing scene feature collection, the terminal performs a matching operation in the historical experience database based on the scene features. If the historical experience database is deployed locally on the terminal, the matching is performed directly in the terminal's local storage. If the historical experience database is deployed on the server or edge, the terminal sends a matching request to the server or edge and receives the returned matching result. If an edge-cloud collaborative approach is used, the terminal prioritizes performing matching on its local experience subset, and if a match fails, it sends a query to the server to obtain historical scheduling experience information suitable for the current scene.

[0065] In some embodiments, performing a matching operation in the historical experience base according to the scene characteristics to obtain historical scheduling experience information adapted to the current scene includes: prioritizing matching according to fine-grained scene constraints based on the scene characteristics; when the historical scheduling experience information matched under the fine-grained scene constraints does not meet the preset availability conditions, gradually relaxing the granularity of the scene constraints until the matched historical scheduling experience information meets the preset availability conditions to obtain historical scheduling experience information adapted to the current scene; wherein, the preset availability conditions include: the sample size of the matched historical scheduling experience information is not less than a preset threshold.

[0066] The preset availability conditions are used to determine whether the matched historical scheduling experience information is sufficient to support the current scheduling decision. In one embodiment, the preset availability condition is that the sample size of the matched historical scheduling experience information is not less than a preset threshold, meaning that the statistical results are only reliable when the number of historical requests in the scenario reaches a certain number. In another embodiment, the preset availability conditions may also include that the confidence level of the matched historical scheduling experience information is not less than a preset confidence threshold, and that the last update time of the matched historical scheduling experience information is no more than a preset validity period from the current time, to ensure that the historical experience is statistically reliable and timely. This disclosure uses sample size as the core judgment dimension of the preset availability conditions for explanation, but those skilled in the art will understand that confidence level, freshness, and other conditions can also be used as components of the preset availability conditions.

[0067] In some embodiments, failure to meet the preset availability conditions includes one or more of the following situations: There is no experience unit that matches the scene characteristics at the current granularity level, that is, data request scheduling has never been performed in this scene, which is a cold start situation with no history. There are matching empirical units at the current granularity level, but their cumulative sample size is lower than the preset threshold, that is, the number of historical records is insufficient and the statistical results do not have sufficient credibility, which belongs to the low sample situation of insufficient experience. There are matching empirical units at the current granularity level, but their confidence level is lower than the preset confidence threshold, meaning that the historical variance is large or the prediction error is high; and There are matching experience units at the current granularity level, but their last update time has exceeded the preset validity period, meaning that the historical experience has expired and may not reflect the true state of the current network environment.

[0068] When any of the above situations occur, the terminal determines that the historical scheduling experience information at the current granularity is unavailable and needs to gradually relax the granularity of the scenario constraints to seek more coarse-grained available experience.

[0069] By prioritizing matching based on fine-grained scenario constraints, and gradually relaxing the granularity of scenario constraints until usable experience is obtained when the matched historical scheduling experience information does not meet the preset usable conditions (such as the sample size being lower than the preset threshold), it ensures that the scheduling parameters most closely matching the current scenario can be obtained when there is sufficient historical experience, while avoiding the problem that no usable experience can be obtained in cold starts or new scenarios due to overly fine scenario division. This enables the terminal to provide a reliable scheduling basis for the playback startup interaction process in various scenarios.

[0070] In some embodiments, the progressive relaxation of scene constraint granularity includes: performing a first-level matching according to fine-grained scene constraints that include at least the network type, the location category, and the city level; if the sample size of historical scheduling experience information matched under the fine-grained scene constraints is lower than a first threshold, then performing a second-level matching according to medium-grained scene constraints that include the network type and the location category; if the sample size of historical scheduling experience information matched under the medium-grained scene constraints is lower than a second threshold, then performing a third-level matching according to coarse-grained scene constraints that include the network type.

[0071] The first level of matching is the fine-grained scenario matching layer. Fine-grained scenario constraints include at least three core dimensions: network type, location category, and city level. Optionally, other dimensions such as time period, signal strength, and network stability can be further included to accurately locate historical experiences highly similar to the current scenario. If the fine-grained scenario matching layer fails to match any experience units that meet the preset usability conditions, it degenerates to the second level of matching, the medium-grained scenario matching layer. In the medium-grained matching layer, relatively sparse or highly fluctuating dimensions such as city level and node density are removed, retaining only the network type and location category—the two most stable and core dimensions affecting scheduling—for matching. This broadens the matching scope from fine-grained scenarios to all experiences under the same network type and location category. If the medium-grained matching layer still fails to match any experience units that meet the preset usability conditions, it further degenerates to the third level of matching, the coarse-grained scenario matching layer. In the coarse-grained matching layer, only the most basic and stable dimension—network type—is retained for matching, ensuring that usable experience can be obtained under any network type, guaranteeing the basic usability of matching operations in new scenarios or scenarios with sparse samples. The first threshold, the second threshold, and the third preset threshold can be the same or different. For example, the first threshold of the fine-grained scene layer can be configured to 3 to 5 valid samples, the second threshold of the medium-grained layer can be configured to 5 to 10 valid samples, and the third preset threshold of the coarse-grained layer can be configured to more than 10 valid samples. The specific values ​​can be configured and adjusted according to business needs, terminal storage capacity, and scene complexity. This disclosure does not limit them.

[0072] In this context, the success rate of the first data source request within the preset time window and the average response time of the first data source within the preset time window are used as experience unit status information for scoring or ranking experience units, and are not used as matching dimensions in the fine-grained scene constraints, the medium-grained scene constraints, or the coarse-grained scene constraints. In other words, when determining which scene bucket the current scene belongs to and which experience unit to match, the matching key value consists of discrete and stable scene dimensions such as network type, location category, and city level. The success rate of the first data source request and the average response time of the first data source are dynamically changing statistical indicators. They are not used as constraints for scene division, but are used to score the reliability and priority of the experience unit after it is matched. For example, when multiple candidate experience units are matched, the experience unit with a higher first data source request success rate and a shorter average response time can be selected as the output. Or, when fine-grained scene experience is insufficient and it is necessary to refer to similar scene experience for weighted fusion, these statistical indicators can be used as the basis for adjusting the weighting coefficients, so that scene experience with better historical performance has a higher weight in the fusion.

[0073] By progressively relaxing and specifying the constraints into a three-level matching structure—from fine-grained constraints that include at least network type, location category, and city level, to medium-grained constraints that include network type and location category, and finally to coarse-grained constraints that include only network type—a clear and orderly degradation path is provided for multi-granularity matching. This ensures that the matching logic has a clear hierarchical progression while maintaining accuracy, making it easier for the terminal to execute efficiently.

[0074] In some embodiments, the method further includes: if no historical scheduling experience information is obtained after performing third-level matching according to network type, or if the sample size of the matched historical scheduling experience information is still lower than a third preset threshold, then a preset default waiting parameter is used as the waiting parameter for this data request.

[0075] For example, when all three matching levels fail to obtain historical scheduling experience information that meets the preset availability conditions, the terminal will no longer attempt matching, but will directly use the system's preset default waiting parameters as the waiting parameters for this data request. These preset default waiting parameters can be determined in one or more of the following ways: The first way is a globally optimal waiting time experience value determined based on a large amount of statistical data, such as an average optimal waiting time of 2000 milliseconds obtained from the statistical analysis of historical playback startup data of all network users; the second way is based on different default values ​​preset according to network type, such as a default waiting time of 3000 milliseconds in a wireless LAN scenario, 1500 milliseconds in a 5G mobile communication network scenario, and 800 milliseconds in a 4G mobile communication network scenario; the third way is based on different default values ​​preset according to data resource type, such as a default waiting time of 500 milliseconds in a live streaming scenario to prioritize the first frame speed, 1000 milliseconds in a short video scenario, and 2500 milliseconds in a long video scenario to fully utilize the bandwidth advantage of the first data source. This default wait parameter ensures that even in extreme cold start scenarios where the terminal is used for the first time and there is no historical experience accumulated in any scenario, the playback startup process can still be executed normally without being stopped due to the lack of scheduling parameters.

[0076] By using a preset default waiting parameter as the waiting parameter for this data request when no sufficient historical experience is obtained in the three-level matching, a reliable fallback mechanism is provided for extreme cold start or scenarios with no available experience. This enables the terminal to execute the scheduling interaction of this data request in various scenarios without getting stuck in decision-making stagnation due to lack of available experience.

[0077] In some embodiments, performing a matching operation in the historical experience base includes: mapping the scene features to candidate scene buckets according to a discrete dimension, and matching corresponding historical scheduling experience information in the candidate scene buckets; wherein the discrete dimension includes one or more of the network type, the location category, and the city level; or calculating a matching index value between the scene features and the scene representations corresponding to each historical scheduling experience information, and performing matching based on the matching index value; wherein the matching index is any one of cosine similarity, weighted Euclidean distance, rule score, or hierarchical distance; or first performing candidate filtering according to the discrete dimension, and then calculating the matching index value within the candidate range for matching; wherein different matching judgment conditions are used for different granularity levels.

[0078] For example, the first matching method is precise scene bucket matching based on discrete dimensions: the terminal maps the discrete dimensions (such as network type, location category, city level) in the current scene features to the corresponding scene buckets, and searches for experience units belonging to that scene bucket in the historical experience database. Different granularity levels correspond to different combinations of discrete dimensions. For example, the fine-grained level uses a combination of network type, location category, and city level, the medium-grained level uses a combination of network type and location category, and the coarse-grained level uses only network type. The terminal only needs to search within the scene bucket range corresponding to the current level, resulting in high matching efficiency and speed.

[0079] For example, the second matching method is based on continuous feature matching index values: when the number of candidate experience units obtained from discrete dimension mapping is small or the sample size is insufficient, the terminal calculates the matching degree between the complete scene representation vector of the current scene and the scene representation vector stored in each experience unit, and selects the experience unit with the highest matching degree as the matching result. Here, the matching degree measures the similarity or closeness between the current scene and historical scenes; a higher matching degree indicates a better match between the current scene and historical scenes. For indices such as cosine similarity and rule scoring, a larger value indicates a greater similarity and higher matching degree between the current scene and historical scenes. The terminal can directly use the index value as the matching degree, i.e., the candidate experience unit with the largest value is the matching result. For distance metrics such as weighted Euclidean distance and hierarchical distance, smaller values ​​indicate a closer similarity between the current and historical scenes, and a higher degree of matching. Terminals can convert the distance values ​​to their reciprocals or negative values ​​to achieve a matching score, ensuring that the converted score also adheres to the unified judgment logic of "larger values ​​indicate a better match," thus maintaining a consistent matching judgment method across different metric types. Alternatively, terminals can avoid this unified conversion and directly match based on the original output values ​​of various metrics. Specifically, when using cosine similarity, the candidate empirical unit with the largest value is selected as the matching result; when using weighted Euclidean distance, hierarchical distance, and other distance metrics, the candidate empirical unit with the smallest value is selected. Cosine similarity is suitable for measuring the directional consistency of two vectors and is insensitive to feature magnitude. Weighted Euclidean distance is suitable for scenarios where the importance of each dimension differs, highlighting the contribution of key dimensions through weights. Rule-based scoring is suitable for scenarios with complex scene matching logic, scoring combinations of dimensions using a pre-defined scoring rule table. Hierarchical distance is suitable for scenarios where scene dimensions have hierarchical relationships, calculating the matching score based on the distance of dimensions in the hierarchical tree.

[0080] For example, the third matching method is hybrid matching: first, candidate filtering is performed using discrete dimensions to narrow the matching range to empirical units within the same scene bucket, and then fine matching is performed within the candidate range by calculating the matching index value, which takes into account both the efficiency of scene bucket matching and the accuracy of similarity matching. At different granularity levels, the matching criteria used differ: Fine-grained scene constraints correspond to stricter matching conditions. For indicators like cosine similarity and rule scores, where higher values ​​indicate a better match, the fine-grained level requires the matching indicator value to reach or exceed a higher lower limit (e.g., a similarity score of 0.85 or higher). For indicators like weighted Euclidean distance and hierarchical distance, where lower values ​​indicate closer proximity, the fine-grained level requires the matching indicator value to be less than or equal to a lower upper limit (e.g., a distance less than a preset lower threshold). A successful match is only determined when the scene representations are highly similar or closely related, ensuring the accuracy of matching results in fine-grained scenes. As scene constraints are gradually relaxed, the matching criteria are correspondingly relaxed. For indicators where higher values ​​indicate a better match, the lower limit is gradually lowered (e.g., the medium-grained level requires a matching indicator value of 0.75 or higher, and the coarse-grained level requires 0.70 or higher). For indicators where lower values ​​indicate closer proximity, the upper limit is gradually relaxed (i.e., allowing larger distance values), making it easier to match usable experience in experience-sparse scenarios, achieving the design goal of progressively relaxing tolerance. The specific values ​​of the matching score and distance threshold mentioned above are for illustrative purposes only. The threshold settings differ for different indicator types. For example, for similarity-based indicators (such as cosine similarity), a higher matching score indicates a better match, and the threshold is set to the upper limit. For distance-based indicators (such as weighted Euclidean distance), a smaller distance value indicates a better match, and the threshold is set to the lower limit. The specific values ​​can be adjusted according to the actual business scenario, the type of indicator used, and the terminal configuration. This disclosure does not impose any limitations on this.

[0081] In some embodiments, the discrete dimensions are organized hierarchically as follows: the first level includes network type, location category, and city level; the second level includes network type and location category; and the third level includes network type. When mapping the scene features to candidate scene buckets, mapping is preferentially performed according to the discrete dimensions of the first level. If the matched historical scheduling experience information does not meet the preset availability conditions, the mapping is switched to the second and third levels step by step. Through the above discrete dimension hierarchical mapping mechanism, when the terminal performs multi-granularity matching, it first maps the scene features to the finest scene bucket for matching according to the fine-grained dimension combination (network type + location category + city level). If no experience unit that meets the preset availability conditions is found in the fine-grained scene bucket, it automatically degenerates to the medium-granularity level, remaps the scene bucket according to the dimension combination of network type + location category, and performs matching. If there is still no available experience, it further degenerates to the coarse-grained level, mapping the scene bucket only according to the network type and performing matching. The mapping and matching logic of each level is consistent, only the discrete dimension combination used is different, realizing a smooth transition from precise matching to loose matching.

[0082] By providing multiple matching implementation methods, including scene bucket filtering, matching index value calculation, and a combination of both, the matching operation can flexibly adapt to different terminal computing capabilities, storage structures, and real-time requirements. Among them, discrete dimension mapping can quickly narrow the matching range and improve matching efficiency, while matching index value calculation (including cosine similarity, weighted Euclidean distance, rule scoring, or hierarchical distance) can make fine comparisons within the candidate range and improve matching accuracy. The hybrid method combines the advantages of both. At the same time, by setting different matching degree judgment criteria for different granularity levels, it is ensured that the higher the granularity level, the stricter the matching criteria, and the lower the granularity level, the more lenient the matching criteria, which is consistent with the design logic of gradually loosening tolerance.

[0083] In some embodiments, the method further includes: when the scene features cannot be matched with the scene representation corresponding to any historical scheduling experience information in the historical experience base, or the sample size of the matched historical scheduling experience information is lower than a preset threshold, acquiring historical scheduling experience information of other refined scenes similar to the current scene as candidate reference information; weighting the candidate reference information according to scene similarity, experience freshness, and sample confidence, generating temporary scheduling parameters based on the weighting result, and using the temporary scheduling parameters as waiting parameters for this data request; after the data request ends, generating initial historical scheduling experience information for the current scene based on the actual feedback information of this request, and writing the initial historical scheduling experience information into the historical experience base for subsequent matching operations under the same or similar scenes.

[0084] For example, the above mechanism can be called a horizontal migration mechanism, which, together with the aforementioned vertical matching mechanism that progressively degenerates to coarse-grained levels, constitutes a multi-granularity matching scheme. Vertical degradation matching, when there is no usable experience at the fine-grained level of the current scenario, gradually relaxes the scenario constraint dimensions to obtain usable experience in a coarser-grained scenario space. Horizontal migration, on the other hand, when insufficient experience can be obtained from the current scenario itself (including its various degradation levels), searches for other fine-grained scenarios similar to the current scenario (e.g., scenarios with similar location categories or adjacent city levels under the same network type, or scenarios with similar historical performance indicators such as success rate, response time, and network stability of point-to-point data source requests). The experience from these similar scenarios is weighted and fused according to scenario similarity, experience freshness, and sample confidence to generate a temporary scheduling parameter for this request. The experience source for vertical degradation is historical data of the current scenario at different granularity levels, essentially experience of the same scenario at different levels of coarseness; while the experience source for horizontal migration is historical data from other fine-grained scenarios different from the current scenario, essentially cross-scenario knowledge transfer. After the data request is completed, the terminal generates initial historical scheduling experience information for the current scenario based on the actual feedback information from the request and writes it into the historical experience database. This allows subsequent identical or similar scenarios to directly match the experience information of the current scenario itself, without relying on lateral migration again. As the feedback samples of the current scenario gradually accumulate and the sample size increases, subsequent scheduling decisions are gradually dominated by the historical scheduling experience information of the current scenario itself. The experience from lateral migration is only used for temporary supplementation during cold starts or low-sample phases, thereby avoiding long-term interference from similar but not identical scenarios in the judgment of the current scenario.

[0085] When it is impossible to directly match historical scheduling experience information that meets the preset threshold, we can obtain historical scheduling experience information from other detailed scenarios similar to the current scenario as candidate reference information, and generate temporary scheduling parameters by weighting them according to scenario similarity, experience freshness and sample confidence. This can ensure that we can still obtain a scientific and reasonable scheduling basis in the absence of directly matching historical data.

[0086] Step 130: Based on the matched historical scheduling experience information, predict the waiting parameters corresponding to the main request of the first data source in this data request, and determine the start time of the backup request of the second data source and the first priority of the first data source and the second data source in the request start phase according to the waiting parameters.

[0087] After the terminal completes the matching operation and obtains historical scheduling experience information suitable for the current scenario, it does not directly decide whether to immediately use the second data source based on fixed rules. Instead, it first predicts the waiting parameters corresponding to the main request of the first data source in this data request based on the matched historical scheduling experience information, and then controls the start timing of the backup request of the second data source according to these waiting parameters. The waiting parameters are the core decision result of the terminal, which directly affects the interaction process of this data request; the first priority is the scheduling tendency derived from the waiting parameters, not a separate set of decision variables independent of the waiting parameters. The terminal reflects the scheduling tendency of the first priority through the length of the waiting parameters, the start time of the backup request of the second data source, and the degree of request concurrency.

[0088] In some embodiments, the waiting parameter is the waiting duration; predicting the waiting parameter corresponding to the main request of the first data source in this data request based on the matched historical scheduling experience information includes: directly outputting the waiting duration of this data request based on the matched historical scheduling experience information; or outputting an intermediate indicator related to the waiting duration based on the matched historical scheduling experience information, and calculating the waiting duration of this data request based on the intermediate indicator, wherein the intermediate indicator includes the estimated response time quantile of the first data source request or the estimated success rate level of the first data source request.

[0089] In other embodiments, the waiting parameter can also be represented as a backup request trigger threshold. In this case, the terminal does not directly predict the time length, but determines a data return threshold based on matched historical scheduling experience information. When the amount of data returned by the first data source master request during the waiting process does not reach this threshold, a backup request for the second data source is triggered. For example, based on historical experience of the average first-frame data return rate of the first data source in the current scenario, the terminal uses 70% of the data required for first-frame decoding as the backup request trigger threshold.

[0090] In another embodiment, the waiting parameter can also be expressed as a concurrency control strategy parameter. The terminal determines the concurrency rate ratio between the primary request from the first data source and the backup request from the second data source based on matched historical scheduling experience information. For example, in scenarios where historical experience indicates that the first data source has a slow response, the initial rate of the backup request from the second data source is configured to a lower level to reduce bandwidth contention, and then increased to the normal rate after the first data source times out. By providing various forms of waiting parameter embodiments, such as waiting duration, backup request trigger threshold, and concurrency control strategy parameters, the terminal can flexibly choose the specific form of the waiting parameter according to different scheduling control requirements.

[0091] In another embodiment, the waiting parameter can also be expressed as a switching condition. In this case, the terminal does not directly predict the duration, but determines the switching condition from the first data source to the second data source based on matched historical scheduling experience information. For example, switching to the second data source is triggered when the cumulative returned data volume of the first data source's main request within a preset time window is lower than a first data volume threshold; or, switching to the second data source is triggered when the completeness of consecutive segments in the data returned by the first data source's main request is lower than a preset completeness threshold; or, switching to the second data source is triggered when the current download rate of the first data source's main request is lower than a preset proportion of the playback bitrate and the duration exceeds a preset duration. By setting switching conditions, the terminal can proactively switch to the second data source when the actual transmission quality of the first data source no longer meets the playback requirements, avoiding impact on the playback experience due to continued waiting or use of low-quality data.

[0092] The historical scheduling experience information stores statistical values ​​of scheduling parameters for this scenario, including at least historical waiting time statistics (such as mean, median, or specific quantiles), historical first data source request success rate, and historical first data source average response time. In the direct output method, the terminal uses the waiting time statistics stored in the matched experience unit as the waiting time for this data request; for example, if the experience unit records a historical optimal waiting time of 1500 milliseconds for this scenario, the terminal directly outputs this value as the prediction result. In the intermediate indicator conversion method, the terminal first extracts intermediate indicators related to the waiting time from the experience unit, and then converts the intermediate indicators into waiting time using a preset conversion formula or mapping relationship. For example, the terminal obtains the estimated response time quantile of the first data source request from the experience unit (e.g., the 90th quantile of historical response time is 1200 milliseconds), and then multiplies this quantile by a preset safety factor (e.g., 1.2) to obtain the current waiting time of 1440 milliseconds; or the terminal obtains the estimated success rate level of the first data source request (e.g., success rate above 95% corresponds to level A, 80% to 95% corresponds to level B, and below 80% corresponds to level C), and then determines the current waiting time according to the preset waiting time mapping table corresponding to different levels, for example, level A corresponds to a waiting time of 1800 milliseconds, level B corresponds to a waiting time of 1200 milliseconds, and level C corresponds to a waiting time of 600 milliseconds. By providing two prediction methods—directly outputting the waiting time and converting it through intermediate indicators—the terminal can flexibly choose the prediction strategy based on the data format stored in the experience unit. Among them, the estimated response time quantile can effectively reflect the distribution characteristics of historical response times and avoid interference from extreme values, while the estimated success rate level can serve as a simplified indicator for quickly judging the quality of a scenario. The two methods complement each other, reducing the implementation complexity of the prediction algorithm in different scenarios.

[0093] In some embodiments, the waiting time is a dynamic value constrained by upper and lower limits; the upper and lower limits are configured based on one or more of the following factors: first frame latency target, service timeout threshold, network type, data resource type, and historical request success rate of the first data source.

[0094] Specifically, if the predicted waiting time is lower than the lower limit, the lower limit value is used; if the predicted waiting time is higher than the upper limit, the upper limit value is used; and if the predicted waiting time is between the upper and lower limits, the predicted value of the predicted waiting time itself is used.

[0095] The waiting time is not an unbounded value or a fixed constant, but is limited to a configurable range. These upper and lower limits ensure that the predicted waiting time is neither too short, causing the primary data source request to terminate prematurely before it has a chance to return data, nor too long, causing the first frame playback latency to exceed the user's acceptable range. For example, in one embodiment, the waiting time can be configured to be between 0 milliseconds and 5000 milliseconds, where 0 milliseconds indicates that the backup request from the second data source intervenes almost immediately, and 5000 milliseconds indicates that the terminal provides sufficient waiting time for the first data source. In another embodiment, the waiting time can be configured to be between 300 milliseconds and 3000 milliseconds, depending on business objectives. In yet another embodiment, it can be configured to be between 500 milliseconds and 5000 milliseconds. These ranges are examples, and the specific upper and lower limits can be adjusted according to the actual business scenario. The first frame latency target refers to the maximum time allowed from the occurrence of the trigger event to the terminal obtaining the first frame response data. The stricter the first frame latency target, the lower the upper limit of the waiting time should be set to avoid the first data source waiting time being too long and crowding out the first frame response time. The service timeout threshold refers to the maximum timeout time allowed for data requests. The upper limit of the waiting time should not exceed the service timeout threshold. The network type reflects the bandwidth and latency characteristics of the current network. In the case of wireless LAN, a longer upper limit can be set to make full use of the bandwidth advantage of the first data source. In the case of mobile network, a shorter upper limit can be set to quickly enable the second data source to ensure the first frame experience. The data resource type reflects the characteristics of the requested data (such as short video, long video, live stream, etc.). Different types have different sensitivities to first frame latency. Live streams and short videos are more sensitive to latency, while long videos can tolerate a slightly longer wait. The historical request success rate of the first data source reflects the availability of the first data source in this scenario. The higher the success rate, the higher the upper limit of the waiting time can be appropriately relaxed to prioritize the use of the first data source. The lower the success rate, the higher the upper limit of the waiting time should be appropriately tightened to quickly enable the second data source. Through the above upper and lower limit constraints, the terminal trims the predicted waiting time. If the predicted waiting time is lower than the lower limit, the lower limit value is taken; if the predicted waiting time is higher than the upper limit, the upper limit value is taken; if the predicted waiting time is between the upper and lower limits, the predicted value of the predicted waiting time itself is taken. This ensures that the final output waiting time is always within a reasonable range, taking into account both the utilization efficiency of the first data source and the first frame playback experience.

[0096] By providing two prediction methods—direct output of waiting time and conversion through intermediate indicators—the terminal can flexibly choose the prediction strategy based on the data format stored in the experience unit. The estimated response time quantile can effectively reflect the distribution characteristics of historical response time and avoid interference from extreme values, while the estimated success rate level can serve as a simplified indicator for quickly judging the quality of a scenario. The two methods complement each other, reducing the implementation complexity of the prediction algorithm in different scenarios.

[0097] In some embodiments, determining the first priority of the first data source and the second data source during the request initiation phase based on the waiting parameter includes: when the waiting time is greater than a first threshold, determining that the first priority is the first data source taking precedence, and delaying the initiation timing of the backup request for the second data source; when the waiting time is less than a second threshold, determining that the first priority is the second data source taking precedence, and initiating the backup request for the second data source earlier or immediately; when the waiting time is between the first threshold and the second threshold, determining that the first priority is a collaborative scheduling state between the first data source and the second data source.

[0098] Specifically, the first threshold and the second threshold are preset time thresholds used to divide the waiting time into three different numerical intervals, each corresponding to a scheduling preference. The first threshold is greater than the second threshold. When the waiting time is greater than the first threshold, it indicates that historical experience shows that it is worthwhile to give the first data source a longer waiting time in this scenario. Based on this, the system determines the first data source as the first priority, and the terminal delays the start time of the second data source backup request, giving the first data source more sufficient waiting time to obtain data from the first data source first. When the waiting time is less than the second threshold, it indicates that historical experience shows that even with waiting, it is difficult to obtain a timely response from the first data source in this scenario. Based on this, the system determines the second data source as the first priority, and the terminal starts the backup request for the second data source earlier or almost immediately to ensure the response speed of the first frame. When the waiting time is between the second threshold and the first threshold, it indicates that historical experience shows that the response time of the first data source is at a moderate level in this scenario. It is neither advisable to rely entirely on the first data source for too long, nor is it advisable to immediately downgrade to the second data source. Therefore, it is determined to be a state of coordinated scheduling between the first and second data sources. Within the waiting window, the terminal prioritizes waiting for the return from the first data source, while preparing the backup request for the second data source with a lower priority, so that the two requests form a concurrent and coordinated scheduling relationship.

[0099] By determining the priority of the first data source and the second data source based on the comparison between the waiting time and the preset threshold, the scheduling needs under different network environments and data request conditions can be flexibly met.

[0100] Step 140: Based on the waiting parameters, the startup timing, and the first priority, perform a coordinated scheduling interaction between the main request of the first data source and the backup request of the second data source to obtain response data.

[0101] After the terminal completes the prediction of waiting parameters, determination of the start time, and determination of the first priority, it executes the coordinated scheduling interaction between the primary request from the first data source and the backup request from the second data source according to the above decision results. Coordinated scheduling interaction refers to the request execution process in which the primary request from the first data source and the backup request from the second data source cooperate in both time and priority dimensions. The terminal does not decide which data source to use only after the waiting window expires; instead, within the waiting window, it prioritizes waiting for the primary request from the first data source to return data. Simultaneously, based on the start time and the determination of the first priority, it prepares or initiates the backup request from the second data source in different ways and at different times. This creates a coordinated relationship in the time dimension where the primary request waits first, and the backup request intervenes in sequence. Finally, the data source to be used is determined based on the return status of both requests. Through the above coordinated scheduling interaction, the terminal obtains the response data and completes the data request.

[0102] In some embodiments, the triggering event is a media content request triggering event; the scene feature is a scene feature of the media content request initiation phase; the first data source is a decentralized distributed data source, and the second data source is a centralized distribution data source; the response data is media content data; the step of performing coordinated scheduling interaction between the main request of the first data source and the backup request of the second data source to obtain response data according to the waiting parameter, the initiation timing, and the first priority includes: in the media content request initiation phase, determining the duration of the waiting window at least according to the waiting parameter, waiting for the main request of the decentralized distributed data source to return media content data within the waiting window, and controlling the initiation of the backup request of the centralized distribution data source according to the initiation timing to obtain the media content data.

[0103] Decentralized distributed data sources refer to data sources composed of multiple peer-to-peer nodes, which do not rely on a single central server for data distribution. Terminals can directly exchange data; peer-to-peer data sources are a typical implementation. Centralized distributed data sources refer to data sources managed and distributed uniformly by one or more centralized distribution nodes. Terminals obtain data by accessing these central nodes; content delivery networks (CDNs) are a typical implementation. The two types of data sources differ significantly in data distribution architecture, resource utilization, and cost structure. Decentralized distributed data sources typically have lower distribution costs but their stability is greatly affected by the number of nodes, while centralized distributed data sources typically have higher stability and service quality but higher distribution costs.

[0104] In some embodiments, the triggering event is a video playback triggering event; the scene feature is a scene feature of the video playback startup phase; the first data source is a peer-to-peer data source, and the second data source is a content delivery network data source; the response data is video playback data; the step of performing coordinated scheduling interaction between the main request of the first data source and the backup request of the second data source to obtain response data according to the waiting parameter, the startup timing, and the first priority includes: in the video playback startup phase, determining a waiting window according to the waiting parameter, waiting in the waiting window for the main request of the peer-to-peer data source to return video playback data, and controlling the initiation of the backup request of the content delivery network data source according to the startup timing to obtain the video playback data.

[0105] The duration of the waiting window is determined at least by the waiting parameters. The waiting window duration can be equal to the waiting duration in the waiting parameters, or it can be increased or decreased by a preset offset. The specific value of the preset offset can be configured in one or more of the following ways: fixed offset, such as increasing or decreasing the waiting duration by a fixed offset of 200 milliseconds; proportional offset, such as increasing or decreasing the waiting duration by a proportional offset of 10%; network type adaptive offset, such as increasing the offset by 300 milliseconds in a wireless LAN scenario to give the first data source more time to wait, and decreasing the offset by 200 milliseconds in a mobile network scenario to enable the second data source faster and ensure a good first-frame experience. Optionally, the starting point of the waiting window is the moment when the terminal initiates the main request to the first data source, and the ending point is the moment after the waiting window duration has elapsed from that moment. Within the waiting window, the terminal prioritizes waiting for the main request from the first data source to return data and does not initiate a formal data request to the second data source, so as to give the first data source sufficient response time and prioritize the data transmission advantages of the first data source. The initiation timing is the time point at which the second data source backup request is initiated, as determined in step 130 based on the waiting parameters. The terminal controls the initiation of the content delivery network data source backup request according to this initiation timing, such as initiating it when the waiting window expires, initiating it after completing the pre-connection before the waiting window expires, or initiating it concurrently with the first data source main request at a low priority. Through the above process, the terminal completes the coordinated scheduling of the first data source main request and the second data source backup request during the video playback initiation phase, and obtains the video playback data used for this video playback.

[0106] During the video playback startup phase, by determining the duration of the waiting window based on waiting parameters and prioritizing the return of video playback data from the main request of the peer-to-peer data source, while controlling the initiation of backup requests from the content delivery network data source according to the startup timing, the transmission advantages of the peer-to-peer network can be fully utilized, reducing the load pressure on the content delivery network and improving the smoothness and stability of video playback.

[0107] In some embodiments, the video playback trigger event includes any of the following: the user clicks the video play button, playback resumes after the user drags the playback progress bar, playback resumes after a network switch, or playback resumes after the application switches to the foreground. These four trigger events cover the most common initiation scenarios in video playback: user-initiated playback, data needs to be retrieved again at a new time position after dragging the progress bar, the original connection is interrupted after a network switch and data retrieval needs to be re-established, and playback needs to be resumed after the application switches from the background to the foreground. The terminal triggers the collaborative scheduling interaction for this data request when it detects any of the above events.

[0108] In some embodiments, the coordinated scheduling interaction between the main request of the first data source and the backup request of the second data source includes: initiating a main request of the first data source; waiting for the main request of the first data source to return data within the waiting window; if the data returned by the main request of the first data source within the waiting window meets the playback conditions, then playing the data returned by the first data source; if the main request of the first data source still does not meet the playback conditions when the waiting window is reached, then initiating a backup request of the second data source according to the start timing; and determining the final data source based on the return status of the main request of the first data source and the backup request of the second data source.

[0109] The process begins with the terminal initiating a primary request to the first data source and starting a waiting window timer with a specified length. Within this window, the terminal continuously monitors the data returned by the primary request and determines in real-time whether the returned data meets the playback conditions. If the data returned by the primary request meets the playback conditions within the waiting window, the terminal directly uses the data returned by the primary data source for playback, eliminating the need to initiate a backup request to the second data source. This fully utilizes the transmission advantages of the primary data source while saving bandwidth resources from the second data source. If the primary request to the first data source still does not meet the playback conditions when the waiting window timer expires, the terminal initiates a backup request to the second data source according to its startup timing and obtains data through the second data source. Subsequently, based on the actual return status of the primary request to the first data source and the backup request to the second data source, the terminal determines the final data source according to a comprehensive availability strategy. Through these steps, the terminal completes a full collaborative scheduling interaction process from request initiation, window waiting, condition judgment, backup activation, to final data source determination.

[0110] By initiating a main request and waiting for its return within a waiting window, while deciding whether to initiate a backup request and determine the final data source based on the return status, we can ensure that all available resources are fully utilized during the data request process, thereby improving the reliability and stability of the data request.

[0111] In some embodiments, initiating the backup request for the second data source according to the startup timing includes any of the following methods: Method 1: After the waiting window expires, the backup request for the second data source is formally initiated. This is the most basic method for initiating a backup request. The terminal only formally initiates a data request to the second data source after the waiting window timer expires, without performing any network operations related to the second data source beforehand. This method is the simplest to implement, consumes the least terminal resources, and is suitable for scenarios where the first data source can successfully return data in most situations, and the second data source is only used as a backup in a few cases.

[0112] Method 2 involves performing DNS resolution and Transport Layer Security (TLS) pre-connection for the second data source before the waiting window expires, and then formally initiating a backup request for the second data source when the waiting window expires. In this method, the terminal begins performing DNS resolution and TLS pre-connection handshake operations for the second data source before the waiting window expires (e.g., when a quarter of the waiting window remains), but does not send a formal data request yet. When the waiting window expires, the DNS resolution and pre-connection are complete, and the terminal can directly initiate a formal data request for the second data source on the established connection without waiting for the DNS resolution and handshake to complete, thus shortening the data return time after formal initiation to only the data transmission time. This method is suitable for scenarios with high requirements for first-frame latency, giving the first data source priority waiting time while minimizing the startup delay of the second data source.

[0113] Method 3 involves initiating a small-byte probe request for the second data source with low priority within the waiting window, and then increasing the request priority of the second data source when the waiting window expires. In this method, the terminal initiates a small-byte probe request (such as requesting the header information or the first few bytes of a data fragment) to the second data source with low priority within the waiting window (e.g., immediately after initiating the main request for the first data source) to assess the availability and response speed of the second data source. However, the terminal does not use the data returned by the second data source as playback data at this time. When the waiting window expires, if the first data source still does not meet the playback conditions, the terminal increases the request priority of the second data source to normal priority and continues to request subsequent data. This method assesses the availability of the second data source in advance through small-byte probes, and since the probe request has already established a connection and started transmission, the increased priority allows for faster acquisition of complete data.

[0114] Method 4 involves initiating a low-rate request for the second data source simultaneously with or after the main request for the first data source, and prioritizing the second data source request if the main request for the first data source fails to meet playback conditions. In this method, the terminal initiates a backup request for the second data source very quickly after initiating the main request for the first data source. However, this backup request operates at a low rate and low priority, consuming only a small amount of bandwidth and not affecting the data transmission of the main request for the first data source. If the main request for the first data source meets playback conditions within the waiting window, the terminal terminates or downgrades the request for the second data source. If the first data source still fails to meet playback conditions by the end of the waiting window, the terminal prioritizes the request for the second data source to normal priority and continues acquiring data. This method is suitable for scenarios where the stability of the first data source is uncertain and a backup channel needs to be established as early as possible, minimizing the data return delay when the second data source needs intervention.

[0115] The terminal selects from the above four initiation methods based on information such as the current network type, first frame latency requirements, and historical performance of the first data source. This allows the terminal to flexibly configure the backup request initiation strategy according to specific scenarios, achieving a balance between the utilization efficiency of the first data source and the first frame response speed.

[0116] In some embodiments, the playback conditions being met include any of the following: obtaining the data segment required to decode the first frame, obtaining the total amount of media data reaching a preset buffer threshold, or obtaining the amount of data required to meet a specified continuous playback duration; wherein the first data source and the second data source use the same or different standards for meeting the playback conditions.

[0117] The data segment required for first-frame decoding refers to the data returned by the data source containing a complete data unit sufficient to complete the first-frame decoding, such as a keyframe of a video and its dependent reference frame data. At this point, the terminal can begin decoding and displaying the first frame, achieving the fastest first-frame response. The preset buffer threshold is a threshold for the amount of buffer data set to ensure playback continuity. When the total amount of acquired media data reaches this threshold, even if subsequent data is briefly interrupted, the terminal can continue playing for a period of time using the buffered data, avoiding playback stuttering. The amount of data required to meet a specified continuous playback duration refers to the amount of acquired media data sufficient to support continuous playback for a preset duration (e.g., 2 seconds, 5 seconds, or 10 seconds). This condition falls between the first-frame decodeability and full buffering, ensuring both a good first-frame experience and playback continuity. Because peer-to-peer data sources and content delivery network (CDN) data sources differ in response paths, stability, and subsequent data supply capabilities, they can use the same or different standards to meet playback conditions. For example, content delivery network (CDN) data sources typically have more stable subsequent supply capabilities and can use lower threshold standards (such as considering playback conditions met if the first frame can be decoded). Peer-to-peer (P2P) data sources, on the other hand, are significantly affected by the online status of peer nodes and can require higher threshold standards (such as download speed exceeding the playback bitrate or reaching a high buffer threshold) before considering playback conditions met, ensuring sufficient data to support continuous playback after switching to a P2P data source. The terminal can independently determine whether each data source meets its corresponding playback condition standards based on the actual amount and characteristics of the returned data, obtaining separate results for whether the first and second data sources meet the playback conditions.

[0118] In some embodiments, the playback conditions met by the first data source side include: obtaining continuous data segments, download rate greater than playback bitrate, or reaching a first buffer threshold; the playback conditions met by the second data source side include: successful request, first packet return, first frame decodeable, or reaching a second buffer threshold, wherein the second buffer threshold is lower than the first buffer threshold.

[0119] The first buffer threshold is higher than the second, meaning that the peer-to-peer data source needs to accumulate more buffered data before being deemed to meet playback conditions. This compensates for potential instability in subsequent data supply from its peer-to-peer network. In contrast, the content delivery network (CDN) data source, with its stable server-side supply capabilities, only requires a lower buffer threshold to be deemed to meet playback conditions. These different standards fully reflect the differences in transmission characteristics and stability between peer-to-peer and CDN data sources, enabling terminals to make more reasonable judgments when switching or selecting data sources.

[0120] By defining multiple scenarios that meet the playback conditions, it can flexibly adapt to scheduling requirements under different video playback needs and scene characteristics.

[0121] In some embodiments, determining the final data source based on the return status of the primary request from the first data source and the backup request from the second data source includes: If only the first data source meets the playback conditions, then the first data source is determined to be the final data source; If only the second data source meets the playback conditions, then the second data source is determined to be the final data source; If both the first data source and the second data source meet the playback conditions, the final data source is determined according to the comprehensive availability strategy. The comprehensive availability strategy is based on one or more of the following factors: first frame satisfaction time, current data acquisition ratio, subsequent continuous supply capability, stability of the first data source, stability of the second data source, data transmission cost, terminal power consumption, network type, and buffered data volume.

[0122] The comprehensive availability strategy is a multi-factor comprehensive scoring or decision-making strategy. When both data sources meet the playback conditions, the terminal needs to comprehensively consider the following factors: first frame fulfillment time (which data source meets the playback conditions earlier), the proportion of currently acquired data (the proportion of data acquired by the main request to the data required to meet the playback conditions; the higher the proportion, the lower the switching cost), subsequent continuous supply capability (whether the data source can continuously provide subsequent data), stability of the first data source (the stability of the first data source based on historical statistics in the current scenario), stability of the second data source (the stability of the second data source in the current network environment), data transmission cost (resource consumption or fees incurred in acquiring data: for the first data source, its data transmission cost includes network resource consumption incurred in data exchange between terminals; for the second data source, its data transmission cost includes bandwidth fees or service fees incurred in acquiring data from the content delivery network), terminal power consumption (the power consumption that may increase in maintaining the connection of the first data source), network type (whether the current network is a wireless LAN or a mobile network; the priority of data source selection differs under different networks), and buffered data volume (the amount of currently buffered data; the more buffered, the lower the requirement for the immediacy of subsequent data supply). The final data source is determined by comprehensively evaluating the weights and scores of the above factors.

[0123] In some embodiments, the comprehensive availability strategy includes: The first branch strategy determines whether the following conditions are met: the first frame satisfaction time of the first data source is no later than that of the second data source; the proportion of data currently acquired by the first data source meets the data proportion required for continuous playback; and the stability of the first data source meets the requirements. If the first condition is met, the first data source is determined to be the final data source. This branch strategy corresponds to the scenario where the first data source is no slower than the second data source in response speed, the amount of acquired data is sufficient to support continuous playback, and the stability of the first data source meets preset requirements. Under this first condition, the first data source performs well in the three dimensions of first frame speed, continuous playback guarantee, and stability. The terminal determines the first data source as the final data source to prioritize its use and reduce data transmission costs.

[0124] The second branch strategy, if the first condition is not met, then determines whether the second condition is met: the first frame fulfillment time of the second data source is earlier than that of the first data source, and the subsequent continuous supply capacity of the first data source is insufficient; if the second condition is met, then the second data source is determined to be the final data source. This branch strategy corresponds to the scenario where the second data source can fulfill the first frame playback condition earlier than the first data source, and the subsequent continuous supply capacity of the first data source is insufficient to guarantee continuous playback. Under this second condition, although the first data source may also meet the playback condition, the second data source is superior to the first data source in both first frame speed and subsequent supply stability. The terminal determines the second data source as the final data source, prioritizing the first frame experience and playback continuity.

[0125] If the first and second conditions are not met, then further judgment is made: The third branch strategy involves maintaining both the first and second data sources if the data transmission cost is below a cost threshold, the terminal power consumption is below a power threshold, and the network type is a wireless LAN. This continues until the buffered media data volume reaches a safety threshold, at which point the second data source's data link is released. This strategy is applicable to scenarios where data transmission costs are low (e.g., the data transmission cost of the first data source is typically close to zero, and the cost of the second data source is acceptable due to service provider discounts or free data policies), the terminal has sufficient power, and the current network is a wireless LAN (with sufficient bandwidth and no mobile data charges). Under these conditions, the terminal maintains both the first and second data sources, using the second data source as a redundant backup to reduce the risk of playback interruption. Once the buffered media data volume reaches a safety threshold (e.g., the buffered data can support more than 10 seconds of continuous playback), the second data source's data link is released, and only the first data source is maintained to save on data transmission costs.

[0126] The fourth branch strategy prioritizes the data source with the lowest data transmission cost over the first data source if the data transmission cost is not lower than the cost threshold, the terminal power consumption is not lower than the power consumption threshold, or the network type is not a wireless LAN. If the difference between the data transmission costs of the first and second data sources is less than a preset difference threshold, the data source with the lowest terminal power consumption is selected as the final data source. This branch strategy is applicable to scenarios where data transmission costs are high, terminal power is insufficient, or the current network is a mobile network, or other resource-constrained situations exist. Under these conditions, the terminal uses data transmission cost as the first comparison dimension. Since the data transmission cost of the first data source (peer-to-peer data source) is usually zero or extremely low, while the data transmission cost of the second data source (content delivery network data source) is usually positive, this rule will prioritize the first data source in most cases. If the cost difference between the two is very small (less than the preset difference threshold), it indicates that the cost factor is insufficient as a decisive factor, and the data source with the lowest terminal power consumption is selected instead. Typically, the content delivery network data source does not need to maintain a peer-to-peer connection, resulting in lower power consumption. This fourth branch strategy, as the reverse conditional fallback strategy of the third branch strategy, ensures that the terminal can make a clear and reasonable final data source selection based on the comprehensive availability strategy, regardless of cost, power, and network conditions.

[0127] Through the above four-branch strategy, when both data sources meet the playback conditions, the terminal can automatically match the corresponding branch decision based on the real-time status and preset thresholds of multiple factors such as the first frame satisfaction time, the proportion of acquired data, the subsequent continuous supply capability, the stability of dual sources, data transmission cost, terminal power consumption, network type, and buffer data volume, to complete the comprehensive availability decision and determine the final data source.

[0128] By comprehensively considering various factors such as the first frame satisfaction time, the proportion of currently acquired data, the ability to continuously supply data, the stability of the data source, the data transmission cost, the terminal power consumption, the network type, and the amount of buffered data, the final data source is determined, which can ensure that the optimal data source can be selected for video playback in various complex scenarios.

[0129] In some embodiments, the method further includes: monitoring the data return progress of the main request of the first data source within the waiting window; if the proportion of the amount of data returned by the main request of the first data source within the waiting window to the amount of data required to meet the playback conditions exceeds a preset proportion threshold, then extending the duration of the waiting window and delaying the start time of the backup request of the second data source; if the main request of the first data source is detected to have failed or timed out before the waiting window expires, then terminating the waiting window in advance and immediately initiating the backup request of the second data source.

[0130] The preset percentage threshold is a threshold for determining whether to extend the waiting window based on the data return progress. For example, the extension mechanism is triggered when the proportion of returned data to the amount of data required to meet playback conditions exceeds the preset percentage threshold. The specific value of the preset percentage threshold can be configured according to the scenario type and the historical performance of the first data source. For example, in a stable network scenario with a high historical success rate of the first data source, the preset percentage threshold can be configured to 70% to trigger the extension mechanism as early as possible when the data return progress is good; in a normal network scenario, the preset percentage threshold can be configured to 80% to trigger the extension mechanism when the data return progress is high; in a weak network scenario with a low historical success rate of the first data source, the preset percentage threshold can be configured to 90% to trigger the extension mechanism only when the data return progress is close to completion, avoiding excessive waiting for the poorly performing first data source. At this point, it means that the first data source has transmitted most of the data, and only a small amount of data remains to meet the playback conditions. If the system switches to the second data source at this moment due to the expiration of the waiting window, most of the transmitted data will be wasted, and the terminal will need to re-obtain data from the second data source, which will increase the first frame latency and bandwidth consumption. Therefore, the terminal extends the waiting window (e.g., by 50% of the original waiting time) and correspondingly delays the initiation of the second data source backup request, giving the first data source a chance to complete the remaining data. When the main request from the first data source fails (e.g., returns an error response) or times out (e.g., no data is received within a preset time), it indicates that the first data source cannot successfully return data in this scenario, and continuing to wait will only increase latency. Therefore, the terminal terminates the waiting window early and immediately initiates the second data source backup request to avoid unnecessary waiting. The above two dynamic adjustment mechanisms, positive extension and negative truncation, enable the waiting window to adapt to the data return progress.

[0131] By monitoring the data return progress of the main request within the waiting window and dynamically adjusting the duration of the waiting window and the timing of the backup request start based on the actual situation, the data request process can be made more flexible, intelligent, and efficient.

[0132] In some embodiments, after acquiring the response data, the method further includes: collecting actual feedback information of the current request during or after the current data request; the actual feedback information includes one or more of the following: the actual waiting time, whether the main request of the first data source successfully returned data within the waiting window corresponding to the waiting parameter, the actual response time of the main request of the first data source, whether the backup request of the second data source was successful, the final data source used, the first frame consumption time, and the playback interruption or switching result; calculating a better target waiting parameter in the current scenario based on the actual feedback information; and updating the historical scheduling experience information corresponding to the current scenario in the historical experience base based on the target waiting parameter.

[0133] Specifically, the terminal records the timestamps and result status of key events in real time during this data request process, and summarizes them to form complete actual feedback information after the data request ends. The actual feedback information includes, but is not limited to: the actual waiting time (i.e., the time between initiating the main request for the first data source and actually determining the final data source), whether the main request for the first data source successfully returned data within the waiting window (used to assess the accuracy of the waiting time prediction), the actual response time of the main request for the first data source (used to quantify the true response speed of the first data source in the current scenario), whether the backup request for the second data source was successful (used to assess the availability of the second data source), the final data source used (used to analyze which data source is more advantageous in this scenario), the first frame latency (i.e., the complete latency from triggering the event to obtaining the first frame response data, a core indicator for measuring user experience), and the playback interruption or switching result (used to identify whether stuttering or data source switching occurred during playback). The terminal uses the above feedback results to calculate a better target waiting parameter in the current scenario. This target waiting parameter represents: the better waiting parameter in this scenario after correction based on this actual feedback. Subsequently, the terminal updates the historical scheduling experience information corresponding to the current scenario in the historical experience base according to the target waiting parameter. Specifically, it updates the waiting parameter statistics in the experience unit, increments the cumulative sample size by one, and updates the last update timestamp.

[0134] By collecting actual feedback information during or after the data request process and calculating better target waiting parameters based on this information to update the historical scheduling experience information in the historical experience database, the historical scheduling experience information can be made closer to the actual scenario and changes in demand.

[0135] In some embodiments, calculating the optimal target waiting parameter in the current scenario based on the actual feedback information includes: if the main request of the first data source successfully returns data within the waiting window, then calculating the target waiting parameter based on the actual response time of the first data source; wherein the target waiting parameter is equal to the actual response time multiplied by a safety factor, or equal to the response time quantile of the first data source plus a safety margin; if the main request of the first data source fails to meet the playback conditions within the waiting window, then determining the adjustment method of the target waiting parameter based on the data return status of the first data source within the waiting window. Thus, by using the actual response time or actual data return status of the current request as the basis for calculating the target waiting parameter, compared to methods based on fixed rules or empirical estimation, the calculated target waiting parameter can more accurately reflect the true response capability of the first data source in the current scenario, thereby providing more accurate waiting time predictions in subsequent similar scenarios, reducing invalid waiting or premature switching due to prediction deviations, and improving the adaptability between scheduling decisions and actual scenarios.

[0136] In this context, "the first data source successfully returns data within the waiting window" means that the first data source has returned sufficient data to meet the playback conditions before the waiting window times out. In this case, the actual response time of the first data source is less than or equal to the predicted waiting time, indicating that the predicted waiting time is sufficient, or even potentially longer. In this scenario, the target waiting parameter can be calculated based on the actual response time, serving as a basis for correcting subsequent waiting time predictions in this scenario. Specifically, the target waiting parameter T_target equals the actual response time t_p2p multiplied by the safety factor k. An example formula for the target waiting parameter is: T_target = clamp(t_p2p) The target waiting parameter is defined as follows: k, T_min, T_max), where clamp() is the clipping function, T_min is the lower limit of the waiting parameter, and T_max is the upper limit of the waiting parameter. The safety factor k is a preset coefficient greater than 1 (e.g., 1.1 or 1.2), used to add a certain safety margin based on the actual response time to avoid the next prediction waiting time being too aggressive, causing the first data source to be terminated prematurely before it has a chance to return data. Alternatively, the target waiting parameter is equal to the quantile value of the first data source response time plus the safety margin, that is, obtaining a specific quantile value of the first data source response time from historical experience, plus a preset safety margin to cover the normal fluctuations in response time.

[0137] If the main request from the first data source fails to meet the playback conditions within the waiting window (including complete failure of the main request, timeout without returning any data, or insufficient returned data), it indicates that the predicted waiting time is too short, or the actual performance of the first data source in this scenario is poor. The terminal needs to determine the adjustment method of the target waiting parameter based on the data returned by the first data source within the waiting window. The terminal limits the calculated target waiting parameter within a preset upper and lower limit range to ensure that the updated waiting parameter does not exceed a reasonable value range.

[0138] In some embodiments, determining the adjustment method of the target waiting parameter based on the data return status of the first data source within the waiting window includes: If the primary request from the first data source does not return any data or returns an error response within the waiting window, shorten the target wait parameter; or If the main request from the first data source has returned data within the waiting window, but the amount of returned data does not meet the playback conditions, and the proportion of the returned data to the amount of data required to meet the playback conditions exceeds a preset threshold, then the target waiting parameter is maintained or increased; or If the main request of the first data source has returned data within the waiting window, but the amount of returned data does not meet the playback conditions, and the proportion of the returned data to the amount of data required to meet the playback conditions does not exceed the preset proximity threshold, then the target waiting parameter is shortened.

[0139] In the first scenario, if the primary request from the first data source does not return any data or returns an error response within the waiting window, it indicates that the first data source may be completely unavailable or have a serious fault in this scenario. The terminal adjusts the target waiting parameter to a shorter duration, for example, by setting the target waiting parameter T_target to the current waiting time T_used multiplied by a decay coefficient r less than 1 (such as 0.7 or 0.8), i.e., T_target = clamp(T_used). r, T_min, T_max), where r<1, enable the terminal to start the backup request for the second data source faster in subsequent similar scenarios, avoiding the impact on the first frame experience due to invalid waiting again.

[0140] In the second scenario, if the primary request from the first data source has returned data within the waiting window, but the amount of returned data is insufficient to meet the playback conditions, and the proportion of returned data to the amount of data required to meet the playback conditions exceeds a preset proximity threshold, it indicates that the first data source has transmitted the vast majority of data within the waiting window, and the playback conditions were not fully met only due to a slightly shorter waiting time. The specific value of the preset proximity threshold can be configured based on the historical performance of the first data source and the network scenario. For example, in a wireless LAN scenario where the first data source has historically high stability, the preset proximity threshold can be configured to 70% to trigger the maintenance or increase of the waiting parameter when the data return progress is good; in a normal network scenario, the preset proximity threshold can be configured to 80% to trigger adjustment when the data return progress is high; in a weak network scenario where the first data source has historically low stability, the preset proximity threshold can be configured to 90% to trigger adjustment only when the data return progress is close to completion, avoiding excessive waiting for the unstable first data source. If the terminal simply treats this scenario as a failure and shortens the waiting time, it may switch to the second data source earlier in the next scenario due to a shorter waiting time, resulting in wasted data from the first data source that could have been successfully acquired, thus increasing data transmission costs. Therefore, the terminal maintains or increases the target waiting parameter (for example, by multiplying the current waiting parameter by a coefficient greater than 1, or by adding a preset increment, such as 200 milliseconds), so that the first data source in subsequent similar scenarios has more time to complete data transmission.

[0141] In the third scenario, if the main request from the first data source has returned data within the waiting window, but the amount of returned data is insufficient to meet the playback conditions, and the proportion of the returned data to the amount of data required to meet the playback conditions does not exceed a preset threshold (e.g., below 80%), it indicates that the actual transmission speed of the first data source in this scenario differs significantly from the expected speed. Even with a longer waiting time, it is difficult to meet the playback conditions within an acceptable latency. In this case, the terminal adjusts the target waiting parameter to a shorter value to prioritize the response speed of the first frame.

[0142] Through the above classification process, the terminal can distinguish between three different situations: "the first data source has truly failed," "the waiting time is slightly shorter, resulting in data close to being satisfied," and "the actual transmission speed is significantly lower than expected," and adjust the target waiting parameters according to the actual situation.

[0143] In some embodiments, updating the corresponding historical scheduling experience information in the historical experience base according to the target waiting parameter includes: obtaining the cumulative sample size recorded in the historical scheduling experience information; determining the update step size according to the cumulative sample size; wherein, the lower the cumulative sample size, the larger the update step size; updating the waiting parameter in the historical scheduling experience information using a weighted average method, wherein the updated waiting parameter is equal to the target waiting parameter multiplied by the update step size, plus the waiting parameter before the update multiplied by one minus the update step size.

[0144] The cumulative sample size refers to the total number of valid samples recorded since the creation of the experience unit, reflecting its statistical reliability. A lower cumulative sample size indicates a weaker statistical foundation for the experience unit, requiring each new feedback to have a greater impact on the correction of the experience value, enabling the terminal to quickly learn and adapt to the current scenario. Conversely, a higher cumulative sample size indicates that the experience unit has accumulated sufficient statistical information, its experience value tends to be stable, and each new feedback only requires minor adjustments. Therefore, the terminal determines the update step size based on the cumulative sample size, which is inversely proportional to the cumulative sample size. The terminal updates the waiting parameters in the experience unit using a weighted average method. The updated waiting parameter T_new equals the target waiting parameter T_target multiplied by the update step size alpha, plus the original waiting parameter T_old multiplied by the update step size (1 - alpha). An example formula for the updated waiting parameter is: T_new = (1 - alpha) T_old +alpha T_target. Through the weighted average update method described above, the waiting parameters of the experience unit are gradually optimized and converged as feedback samples accumulate. Furthermore, experience units with larger sample sizes are less affected by single abnormal feedback, ensuring the stability and reliability of the experience base during long-term operation. Here, alpha is the update step size, i.e., the dynamic learning rate, which can decrease as the sample size increases. For example, a larger value is used in the low-sample stage for rapid learning, and a smaller value is used in the high-sample stage for stable fine-tuning. The above formula is only an example; specific update methods can use EMA (Exponential Moving Average), recursive statistics, quantile updates, or other online update methods. In addition to the sample size, alpha can also be adjusted based on prediction error, scene matching similarity, freshness, sample quality, and scene stability. When the matching degree is low or the sample quality is low, the weight of ordinary updates to the original experience can be reduced; however, if low matching or large errors occur consecutively, drift detection or a fast learning branch can be triggered, thereby adapting to the new scene by resetting the confidence level, reducing the sample size, or entering a fast update stage.

[0145] By using a weighted average method to update the waiting parameters in historical scheduling experience information and determining the update step size based on the cumulative sample size, the updated waiting parameters can be made more stable, reliable, and representative.

[0146] In some embodiments, the update step size is also dynamically adjusted based on one or more of the following factors: the magnitude of the current prediction error, the matching similarity between the current scene features and the scene representations corresponding to the matched historical scheduling experience information, the freshness of the historical scheduling experience information, and the sample quality.

[0147] The current prediction error refers to the absolute value of the difference between the predicted waiting parameter and the target waiting parameter obtained from the actual feedback. A larger prediction error indicates lower accuracy of the current historical scheduling experience information, requiring a larger update step size to accelerate the correction speed and allow the experience value to quickly approach the actual value. The matching similarity between the current scene features and the scene representations corresponding to the matched historical scheduling experience information reflects the reliability of the match. Higher similarity indicates a more accurate match, more reliable experience, and a smaller update step size. Lower similarity indicates a certain deviation between the current scene and historical experience, requiring a larger update step size to adapt to changes in the current environment more quickly. The freshness of historical scheduling experience information is measured by the time elapsed between the last update time of the experience unit and the current moment. Lower freshness indicates outdated experience that may not accurately reflect the true state of the current network environment; in this case, a larger update step size is needed to accelerate the elimination of old experience. When the sample quality is low, a smaller update step size is needed to reduce the impact of low-quality feedback on the experience value. By dynamically adjusting the update step size by comprehensively considering these factors, the update strategy of the experience unit becomes more refined and flexible, achieving an optimal balance between rapid learning and stable fine-tuning in different scenarios.

[0148] In some embodiments, before calculating the optimal target waiting parameter in the current scenario based on the actual feedback information, the method further includes: performing anomaly detection on the actual feedback information; if one or more of the following abnormal situations are detected, the actual feedback information is removed, downgraded, or marked as a risk signal: the network type changes during this data request; the user actively exits or the playback duration is less than a preset threshold; the terminal switches to the background; the player is interrupted by the service; a server-side anomaly causes the first data source and the second data source to become unavailable simultaneously; the response time exceeds a preset normal range.

[0149] The purpose of anomaly detection is to ensure that only feedback samples that can truly reflect the scheduling performance of the first and second data sources under normal scenarios are used for normal updates of the experience base, so as to avoid the experience base being contaminated or the prediction of waiting parameters deviating from normal values ​​due to abnormal interference. Specifically, if the network type changes during the data request process (e.g., switching from Wi-Fi to mobile network), the scenario characteristics corresponding to this feedback are no longer consistent with the scenario characteristics collected when the data request was initiated. Attributing this feedback to the original scenario would result in the data in the experience unit being mixed with performance under different network environments. Therefore, this feedback sample is removed or downweighted. If the user actively exits playback or the playback duration is extremely short (below the preset threshold, such as less than 3 seconds), the terminal may not have obtained enough data to evaluate the true performance of the first data source, and this sample is not statistically significant. If the terminal switches to the background or the player is interrupted by the service, the data request may have been manually aborted rather than due to a data source problem, and the feedback result cannot truly reflect the availability of the data source. If a server-side anomaly causes both the first and second data sources to become unavailable, the reason for this failure lies with the server rather than the data source selection strategy, and this sample cannot be used to correct scheduling parameters. If the response time exceeds the preset normal range (e.g., much greater than the historical maximum value), there may be a momentary network anomaly or statistical anomaly. This extreme value should not be used for normal experience updates. For detected abnormal samples, the terminal can remove them (completely exclude them from experience updates), reduce their weight (participate in updates with lower weights), or mark them as risk signals (record the reason for the anomaly but exclude them from experience updates for later analysis). Through the anomaly detection and cleaning mechanism, the terminal ensures the authenticity and reliability of feedback samples participating in experience updates, thus guaranteeing the data quality of the historical experience database.

[0150] In some embodiments, the method further includes: performing lifecycle management operations on historical scheduling experience information in the historical experience base; the lifecycle management operations include one or more of the following: persistently storing the historical scheduling experience information locally on the terminal; when the number of historical scheduling experience information in the historical experience base reaches the upper limit, discarding the historical scheduling experience information with the earliest creation time or the least recently used; cleaning up historical scheduling experience information with a sample size below the minimum sample threshold and a duration exceeding a preset duration threshold; applying freshness decay to historical scheduling experience information with a duration exceeding a preset freshness threshold, reducing its matching weight or confidence; applying a smoothing factor to the waiting parameter prediction results output by historical scheduling experience information with a sample size below the confidence smoothing threshold; when it is detected that the prediction error of the same historical scheduling experience information exceeds the error threshold multiple times consecutively, performing drift reset on the historical scheduling experience information.

[0151] Lifecycle management operations include one or more of the following: First, historical scheduling experience information is persistently stored locally on the terminal. Specifically, the terminal writes each experience unit from the historical experience database to its non-volatile storage medium (such as flash memory, solid-state drive, or embedded multimedia card) to prevent data loss after terminal restart or application shutdown. Persistent storage can take various forms, including but not limited to binary files, databases, key-value stores, or memory mirroring with periodic persistence. The terminal can perform persistent writing immediately after each experience unit update, or it can perform persistent writing in batches according to preset periods (such as every 5 minutes or every 10 new samples) to achieve a balance between data security and storage input / output overhead. When the terminal starts or the application initializes, the historical experience database data is loaded from the non-volatile storage medium into memory, restoring the experience state at the end of the last run, ensuring that learning results can be continuously accumulated between different running cycles.

[0152] Second, when the number of historical scheduling experience information in the historical experience database reaches its limit, the earliest created or least recently used historical scheduling experience information is evicted. Specifically, the terminal sets a maximum number of experience units in the historical experience database (e.g., a maximum of 500, 1000, or 5000 experience units) to prevent the database from expanding indefinitely and consuming excessive terminal storage resources. When the number of experience units in the database reaches this limit, if new experience units need to be added (e.g., generating initial historical scheduling experience information for the current scenario through horizontal migration), the terminal needs to evict one or more existing experience units to free up storage space. The eviction strategy can be to evict the earliest created experience unit (i.e., first-in, first-out principle); or it can be to evict the least recently used experience unit (i.e., least recently used principle). This strategy prioritizes retaining frequently matched active experiences and evicts infrequently matched experiences, thus allocating storage resources to high-frequency scenarios. The terminal supports the above eviction strategy by maintaining the creation timestamp or most recently accessed timestamp of the experience units.

[0153] Third, historical scheduling experience information with a sample size below the minimum sample threshold and an existence duration exceeding a preset duration threshold is cleaned up. Specifically, some experience units, although created, have not been hit or updated for a long time, and their cumulative sample size remains at a low level. The statistical reliability of such experience units is insufficient, and their long-term lack of use indicates that the scenario is not important in the terminal's usage pattern or no longer occurs. The terminal periodically (e.g., daily or weekly) scans the historical experience database and cleans up and deletes experience units that simultaneously meet both conditions: "cumulative sample size below the minimum sample threshold (e.g., less than 3 valid samples)" and "existence duration exceeding a preset duration threshold (e.g., not updated for more than 30 days)". This frees up storage space and keeps the experience database concise. Both conditions must be met simultaneously to trigger cleanup, avoiding the accidental deletion of newly created experience units that have not yet accumulated enough samples.

[0154] Fourth, freshness decay is applied to historical scheduling experience information whose existence duration exceeds a preset freshness threshold, reducing its matching weight or confidence. Specifically, the freshness of an experience unit reflects the validity of its experience information at the current moment. The longer the last update time of an experience unit is from the current moment, the less likely the scheduling parameters it records may accurately reflect the true state of the current network environment. When the existence duration of an experience unit (the length of time from its creation or last update time to the current moment) exceeds the preset freshness threshold, the terminal applies freshness decay to that experience unit, reducing its weight or confidence in the subsequent matching process. The specific implementation method of freshness decay is detailed in subsequent embodiments.

[0155] Fifth, a smoothing factor is applied to the waiting parameter prediction results output by historical scheduling experience information with a sample size below the confidence smoothing threshold. Specifically, when the cumulative sample size of an experience unit is low (e.g., less than 10 samples), its statistical results may fluctuate significantly due to insufficient samples. Directly using the waiting parameter statistics from this experience unit as the prediction result may lead to unstable scheduling decisions. The terminal applies a smoothing factor to the waiting parameter prediction results output by experience units with low sample sizes, that is, to bring their statistical values ​​closer to the global default waiting parameters or the experience values ​​of coarser-grained scenarios, in order to suppress the prediction fluctuations caused by small samples. The smoothing factor can be a weighting coefficient between 0 and 1. The lower the sample size, the larger the smoothing factor, and the more the prediction result tends to the default value or coarse-grained experience value. As the sample size gradually increases, the smoothing factor gradually decreases, and the prediction result is gradually dominated by the statistical value of the experience unit itself, realizing a smooth transition from the default value to the experience value.

[0156] Sixth, when the prediction error of the same historical scheduling experience information exceeds the error threshold multiple times consecutively, a drift reset is performed on that historical scheduling experience information. Specifically, after each time the terminal receives feedback and calculates the target waiting parameter, it compares the predicted waiting parameter with the target waiting parameter and calculates the error between the two. If the prediction error of the same experience unit exceeds the preset error threshold multiple times consecutively (e.g., 5 times consecutively), it is considered that the experience unit has "drifted," meaning that the network environment, resource distribution, or terminal usage pattern in this scenario has changed significantly, and the historically accumulated experience can no longer accurately reflect the current situation. At this time, if the old experience is continued to be used for scheduling decisions, it will lead to continuous prediction deviation and deterioration of the playback experience. Therefore, the terminal performs a drift reset operation on the experience unit.

[0157] In some embodiments, the freshness decay includes: during matching, multiplying the original similarity of historical scheduling experience information by a freshness weight, wherein the freshness weight decreases as the last update time of the historical scheduling experience information increases.

[0158] In some embodiments, the freshness weight is calculated using an exponential decay, linear decay, or piecewise decay method.

[0159] In some embodiments, the drift reset includes: comparing the predicted waiting parameter with the target waiting parameter obtained from feedback; if the error exceeds a preset error threshold and occurs multiple times consecutively, a drift reset is triggered; after triggering, one or more of the following operations are performed: reducing the confidence of the historical scheduling experience information, resetting the sample size to a smaller value, updating the waiting parameter to the most recent target value, clearing the consecutive error count, using a larger learning rate for rapid relearning in subsequent updates, or reverting to a coarser-grained historical scheduling experience information or the default waiting parameter.

[0160] By performing lifecycle management operations on historical scheduling experience information, including persistent storage, eviction of expired or low-quality data, cleaning up data that has not been updated for a long time, applying freshness decay, and smoothing out low-confidence data, it can be ensured that the data in the historical scheduling experience information database always maintains high quality, high availability, and high timeliness.

[0161] This disclosure addresses the technical problems of traditional technologies, such as the inability of fixed waiting windows or static rules to adapt to scene differences, lack of individual adaptation, and insufficient continuous optimization capabilities, by reconstructing the in-device request interaction process after a triggered event. In this disclosure, the terminal matches the current scene using a historical experience database and degrades to a coarser-grained scene when there is insufficient experience in a fine-grained scene. The terminal predicts waiting parameters based on current scene characteristics and historical experience, and uses these parameters to determine the first priority and the timing of backup request initiation, thereby controlling the request interaction process of the two data sources. The terminal performs online correction of the waiting window for subsequent similar scenes based on the success or failure and response time of the first data source. Furthermore, the terminal maintains long-term learning capabilities without introducing high resource overhead through lightweight experience unit storage and lifecycle management. Based on the above mechanism, this disclosure achieves the following beneficial effects: First, it transforms the request scheduling interaction after a triggered event from a fixed, static execution to an adaptive execution based on scene characteristics. When a triggered event occurs, the terminal collects the current scene characteristics, performs multi-granularity matching in the historical experience database based on the scene characteristics to obtain historical scheduling experience information adapted to the current scene, predicts the waiting parameters of the primary request of the first data source in this data request based on the matched historical scheduling experience information, and determines the start time and first priority of the backup request of the second data source based on the waiting parameters. This allows the waiting window length and the timing of backup request intervention to be dynamically adjusted according to scene changes, thereby shortening unreasonable waiting and improving the first frame response speed.

[0162] Second, it makes the first priority judgment and data source switching decision more closely aligned with the real-time environment of the terminal, improving request success rate and user experience. By determining the first priority based on waiting parameters, when the waiting time is greater than a first threshold, the first data source takes priority and the backup request start time is delayed; when the waiting time is less than a second threshold, the second data source takes priority and the backup request is started earlier or immediately; when the waiting time is between the first and second thresholds, it is in a collaborative scheduling state. This allows the terminal to automatically determine the scheduling preference and start strategy of the main request and backup request in different scenarios, and obtain response data by executing the collaborative scheduling interaction between the main request of the first data source and the backup request of the second data source, thereby improving the request success rate while ensuring response speed.

[0163] Third, by continuously refining the predicted waiting time through local historical feedback from the terminal, the scheduling interaction in similar scenarios possesses continuous self-learning and gradual optimization capabilities. During or after each data request, the terminal collects actual feedback information, including the actual waiting time, whether the primary request from the first data source successfully returned data within the waiting window, the actual response time of the first data source, whether the backup request from the second data source was successful, the final data source used, the first frame's latency, and playback interruption or switching results. Based on this actual feedback information, a better target waiting parameter for the current scenario is calculated. After determining the update step size according to the cumulative sample size, a weighted average method is used to update the historical scheduling experience information for the corresponding scenario in the historical experience database. This allows the waiting parameter in the experience unit to gradually converge towards the optimal value for that scenario as feedback samples accumulate, resulting in more accurate predictions of waiting parameters for subsequent identical or similar scenarios.

[0164] Fourth, multi-granularity scenario matching addresses the issues of cold start and lack of available experience in new scenarios. When the terminal performs multi-granularity matching in the historical experience database, it prioritizes matching based on fine-grained scenario constraints. When the sample size of historical scheduling experience information matched under fine-grained scenario constraints falls below a preset threshold, the granularity of the scenario constraints is gradually relaxed. For example, it degenerates from fine-grained constraints including network type, location category, and city level to medium-grained constraints including network type and location category, and then to coarse-grained constraints including only network type, until historical scheduling experience information that meets the preset usable conditions is obtained. If there is no usable experience at all levels, a preset default waiting parameter is used, thus ensuring that the terminal can provide usable scheduling basis for scheduling interaction in any scenario. In addition, when sufficient historical experience cannot be directly matched in the current scenario, the terminal can also obtain historical scheduling experience information from other fine-grained scenarios similar to the current scenario. Temporary scheduling parameters are generated by weighting according to scenario similarity, experience freshness, and sample confidence for this request. After the request ends, the initial historical scheduling experience information for the current scenario is generated based on the actual feedback and written into the historical experience database, further enriching the scheduling strategy in the cold start and low-sample stages.

[0165] Fifth, through lifecycle management, historical scheduling experience information is kept valid for a long time, reducing the probability of misscheduling caused by the expiration of old experience. The terminal performs lifecycle management operations on the historical scheduling experience information in the historical experience database, including persistent storage, eviction of the oldest or least used experience when the quantity reaches the limit, cleaning up low-sample and timed-out experience, applying freshness decay to old experience to reduce matching weight, applying a smoothing factor to low-sample experience output, and performing drift reset when the prediction error exceeds the error threshold multiple times in a row. This enables the historical experience database to automatically evict expired and low-quality data, suppress the continuous interference of old experience, smooth small sample fluctuations, and quickly respond to scene changes during long-term operation, maintaining the simplicity and effectiveness of the experience database under the limited storage and computing resources of the terminal.

[0166] Sixth, without adding any additional visible interactive controls, the overall interactive experience and system resource utilization efficiency after the event is triggered are optimized. All scheduling logic in this embodiment is executed automatically in the terminal background without requiring the user to manually configure any parameters or perform any additional operations. Furthermore, by prioritizing the use of the first data source, the bandwidth dependence on the second data source is reduced, and by reducing invalid waiting, the consumption of terminal power and network resources is reduced, achieving a dual improvement in user experience and system resource utilization efficiency.

[0167] All of the above technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0168] The data processing method provided in this disclosure, in response to a triggering event, acquires the current scene characteristics of the terminal, enabling scheduling decisions to perceive the real-time environmental state of the terminal. Based on the scene characteristics, a matching operation is performed in a historical experience database to obtain historical scheduling experience information adapted to the current scene, ensuring scheduling availability. Based on the matched historical scheduling experience information, the waiting parameters corresponding to the main request of the first data source in this data request are predicted, and the start time of the backup request of the second data source and the first priority of the first and second data sources during the request start phase are determined according to the waiting parameters, enabling the waiting window to be adaptively adjusted. Based on the waiting parameters, start time, and first priority, a collaborative scheduling interaction is performed between the main request of the first data source and the backup request of the second data source to obtain response data, achieving orderly coordination between the main request and the backup request in the time dimension. This disclosure, by acquiring the current scene characteristics of the terminal in response to a triggering event and performing a matching operation in a historical experience database based on the scene characteristics to obtain historical scheduling experience information adapted to the current scene, predicts the waiting parameters of the current data request, and performs collaborative scheduling interaction to obtain response data, transforms data request scheduling from fixed static execution to adaptive execution based on the terminal scene and historical feedback, thereby optimizing data request scheduling and improving data transmission efficiency.

[0169] To facilitate better implementation of the data processing method of this disclosure, this disclosure also provides a data processing apparatus. Please refer to... Figure 3 , Figure 3 This is a schematic diagram of the structure of a data processing apparatus provided in an embodiment of the present disclosure. The data processing apparatus 200 may include: Acquisition unit 210 is used to acquire the current scene features of the terminal in response to a trigger event; The matching unit 220 is used to perform a matching operation in the historical experience database according to the scene characteristics in order to obtain historical scheduling experience information that is compatible with the current scene. The first processing unit 230 is used to predict the waiting parameters corresponding to the main request of the first data source in this data request based on the matched historical scheduling experience information, and determine the start time of the backup request of the second data source and the first priority of the first data source and the second data source in the request start phase according to the waiting parameters. The second processing unit 240 is configured to perform a coordinated scheduling interaction between the main request of the first data source and the backup request of the second data source according to the waiting parameters, the startup timing and the first priority, so as to obtain response data.

[0170] In some embodiments, the scene features include one or more of the following dimensions: network type, signal strength, current time period, location category of the terminal, city level, success rate of the first data source request within a preset time window, average response time of the first data source within the preset time window, network stability, and density of connectable peer nodes.

[0171] In some embodiments, the matching unit 220 is configured to: perform matching based on the scene characteristics, prioritizing matching according to fine scene constraints; when the historical scheduling experience information matched under the fine scene constraints does not meet the preset availability conditions, gradually relax the granularity of the scene constraints until the historical scheduling experience information matched meets the preset availability conditions, so as to obtain historical scheduling experience information adapted to the current scene; wherein, the preset availability conditions include: the sample size of the matched historical scheduling experience information is not less than a preset threshold.

[0172] In some embodiments, the matching unit 220 is configured to progressively relax the granularity of scene constraints, including: performing a first-level matching according to fine-grained scene constraints that include at least the network type, the location category, and the city level; if the sample size of historical scheduling experience information matched under the fine-grained scene constraints is lower than a first threshold, then performing a second-level matching according to medium-grained scene constraints that include the network type and the location category; if the sample size of historical scheduling experience information matched under the medium-grained scene constraints is lower than a second threshold, then performing a third-level matching according to coarse-grained scene constraints that include the network type.

[0173] In some embodiments, the matching unit 220 is further configured to use a preset default waiting parameter as the waiting parameter for this data request if no historical scheduling experience information is obtained after performing third-level matching according to network type, or if the sample size of the matched historical scheduling experience information is still lower than a third preset threshold.

[0174] In some embodiments, the matching unit 220 is configured to: map the scene features to candidate scene buckets according to a discrete dimension, and match corresponding historical scheduling experience information in the candidate scene buckets; wherein the discrete dimension includes one or more of the network type, the location category, and the city level; or calculate a matching index value between the scene features and the scene representations corresponding to each historical scheduling experience information, and perform matching based on the matching index value; wherein the matching index is any one of cosine similarity, weighted Euclidean distance, rule score, or hierarchical distance; or first perform candidate filtering according to the discrete dimension, and then calculate the matching index value within the candidate range for matching; wherein different matching judgment conditions are used for different granularity levels.

[0175] In some embodiments, the waiting parameter is the waiting duration; the first processing unit 230 is configured to: directly output the waiting duration of the current data request based on the matched historical scheduling experience information; or output an intermediate indicator related to the waiting duration based on the matched historical scheduling experience information, and calculate the waiting duration of the current data request based on the intermediate indicator, wherein the intermediate indicator includes the estimated response time quantile of the first data source request or the estimated success rate level of the first data source request.

[0176] In some embodiments, the triggering event is a video playback triggering event; the scene feature is a scene feature of the video playback startup phase; the first data source is a peer-to-peer data source, and the second data source is a content delivery network data source; the response data is video playback data; the second processing unit 240 is configured to: determine a waiting window according to the waiting parameters during the video playback startup phase, wait preferentially for the main request from the peer-to-peer data source to return video playback data within the waiting window, and control the initiation of a backup request from the content delivery network data source according to the startup timing to obtain the video playback data.

[0177] In some embodiments, the first processing unit 230 is configured to: when the waiting time is greater than a first threshold, determine that the first priority is the first data source priority and postpone the start time of the backup request of the second data source; when the waiting time is less than a second threshold, determine that the first priority is the second data source priority and start the backup request of the second data source in advance or immediately; when the waiting time is between the first threshold and the second threshold, determine that the first priority is the first data source and the second data source in a coordinated scheduling state.

[0178] In some embodiments, the second processing unit 240 is configured to: initiate a main request for the first data source; wait for the main request of the first data source to return data within the waiting window; if the data returned by the main request of the first data source within the waiting window meets the playback conditions, then play the data returned by the first data source; if the main request of the first data source still does not meet the playback conditions when the waiting window is reached, then initiate a backup request for the second data source according to the start timing; and determine the final data source based on the return status of the main request of the first data source and the backup request of the second data source.

[0179] In some embodiments, the playback conditions include any of the following: obtaining the data segment required to decode the first frame, obtaining the total amount of media data that reaches a preset buffer threshold, or obtaining the amount of data required to satisfy a specified continuous playback duration. The first data source and the second data source may use the same or different standards to meet the playback conditions.

[0180] In some embodiments, the second processing unit 240 is configured to determine the final data source based on the return status of the main request from the first data source and the backup request from the second data source, including: If only the first data source meets the playback conditions, then the first data source is determined to be the final data source; If only the second data source meets the playback conditions, then the second data source is determined to be the final data source; If both the first data source and the second data source meet the playback conditions, the final data source is determined according to the comprehensive availability strategy. The comprehensive availability strategy is based on one or more of the following factors: first frame satisfaction time, current data acquisition ratio, subsequent continuous supply capability, stability of the first data source, stability of the second data source, data transmission cost, terminal power consumption, network type, and buffered data volume.

[0181] In some embodiments, the comprehensive availability strategy includes: Determine whether the first condition is met: the first frame satisfaction time of the first data source is not later than the first frame satisfaction time of the second data source, the current acquired data ratio of the first data source meets the data ratio required for continuous playback, and the stability of the first data source meets the requirements; if the first condition is met, then the first data source is determined to be the final data source. If the first condition is not met, then determine whether the second condition is met: the first frame of the second data source is satisfied earlier than the first frame of the first data source, and the subsequent continuous supply capacity of the first data source is insufficient; if the second condition is met, then determine the second data source as the final data source. If the first and second conditions are not met, then further judgment is made: If the data transmission cost is lower than the cost threshold, the terminal power consumption is lower than the power threshold, and the network type is a wireless LAN, then both the first data source and the second data source data links are retained until the buffered media data volume reaches a safety threshold, at which point the data link of the second data source is released; or If the data transmission cost is not lower than the cost threshold, or the terminal power consumption is not lower than the power threshold, or the network type is not a wireless LAN, then the data source with the lowest data transmission cost among the first data source and the second data source shall be selected as the final data source; if the difference between the data transmission costs of the first data source and the second data source is less than a preset difference threshold, then the data source with the lowest terminal power consumption shall be selected as the final data source.

[0182] In some embodiments, the second processing unit 240 is further configured to: monitor the data return progress of the main request of the first data source within the waiting window; if the proportion of the amount of data returned by the main request of the first data source within the waiting window to the amount of data required to meet the playback conditions exceeds a preset proportion threshold, extend the duration of the waiting window and postpone the start time of the backup request of the second data source; if the main request of the first data source is detected to have failed or timed out before the waiting window expires, terminate the waiting window in advance and immediately initiate the backup request of the second data source.

[0183] In some embodiments, the second processing unit 240 is further configured to: after acquiring response data, during or after the current data request process, collect actual feedback information of the current request; the actual feedback information includes one or more of the following: the actual waiting time, whether the main request of the first data source successfully returned data within the waiting window corresponding to the waiting parameter, the actual response time of the main request of the first data source, whether the backup request of the second data source was successful, the final data source used, the first frame consumption time, and the playback interruption or switching result; calculate a better target waiting parameter in the current scenario based on the actual feedback information; and update the historical scheduling experience information corresponding to the current scenario in the historical experience database based on the target waiting parameter.

[0184] In some embodiments, the second processing unit 240 is configured to calculate a better target waiting parameter in the current scenario based on the actual feedback information, including: if the main request of the first data source successfully returns data within the waiting window, then calculate the target waiting parameter based on the actual response time of the first data source; wherein the target waiting parameter is equal to the actual response time multiplied by a safety factor, or equal to the response time quantile of the first data source plus a safety margin; if the main request of the first data source fails to meet the playback conditions within the waiting window, then determine the adjustment method of the target waiting parameter based on the data return status of the first data source within the waiting window.

[0185] In some embodiments, the second processing unit 240 is configured to determine the adjustment method of the target waiting parameter based on the data return status of the first data source within the waiting window, including: shortening the target waiting parameter if the main request of the first data source does not return any data or returns an error response within the waiting window; or maintaining or increasing the target waiting parameter if the main request of the first data source has returned data within the waiting window but the amount of returned data does not meet the playback conditions, and the proportion of the returned data to the amount of data required to meet the playback conditions exceeds a preset proximity threshold; or shortening the target waiting parameter if the main request of the first data source has returned data within the waiting window but the amount of returned data does not meet the playback conditions, and the proportion of the returned data to the amount of data required to meet the playback conditions does not exceed the preset proximity threshold.

[0186] In some embodiments, the second processing unit 240 is configured to update the corresponding historical scheduling experience information in the historical experience base according to the target waiting parameter, including: obtaining the cumulative sample size recorded in the historical scheduling experience information; determining an update step size according to the cumulative sample size; wherein, the lower the cumulative sample size, the larger the update step size; and updating the waiting parameter in the historical scheduling experience information using a weighted average method, wherein the updated waiting parameter is equal to the target waiting parameter multiplied by the update step size, plus the waiting parameter before the update multiplied by one minus the update step size.

[0187] In some embodiments, the second processing unit 240 is further configured to: when the scene features cannot be matched with the scene representation corresponding to any historical scheduling experience information in the historical experience base, or when the sample size of the matched historical scheduling experience information is lower than a preset threshold, obtain historical scheduling experience information of other refined scenes similar to the current scene as candidate reference information; weight the candidate reference information according to scene similarity, experience freshness and sample confidence, generate temporary scheduling parameters according to the weighting result, and use the temporary scheduling parameters as waiting parameters for this data request; after the data request ends, generate initial historical scheduling experience information of the current scene according to the actual feedback information of this request, and write the initial historical scheduling experience information into the historical experience base for subsequent matching operations in the same or similar scenes.

[0188] In some embodiments, the second processing unit 240 is further configured to: perform lifecycle management operations on the historical scheduling experience information in the historical experience base; the lifecycle management operations include one or more of the following: persistently storing the historical scheduling experience information locally on the terminal; when the number of historical scheduling experience information in the historical experience base reaches the upper limit, eliminating the historical scheduling experience information with the earliest creation time or the least recently used; cleaning up historical scheduling experience information with a sample size lower than the minimum sample threshold and a duration exceeding a preset duration threshold; applying freshness decay to historical scheduling experience information with a duration exceeding a preset freshness threshold, reducing its matching weight or confidence; applying a smoothing factor to the waiting parameter prediction results output by historical scheduling experience information with a sample size lower than the confidence smoothing threshold; and performing drift reset on the historical scheduling experience information when the prediction error of the same historical scheduling experience information exceeds the error threshold multiple times consecutively.

[0189] Each unit in the aforementioned data processing device can be implemented entirely or partially through software, hardware, or a combination thereof. Each unit can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each unit.

[0190] The data processing device 200 can be integrated into a terminal or server that has storage and a processor and thus computing power, or the data processing device 200 can be the terminal or server.

[0191] Optionally, this disclosure also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0192] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this disclosure. The computer device may be a terminal or a server. Figure 4 As shown, the computer device 300 includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored in the memory 302 and executable on the processor. The processor 301 is electrically connected to the memory 302. Those skilled in the art will understand that the computer device structure shown in the figures does not constitute a limitation on the computer device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0193] The processor 301 is the control center of the computer device 300. It connects various parts of the computer device 300 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 302, and calling data stored in the memory 302, it performs various functions of the computer device 300 and processes data, thereby performing overall processing of the computer device 300.

[0194] In this embodiment of the disclosure, the processor 301 in the computer device 300 loads the instructions corresponding to the processes of one or more computer programs into the memory 302 according to the following steps, and the processor 301 runs the computer programs stored in the memory 302 to realize various functions: In response to a triggering event, the system acquires the current scene characteristics of the terminal; based on the scene characteristics, it performs a matching operation in the historical experience database to obtain historical scheduling experience information adapted to the current scene; based on the matched historical scheduling experience information, it predicts the waiting parameters corresponding to the main request of the first data source in this data request, and determines the start time of the backup request of the second data source and the first priority of the first data source and the second data source in the request start phase according to the waiting parameters, the start time, and the first priority; based on the waiting parameters, the start time, and the first priority, it performs a collaborative scheduling interaction between the main request of the first data source and the backup request of the second data source to obtain response data.

[0195] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0196] Optional, such as Figure 4 As shown, the computer device 300 also includes: a display screen 303, a radio frequency circuit 304, an audio circuit 305, an input unit 306, and a power supply 307. The processor 301 is electrically connected to the display screen 303, the radio frequency circuit 304, the audio circuit 305, the input unit 306, and the power supply 307. Those skilled in the art will understand that... Figure 4 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0197] The display screen 303 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The display screen 303 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the computer device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program. Optionally, the touch panel may include a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, and transmits the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, sends it to the processor 301, and can receive and execute commands from the processor 301. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 301 to determine the type of touch event. Subsequently, the processor 301 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the display screen 303 to achieve input and output functions. However, in some embodiments, the touch panel and the display screen 303 can be implemented as two independent components to achieve input and output functions. That is, the display screen 303 can also be used as part of the input unit 306 to achieve input functions.

[0198] The radio frequency circuit 304 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other computer devices, and to transmit and receive signals with network devices or other computer devices.

[0199] Audio circuitry 305 can be used to provide an audio interface between a user and a computer device via a speaker and a microphone. Audio circuitry 305 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 305, converted back into audio data, and output to processor 301 for processing. The audio data is then transmitted via radio frequency circuitry 304 to, for example, another computer device, or output to memory 302 for further processing. Audio circuitry 305 may also include an earphone jack to facilitate communication between peripheral headphones and the computer device.

[0200] The input unit 306 can be used to receive input numbers, characters, or object feature information (such as fingerprints, irises, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0201] Power supply 307 is used to supply power to various components of computer device 300. Optionally, power supply 307 can be logically connected to processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 307 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0202] although Figure 4 As not shown in the diagram, the computer device 300 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0203] This disclosure also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute corresponding processes in the data processing methods of the embodiments of this disclosure; for brevity, further details are omitted here.

[0204] This disclosure also provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding flow in the data processing method of the embodiments of this disclosure. For brevity, further details are omitted here.

[0205] This disclosure also provides a computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding flow in the data processing method of this disclosure; for brevity, further details are omitted here.

[0206] It should be understood that the processor disclosed herein may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0207] It is understood that the memory in the embodiments of this disclosure can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0208] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0209] Those skilled in the art will 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.

[0210] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0211] In the several embodiments provided in this disclosure, 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 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0213] In addition, the functional units in this disclosure 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.

[0214] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer or a server) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0215] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A data processing method, characterized in that, The method includes: In response to a triggering event, obtain the current scene characteristics of the terminal; Based on the scene characteristics, a matching operation is performed in the historical experience database to obtain historical scheduling experience information that is compatible with the current scene; Based on the matched historical scheduling experience information, the waiting parameters corresponding to the main request of the first data source in this data request are predicted, and the start time of the backup request of the second data source and the first priority of the first data source and the second data source in the request start phase are determined according to the waiting parameters. Based on the waiting parameters, the startup timing, and the first priority, a coordinated scheduling interaction is performed between the main request of the first data source and the backup request of the second data source to obtain response data.

2. The data processing method according to claim 1, characterized in that, The scene features include one or more of the following dimensions of information: Network type, signal strength, current time period, location category of the terminal, city level, success rate of the first data source request within the preset time window, average response time of the first data source within the preset time window, network stability, and density of connectable peer nodes.

3. The data processing method according to claim 2, characterized in that, The step of performing a matching operation in the historical experience database based on the scenario characteristics to obtain historical scheduling experience information adapted to the current scenario includes: Based on the scene characteristics, matching is prioritized according to the fine scene constraints; When the historical scheduling experience information matched under the fine scene constraints does not meet the preset availability conditions, the granularity of the scene constraints is gradually relaxed until the matched historical scheduling experience information meets the preset availability conditions, so as to obtain historical scheduling experience information that is compatible with the current scene. The preset availability conditions include: the sample size of matched historical scheduling experience information is not less than a preset threshold.

4. The data processing method according to claim 1, characterized in that, The waiting parameter is the waiting duration; the prediction of the waiting parameter corresponding to the main request of the first data source in this data request based on the matched historical scheduling experience information includes: Based on the matched historical scheduling experience information, directly output the waiting time for this data request; or Based on the matched historical scheduling experience information, an intermediate indicator related to the waiting time is output, and the waiting time of this data request is calculated based on the intermediate indicator. The intermediate indicator includes the estimated response time quantile of the first data source request or the estimated success rate level of the first data source request.

5. The data processing method according to claim 1, characterized in that, The triggering event is a video playback triggering event; the scene features are scene features of the video playback startup phase; The first data source is a peer-to-peer data source, the second data source is a content delivery network data source, and the response data is video playback data; The step of performing a coordinated scheduling interaction between the primary request of the first data source and the backup request of the second data source, based on the waiting parameters, the startup timing, and the first priority, to obtain response data, includes: During the video playback startup phase, a waiting window is determined based on the waiting parameters. Within the waiting window, priority is given to waiting for the main request from the peer-to-peer data source to return video playback data. The backup request from the content delivery network data source is initiated based on the startup timing to obtain the video playback data.

6. The data processing method according to claim 1, characterized in that, The method further includes: Perform lifecycle management operations on the historical scheduling experience information in the historical experience database; the lifecycle management operations include one or more of the following: The historical scheduling experience information is persistently stored locally on the terminal. When the number of historical scheduling experience information in the historical experience database reaches the upper limit, the historical scheduling experience information with the earliest creation time or the least recently used will be eliminated. Clean up historical scheduling experience information where the sample size is below the minimum sample threshold and the duration exceeds the preset duration threshold; Apply freshness decay to historical scheduling experience information that has a duration exceeding a preset freshness threshold, thereby reducing its matching weight or confidence. Apply a smoothing factor to the waiting parameter prediction results output by historical scheduling experience information with a sample size below the confidence smoothing threshold; When the prediction error of the same historical scheduling experience information exceeds the error threshold multiple times in a row, the historical scheduling experience information is drifted and reset.

7. A data processing apparatus, characterized in that, The device includes: The acquisition unit is used to acquire the current scene features of the terminal in response to the triggering event; The matching unit is used to perform a matching operation in the historical experience database according to the scene characteristics in order to obtain historical scheduling experience information that is compatible with the current scene. The first processing unit is used to predict the waiting parameters corresponding to the main request of the first data source in this data request based on the matched historical scheduling experience information, and determine the start time of the backup request of the second data source and the first priority of the first data source and the second data source in the request start phase according to the waiting parameters. The second processing unit is configured to perform a coordinated scheduling interaction between the main request of the first data source and the backup request of the second data source according to the waiting parameters, the startup timing, and the first priority, so as to obtain response data.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to perform the data processing method as described in any one of claims 1-6.

9. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program, and the processor executing the data processing method according to any one of claims 1-6 by calling the computer program stored in the memory.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the data processing method according to any one of claims 1-6.

Images