A computing power network bandwidth estimation method

Abstract

The application discloses a computing power network bandwidth estimation method, relates to the technical field of bandwidth estimation, and solves the technical problem of urgently needing a high-precision, low-delay and strong-adaptability available bandwidth estimation method to meet the strict requirement on network transmission efficiency in a cloud game / cloud e-sports scene. The method comprises the following steps: acquiring an RTCP feedback frame of a video stream, performing bandwidth sampling, congestion detection and link capacity detection according to the RTCP feedback frame, and obtaining 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 a sending end to a receiving end through the congestion signal; and if no congestion occurs, iteratively calculating the current available bandwidth from the sending end to the receiving end through the bandwidth data. The application can improve the utilization rate of bandwidth, reduce delay and be applicable to various scenes.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of bandwidth estimation, and particularly relates to a computing power network bandwidth estimation method. BACKGROUND

[0002] In the streaming transmission scenario of cloud gaming / cloud e-sports (C-end), the network environment is usually dynamically changing, so it is necessary to monitor the network state in real time, including available bandwidth, packet loss rate and round-trip time (RTT). Among them, the accurate estimation of available bandwidth is one of the most critical network indicators, which directly affects the sending strategy of streaming data. Accurate and rapid estimation of available bandwidth can maximize bandwidth utilization under the premise of avoiding network congestion, thereby guaranteeing low delay and high fluency of user experience.

[0003] At present, the cloud gaming industry widely adopts WebRTC GCC (Google Congestion Control) algorithm for congestion control. The core idea of this algorithm is to gradually approach the upper limit of available bandwidth by adjusting the sending code rate, and when the sending code rate is insufficient to detect the upper limit of bandwidth, GCC will actively detect by sending empty packets (probes). However, GCC has a slow code rate in practical application, and it takes a long time for GCC to recover to the optimal code rate after network burst congestion, resulting in low bandwidth utilization. In addition, in the bandwidth detection phase, GCC may send too many data packets (overrun), causing network buffer accumulation, increasing end-to-end delay, and even causing video stuttering.

[0004] In addition to GCC, the industry has also tried to use other congestion control algorithms for optimization, such as:

[0005] TCP Cubic: This algorithm detects the bandwidth boundary by adjusting the sending code rate, and uses packet loss as a congestion signal. However, TCP Cubic performs poorly in real-time audio and video transmission because it relies on packet loss feedback, and real-time streaming is extremely sensitive to delay, and packet loss can cause severe stuttering and picture quality degradation.

[0006] BBR (Bottleneck Bandwidth and Round-trip propagation time): BBR adjusts the sending rate by actively measuring bandwidth and RTT, and uses RTT changes to predict congestion. However, BBR has a significant defect: it enters a minimum RTT detection phase (lasting 200ms) every 10 seconds, during which the sending window (cwnd) drops sharply to 4 packets, causing a sharp drop in instantaneous throughput. This periodic speed reduction introduces unacceptable delay and stuttering in real-time audio and video transmission scenarios, severely affecting user experience.

[0007] In summary, the existing bandwidth estimation algorithms (such as GCC, Cubic, BBR) have poor adaptability in delay-sensitive scenarios, and it is difficult to balance high bandwidth utilization and low delay.

[0008] In the process of implementing the present application, the inventors have found at least the following problems in the prior art:

[0009] There is an urgent need for a high-precision, low-delay, and strongly adaptive available bandwidth estimation method to meet the stringent requirements for network transmission efficiency in cloud gaming / cloud e-sports scenarios. SUMMARY

[0010] The present application aims to provide a computing power network bandwidth estimation method to solve the technical problem of the urgent need for a high-precision, low-delay, and strongly adaptive available bandwidth estimation method to meet the stringent requirements for network transmission efficiency in cloud gaming / cloud e-sports scenarios in the prior art.

[0011] The preferred technical solutions in the many technical solutions provided by the present application can produce many technical effects, which are described in detail below.

[0012] To achieve the above-mentioned object, the present application provides the following technical solutions:

[0013] The computing power network bandwidth estimation method provided by the present application comprises the following steps: obtaining an RTCP feedback frame of a video stream, performing bandwidth sampling, congestion detection, and link capacity detection according to the RTCP feedback frame, respectively, 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 through the congestion signals; and if no congestion occurs, iteratively calculating the current available bandwidth from the sending end to the receiving end through the bandwidth data.

[0014] Optionally, the bandwidth sampling, congestion detection, and link capacity detection according to the obtained RTCP feedback frame to obtain the current bandwidth sampling data, congestion signals, and link capacity comprise: performing bandwidth sampling by inputting the RTCP feedback frame into a bandwidth sampler to obtain the current bandwidth sampling data; performing congestion detection by inputting the RTCP feedback frame into a trend line estimator to obtain the current congestion signals; and performing link capacity detection by inputting the RTCP feedback frame into a code rate estimator to obtain the current link capacity.

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

[0016] 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 transmission time of a first data packet and reception 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 within a time window.

[0017] 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 within the time window to obtain the minimum one-way transmission delay; performing smoothing operation on the one-way transmission delay of each frame within the time window to obtain a smoothed one-way delay; calculating standard deviation of all the one-way transmission delays within the time window, and correcting the minimum one-way transmission delay according to the standard deviation and the smoothed one-way delay.

[0018] Optionally, the formula for calculating the bandwidth sampling S of the video stream is:

[0019] ;

[0020] wherein F represents total size of the video stream; R represents queuing time of the video stream in a transmission link.

[0021] 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; 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:

[0022] ;

[0023] Wherein, gamma is the expansion multiple of the video stream; Sstart and Rend respectively represent the sending time of the first data packet and the receiving time of the last data packet of the video stream.

[0024] Optionally, when a packet loss occurs in the transmission process of the video stream, the formula for calculating the bandwidth sampling of the video stream is adjusted as:

[0025] Or ;

[0026] Wherein, is the cumulative length of all packet losses in the transmission process of a video stream; is the packet loss rate of a video stream.

[0027] Optionally, the iteration calculation of the current available bandwidth from the sending end to the receiving end through the congestion signal comprises: when it is detected according to the congestion signal that congestion occurs, a multiplicative reduction is first performed; then if congestion is detected for n consecutive times, the multiplicative reduction is performed again, and the strength of the multiplicative reduction is increased, so as to calculate the available bandwidth in the process of performing the multiplicative reduction.

[0028] Optionally, the correction of the bandwidth sampling data according to the link capacity to obtain the current bandwidth data comprises: obtaining the current link state according to the characteristics of the packet receiving interval of the video stream; filtering the bandwidth sampling data according to the current link state, so as to correct the bandwidth sampling data according to the link capacity to obtain the current bandwidth data.

[0029] Implementing one of the technical solutions in the application has the following advantages or beneficial effects:

[0030] The computing power network bandwidth estimation method provided by the application can respectively perform bandwidth sampling, congestion detection and link capacity detection according to RTCP feedback frames, calculate the current available bandwidth according to the congestion signal if congestion occurs, and calculate the current available bandwidth according to the bandwidth sampling data if no congestion occurs. Rotating different bandwidth estimations according to the congestion situation can improve the accuracy of bandwidth estimation, and is suitable for various scenes, especially can meet the strict requirements of network transmission efficiency in cloud gaming / cloud e-sports scenes. In addition, the bandwidth sampling data is corrected through link capacity detection to improve the accuracy of the sampling bandwidth data, which can also improve the utilization rate of bandwidth and reduce the delay. BRIEF DESCRIPTION OF DRAWINGS

[0031] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments description. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor, and the drawings are as follows:

[0032] Figure 1 is a flow chart of the bandwidth estimation method of the embodiments of the present application;

[0033] Figure 2 is a structural block diagram of the bandwidth estimation method of the embodiments of the present application;

[0034] Figure 3 is a queuing time schematic diagram in the scenario of insufficient bandwidth utilization or utilization reaching 100% of the embodiments of the present application;

[0035] Figure 4 is a queuing time schematic diagram in the scenario of excess bandwidth utilization of the embodiments of the present application;

[0036] Figure 5 is a flow chart of step S2 of the bandwidth estimation method of the embodiments of the present application;

[0037] Figure 6 is a queuing time schematic diagram in the scenario of small video stream of the embodiments of the present application. DETAILED DESCRIPTION

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

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

[0040] In order to illustrate the technical solutions described in the present application, the following will be described by specific examples, only showing the part related to the embodiment of the present application.

[0041] Example one:

[0042] As shown in Figure 1 and Figure 2 , the present application provides a kind of computing power network bandwidth estimation method, comprising the following steps: S1, the RTCP feedback frame of video stream is acquired, according to RTCP feedback frame, bandwidth sampling, congestion detection and link capacity detection are carried out respectively, and the current bandwidth sampling data, congestion signal and link capacity are obtained;S2, bandwidth sampling data is corrected according to link capacity, and the current bandwidth data is obtained;S3, if congestion is generated, the current available bandwidth from sending end to receiving end is iteratively calculated through congestion signal;S4, if no congestion is generated, the current available bandwidth from sending end to receiving end is iteratively calculated through bandwidth data.It should be noted that the present embodiment judges whether the current link has generated congestion through congestion signal;After available bandwidth is calculated, video stream can be allocated bandwidth according to available bandwidth, and target encoding code rate and smooth sending code rate of video stream are obtained according to bandwidth allocation situation, then smooth sender is utilized, video stream is sent to receiving end according to bandwidth allocation situation, target encoding code rate and smooth sending code rate, receiving end collects the relevant information of video stream to form RTCP feedback frame, then newly formed RTCP feedback frame is sent to sending end, and sending end re-calculates the current available bandwidth, to form a cycle.

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

[0044] In the following, the computing power network bandwidth estimation method provided by the embodiment is described in detail in combination with Figures 1-6 The specific implementation of the computing power network bandwidth estimation method provided by the embodiment is described in detail as follows:

[0045] First, the RTCP feedback frame of the video stream is obtained in step S1, and bandwidth sampling, congestion detection, and link capacity detection are performed according to the RTCP feedback frame to obtain the current bandwidth sampling data, congestion signal, and link capacity.

[0046] 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) and 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.

[0047] 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 be calculated to obtain accurate bandwidth sampling data of the video stream.

[0048] Specifically, based on the RTCP feedback frames, the one-way transmission delay of the video stream is measured, and based on the one-way transmission delay, the queuing time of the video stream in the transmission link is calculated, including:

[0049] like Figure 3 As shown, in scenarios where bandwidth is underutilized or utilized to 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. When the network is underutilized or 100% utilized, the video stream will not experience additional queuing between multiple frames. Therefore, the one-way transmission delay of the video stream remains essentially constant over a period of time and can be directly used to calculate the queuing time. It should be noted that in actual use environments, scenarios where bandwidth is underutilized or utilized to 100% are very rare and can be ignored. However, scenarios where bandwidth is overutilized are very common, requiring precise calculation of the queuing time under these scenarios.

[0050] like Figure 4 As shown, in scenarios of excessive bandwidth usage, the queuing time of the 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. When bandwidth is excessively used, transient overutilization due to frame size overshoot, bandwidth overestimation, or network bandwidth degradation may lead to queuing across 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 the bandwidth sample size of subsequent frames.

[0051] Furthermore, such as Figure 5 As shown, in a scenario of excessive bandwidth usage, the queuing time of the video stream in the transmission link is calculated, including: S21, saving all one-way transmission delays within the time window and obtaining the minimum one-way transmission delay; S22, smoothing the one-way transmission delay of each frame within the time window to obtain the smoothed one-way delay; S23, calculating the standard deviation of all one-way transmission delays within the time window and calculating 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 calculated bandwidth data exhibits significant jitter during actual data transmission due to jitter generated when measuring the minimum one-way delay, the bandwidth estimate obtained through iterative calculation fluctuates greatly, resulting in low accuracy. Therefore, this embodiment ensures the stability of the bandwidth data by setting a reasonable sampling time window and smoothing parameters.

[0052] For example, the time window is set as 2*min_RTT window (representing a time window based on round-trip time (RTT) dynamic adjustment 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; the one-way transmission delay of each frame is smoothed 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.

[0053] As an alternative embodiment, the formula for calculating the bandwidth sampling data S of the video stream is:

[0054] ;

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

[0056] 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 the actual transmission process of the video stream will be affected by various disturbances, the bandwidth sampling data is corrected by the link capacity to obtain accurate bandwidth data, so as to improve the accuracy of bandwidth estimation.

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

[0058] 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 6As shown, when the size of the video stream is less than the minimum frame threshold, the obtained current bandwidth data is discarded and does not participate in the iterative calculation; when the video stream is very small (e.g., less than 1500B, i.e., the minimum frame threshold is equal to 1500B), the measured bandwidth data is large and not very accurate, and at this time, the data is discarded and does not participate in the iteration, so as 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:

[0059] ;

[0060] wherein γ is the expansion multiple of the video stream. By proportionally expanding the length of the data frame and the queuing time through the formula, the accuracy of the bandwidth estimation can also be improved.

[0061] When packet loss occurs in the transmission process of the video stream, the formula for calculating the bandwidth sampling of the video stream is adjusted to:

[0062] or ;

[0063] wherein is the cumulative length of all packet losses of a video stream in the transmission process; is the packet loss rate of a video stream. Through the formula, the bandwidth data sampled under the condition of packet loss can be corrected, so as to improve the accuracy of the bandwidth sampling.

[0064] As an optional implementation, due to the unsynchronized timestamps of the client and the server, errors and fluctuations will be caused in the measurement of the minimum one-way transmission delay and the queuing time. The server timestamp can be uniformly used (i.e., the client timestamp is converted into the server timestamp), so as to enhance the stability of the calculation result.

[0065] As an optional implementation, when burst reception (i.e., the queuing time of the entire frame is very small (<=1ms), and the receiving end continuously receives multiple data packets in a very short time) occurs, the pipeline will be emptied after congestion and in the stage of recovery. This condition is determined as an abnormal sampling, and the abnormal sampling is skipped, so that the bandwidth sampling value during the burst is directly ignored, so as to avoid the pollution of the iteration process.

[0066] After the bandwidth data is corrected, it is determined according to the congestion signal whether the current link is congested, and if so, step S3 is executed, and the available bandwidth from the sending end to the receiving end is iteratively calculated according to the congestion signal.

[0067] Specifically, the step S3 comprises: when the congestion is detected according to the congestion signal, a multiplicative decrease is first performed; then if the congestion is detected for n times in succession, the multiplicative decrease is performed again, and the strength of the multiplicative decrease is increased, so as to calculate the available bandwidth in the process of performing the multiplicative decrease; since the convergence speed is fast in the calculation, the bandwidth estimation fluctuates frequently in the burst congestion, small jitter and frequent jitter; in order to reduce the amplitude and frequency of the bandwidth estimation jitter, the sensitivity of the congestion signal is adjusted, and the multiplicative decrease is tentatively performed, and the process of performing the multiplicative decrease for n times is the process of iteratively calculating the bandwidth estimation. The trend line estimator is more sensitive in the large bandwidth scene (such as 20 Mbps-30 Mbps), and can detect the congestion too early, so that the detection threshold can be appropriately relaxed to reduce the sensitivity of the congestion signal. The multiplicative decrease (MD) is a core strategy in network congestion control, which means that when the congestion is detected, the current sending rate (or congestion window) is directly multiplied by a coefficient less than 1 (such as 0.5), so as to quickly reduce the load and relieve the network congestion.

[0068] As an alternative embodiment, when the network buffer is large, the burst congestion is generated, and the stall is long (2s+). Since the bandwidth estimation method of the embodiment is to drive the algorithm to iterate in the frame unit, in this scenario, the network buffer is filled, and the received frame of the client is small, so that the bandwidth estimation decreases slowly. When the feedback frame is received, whether the bandwidth estimation generates iteration or network congestion is detected at an interval of 100 ms, if there is no iteration, a forced iteration is performed.

[0069] If the congestion is not generated, the step S4 is performed, and the current available bandwidth from the sending end to the receiving end is iteratively calculated based on the bandwidth data.

[0070] As an alternative embodiment, the formula for iteratively calculating the current available bandwidth from the sending end to the receiving end is:

[0071] ;

[0072] Wherein, represents the iteratively updated available bandwidth; represents the current available bandwidth; represents the step length; represents the reward parameter of the bandwidth utilization rate. Since the bandwidth sampling is unstable, the jitter is large in a short time, so the correct value is converged through the step-by-step iteration.

[0073] As an alternative embodiment, different probing speeds are selected according to the bandwidth estimation to balance the relationship among the convergence speed, experience and code rate jitter. A staged probing rate mechanism is set: when the bandwidth size is 0M->5M, a faster probing speed is set, such as 1 second, to quickly fill the low bandwidth link and reduce the initial lag; when the bandwidth size is 5M->16M, a normal probing speed is set, such as 4-5 seconds, to balance the convergence speed and stability, suitable for mainstream video scenarios; when the bandwidth size is 16M->30M, a slower probing speed is set, such as 10-20 seconds or more than 20 seconds, to avoid excessive probing to cause congestion under high bandwidth; the probing speed refers to the speed of actively increasing the sending rate to probe higher available bandwidth when the network is not fully utilized in the bandwidth estimation (BWE) process, and different probing speeds are selected according to the bandwidth range to quickly discover the idle bandwidth and avoid congestion caused by excessive aggressiveness.

[0074] Further, small fluctuations can be filtered by a lag filter, specifically, if the calculated bandwidth estimation value (compared to the last time) changes less (change amplitude<=1%), the last value is used to correct the bandwidth estimation result.

[0075] The embodiment is only a specific example, and does not indicate that the present application is such an implementation.

[0076] The above is only a preferred embodiment of the present application, and those skilled in the art know that various changes or equivalent replacements can be made to the features and embodiments without departing from the spirit and scope of the present application. In addition, the features and embodiments can be modified to adapt to specific conditions and materials under the guidance of the present application without departing from the spirit and scope of the present application. Therefore, the present application is not limited to the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of the present application are within the protection scope of the present application.

Claims

1. A method for estimating bandwidth in a computing power network, characterized in that, The method comprises the following steps: obtaining an RTCP feedback frame of a video stream, and performing bandwidth sampling, congestion detection and link capacity detection according to the RTCP feedback frame 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 through the congestion signal, comprising: when detecting that congestion occurs according to the congestion signal, performing a multiplicative reduction once; if congestion is detected for n consecutive times, performing multiplicative reduction again and increasing the strength of multiplicative reduction to calculate the available bandwidth in the process of performing multiplicative reduction; if no congestion occurs, iteratively calculating the current available bandwidth from the sending end to the receiving end through the bandwidth data; when receiving a feedback frame, detecting whether iteration or network congestion occurs at a bandwidth estimation interval of 100 ms, and if no iteration occurs, forcibly performing an iteration to avoid burst congestion and long freezing when the network buffer queue is large.

2. The computing power network bandwidth estimation method of claim 1, wherein, The method of performing bandwidth sampling, congestion detection and link capacity detection according to the obtained RTCP feedback frame to obtain current bandwidth sampling data, a congestion signal and link capacity comprises: performing bandwidth sampling by inputting the RTCP feedback frame into a bandwidth sampler to obtain the current bandwidth sampling data; performing congestion detection by inputting the RTCP feedback frame into a trend line estimator to obtain the current congestion signal; performing link capacity detection by inputting the RTCP feedback frame into a code rate estimator to obtain the current link capacity.

3. The computing power network bandwidth estimation method of claim 2, wherein, The method of performing bandwidth sampling by inputting the RTCP feedback frame into a bandwidth sampler to obtain the current bandwidth sampling data comprises: 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 a transmission link according to the one-way transmission delay; calculating the current bandwidth sampling data of the video stream according to the queuing time.

4. The computing power network bandwidth estimation method of claim 3, wherein, The method 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 a transmission link according to the one-way transmission delay comprises: in a scenario where bandwidth is not fully utilized or the utilization rate reaches 100%, the queuing time of the video stream in the transmission link is Rend-Sstart-owd; wherein 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, and owd represents the one-way transmission delay; in a scenario where bandwidth is excessively used, 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.

5. The computing power network bandwidth estimation method of claim 4, wherein, In a scenario where bandwidth is excessively used, the method of calculating the 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; Smooth the one-way transmission delay of each frame in the time window to obtain a smoothed one-way delay; Calculate the standard deviation of all the one-way transmission delays in the time window, and calculate a jitter amplitude according to the standard deviation; Correct the minimum one-way transmission delay according to the jitter amplitude and the smoothed one-way delay.

6. The computing power network bandwidth estimation method of claim 4, wherein, The formula for calculating the bandwidth sample 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.

7. The computing power network bandwidth estimation method of claim 6, wherein, 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; when the frame 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 sample of the video stream is adjusted to: ； Wherein, γ is the expansion multiple of the video stream; Sstart and Rend respectively represent the transmission time of the first data packet and the reception time of the last data packet of the video stream.

8. The computing power network bandwidth estimation method of claim 6, wherein, When a packet loss occurs in the transmission process of the video stream, the formula for calculating the bandwidth sample of the video stream is adjusted to: or ; wherein, is the accumulated length of all lost packets of one said video stream during transmission; is the packet loss rate of one said video stream.

9. The computing power network bandwidth estimation method of claim 6, wherein, The correction of the bandwidth sample data according to the link capacity to obtain the current bandwidth data comprises: According to the characteristics of the packet receiving interval of the video stream, the current link state is obtained; according to the current link state, the bandwidth sample data is filtered by referring to the link capacity, so as to correct the bandwidth sample data according to the link capacity to obtain the current bandwidth data.

Images