Switching perception adaptive live broadcast method for low earth orbit satellite network

Abstract

The invention discloses a low earth orbit satellite network-oriented switching perception adaptive live broadcast method. The method comprises the steps of obtaining a predicted satellite switching opportunity in a low earth orbit satellite network; based on the predicted satellite switching opportunity, a video stream transmission time axis is divided into a stable period and a switching period by adopting an adaptive segmentation division mechanism, in the stable period, data of the video stream is divided into segments for transmission, and in the switching period, the data of the video stream is divided into blocks for transmission; based on the predicted satellite switching opportunity, the video code rate and the playing speed in the satellite switching process are dynamically adjusted by adopting a switching perception adaptive code rate control algorithm, and a playing buffer area is actively pre-filled before switching; wherein the playing duration of the blocks is smaller than the playing duration of the segments. The switching perception adaptive live broadcast method can effectively alleviate the problem that the existing adaptive code rate algorithm is difficult to stably optimize dynamic bandwidth, burst packet loss and the like easily caused in a satellite switching scene.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of video streaming transmission, and particularly relates to a switching-aware adaptive live streaming method for low earth orbit satellite networks (LEO Satellite Networks, LSNs). BACKGROUND

[0002] Currently, mainstream Internet live streaming transmission adopts the HTTP-based adaptive streaming (HAS) method, such as MPEG-DASH and HLS. This method divides video content into several segments of fixed time length, and encodes multiple rate versions for each segment, and the playback end selects a suitable rate for downloading according to the network state through an adaptive bit rate (ABR) algorithm. Although in recent years, in order to adapt to the needs of lower delay applications, related protocols such as LL-DASH and LL-HLS introduce finer-grained block transmission methods to achieve faster playback response and lower end-to-end delay, but the core segmentation and transmission mechanism is still mainly designed for random fluctuations of ground networks.

[0003] In order to cope with the bandwidth changes caused by such network fluctuations, researchers have designed various ABR algorithms to dynamically adjust video rates. Common ABR algorithms are divided into three categories: (1) algorithms based on throughput estimation (such as PANDA); (2) algorithms based on playback buffer (such as BBA, BOLA); (3) hybrid type algorithms (such as MPC, Pensieve). Some new algorithms, such as L2A and LOL+, also introduce online learning mechanisms and playback speed control mechanisms to further improve user experience performance (QoE). However, these algorithms are mostly designed for ground networks and are difficult to adapt to the frequent and predictable topology changes in satellite networks.

[0004] Low earth orbit satellite networks (such as Starlink) have gradually become an important supplement to the next generation of Internet due to their wide coverage and low latency. However, its high orbital speed (about 7.8 km / s) causes the terminal to experience an inter-satellite handover every 15 seconds. Each handover may cause RTT jumps, packet loss, and TCP slow start, resulting in reduced throughput, playback interruptions, and decreased QoE, especially in live streaming scenarios. Traditional ABR algorithms face significant performance degradation in such networks.

[0005] Although some research has attempted to optimize live streaming in low earth orbit satellite scenarios, such as predicting network fluctuations and responding through multi-armed bandit or neural network methods. However, these methods are not accurate enough in timing handovers, or fail to consider segmentation strategies and ABR strategies at the system level. In addition, most existing methods do not specifically optimize the "handover window period", resulting in the problem of playback freezing or drastic fluctuations in picture quality during this critical period. SUMMARY

[0006] The application provides a switching-aware adaptive live streaming method suitable for a low-orbit satellite network, which can significantly improve the transmission continuity of live video and user experience in a frequent satellite switching environment, and effectively solves the above technical problems.

[0007] According to a first aspect of the application, the application provides a switching-aware adaptive live method for a low-orbit satellite network, comprising the following steps: obtaining a predicted satellite switching time in a low-orbit satellite network; based on the predicted satellite switching time, using an adaptive segmentation division mechanism to divide the video stream transmission time axis into a stable period and a switching period, in the stable period, dividing the data of the video stream into segments for transmission, and in the switching period, dividing the data of the video stream into blocks for transmission; based on the predicted satellite switching time, using a switching-aware adaptive bit rate control algorithm to dynamically adjust the video bit rate and the playing speed in the satellite switching process, and actively pre-filling the playing buffer before the switching occurs; wherein the playing duration of the block is less than the playing duration of the segment.

[0008] Further, the switching period is a time window formed by taking the predicted satellite switching time as the center and extending forward and backward by a preset time, and the stable period is the remaining period except the switching period.

[0009] Further, the adaptive segmentation division mechanism is implemented by updating the MPD file, and the MPD file uses the SegmentTimeline mode to ensure the continuity of the timestamp.

[0010] Further, the workflow of the adaptive segmentation division mechanism is as follows: In the server pre-encoding stage, the input video is initially segmented according to the bit rate list to form a DASH basic stream; When the switching predictor is triggered, the initial segmentation is divided into blocks, and at the same time, the client updates the new MPD file in time according to the minimum Update Period attribute of the old MPD file, and the client player can automatically read the new MPD file and adjust the playing strategy according to the change of the MPD file.

[0011] Further, the adaptive bit rate control algorithm takes the maximization of the QoE function utility as the optimization goal, and the evaluation parameters of the QoE function utility at least include visual quality, playing fluency and live delay deviation.

[0012] Further, the adaptive bit rate control algorithm is specifically: calculate an ideal playout speed based on the predicted satellite handover timing and the current playout delay; determine a candidate combination set including code rate and playout speed that satisfy buffer constraint conditions based on the ideal playout speed, current buffer status and predicted remaining time before handover, the buffer constraint conditions including a long-term constraint that guarantees the playout buffer is non-empty at any time, and a safety constraint that the buffer does not underflow before the predicted handover occurs; select a video code rate and playout speed combination from the candidate combination set that maximizes the QoE function utility of the current video segment.

[0013] Further, the adaptive segment division mechanism and the handover-aware adaptive rate control algorithm are deployed in the form of a plug-in module in an existing DASH or HLS client without modifying the satellite link layer or physical layer.

[0014] According to a second aspect of the present application, the present application also provides a handover-aware adaptive live streaming system for a low-orbit satellite network, comprising: a handover prediction module configured to obtain a predicted satellite handover timing in the low-orbit satellite network; an adaptive segment division module configured to divide a video stream transmission timeline into a stable period and a handover period based on the predicted satellite handover timing, and generate corresponding segment control instructions according to different periods; a video data processing module configured to encapsulate video data in the stable period as segments and encapsulate video data in the handover period as blocks in response to the segment control instructions, wherein the playout duration of the blocks is less than the playout duration of the segments; an adaptive rate control module configured to dynamically adjust the video code rate and playout speed before the handover period based on the predicted satellite handover timing to achieve active pre-filling of the buffer.

[0015] According to a third aspect of the present application, the present application also provides an electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of any of the above handover-aware adaptive live streaming methods for a low-orbit satellite network when executing the program.

[0016] According to a fourth aspect of the present application, the present application also provides a storage medium having a plurality of instructions stored therein, the instructions being adapted to be loaded by a processor to execute the steps of any of the above handover-aware adaptive live streaming methods for a low-orbit satellite network.

[0017] At least the following technical effects can be achieved by one or more of the above embodiments in the present application: The present application proposes a switching-aware adaptive live method aiming at the stability challenges brought by frequent switching of low-orbit satellite networks on live video services. By introducing a switching prediction-driven adaptive segmentation mechanism, the video segmentation and buffering strategy can be actively adjusted before switching, effectively reducing the re-buffering events caused by packet loss. At the same time, aiming at the characteristics of sudden bandwidth drop and delay fluctuation during switching, an adaptive bit rate control algorithm for periodic network fluctuation is designed to jointly optimize the video bit rate and the playing speed, thereby realizing the playing continuity guarantee and experience optimization under dynamic link conditions. The switching-aware adaptive live method of the present application can effectively alleviate the problems that the existing adaptive bit rate algorithm is difficult to stably optimize in the dynamic bandwidth and burst packet loss environment under the satellite switching scenario. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0019] Figure 1 is the packet loss and one-way delay change in the Starlink provided by the embodiments of the present application; Figure 2 is the switching-induced re-buffering event analysis provided by the embodiments of the present application; Figure 3 is the segmentation playback failure due to packet loss provided by the embodiments of the present application; Figure 4 is the segmentation playback success due to the playability of the block provided by the embodiments of the present application; Figure 5 is the HALS provided by the embodiments of the present application 2 Design overview; Figure 6 is the greedy algorithm HALS provided by the embodiments of the present application 2 -Greedy execution process; Figure 7 is the Lyapunov optimization algorithm HALS provided by the embodiments of the present application 2 -Lyapunov execution process; Figure 8 is the average delay of the ABR algorithm provided by the embodiments of the present application; Figure 9 is the average bit rate of the ABR algorithm provided by the embodiments of the present application; Figure 10is the average rebuffering time of the algorithm provided by the embodiment of the present application; Figure 11 is the comparison of the ABR algorithm under different bandwidths at 2s and 6s target delays provided by the embodiment of the present application; comparison; Figure 12 is the comparison of the ABR algorithm under different bandwidths at 2s and 6s target delays provided by the embodiment of the present application; comparison; Figure 13 is the comparison of the ABR algorithm under different bandwidths at 2s and 6s target delays provided by the embodiment of the present application; comparison; Figure 14 is the comparison of the ABR algorithm under different bandwidths at 2s and 6s target delays provided by the embodiment of the present application; comparison. DETAILED DESCRIPTION

[0020] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person skilled in the art without creative labor fall within the protection scope of the present application.

[0021] The terms "first", "second", etc. are only used for description purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first", "second", etc. can explicitly or implicitly include one or more features. In the description of the present application, the meaning of "multiple" is two or more, unless otherwise specifically limited.

[0022] "A and / or B" includes the following three combinations: only A, only B, and the combination of A and B.

[0023] The use of "adapted for" or "configured for" in the present application means open and inclusive language that does not exclude devices adapted for or configured for performing additional tasks or steps. In addition, the use of "based on" means open and inclusive, because the process, step, calculation or other action "based on" one or more conditions or values can be based on additional conditions or values in practice.

[0024] In this disclosure, the word "exemplary" is used to mean "serving as an example, instance, or illustration." Any implementation described as "exemplary" is not necessarily to be construed as preferred or advantageous over other implementations. The following description is presented to enable any person skilled in the art to make and use the disclosure. Details are set forth in the following description for purpose of explanation. It should be appreciated that one of ordinary skill in the art will readily recognize that the disclosure can be practiced without the use of these specific details. In other instances, well-known structures and processes have not been described in detail in order to avoid obscuring the description of the disclosure. Thus, the present disclosure is not intended to be limited to the implementations shown, but is to be accorded the widest scope consistent with the principles and features disclosed.

[0025] In practice, live streaming transmission in LSNs encounters a number of problems, including the following: (1) Network jitter caused by frequent satellite handovers significantly degrades service quality.

[0026] When providing live streaming services in low earth orbit satellite networks (LSNs), system performance can be significantly degraded due to frequent link handovers. This high frequency of handovers is mainly due to the high orbital velocity of low earth orbit satellites (LEOs) (about 28800 km per hour) and the relatively limited ground coverage range. As shown in Figure 1 Existing studies have shown that, in systems such as Starlink, the frequent inter-satellite handovers triggered by packet loss can trigger TCP slow start, thereby significantly affecting throughput performance. Experiments have also observed that the severe network jitter caused by satellite handovers can severely damage the quality of live streaming services.

[0027] Based on the analysis of the public dataset provided by LENS, this embodiment further reveals the persistent impact that short handover events can cause. Figure 1 As shown, in each interval of about 15 seconds, there are significant fluctuations in latency and packet loss. Although the RTT is relatively stable in some time slots, due to handover or RTT timeout, the client and server can still enter the TCP slow start phase, thereby significantly reducing the TCP throughput on which live streaming relies. Figure 2 A typical rebuffering event triggered by a handover is shown: in this case, the application layer connection reconstruction takes about 2 seconds, causing a user-perceptible playback interruption. This delay is due to the TCP slow start mechanism and is further amplified in the context of the long propagation delay of LSNs. In HAS, each segment is an independent media file (e.g., MP4 or TS) that encapsulates a discrete portion of the video stream. Successful decoding of a segment requires complete reception of its data. Therefore, even a small amount of packet loss during a handover can compromise the integrity of the entire segment, causing a playback interruption and possibly triggering a rebuffering event, as shown inFigure 3 as shown.

[0028] (2) Inappropriate bit rate selection due to inaccurate network estimation by traditional ABR algorithms.

[0029] Network conditions in terrestrial networks are generally more stable than in LSNs. Existing ABR algorithms are primarily designed for terrestrial environments, and their goal is typically to select the highest bit rate supported by the current network environment. However, this strategy greatly increases the risk of rebuffering events during LSN handover. Moreover, these rebuffering events often prompt the ABR algorithm to switch to a lower bit rate, even though a higher quality option might become available immediately after the handover, resulting in suboptimal bit rate selection and reduced QoE.

[0030] Based on the above technical problems, the present application provides a handover-aware adaptive live streaming method (HALS 2 : Handover-Aware Live Streaming System) for low-orbit satellite networks, as shown. Figure 4 HALS 2 solves the above challenges by utilizing a predictable satellite handover timing adaptive segment division mechanism and a handover-aware ABR algorithm in low-orbit satellite networks. This proactive control mechanism enables the system to mitigate the adverse effects of handover on playback continuity and video quality.

[0031] The adaptive segment division mechanism and the handover-aware ABR algorithm are described in detail below.

[0032] Adaptive segment division mechanism: To mitigate rebuffering caused by incomplete segments during handover, HALS 2 introduces an adaptive segment division mechanism. According to the predicted satellite handover timing, the live streaming session is divided into a handover period and a stable period along the transmission time axis. The handover period is defined as a two-second time window before and after the handover event, during which all video segments are subdivided into smaller chunks for transmission to enhance resistance to potential interference. As shown in Figure 5 , smaller chunks are used for transmission during the handover period, which can minimize the pause time for users to watch even if packet loss occurs. The remaining time interval is the stable period, during which the system returns to the traditional segment-based division, and the playback duration of the segment is longer than that of the chunk, thereby reducing overhead and improving transmission efficiency. This adaptive segment division strategy balances QoE and system efficiency by reducing additional headers.

[0033] ABR algorithm with handover awareness: To address the inappropriate bitrate selection during handover, this embodiment proposes a new ABR algorithm designed specifically for live streaming on LSNs. This algorithm utilizes the predictability of handover timing to dynamically adjust the video bitrate and playback speed, proactively pre-filling the buffer before handover, thereby improving overall QoE. The following details the implementation process of this ABR algorithm with handover awareness, mainly including three stages: problem modeling, greedy algorithm implementation, and enhancement based on Lyapunov optimization.

[0034] First, the live bitrate decision problem during handover in LEO satellite networks is modeled.

[0035] In DASH, video content is divided into fixed-length segments with a duration of seconds. Each segment is encoded at M discrete quality levels, represented by a set of bitrates To quantify user utility, a quality function (e.g., MOS VMAF) is defined to evaluate the perceived experience corresponding to bitrate , where denotes the bitrate chosen for the i-th video segment.

[0036] QoE is evaluated from three dimensions: visual quality, playback smoothness, and delay deviation. Accordingly, the QoE related to the chosen bitrate and playback speed for the i-th segment is defined as follows:

[0037] where is the rebuffering time, and quantify the fluctuations in video quality and playback speed between consecutive segments, respectively, and the weight parameters ρ, η, and ι adjust the trade-off between different factors, while the term reflects the delay deviation, where denotes the target delay, defined as the expected end-to-end delay from content generation to client presentation, denotes the delay deviation.

[0038] To keep the real-time playback delay consistent with the target delay , the playback speed must be adjusted accordingly. However, abrupt changes in playback speed can significantly degrade QoE. Therefore, this adjustment should be done in a smooth and gradual manner. In practical applications, this is usually achieved by defining an ideal playback speed ​This is achieved by simultaneously addressing the needs of correcting latency drift and maintaining playback stability. For example, the default catch-up mechanism in the current version (5.0.0) of the DASH Reference Player will... Defined as:

[0039] In the formula, This represents the compensation coefficient derived from the playback speed list. It defines the allowable adjustment range of the playback speed, i.e. It is worth noting that equation (2) uses the sigmoid function to ensure that the adjustment of playback speed is gradual and continuous, thereby reducing the risk of perceptible playback discontinuity. Therefore, equation (2) The delay deviation term in and playback speed fluctuation item A uniform deviation term can be used. Instead, it simplifies the concept of QoE by implicitly capturing latency control and smoothness within the monomial.

[0040] In practical applications, rebuffering events are often the most critical factor in reducing QoE. To avoid rebuffering and ensure playback continuity, it is necessary to ensure that the playback buffer is non-empty at all times, i.e., Ti=0 is always satisfied. To achieve this, this embodiment defines the net buffer gain of segment n as:

[0041] In the formula, Let be the estimated available transmission rate (throughput) during the download of the i-th segment. In equation (3), the first and second terms represent the playback time and download time of the i-th segment, respectively. Therefore... This reflects the change in the remaining playback time in the buffer. To ensure the buffer is always non-empty, it is only necessary that the cumulative net buffer gain of all segments is greater than or equal to zero, which can be expressed as:

[0042] Where N represents the total number of segments.

[0043] However, in low-Earth orbit satellite networks, the actual download speed during handover may deviate from the estimate. Constraint (4) alone is insufficient to guarantee that rebuffering events will not occur. Therefore, the buffer must be pre-filled to the safety level before each handover, so that uninterrupted playback can be guaranteed throughout the handover even if no data is downloaded during the handover.

[0044] To identify segments where playback and switching overlap, a set H of switching occurrence times is first defined. For example, in the case of Starlink, switching occurs at seconds 12, 27, 42, and 57 of each minute, therefore... Let denote the playback completion time of the ith segment, and denote the start time. Based on equation (4), uninterrupted continuous playback is guaranteed:

[0045] Therefore, if there exists such that then it is considered that a switch occurs during the playback of the ith segment.

[0046] For these segments, let ′ denote the decision time of the ith segment bit rate and playback speed. This decision point occurs immediately before the segment download begins. Also define h t i′j = h j -t' i′ as the remaining time before the next switch. Within h t i′j , the maximum number of segments that can be downloaded is denoted as k i′j , which is subject to the estimated throughput C i′ and the bit rate b i′ , as well as the constraint on the maximum number of segments generated by the streamer within h t i′j . Therefore, can be expressed as:

[0047] For convenience, we denote the set of these segments as . For each segment , to ensure that the buffer does not underflow after switching at time , the selection of the bit rate and playback speed should follow the following constraints:

[0048] where is the buffer at the decision time , ε is a safety margin to prevent rebuffering, is the remaining time until the next switch, is the maximum number of segments that can be downloaded within h . The first term of equation (5) quantifies the total amount of video content available for playback before the next switch, including both buffered content and expected downloads within that interval, adjusted by the playback speed. Constraints (4) and (5) guarantee uninterrupted playback, which means that the With the above simplifications and constraints, the optimization objective is defined as maximizing the cumulative QoE subject to constraints (4) and (5):

[0049] where θ controls the penalty weight for deviating from the ideal playback speed βideal. HALS 2 The goal is to jointly optimize the bitrate and the playback speed to maximize the cumulative QoE subject to constraints:

[0050] To achieve the optimization objective defined in (7), the embodiment first designs a greedy algorithm HALS 2 -Greedy, i.e., make a myopic decision by optimally choosing the next segment to maximize the immediate QoE' given the current conditions. The greedy algorithm HALS 2 -Greedy works as follows: Figure 6 The process first calls the Handover_Predictor() function, which returns a Boolean variable Handover indicating whether the current segment i belongs to the set Ki'. If yes, the estimated remaining time h t ij Until the next handover is returned. Subsequently, the algorithm computes the ideal playback speed βideal by calling the Calculate_Ideal_Speed() function. Once βideal is obtained, HALS 2 -G exhaustively searches all combinations of bitrate r and playback speed β from a fixed candidate list. For each combination, the algorithm checks whether it satisfies the constraints (4) and (5), and if so, evaluates the corresponding QoE'. Meanwhile, HALS 2 -G keeps track of the best combination found so far.

[0051] In the experiments of the embodiment, the playback rate β is restricted to the interval [0.95, 1.03], which is the perceptually safe range verified by previous studies. In addition, β is quantized with a granularity of 0.001, since finer-grained adjustments would bring negligible perceptual experience improvement. Since the number of possible values is limited, the computational overhead of the exhaustive search of (bi, βi) is acceptable. Moreover, the bitrate ladder of a live stream typically contains a limited number of discrete levels (usually no more than 10). Therefore, the number of possible combinations of bitrate and playback speed is generally in the order of hundreds. Thus, the overall complexity is still manageable.

[0052] To overcome the myopic nature of the greedy algorithm HALS 2 -G, in other embodiments of the application, a HALS based on Lyapunov optimization is further introduced.2 The Lyapunov algorithm provides a framework for handling time-averaged objectives under long-term constraints. This algorithm introduces a virtual queue to track constraint violations, enabling online decision-making to optimize both instantaneous utility and long-term stability and performance. Furthermore, it does not require prior knowledge of future network dynamics, making it highly applicable to dynamic and stochastic LSNs. See also Figure 7 HALS 2 The workflow of the -L algorithm is as follows: After obtaining the HALS... 2 -G same , After Handover, the algorithm performs an exhaustive search and tracks the combination (bi, βi) that minimizes the DPT. After the search is complete, the virtual queues Q and b are updated with the selected optimal combination (bi, βi).

[0053] Specifically, HALS 2 The Lyapunov algorithm transforms the long-term constraint (4) into a stability problem of the virtual queue Q. By ensuring that Q remains stable, the long-term constraint is implicitly satisfied over time. The queue update rule is as follows:

[0054] By defining Lyapunov functions The Lyapunov drift under single-slot conditions is:

[0055] In the formula, V>0 represents the Trade-Off parameter. Since precise drift is often difficult to handle, an upper bound is minimized on each segment, expressed as:

[0056] This leads to the following segment-by-segment optimization:

[0057] However, based on HALS 2 The experimental results of -G show that, simply by... The adjustment delay bias is too conservative because Originally designed for stable terrestrial networks. To accelerate the reduction of latency bias, (…) was introduced. The *(Lt-Li) term is used to enhance the sensitivity of playback speed adjustments. Furthermore, to better capture long-term fluctuations in video quality, this embodiment incorporates the short-term bitrate variation term in the QoE' formula. Replace with ,in It is the smoothed average bitrate calculated using a sliding window and updated as follows: Thus, a more robust code rate stability metric under dynamic network conditions is provided. Based on these two modifications, the final defined optimization objective is as follows:

[0058] Further, based on the switching-aware adaptive live streaming method for low-orbit satellite networks provided in the above embodiments, the application also provides a switching-aware adaptive live streaming system for low-orbit satellite networks, which comprises: A switching prediction module is configured to obtain a predicted satellite switching time in the low-orbit satellite network.

[0059] An adaptive segment division module is configured to divide a video stream transmission timeline into a stable period and a switching period based on the predicted satellite switching time, and generate corresponding segment control instructions according to different periods.

[0060] A video data processing module is configured to encapsulate video data in the stable period as segments and encapsulate video data in the switching period as blocks in response to the segment control instructions.

[0061] An adaptive code rate control module is configured to dynamically adjust a video code rate and a playing speed based on a Qoe maximum optimization objective before the switching period based on the predicted satellite switching time, and realize active pre-padding of a buffer.

[0062] In summary, the application proposes a switching-aware adaptive live streaming method (HALS 2 ) for the stability challenge of live video services caused by frequent switching of low-orbit satellite networks (LSNs), which effectively alleviates the problem that existing adaptive bit rate (ABR) algorithms are difficult to stably optimize in a dynamic bandwidth and burst packet loss environment. By introducing a switching prediction driven adaptive segmentation mechanism, video segmentation and buffering strategies can be actively adjusted according to the stable or switching period before switching, effectively reducing the rebuffering events caused by packet loss. At the same time, an adaptive code rate and playing speed joint optimization algorithm for periodic network fluctuations is also designed for the characteristics of bandwidth drop and delay fluctuation during switching, realizing playing continuity guarantee and experience optimization under dynamic link conditions.

[0063] In addition, the method proposed in the application has good deployability, only needs software level integration in the application layer, and can be seamlessly adapted to the existing DASH protocol stack and player framework, avoiding complex modifications to satellite links or terminal devices.

[0064] To verify the effectiveness of the switching-aware adaptive live streaming method (HALS 2 ) proposed in the application in low-orbit satellite networks, the present embodiment also constructs a multi-modal satellite network simulation experiment platform, based on real LEO satellite link modeling and real-time video transmission scene testing, systematically presents the HARS2 Protocol stack end-to-end live performance evaluation data under time-varying bandwidth and long delay constraints.

[0065] Experimental setup: A live simulation test platform for LSNs was designed and built, and through multiple experiments, it was compared and evaluated with existing adaptive algorithms, focusing on performance in a frequent satellite switching environment. The experimental selected CMAB, L2A-LL, BOLA, DYNAMIC, and LOL+ as the control group.

[0066] The entire experimental system was built using Docker container architecture, coordinated and scheduled using Docker Compose, and the platform components mainly included: (1) Live generation module: The open-source framework livesim2 was used to timestamp rewrite VoD DASH resources to simulate continuous live streaming; each segment lasted 2 seconds, and the chunk lasted 500ms. The video dataset used in our measurement came from the CTA WAVE test project. The bit rate ladder is shown in Table 1, which contains 8 different resolutions and frame rates, with a target H.264 encoding bit rate ranging from 300 Kbps to 6000 Kbps.

[0067]

[0068] Table 1 Default bit rate ladder of the video dataset of the CTA WAVE test project (2) Network simulation module: Real Starlink network data (including delay, packet loss rate, and bandwidth) was reproduced using Linux tools such as tc and netem to simulate the LSNs communication environment with frequent switching and bandwidth jitter.

[0069] (3) CDN and player module: Nginx-RTMP was used for CDN deployment; dash.js (v5.0.0) was developed for the player, integrating HALS 2 -G and HALS 2 -L two algorithms; selenium / standalone-chrome was used to automatically control browser behavior and collect playback data; the FastSwitching function was disabled to prevent QoE loss caused by frequent re-requests.

[0070] To comprehensively evaluate the playback experience, the following QoE evaluation formula was used:

[0071] Where the parameter weight configuration is shown in Table 2.

[0072]

[0073] Table 2 QoE metric parameter configuration Key indicators (bitrate, playback speed, live delay) during the playback process are automatically collected by JavaScript every 100 ms and stored in MongoDB for subsequent analysis.

[0074] To verify the robustness of HALS 2 , the experimental test setup includes different target delays (2s, 4s, 6s, 8s to simulate different viewing scenarios) and different network bandwidths (10Mbps, 20Mbps, 40Mbps, 80Mbps to simulate different network conditions). Evaluation indicators include: average live delay and deviation, average bitrate and stability, rebuffering time, comprehensive QoE, etc.

[0075] Evaluation of live delay and stability: The experiment first evaluates the performance of different ABR algorithms under four target delays (2s, 4s, 6s, 8s). Figure 8 It is shown that under the 2s low delay target, the comparative algorithms are difficult to achieve the expected delay, while HALS 2 -L effectively reduces the deviation between the actual delay and the target delay by 53.57% - 77.78% through adaptive segment strategy. As the target delay is relaxed, HALS 2 -G and HALS 2 -L can always keep the live delay close to the target value, and the delay fluctuation is significantly lower than that of the comparative algorithms, showing good delay control ability and robustness.

[0076] Evaluation of bitrate selection and quality stability: In terms of bitrate performance, the experimental results show that all algorithms have an upward trend in bitrate as the delay target is relaxed. Figure 9 However, HALS 2 series algorithm achieves higher average bitrate and smaller fluctuation amplitude under all delay targets, especially in the 2s delay scenario, traditional algorithms (such as Dynamic, Bola, LoL+) show significant performance degradation, while HALS 2 can maintain high video quality while ensuring low delay. This advantage is mainly due to the pre-buffering before switching and re-buffering avoidance mechanism proposed by HALS 2 , which reduces the bitrate degradation phenomenon caused by switching.

[0077] Comparison of rebuffering time: The comparison results of rebuffering time Figure 10 show that HALS 2-L shows the shortest rebuffering time in all delay targets. In the strict 2-second delay target, HALS 2 -L can reduce the rebuffering time by 58.03%-65.67% compared with the baseline algorithm. This performance improvement is due to the HALS 2 By switching the awareness of segment and rate control strategy, the problem of playing interruption caused by switching is effectively alleviated, thereby significantly enhancing the playing continuity.

[0078] Comprehensive QoE performance analysis: In linear QoE and logarithmic QoE two evaluation ways, the comprehensive experience performance of different algorithms under different bandwidth and delay targets is compared and analyzed. The experimental results Figures 11-14 show that HALS 2 -G and HALS 2 -L shows excellent QoE level in all kinds of scenes. In the condition of sufficient bandwidth (40 Mbps) and relaxed delay target (6 seconds), HALS 2 -L improves the average QoE index by 19.91% (linear) and 12.94% (logarithmic) compared with the best comparative algorithm (L2A). Even in the bandwidth limited (10 Mbps) and strict delay requirement (2 seconds), HALS 2 -L can still maintain 1.5 to 2 times the QoE advantage of the existing best algorithm (such as CMAB).

[0079] In addition, it is found that the traditional ABR algorithm is difficult to adapt to the dynamic bandwidth and packet loss caused by frequent switching in LSNs, and is prone to aggressive rate selection, resulting in frequent rebuffering events, which seriously affects the subsequent video quality. The present application introduces a "switching-aware" rate and playing speed joint optimization mechanism, which can actively complete buffer adjustment before the switching event, significantly improving the whole link adaptive ability and user experience.

[0080] From the above experimental results, it can be seen that HALS 2 can reduce the live delay deviation to 77.78% and shorten the rebuffering time to 65.67% in various network environments and delay requirements, and the comprehensive QoE index is 1.2 to 2 times higher than the existing optimal scheme. In summary, the present application realizes the significant improvement of live playing experience in low-orbit satellite network through switching awareness and joint optimization mechanism, and has wide application prospect and industrial value.

[0081] Based on any of the above embodiments, another embodiment of the present application also provides an electronic device, which can include a processor, a communications interface, a memory and a communications bus, wherein the processor, the communications interface and the memory complete the communication with each other through the communications bus. The processor can invoke the logical instructions in the memory to execute the above-mentioned low-orbit satellite network-oriented switching-aware adaptive live streaming method.

[0082] In addition, the logical instructions in the above-mentioned memory can be implemented in the form of a software functional unit and sold or used as an independent product, which can be stored in a computer-readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or part of the technical solutions can be embodied in the form of a software product, which is stored in a storage medium, including a number of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0083] The device embodiments described above are only schematic, wherein the units shown as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Part or all of the modules can be selected to achieve the purpose of the present embodiment according to actual needs. Those skilled in the art can understand and implement without creative labor.

[0084] From the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be realized by means of software and the necessary general hardware platform, and of course, can also be realized by hardware. Based on such understanding, the above technical solutions essentially or the part that contributes to the prior art can be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., including a number of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the method of each embodiment or some part of the embodiment.

[0085] The above describes in detail the switching-aware adaptive live broadcast method for the low-orbit satellite network provided by the embodiment of the present application, and the principle and implementation manner of the present application are described by using specific examples; the above embodiment description is only used to help understand the method of the present application and the core idea thereof; meanwhile, for those skilled in the art, the specific implementation manner and application range can be changed according to the idea of the present application; and in conclusion, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A handover-aware adaptive live streaming method for low earth orbit satellite networks, characterized in that, The application comprises: acquiring a predicted satellite switching occasion in a low-orbit satellite network; based on the predicted satellite switching occasion, using an adaptive segment division mechanism to divide a video stream transmission timeline into a stable period and a switching period, in the stable period, dividing data of the video stream into segments for transmission, and in the switching period, dividing data of the video stream into blocks for transmission; based on the predicted satellite switching occasion, using a switching-aware adaptive bit rate control algorithm to dynamically adjust the video bit rate and the playing speed during the satellite switching process, and proactively pre-filling the playing buffer before the switching occurs; wherein the playing duration of the block is shorter than the playing duration of the segment.

2. The low earth orbit satellite network oriented handoff aware adaptive live streaming method of claim 1, wherein, The switching period is a time window formed by taking the predicted satellite switching occasion as the center and extending a preset time forward and backward, and the stable period is the remaining period other than the switching period. 3.The low earth orbit satellite network oriented handoff-aware adaptive live streaming method of claim 1, wherein, The adaptive segment division mechanism is implemented by updating the MPD file, and the MPD file uses the SegmentTimeline mode to ensure the continuity of the timestamp.

4. The low earth orbit satellite network oriented handoff aware adaptive live streaming method according to claim 1 or 3, characterized in that, The workflow of the adaptive segment division mechanism is as follows: In the server pre-encoding stage, the DASH basic stream is formed according to the bit rate list to initially segment the input video; When the switching predictor is triggered, the initial segments are divided into blocks, and at the same time, the client updates the new MPD file in time according to the minimum Update Period attribute of the old MPD file, and the client player can automatically read the new MPD file and adjust the playing strategy according to the change of the MPD file.

5. The low earth orbit satellite network oriented handoff aware adaptive live streaming method of claim 1, wherein, The adaptive bit rate control algorithm takes the maximization of the QoE function utility as the optimization target, and the evaluation parameters of the QoE function utility at least include the visual quality, the playing fluency and the live delay deviation.

6. The low earth orbit satellite network oriented handoff aware adaptive live streaming method according to claim 1 or 5, characterized in that, The adaptive bit rate control algorithm is specifically: based on the predicted satellite switching occasion and the current playing delay, calculating the ideal playing speed; based on the ideal playing speed, the current buffer state and the predicted remaining time before the switching, determining a candidate combination set including the bit rate and the playing speed that meets the buffer constraint condition, the buffer constraint condition including the long-term constraint of ensuring that the playing buffer is non-empty at any time and the safety constraint of preventing the buffer from underflowing before the predicted switching occurs; from the candidate combination set, selecting the video bit rate and the playing speed combination that maximizes the QoE function utility of the current video segment.

7. The low earth satellite network oriented handoff aware adaptive live streaming method of claim 1, wherein, The adaptive segment division mechanism and the switching-aware adaptive bit rate control algorithm are deployed in the existing DASH or HLS client in the form of a plug-in module, without modifying the satellite link layer or the physical layer. 8.A handover-aware adaptive live streaming system for low earth orbit satellite networks, characterized in that, The application comprises: a switching prediction module for acquiring a predicted satellite switching occasion in a low-orbit satellite network; an adaptive segment division module for dividing a video stream transmission timeline into a stable period and a switching period based on the predicted satellite switching occasion, and generating corresponding segment control instructions according to different periods; a video data processing module, configured to encapsulate video data in the stable period as a segment and encapsulate video data in the switching period as a block in response to the segment control instruction, wherein a playing time length of the block is less than a playing time length of the segment; an adaptive code rate control module, configured to dynamically adjust a video code rate and a playing speed before the switching period based on the predicted satellite switching timing to achieve active pre-padding of a buffer. 9.An electronic device comprising a memory and a processor, the memory storing a computer program, wherein, The processor implements the steps of the low-orbit satellite network-oriented switching-aware adaptive live broadcast method in any one of claims 1 to 7 when executing the computer program.

10. A storage medium, characterized by The storage medium has a plurality of instructions stored therein, and the instructions are adapted to be loaded by the processor to execute the steps of the low-orbit satellite network-oriented switching-aware adaptive live broadcast method in any one of claims 1 to 7.

Images