Switching-aware adaptive live streaming method for low earth orbit satellite networks

Abstract

The application discloses a low-orbit satellite network-oriented switching-aware adaptive live streaming method, which comprises the following steps: acquiring a predicted satellite switching time in a low-orbit satellite network; based on the predicted satellite switching time, adopting an adaptive segmentation division mechanism to divide a video stream transmission time axis into a stable period and a switching period, dividing data of the video stream into segments for transmission in the stable period, and dividing data of the video stream into blocks for transmission in the switching period; based on the predicted satellite switching time, adopting a switching-aware adaptive code rate control algorithm to dynamically adjust a video code rate and a playing speed in a satellite switching process, and proactively pre-filling a playing buffer before the switching occurs; wherein a playing duration of the block is shorter than that of the segment. The switching-aware adaptive live streaming method can effectively alleviate the problems, such as dynamic bandwidth and burst packet loss, which are difficult to be stably optimized and are easily caused by an existing adaptive code rate algorithm in a satellite switching scenario.

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:

[0008] obtaining a predicted satellite switching time in a low-orbit satellite network;

[0009] 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;

[0010] 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 proactively pre-filling the playing buffer before the switching occurs;

[0011] wherein the playing duration of the block is less than the playing duration of the segment.

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

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

[0014] Further, the workflow of the adaptive segmentation division mechanism is as follows:

[0015] In the server pre-encoding stage, the input video is initially segmented according to the bit rate list to form a DASH basic stream;

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

[0017] Further, the adaptive code 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.

[0018] Further, the adaptive code rate control algorithm specifically is:

[0019] Based on the predicted satellite switching occasion and the current playing delay, an ideal playing speed is calculated;

[0020] Based on the ideal playing speed, the current buffer state and the predicted remaining time before switching, a candidate combination set including code rate and playing speed that meets the buffer constraint condition is determined, and the buffer constraint condition includes a long-term constraint that guarantees the playing buffer to be non-empty at any time period, and a safety constraint that the buffer does not underflow before the predicted switching occurs;

[0021] From the candidate combination set, a video code rate and playing speed combination that maximizes the QoE function utility of the current video segment is selected.

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

[0023] According to a second aspect of the present application, the present application further provides a switching-aware adaptive live system for a low-orbit satellite network, comprising:

[0024] A switching prediction module is configured to obtain a predicted satellite switching occasion in a low-orbit satellite network.

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

[0026] 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, wherein the playing time length of the blocks is less than the playing time length of the segments.

[0027] An adaptive code rate control module is configured to dynamically adjust video code rate and playing speed before the switching period based on the predicted satellite switching occasion, so as to realize active pre-filling of the buffer.

[0028] 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 low-orbit satellite network-oriented switching-aware adaptive live streaming methods when executing the program.

[0029] According to a fourth aspect of the present application, the present application also provides a storage medium, wherein a plurality of instructions are stored in the storage medium, and the instructions are adapted to be loaded by a processor to execute the steps of any of the above low-orbit satellite network-oriented switching-aware adaptive live streaming methods.

[0030] By one or more of the above embodiments of the present application, at least the following technical effects can be achieved: The present application proposes a switching-aware adaptive live streaming method aiming at the stability challenges brought by frequent switching of low-orbit satellite networks to 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 bandwidth sudden 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 streaming method of the present application can effectively alleviate the problems that the existing adaptive bit rate algorithm is prone to cause under the dynamic bandwidth and burst packet loss environment in the satellite switching scenario. BRIEF DESCRIPTION OF DRAWINGS

[0031] 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 as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0032] Figure 1 is the packet loss and one-way delay variation in the Starlink provided by the embodiments of the present application;

[0033] Figure 2 is the switching-induced re-buffering event analysis provided by the embodiments of the present application;

[0034] Figure 3 is the segmentation playback failure due to packet loss provided by the embodiments of the present application;

[0035] Figure 4 is the segmentation playback success due to the playability of the block provided by the embodiments of the present application;

[0036] Figure 5 is the HALS provided by the embodiments of the present application 2Design overview

[0037] Figure 6 is the greedy algorithm HALS provided by the embodiment of the present application 2 -Greedy execution process

[0038] Figure 7 is the Lyapunov optimization algorithm HALS based on the embodiment of the present application 2 -Lyapunov execution process

[0039] Figure 8 is the average delay of the ABR algorithm provided by the embodiment of the present application

[0040] Figure 9 is the average bit rate of the ABR algorithm provided by the embodiment of the present application

[0041] Figure 10 is the average rebuffering time of the algorithm provided by the embodiment of the present application

[0042] 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

[0043] 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

[0044] 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

[0045] 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

[0046] 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 those skilled in the art without creative labor fall within the scope of protection of the present application.

[0047] The terms "first", "second", etc. are used only for descriptive purposes and do not connote or imply relative importance or an ordering. Thus, a feature defined with "first", "second" etc. can include one or more features, explicitly or implicitly.

[0048] "A and / or B" includes the following three combinations: A alone, B alone, and a combination of A and B.

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

[0050] In the present 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 present disclosure. In the following description, for purposes of explanation, specific details are set forth. It is apparent to those skilled in the art that the present disclosure can be practiced without using these specific details. In other instances, well-known structures and processes are not elaborated in order not to obscure the description of the present disclosure with unnecessary details. Thus, the present disclosure is not intended to be limited by the embodiments shown, but is to be accorded with the widest scope consistent with the principles and features disclosed.

[0051] In practice, live streaming transmission in LSNs encounters many problems, mainly including the following aspects:

[0052] (1) Network jitter caused by frequent satellite switching significantly reduces service quality.

[0053] When providing live streaming services in low earth orbit satellite networks (LSNs), system performance can be significantly degraded due to frequent link switching. This high-frequency switching is mainly due to the high orbital speed (about 28800 kilometers per hour) of low earth orbit satellites (LEO) 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 switching-induced packet loss can trigger TCP slow start, thereby significantly affecting the throughput performance. Experiments also observed that the severe network jitter caused by satellite switching can seriously damage the quality of live streaming services.

[0054] Based on the analysis of the public dataset provided by LENS, this embodiment further reveals the persistent impact that short-lived handover events can cause. Figure 1 It is shown that significant latency and packet loss fluctuation occurs at every interval of about 15 seconds. Although the RTT is relatively stable in some time slots, the client and server can still enter the TCP slow start phase due to packet loss caused by handover or RTT timeout, which greatly reduces the TCP throughput on which live streaming relies. Figure 2 A typical rebuffering event triggered by handover is shown: in this case, the connection reconstruction at the application layer takes about 2 seconds, causing a user-perceived 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 LSN. 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 handover can compromise the integrity of the entire segment, causing a playback interruption and possibly triggering a rebuffering event, as shown in Figure 3 .

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

[0056] The network conditions of terrestrial networks are generally more stable than those in LSN. Existing ABR algorithms are mainly designed for terrestrial environments, and their goal is usually 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. In addition, these rebuffering events often prompt the ABR algorithm to switch to a lower bit rate, even though a higher quality option may become available immediately after the handover, resulting in suboptimal bit rate selection and reduced QoE.

[0057] 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 in 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.

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

[0059] Adaptive segment division mechanism: To mitigate the rebuffering caused by incomplete segments during handover, HALS 2 An adaptive segment division mechanism is introduced. According to the predicted satellite handover timing, the live streaming session is divided into a handover period and a stable period along the transmission timeline. 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 the resistance to potential interference. As shown in FIG. 2, 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 a segment is longer than that of a chunk, thereby reducing overhead and improving transmission efficiency. This adaptive segment division strategy balances QoE and system efficiency by reducing additional headers. Figure 5

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

[0061] First, the live streaming bitrate decision problem during the handover process of low-orbit satellite networks is modeled.

[0062] In DASH, video content is divided into fixed-length segments with a duration of seconds. Each segment is encoded on 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 the bitrate , where represents the bitrate selected for the i-th video segment.

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

[0064]

[0065] In the formula, is the rebuffering time,​​ and quantify the fluctuations of video quality and playback speed between consecutive segments, respectively, the weight parameters p, h and i adjust the trade-off between different factors, the term reflects the delay bias, where denotes the target delay, defined as the expected end-to-end delay from content generation to client presentation, denotes the delay bias.

[0066] To keep the live playout delay consistent with the target delay , the playback speed must be adjusted accordingly. However, abrupt changes in playback speed can significantly degrade the QoE. Therefore, such adjustment should be done in a smooth and gradual manner. In practical applications, this is usually achieved by defining an ideal playback speed that takes into account both the need to correct the delay drift and the need to maintain playout stability. For example, the default catch-up mechanism in the current version (5.0.0) of the DASH reference player defines as:

[0067]

[0068] where denotes the compensation factor derived from the playback speed list, which defines the allowed adjustment range of the playback speed, i.e. . It is worth noting that the sigmoid function in equation (2) is adopted to ensure that the adjustment of the playback speed is gradual and continuous, thereby reducing the risk of perceptible playout discontinuity. Therefore, the delay bias term and the playback speed fluctuation term in equation can be replaced by a unified bias term . This simplifies the formulation of QoE, which implicitly captures the delay control and smoothness within a single term.

[0069] In practical applications, the rebuffering event is usually the most critical factor that degrades the QoE. To avoid rebuffering and ensure playout continuity, it is necessary to ensure that the playout buffer is never empty, i.e. Ti=0 is always satisfied. To achieve this, the present embodiment defines the net buffer gain of the ith segment as:

[0070]

[0071] where is the estimated available transmission rate (throughput) during the download of the ith segment. The first and second terms in equation (3) represent the playout duration and download duration of the ith segment, respectively, so that reflects the change of the remaining playout time of the buffer. To ensure that the buffer is always non-empty, it is only required that the cumulative net buffer gain of all segments is greater than or equal to zero, which can be expressed as:

[0072]

[0073] where N denotes the number of all segments.

[0074] However, in low earth orbit satellite networks, the actual download rate during handover can deviate from the estimated value , and the constraint (4) is not sufficient to guarantee no rebuffering event. Therefore, the buffer must be pre-filled to a safety level before each handover, so that uninterrupted playout can be guaranteed throughout the handover even if no data is downloaded during the handover.

[0075] To identify the segments whose playout overlaps with the handover, the set of handover occurrence time H is first defined. For example, in the case of Starlink, the handover occurs at the 12th, 27th, 42nd and 57th second of each minute, thus Let denote the playout completion time of the i-th segment, and denote the start time. Based on equation (4), uninterrupted continuous playout is guaranteed:

[0076]

[0077] Therefore, if there exists such that , it is considered that the handover occurs during the playback of the i'-th segment.

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

[0079]

[0080] For convenience, we use These A set of segments. For each segment... To ensure the buffer is in To prevent underflow after time-lapse, the selection of bitrate and playback speed should adhere to the following constraints:

[0081]

[0082] In the formula, For decision-making moments The buffer, ε, is a safety margin to prevent rebuffering. This represents the remaining time until the next handover. In order to be in The maximum number of downloadable segments. The first term of equation (5) quantifies the total amount of video content available for playback before the next handover, including both buffered content and content expected to be downloaded within that interval, and is adjusted by the playback speed. Constraints (4) and (5) guarantee uninterrupted playback, which means that all segments... Based on the above simplifications and constraints, the optimization objective is defined as maximizing the cumulative simplified QoE while satisfying constraints (4) and (5):

[0083]

[0084] In the formula, θ controls the penalty weight for deviations from the ideal playback speed β. HALS 2 The goal is to jointly optimize bitrate and playback speed to maximize cumulative QoE under constraints.

[0085]

[0086] To achieve the optimization objective defined in equation (7), this embodiment first designs the greedy algorithm HALS. 2 -Greedy, meaning that based on current conditions, the myopia decision is made by optimizing the selection of the next segment to maximize the immediate QoE′. Greedy algorithm HALS 2 See the execution process of Greedy. Figure 6 The process first calls the Handover_Predictor() function, which returns a boolean toggle indicating whether the current segment i belongs to set Ki′j. If so, the estimated remaining time h is... t ij This continues until the next switch is also returned. The algorithm then calculates the ideal playback speed β_ideal by calling the `Calculate_Ideal_Speed()` function. Once β_ideal is obtained, HALS... 2-G exhaustively searches from a fixed candidate list for all combinations of bitrates r and playback speeds β. For each combination, the algorithm checks whether it satisfies constraints (4) and (5), and if so, evaluates the corresponding QoE'. Meanwhile, throughout the traversal, HALS 2 - keeps track of.

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

[0088] To overcome the short-sightedness of the greedy algorithm HALS 2 -G, in other embodiments of the present application, HALS 2 -L based on Lyapunov optimization is further introduced, which provides a framework for handling time-averaged objectives under long-term constraints. This algorithm tracks constraint violations by introducing a virtual queue, so that online decisions can optimize both instantaneous utility and guarantee long-term stability and performance. Moreover, it does not require prior knowledge of future network dynamics, making it highly suitable for dynamic and stochastic LSNs. See Figure 7 , HALS 2 -L algorithm works as follows: after obtaining the same 2 -G as HALS , and Handover, the algorithm performs an exhaustive search and tracks the combination (bi, βi) that minimizes DPT. After the search is completed, the selected optimal combination (bi, βi) is used to update the virtual queue Q and b.

[0089] Specifically, HALS 2 -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:

[0090]

[0091] By defining the Lyapunov function , the single-slot conditional Lyapunov drift is:

[0092]

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

[0094]

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

[0096]

[0097] 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: This provides a more robust measure of rate stability under dynamic network conditions. Based on these two modifications, the final optimization objective is defined as follows:

[0098]

[0099] Furthermore, based on the handover-aware adaptive live streaming method for low-Earth orbit satellite networks provided in the above embodiments, this application also provides a handover-aware adaptive live streaming system for low-Earth orbit satellite networks, the system comprising:

[0100] The switching prediction module is used to obtain the predicted satellite switching timing in the low-Earth orbit satellite network.

[0101] The adaptive segmentation module is used to divide the video stream transmission timeline into stable periods and switching periods based on the predicted satellite switching timing, and generate corresponding segmentation control commands according to different periods.

[0102] The video data processing module is used to respond to segmentation control commands by encapsulating video data in stable cycles into segments and video data in switching cycles into blocks.

[0103] The adaptive bitrate control module is used to dynamically adjust the video bitrate and playback speed based on the Qoe maximum optimization target before the switching cycle, based on the predicted satellite switching timing, to achieve proactive pre-filling of the buffer.

[0104] In summary, the present application proposes a handover-aware adaptive live streaming method (HALS 2 ) to address the stability challenges of live video services in low earth orbit satellite network (LSNs) with frequent handovers, effectively alleviating the problem that existing adaptive bitrate (ABR) algorithms are difficult to optimize stably in dynamic bandwidth and burst packet loss environments. By introducing a handover prediction-driven adaptive segmentation mechanism, the video segmentation and buffering strategy can be actively adjusted before handover according to the stable or handover period, effectively reducing the rebuffering events caused by packet loss. At the same time, in view of the characteristics of bandwidth drop and delay fluctuation during handover, an adaptive bitrate and playback speed joint optimization algorithm for periodic network fluctuation is also designed to realize the playback continuity guarantee and experience optimization under dynamic link conditions.

[0105] In addition, the method proposed in the present application has good deployability, only needs software-level integration at the application layer, and can seamlessly adapt to existing DASH protocol stacks and player frameworks, avoiding complex modifications to satellite links or terminal devices.

[0106] To verify the effectiveness of the handover-aware adaptive live streaming method (HALS 2 ) proposed in the present application in low earth orbit satellite networks, the present embodiment also builds 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 end-to-end live performance evaluation data of HARS 2 protocol stack under time-varying bandwidth and long delay constraints.

[0107] Experiment setup: A live simulation test platform for LSNs is designed and built, and through multiple experiments, the performance is compared and evaluated with existing adaptive algorithms, focusing on performance in a frequent satellite handover environment. The experiment selects five mainstream ABR algorithms, CMAB, L2A-LL, BOLA, DYNAMIC, and LOL+, as the control group.

[0108] The entire experimental system is built using Docker container architecture and coordinated and scheduled using Docker Compose. The platform components mainly include:

[0109] (1) Live generation module: The open-source framework livesim2 is used to timestamp rewrite VoD DASH resources to simulate continuous live streaming; each segment is 2 seconds long and each chunk is 500ms long. The video dataset used in our measurement comes from the CTA WAVE test project. The code rate ladder is shown in Table 1 below, which contains 8 different resolutions and frame rates, with a target H.264 encoding code rate ranging from 300 Kbps to 6000 Kbps.

[0110]

[0111] Table 1 Default bitrate ladder for video datasets of CTA WAVE test items

[0112] (2) Network simulation module: using Linux tools like tc and netem, replicate real Starlink network data (including delay, packet loss rate and bandwidth), simulate LSNs communication environment with frequent handover and bandwidth jitter.

[0113] (3) CDN and player module: CDN uses Nginx-RTMP deployment; player uses dash.js (v5.0.0) development, integrated HALS 2 -G and HALS 2 -L two algorithms; use selenium / standalone-chrome to automatically control browser behavior and collect playback data; disable FastSwitching function to prevent QoE loss caused by frequent re-request.

[0114] To comprehensively evaluate the playback experience, the following QoE evaluation formula is used in this experiment:

[0115]

[0116] Among them, the parameter weight configuration is shown in Table 2.

[0117]

[0118] Table 2 QoE metric parameter configuration

[0119] Key indicators (bitrate, playback speed, live delay) during playback are automatically collected by JavaScript every 100ms and stored in MongoDB for subsequent analysis.

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

[0121] Evaluation of live delay and stability:

[0122] The experiment first evaluates the performance of different ABR algorithms under four target delays (2s, 4s, 6s, 8s). Figure 8It is shown that, under the 2s low-delay target, all the compared algorithms are difficult to achieve the expected delay, while HALS 2 By the adaptive segmentation strategy, HALS 2 effectively reduces the deviation between the actual delay and the target delay, with a reduction of 53.57%–77.78%. 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 compared algorithms, demonstrating good delay control ability and robustness.

[0123] Regarding the evaluation of the code rate selection and the quality stability:

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

[0125] Regarding the comparison of re-buffering time:

[0126] Comparison of re-buffering time Figure 10 It is shown that, under all delay targets, HALS 2 -L shows the shortest re-buffering time. Under the strict 2s delay target, HALS 2 -L can reduce the re-buffering time by 58.03%–65.67% compared to the baseline algorithm. This performance improvement is due to the adaptive segmentation and rate control strategy of HALS 2 , which effectively alleviates the playback interruption problem caused by switching, thereby significantly enhancing the playback continuity.

[0127] Comprehensive QoE performance analysis:

[0128] In linear QoE and logarithmic QoE evaluation methods, 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, under all kinds of scenarios, HALS 2 -G and HALS 2 -L show excellent QoE level. Under the condition of sufficient bandwidth (40Mbps) and relaxed delay target (6s), HALS2 L outperforms the best contrastive algorithm (L2A) by 19.91% (linear) and 12.94% (log) in average QoE. Even under bandwidth constraint (10 Mbps) and strict delay requirement (2 seconds), HALS 2 L still maintains 1.5 to 2 times QoE advantage over the existing best algorithm (e.g., CMAB).

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

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

[0131] Based on any of the above embodiments, another embodiment of the present application further 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 mutual communication through the communications bus. The processor can call logical instructions in the memory to execute the above-mentioned switching-aware adaptive live streaming method for low-orbit satellite networks.

[0132] In addition, the logic instructions in the memory described above can be implemented in the form of a software function unit and sold or used as an independent product, and can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the parts that contribute to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of the embodiments of the present application. The aforementioned 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.

[0133] The device embodiments described above are only schematic, and the units illustrated as separate components can or can not be physically separated, and the components illustrated 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 embodiment according to actual needs. Those skilled in the art can understand and implement without creative labor.

[0134] From the above description of the embodiments, those skilled in the art can clearly understand that the embodiments can be implemented by means of software and the necessary general hardware platform, and of course can also be implemented by hardware. Based on such understanding, the above technical solutions essentially or the parts that contribute to the prior art can be embodied in the form of a software product. The computer software product can be stored in a computer readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of the embodiments or some parts of the embodiments.

[0135] The above describes in detail a switching-aware adaptive live streaming method for low earth orbit satellite networks provided by the embodiments of the present application. The principles and implementation manners of the present application are described by applying specific examples. The above embodiment descriptions are only used to help understand the method of the present application and its core idea; meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation manners and application ranges will be changed. In summary, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A handover-sensing adaptive live broadcast method for low-Earth orbit satellite networks, characterized in that, include: Obtain predicted satellite handover timings in low-Earth orbit satellite networks; Based on the predicted satellite switching timing, an adaptive segmentation mechanism is used to divide the video stream transmission time axis into a stable period and a switching period. During the stable period, the video stream data is divided into segments for transmission, and during the switching period, the video stream data is divided into blocks for transmission. Based on the predicted satellite switching timing, a switching-aware adaptive bitrate control algorithm is used to dynamically adjust the video bitrate and playback speed during the satellite switching process, and the playback buffer is actively pre-filled before the switching occurs. The playback duration of the block is less than the playback duration of the segment.

2. The handover-aware adaptive live broadcast method for low-Earth orbit satellite networks according to claim 1, characterized in that, The switching cycle is a time window centered on the predicted satellite switching timing and extended forward and backward by a preset time. The stable period is the remaining time period excluding the switching cycle.

3. The handover-aware adaptive live broadcast method for low-Earth orbit satellite networks according to claim 1, characterized in that, The adaptive segmentation mechanism is implemented by updating the MPD file, which uses the SegmentTimeline mode to ensure the continuity of timestamps.

4. The handover-aware adaptive live broadcast method for low-Earth orbit satellite networks according to claim 1 or 3, characterized in that, The workflow of the adaptive segmentation mechanism is as follows: During the server pre-encoding stage, the input video is initially segmented based on the DASH elementary stream formed according to the bitrate list. When the switching predictor is triggered, the initial segment is divided into blocks. At the same time, the client updates the new MPD file in a timely manner according to the minimum update period attribute of the old MPD file. The client player automatically reads the new MPD file and adjusts the playback strategy according to the changes in the MPD file.

5. The handover-aware adaptive live broadcast method for low-Earth orbit satellite networks according to claim 1, characterized in that, The adaptive bitrate control algorithm aims to maximize the utility of the QoE function, and the evaluation parameters of the QoE function utility include at least visual quality, playback smoothness, and live streaming latency deviation.

6. The handover-aware adaptive live broadcast method for low-Earth orbit satellite networks according to claim 1 or 5, characterized in that, The adaptive rate control algorithm is specifically as follows: Calculate the ideal playback speed based on the predicted satellite switching timing and the current playback delay; Based on the ideal playback speed, the current buffer state, and the predicted remaining time before the switch, a set of candidate combinations of bitrate and playback speed that satisfy the buffer constraints are determined. The buffer constraints include a long-term constraint that ensures the playback buffer is non-empty at any time, and a safety constraint that the buffer does not underflow before the predicted switch occurs. From the candidate combination set, select the video bitrate and playback speed combination that maximizes the QoE function utility of the current video segment.

7. The handover-aware adaptive live broadcast method for low-Earth orbit satellite networks according to claim 1, characterized in that, The adaptive segmentation mechanism and the handover-aware adaptive rate control algorithm are deployed as pluggable modules in existing DASH or HLS clients without requiring modification of the satellite link layer or physical layer.

8. A handover-aware adaptive live broadcast system for low-Earth orbit satellite networks, characterized in that, include: The switching prediction module is used to obtain the predicted satellite switching timing in the low-Earth orbit satellite network. An adaptive segmentation module is used to divide the video stream transmission time axis into a stable period and a switching period based on the predicted satellite switching timing, and generate corresponding segmentation control commands according to different periods. A video data processing module is configured to, in response to the segmentation control command, encapsulate video data in the stable period into segments and video data in the switching period into blocks, wherein the playback duration of the blocks is less than the playback duration of the segments. An adaptive bitrate control module is used to dynamically adjust the video bitrate and playback speed before the switching cycle based on the predicted satellite switching timing, thereby achieving proactive pre-filling of the buffer.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the handover-aware adaptive live broadcast method for low-Earth orbit satellite networks as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a plurality of instructions adapted for loading by a processor to execute the steps of the handover-aware adaptive live broadcast method for low-Earth orbit satellite networks as described in any one of claims 1 to 7.

Images