Server-side adaptive SVC ABR method based on MPQUIC and prefetching

Abstract

The present invention discloses a server-side adaptive SVC ABR method based on MPQUIC and pre-fetching, wherein the client sends multiple video requests concurrently, the server extracts application layer information, and calculates the size of the client video buffer and the available bandwidth; then selects the corresponding video layer transmission strategy and makes a video stream selection decision; after the server sends the video stream to the client, when the video playback of the client freezes, the server dynamically adjusts the cutoff time of subsequent video clips until the entire video is played. The present invention can quickly respond to changes in the network environment and improve the bandwidth resource utilization of each sub-path. Compared with the existing ABR solution, the present invention can improve the overall video QoE by 40%, the average bit rate by 28%, and the average quality switching times are reduced by 15% compared with the existing ABR solution.

Description

Technical Field

[0001] The present invention relates to the field of video transmission, and in particular to a server-side adaptive SVC ABR method based on MPQUIC and pre-fetching. Background Art

[0002] HTTP Adaptive Streaming (HAS) is one of the main technologies for video transmission. In the HAS system, the server divides the video into segments of equal length and then encodes these segments into multiple quality levels. The client then requests the corresponding video segments based on the existing conditions according to the Adaptive Bitrate (ABR) algorithm to provide the best user experience quality (QoE) in the case of network fluctuations.

[0003] In the HAS system using Scalable Video Coding (SVC), each video segment consists of a base layer and multiple enhancement layers. The base layer is the minimum playback condition, while the enhancement layer needs to rely on the base layer and the lower enhancement layer for decoding, thereby improving the video playback quality on the client. This layered structure allows the client to select the corresponding quality layer according to the network status during video playback to improve the quality of the buffered segment, thereby reducing bandwidth waste and achieving scalability of playback bit rate, allowing video service providers to better meet users' needs for different quality, while also providing a technical basis for achieving higher dynamic adaptability.

[0004] Multipath transmission technology is also widely used in the field of video transmission optimization by aggregating the bandwidth of multiple paths. However, existing ABR algorithms usually adopt a blocking single request method on the client side, that is, a new request is initiated only after the previous request is completed. Figure 1 , Figure 2 As shown, Figure 1 In the transport layer, due to path scheduling, the tail of the file transfer is likely to be idle due to no data being sent. Figure 2 In the application layer, there is at least one transmission gap between the end of the previous request and the arrival of the next request. Therefore, this method fails to fully utilize the multipath bandwidth to improve the QoE of the video, resulting in significant bandwidth waste, especially in the SVC scenario where frequent requests are required.

[0005] Since direct prefetching is a coarse-grained decision-making method, it essentially wastes the fine-grained scalability function of SVC, which leads to a contradiction between prefetching and SVC scalability. Therefore, the existing traditional SVC ABR algorithm does not consider the prefetching situation, but adjusts the download strategy according to the network conditions each time a video layer is downloaded. Therefore, the current ABR algorithm in the SVC scenario still has the technical problem of failing to effectively utilize multi-path bandwidth resources and maximizing user QoE. Summary of the invention

[0006] In order to solve the technical problem that the ABR algorithm in the current SVC scenario cannot utilize multipath bandwidth resources, the present invention provides a server-side adaptive SVC ABR method based on MPQUIC and prefetching, which can effectively utilize multipath bandwidth for video transmission and achieve fine-grained adjustment to maximize user QoE.

[0007] In order to achieve the above technical objectives, the technical solution of the present invention is a server-side adaptive SVC ABR method based on MPQUIC and pre-fetching, comprising the following steps:

[0008] Step 1: The server receives multiple video requests initiated simultaneously in a concurrent manner, wherein the multiple video requests are initiated by a single client having a video playback requirement, each video request corresponds to a video layer in a video segment of the video, and the video request includes application layer information of the video layer;

[0009] Step 2: The server extracts the application layer information in the video request and calculates the amount of video clips that can be played in the client video playback buffer according to the current video stream transmission situation. cur The size of the packet and the available bandwidth are estimated based on the current congestion window and round-trip time.

[0010] Step 3: The server receives the application layer information and B cur The size and available bandwidth of B select the corresponding video layer transmission strategy and make a video stream selection decision; the video layer transmission strategy is based on B cur To decide: When B cur When B is insufficient, the base layer data in the video layer is transmitted first; cur When B is moderate, the base layer and enhancement layer data in the video layer are transmitted in a balanced manner to maintain video quality. cur When the data of the enhancement layer in the video layer is sufficient, the enhancement layer data in the video layer is transmitted first; the selection decision of the video stream is completed through the following steps: First, check B cur , if B curIf the available bandwidth is insufficient, only the base layer is added to the transmission queue to wait for transmission; otherwise, all video requests are traversed in sequence according to the application layer information for screening, and then the bandwidth required for the filtered video requests is calculated. If the available bandwidth meets the required bandwidth, the video stream corresponding to the video request is added to the transmission queue to wait for transmission;

[0011] Step 4: The server sends the video stream in the transmission queue to the client. When the video playback of the client is stuck, the server obtains the stuck situation by receiving the custom MPQUIC control frame from the client, and postpones the corresponding deadline of the subsequent video segment according to the specific stuck duration to achieve dynamic adjustment until the entire video is played.

[0012] In the method, in step 1, multiple video requests are initiated simultaneously in a concurrent manner, wherein each video request sequentially requests video layers of each quality level of the corresponding video segment in order from low to high; the application layer information of the video layer includes the video segment number, the requested video layer number and the deadline of the video segment.

[0013] The method, in step 2, calculates the amount of video clips B that can be played in the client video playback buffer. cur The sizes include:

[0014] All concurrent video requests are traversed in sequence. When the first video segment whose base layer has not been completely downloaded is encountered, the difference between the previous video segment number of this video segment and the currently playing video segment number is used as B cur .

[0015] In the method described above, whether a certain video layer has been completely downloaded is determined according to the following method:

[0016] When at least one of the following conditions is met, it is determined that the current video layer has been successfully transmitted:

[0017] 1) A higher video layer request has been received for the same video segment;

[0018] 2) All data of the video layer has been sent, and all packets carrying the video layer data frames have been confirmed.

[0019] The method is characterized in that in step 2, estimating the available bandwidth according to the current congestion window and round trip time is achieved by the following formula:

[0020] ;

[0021] Among them, BW avail Indicates the available bandwidth, CWNDpath irepresents the congestion window of subpath i, sRTTpath i represents the smoothed round trip time of subpath i, and n is the number of subpaths.

[0022] The method, in step 3, according to the video clip amount B in the client video playback buffer cur To determine the scheduling strategy, judge B cur Whether it is sufficient is determined based on the following process:

[0023] Set a maximum threshold B max When B cur No more than B max One third of cur Insufficient; when B cur Greater than B max When it is two-thirds of cur Sufficient, otherwise it is considered B cur Moderate.

[0024] The method described above, in judging B cur At the same time, it also includes the step of updating the highest layer of the video layer currently allowed to be transmitted:

[0025] Setting parameter L allowed As the highest layer of the video layer currently allowed to be transmitted, L allowed The initial value of is the layer corresponding to the average playback bitrate of the client buffer;

[0026] When B cur If it is insufficient, L allowed Updated to 0, when B cur When it is moderate, L allowed remain unchanged, when B cur When it is sufficient, L allowed Increase by 1.

[0027] In the method, in step 3, when making a video stream selection decision, all video requests are sequentially traversed for screening according to the application layer information, in the order from the next video segment to be played to the request with the current largest video segment number, and the segments in the request queue are sequentially traversed. If any of the following conditions is met, the request will be discarded:

[0028] ①The request is empty;

[0029] ②The current time has exceeded the deadline;

[0030] ③The layer number exceeds L allowe The highest allowed video layer;

[0031] Next calculate , that is, the bandwidth required to transmit the request stream S, when the calculated BW need When it is greater than the available bandwidth and S is an enhanced layer, the transmission request stream S is abandoned; finally, the filtered stream will be added to the transmission queue sendStreams, and the amount of data transmitted totalSend will be updated, where S.remain is the remaining data amount of the current request stream, DDL is the deadline, and now is the current time.

[0032] In the method, in step 4, the client-defined MPQUIC control frame includes the following information for indicating the jamming situation:

[0033] Intrinsic parameters VIDEO_INITIAL for initializing video and client information, including the number of video segments, the playback duration of a single video segment, and the maximum capacity of the client buffer;

[0034] The deadline VIDEO_SYNCHRONOUS used to synchronize video playback and update subsequent video segments, including the latest played video segment number and playback timestamp;

[0035] VIDEO_INITIAL is used to synchronize the server and client at the beginning of video playback, while VIDEO_SYNCHRONOUS is used to synchronize the server and client at the beginning of each video segment.

[0036] The technical effect of the present invention is that the present invention takes the problem of underutilization of bandwidth resources that is prevalent in multi-path scenarios as a starting point, designs an ABR solution executed on the server side, and the present invention can quickly respond to changes in the network environment and improve the bandwidth resource utilization of each sub-path. Compared with the existing ABR solution, the present invention can improve the overall video QoE by 40%, the average bit rate by 28%, and the average quality switching times by 15% compared with the existing ABR solution. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 This is a schematic diagram showing that a single file request method in the prior art may result in an idle path.

[0038] Figure 2 A schematic diagram of the interval between file transmissions in the prior art.

[0039] Figure 3 It is a schematic diagram of the architecture of the present invention.

[0040] Figure 4 A schematic diagram of concurrent requests of the present invention.

[0041] Figure 5It is a schematic diagram of the algorithm process of the flow selection method adopted in the present invention.

[0042] Figure 6 Schematic diagram of network traces of the network data set in the comparative example, where (a) is a high-bandwidth schematic diagram of trace1, (b) is a medium-bandwidth schematic diagram of trace2, and (c) is a low-bandwidth schematic diagram of trace3.

[0043] Figure 7 It is a schematic diagram comparing the overall QoE performance of the present invention and the benchmark solution in the comparative example.

[0044] Figure 8 Schematic diagram for comparing the performance of specific QoE indicators of the present invention and the benchmark solution in the comparative example, wherein (a) is a schematic diagram for comparing the bit rate (MBps / sec), (b) is a schematic diagram for comparing the number of quality switching times, (c) is a schematic diagram for comparing the startup delay, and (d) is a schematic diagram for comparing the buffering time.

[0045] Fig. 9 This is a schematic diagram of the proportion of playback bitrate under different ABR algorithms. DETAILED DESCRIPTION

[0046] This embodiment discloses a server-side adaptive SVC ABR method based on MPQUIC and pre-fetching, including the following steps:

[0047] Step 1, the server receives multiple video requests initiated simultaneously in a concurrent manner, wherein the multiple video requests are initiated by a single client with a video playback requirement, each video request corresponds to a video layer in a video segment, and the video request includes application layer information of the video layer. In this step 1, multiple video requests are initiated simultaneously in a concurrent manner, wherein each video request sequentially requests video layers of each quality level of the corresponding video segment in order from low to high; the application layer information of the video layer includes the video segment number, the requested video layer number, and the deadline of the video segment.

[0048] Step 2: The server extracts the application layer information in the video request and calculates the amount of video clips that can be played in the client video playback buffer according to the current video stream transmission situation. cur The size of the packet is calculated, and the available bandwidth is estimated based on the current congestion window and round-trip time.

[0049] In this step 2, the amount of video clips that can be played in the client video playback buffer is calculated. cur The sizes include:

[0050] All concurrent video requests are traversed in sequence. When the first video segment whose base layer has not been completely downloaded is encountered, the difference between the previous video segment number of this video segment and the currently playing video segment number is used as B cur . To determine whether a video layer has been completely downloaded:

[0051] When at least one of the following conditions is met, it is determined that the current video layer has been successfully transmitted:

[0052] 1) A higher video layer request has been received for the same video segment;

[0053] 2) All data of the video layer has been sent, and all packets carrying the video layer data frames have been confirmed.

[0054] At the same time, the available bandwidth is estimated based on the current congestion window and round-trip time, which is achieved through the following formula:

[0055] ;

[0056] Among them, BW avail Indicates the available bandwidth, CWNDpath i represents the congestion window of subpath i, sRTTpath i represents the smoothed round trip time of subpath i, and n is the number of subpaths.

[0057] Step 3: The server receives the application layer information and B cur The size and available bandwidth of B select the corresponding video layer transmission strategy and make a video stream selection decision; the video layer transmission strategy is based on B cur To decide: When B cur When B is insufficient, the base layer data in the video layer is transmitted first; cur When B is moderate, the base layer and enhancement layer data in the video layer are transmitted in a balanced manner to maintain video quality. cur When the data of the enhancement layer in the video layer is sufficient, the enhancement layer data in the video layer is transmitted first; the selection decision of the video stream is completed through the following steps: First, check B cur , if B cur If the available bandwidth is insufficient, only the base layer is added to the transmission queue to wait for transmission; otherwise, all video requests are traversed in sequence according to the application layer information for screening, and then the bandwidth required for the filtered video requests is calculated. If the available bandwidth meets the required bandwidth, the video stream corresponding to the video request is added to the transmission queue to wait for transmission.

[0058] In this step 3, according to the video clip amount B in the client video playback buffer cur To determine the scheduling strategy, judge B curWhether it is sufficient is determined based on the following process:

[0059] Set a maximum threshold B max When B cur No more than B max One third of cur Insufficient; when B cur Greater than B max When it is two-thirds of cur Sufficient, otherwise it is considered B cur Moderate.

[0060] In judging B cur At the same time, it also includes the step of updating the highest layer of the video layer currently allowed to be transmitted:

[0061] Setting parameter L allowed As the highest layer of the video layer currently allowed to be transmitted, L allowed The initial value of is the layer corresponding to the average playback bitrate of the client buffer;

[0062] When B cur If it is insufficient, L allowed Updated to 0, when B cur When it is moderate, L allowed remain unchanged, when B cur When it is sufficient, L allowed Increase by 1.

[0063] When making a video stream selection decision, all video requests are traversed in sequence according to the application layer information for screening, from the next video segment to be played to the current request with the largest video segment number, and the segments in the request queue are traversed in sequence. If any of the following conditions is met, the request will be discarded:

[0064] ①The request is empty;

[0065] ②The current time has exceeded the deadline;

[0066] ③The layer number exceeds L allowe The highest allowed video layer;

[0067] Next calculate , that is, the bandwidth required to transmit the request stream S, when the calculated BW need When it is greater than the available bandwidth and S is an enhanced layer, the transmission request stream S is abandoned; finally, the filtered stream will be added to the transmission queue sendStreams, and the amount of data transmitted totalSend will be updated, where S.remain is the remaining data amount of the current request stream, DDL is the deadline, and now is the current time.

[0068] Step 4: The server sends the video stream in the transmission queue to the client. When the video playback of the client is stuck, the server obtains the stuck situation by receiving the custom MPQUIC control frame from the client, and postpones the corresponding deadline of the subsequent video segment according to the specific stuck duration to achieve dynamic adjustment until the entire video is played.

[0069] The client-defined MPQUIC control frame includes the following information to indicate the jamming situation:

[0070] Intrinsic parameters VIDEO_INITIAL for initializing video and client information, including the number of video segments, the playback duration of a single video segment, and the maximum capacity of the client buffer;

[0071] The deadline VIDEO_SYNCHRONOUS used to synchronize video playback and update subsequent video segments, including the latest played video segment number and playback timestamp;

[0072] VIDEO_INITIAL is used to synchronize the server and client at the beginning of video playback, while VIDEO_SYNCHRONOUS is used to synchronize the server and client at the beginning of each video segment.

[0073] See also Figure 3 This embodiment also proposes a server-side adaptive SVC ABR architecture based on MPQUIC and prefetching. The overall architecture is divided into five modules. The concurrent stream prefetching module and the deadline correction module are located on the client side. Through multi-threaded requests and connection multiplexing, the client information is conveyed to the server side, so that the MPQUIC server side has basic stream scheduling capabilities. The cross-layer information perception module, bandwidth prediction module, and stream scheduling module are located on the server side, which parse the application layer information from the client and make stream scheduling decisions based on it, thereby controlling the client video playback bit rate and achieving the ABR effect.

[0074] This embodiment integrates a concurrent stream pre-fetching module and a deadline correction module on the client side, and integrates a cross-layer information perception module, a bandwidth prediction module, and a stream scheduling module on the server side. The concurrent stream pre-fetching module, the deadline correction module, and the cross-layer information perception module create the necessary conditions for efficient stream scheduling at the transport layer. Subsequently, the stream scheduling module determines which streams to transmit and the order of transmission through fine-grained stream scheduling to quickly respond to network changes.

[0075] The workflow is as follows:

[0076] 1. When the client has a video playback demand, the concurrent stream prefetching module located on the client will simultaneously initiate multiple video requests carrying application layer information. Each video segment corresponds to a video request, where each video layer request is a sequential request, which means that the next request will be issued only after the previous request is completed. It contains application layer information such as the segment number (SegmentNumber, SegNum), the requested video layer number (Layer Number, LayerNum), and the playback time (Deadline, DDL) of the video segment;

[0077] 2. When the server receives a video request from the client, the cross-layer information perception module located in the server-side transport layer will parse the request, extract the SegNum, LayerNum and DDL, and evaluate the status of the client video buffer in combination with the current video stream transmission status, and calculate the current client video buffer size B cur At the same time, the bandwidth prediction module estimates the available bandwidth based on the congestion window and smoothed round trip time (RTT) detected by the server transport layer, and provides the available bandwidth to the flow scheduler. This information will be provided to the flow scheduling module for scheduling decisions;

[0078] 3. The stream scheduling module performs packet-level video stream scheduling based on the application layer information and buffer status parsed by the cross-layer information perception module and the available bandwidth calculated by the bandwidth prediction module. The scheduled stream will be pushed to the send buffer and prepared for transmission to the client;

[0079] 4. After receiving the video data, the client will reconstruct the video stream, decode the video, and play the video stream in sequence;

[0080] 5. The deadline correction module monitors the video playback status in real time. If a video freeze occurs in a certain video segment, the deadline of this segment and all subsequent segments will be adjusted. The corrected deadline is passed to the cross-layer information perception module of the server through a custom MPQUIC control frame to update the deadline of the video segment.

[0081] Next, we will introduce several sub-modules:

[0082] Concurrent stream prefetching module: This module is used to implement concurrent requests for video streams by combining the multiplexing function of MPQUIC. Specifically, multiple video requests are initiated simultaneously, and each video segment in the buffer corresponds to an independent request thread. Each thread requests the quality level of the video segment in a bottom-up manner, and carries information such as segment number, layer number, and deadline when issuing the request. Figure 4 shown.

[0083] Deadline correction module: For server-side stream scheduling, the deadline of each video segment is a key parameter. However, due to video freezes and the possibility of rebuffering, the deadline of the video segment may change. In order to solve this problem, this embodiment introduces a deadline correction module on the client side, which dynamically corrects the deadline of the video segment by using a custom control frame. Specifically, when the video starts playing a certain segment, the client notifies the video server through a custom MPQUIC control frame to adjust the deadline (revisedDDL) of all subsequent video segments. This ensures that the video segment is transmitted before its deadline, thereby avoiding rebuffering events of the video segment and improving QoE.

[0084] Cross-layer Information Awareness Module: The Cross-layer Information Awareness Module located on the server side enables the video server to manage the layer information of each requested stream during SVC playback. By analyzing the packet confirmation frame and combining the arrival of subsequent requests, the module determines whether the video layer is successfully transmitted. In addition to parsing the request from the client to obtain the application layer information (SegNum, LayerNum, and DDL), the module also evaluates the current buffer status of the client to obtain the size of the client's current buffer B cur , and then SegNum, LayerNum, DDL and B cur The data are sent together to the flow scheduling module for subsequent fine-grained flow scheduling.

[0085] Calculate B cur The core idea is to determine the index of the latest segment whose base layer has been completely downloaded and all the base layers of the previous segments have also been completely downloaded. For example, suppose that the current video segment 5 has been played and the current video segments 6, 7, 8, 9 and 10 are requested, and the base layers of 6, 7 and 8 have been downloaded, then B cur The size is 3. Therefore, in this embodiment, it is necessary to traverse all concurrent requests in sequence until the first base layer segment that has not been completely downloaded is encountered. For each video layer, there are two conditions to determine whether it has completely arrived at the client: 1) The high-level request under the same video segment has arrived, which means that the client has completely received all the low-level layers of the same video segment; 2) All data of the video layer has been sent, and the packets carrying the data frames of the video layer have been confirmed. After each video layer is judged to be complete, there is no need to judge again.

[0086] Bandwidth prediction module: Use MPQUIC's real-time congestion window (CWND) and smoothed round-trip time (sRTT) to calculate the available bandwidth availBW and provide it to the flow scheduling module for scheduling. The bandwidth prediction method used in this embodiment continues the method in MPQUIC, which fully considers the real-time CWND and sRTT, and the calculation formula is as follows:

[0087] ;

[0088] Among them, CWNDpath i represents the congestion window of subpath i, sRTTpath i represents the smoothed RTT of subpath i.

[0089] The flow scheduling module of this embodiment implements a fine-grained flow scheduling strategy to quickly respond to network changes. For ease of understanding, the strategy is introduced in three steps: (i) scheduling strategy selection stage; (ii) transmission flow decision stage; (iii) data packet transmission stage. After the first two stages are completed, the data packets will be scheduled in sequence according to the minRTT data packet scheduling algorithm and transmitted on multiple sub-paths. Therefore, the first two stages are not described in detail.

[0090] Scheduling strategy selection stage: In this stage, three sub-strategies are implemented, and one of the scheduling strategies is dynamically selected according to the status of the client buffer to improve the video playback quality and ensure the smoothness of playback, thereby optimizing the video QoE. Among them, Bavoid_switch represents the threshold for avoiding quality switching, and Benhance_quality represents the threshold for enhancing playback quality. In addition, this embodiment adopts a parameter L allowed , representing the highest level of transmission allowed. allowed The default value of is the average playback bit rate of the client buffer. max = 20, B avoid_switch =⌈B max / 3⌉,B enhance_quality = ⌈2 / 3 B max ⌉. The three-seed strategy and Lallowed updates are as follows:

[0091] Basic layer guarantee strategy: When the video clips in the client's video playback buffer are insufficient (i.e., B cur ≤B avoid_switch ), this strategy is enabled, giving priority to transmitting base layer data to ensure the continuity of video playback. When this strategy is selected, L allowedUpdated to 0, which is the corresponding base layer.

[0092] Stable video playback strategy: When the buffer is half full (i.e. B avoid_switch < B cur ≤B enhance_quality ), this strategy is activated, by balancing the transmission of data at each layer to avoid sudden changes in video quality, thereby maintaining smooth playback. Under this strategy, L allowed Remain unchanged.

[0093] Enhancement layer priority strategy: When the buffer is fully filled (i.e. B cur > B enhance_quality ), this strategy is enabled, focusing on transmitting enhanced layer data to significantly improve playback quality and enrich the overall video experience. When this strategy is selected, L allowed It needs to be increased by 1. In a specific implementation, the enhancement layer other than the base layer may include multiple layers. In this embodiment, the highest layer is 3.

[0094] The strategy is designed with the hierarchical nature of SVC in mind, making dynamic and fine-grained adjustments based on real-time network and buffer conditions to optimize video QoE.

[0095] Transport Stream Decision Phase: In this phase, three goals need to be achieved: (i) prevent the transmission of invalid video layers or layers that cause significant quality switching; (ii) ensure that the currently required video layers can be transmitted completely and in a timely manner; (iii) maintain continuous data transmission so that the transmission path remains active and avoids idleness.

[0096] See also Figure 5 In order to achieve these three goals, the core idea of ​​the stream selection method adopted in this embodiment is as follows: first, the buffer status of the client is evaluated. If the buffer is insufficient, the base layer is queued for transmission ( Figure 5 Otherwise, the algorithm iterates through the segments in the request queue in order (from the next segment to be played to the latest segment) ( Figure 5 For each segment request, its deadline and corresponding stream layer information are provided by the cross-layer information sensing module (in Figure 3 The request will be discarded if any of the following conditions are met: the request is empty, the current time has exceeded the deadline, or the layer number exceeds the maximum allowed layer ( Figure 5 Next, we calculate BWneed, the bandwidth required to transmit the requested stream S, and check whether the available bandwidth BWavail can meet this requirement; if S is an enhancement layer and the available bandwidth is insufficient, the request is abandoned ( Figure 5 Finally, the streams that pass these filters are added to the transmission queue sendStreams, and the amount of data transmitted totalSend is updated ( Figure 5 18-19 in the figure).

[0097] It is important to note that the relationship between flows and paths can be one-to-many; in other words, after this stage, a single flow can be transmitted through multiple paths simultaneously.

[0098] Comparative Example:

[0099] In this comparative example, Mininet is used to simulate the experimental environment to comprehensively evaluate the performance of the present invention. Mininet is a network simulator that can create a realistic virtual network and can simulate the video request from the client to the server in the present invention. In addition, in this comparative example, the Go language is used to implement the video server based on MPQUIC, and AStream (an open source virtual player that can simulate video playback) is modified as the client player to support SVC video playback.

[0100] Experimental setup:

[0101] Video source: In the simulation experiment, various algorithms are evaluated by using the completely open-source video "Big Buck Bunny", which has a resolution of 720p and a frame rate of 24 fps. The video consists of four layers, including a base layer (BL) and three enhancement layers (EL), and the clips of each layer last for 2 seconds. The average bit rates are: 189.84 KBps, 330.80 KBps, 555.08 KBps, 837.13 KBps. The playback bit rate of each bit rate is the cumulative sum of all bit rates from the base layer to the enhancement layer.

[0102] Benchmark solution: As a server-side alternative to the traditional SVC ABR algorithm, the present invention is essentially a variant of the ABR algorithm. For comparison, some representative SVC ABR algorithms are selected in this comparative example, including:

[0103] Backfilling: This is a buffer-based ABR algorithm that first fills the base layer in the buffer in order, and then requests higher layers of the video fragment in reverse order, trying to avoid downloading useless video layers;

[0104] RASD: This is a hybrid ABR algorithm. After downloading the base layer, RASD evaluates whether the current buffer is sufficient and chooses to backfill the buffer with enhancement layers. The number of enhancement layers is lower than the number of layers determined by the current bitrate and bandwidth decision;

[0105] H2BR: This is a hybrid ABR algorithm that takes advantage of the multi-stream and priority features of QUIC. When bandwidth and buffer are sufficient, the next base layer and the enhancement layer in the buffer are requested in parallel based on priority and deadline. When there is not enough time or buffer, the download of the enhancement layer is stopped;

[0106] mpBack 2 : When the buffer is sufficient, select the current highest bit rate based on the multipath bandwidth, and when the buffer is insufficient, use the bandwidth of the faster path. 2 In , each subpath downloads the video layer separately.

[0107] It is worth noting that the above algorithms are all run on the client side, while this method is run on the server side.

[0108] Evaluation indicators: Same as mpBack 2 , this embodiment uses an overall evaluation table to evaluate the overall QoE of video stream transmission, as shown in the following formula:

[0109] QoE = rB×a0-(sD×a1+rC×a2+uC×a3+uD×a4);

[0110] Where rB represents the average video bitrate during playback (in KBps). sD represents the startup delay. rC and uC represent the number of quality switching and freeze events, respectively. uD represents the total freeze duration during video playback (in seconds). 2 In the example, coefficients a0, a1, a2, a3, and a4 are set to 0.236, 0.049, 0.092, 0.436, and 0.187, respectively. The same values ​​are used in this comparative example. In addition, this comparative example uses the following metrics to evaluate the detailed QoE of video playback: (1) average bitrate, (2) number of quality switching times, (3) startup delay, and (4) rebuffering time. All experimental results are the average of 50 runs.

[0111] Network Dataset: This comparison builds an experimental environment to simulate the process of a client requesting video data from a server through two network paths. The delays of these two paths are 22ms and 53ms respectively, and both have a packet loss rate of 0.1%. In order to truly simulate network conditions, this comparison uses three network traces from the open source project Pensive. The detailed information is as follows: Figure 6As shown in the figure, high-bandwidth traces are assigned to faster paths, and low-bandwidth traces are assigned to slower paths, thereby establishing three different multi-path scenarios: Scenario 1 combines (trace 1) and (trace 2), Scenario 2 combines (trace 1) and (trace 3), and Scenario 3 combines (trace 2) and (trace 3). These scenarios are used to evaluate the video playback experience quality of the present invention under different network conditions.

[0112] Figure 7 The overall QoE comparison between the present invention and various benchmark algorithms under different network environments is shown. In different network scenarios, the present invention always provides the best overall QoE, followed closely by mpBack 2 , and H2BR performs the worst. It is worth noting that under poor network conditions, the present invention still performs well. Specifically, compared with Backfilling, RASD, H2BR and mpBack 2 In comparison, the average overall QoE of the present invention is improved by 36.5%, 43.8%, 68.5% and 14.1% respectively.

[0113] These improvements are due to two reasons: First, as a server-side ABR alternative, the present invention can respond to network changes faster than the baseline algorithm. Second, the present invention uses the "concurrent stream prefetching" technology, which reduces bandwidth waste by enabling multiple parallel requests, unlike the single request method. In addition, the reason for the poor performance of H2BR is that H2BR is an AVC-based decision algorithm that makes one-time decisions, has poor network responsiveness, and cannot adapt to changes in multi-path networks.

[0114] See also Figure 8 , in different network environments, Figure 8 (a) clearly shows that the present invention always achieves the highest bit rate in various network environments, followed by mpBack 2 , while H2BR performed the worst. Figure 6 The results are consistent with those in , and the reasons are the same, so I will not repeat them here.

[0115] like Figure 8 As shown in (b), under high bandwidth conditions, the quality switching times of the present invention are the least, and even the quality of the most stable playback known before is improved by 34.2%. However, under low bandwidth conditions, its performance is slightly reduced. This is because under higher bandwidth, the present invention can better utilize the available bandwidth and successfully transmit streams that other benchmark algorithms cannot transmit. On the contrary, as network conditions deteriorate and there is no additional bandwidth for transmission, the performance will gradually degrade.

[0116] Figure 8(c) shows that the present invention performs poorly in terms of the startup delay indicator, which is 1.86% lower than the best-performing Backfilling. This is because in the present invention, the client sends parallel requests at the same time, but these requests do not arrive at the server at the same time. If the later fragment request arrives first, the server will prioritize the transmission of the base layer of the fragment, which will occupy bandwidth and delay the transmission of the initial fragment base layer. However, considering that the bit rate has increased by 10.8% to 43.2%, it can be considered that sacrificing the startup delay is worth it.

[0117] The rebuffering time refers to the duration of the freeze excluding the startup delay. Figure 8 As shown in (d), the rebuffering time of the present invention and Backfilling is zero. The reason is as follows: Backfilling prioritizes downloading the base layer, and only when all base layers in the client buffer are downloaded, will it request the enhancement layer. The present invention adopts an adaptive scheduling selection strategy, which is adjusted based on the client's buffer status to ensure that the base layer is transmitted first when the buffer is low.

[0118] Fig. 9 The performance of different ABR algorithms on the SVC layer ratio in scenario 1 is analyzed. The goal of the present invention is to obtain a higher enhancement layer ratio. Since the ABR algorithms for this indicator perform similarly in different network environments, these results are not shown to save space.

[0119] Under the same network environment, the present invention can request more enhancement layers, especially EL3, for three main reasons: (i) the present invention moves ABR to the server side, which can detect the available bandwidth faster and more accurately; (ii) the present invention takes advantage of the multiplexing feature of MPQUIC to fully utilize the detected bandwidth through parallel requests; (iii) the present invention adjusts its scheduling strategy according to the status of the client buffer, maximizing the download of enhancement layers with deadline guarantees while ensuring that the base layer buffer is sufficient.

Claims

1. A server-side adaptive SVC ABR method based on MPQUIC and prefetching, characterized in that: The following steps are involved: Step 1: The server receives multiple video requests initiated simultaneously in a concurrent manner, wherein the multiple video requests are initiated by a single client having a video playback requirement, each video request corresponds to a video layer in a video segment of the video, and the video request includes application layer information of the video layer; Step 2: The server extracts the application layer information in the video request and calculates the amount of video clips that can be played in the client video playback buffer according to the current video stream transmission situation. cur The size of the packet and the available bandwidth are estimated based on the current congestion window and round-trip time. Step 3: The server receives the application layer information and B cur The size and available bandwidth of B select the corresponding video layer transmission strategy and make a video stream selection decision; the video layer transmission strategy is based on B cur To decide: When B cur When B is insufficient, the base layer data in the video layer is transmitted first; cur When B is moderate, the base layer and enhancement layer data in the video layer are transmitted in a balanced manner to maintain video quality. cur When the data of the enhancement layer in the video layer is sufficient, the enhancement layer data in the video layer is transmitted first; the selection decision of the video stream is completed through the following steps: First, check B cur , if B cur If the number of available layers is insufficient, only the base layer is added to the transmission queue to wait for transmission; Otherwise, all video requests are traversed in sequence according to the application layer information for screening, and then the bandwidth required by the screened video requests is calculated. If the available bandwidth meets the required bandwidth, the video stream corresponding to the video request is added to the transmission queue to wait for transmission; Step 4: The server sends the video stream in the transmission queue to the client. When the video playback of the client is stuck, the server obtains the stuck situation by receiving the custom MPQUIC control frame from the client, and postpones the corresponding deadline of the subsequent video segment according to the specific stuck duration to achieve dynamic adjustment until the entire video is played.

2. The method according to claim 1, characterized in that: In the step 1, multiple video requests are initiated simultaneously in a concurrent manner, wherein each video request requests the video layers of each quality level of the corresponding video segment in sequence from low to high; the application layer information of the video layer includes the video segment number, the requested video layer number and the deadline of the video segment.

3. The method according to claim 1, characterized in that In step 2, the amount of video clips that can be played in the client video playback buffer is calculated. cur The sizes include: All concurrent video requests are traversed in sequence. When the first video segment whose base layer has not been completely downloaded is encountered, the difference between the previous video segment number of this video segment and the currently playing video segment number is used as B cur .

4. The method according to claim 3, characterized in that Whether a video layer has been completely downloaded is determined in the following way: When at least one of the following conditions is met, it is determined that the current video layer has been successfully transmitted: 1) A higher video layer request has been received for the same video segment; 2) All data of the video layer has been sent, and all packets carrying the video layer data frames have been confirmed.

5. The method according to claim 1, characterized in that In step 2, the available bandwidth is estimated based on the current congestion window and round trip time, which is achieved by the following formula: ； Among them, BW avail Indicates the available bandwidth, CWNDpath i represents the congestion window of subpath i, sRTTpath i represents the smoothed round trip time of subpath i, and n is the number of subpaths.

6. The method according to claim 1, characterized in that In step 3, according to the video clip amount B in the client video playback buffer cur To determine the scheduling strategy, judge B cur Whether it is sufficient is determined based on the following process: Set a maximum threshold B max ; When B cur No more than B max One third of cur Insufficient; when B cur Greater than B max When it is two-thirds of cur Sufficient, otherwise it is considered B cur Moderate.

7. The method according to claim 6, characterized in that In judging B cur At the same time, it also includes the step of updating the highest layer of the video layer currently allowed to be transmitted: Setting parameter L allowed As the highest layer of the video layer currently allowed to be transmitted, L allowed The initial value of is the layer corresponding to the average playback bitrate of the client buffer; When B cur If it is insufficient, L allowed Updated to 0, when B cur When it is moderate, L allowed remain unchanged, when B cur When it is sufficient, L allowed Increase by 1.

8. The method according to claim 7, characterized in that In step 3, when making a video stream selection decision, all video requests are sequentially traversed for screening according to the application layer information, from the next video segment to be played to the request with the current largest video segment number, and the segments in the request queue are sequentially traversed. If any of the following conditions is met, the request will be discarded: ①The request is empty; ②The current time has exceeded the deadline; ③The layer number exceeds L allowe The highest allowed video layer; Next calculate , that is, the bandwidth required to transmit the request stream S, when the calculated BW need When it is greater than the available bandwidth and S is an enhanced layer, the transmission request stream S is abandoned; finally, the filtered stream will be added to the transmission queue sendStreams, and the amount of data transmitted totalSend will be updated, where S.remain is the remaining data amount of the current request stream, DDL is the deadline, and now is the current time.

9. The method according to claim 2, characterized in that: In step 4, the MPQUIC control frame customized by the client includes the following information for indicating the jamming situation: Intrinsic parameters VIDEO_INITIAL for initializing video and client information, including the number of video segments, the playback duration of a single video segment, and the maximum capacity of the client buffer; The deadline VIDEO_SYNCHRONOUS used to synchronize video playback and update subsequent video segments, including the latest played video segment number and playback timestamp; VIDEO_INITIAL is used to synchronize the server and client at the beginning of video playback, while VIDEO_SYNCHRONOUS is used to synchronize the server and client at the beginning of each video segment.

Images