Computing power network bandwidth estimation method

Abstract

The invention discloses a computing power network bandwidth estimation method, relates to the technical field of bandwidth estimation, and solves the technical problem that an available bandwidth estimation method which is high in precision, low in delay and high in adaptability is needed urgently to meet the strict requirement for network transmission efficiency in a cloud game / cloud electronic sports scene. The method comprises the following steps: acquiring an RTCP feedback frame of a video stream, and respectively carrying out bandwidth sampling, congestion detection and link capacity detection according to the RTCP feedback frame to obtain current bandwidth sampling data, congestion signals and link capacity; correcting the bandwidth sampling data according to the link capacity to obtain current bandwidth data; if congestion is generated, iteratively calculating the current available bandwidth from the sending end to the receiving end through a congestion signal; and if the congestion is not generated, iteratively calculating the current available bandwidth from the sending end to the receiving end through the bandwidth data. The method can improve the utilization rate of bandwidth, reduce delay and be suitable for various scenes.

Description

Technical Field

[0001] The present invention relates to the technical field of bandwidth estimation, and in particular to a method for estimating computing power network bandwidth. Background Art

[0002] In streaming scenarios for cloud gaming / cloud esports (on the consumer side), the network environment is often dynamic, necessitating real-time monitoring of network status, including available bandwidth, packet loss rate, and round-trip time (RTT). Accurately estimating available bandwidth is one of the most critical network metrics, directly impacting streaming data delivery strategies. Accurate and rapid estimation of available bandwidth maximizes bandwidth utilization while avoiding network congestion, ensuring a low-latency, highly fluid user experience.

[0003] Currently, the cloud gaming industry widely uses the WebRTC Google Congestion Control (GCC) algorithm for congestion control. The algorithm's core principle is to gradually approach the upper limit of available bandwidth by adjusting the bitrate. When the bitrate is insufficient to detect the bandwidth limit, GCC actively probes by sending empty packets (probes). However, in practice, GCC's bitrate ramps up slowly. After a sudden network congestion, GCC takes a long time to recover to the optimal bitrate, resulting in poor bandwidth utilization. Furthermore, during the bandwidth detection phase, GCC may send too many packets (over-transmission), leading to network buffer backlogs, increased end-to-end latency, and even video stuttering.

[0004] In addition to GCC, the industry has also attempted to use other congestion control algorithms for optimization, such as: TCP Cubic: This algorithm detects bandwidth limits by adjusting the sending bitrate and uses packet loss as a signal for congestion. However, TCP Cubic performs poorly in real-time audio and video transmission because it relies on packet loss feedback. Real-time streaming is extremely sensitive to latency, and packet loss can cause severe lag and image quality degradation.

[0005] Bottleneck Bandwidth and Round-trip Propagation Time (BBR): BBR proactively measures bandwidth and RTT to adjust the sending rate and uses RTT variations to predict congestion. However, BBR has a significant drawback: approximately every 10 seconds, it enters a minimum RTT detection phase (lasting 200ms), during which the sending window (cwnd) drops sharply to 4 packets, resulting in a sharp drop in instantaneous throughput. This periodic speed reduction can introduce unacceptable latency and lag in real-time audio and video transmission scenarios, severely impacting the user experience.

[0006] In summary, existing bandwidth estimation algorithms (such as GCC, Cubic, and BBR) all have problems such as poor adaptability to delay-sensitive scenarios and difficulty in balancing high bandwidth utilization and low latency.

[0007] In the process of implementing the present invention, the inventors discovered that the prior art has at least the following problems: There is an urgent need for a high-precision, low-latency, and highly adaptable available bandwidth estimation method to meet the stringent requirements for network transmission efficiency in cloud gaming / cloud e-sports scenarios. Summary of the Invention

[0008] The purpose of the present invention is to provide a computing power network bandwidth estimation method to solve the technical problem that the existing technology urgently needs a high-precision, low-latency, and highly adaptable available bandwidth estimation method to meet the stringent requirements of network transmission efficiency in cloud gaming / cloud e-sports scenarios.

[0009] The various technical effects that can be produced by the preferred technical solutions among the various technical solutions provided by the present invention are described in detail below.

[0010] To achieve the above objectives, the present invention provides the following technical solutions: The present invention provides a computing power network bandwidth estimation method, comprising the following steps: obtaining RTCP feedback frames of a video stream, and performing bandwidth sampling, congestion detection, and link capacity detection according to the RTCP feedback frames to obtain current bandwidth sampling data, a congestion signal, and link capacity; correcting the bandwidth sampling data according to the link capacity to obtain current bandwidth data; if congestion occurs, iteratively calculating the current available bandwidth from the sending end to the receiving end using the congestion signal; if no congestion occurs, iteratively calculating the current available bandwidth from the sending end to the receiving end using the bandwidth data.

[0011] Optionally, bandwidth sampling, congestion detection and link capacity detection are performed respectively based on the obtained RTCP feedback frame to obtain current bandwidth sampling data, congestion signal and link capacity, including: inputting the RTCP feedback frame into a bandwidth sampler for bandwidth sampling to obtain the current bandwidth sampling data; inputting the RTCP feedback frame into a trend line estimator for congestion detection to obtain the current congestion signal; and inputting the RTCP feedback frame into a bit rate estimator for link capacity detection to obtain the current link capacity.

[0012] Optionally, the bandwidth sampling by inputting the RTCP feedback frame into the bandwidth sampler to obtain the current bandwidth sampling data comprises: measuring one-way transmission delay of the video stream according to the RTCP feedback frame, and calculating queuing time of the video stream in a transmission link according to the one-way transmission delay; and calculating the current bandwidth sampling data of the video stream according to the queuing time.

[0013] Optionally, the measuring one-way transmission delay of the video stream according to the RTCP feedback frame, and calculating queuing time of the video stream in a transmission link according to the one-way transmission delay comprises: in a scenario of insufficient bandwidth utilization or utilization reaching 100%, the queuing time of the video stream in the transmission link is Rend-Sstart-owd; wherein Sstart and Rend respectively represent sending time of a first data packet and receiving time of a last data packet of the video stream; and owd represents the one-way transmission delay; and in a scenario of excess bandwidth utilization, the queuing time of the video stream in the transmission link is Rend-Sstart-Δmin; wherein Δmin = min(owd) represents the minimum one-way transmission delay of the video stream sent in a time window.

[0014] Optionally, in the scenario of excess bandwidth utilization, the calculating queuing time of the video stream in the transmission link comprises: saving all the one-way transmission delays in the time window to obtain the minimum one-way transmission delay; performing smoothing operation on the one-way transmission delay of each frame in the time window to obtain a smoothed one-way delay; calculating standard deviation of all the one-way transmission delays in the time window, and correcting the minimum one-way transmission delay according to the standard deviation and the smoothed one-way delay.

[0015] Optionally, the formula for calculating the bandwidth sampling S of the video stream is: ; wherein F represents total size of the video stream; R represents queuing time of the video stream in a transmission link.

[0016] Optionally, when the frame size of the video stream is less than a minimum frame threshold, the obtained current bandwidth data is discarded and does not participate in iterative calculation; and when the frame size of the video stream is greater than the minimum frame threshold and less than an average frame size of the video stream, the formula for calculating the bandwidth sampling of the video stream is adjusted as: ; Wherein, γ is the expansion multiple of the video stream; Sstart and Rend represent the sending time of the first data packet and the receiving time of the last data packet of the video stream, respectively.

[0017] Optionally, when packet loss occurs during the transmission of the video stream, the formula for calculating the bandwidth sampling of the video stream is adjusted to: or ; in, is the cumulative length of all lost packets during the transmission of the video stream; is a packet loss rate of the video stream.

[0018] Optionally, the iterative calculation of the current available bandwidth from the sending end to the receiving end through the congestion signal includes: when congestion is detected according to the congestion signal, first performing a multiplicative subtraction; then, if congestion is detected for n consecutive times, performing the multiplicative subtraction again and increasing the strength of the multiplicative subtraction to calculate the available bandwidth in the process of performing the multiplicative subtraction.

[0019] Optionally, the correcting the bandwidth sampling data according to the link capacity to obtain the current bandwidth data includes: obtaining the current link status according to the characteristics of the packet receiving interval of the video stream; filtering the bandwidth sampling data with reference to the link capacity according to the current link status to correct the bandwidth sampling data according to the link capacity to obtain the current bandwidth data.

[0020] Implementing one of the above technical solutions of the present invention has the following advantages or beneficial effects: The computing network bandwidth estimation method provided by the present invention performs bandwidth sampling, congestion detection and link capacity detection according to RTCP feedback frames. If congestion occurs, the current available bandwidth is calculated according to the congestion signal; if no congestion occurs, the current available bandwidth is calculated according to the bandwidth sampling data. Rotating different bandwidth estimates according to the congestion situation can improve the accuracy of bandwidth estimation and is applicable to various scenarios, especially meeting the strict requirements for network transmission efficiency in cloud gaming / cloud e-sports scenarios. The bandwidth sampling data is corrected through link capacity detection to improve the accuracy of the sampled bandwidth data, improve bandwidth utilization, and reduce latency. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. Those skilled in the art can also derive other drawings based on these drawings without inventive work. In the drawings: Figure 1 is a flow chart of a bandwidth estimation method according to an embodiment of the present invention; Figure 2 is a structural block diagram of a bandwidth estimation method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of queuing time in a scenario where bandwidth is not fully utilized or the utilization rate reaches 100% according to an embodiment of the present invention; Figure 4 This is a schematic diagram of queuing time in a scenario of bandwidth overuse according to an embodiment of the present invention; Figure 5 is a flowchart of step S2 of the bandwidth estimation method according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the queuing time in a scenario with a small video stream according to an embodiment of the present invention. DETAILED DESCRIPTION

[0022] In order to make the objects, technical solutions and advantages of the present invention clearer, the various exemplary embodiments to be described below will refer to the corresponding drawings, which constitute a part of the exemplary embodiments, in which various exemplary embodiments that may be used to implement the present invention are described. Unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation methods described in the following exemplary embodiments do not represent all implementation methods consistent with the present disclosure. It should be understood that they are only examples of processes, methods and devices that are consistent with some aspects of the present disclosure as detailed in the appended claims, and other embodiments may also be used, or structural and functional modifications may be made to the embodiments listed herein without departing from the scope and essence of the present invention.

[0023] In the description of the present invention, it should be understood that the terms "center", "longitudinal", "transverse", etc. indicate the orientation or position relationship based on the drawings, and are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the elements referred to must have a specific orientation, be constructed and operate in a specific orientation. The terms "first", "second", etc. are only used for descriptive purposes and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. The term "plurality" means two or more. The terms "connected" and "connected" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, an integral connection, a mechanical connection, an electrical connection, a communication connection, a direct connection, an indirect connection through an intermediate medium, and can be the internal connection of two elements or the interaction relationship between two elements. The term "and / or" includes any and all combinations of one or more related listed items. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to the specific circumstances.

[0024] In order to illustrate the technical solution of the present invention, a specific embodiment is provided below, in which only the parts related to the embodiment of the present invention are shown.

[0025] Example 1: like Figure 1 and Figure 2 As shown, the present invention provides a computing network bandwidth estimation method, comprising the following steps: S1. Obtaining RTCP feedback frames of a video stream, and performing bandwidth sampling, congestion detection, and link capacity detection based on the RTCP feedback frames to obtain current bandwidth sampling data, congestion signals, and link capacity; S2. Correcting the bandwidth sampling data based on the link capacity to obtain current bandwidth data; S3. If congestion occurs, iteratively calculating the current available bandwidth from the sender to the receiver using the congestion signal; S4. If congestion does not occur, iteratively calculating the current available bandwidth from the sender to the receiver using the bandwidth data. It should be noted that this embodiment uses the congestion signal to determine whether the current link is congested; after calculating the available bandwidth, bandwidth can be allocated to the video stream based on the available bandwidth, and the target encoding bit rate and smoothed transmission bit rate of the video stream can be obtained based on the bandwidth allocation. Then, a smoothing transmitter is used to transmit the video stream to the receiver based on the bandwidth allocation, the target encoding bit rate, and the smoothed transmission bit rate. The receiver collects relevant information about the video stream to form an RTCP feedback frame, and then transmits the newly formed RTCP feedback frame to the transmitter, which then recalculates the current available bandwidth, repeating this cycle.

[0026] The computing power network bandwidth estimation method provided by the embodiment can improve the accuracy of bandwidth estimation and is suitable for various scenes, especially meeting the stringent requirements for network transmission efficiency in cloud gaming / cloud e-sports scenes, by rotating different bandwidth estimations according to congestion conditions. In addition, the accuracy of the sampled bandwidth data is improved, and the utilization rate of the bandwidth is also improved, and the delay is reduced.

[0027] In the following, the computing power network bandwidth estimation method provided by the embodiment is described in detail. Figures 1-6 In the following, the computing power network bandwidth estimation method provided by the embodiment is described in detail. First, step S1 is performed to obtain the RTCP feedback frame of the video stream. According to the RTCP feedback frame, bandwidth sampling, congestion detection, and link capacity detection are performed respectively to obtain the current bandwidth sampling data, congestion signal, and link capacity.

[0028] Specifically, step S1 includes: inputting the RTCP feedback frame into a bandwidth sampler to perform bandwidth sampling and obtain the current bandwidth sampling data; the RTCP feedback frame is a special data packet in the Real-time Transport Control Protocol (RTCP), which is used to transmit network state information such as delay, packet loss, and receiving rate from the receiving end to the sending end in real-time communication (such as WebRTC and video conference). The bandwidth sampler can perform bandwidth sampling according to the RTCP feedback frame. The RTCP feedback frame is input into a trend line estimator to perform congestion detection and obtain the current congestion signal; the RTCP feedback frame is input into the trend line estimator to perform congestion detection, which can monitor the delay gradient in real time and respond to congestion quickly to identify the trend of network congestion; finally, the current congestion signal is output to represent the congestion degree of the current network. The RTCP feedback frame is input into a code rate estimator to perform link capacity detection and obtain the current link capacity. The RTCP feedback frame is input into the code rate estimator to estimate the maximum sustainable transmission code rate of the link, i.e., the link capacity, to avoid over-limit detection.

[0029] Further, the RTCP feedback frame is input into the bandwidth sampler to perform bandwidth sampling and obtain the current bandwidth sampling data, including: measuring the one-way transmission delay of the video stream according to the RTCP feedback frame, and calculating the queuing time of the video stream in the transmission link according to the one-way transmission delay; and calculating the current bandwidth sampling data of the video stream according to the queuing time. The queuing time of the video stream in the transmission link can obtain accurate bandwidth sampling data of the video stream.

[0030] Specifically, the one-way transmission delay of the video stream is measured based on the RTCP feedback frame, and the queuing time of the video stream in the transmission link is calculated based on the one-way transmission delay, including: like Figure 3 As shown in the figure, when bandwidth is underutilized or reaches 100% utilization, the queuing time of a video stream in the transmission link is: Rend - Sstart - owd. Sstart and Rend represent the sending time of the first packet and the receiving time of the last packet of the video stream, respectively. owd represents the one-way transmission delay. When the network is underutilized or 100% utilized, the video stream does not experience additional queuing between frames. Therefore, the one-way transmission delay of the video stream remains essentially unchanged over a period of time and can be directly used to calculate the queuing time. It should be noted that in actual usage environments, the scenarios where bandwidth is underutilized or reaches 100% utilization are very rare and can be ignored. However, scenarios where bandwidth is overutilized are numerous, and it is necessary to accurately calculate the queuing time in these scenarios.

[0031] like Figure 4 As shown in the figure, in a bandwidth oversubscription scenario, the queuing time of a video stream in the transmission link is: Rend - Sstart - ∆min; where ∆min = min(owd), representing the minimum one-way transmission delay of the video stream sent within the time window. In bandwidth oversubscription, transient overutilization due to frame size overshoot, bandwidth overestimation, or network bandwidth drop can lead to queues spanning multiple frames. This causes fluctuations in one-way transmission delay. Therefore, the minimum one-way transmission delay within the time window is selected to calculate the queuing time, thereby reducing bandwidth samples for subsequent frames.

[0032] Further, if Figure 5 As shown, in the scenario of bandwidth overuse, the queuing time of the video stream in the transmission link is calculated, including: S21, saving all one-way transmission delays in the time window to obtain the minimum one-way transmission delay; S22, smoothing the one-way transmission delay of each frame in the time window to obtain the smoothed one-way delay; S23, calculating the standard deviation of all one-way transmission delays in the time window, and obtaining the jitter amplitude based on the standard deviation; S24, correcting the minimum one-way transmission delay based on the jitter amplitude and the smoothed one-way delay. Since the bandwidth data calculated during the actual data transmission process has a large jitter, it is because jitter is generated when measuring the minimum one-way delay, which will cause the iteratively calculated bandwidth estimate to fluctuate greatly, resulting in low accuracy. Therefore, this embodiment ensures the stability of bandwidth data by setting a reasonable sampling time window and smoothing parameters.

[0033] For example, the time window is set as 2*min_RTT window (representing a time window dynamically adjusted based on round-trip time (RTT) for statistics and analysis of network status), all one-way transmission delays within the 2*min_RTT window are saved, and the minimum value of the one-way transmission delays is min_owd; a smoothing operation is performed on the one-way transmission delay of each frame to obtain a smoothed one-way delay smoothed_owd; the standard deviation of the one-way transmission delay of each frame within the 2*min_RTT window is calculated, and a jitter amplitude alpha is calculated according to the standard deviation; and the minimum one-way transmission delay is corrected, that is, ∆min=min_owd*alpha+smoothed_owd*(1-alpha). In different scenarios, adaptive adjustment is made, such as different parameters used in cloud e-sports scenarios and cloud game scenarios.

[0034] As an alternative embodiment, the formula for calculating the bandwidth sampling data S of the video stream is: wherein F represents the total size of the video stream; represents the queuing time of the video stream in the transmission link. The formula is a formula for calculating the bandwidth sampling in an ideal environment.

[0035] Then, step S2 is performed to correct the bandwidth sampling data according to the link capacity to obtain the current bandwidth data. Since the above bandwidth sampling data is calculated in an ideal environment, and various interferences will occur in the actual transmission process of the video stream, the bandwidth sampling data is corrected according to the link capacity to obtain accurate bandwidth data, so as to improve the accuracy of bandwidth estimation.

[0036] Specifically, step S2 includes: acquiring the current link state according to the characteristics of the packet receiving interval of the video stream; and filtering the bandwidth sampling data according to the current link state and referring to the link capacity to correct the bandwidth sampling data according to the link capacity to obtain the current bandwidth data. Considering the instantaneous jitter caused by measurement error, the jitter-type network scenario also needs to be considered, and therefore the bandwidth sampling needs to be calibrated in combination with the link capacity.

[0037] In addition, considering the influence of other factors on the bandwidth sampling, the following method can be used to correct the bandwidth sampling: for example, Figure 6 ​As shown in the figure, when the size of the video stream is less than the minimum frame threshold, the current bandwidth data is discarded and does not participate in the iterative calculation; when the video stream is very small (for example, less than 1500B, that is, the minimum frame threshold is equal to 1500B), the measured bandwidth data has large jitter and is less accurate. In this case, the data is discarded and does not participate in the iteration to ensure the accuracy of the bandwidth estimation. When the size of the video stream is greater than the minimum frame threshold and less than the average frame size of the video stream, the formula for calculating the bandwidth sampling data of the video stream is adjusted to: ; Here, γ is the expansion factor of the video stream. By proportionally increasing the length of the data frame and the queuing time using this formula, the accuracy of bandwidth estimation can also be improved.

[0038] When packet loss occurs during video stream transmission, the formula for calculating the bandwidth sampling of the video stream can be adjusted to: or ; in, It is the cumulative length of all packet loss during the transmission of a video stream; is the packet loss rate of a video stream. This formula can be used to correct the bandwidth data sampled when packet loss occurs, thereby improving the accuracy of bandwidth sampling.

[0039] As an alternative implementation, due to the asynchronous timestamps between the client and server, errors and jitter may occur when measuring the minimum one-way transmission delay and queuing time. By using the server's timestamp (that is, converting the client's timestamp to the server's timestamp), the stability of the calculation results can be improved.

[0040] As an optional implementation, when burst reception occurs (i.e., the queuing time for the entire frame is very short (<=1ms), and the receiver receives multiple packets in a very short period of time), the congestion-post-pipeline-draining and recovery phase occurs. This is considered abnormal sampling and is skipped. The bandwidth samples during the burst period are directly ignored to avoid contamination in the iteration process.

[0041] After the bandwidth data is corrected, it is determined whether the current link is congested based on the congestion signal. If so, step S3 is executed to iteratively calculate the current available bandwidth from the sending end to the receiving end based on the congestion signal.

[0042] Specifically, step S3 includes: when congestion is detected based on the congestion signal, a multiplicative subtraction is first performed; if congestion is detected n times consecutively, the multiplicative subtraction is performed again, with an increased intensity, to calculate the available bandwidth during the multiplicative subtraction process. Due to the rapid convergence rate during the calculation, sudden congestion, small jitter, and frequent jitter can cause frequent fluctuations in the bandwidth estimate. To reduce the amplitude and frequency of bandwidth estimate jitter, the sensitivity of the congestion signal is adjusted, and tentative multiplicative subtraction is performed. This process of repeatedly performing multiplicative subtraction is the process of iteratively calculating the bandwidth estimate. The trend line estimator is more sensitive in high-bandwidth scenarios (e.g., 20Mbps-30Mbps), which can prematurely detect congestion. The detection threshold can be appropriately relaxed to reduce the sensitivity of the congestion signal. Multiplicative Decrease (MD) is a core strategy in network congestion control. When congestion is detected, the current sending rate (or congestion window) is directly multiplied by a coefficient less than 1 (such as 0.5), thereby quickly reducing the load and alleviating network congestion.

[0043] As an alternative implementation, a large network buffer creates a sudden congestion, resulting in a long pause (2 seconds or more). Since the bandwidth estimation method in this embodiment uses frames as the unit to drive the algorithm iteration, in this scenario, the network buffer is full and the client receives few frames, resulting in a very slow decrease in bandwidth estimation. Upon receiving feedback frames, the bandwidth estimation is checked at 100ms intervals to see if there is an iteration or network congestion. If there is no iteration, a forced iteration is performed.

[0044] If no congestion occurs, step S4 is executed to iteratively calculate the current available bandwidth from the sending end to the receiving end through the bandwidth data.

[0045] As an optional implementation, the formula for iteratively calculating the current available bandwidth from the sending end to the receiving end is: ; in, Indicates the available bandwidth after iterative update; Indicates the current available bandwidth; Indicates the step length; A reward parameter representing bandwidth utilization. Since bandwidth sampling is unstable and has large short-term jitter, it is converged to the correct value through gradual iteration.

[0046] As an optional implementation, different probing rates are selected based on the bandwidth estimation gear to balance convergence speed, user experience, and bitrate jitter. A phased probing rate mechanism is set: When the bandwidth ranges from 0M to 5M, a faster probing rate, such as 1 second, can be set to quickly fill low-bandwidth links and reduce initial lag. When the bandwidth ranges from 5M to 16M, a normal probing rate, such as 4-5 seconds, is set to balance convergence speed and stability, suitable for mainstream video scenarios. When the bandwidth ranges from 16M to 30M, a slower probing rate, such as 10-20 seconds or longer, is set to avoid congestion caused by excessive probing at high bandwidths. The probing rate refers to the rate at which the sending rate is actively increased to detect higher available bandwidth when the network is underutilized during the bandwidth estimation (BWE) process. Selecting different probing rates based on the bandwidth gear can quickly discover idle bandwidth and avoid overly aggressive probing that can cause congestion.

[0047] Small fluctuations can be further filtered out using a lag filter. Specifically, if the calculated bandwidth estimate value (compared to the previous value) changes slightly (the change range is <= 1%), the previous value is used to correct the bandwidth estimation result.

[0048] The embodiment is only a special example and does not represent only one way of implementing the present invention.

[0049] The above are merely preferred embodiments of the present invention. Those skilled in the art will appreciate that various changes or equivalent substitutions may be made to these features and embodiments without departing from the spirit and scope of the present invention. Furthermore, under the guidance of the present invention, these features and embodiments may be modified to adapt to specific circumstances and materials without departing from the spirit and scope of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of this application are intended to be within the scope of the present invention.

Claims

1. A method for estimating computing power network bandwidth, characterized in that: The following steps are involved: Obtaining RTCP feedback frames of the video stream, and performing bandwidth sampling, congestion detection, and link capacity detection based on the RTCP feedback frames to obtain current bandwidth sampling data, congestion signals, and link capacity; Correcting the bandwidth sampling data according to the link capacity to obtain current bandwidth data; If congestion occurs, iteratively calculating the current available bandwidth from the sending end to the receiving end using the congestion signal; If no congestion occurs, the current available bandwidth from the sending end to the receiving end is iteratively calculated using the bandwidth data.

2. A computing power network bandwidth estimation method according to claim 1, characterized in that: The method of performing bandwidth sampling, congestion detection, and link capacity detection based on the obtained RTCP feedback frame to obtain current bandwidth sampling data, congestion signal, and link capacity includes: Inputting the RTCP feedback frame into a bandwidth sampler for bandwidth sampling to obtain current bandwidth sampling data; The RTCP feedback frame is input into a trend line estimator to perform congestion detection, thereby obtaining the current congestion signal; The current link capacity is obtained by inputting the RTCP feedback frame into a code rate estimator to perform link capacity detection.

3. A computing power network bandwidth estimation method according to claim 2, characterized in that: The step of inputting the RTCP feedback frame into a bandwidth sampler to perform bandwidth sampling to obtain current bandwidth sampling data includes: Measuring a one-way transmission delay of the video stream according to the RTCP feedback frame, and calculating a queuing time of the video stream in a transmission link according to the one-way transmission delay; The current bandwidth sampling data of the video stream is calculated according to the queuing time.

4. A computing power network bandwidth estimation method according to claim 3, characterized in that: The step of measuring the one-way transmission delay of the video stream according to the RTCP feedback frame, and calculating the queuing time of the video stream in the transmission link according to the one-way transmission delay, includes: In the scenario where bandwidth is not fully utilized or utilization reaches 100%, the queuing time of the video stream in the transmission link is: Rend-Sstart-owd; where Sstart and Rend represent the sending time of the first data packet and the receiving time of the last data packet of the video stream, respectively; owd represents the one-way transmission delay; In a scenario where bandwidth is overused, the queuing time of the video stream in the transmission link is: Rend-Sstart-∆min; where ∆min=min(owd), which represents the minimum one-way transmission delay of the video stream sent within the time window.

5. A computing power network bandwidth estimation method according to claim 4, characterized in that: In a scenario where bandwidth is overused, calculating the queuing time of the video stream in the transmission link includes: Saving all the one-way transmission delays within the time window, and obtaining the minimum one-way transmission delay; Performing a smoothing operation on the one-way transmission delay of each frame in the time window to obtain a smoothed one-way delay; Calculating the standard deviation of all the one-way transmission delays within the time window, and obtaining the jitter amplitude based on the standard deviation; The minimum one-way transmission delay is corrected according to the jitter amplitude and the smoothed one-way delay.

6. A computing power network bandwidth estimation method according to claim 4, characterized in that: The formula for calculating the bandwidth sampling S of the video stream is: ； Wherein, F represents the total size of the video stream; Indicates the queuing time of the video stream in the transmission link.

7. A computing power network bandwidth estimation method according to claim 6, characterized in that: When the frame size of the video stream is smaller than the minimum frame threshold, the current bandwidth data is discarded and does not participate in the iterative calculation; when the frame size of the video stream is larger than the minimum frame threshold but smaller than the average frame size of the video stream, the formula for calculating the bandwidth sampling of the video stream is adjusted to: ； Wherein, γ is the expansion multiple of the video stream; Sstart and Rend represent the sending time of the first data packet and the receiving time of the last data packet of the video stream, respectively.

8. A computing power network bandwidth estimation method according to claim 6, characterized in that: When packet loss occurs during the transmission of the video stream, the formula for calculating the bandwidth sampling of the video stream is adjusted to: or ; in, is the cumulative length of all lost packets during the transmission of the video stream; is a packet loss rate of the video stream.

9. A computing power network bandwidth estimation method according to claim 1, characterized in that: The iterative calculation of the current available bandwidth from the sending end to the receiving end using the congestion signal includes: When congestion is detected according to the congestion signal, a multiplicative reduction is first performed; if congestion is detected for n consecutive times, the multiplicative reduction is performed again and the intensity of the multiplicative reduction is increased to calculate the available bandwidth during the multiplicative reduction process.

10. A computing power network bandwidth estimation method according to claim 6, characterized in that: The correcting the bandwidth sampling data according to the link capacity to obtain current bandwidth data includes: The current link status is obtained according to the characteristics of the packet receiving interval of the video stream; the bandwidth sampling data is filtered according to the current link status with reference to the link capacity, so as to correct the bandwidth sampling data according to the link capacity to obtain the current bandwidth data.

Images