Short video preloading method, electronic device, storage medium and computer program product

Abstract

Embodiments of the present application relate to a short video preloading method, an electronic device, a storage medium and a computer program product. The method comprises: acquiring a sliding speed feature sequence of a user terminal in a short video playing process; determining a target preloading range according to the sliding speed feature sequence; and performing a preloading action according to the target preloading range. Embodiments of the present application dynamically determine the preloading range by acquiring the user sliding speed feature in real time, so that the preloading quantity is adaptively matched with the actual browsing speed of the user. When the sliding speed is fast, the preloading range is automatically expanded to avoid playing waiting; when the sliding speed is slow, the preloading range is automatically reduced to save bandwidth and memory resources. Thus, while improving the video switching fluency, the overloading or insufficient loading caused by the fixed preloading strategy can be avoided, the system resource utilization efficiency is effectively optimized, and the viewing experience of users with different sliding habits is improved.

Description

Technical Field

[0001] This application relates to the field of mobile internet video playback optimization technology, and in particular to a short video preloading method, electronic device, storage medium, and computer program product. Background Technology

[0002] In short video applications, users browse a large amount of video content by swiping up and down. Existing technologies typically employ a fixed-range preloading strategy, which preloads several video segments adjacent to the current video. However, this approach has several drawbacks. A fixed preloading range cannot adapt to different users' swiping habits, leading to playback delays for some users who swipe quickly, while wasting bandwidth and memory for others who swipe slowly. Furthermore, the preloading direction is singular, usually only preloading content after the current video; when users quickly swipe up to rewind, reloading is still required. Finally, it cannot predict user swiping intentions, lacking the ability to anticipate user pauses followed by continued swiping, resulting in a poor viewing experience. Summary of the Invention

[0003] To address the aforementioned issues, embodiments of this application provide a short video preloading method, an electronic device, a storage medium, and a computer program product.

[0004] According to a first aspect of the embodiments of this application, a short video preloading method is provided, the method comprising: Obtain the scrolling speed feature sequence of the user terminal during short video playback; The target preload range is determined based on the sliding speed characteristic sequence; Perform the preloading action according to the target preloading range.

[0005] In one embodiment, obtaining the scrolling speed feature sequence of the user terminal during short video playback includes: Collect multi-touch data of the user terminal during the sliding operation. The multi-touch event data includes the coordinates of the sliding start point, the coordinates of the sliding end point, and the corresponding timestamp. The sliding distance is calculated based on the coordinates of the sliding start point and the sliding end point, and the sliding time is calculated based on the timestamp. The average speed is calculated based on the sliding distance and the sliding time, and the instantaneous speed sequence is calculated based on multiple intermediate coordinate points within the sampling period to obtain the sliding speed feature sequence.

[0006] In one implementation, determining the target preload range based on the sliding velocity characteristic sequence includes: Extract statistical features from the sliding speed feature sequence, wherein the statistical features include at least one of average speed, maximum speed, speed variance, or speed trend; Calculate the speed correction coefficient and trend correction coefficient based on the statistical characteristics described above; The target number of preloaded videos is calculated based on the baseline number of preloaded videos, the speed correction factor, and the trend correction factor.

[0007] In one implementation, the speed trend includes an acceleration trend and a deceleration trend; When the speed trend is an accelerating trend, the trend correction coefficient is greater than 1, which is used to increase the preload weight in the current sliding direction; When the speed trend is a deceleration trend, the trend correction coefficient is less than 1, which is used to reduce the preload weight in the current sliding direction.

[0008] In one implementation, determining the target preload range based on the sliding velocity characteristic sequence includes: After filtering and denoising the sliding speed feature sequence, the statistical features of the sliding speed feature sequence are extracted. The statistical features include at least one of the following: average speed, maximum speed, speed variance, speed trend, single sliding duration and sliding distance. The speed trend is determined according to the sign of the acceleration feature, with positive values ​​indicating acceleration and negative values ​​indicating deceleration. The sliding speed feature sequence is input into a pre-trained sliding direction prediction model to output the sliding direction prediction result of the user at the next moment. The sliding direction prediction model includes a hidden Markov model or a long short-term memory network model. The prediction result includes the probability of sliding upward, the probability of sliding downward, and the probability of staying. The target preload range is determined based on the predicted sliding direction.

[0009] In one implementation, the long short-term memory network model includes: The input layer receives a sliding velocity feature sequence of length T; the first long short-term memory network layer contains 4N hidden units; the second long short-term memory network layer contains 2N hidden units; and the fully connected layer contains N neurons and uses the ReLU activation function, where N is a positive integer. The output layer uses the softmax function to output the probability distributions for the three directions: sliding up, sliding down, and staying.

[0010] In one implementation, the training steps of the long short-term memory network model include: Collect multiple historical swipe behavior data of the user to construct a speed sequence sample set, with each sample labeled with the corresponding actual swipe direction; The long short-term memory network model was trained using the cross-entropy loss function and the Adam optimizer. The trained model is quantized and compressed before being deployed to mobile devices.

[0011] In one implementation, determining the target preload range based on the sliding direction prediction result includes: When the probability of sliding downwards is greater than a first threshold, increase the number of preloaded videos in the downward direction; or When the upward sliding probability is greater than the second threshold, increase the number of preloaded videos in the upward direction; or When the probability of dwelling is greater than the third threshold, the preloading action is paused.

[0012] In one embodiment, the method further includes: Obtain device status parameters, including remaining memory and CPU utilization. When the remaining memory is below the memory threshold or the CPU utilization is above the load threshold, the target preload range is reduced.

[0013] In one embodiment, the method further includes: Obtain the current network status parameters, including network type and signal strength; When the network type is WiFi, the target preloading range is expanded; When the network type is a cellular network and the signal strength is below the signal threshold, the target preloading range is reduced.

[0014] In one implementation, determining the target preload range based on the sliding velocity characteristic sequence includes: Obtain the speed prediction score; Obtain at least one of the device status score, network status score, and user profile score; The preloaded fusion score is obtained based on at least one of the speed prediction score and the device status score, the network status score, or the user profile score. The target preloading range is determined based on the preloading fusion score.

[0015] In one implementation, performing the preloading action according to the target preloading range includes: Send a preload request to the content delivery network scheduler and / or video buffer manager, the preload request carrying a list of target videos; Video segments in the target video list are loaded in descending order of preloading priority, with video segments closer to the currently playing video having a higher preloading priority.

[0016] In one embodiment, the method further includes: When the number of cached videos on the user terminal exceeds the cache capacity, an elimination score is obtained for each cached video. The elimination score is calculated by weighting the video popularity, preloading priority, and most recent access time. Cached videos are eliminated in ascending order of their elimination scores, with the currently playing video and the most recently preloaded video having the highest elimination scores and thus being prohibited from being eliminated.

[0017] According to a second aspect of the embodiments of this application, an electronic device is provided, comprising: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method of any one of the first aspects.

[0018] According to a third aspect of the embodiments of this application, a non-transitory computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0019] According to a fourth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0020] The embodiments of this application achieve the following beneficial effects: This application provides a short video preloading method, including: acquiring a sliding speed feature sequence of a user terminal during short video playback; determining a target preloading range based on the sliding speed feature sequence; and performing a preloading action based on the target preloading range. This application dynamically determines the preloading range by acquiring user sliding speed features in real time, making the preloading quantity adaptively match the user's actual browsing speed. When the sliding speed is fast, the preloading range is automatically expanded to avoid playback waiting; when the sliding speed is slow, the preloading range is automatically reduced to save bandwidth and memory resources. Therefore, while improving the smoothness of video switching, it can avoid overloading or underloading caused by a fixed preloading strategy, effectively optimize system resource utilization efficiency, and improve the viewing experience for users with different sliding habits.

[0021] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a short video preloading method provided in an embodiment of this application.

[0023] Figure 2 This is a flowchart of a short video preloading method provided in an embodiment of this application.

[0024] Figure 3 This is a flowchart of a short video preloading method provided in an embodiment of this application.

[0025] Figure 4 This is a flowchart of a short video preloading method provided in an embodiment of this application.

[0026] Figure 5 This is a flowchart of a short video preloading method provided in an embodiment of this application.

[0027] Figure 6 This is a flowchart of a short video preloading method provided in an embodiment of this application.

[0028] Figure 7 This is a flowchart of a short video preloading method provided in an embodiment of this application.

[0029] Figure 8 This is a flowchart of a short video preloading method provided in an embodiment of this application.

[0030] Figure 9 This is a flowchart of a short video preloading method provided in an embodiment of this application.

[0031] Figure 10 This is a flowchart of a short video preloading method provided in an embodiment of this application.

[0032] Figure 11 This is a block diagram of an electronic device provided in one embodiment of this application. Detailed Implementation

[0033] The specific embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this application.

[0034] It should be understood that the term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description.

[0035] It should be noted that the concepts of "first" and "second" mentioned in this application are only used to distinguish different devices, modules, or units, and are not used to limit the order of functions performed by these devices, modules, or units or their interdependencies. The modifications of "one" and "multiple" mentioned in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless explicitly stated in the context, they should be understood as "one or more". In the description of this application, unless otherwise stated, "multiple" means two or more, and other quantifiers are similar; "at least one item", "one item or multiple items", or similar expressions refer to any combination of these items, including any combination of single or multiple items.

[0036] Although operations or steps are described in a specific order in the accompanying drawings in the embodiments of this application, this should not be construed as requiring these operations or steps to be performed in the specific order or serial order shown, or requiring all of the shown operations or steps to be performed to obtain the desired result. In the embodiments of this application, these operations or steps may be performed serially; they may be performed in parallel; or a portion of these operations or steps may be performed.

[0037] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information. It is understood that before using the technical solutions disclosed in the embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained. The application will now be described in conjunction with specific embodiments.

[0038] Figure 1 This is a flowchart illustrating a short video preloading method provided in one embodiment of this application. Figure 1 As shown in the figure, this application provides a short video preloading method, which may include the following steps: In step S10, the sliding speed feature sequence of the user terminal during the short video playback process is obtained.

[0039] In step S20, the target preload range is determined based on the sliding speed characteristic sequence.

[0040] In step S30, a preloading action is performed according to the target preloading range.

[0041] For example, the sliding speed feature sequence of a user terminal during short video playback can be obtained. When the user performs a sliding operation, the following data can be collected in real time: the coordinates of the starting point and ending point of the sliding, the sliding timestamp, and multiple intermediate coordinate points within the sampling period, thereby obtaining the sliding speed feature sequence.

[0042] The target preload range can be determined based on the sliding speed feature sequence. Specifically, statistical features of the sliding speed feature sequence are extracted, which may include at least one of average speed, maximum speed, speed variance, or speed trend. Speed ​​correction coefficients and trend correction coefficients are calculated based on the statistical features. Then, the target preload video count is calculated based on the baseline preload video count, the speed correction coefficients, and the trend correction coefficients.

[0043] Preloading actions can be performed based on the target preloading range by sending a preloading request to the content delivery network scheduler and / or video buffer manager. This preloading request carries a list of target videos, and the video segments in the target video list are loaded in descending order of preloading priority.

[0044] This application embodiment dynamically determines the preloading range by acquiring user scrolling speed characteristics in real time, so that the preloading quantity adaptively matches the user's actual browsing speed. When the scrolling speed is fast, the preloading range is automatically expanded to avoid playback waiting; when the scrolling speed is slow, the preloading range is automatically reduced to save bandwidth and memory resources. Therefore, while improving the smoothness of video switching, it avoids overloading or underloading caused by a fixed preloading strategy, effectively optimizing system resource utilization efficiency and improving the viewing experience for users with different scrolling habits.

[0045] Figure 2 This is a flowchart illustrating a short video preloading method provided in one embodiment of this application. Figure 2 As shown, obtaining the scrolling speed feature sequence of the user terminal during short video playback may include the following steps: In step S101, multi-touch data of the user terminal during the sliding operation is collected. The multi-touch event data includes the coordinates of the sliding start point, the coordinates of the sliding end point, and the corresponding timestamp.

[0046] In step S102, the sliding distance is calculated based on the coordinates of the sliding start point and the sliding end point, and the sliding time is calculated based on the timestamp.

[0047] In step S103, the average speed is calculated based on the sliding distance and the sliding time, and the instantaneous speed sequence is calculated based on multiple intermediate coordinate points within the sampling period to obtain the sliding speed feature sequence.

[0048] For example, during the operation of this embodiment, the user terminal can continuously monitor touchscreen events. When a swipe operation is detected, multi-touch data can be collected in sampling periods. After each sampling period, the instantaneous speed within that period can be calculated and a timestamp recorded, forming a speed sequence that is continuously updated over time. This sequence can be statistically analyzed in real time to calculate the average speed to reflect the overall swipe speed of the user, calculate the maximum speed to capture the peak operation intensity of the user, calculate the speed variance to measure the smoothness of the user's swipe, and calculate the speed trend to determine whether the user is continuously accelerating or decelerating.

[0049] The following data are collected in real time: the coordinates of the starting point and ending point of the slide, the slide timestamp, and multiple intermediate coordinate points within the sampling period. The average speed is calculated based on the sliding distance and sliding time, and the instantaneous speed sequence is calculated based on the multiple intermediate coordinate points within the sampling period to obtain the sliding speed feature sequence.

[0050] For example, the sliding distance d can be obtained by the following formula: d = sqrt((x2-x1)² + (y2-y1)²) Formula 1 Where sqrt is the square root, (x1, y1) are the starting coordinates, and (x2, y2) are the ending coordinates.

[0051] The sliding time Δt can be obtained by the following formula: Δt = t2 - t1 Formula 2 Where t1 is the start timestamp and t2 is the end timestamp.

[0052] The average velocity v_avg can be obtained by the following formula: v_avg = d / Δt (Formula 3) Where Δt is not zero.

[0053] The instantaneous velocity v_i can be obtained by the following formula: v_i = distance(p_i, p_{i+1}) / (t_{i+1} - t_i) Formula 4 Where distance(p_i, p_{i+1}) is the distance between the i-th touch point and the (i+1)-th touch point, and (t_{i+1} - t_i) is the time interval between the (i+1)-th touch point and the i-th touch point.

[0054] The embodiments of this application achieve dynamic adjustment of the preloading range according to the user's swiping speed through the above process. When swiping quickly, the preloading range is automatically expanded to avoid playback waiting, and when swiping slowly, the preloading range is automatically reduced to save bandwidth and memory, thereby realizing the adaptation of the preloading strategy to the user's swiping habits.

[0055] Figure 3 This is a flowchart illustrating a short video preloading method provided in one embodiment of this application. Figure 3 As shown, determining the target preload range based on the sliding speed feature sequence may include the following steps: In step S201a, statistical features of the sliding speed feature sequence are extracted, and the statistical features include at least one of average speed, maximum speed, speed variance, or speed trend.

[0056] In step S202a, the speed correction coefficient and the trend correction coefficient are calculated based on the statistical characteristics.

[0057] In step S203a, the target number of preloaded videos is calculated based on the baseline number of preloaded videos, the speed correction coefficient, and the trend correction coefficient.

[0058] For example, in the runtime of this application embodiment, the user terminal captures the raw data of each touch event through the touchscreen driver layer. When the user's finger touches the screen and begins to slide, the coordinates and timestamp of the touch point can be recorded. For each complete slide operation, the coordinates (x1, y1) of the starting point of the slide and the corresponding timestamp t1, and the coordinates (x2, y2) of the ending point of the slide and the corresponding timestamp t2 can be obtained. The slide distance is calculated using the Euclidean distance formula, and the slide duration is obtained by subtracting the starting point timestamp from the ending point timestamp. The average speed of the slide is obtained by dividing the two.

[0059] Meanwhile, multiple intermediate coordinate points can be recorded within the sampling period. For two adjacent sampling points, their Euclidean distance is calculated and divided by the sampling time interval to obtain the instantaneous velocity at that sampling moment. These instantaneous velocities are arranged in chronological order to form a sliding velocity feature sequence. This sequence not only contains information about the magnitude of the velocity but also implies the trend of velocity change.

[0060] Based on this, the average speed, maximum speed, and speed variance of the sequence can be statistically analyzed, and the speed trend can be determined by performing linear fitting on the sequence or calculating the speed difference between the first and last speeds. Subsequently, the average speed can be compared with preset high speed thresholds and low speed thresholds. When the average speed is higher than the high speed threshold, the speed correction coefficient is greater than 1, increasing the preload quantity; when the average speed is lower than the low speed threshold, the speed correction coefficient is less than 1, decreasing the preload quantity; when the average speed is between the two, the speed correction coefficient is equal to 1, maintaining the baseline quantity.

[0061] Regarding speed trends, when the trend is accelerating, the trend correction coefficient is greater than 1, increasing the preload weight in the current sliding direction; when the trend is decelerating, the trend correction coefficient is less than 1, decreasing the preload weight in the current sliding direction. The final target number of preloaded videos can be calculated by multiplying the baseline number of preloaded videos by the speed correction coefficient, then multiplying by the trend correction coefficient, and rounding to the nearest integer.

[0062] For example, the target number of preloaded videos, N_target, can be obtained by the following formula: N_target = round(N_base * k_v * k_t) (Formula 5) Where, round is for rounding to the nearest integer, N_base is the base number of preloaded videos, k_v is the speed correction factor, and k_t is the trend correction factor.

[0063] The embodiments of this application accurately calculate the sliding distance, sliding time, average speed, and instantaneous speed sequence based on multi-touch data, making the extraction of speed features more accurate and comprehensive, thereby making the adjustment of the preload range more refined and reasonable, and effectively avoiding the problem of insufficient or excessive preload caused by inaccurate speed measurement.

[0064] Optionally, the speed trend includes an acceleration trend and a deceleration trend. When the speed trend is an acceleration trend, the trend correction coefficient is greater than 1, which is used to increase the preload weight in the current sliding direction; when the speed trend is a deceleration trend, the trend correction coefficient is less than 1, which is used to decrease the preload weight in the current sliding direction.

[0065] For example, in the embodiments of this application, the indicative role of speed trends in indicating the user's swiping intention is emphasized during runtime. After obtaining the swiping speed feature sequence, the acceleration feature can be obtained by calculating the difference between the last instantaneous speed and the first instantaneous speed in the sequence and dividing it by the total duration.

[0066] When the acceleration feature is positive, it indicates that the user is continuously accelerating during the swipe. At this time, the user's swipe intention tends to continue browsing quickly in the current direction. Therefore, the trend correction coefficient can be set to a value greater than 1, so that the number of target preloaded videos can be further increased on the basis of speed correction, and the increased preloaded resources are tilted towards the current swipe direction, that is, the number of preloaded videos in the current swipe direction is more than that in the opposite direction.

[0067] When the acceleration feature is negative, it indicates that the user is continuously decelerating during the swipe. In this case, the user's swipe intention tends to be about to stop or change direction. Therefore, the trend correction coefficient can be set to a value less than 1, appropriately reducing the number of preloaded videos based on the speed correction, while also reducing the preload weight in the current swipe direction to avoid over-preloading in the direction the user is about to stop. When the acceleration feature is close to zero, it indicates that the user is swiping at a constant speed, and the trend correction coefficient is set to 1, without further adjustment to the preload range.

[0068] This application embodiment utilizes a speed trend correction coefficient to finely adjust the distribution of the preloading range in different directions, making the preloading strategy more aligned with the user's real-time scrolling intentions, and further improving the targeting and resource utilization efficiency of preloading.

[0069] Figure 4 This is a flowchart illustrating a short video preloading method provided in one embodiment of this application. Figure 4 As shown, determining the target preload range based on the sliding speed feature sequence may include the following steps: In step S201b, after filtering and denoising the sliding speed feature sequence, the statistical features of the sliding speed feature sequence are extracted. The statistical features include at least one of the following: average speed, maximum speed, speed variance, speed trend, single sliding duration, and sliding distance. The speed trend is determined according to the positive or negative value of the acceleration feature, with a positive value indicating acceleration and a negative value indicating deceleration.

[0070] In step S202b, the sliding speed feature sequence is input into a pre-trained sliding direction prediction model to output the sliding direction prediction result of the user at the next moment. The sliding direction prediction model includes a Hidden Markov Model or a Long Short-Term Memory Network Model, and the prediction result includes the probability of sliding upward, the probability of sliding downward, and the probability of staying.

[0071] In step S203b, the target preload range is determined based on the sliding direction prediction result.

[0072] For example, the acquired swipe speed feature sequence can be preprocessed first. Since the raw signal acquired by the touchscreen may contain noise, such as slight finger tremors or screen sampling errors, filtering algorithms can be used to denoise the speed sequence. Common filtering methods include median filtering or Kalman filtering. The denoised speed sequence can better reflect the user's actual swipe behavior.

[0073] Various statistical features can be extracted from the denoised sequence. Average speed reflects the overall speed of the user's swipe, maximum speed reflects the peak intensity of the user's swipe, speed variance reflects the stability and volatility of the user's swipe, speed trend is determined by calculating the sign of the acceleration feature (positive value indicates acceleration, negative value indicates deceleration), single swipe duration reflects the length of a single swipe operation, and swipe distance reflects the total amplitude of a single swipe operation. These features characterize the user's swipe behavior patterns from different dimensions.

[0074] The aforementioned statistical features can be combined into a feature vector and input into a pre-trained sliding direction prediction model. When using a Hidden Markov Model, the velocity feature sequence can be used as the observation sequence, and the most probable hidden state sequence can be obtained by decoding it using the Viterbi algorithm, thereby predicting the sliding direction at the next moment.

[0075] When using a Long Short-Term Memory (LSTM) network model, the velocity feature sequence can be input into the network step by step. The network's memory units capture long-term dependencies in the sequence, ultimately outputting probability distributions for three directions: upward sliding, downward sliding, and stationary. Based on the prediction results, when the probability of downward sliding exceeds a first threshold, the number of preloaded videos in the downward direction is increased; when the probability of upward sliding exceeds a second threshold, the number of preloaded videos in the upward direction is increased; and when the probability of stationary sliding exceeds a third threshold, the preloading process is paused.

[0076] This application not only utilizes speed characteristics to adjust the preload quantity, but also uses a prediction model to predict the user's swipe direction, enabling preloading to load video content in the target direction before the user actually swipes, further reducing playback waiting time and improving user experience.

[0077] Optionally, the long short-term memory network model may include: an input layer for receiving a sliding velocity feature sequence of length T; a first long short-term memory network layer containing 4N hidden units; a second long short-term memory network layer containing 2N hidden units; and a fully connected layer containing N neurons and employing the ReLU activation function, where N is a positive integer.

[0078] The output layer uses the softmax function to output the probability distributions for the three directions: sliding up, sliding down, and staying.

[0079] For example, this application embodiment specifically defines the network structure of a Long Short-Term Memory (LSTM) network model. The input layer receives a sliding velocity feature sequence of length T, where each time step corresponds to an instantaneous velocity value at a sampling moment. The value of T can be set according to the actual application scenario, for example, 20 sampling points. The first LSM network layer contains 4N hidden units, where N is a positive integer and can be selected based on the trade-off between model accuracy and computational resources. For example, when N is 32, the first layer contains 128 hidden units. This layer is responsible for extracting short-term and medium-term time-dependent features from the velocity sequence.

[0080] The second Long Short-Term Memory (LSTM) network layer contains 2N hidden units. This layer further abstracts the features extracted by the first layer, capturing long-term dependencies and higher-level temporal patterns in the velocity sequence. The fully connected layer contains N neurons and uses the ReLU activation function. This layer performs non-linear transformation and dimensionality reduction on the feature vector output by the LSTM layer, enhancing the model's expressive power.

[0081] The output layer uses the softmax function to convert the output of the fully connected layer into probability distributions for three categories: sliding upwards, sliding downwards, and staying still. The entire network is trained end-to-end, taking the original velocity feature sequence as input and directly outputting the probability prediction of the sliding direction.

[0082] In this embodiment, the dual-layer LSTM structure can effectively capture the temporal dependencies in the sliding velocity sequence. The configuration of 4N and 2N hidden units controls the model size while ensuring the model's expressive power. The ReLU activation function alleviates the gradient vanishing problem, and the softmax output layer provides an intuitive probabilistic interpretation, making the sliding direction prediction more accurate and reliable.

[0083] Optionally, the training process of the Long Short-Term Memory network model may include the following steps: First, collect multiple historical swiping behavior data of the user to construct a speed sequence sample set, with each sample labeled with the corresponding actual swiping direction.

[0084] 2. The Long Short-Term Memory network model is trained using the cross-entropy loss function and the Adam optimizer.

[0085] 3. After quantizing and compressing the trained model, deploy it to mobile devices.

[0086] For example, this application describes a complete training and deployment process for a Long Short-Term Memory (LSTM) network model. First, historical swiping behavior data of users during short video application usage can be collected in the background. For each swipe operation, the instantaneous velocity at each sampling moment during the swipe can be recorded to form a velocity sequence, and the actual swipe direction performed by the user after the swipe operation can be recorded, including swiping upwards, downwards, or remaining still. Each velocity sequence can be used as a training sample, and the corresponding actual swipe direction as the label of that sample. After collecting a sufficient number of samples, a training dataset can be constructed.

[0087] During training, the cross-entropy loss function can be used to measure the difference between the probability distribution predicted by the model and the true labels. The cross-entropy loss function is suitable for multi-class classification problems and can effectively guide the optimization of model parameters. The Adam optimizer can be used for parameter updates. The Adam optimizer combines the advantages of momentum and adaptive learning rates, and can adaptively adjust the learning rate across different parameter dimensions, accelerating convergence and improving training stability.

[0088] After training, to ensure efficient operation on mobile devices, the trained model can be quantized and compressed, for example, quantizing 32-bit floating-point parameters into 8-bit integers. This reduces model storage space and runtime memory usage, while leveraging mobile neural network acceleration hardware for faster inference. After deployment, the model runs locally on the mobile device, eliminating the need to upload user data to the cloud, thus protecting user privacy.

[0089] In this embodiment, the model is trained based on the user's own swiping behavior data, enabling it to learn the user's personalized swiping patterns and achieve more accurate predictions. The quantized and compressed model has a smaller file size and higher inference speed, making it suitable for real-time operation on resource-constrained mobile devices.

[0090] Figure 5 This is a flowchart illustrating a short video preloading method provided in one embodiment of this application. Figure 5 As shown, determining the target preload range based on the sliding direction prediction result may include the following steps: In step S2031b, when the downward sliding probability is greater than the first threshold, the number of preloaded videos in the downward direction is increased.

[0091] In step S2032b, when the upward sliding probability is greater than the second threshold, the number of preloaded videos in the upward direction is increased.

[0092] In step S2033b, when the dwell probability is greater than the third threshold, the preloading action is paused.

[0093] For example, this application embodiment specifically defines how to determine the preloading strategy based on the output of the sliding direction prediction model. The model outputs probability values ​​for three directions, representing the likelihood of the user sliding up, down, and staying in the next moment, respectively, and the sum of the three probability values ​​is 1.

[0094] Three thresholds can be preset: a first threshold, a second threshold, and a third threshold. When the probability of scrolling down is greater than the first threshold, it indicates that the model predicts with high confidence that the user will scroll down. At this point, the number of preloaded videos in the downward direction can be increased. The specific increase can be positively correlated with the probability of scrolling down; the higher the probability, the more preloaded videos should be added.

[0095] When the probability of swiping upwards exceeds the second threshold, it indicates that the model predicts with high confidence that the user will swipe upwards. In this case, the number of preloaded videos in the upward direction can be increased. It should be noted that in short video applications, swiping downwards usually corresponds to loading updated video content, while swiping upwards corresponds to replaying previously played video content. Preloading in both directions can exist simultaneously, but their respective weights are adjusted based on the predicted probabilities.

[0096] When the probability of dwelling exceeds the third threshold, it indicates that the model predicts the user may pause scrolling and remain watching the current video. In this case, preloading can be paused to avoid unnecessary preloading when the user has no intention to scroll, thus saving network bandwidth and memory resources. The specific values ​​of the above three thresholds can be set and adjusted according to the actual application scenario and requirements.

[0097] This application embodiment adopts a differentiated preloading strategy based on the comparison results of the predicted probability and the threshold, so that the preloading action is more in line with the user's actual swiping intention, which not only ensures the timeliness of preloading during swiping, but also avoids the waste of resources during dwell time.

[0098] Figure 6 This is a flowchart illustrating a short video preloading method provided in one embodiment of this application. Figure 6 As shown, the method may further include the following steps: In step S40, device status parameters are obtained, including remaining memory and CPU utilization.

[0099] In step S50, when the remaining memory is lower than the memory threshold or the CPU utilization is higher than the load threshold, the target preload range is reduced.

[0100] For example, a device state awareness mechanism can be introduced on top of the existing scrolling speed prediction and preloading. The remaining memory and CPU usage of the device can be obtained in real time through the operating system interface. Remaining memory reflects the amount of storage space currently available for caching video, and CPU usage reflects the current computational load of the device.

[0101] Memory and load thresholds can be preset. When the remaining memory is lower than the memory threshold, it indicates that the device's available memory is tight. If preloading continues according to the original target preloading range, it may lead to insufficient memory, affecting system stability and the smoothness of current video playback. Therefore, the target preloading range can be reduced, for example, by halving the number of preloaded videos or reducing it to the baseline number.

[0102] When CPU utilization exceeds the load threshold, it indicates a high computational load on the device, potentially due to other background applications consuming CPU resources or the system performing other computationally intensive tasks. Performing large-scale preloading at this time will further increase the CPU burden, causing stuttering during video decoding and playback. Therefore, the target preloading range can be reduced to alleviate CPU pressure. When remaining memory and CPU utilization are normal, preloading can be performed normally according to the target preloading range determined by the sliding speed prediction.

[0103] The preloading strategy in this application not only considers user scrolling behavior, but also takes into account the real-time status of the device. When device resources are scarce, it actively reduces the preloading intensity, ensuring the smoothness of the current video playback and the overall stability of the system.

[0104] Figure 7 This is a flowchart illustrating a short video preloading method provided in one embodiment of this application. Figure 7 As shown, the method may further include the following steps: In step S60, the current network status parameters are obtained, including network type and signal strength.

[0105] In step S70, when the network type is WiFi, the target preloading range is expanded.

[0106] In step S80, when the network type is a cellular network and the signal strength is below the signal threshold, the target preloading range is narrowed.

[0107] For example, this application introduces a network status awareness mechanism. The network type and signal strength currently connected to the device can be obtained through the operating system's network management interface. The network type may include WiFi, 4G, 5G, etc., and the signal strength may be expressed in dBm or in bars.

[0108] When the network type is WiFi, it indicates that the device is currently connected to a wireless local area network. WiFi networks typically have high bandwidth and low latency, and do not consume the user's mobile data. Therefore, the target preloading range can be expanded. For example, the number of videos preloaded can be increased by a certain percentage based on the original target preloaded video count. This fully utilizes the high bandwidth advantage of WiFi networks to preload more video content and improve the smoothness of subsequent scrolling and browsing.

[0109] When the network type is cellular, it indicates that the device is currently using a mobile data network. In this case, the signal strength can be further checked. When the signal strength is below the signal threshold, it indicates that the current cellular network signal is weak, and the network bandwidth may be limited and unstable. Performing large-scale preloading in this situation could lead to slow preloading speeds, long processing times, or even failure due to network timeouts, thus consuming valuable mobile data. Therefore, the target preloading scope can be narrowed, for example, by reducing the number of videos to be preloaded, prioritizing the playback quality of the current video.

[0110] When the network type is cellular but the signal strength is good, preloading can be performed according to the normal target preloading range, or preloading can be performed depending on whether the user has enabled the mobile data preloading switch.

[0111] The preloading strategy of this application embodiment adaptively adjusts according to network type and signal strength. In WiFi environment, it makes full use of network resources to load in advance, and actively reduces preloading when the cellular network signal is poor. This not only improves the user experience, but also avoids the waste of mobile data traffic.

[0112] Figure 8 This is a flowchart illustrating a short video preloading method provided in one embodiment of this application. Figure 8 As shown, determining the target preload range based on the sliding speed feature sequence may include the following steps: In step S201c, the speed prediction score is obtained.

[0113] In step S202c, at least one of the device status score, network status score, and user profile score is obtained.

[0114] In step S203c, a preloaded fusion score is obtained based on at least one of the speed prediction score, the device status score, the network status score, or the user profile score.

[0115] In step S204c, the target preload range is determined based on the preload fusion score.

[0116] For example, embodiments of this application employ a multi-factor weighted fusion approach to determine the final preloading range. The speed prediction score is a score predicted based on the swipe speed feature sequence, reflecting the degree of preloading demand for the user's upcoming swipe action. A higher speed prediction score indicates that the user's swipe speed is faster or that a swipe is predicted to occur, requiring a larger preloading range.

[0117] The device status score can be calculated based on the device's remaining memory and CPU utilization. When there is sufficient remaining memory and low CPU utilization, the device status score is higher, allowing for a larger preload range. When there is insufficient remaining memory or high CPU utilization, the device status score is lower, limiting the preload range.

[0118] The network status score can be calculated based on the current network type and signal strength. When the network is a WiFi or cellular network with a strong signal, the network status score is higher, supporting a larger preload range; when the network is a cellular network with a weak signal, the network status score is lower, limiting the preload range.

[0119] User profile scores can be built based on users' historical behavior data, including their scrolling habits and video type preferences. For example, users who are used to scrolling quickly have higher user profile scores and are more likely to be given a larger preload range; users who are used to browsing slowly have lower user profile scores and are more likely to be given a smaller preload range.

[0120] Different weights can be assigned to the speed prediction score, device status score, network status score, and user profile score, and then the weighted sum is used to obtain the preloaded fusion score. The specific values ​​of the weights can be set and adjusted according to the actual application scenario and requirements. Finally, the target number of preloaded videos can be determined based on the mapping relationship between the preloaded fusion score and the preset score range.

[0121] The preloading decision in this application comprehensively considers multiple factors such as user swiping behavior, real-time device status, current network conditions, and user personalized habits, making the preloading strategy more comprehensive, intelligent, and personalized, and further improving the accuracy of preloading and resource utilization efficiency.

[0122] Figure 9 This is a flowchart illustrating a short video preloading method provided in one embodiment of this application. Figure 9 As shown, performing the preloading action according to the target preloading range may include the following steps: In step S301, a preload request is sent to the content delivery network scheduler and / or video buffer manager, the preload request carrying a list of target videos.

[0123] In step S302, video segments in the target video list are loaded in descending order of preloading priority, wherein the video segments closer to the currently playing video have a higher preloading priority.

[0124] For example, this application embodiment specifically describes the execution method of the preloading action. After determining the target preloading range and the target video list, the preloading instruction can be sent to the underlying content delivery network scheduler and video buffer manager. The content delivery network scheduler is responsible for selecting the optimal node from the distributed CDN nodes to transmit the video content to the user terminal at the fastest speed. The video buffer manager is responsible for managing the local video buffer of the user terminal and controlling the downloading, caching, and playback of video segments.

[0125] A preload request can be sent to the content delivery network scheduler and / or video buffer manager, carrying a list of target videos. This list contains the identifiers of the videos to be preloaded and their corresponding video segment information. During the loading process, video segments in the target video list can be loaded sequentially in descending order of preload priority. The principle for determining the preload priority is that video segments closer to the currently playing video have higher preload priority. Specifically, assuming that video N is currently playing, and the target preload range is M1 videos above and M2 videos below, then the preload priority from high to low is video N+1, video N-1, video N+2, video N-2, ..., that is, videos adjacent to the current video are loaded alternately, and the closer to the current video, the higher the priority.

[0126] In this embodiment, video segments closer to the currently playing video are loaded first, ensuring that the video content most likely to be accessed by the user while swiping is prepared in advance, minimizing playback waiting time. At the same time, loading according to priority order also avoids low-priority videos occupying preloaded resources, improving the efficiency and targeting of preload.

[0127] Figure 10 This is a flowchart illustrating a short video preloading method provided in one embodiment of this application. Figure 10 As shown, the method may further include the following steps: In step S90, when the number of cached videos on the user terminal exceeds the cache capacity, an elimination score is obtained for each cached video. The elimination score is calculated by weighting the video popularity, preloading priority, and most recent access time.

[0128] In step S100, cached videos are eliminated in order of elimination scores from low to high, wherein the elimination scores of the currently playing video and the most recently preloaded video are set to the highest value and are prohibited from being eliminated.

[0129] For example, this application embodiment introduces a cache eviction mechanism. The cache capacity of a user terminal is limited. As the system continuously performs preloading, the number of cached videos may gradually increase and eventually exceed the cache capacity limit. At this point, the system needs to select a portion of the cached videos for eviction to make room for newly preloaded videos.

[0130] The elimination score can be calculated for each cached video. The calculation of the elimination score takes into account three factors. Video popularity reflects the popularity of the video on the entire network or locally, which can be measured by indicators such as number of views, number of likes, and number of shares. The higher the video popularity, the more likely users are to watch the video, the higher the elimination score, and the less likely it is to be eliminated.

[0131] Preloading priority reflects the importance of a video during preloading. Videos closer to the currently playing video are given higher priority during preloading, resulting in higher elimination scores and a lower likelihood of being eliminated. Recent access time reflects the video's proximity to the current moment; recently accessed videos have higher elimination scores and are less likely to be eliminated. Weights can be assigned to each of these three factors, and a weighted sum can be obtained for the elimination score of each cached video. These weights can be set and adjusted according to actual needs.

[0132] During the elimination process, cached videos can be sorted in ascending order of elimination score, prioritizing the elimination of videos with the lowest scores. Simultaneously, the elimination scores of the currently playing video and the most recently preloaded videos are set to the highest value to ensure they are not eliminated, thus preserving the continuity of current playback and the results of preloading.

[0133] For example, the elimination score can be obtained by the following formula: score = α * video_hotness + β * preload_priority + γ * last_access_time formula 6 Where video_hotness is the video's popularity, preload_priority is the preload priority, last_access_time is the last access time, and α, β, and γ are weighting coefficients.

[0134] The cache eviction strategy in this application comprehensively evaluates the retention value of each video based on three dimensions: video popularity, preloading priority, and most recent access time. It prioritizes eviction of videos with lower value and retains videos with higher value, so that the limited cache space is used most effectively, while ensuring that currently playing and recently preloaded videos are not accidentally evicted.

[0135] Figure 11This is a block diagram of an electronic device provided in one embodiment of this application. For example... Figure 11 As shown, the electronic device 1100 may include: a processor 1101 and a memory 1102. The electronic device 1100 may also include one or more of a multimedia component 1103, an input / output (I / O) interface 1104, and a communication component 1105.

[0136] The processor 1101 controls the overall operation of the electronic device 1100 to complete all or part of the steps in the aforementioned short video preloading method. The memory 1102 stores various types of data to support the operation of the electronic device 1100. This data may include, for example, instructions for any application or method operating on the electronic device 1100, and application-related data such as contact data, sent and received messages, pictures, audio, video, etc. The memory 1102 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. Multimedia component 1103 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 1102 or transmitted via communication component 1105. The audio component also includes at least one speaker for outputting audio signals. I / O interface 1104 provides an interface between processor 1101 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 1105 is used for wired or wireless communication between the electronic device 1100 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 1105 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0137] In an exemplary embodiment, the electronic device 1100 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the short video preloading method described above.

[0138] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the short video preloading method described above. For example, the computer-readable storage medium may be the memory 1102 including program instructions described above, which may be executed by the processor 1101 of the electronic device 1100 to complete the short video preloading method described above.

[0139] In another exemplary embodiment, a computer program product is also provided, comprising a computer program executable by a programmable device, the computer program having a code portion for performing the short video preloading method described above when executed by the programmable device.

[0140] The preferred embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this application, various simple modifications can be made to the technical solution of this application, and these simple modifications all fall within the protection scope of this application.

[0141] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this application will not describe the various possible combinations separately.

[0142] Furthermore, various different implementations of this application can be combined in any way, as long as they do not violate the spirit of this application, they should also be regarded as the content disclosed in this application.

Claims

1. A short video preloading method, characterized in that, The method includes: Obtain the scrolling speed feature sequence of the user terminal during short video playback; The target preload range is determined based on the sliding speed characteristic sequence; Perform the preloading action according to the target preloading range.

2. The method according to claim 1, characterized in that, The acquisition of the user terminal's scrolling speed feature sequence during short video playback includes: Collect multi-touch data of the user terminal during the sliding operation. The multi-touch event data includes the coordinates of the sliding start point, the coordinates of the sliding end point, and the corresponding timestamp. The sliding distance is calculated based on the coordinates of the sliding start point and the sliding end point, and the sliding time is calculated based on the timestamp. The average speed is calculated based on the sliding distance and the sliding time, and the instantaneous speed sequence is calculated based on multiple intermediate coordinate points within the sampling period to obtain the sliding speed feature sequence.

3. The method according to claim 1, characterized in that, Determining the target preload range based on the sliding speed feature sequence includes: Extract statistical features from the sliding speed feature sequence, wherein the statistical features include at least one of average speed, maximum speed, speed variance, or speed trend; Calculate the speed correction coefficient and trend correction coefficient based on the statistical characteristics described above; The target number of preloaded videos is calculated based on the baseline number of preloaded videos, the speed correction factor, and the trend correction factor.

4. The method according to claim 3, characterized in that, The speed trend includes acceleration and deceleration trends; When the speed trend is an accelerating trend, the trend correction coefficient is greater than 1, which is used to increase the preload weight in the current sliding direction; When the speed trend is a deceleration trend, the trend correction coefficient is less than 1, which is used to reduce the preload weight in the current sliding direction.

5. The method according to claim 1, characterized in that, Determining the target preload range based on the sliding speed feature sequence includes: After filtering and denoising the sliding speed feature sequence, the statistical features of the sliding speed feature sequence are extracted. The statistical features include at least one of the following: average speed, maximum speed, speed variance, speed trend, single sliding duration and sliding distance. The speed trend is determined according to the sign of the acceleration feature, with positive values ​​indicating acceleration and negative values ​​indicating deceleration. The sliding speed feature sequence is input into a pre-trained sliding direction prediction model to output the sliding direction prediction result of the user at the next moment. The sliding direction prediction model includes a hidden Markov model or a long short-term memory network model. The prediction result includes the probability of sliding upward, the probability of sliding downward, and the probability of staying. The target preload range is determined based on the predicted sliding direction.

6. The method according to claim 5, characterized in that, The long short-term memory network model includes: The input layer receives a sliding velocity feature sequence of length T; the first long short-term memory network layer contains 4N hidden units; the second long short-term memory network layer contains 2N hidden units; and the fully connected layer contains N neurons and uses the ReLU activation function, where N is a positive integer. The output layer uses the softmax function to output the probability distributions for the three directions: sliding up, sliding down, and staying.

7. The method according to claim 6, characterized in that, The training steps of the Long Short-Term Memory (LSTM) network model include: Collect multiple historical swipe behavior data of the user to construct a speed sequence sample set, with each sample labeled with the corresponding actual swipe direction; The long short-term memory network model was trained using the cross-entropy loss function and the Adam optimizer. The trained model is quantized and compressed before being deployed to mobile devices.

8. The method according to claim 5, characterized in that, Determining the target preload range based on the sliding direction prediction result includes: When the probability of sliding downwards is greater than a first threshold, increase the number of preloaded videos in the downward direction; or When the upward sliding probability is greater than the second threshold, increase the number of preloaded videos in the upward direction; or When the probability of dwelling is greater than the third threshold, the preloading action is paused.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: Obtain device status parameters, including remaining memory and CPU utilization. When the remaining memory is below the memory threshold or the CPU utilization is above the load threshold, the target preload range is reduced.

10. The method according to any one of claims 1-8, characterized in that, The method further includes: Obtain the current network status parameters, including network type and signal strength; When the network type is WiFi, the target preloading range is expanded; When the network type is a cellular network and the signal strength is below the signal threshold, the target preloading range is reduced.

11. The method according to any one of claims 1-8, characterized in that, Determining the target preload range based on the sliding speed feature sequence includes: Obtain the speed prediction score; Obtain at least one of the device status score, network status score, and user profile score; The preloaded fusion score is obtained based on at least one of the speed prediction score and the device status score, the network status score, or the user profile score. The target preloading range is determined based on the preloading fusion score.

12. The method according to any one of claims 1-8, characterized in that, The step of performing the preloading action according to the target preloading range includes: Send a preload request to the content delivery network scheduler and / or video buffer manager, the preload request carrying a list of target videos; Video segments in the target video list are loaded in descending order of preloading priority, with video segments closer to the currently playing video having a higher preloading priority.

13. The method according to any one of claims 1-8, characterized in that, The method further includes: When the number of cached videos on the user terminal exceeds the cache capacity, an elimination score is obtained for each cached video. The elimination score is calculated by weighting the video popularity, preloading priority, and most recent access time. Cached videos are eliminated in ascending order of their elimination scores, with the currently playing video and the most recently preloaded video having the highest elimination scores and thus being prohibited from being eliminated.

14. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method according to any one of claims 1-13.

15. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method described in any one of claims 1-13.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-13.

Images